El uso de prototipos en el ciclo de vida de construcción del software

 Los prototipos son una técnica ampliamente usada para descubrir y documentar requisitos y casos de uso. En este caso hablamos de los prototipos de la interfaz de usuario, es decir, de todo lo que tiene que ver con la interacción usuario-máquina.

Los prototipos son muy útiles para refinar la especificación de requisitos funcionales del software, específicamente en todo lo que tiene que ver con la descripción de pantallas o formularios de entrada de datos, formulario de salida de datos (consultas), reportes, las opciones de navegación y, en general, toda la carta de navegación del usuario a través del software.

Existen prototipos rápidos y prototipos evolutivos. Los primeros son aquellos que se realizan en las primeras etapas del ciclo de vida y son usados para solucionar inquietudes iniciales relacionadas con la interfaz de usuario que no están claras o precisas en la documentación textual de los requisitos. Estos prototipos pueden ser elaborados en papel o en herramientas básicas como MS-Office (Word, Power Point, Excel, Visio).

Los prototipos evolutivos son artefactos más elaborados que se construyen durante la fase de diseño del software como complemento a la especificación de requisitos (y casos de uso) y que están muy cercanos al diseño final de la solución. Normalmente son hechos con las mismas herramientas con las que será construido el software o con alguna herramienta de automatización que permita generación de código fuente o algo parecido.

Hay distintos aspectos a tener en cuenta durante el uso de prototipos:

•  Tipo de problema a resolver: si el problema es no-estructurado, novedoso, complejo o de manejo de información con un alto grado de personalización para un usuario o un grupo de usuario, entonces la técnica es muy útil.
•  Conocimiento de los requisitos: si se desconocen los detalles de los requisitos del software, si existe poca información al respecto, los prototipos son útiles.
•  Necesidad de revisar, evaluar y aprobar los requisitos: si los procedimientos o controles exigen que los requisitos del software sean revisados, evaluados y aprobados por usuarios y otro tipo de personas, los prototipos serán de gran ayuda a la hora de tomar decisiones.
•  Este aspecto es crucial en muchas compañías ya que el alto grado de formalidad que exigimos para la especificación de requisitos, que tiene carácter contractual, exige que no solo los usuarios revisen y aprueben los requisitos y casos de uso, sino que estos deben ser revisados y valorados en distinto grado por personas de distintas áreas.

En estos casos es cuando los prototipos juegan un papel muy importante ya que aclaran situaciones que no están precisas en los documentos de texto. Sobre todo, con el bajo grado de madurez que tienen los documentos de requisitos y de casos de uso en el medio.

Otros aspectos a tener en cuenta en el uso de prototipos son: la cantidad y calidad de los riesgos del proyecto/requerimiento, no disponibilidad de los usuarios para revisiones y aprobaciones, uso de nuevas tecnologías o la falta de experiencia en el uso de esas tecnologías, entre otros.

Algunas Ventajas del uso de prototipos

1.  Permiten el desarrollo de un sistema a partir de requisitos poco claros o cambiantes. Esto ocurre con cierta frecuencia en muchos proyectos de software.
2.  Como información complementaria a los requisitos (y casos de uso) constituyen un gran apoyo a las estimaciones de esfuerzo de todas las áreas, incluyendo proveedores.
3.  Son más fáciles de abordar con los usuarios finales.
4.  Precisamente, el usuario participa más activamente en la construcción del producto de software (La Solución), ya que “lo puede ver” y, dependiendo del tipo de prototipo,  “utilizar” desde el primer momento.
5. Se reduce el riesgo o la incertidumbre sobre la implementación del software.
6. En general, el uso de prototipos redunda en una mayor satisfacción del usuario con el producto final, ya que él o ella han participado activamente de su diseño.
7. Proporciona al usuario un mayor conocimiento del sistema con una curva menor de aprendizaje.
8. Permite a todos los involucrados (usuarios y equipo de trabajo, incluyendo proveedores) entender bien y mejor el problema antes de la implementación final.

Algunas Desventajas del uso de prototipos

1.  En general, encontramos que el usuario quiere empezar a trabajar desde el primer momento con el prototipo para solucionar su problema particular, cuando el prototipo es solo un modelo de lo que será el producto.
2.  Los prototipos generan o pueden generar otro tipo de problemas si su presentación y discusión con los usuarios no es controlada: puesto que son modelos inconclusos, los usuarios suelen enfocarse en aspectos “superficiales” del prototipo que los pueden dejar inconformes luego de verlos por primera vez. También es posible que se pierda mucho tiempo, innecesariamente, tratando de hacer entender al usuario la finalidad real de los prototipos.
3.  Requiere participación activa del usuario, al menos, para evaluar el prototipo. Y mucho más involucramiento si queremos que participe en su creación.
4. Una desventaja importante a tener en cuenta es la falta de experiencia que tienen muchos Analistas Funcionales en programación y en actividades de diseño de interfaces de usuario.

Revisar/Aprobar Prototipos en Vez de Requisitos/Casos de Uso

Los prototipos son una herramienta complementaria, una técnica más, para la especificación de requisitos (funcionales), incluyendo casos de uso. Con esto en mente, es posible que los usuarios revisen (previa presentación “en vivo”) y aprueben estos prototipos durante la fase de Visión del proyecto/requerimiento. Más adelante, al final de la fase de Diseño (Planeación), el usuario puede confirmar su grado de satisfacción por los prototipos, estos ya más cercanos al producto final.

Tanto los primeros como estos últimos prototipos deben incluir el diseño de formularios de captura o ingreso de datos, formularios de consulta, reportes, opciones de navegación (menú), mensajes de usuario, ayudas en línea, entre otros aspectos. La única diferencia entre unos y otros prototipos debería ser la herramienta usada en la construcción de los prototipos y la precisión (menor en Visión, mayor en Planeación) de tales prototipos.

La otra parte de la tarea, aunque igualmente importante, es que entonces será el Analista Funcional el encargado de verificar que la descripción de los prototipos corresponda a la especificación de los requisitos en su totalidad. Las cosas así, es evidente que se incrementa el esfuerzo de los Analistas, sobre todo en la etapa de Visión y Alcance del proyecto. No obstante, el proceso de construcción de software puede mejorarse con la inclusión de guías para la elaboración de prototipos en las distintas plataformas.

Recomendación para implantar el uso de prototipos en un proceso de software

Como siempre, la recomendación es realizar algunos pilotos controlados donde pongamos en práctica el uso de prototipos en distintos proyectos, donde podamos medir y analizar los resultados con el fin de tener mejores herramientas para tomar la decisión, no solo de incluir los prototipos como una práctica común y hasta obligatoria durante el ciclo de vida, sino para que estos sean revisados/aprobados por los usuarios, en vez de los requisitos y casos de uso.

Casos de Uso 2.0 – Aplicable a todos los tipos de sistemas y organizaciones

Casos de Uso 2.0 puede ser usada en muchos contextos distintos para ayudar a producir muchos tipos de software diferentes.

Aplicable para todos los tipos de sistemas: Mucha gente piensa que los casos de uso son solamente aplicables a sistemas usuario-dependientes, es decir, aquellos donde los usuarios hacen uso intensivo de los mismos, donde hay mucha interacción entre usuarios humanos y el sistema. Esto es extraño porque la idea original de los casos de uso vino de los sistemas telecomunicaciones, que tenían tanto usuarios humanos (suscriptores, operadores) como usuarios máquinas, en forma de sistemas interconectados. Los casos de uso son aplicables para todos los sistemas que son usados.

Casos de Uso 2.0: no es solo para aplicaciones de uso intensivo por usuarios

De hecho, muchos casos de uso son útiles para sistemas embebidos con poca o ninguna interacción humana. Actualmente la gente está usando casos de uso en el desarrollo de cualquier clase de software embebido en dominios tan diversos como el la industria del consumo electrónico, del motor, militar, aeroespacial y médica. Aun sistemas de control de procesos en tiempo real usados para plantas químicas pueden describirse mediante casos de uso, donde cada caso de uso se enfoca en una parte específica del comportamiento del proceso de la planta y de las necesidades de automatización.

Casos de Uso 2.0: no es solo para desarrollo de software

La aplicación de casos de uso no está limitada al desarrollo de software. Estos también pueden ser usados para ayudar a entender los requisitos del negocio, analizar el negocio actual, diseñar nuevos y mejores procesos de negocio, y explotar el poder de la IT para transformar el negocio. Usando casos de uso recursivamente para (1) modelar el negocio y sus interacciones con el mundo exterior y (2) modelar los sistemas necesarios para soportar y mejorar el negocio, es posible identificar fácilmente donde el sistema impactará el negocio y cuales sistemas son necesarios para soportar el negocio.

Los casos de uso usados para modelar el negocio son muchas veces referenciados como casos de uso del negocio. Estos proporcionan el contexto para el trabajo de desarrollo de sistemas de la IT, permitiendo que el desarrollo del negocio y el desarrollo de la IT se lleven a cabo de manera sincronizada. No solo es posible desarrollar los sistemas IT porción por porción sino que también es posible desarrollar el modelo del negocio porción por porción. Esto es muy poderoso porque permite evolucionar el negocio y sus sistemas de apoyo en conjunto unos con otros, habilitando el desarrollo incremental del negocio así como el desarrollo incremental de los sistemas.

En el mundo moderno, el negocio y los sistemas de la IT que lo soportan pueden, y deberían, ser desarrollados en sincronización (uno no trabajará sin el otro). El uso de casos de uso y de porciones de casos de uso tanto en el negocio como en la IT puede cerrar la brecha entre el negocio y la IT habilitando el trabajo como socios colaborativos verdaderos.

¡Quiero una Porción de Caso de Uso!

No se trata de una charada ni nada por el estilo. El concepto fundamental de Casos de Uso 2.0 (como fue expuesta por Ivar Jacobson en su eBook “Use Case 2.0 The Definitive Guide”), es el de caso de uso y con este, el de “porción de caso de uso” (Use Case Slide, en inglés).

Ya sabemos ampliamente qué es un caso de uso y que todos los casos de uso de un sistema constituyen todos los posibles caminos que un usuario puede tomar para usar el sistema. Un caso de uso tiene una meta bien establecida, una estructura de historia entendida por todos los involucrados en el proyecto, pero también un conjunto de historias que el sistema debe satisfacer o cumplir, incluyendo la más simple, la cual es la historia más simple que le permite al usuario alcanzar la meta.

Y todo esto se puede lograr implementando cada caso de uso porción por porción. Así que ¿qué es una porción de caso de uso? Una porción de caso de uso es una o más historias seleccionadas de un caso de uso para formar un elemento de trabajo que es de valor claro para el usuario. La porción actúa como un contenedor para todo el trabajo requerido para completar la implementación de las historias seleccionadas. Las porciones de casos de uso son más que requisitos y casos de prueba y evolucionan para incluir las porciones correspondientes a través del diseño, la implementación y las pruebas.

La porción de caso de uso es la parte más importante de Casos de Uso 2.0 y no es solamente usada para ayudar con los requisitos sino también para conducir el desarrollo de un sistema que los solucione. Las porciones de caso de uso:

·         Posibilitan que los casos de uso sean divididos en unidades de trabajo más pequeñas e independientemente entregables.

·         Posibilitan que los requisitos contenidos en un conjunto de casos de uso sean ordenados, priorizados y tratados en paralelo.

·         Enlazan los distintos modelos de un sistema (requisitos, análisis, diseño, implementación y pruebas) usados en el desarrollo dirigido por casos de uso.

Por ejemplo, en un caso de uso cuyo propósito es que un cliente de un banco retire dinero vía cajeros electrónicos (ATM), una porción básica del caso de uso es aquella en la que el cliente inserta su tarjeta débito, proporciona los datos de su pin y la cantidad a retirar y la máquina le entrega la cantidad solicitada. Otra porción puede ser aquella en la que el pin no concuerda con los datos de la tarjeta, otra porción es cuando el cliente no tiene fondos suficientes, otra es cuando el cliente ingresa varias veces el pin de manera incorrecta y el sistema bloquea la tarjeta. Y así, puede haber muchas porciones de caso de uso en un caso de uso relativamente simple.

Así que ¿de qué sabor quieres tu porción de caso de uso?

PD. Sobre casos de uso, los invito a leer las Lecturas Fundamentales de este Gazafatonario IT. http://gazafatonarioit.blogspot.com/2006/11/lecturas-fundamentales.html.

Sobre casos de uso 2.0, pueden ver mi artículo en:

http://gazafatonarioit.blogspot.com/2012/04/casos-de-uso-20.html

Y este otro:

http://gazafatonarioit.blogspot.com/2012/04/casos-de-uso-20-y-metodos-agiles.html

Todavía Otro Cuerpo de Conocimiento Más (BABOK 2.0)

El Business Analysis Body of Knowledge (BABOK) es una colección de conocimiento dentro de la profesión del Análisis de Negocio y refleja unas mejores prácticas generalmente aceptadas. Como con otras profesiones, el cuerpo de conocimiento es definido y mejorado por profesionales Analistas de Negocios quienes lo aplican en su trabajo diario. El BABOK  describe las áreas de conocimiento del Análisis de Negocio, sus actividades asociadas y las tareas y habilidades necesarias para ser efectivo en su ejecución.

Como todo cuerpo de conocimiento (PMBOK, SWEBOK, entre otros), el BABOK tiene varias áreas de Conocimiento. Cada una de estas áreas se enfoca en una parte del análisis del negocio. Estas áreas son:

·         Planeación y Monitoreo del Análisis de Negocio

·         Obtención de Requisitos

·         Gestión y Comunicación de Requisitos

·         Análisis Empresarial

·         Análisis de Requisitos

·         Evaluación y Validación de la Solución

·         Competencias Subyacentes 

·         Dinámica de Análisis de Negocios 

Me parece importante anotar que esto no es más que eso, una propuesta de prácticas que funcionan en ciertos contextos, en muchos realmente, pero no es una solución definitiva a todos los posibles escenarios que nos encontramos en la “vida real” del análisis y modelado de negocios en los proyectos actuales.

Cuando se trata de estándares siempre recomiendo darles el beneficio de la duda. Lo primero que debemos hacer es estudiarlo profusamente y entenderlo, apoyándonos en expertos que lo hayan puesto en prácticas en diversas situaciones. A partir de allí, podemos iniciar un proceso de adopción y adaptación. A esto último yo lo llamo “tropicalización”.

Lo adaptamos a nuestras necesidades, a nuestra forma de hacer las cosas, a nuestro presupuesto y economía, a nuestra experiencia (que siempre nos va a faltar), a nuestra idiosincrasia, a nuestra forma de ver el mundo y de interpretarlo, a la agenda tan apretada que tenemos en los proyectos. Esto es importante, porque este tipo de estándares son definidos por organizaciones o grupos de organizaciones que tienen otra filosofía, existen en otras economías (generalmente mejores que las nuestras), la gente que los práctica allá piensa diferente, los proyectos tienen otros presupuestos y otras agendas, los equipos de trabajo son más grandes, tienen más recursos y más experiencia, tienen más expertos, etc.

¿A quiénes les interesa este estándar?

Principalmente a los Analistas del Negocio, pero también a los Ingenieros de Requisitos o Analistas de Requisitos.

“El Analista de Negocios es el responsable de identificar las necesidades de negocios de sus clientes y usuarios interesándose en ayudarlos a determinar las soluciones a sus problemas”.

·         El Analista de Negocios es responsable del:

o    Desarrollo y Administración de Requisitos de sistemas

o    Validación de requisitos para re-ingeniería de Procesos

o    Análisis y recomendación de soluciones de mejora continua

o    Validación y documentación de problemas y oportunidades de negocio

o    Análisis de requisitos Organizacionales u Operacionales

·         Las Soluciones NO son predeterminadas por el Analista- de Negocios- y son manejadas solamente a través del requerimiento de negocios.

·         Las Soluciones frecuentemente incluyen componentes de desarrollo de sistemas- pero pueden también consistir en mejoramiento de procesos o cambios organizacionales.

·         El Analista de Negocios es el facilitador clave dentro de una organización, el cual actúa como puente entre el cliente, el usuario interesado y el equipo de solución.

·         El Análisis de Negocios es distinto al análisis financiero, a la administración de proyectos, al aseguramiento de calidad, al desarrollo organizacional, a la ejecución de pruebas, a la capacitación y al desarrollo de documentación.

Sin embargo dependiendo de la organización, un Analista de Negocios puede ejecutar alguna o todas estas funciones relacionadas.

Estándares Relacionados

Relacionado estrechamente con el BABOK encontramos el SWEBOK (Software Engineering Book of Knowledge), sobre todo en el capítulo 2 que tiene que ver con Ingeniería de Requisitos. Este estándar es soportado por la IEEE.

Analista del Negocio versus Analista Funcional, Parte 2

Veamos ahora el asunto con el Analista Funcional. Este es también conocido como Analista del Sistema, Analista del Software o también Ingeniero de Requisitos.

En términos simples, este personaje es quien identifica (captura), documenta, organiza y administra los requisitos del sistema de software. Más exactamente, es quien desarrolla la Visión del Sistema, atiende las solicitudes de todos los involucrados, define el contexto del sistema, encuentra actores y casos de uso del sistema y estructura el modelo de casos de uso; también es quien desarrolla las especificaciones suplementarias (requisitos no funcionales y otros) y administra las dependencias entre los requisitos.

Este Analista Funcional es quien tiene la tarea de definir el producto que luego usarán los usuarios para resolver sus necesidades de negocio, como se la expresaron al Analista del Negocio. ¿Ah, ya vieron la relación?

Siendo consecuentes con la definición que hice de Analista del Negocio, es recomendable que un analista funcional sea, entre todo lo demás, un experto en la identificación y entendimiento de problemas y oportunidades. Esto incluye la habilidad de articular las necesidades que están asociadas con el problema clave a ser resuelto u oportunidad a ser abordada. A esto yo lo llamo, conocer el problema detrás del problema.

Por supuesto, un buen analista del sistema es un buen facilitador y también debe tener excelentes habilidades de comunicación (todo tipo de comunicación). El conocimiento del dominio del negocio y de la tecnología son habilidades adicionales útiles para estas personalidades. Sin embargo, estas últimas son de menos importancia si el individuo tiene la habilidad de absorber y entender información nueva rápidamente. Y ya que es un papel central en los equipos de proyectos, un analista funcional debe ser capaz de colaborar efectivamente con otros miembros del equipo.

¿Y todo esto qué nos dice? Que siempre es posible que un Analista Funcional o Ingeniero de Requisitos juegue a ser Analista del Negocio; y al contrario, un Analista del Negocio puede ser un analista funcional, aunque esto último no siempre es posible, ya que un Analista del Negocio puede ser “interpretado” por alguien que no tenga preparación académica ni experiencia en tecnología de software y relacionados. Al menos, eso me lo ha enseñado la experiencia. Con el tiempo, ambos roles se pueden intercambiar uno con otro, yo lo he hecho durante la última década sin problemas.

También ocurre que en proyectos de medianos a grandes y dependiendo del presupuesto del proyecto y de la organización, es posible tener los dos roles por separado; pero la mayoría de las veces estos dos roles son jugados por una sola persona. Si son dos personas distintas, deben trabajar en estrecha relación, apoyándose mutuamente y comunicándose todo el tiempo. Este es el factor de clave éxito: la comunicación. No en vano, la recomendación de que ambos figurantes tengan esta como una de sus destrezas esenciales.

----------------------------------------------------------------------------------------------

La primera parte de este artículo lo encuentran en este mismo blog en:

http://gazafatonarioit.blogspot.com/2012/04/analista-del-negocio-versus-analista.html