Casos de Abuso, Parte 4: Resumen ejecutivo

Recapitulemos. Tenemos una lista corta de escenarios en donde estamos usando mal los casos de uso como instrumentos para identificar, organizar, documentar y administrar requisitos de software, tanto funcionales como no funcionales.

Estos son los casos enumerados hasta el momento:

1.    El caso de uso es la única documentación necesaria para construir el software.

Impacto en la calidad: Alto.

2.    El caso de uso se usa en todos los casos.

Impacto en la calidad: Bajo.

3.    Lo que no está documentado en los casos de uso no hace parte del sistema.

Impacto en la calidad: Medio.

4.    El caso de uso se identifica, elabora, diseña, implementa y prueba en la misma iteración.

Impacto en la calidad: Medio.

Entonces, ya sabemos que la especificación de requisitos de software (ERS) viene, o puede aparecer, en recipientes de distintos tamaños y diferentes formas y colores: algunos son cacharros escuetos pero con significado y suficiencia para quien los elabora y para los interesados en los mismos, otros son cristalerías sofisticadas que se aproximan a lo mundano, en el sentido de cosmopolita. Pero contienen requisitos de software, al fin y al cabo.

En términos de artefactos de especificación y modelado de sistemas de información, estoy hablando de folios de especificación funcional, con sus requisitos en prosa y todo el detalle aledaño que siempre los acompaña; pero también me refiero a la descripción de procesos del negocio, desde macro-procesos, hasta tareas simples y atómicas, pasando por procesos y subprocesos; representaciones de herramientas visuales como prototipos estáticos y simuladores.

También hago alusión a diagramas de UML, como  diagramas de actividad y de estado, diagramas de procesos, diagramas de contexto y mapas mentales, entre algunos otros; descripción de reglas y políticas del negocio; acuerdos de entendimiento entre los usuarios y el área de tecnología; listas de deseos escritas a mano; y, las más usadas, historias de usuario y casos de uso. Incluso, con las nuevas tecnologías, los requisitos de software bien pueden aparecerse en formato de videos o audios digitales, fotografías de alta definición capturadas por teléfonos inteligentes, mensajes electrónicos y trinos de 140 caracteres o menos.

Usualmente, la ERS se exhibe en una combinación de dos o más de estos instrumentos y lo único que importa es que provenga de las personas apropiadas e interesadas en el producto de software y que cada requisito cumpla o pueda cumplir con algunos atributos o rasgos de calidad:

·         Claridad

·         Atómicidad

·         Precisión

·         Verificabilidad

·         Necesidad u oportunidad

·         Priorización

La ERS, por su parte, debe ser:

·         Independiente de diseño

·         Completa

·         Consistente

·         Rastreable

·         Modificable / Extensible

Ahora ya sabemos cómo corregir algunos de esos defectos. ¿Ustedes qué creen?

Salud@s.

Casos de Abuso, Parte 3: El caso de uso se identifica, elabora, diseña, implementa y prueba en la misma iteración

El modelo iterativo de desarrollo de software dicta que podemos construir el sistema mediante incrementos en períodos de tiempo relativamente cortos y con un objetivo fijo. A estas fases de tiempo se les conoce como Iteraciones y al producto (resultado) de la fase se le conoce como Incremento.

En otras palabras, una iteración es un mini-proyecto con una salida bien definida: una versión incrementada, estable, probada e integrada del producto de software, con su documentación asociada. Pues bien, una de las faltas típicas que cometemos durante el ciclo de vida del software tiene que ver con esto.

Veamos de qué se trata:

Caso de Abuso 4: El caso de uso se identifica, elabora, diseña, implementa y prueba en la misma iteración.

Este es un error muy común al iniciarse en un proceso iterativo. Un caso de uso pasa por varias etapas o períodos durante su ciclo de vida: desde la identificación o descubrimiento del caso de uso, hasta la puesta en ejecución del mismo, pasando por la Ingeniería del Caso de Uso (conocida entre nosotros como la Ingeniería de Requisitos), el Análisis y Diseño, la Implementación, las Pruebas y el Despliegue final.

Y cada una de estas etapas ocurre a través distintas fases del proyecto y de diferentes iteraciones. Durante la fase de inicio o visionamiento del proyecto, descubrimos un número significativo de casos de uso y algunos de ellos pasan a la etapa de Ingeniería de Requisitos; muy pocos de estos casos de uso llegan a la etapa de Análisis y Diseño y ninguno llega a la Implementación.

Más adelante, durante la fase de Planeación o Elaboración del proyecto, los llamados casos de uso arquitectónicos, de los identificados en la fase previa, llegan a las etapas de implementación y pruebas, mientras que otros casos de uso son descubiertos y otros llegan al período de Ingeniería de requisitos.

Durante las siguientes fases del proyecto, algunos pocos casos de uso son identificados, los últimos, y los demás pasan, iteración tras iteración, por las etapas expuestas; pero nunca, un caso de uso se identifica y llega a implementarse en la misma iteración, por muy simple que sea. Eso sería apenas una simple coincidencia y, casi siempre, un error.

Muy relacionado con este abuso está el abuso No. 12, aunque hay diferencias fundamentales entre aquel y este. (Lo veremos en su momento)

Impacto en la calidad: Medio.

PD. Sobre iteraciones, los invito a leer mi artículo Gerencia de Proyectos Iterativos en la Revista Project Management Iberoamericano de la Asociación Española de Profesionales en Dirección de Proyectos.

Casos de Abuso, Parte 2: El caso de uso es la única documentación necesaria para construir el software

Abusar.

(De abuso).

1. intr. Usar mal, excesiva, injusta, impropia o indebidamente de algo o de alguien. Abusaba DE su autoridad.

Real Academia Española © Todos los derechos reservados

Caso de Abuso 3: El caso de uso es la única documentación necesaria para construir el software.

Quizás esta idea surge de la premisa de que el proceso de desarrollo de software es dirigido por casos de uso [1], que es algo mucho más amplio y totalmente distinto. Además, está el factor tiempo que siempre hace falta en los proyectos de desarrollo de software.

Un caso de uso es el primer repositorio de documentación en un proyecto, puesto que es el artefacto que legitima los requisitos funcionales del software. Sin embargo, después del caso de uso y antes del código fuente hay un abismo sobre el que debemos construir un puente para ir desde la solicitud del usuario, su problema y sus necesidades, hasta un sistema de software que soporte su proceso, que resuelva su problema y cubra sus necesidades.

Ahora bien, hay casos de casos: están los llamados casos de uso arquitectónicos o más complejos, que bien podrían representar alrededor del 20% del total de casos de uso de un proyecto. A estos casos de uso debemos aplicarles rigurosamente el proceso: Análisis, Diseño, Implementación, Pruebas, Despliegue y vuelta a empezar. Y durante el Análisis y el Diseño se construyen una serie de artefactos que van desde documentos anexos hasta diagramas (de UML) de casos de uso, de secuencia, de comunicación, de clases, de estados, de actividad y de entidad-relación, entre otros. También están los requisitos no funcionales o especiales que aplican a cada uno de esos casos de uso, el pseudocódigo y los prototipos; asimismo, están los casos y procedimientos de prueba.

Es principalmente durante el período de Análisis y Diseño del caso de uso cuando ocurre la suplementación del mismo, es decir, la adición de detalles técnicos y no funcionales al caso de uso. Y en todas estas actividades intervienen todos los miembros del equipo del proyecto: unos elaboran y presentan, otros retroalimentan, complementan, realizan el siguiente paso y también lo presentan, y así, en una espiral en la que el producto se va gestando hasta quedar terminado.

Luego están los demás casos de uso del proyecto, el otro 80%. Unos son más complejos que otros desde el punto de vista de diseño, mientras que algunos son más críticos que otros desde la perspectiva del usuario. Muchos de estos casos de uso, sino todos, también deben someterse al mismo proceso que los anteriores. Lo que varía es la severidad o formalidad con que se elaboren todos esos artefactos.

Dependiendo del tipo de proyecto, de los aspectos legales del mismo y de otras variables del entorno, será necesario realizar cada documento siguiendo plantillas formales del proceso de desarrollo, casi con rigurosidad científica: diagramas de UML bien construidos y detallados, tantos como sean necesarios para entender el producto, documentos sujetos al escrutinio de revisiones técnicas y de estilo, con listas de chequeo formales y con todas las excepciones consideradas. Algunos casos de uso requerirán de tres, cinco o más diagramas de interacción, por ejemplo; otros necesitarán sólo uno de estos diagramas.

En otros proyectos, menos formales desde el punto de vista legal (aunque es difícil imaginar tal cosa), será suficiente con que estos artefactos se elaboren en reuniones de análisis y diseño en un tablero donde todo el equipo de desarrollo pueda verlos, opinar, tomar nota y entenderlos, que es el objetivo último del modelado.

La categoría de las herramientas a usar también depende de la complejidad técnica y de la formalidad legal: para unos proyectos basta lápiz y papel, o tiza y tablero, mientras que para otros serán necesarias herramientas sofisticadas de Ingeniería de Software.

En cualquier caso, nunca hay que perder de vista que el software, por naturaleza, es complejo; y que construir software, por naturaleza, es una actividad compleja. También, que las herramientas con las que se construye software (que casualmente están hechas de software) también son complejas. Y con este nivel de complejidad, no es posible que algo simple, como el caso de uso, sea capaz de resolver nuestro problema sin más colaboración.

Impacto en la calidad: Alto.

Referencias

[1]   Luis Antonio Salazar Caraballo, “RUP: Fase de Concepción”, Gazafatonario IT,  http://gazafatonarioit.blogspot.com/2007/03/lecturas-fundamentales-8.html, 08 mar. 2007.

La Parte 1 de este análisis lo encuentras en: http://gazafatonarioit.blogspot.com/2012/09/casos-de-abuso-parte-1.html

Sobre abecés, anatomía y prácticas de casos de uso y requisitos en general, puedes visitar mi Sección Lecturas Fundamentales en este mismo Gazafatonario IT.

http://gazafatonarioit.blogspot.com/2006/11/lecturas-fundamentales.html

Casos de Abuso, Parte 1: El caso de uso se usa en todos los casos

La segunda ley de la Ingeniería del Software o el modelo Información-Materia-Energía (IME) establece que el mundo natural que forma el contexto de la inteligencia humana y la ciencia del software es una dualidad: un aspecto de ésta es el mundo físico y el otro es el mundo abstracto, donde la materia y la energía son usadas para modelar el primero, y la información, para modelar el segundo. Los modelos del mundo físico han sido bien estudiados por la Física y otras ciencias naturales. Sin embargo, el modelado del mundo abstracto todavía es un problema fundamental a ser explorado por la ingeniería del software.

Ahora bien, aunque el mundo físico es el mismo para todas las personas, el mundo natural es percibido de forma diferente por distintos individuos debido a que el mundo abstracto, como parte de éste, es subjetivo dependiendo de la información que los individuos obtienen y perciben. Y es debido a esta diversidad en la percepción del mundo abstracto que se presentan los errores en la ingeniería del software y por ello es que son más comunes de lo que a veces queremos. En el ciclo de vida de la ingeniería del software, esos errores empiezan durante la identificación, especificación y modelado de casos de uso.

Algunas de estas falencias, son las que empezaré a presentar a partir de hoy en varias entregas. Se trata de un estudio de los malos usos de los casos de uso.

Este es realmente un estudio patológico y forense: es patológico porque hago un estudio de los desórdenes más comunes encontrados durante mis continuas revisiones de casos de uso a todo lo largo de su ciclo de vida: identificación, especificación, análisis, diseño, implementación y pruebas. Quise hacer este estudio en un sentido amplio, es decir, observé estas alteraciones como procesos o estados anómalos de raíces conocidas o ignoradas. También es patológico porque extraje las pruebas que señalan la presencia de tales afecciones del examen minucioso de cada error en todos sus niveles estructurales, desde el nombre del caso de uso, hasta las secuencias básica y las alternativas del mismo, pasando por la breve descripción, las pre y poscondiciones, el actor y los requisitos especiales, entre otros aspectos. Desde este punto de vista me convertí en un anatomopatólogo o, simplemente, en un patólogo clínico de los casos de uso, si es posible trasladar ese término médico a nuestro entorno.

Es forense porque estudié los aspectos técnicos derivados de la práctica diaria de los equipos de desarrollo de software, en los que he participado centenares de veces, como sujeto activo y como perito. Bajo este último título he tratado de contribuir con mi actuación a dar valor y significación genuinos a los aciertos hechos en materia de especificación y evolución de casos de uso y también a la promoción de ciertas prácticas que creo exitosas en la industria. En particular, he tenido la oportunidad de examinar y recoger indicadores de casos de uso propios y de extraños (colegas, clientes, socios de negocio); de los modelos y especificaciones de casos de uso he determinado los elementos donde se presentan los errores, las posibles causas de los mismos y he presentado posibles soluciones.

Caso de Abuso 1: El caso de uso se usa en todos los casos.

Es un juego de palabras pero es falso. Los casos de uso son un repositorio, un mecanismo de comunicación durante el ciclo de vida de desarrollo del software. Contienen y transmiten requisitos y otros aspectos relacionados con la funcionalidad del software en construcción.

Pero hay muchas maneras de documentar todo esto: documentos de requisitos funcionales y no funcionales donde, en prosa, se especifican los detalles del producto. En otros casos se pueden usar prototipos, como en los reportes ad-hoc o estándares, donde preparar un documento en el que se muestre como lucirá un reporte es más práctico que escribir en palabras los detalles del mismo. En otros casos, serán necesarios uno o más diagramas de UML (de estados o de actividad, por ejemplo), como cuando la descripción en prosa del proceso funcional es engorrosa debido a la complejidad del proceso y, además, un prototipo no es suficiente o no aplica.

Impacto en la calidad: Bajo.

Caso de Abuso 2: Lo que no está documentado en los casos de uso no hace parte del proyecto.

Esta es una consecuencia del abuso anterior. En muchas ocasiones usamos sólo los requisitos que están consignados en casos de uso para realizar la estimación del proyecto, para considerar tiempos y recursos, para definir la arquitectura del software y para diseñar el sistema. Sólo cuando ya es muy tarde alguien recuerda que hay otras funcionalidades a diseñar e implementar y que posiblemente afecten no sólo la arquitectura del sistema, sino también los tiempos y los recursos necesarios para terminar el producto. Un caso típico ocurre cuando el producto tiene muchos procesos batch, de esos que se ejecutan por la noche o al cierre de un período específico y que hacen uso intensivo de datos sin ninguna interfaz gráfica. Otro caso se presenta con las consultas y reportes, muchas veces menoscabados, en el sentido de reducidos, por todos los involucrados en el proyecto.

Impacto en la calidad: Medio.

¿Es maduro tu proceso de Ingeniería de Requisitos?

Hace algún tiempo, cuando me involucré en las iniciativas de mejoramiento de procesos de Intergrupo, las que finalmente condujeron a alcanzar el nivel CMMI 5, entendí que la cultura orgánica tiene su propio proceso natural de supervivencia y éxito y que siempre debía medir cuidadosamente lo que es adicionado y es removido de mi entorno. Por supuesto, siempre he tenido claro cuando ser “interno” o “externo” al proceso.

Fue una época en que puse en práctica algunos de los principios memorables de Deming en Administración: “La mejora de procesos debe ser realizada para mejorar el negocio – No como un objetivo en sí misma”. Y empezaba a pregonar que un proceso debe usar prácticas probadas en la industria, no solo la última moda, lo que escuchamos en la conferencia del día anterior o lo que leímos en el último artículo de la IEEE.

Y lo más importante, difundía a mil voces que debemos ser prácticos, que debemos entregar la información que se necesita, cuando se requiere y en un formato que se pueda usar. Con todo esto en mente, usamos un modelo de madurez típico como CMMI para mejorar nuestros procesos. Y uno de los primeros procesos que optimizamos fue este de la Ingeniería de Requisitos.

Pero ¿cómo saber si tu proceso es lo suficientemente maduro? ¿En la práctica qué significa identificar, documentar y administrar requisitos de software de una manera formal y razonable? Según el SEI (siglas en inglés del Instituto de Ingeniería de Software), autor del modelo CMMI, “los requisitos son manejados y las inconsistencias con los planes de proyecto y los productos de trabajo son identificadas”.

Lo que no dice el SEI en su área de proceso de RM (siglas en inglés de Administración de Requisitos), es que esas inconsistencias deben detectarse a tiempo porque cualquier cambio que involucre requisitos es altamente costoso para el proyecto y para los participantes en el mismo.

Para manejar los requisitos, el SEI recomienda:

·         Entender los requisitos

·         Acordar los requisitos con todos los involucrados

·         Administrar los cambios a los requisitos

·         Mantener una rastreabilidad bidireccional de los requisitos

·         Identificar las inconsistencias entre el trabajo del proyecto y los requisitos

Parece sencillo pero quienes hemos trasegado por los vericuetos de la Ingeniería de Requisitos con casos de uso sabemos que es más fácil decirlo que hacerlo y, sobre todo, hacerlo bien. Por ejemplo, sin duda es más simple entender y acordar requisitos entre las personas que están más involucradas en el proyecto, como los Analistas y los usuarios que quienes empiezan a llegar a medida que avanza el ciclo de vida, como los programadores o los certificadores.

Manejar los cambios, naturales por demás en un proyecto típico de software, es muchas veces otro dolor de cabeza para los participantes. Hay quienes creen que una solicitud de cambio es algo de menor valía, cuando la experiencia nos ha enseñado que sea cual fuere el momento y la fuente de la solicitud, siempre hay un impacto significativo y hay costos ocultos que solo los experimentados son capaces de descubrir a tiempo.

Por su parte, mantener una trazabilidad adecuada de los requisitos en ambas direcciones, lo que significa tener un mapa desde las necesidades del usuario y características del software, hasta el código ejecutable, pasando por los casos de prueba y otros artefactos importantes, es algo que solo se puede lograr adecuadamente con el uso de herramientas especializadas. En proyectos pequeños es posible que un Excel sirva, pero en algo más elaborado necesitamos de los instrumentos apropiados.

En cualquier caso, estas prácticas recomendadas (y esta es la palabra clave: “recomendadas”), son apenas un primer escaño para alcanzar la tan ansiada madurez en nuestros procesos de Ingeniería de Requisitos. Volveremos sobre ello más adelante.

Ventajas y Desventajas del Uso de Prototipos

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 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.       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.       Su uso 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 entender bien y mejor el problema antes de la implementación final.

Algunas Desventajas del uso de prototipos

1.       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 suplementaria a la especificación de requisitos (funcionales). Con esto en mente, es posible que los usuarios revisen y aprueben estos prototipos durante la fase inicial del proyecto. Más adelante, el usuario puede confirmar su grado de satisfacción por los prototipos, más cercanos al producto final.

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.

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.