Requerimientos

La Importancia de la Ingeniería de Requerimientos

ana2lp — Wed, 03 May 2017 06:17:27 +0000

La Importancia de la Ingeniería de Requerimientos

ana2lp Wed, 05/03/2017 - 01:17

Publicado en

SG #54

Requerimientos

Autor

Guilherme Siqueira Simões

La ingeniería de requerimientos es una de las disciplinas fundamentales de la ingeniería de software y proporciona información para la mayoría de las demás disciplinas. Este artículo presenta resultados de investigaciones que fundamentan de manera cuantitativa esta cuestión. El propósito es demostrar las consecuencias del descuido de la disciplina de requerimientos: retrasos en el cronograma y costo adicional, nivel alto de defectos en el software y principalmente la entrega de un software que no satisface las necesidades del cliente.

Fallos famosos

Para ilustrar, a continuación se muestran casos famosos de fallos en proyectos de software relacionados con algún tipo de discapacidad en el ejercicio de la ingeniería de requerimientos.

La sonda espacial Mars Climate Orbiter (MCO)

La MCO fue una sonda espacial cuyo objetivo principal era estudiar el clima de Marte. Fue lanzada en diciembre de 1998, alcanzando Marte nueve meses y medio después. Al entrar en la órbita de Marte, la sonda fue destruida en la atmósfera debido a un error de cálculo en la maniobra. El error fue causado porque el software responsable del cálculo de ruta de entrada esperaba datos usando el sistema de medidas imperial (libras fuerza) y recibió datos en sistema métrico universal (newtons). No se sabe si la NASA proporcionó la especificación equivocada al proveedor que desarrolló el software o si hubo una falla del proveedor en el levantamiento de requerimientos.

Misil antibalístico Patriot

Durante la Guerra del Golfo, los Estados Unidos usaron un sistema de defensa con misiles antibalísticos llamado Patriot. El 25 de febrero de 1991 este sistema falló y no interceptó el misil Scud lanzado por Irak que mató a 28 militares y lesionó otros 98.

La raíz de la falla fue que el software original del sistema utilizaba datos de las señales del radar para calcular la ruta del Patriot y trabajaba con una precisión de fracciones por segundo. Para hacer frente a misiles de más alta velocidad, se creó una subrutina para manejar el tiempo con mejor precisión (más decimales). Sin embargo, esta subrutina no fue aplicada a todas las partes necesarias del software lo que generó una acumulación de fallas de precisión; y después de cierto tiempo, el sistema se quedaba ineficaz. No fue sólo un fallo de programación, fue también un fallo de evaluación en el impacto del cambio.

Cohete Ariane 501

El 1996, el cohete Ariane 501 fue lanzado y unos 37 segundos después del despegue, se desvió del curso esperado para después explotar. Fue el primer lanzamiento de la serie Ariane 5. La pérdida del cohete y su carga ascendieron a una pérdida de más de 370 millones de dólares. La comisión de investigación señaló que la falla había estado en el sistema de referencia inercial, el cual había sido reutilizado de la serie Ariane 4. El problema fue que el Ariane 5 estaba diseñado para transportar más carga, lo que implica otros estándares de trayectoria y velocidad diferentes, y esto no se tomó en cuenta al realizar el diseño y pruebas pertinentes.

Archivo Virtual FBI

A principios del 2000, el FBI comenzó el desarrollo de un software llamado Virtual Case File (VCF) que permitiría el intercambio de información de casos entre los agentes. Originalmente se estimó que el desarrollo tomaría 3 años. Después de la tragedia del 11 de septiembre de 2001 el FBI recibió fuertes críticas por no anticipar el ataque; las evidencias estaban expuestas, el error fue no enlazarlas entre sí. Ante esto, se decidió aumentar la prioridad del VCF y extender su alcance. Cinco años y 170 millones de dólares después, el sistema no había podido ser terminado y se canceló su desarrollo. La investigación a cargo determinó que las principales causas de fracaso fueron:

Cambios frecuentes en los requerimientos. El proveedor alegó que el FBI adoptó la filosofía de trabajo de: "Yo sé lo que quiero después de ver el producto."
Alta rotación de gestión (también contribuyó a los cambios frecuentes).
Aumento descontrolado del alcance, con requerimientos agregados incluso cuando el proyecto ya estaba retrasado.

El principal motivo de fracaso

De acuerdo con cifras del Project Management Institute (PMI) [1], el 47% del fracaso de los proyectos es causado por una deficiencia en el ejercicio de la ingeniería de requerimientos. Algunos casos comunes:

El producto se entrega sin cumplir con los requerimientos necesarios, sin identificar varios de ellos.
La entrega final es un producto que no satisface al cliente, aunque a tiempo y dentro del presupuesto.
El proyecto incorpora requerimientos que no deben estar en el alcance.
La estimación de costo/esfuerzo se hace en base a un alcance equivocado ya que no considera algunas áreas funcionales y procesos de negocio.
Fallas de comunicación sobre requisitos, lo que resulta en la entrega de un producto defectuoso.
Cambios innecesarios debido a la falta de atención por comprender correctamente las necesidades del cliente al principio.

Una de las principales causas de defectos

Los defectos pueden surgir en cualquier etapa del ciclo de vida del proyecto, siendo el más común aquellos insertados durante la construcción, donde el producto construido tiene un comportamiento diferente al especificado.

Asimismo, un número significativo de defectos se origina a partir de los requerimientos. Pero, ¿La calidad no es cumplir con los requerimientos? ¿Cómo sería posible ello? Simple, basta que la especificación no represente correctamente las necesidades del usuario.

Según, Capers Jones [2], 1 de cada 5 posibles defectos se origina en los requerimientos, y estos pueden ser hasta el 60% del total de errores en el proyecto según explica Pohl [4]. La problemática es que estos sólo se detectan en etapas avanzadas del proyecto, a menudo cuando se aprueba el producto. Por otro lado, Leffingwell [5] acota que en proyectos complejos la fuente más común de errores son los requerimientos. Esto último se refleja en los resultados mostrados por Jones y Bonsignour [3] que se capturan en la tabla 1 donde se muestra la tasa potencial de defectos por punto de función segregados por la fuente del defecto y estratificado de acuerdo al tamaño del sistema.

Origen del Defecto	Tamaño del sistema (en puntos de función)
	100	1,000	10,000
	Defectos potenciales (bugs/PF)
Requerimiento	0.75	1.00	1.25
Arquitectura	0.10	0.25	0.50
Diseño	1.00	1.25	1.50
Código fuente	1.70	1.75	2.00
Material de pruebas	1.50	1.85	2.00
Documentación	0.65	0.70	0.75
Base de datos	2.00	2.75	3.00
Website	1.50	1.75	2.00
Total	9.20	11.30	13.00

Tabla 1. Defectos en potencial por tamaño de sistema y origen.

Los defectos originados en requerimientos son más difíciles de eliminar por métodos tradicionales: pruebas y análisis estático. Esto se debe a que cuando se aprueba la especificación con un requerimiento defectuoso, los casos de prueba son elaborados a partir del comportamiento equivocado.

Adicionalmente, los cambios en requerimientos tienden a una densidad de defectos mayor, debido a que típicamente son tratados a toda prisa. Y son más difíciles de eliminar porque “saltan” el control de calidad del proyecto. Por ejemplo, un crecimiento del 10% en el alcance del proyecto implica un aumento del 12% en el número de defectos.

El costo de reparación de los defectos

La industria del software tiene un gran potencial para explotar las ganancias de eficiencia. Según Boehm [6] del 40 al 50% del esfuerzo en los proyectos de software se gasta en la corrección de defectos. Uno de los factores que contribuyen para esta ineficiencia es que al corregir un defecto existe un 20-50% de posibilidades de introducir otro error al software [7].

Pohl [4] sostiene que la mayoría de los errores originados en los requerimientos se detecta en las etapas avanzadas del proyecto. Él afirma que una parte significativa de estos errores se identifica durante la validación por el cliente. El esfuerzo de encontrar y corregir un defecto después de la entrega, suele costar a menudo 100 veces más que corregirlo cuando todavía se está desarrollando los requerimientos. Como se observó en los casos citados, los errores detectados con el software en operación pueden causar daños en varios órdenes de magnitud mayor al costo de corrección del defecto.

El objetivo es desarrollar el producto correcto en el primer intento. De esta manera, se reducen los errores en las primeras etapas del proyecto en donde se puede mitigar con mayor intensidad la reanudación. El método de ensayo y error, además de ser más caro y demorado, crea insatisfacción en el cliente. Por lo que se busca es evolucionar en la calidad del trabajo con requerimientos para lograr un impacto positivo en el costo, el tiempo y la satisfacción del proyecto.

Referencias

PMI - Project Management Institute. PMI’s Pulse of the Profession: Requirements Management - A Core Competency for Project and Program Success, 2014.
C. Jones. Software Defects Origins and Removal Methods, 2012.
C. Jones, O. Bonsignour. The Economics of Software Quality. Addison-Wesley, 2012.
K. Pohl, C. Rupp. Requirements Engineering Fundamentals. Rocky Nook Computing, 2011.
D. Leffingwell. “Calculating the Return on Investment from More Effective Requirements Management”. American Programmer 10(4); 13-16; 1997.
B. Boehm & V. Basili, V. “Software Defect Reduction Top 10 List”. Computer 34(1). IEEE, 2001.
F. Brooks. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1995.

Bio

Guilherme Siqueira Simões es socio de FATTO Consultoría y Sistemas, donde actúa en consultoría y entrenamiento en medición, estimación y requisitos de software. Es graduado en Ciencias de la Computación por la UFES, posgraduado en Gestión Empresarial por el IEL/UFES, certificado como experto en Puntos de Función por IFPUG y COSMIC, Director de Proyectos (PMP) por PMI e Ingeniero de Requisitos por IREB. guilherme.simoes@fattocs.com

Los Niveles de Granularidad del Requerimiento Funcional

sg — Fri, 08 Jul 2016 17:27:01 +0000

Los Niveles de Granularidad del Requerimiento Funcional

sg Fri, 07/08/2016 - 12:27

Publicado en

SG #51

Requerimientos

Autor

Como la mayoría de los lectores de SG saben, todo software posee dos dimensiones de requerimientos: funcional y no funcional. Los requerimientos funcionales (RF) describen el comportamiento del software para proporcionar tareas y servicios a sus usuarios; estos tipos de requerimientos están relacionados a lo que el software debe hacer. Los requerimientos no funcionales (RNF) están relacionados al cómo las funcionalidades del software serán entregadas a sus usuarios y pueden incluir aspectos de calidad, técnicos, ambientales y organizacionales.

Teniendo en cuenta un sistema de cajero automático de un banco se podría suponer los siguientes ejemplos para los dos tipos de requerimientos:

RF: Consultar saldo de la cuenta corriente (el qué).
RNF: Toda transacción debe ser completada en un máximo de 30 segundos (el cómo).

Aunque no sea una regla, el RF se acostumbra manifestar de manera explícita en el software, es un comportamiento que se puede determinar claramente en qué parte del software está. El RNF, por lo contrario, se acostumbra manifestar de manera general, se aplica a todo o casi todo el software.

Para la Ingeniería de Requerimientos los dos tipos son igualmente relevantes: ambos deben ser identificados, analizados, especificados, modelados y gestionados. Sin embargo, hay algunas diferencias entre estos dos tipos de requerimientos que valen la pena comentar por separado. Este artículo se enfocará en los RF, con el objetivo de presentar sus niveles de granularidad y su importancia en el trabajo de la Ingeniería de Requerimientos.

Los niveles de granularidad

Continuando con el ejemplo del sistema de cajero automático, las siguientes descripciones podrían estar presentes en su especificación de requerimientos:

Realizar transacciones con la cuenta corriente.
Transferir una cifra de una cuenta corriente para otra cuenta corriente.
Validar la tarjeta y la contraseña del cliente.
Garantizar que la suma de todas las transacciones del cliente en el día no puede ser superior a $5,000.

Aunque estos cuatro ejemplos sean casos válidos de RF, es posible percibir que el nivel de detalle (o granularidad) entre ellos es distinto. Lo más frecuente es que una especificación presente los requerimientos en distintos niveles de granularidad.

El nivel de granularidad es la mayor o menor amplitud de la descripción del comportamiento esperado para el software en una especificación funcional. Esto está relacionado al tipo de objetivo asociado al requerimiento. La Figura 1 ilustra la relación entre estos objetivos y el nivel de granularidad, utilizando una clasificación de tres niveles (agregado, usuario, subfunción) propuesta por Cockburn (2000) para casos de uso y generalizada por los autores para requerimientos funcionales. Esta clasificación no significa que el proceso de la ingeniería de requerimientos deba utilizar una estrategia de desarrollo por descomposición funcional.

Figura 1. Niveles de granularidad.

Nivel de usuario

El requerimiento a nivel de objetivo de usuario es aquel que:

Abarca una única tarea bajo la responsabilidad de un único individuo;
Es realizado en el momento en que el usuario posee todo lo que es necesario para que la tarea sea completada hasta el límite de su responsabilidad en el flujo operativo donde está contenida.

Al final de la tarea el usuario alcanza su propósito, está satisfecho y no hay nada más que necesite hacer. Una vez que el requerimiento fue completado, todo lo que debería de realizarse para tratar un evento externo fue realizado. Esta tarea es casi siempre parte de un proceso de negocio que puede tener un flujo operativo más amplio y por esto puede aún no estar completa. Sin embargo, la perspectiva relevante en este caso no es del proceso de negocio, es de la tarea.

En general, si un trabajo involucra más de un individuo es porque hay más de una tarea presente en el contexto. Hay excepciones como un retiro en la cuenta corriente en la sucursal del banco donde dos individuos participan: la caja del banco que solicita e informa datos para el retiro y el cliente que informa la contraseña.

Esta es la granularidad del ejemplo 2 (“Transferir una cifra de una cuenta corriente para otra cuenta corriente.”). Es una única tarea (seguramente compuesta por varios pasos y reglas), bajo la responsabilidad de un único individuo que al final de todos los pasos está satisfecho con el objetivo alcanzado: una cifra fue transferida a otra cuenta corriente.

Nivel agregado

El requerimiento en este nivel agrega varios requerimientos a nivel de objetivo de usuario en una única especificación de más alto nivel. Tanto más alto sea su nivel, más generales son sus objetivos y para que un objetivo de nivel más alto sea alcanzado, otros objetivos de nivel más bajo deben ser alcanzados primero.

Este tipo de requerimiento está relacionado a objetivos más generales y su amplitud está asociada a objetivos colaborativos o asociados a procesos de negocio de alto nivel. No es relativo a una única tarea, por lo contrario, agrega un conjunto de tareas de uno o más usuarios. Esta es la granularidad del ejemplo 1 (“Realizar transacciones con la cuenta corriente.”).

¿Cuáles son las tareas asociadas a este tipo de requerimiento? Tal vez sean obvias para los lectores de la especificación (los interesados) o tal vez aún no sean conocidas. Sin embargo, es sabido que hay actividades a realizar para levantar (refinar) este requerimiento. Lo que importa es que ya está claro que este requerimiento está dentro del alcance del software a ser desarrollado.

Sin embargo, algunos RF de este tipo poseen patrones que eliminan la necesidad de proporcionar más detalles. Un ejemplo clásico son los formularios CRUD (Create, Read, Update, Delete) para que el usuario pueda mantener datos por medio del software. Es muy común que esto sea expresado como: “El sistema debe mantener productos.”. Hay un conocimiento tácito entre los interesados que el verbo “mantener” agrega las tareas del CRUD. Por lo tanto queda claro a todos los lectores que el software debe permitir al usuario realizar las siguientes tareas: agregar, modificar, eliminar y consultar datos de producto.

Nivel de subfunción

Estos requerimientos son pedazos de requerimientos con objetivo de usuario; están relacionados a un conjunto de pasos o a reglas de una o más tareas de los usuarios.

El requerimiento en nivel de subfunción que representa un conjunto de pasos describe el cambio de datos en los dos sentidos entre el usuario y el software; y entre el software y los requerimientos de almacenamiento. Este es el caso del ejemplo 3 (“Validar la tarjeta y la contraseña del cliente.”). Cada tipo de transacción que utiliza la cuenta corriente (ej.: retiro, transferencia, pago, etc.) exige el mismo conjunto de pasos descrito por el ejemplo 3, que se podría suponer como:

Verificar si la tarjeta es válida.
Verificar si la transacción elegida es compatible con el tipo de tarjeta.
Verificar si la contraseña informada es correcta.
Incrementar el control de errores de contraseña en caso que la contraseña informada sea incorrecta.
Cambiar a cero el control de errores de contraseña en caso que la contraseña informada sea correcta.

Validar la tarjeta y contraseña del cliente no es el objetivo del cliente al utilizar el sistema de cajero automático, sin embargo son pasos necesarios y intermediarios para alcanzar su objetivo: por ejemplo, hacer un retiro.

El requerimiento en el nivel de subfunción que está relacionado a reglas, en general se vincula a las leyes que gobiernan el negocio y describen de manera que complementan los procesos de negocio. También llamadas muchas veces como reglas de negocio. La regla puede describir políticas corporativas, reglamentos gubernamentales o estándares de la industria por los cuales el software debe estar subordinado.

Este es el caso del ejemplo 4 (“Garantizar que la suma de todas las transacciones del cliente en el día no puede ser superior a $5,000.”). Las reglas de negocio muchas veces son compartidas entre varios RF, hasta entre distintos productos de software en la empresa.

Importancia de la granularidad

En una visión simplificada se puede decir que hay dos momentos clave donde una especificación de requerimientos es necesaria:

A. Proporcionar una visión amplia del software (y tal vez aún no profunda).

B. Proporcionar una visión profunda del software (de una parte o del todo).

El caso A es muy común en etapas tempranas de proyectos. El objetivo en este momento es primero obtener una visión amplia del alcance, por ejemplo: para planificar el proyecto, estimar un orden de magnitud de costo o plazo, o hacer un análisis de factibilidad. Un documento de visión es un ejemplo de documento que cumple este propósito. Especificar los RF en el nivel agregado es suficiente y más adecuado a este caso. El costo para obtener información y especificar en un nivel de granularidad más bajo puede significar desperdicio de esfuerzo para detallar lo que no es necesario.

Entonces el documento de requerimientos para el propósito A, tendrá la mayoría de los RF especificados en el nivel agregado. Es posible también que haya especificaciones en el nivel de usuario o subfunción, esto no es un error. A veces puede ser interesante especificar los RF más críticos (no todos o la mayoría) en un nivel más detallado, ya sea para facilitar la comprensión del alcance por el interesado o permitir una estimación con menos incertidumbre.

El principal propósito para especificar requerimientos en niveles agregados es establecer áreas de proceso objeto de informatización y/o automatización para que las necesidades de negocio queden resueltas.

Si el objetivo de la especificación es proporcionar una visión profunda de parte o de todo el software, por ejemplo para iniciar su desarrollo, la existencia de RF en el nivel agregado puede significar que varias decisiones sobre el alcance todavía siguen pendientes. Es decir, hay trabajo de levantamiento que debe ser hecho.

Para el propósito B, el nivel de granularidad más adecuado es del objetivo del usuario pues es el único que proporciona una definición de alcance del software de manera inequívoca; no hay dudas sobre lo que es abarcado. Esto es también el único nivel de descripción de procesos que puede ser estandarizado y consecuentemente es el nivel utilizado por todos los métodos de medición de tamaño funcional adherentes a la norma ISO/IEC 14143.

Consecuentemente, para el propósito B, lo más común es que un documento de requerimientos tenga los RF especificados en su mayoría con el objetivo de usuario. RF en el nivel agregado puede estar presente sólo cuando es el caso de que esté claro a todos los interesados que tareas son abarcadas por este RF.

La definición de un requerimiento en el nivel de subfunción es adecuada cuando el comportamiento especificado es común y compartido por varias otras tareas que el software entrega a los usuarios. Esto hace con que la especificación de requerimientos sea más fácil de modificar en respuesta a cambios, pues disminuye la redundancia de información al evitar describir el mismo conjunto de pasos o reglas más de una vez. También ayuda a alcanzar una especificación más consistente.

Conclusión

Aunque el concepto de los niveles de granularidad del requerimiento funcional sea sencillo, en términos prácticos se percibe que muchos ingenieros de requerimientos no están atentos a esto cuando elaboran las especificaciones. Tener en cuenta los niveles de granularidad ayuda a definir el esfuerzo adecuado para ser dedicado a la elaboración de la especificación y también a alcanzar una especificación de requerimientos de mejor calidad.

El estándar 830 de la IEEE presenta los siguientes criterios para evaluar la calidad de una especificación de requerimientos: correcta, completa, clara (no ambigua), consistente, modificable, priorizada, verificable, trazable.

Siendo el propósito de la especificación proporcionar una visión profunda del alcance, estar atento al nivel de granularidad del RF permite que:

• Se descubra que la especificación puede no estar completa cuando hay RF agregados.

• Se proporcione la comprensión del alcance sin ninguna ambigüedad con respeto a las tareas que el software entregará cuando se enfoca el RF con objetivo de usuario.

• Se genere un documento de requerimientos más fácil de mantener y consecuentemente más consistente al especificar los RF adecuados con objetivo de subfunción.

Referencias

A. Cockburn. Writing Effective Use Cases. Addison-Wesley, 2000.
COSMIC Measurement Manual: 4.0.1. Common Software Measurement International Consortium, 2015.
IEEE Std. 830–1998: IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998.
Function Point Counting Practices Manual. Release 4.3.1. IFPUG, 2010.
C. Vazquez, G. Simões & R. Albert. Análise de Pontos de Função, Medição, Estimativas e Gerenciamento de Projetos de Software. Saraiva, 2013.
C. Vazquez, G. Simões. Engenharia de Requisitos: Software Orientado ao Negócio. Brasport, 2016.

Casos y Cosas de los Casos de Uso

lasr21 — Wed, 20 Mar 2013 23:40:23 +0000

Casos y Cosas de los Casos de Uso lasr21 Wed, 03/20/2013 - 17:40

Publicado en

SG #39

Requerimientos

Autor

Efraín Cordero

Reordenando racimos de uvas

Es común encontrar sistemas con varias decenas o incluso cientos de casos de uso. Intentar representar todos estos casos en unos pocos diagramas no es muy útil ya que debido al exceso de elementos se complica el entendimiento del alcance. Los diagramas dan la apariencia de contener racimos de uvas que amenazan derramarse de tanto peso.

Para solventar esta situación, una estrategia es establecer un criterio de subdivisión del modelo y fragmentar los diagramas saturados. El criterio normalmente proviene del negocio, y pueden ser roles, áreas de la empresa, áreas de proceso, prioridades, etc. Por ejemplo, si el criterio fuera “Roles” y como tales hubiera “Cajero”, “Contador”, etc., por cada uno de ellos se crea un paquete y en él se colocan los elementos que le correspondan. Este mecanismo facilita la comprensión del alcance, enfoca las revisiones con usuarios, permite establecer prioridades y simplifica las búsquedas de elementos.

Un hermoso martillo dorado

Un “martillo dorado” se refiere a abusar del uso de cierto recurso o herramienta, queriendo aplicarla incluso en problemas para los que no está diseñada. Veamos el siguiente caso de uso:

Caso de Uso: Generar Reporte X. Objetivo: Generar y desplegar el reporte X. Actores: Actor X. Flujo Básico:

El actor X indica al sistema que desea consultar el reporte X.
El sistema permite al actor X indicar los valores para filtrar el reporte.
El actor X proporciona los valores a usar para filtrar el reporte.
El actor X solicita al sistema que genere el reporte.
El sistema genera el reporte y lo muestra al actor X.

5.1 El sistema determina que no hay información y lo notifica al actor X.

5.2 Regresa al paso 3 del flujo básico.

¿Qué tiene de malo el caso de uso anterior? Describe la interacción completa de un usuario con el sistema, el objetivo es claro, y la secuencia de pasos parece lógica. El problema es que en casos como este, lo más importante es la información que debe contener el reporte, cómo se obtiene y se despliega, y el caso de uso no dice nada sobre esto.

El siguiente ejemplo muestra un extremo de esta situación:

Caso de Uso: Ejecutar Proceso Z Objetivo: Que el proceso Z sea ejecutado. Actores: Actor X Flujo Básico:

El actor X indica al sistema que ejecute el proceso Z.
El sistema ejecuta el proceso Z.

¿En situaciones como estas agrega algún valor tener casos de uso? Los casos de uso son útiles cuando hay gran interacción entre el actor y el sistema, pero cuando no es así o la cantidad de reglas es abrumadora (ej. procesos batch, interfaces B2B), es mejor considerar otras alternativas. Gottesdiener proporciona una lista de opciones para documentar diferentes tipos de requerimientos tales como diagramas de estado, mapas de procesos, prototipos y modelos de datos. Para situaciones donde hay una gran cantidad de reglas, la opción es extraerlas de la narrativa y colocarlas en anexos o documentos separados, dejando en la narrativa las correspondientes referencias.

A ritmo de “copy-paste”

Imaginemos un caso de uso de registro de elementos en un catálogo, que tendría un flujo básico similar al siguiente:

El actor X indica al sistema que desea registrar un elemento X.
El sistema despliega la forma de registro para un elemento X.
El actor X llena la forma de registro e indica al sistema que desea proceder con el registro.
El sistema revisa que la información proporcionada sea válida.
El sistema registra el elemento X.

Es muy posible que para todos los catálogos simples el proceso de inserción sea muy similar al descrito, por lo que el equipo seguramente tomará la decisión de usarlo como “plantilla base”. Por tanto, si el sistema comprende 50 catálogos, se generarán 49 clones donde lo único que difiere es el nombre del “elemento X”. Esto se repetirá para consulta, modificación y eliminación, por lo que se tendrán 196 narrativas creadas a partir de las 4 base, para un total de 200 elementos.

Más que cuestionar la validez del tratamiento anterior, la pregunta es ¿realmente será útil para el equipo lidiar con 200 documentos que dicen prácticamente lo mismo? ¿Y para el cliente? ¿Ese tipo de documentación realmente le sirve?

Aunque para los diagramas basta con manejar relaciones de generalización, para las narrativas la estrategia es crear un documento base y aislar en un anexo o documento separado las peculiaridades de cada elemento. De esta manera terminará teniéndose una sola narrativa.

Perdidos en el espacio

En un proyecto en el que participé algunos años, nos encontramos con que a pesar de que los desarrolladores eran buenos, estaban teniendo problemas para implementar correctamente el sistema. El problema era que los desarrolladores desconocían la operación del negocio, así que no entendían cómo los casos de uso soportaban el proceso de negocio y por lo tanto no les era obvio el orden en el que se debían realizar las interacciones indicadas en los casos de uso. A pesar de que los casos de uso manejan relaciones de inclusión y extensión, así como el manejo de precondiciones en las narrativas, éstas no son suficientes para establecer el orden de ejecución de escenarios para la consecución de flujos completos. Por ende, cuando un desarrollador trabajaba con un caso de uso, tenía que “descubrir” como funcionaba el proceso completo haciendo ingeniería inversa. Esto, además de ser propenso a errores, consumía demasiado tiempo.

Para corregir esta situación realizamos las siguientes acciones:

Brindar inducción a los nuevos integrantes del equipo en aspectos de negocio.
Documentar los flujos a través de diagramas de proceso de negocio, y registrar la rastreabilidad procesos - casos de uso.
Asignar a recursos experimentados como “coaches” de negocio.
Manejar matrices de rastreabilidad que documenten qué partes del código corresponden a qué caso de uso, para detectar elementos compartidos.
Diseñar baterías reutilizables de datos de prueba para consumo de todo el equipo.
Implementar esquemas de integración continua para detectar impactos laterales lo más rápido posible.

Rompiendo el principio de impenetrabilidad

Extrapolando el principio de impenetrabilidad de física a los casos de uso, se tendría que un caso de uso no puede establecer al mismo tiempo la funcionalidad establecida por otro. Aunque suena lógico, en mantenimiento evolutivo una situación común es que, en lugar de modificar los casos de uso preexistentes, los levantadores de requerimientos prefieren crear nuevos sin avisar que reemplazan o “complementan” otros. Esto típicamente sucede bajo dos modalidades:

Reemplazo total: Se bosqueja la funcionalidad actual y solo se describe de manera detallada lo que cambia.
Reemplazo parcial: El caso de uso solo trata de los cambios a la funcionalidad actual.

En el primer caso, los desarrolladores pueden terminar creando duplicados de funcionalidades en lugar de actualizar las existentes. En el segundo caso, el resultado es un Frankenstein de modelo donde para conocer la funcionalidad del sistema es necesario realizar un tour entre entre los casos de originales y los n casos de uso “complementarios”. Adicionalmente, se pueden dar situaciones de choque entre fragmentos de funcionalidad. Esto se vuelve verdaderamente inmanejable.

Las razones más comunes por lo que sucede lo anterior son: partir de un modelo desactualizado, desconocimiento del modelo, o simplemente pereza. Es necesario promover la actualización del modelo, capacitar a los levantadores de requerimientos en el mismo, y establecer un responsable que supervise que las actualizaciones sean congruentes y no rompan la estructura.

Conclusiones

Los casos de uso son y seguirán siendo una muy buena herramienta para documentar y comunicar requerimientos. Sin embargo, es fácil dejarse llevar por la idea de que su uso es trivial y que son adecuados para capturar todo tipo de requerimientos. Una adecuada comprensión de sus limitaciones junto al conocimiento de otras herramientas de levantamiento de requerimientos, aunado a la aplicación de estrategias simples de organización y distribución, traerá como consecuencia requerimientos mejor plasmados, más completos y más sencillos, en beneficio tanto de los equipos de desarrollo como de los usuarios finales y el resto de las áreas involucradas.

Referencias

[1] S. Ferg. “What's Wrong with Use Cases?” http://swgu.ru/sg39r2
[2] E. Gottesdiener. “Top Ten Ways Project Teams Misuse Use Cases - and How to Correct Them.” http://swgu.ru/sg39r3
[3] I. Jacobson et al, Object-Oriented Software Engineering - A Use Case Driven Approach. Addison-Wesley, 1992.

Bio

Efraín Cordero López es responsable técnico y líder de proyecto en grupo CARSO. Es licenciado en computación por la Universidad Autónoma Metropolitana y cuenta con acreditaciones como SCJP, SCWCD y Oracle SOA Implementation Champion. Es autor de cursos de diseño, pruebas unitarias y mejores prácticas de ingeniería de software.

Obtención de Requerimientos. Técnicas y Estrategia

Anonymous — Wed, 28 Nov 2007 19:58:22 +0000

Obtención de Requerimientos. Técnicas y Estrategia Anonymous Wed, 11/28/2007 - 13:58

Publicado en

SG #17

Requerimientos

Autor

César Arturo Guerra

Como sabemos, un área de conocimiento de gran importancia en el desarrollo de software, es la ingeniería de requerimientos. Esta comprende las actividades de obtención (captura, descubrimiento y adquisición), análisis (y negociación), especificación, y validación de requisitos. Además, establece una actividad de gestión de requerimientos para manejar los cambios, mantenimiento y rastreabilidad de los requerimientos.

El proceso de obtención de requisitos, cuya finalidad es llevar a la luz los requisitos, no solo es un proceso técnico, sino también un proceso social que envuelve a diferentes personas, lo que conlleva dificultades añadidas a su realización.

Técnicas Para la Obtención de Requerimientos

Existe un gran número de técnicas para obtener requerimientos. A continuación describo las más utilizadas. Hay que aclarar que ninguna de estas técnicas es suficiente por sí sola y que es recomendable combinarlas para obtener requerimientos completos.

Entrevistas

La entrevista es de gran utilidad para obtener información cualitativa como opiniones, o descripciones subjetivas de actividades. Es una técnica muy utilizada, y requiere una mayor preparación y experiencia por parte del analista. La entrevista se puede definir como un “intento sistemático de recoger información de otra persona” a través de una comunicación interpersonal que se lleva a cabo por medio de una conversación estructurada. Debe quedar claro que no basta con hacer preguntas para obtener toda la información necesaria. Es muy importante la forma en que se plantea la conversación y la relación que se establece en la entrevista.

Estos son algunos de los aspectos más importantes a tener en cuenta al realizar entrevistas:

Preparación. Es necesario documentarse e investigar la situación de la organización analizando los documentos disponibles, de tal forma que la entrevista se enfoque en aquellos aspectos que están solamente en la mente del entrevistado y que no son accesibles por otros medios como la observación o el análisis de documentos.
Entrevistar al personal adecuado. La mayoría de los analistas adoptan un enfoque top-down, comenzando a entrevistar a directivos para que brinden un panorama general de hacia donde deberían ir las cosas, y terminando por hablar con los empleados que aportan detalles importantes de la operación.
Duración. Una entrevista debería durar a lo sumo un par de horas.
Formato. Se recomienda utilizar preguntas abiertas, donde los entrevistados puedan elaborar y dar detalles, más allá de simplemente responder “si” o “no”.

Desarrollo Conjunto de Aplicaciones ( JAD )

Es una técnica que se utiliza para promover la cooperación y el trabajo en equipo entre usuarios y analistas. Consiste en realizar sesiones en las que participan usuarios expertos del dominio junto a analistas de software. La idea es aprovechar la dinámica de grupos aplicando un proceso de trabajo sistemático y organizado, apoyado por elementos visuales de comunicación y comprensión de soluciones.

Las razones que sirven de base a JAD son las siguientes:

Las entrevistas requieren mucho tiempo, no solo en prepararlas y hacerlas sino también en redactar un conjunto de requisitos coherente a partir de opiniones diferentes de los distintos entrevistados.
Es más difícil apreciar posibles errores en la especificación de requisitos, ya que sólo el analista revisa el documento. En el JAD todo el grupo puede actuar como revisor y detectar defectos.
El JAD propugna una participación más profunda de los usuarios en el proyecto, hasta tal punto que los usuarios que participan adquieren un cierto sentido de propiedad en el sistema que se construye.

El JAD no se utiliza demasiado, debido a que requiere una mayor organización que las entrevistas y porque el ambiente o los métodos de trabajo convencionales en las empresas no facilitan este tipo de actividades (falta de tiempo, dificultad de coordinación de tanta gente, dificultad para convencer a la dirección, etc.). No obstante las empresas que han implantado este método han informado de importantes ahorros de tiempo en el desarrollo de software, así como de una mayor satisfacción de los usuarios con los sistemas construidos.

Desarrollo de Prototipos

Los prototipos suelen consistir en versiones reducidas, demos o conjuntos de pantallas (que no son totalmente operativos) de la aplicación pedida. Esta técnica es particularmente útil cuando:

El área de la aplicación no está bien definida (posiblemente por ser algo muy novedoso).
El costo del rechazo de la aplicación por los usuarios es muy alto.
Es necesario evaluar previamente el impacto del sistema en los usuarios y en la organización.

Los prototipos de sistema permiten a los usuarios experimentar para ver cómo éste ayuda a su trabajo. Fomentan el desarrollo de ideas que desembocan en requerimientos. Además de permitir a los usuarios mejorar las especificaciones de requerimientos, el desarrollo de un prototipo tiene otras ventajas:

Al demostrar las funciones del sistema se identifican las discrepancias entre los desarrolladores y los usuarios.
Durante el desarrollo del prototipo, el personal del desarrollo de software puede darse cuenta de que los requerimientos son inconsistentes y/o están incompletos.
Aunque limitado, se dispone rápidamente de un sistema que funciona y demuestra la factibilidad y usabilidad de la aplicación a administrar.
El prototipo se utiliza como base para escribir la especificación para la producción.

En general, el uso de esta técnica es un medio que permite solventar objeciones del usuario del tipo: “No sé exactamente lo que quiero, pero lo sabré cuando lo vea”. Por lo general, la construcción de prototipos incrementa los costos en las etapas iniciales de un proyecto, pero esto se recupera en etapas posteriores gracias al mejor entendimiento de los requerimientos por parte de los desarrolladores. En algunos casos también se utiliza como un medio para formalizar la aceptación previa del cliente de los requisitos del proyecto.

Observación

Por medio de esta técnica el analista obtiene información de primera mano sobre la forma en que se efectúan las actividades. Este método permite observar la forma en que se llevan a cabo los procesos y, por otro, verificar que realmente se sigan todos los pasos especificados. Como sabemos, en muchos casos los procesos son una cosa en papel y otra muy diferente en la práctica. Los observadores experimentados saben qué buscar y cómo evaluar la relevancia de lo que observan.

Estudio de documentación

Varios tipos de documentación, como manuales y reportes, pueden proporcionar al analista información valiosa con respecto a las organizaciones y a sus operaciones. La documentación difícilmente refleja la forma en que realmente se desarrollan las actividades, o donde se encuentra el poder de la toma de decisiones. Sin embargo, puede ser de gran impotancia para introducir al analista al dominio de operación y el vocabulario que utiliza.

Cuestionarios

El uso de cuestionarios permite a los analistas reunir información proveniente de un grupo grande de personas. El empleo de formatos estandarizados para las preguntas puede proporcionar datos más confiables que otras técnicas; por otra parte, su amplia distribución asegura el anonimato de los encuestados, situación que puede conducir a respuestas más honestas.

El inconveniente es que la respuesta puede ser limitada, ya que es posible que no tenga mucha importancia para los encuestados llenar el cuestionario. Es recomendable conseguir apoyo de la alta dirección para solicitar a las personas de la organización que contesten el cuestionario.

Al igual que con las entrevistas, se debe seleccionar a los encuestados. El analista debe asegurar que el conocimiento y experiencia de éstos califiquen para dar respuestas a las preguntas.

Tormenta de ideas ( Brainstorming )

Consiste en reuniones con cuatro a diez personas donde como primer paso sugieren toda clase de ideas sin juzgar su validez –por muy disparatadas que parezcan–, y después de recopilar todas las ideas se realiza un análisis detallado de cada propuesta. Esta técnica se puede utilizar para identificar un primer conjunto de requisitos en aquellos casos donde no están muy claras las necesidades que hay que cubrir, o cuando se esta creando un sistema que habilitará un servicio nuevo para la organización.

ETHICS ( Implementación Efectiva de Sistemas Informáticos desde los puntos de vista Humano y Técnico )

Constituye un método bastante evolucionado para fomentar la participación de los usuarios en los proyectos. Creado por E. Mumford en 1979, coordina la perspectiva social de los sistemas con su implementación técnica. Un sistema no tiene éxito si no se ajusta a los factores sociales y organizacionales que rigen a la empresa. Se busca la satisfacción de los empleados en el trabajo a través de estudios integrales. Los requisitos técnicos del sistema serán los necesarios para mejorar la situación de los empleados (y, por lo tanto, su productividad) en función de dichos análisis.

Puntos de Vista

Cualquier sistema de software no trivial debe satisfacer las necesidades de un grupo diverso de interesados (stakeholders). Cada uno de estos puede tener intereses diferentes en el sistema de software, y por lo tanto sus necesidades pueden generar requerimientos que tengan conflicto entre sí, o incluso se contradigan.

Los métodos orientados a puntos de vista (viewpoints) toman en consideración estas perspectivas diferentes y las utilizan para estructurar y organizar tanto el proceso de obtención, como los requerimientos mismos. Uno de estos métodos es el método VORD (Definición de Requerimientos Orientado a Puntos de Vista), el cual provee un marco de trabajo orientado para la obtención y documentación de requerimientos. Las etapas principales de este método son:

Identificación de puntos de vista, que implica descubrir los que reciben los servicios del sistema e identificar los servicios específicos que se suministran a cada punto de vista.
Estructuración de puntos de vista, que comprende agrupar los relacionados en una jerarquía. Los servicios comunes se ubican en los niveles altos de la jerarquía y se heredan los puntos de vista de bajo nivel.
Documentación de puntos de vista, que comprende refinar la descripción de éstos y los servicios identificados.
Trazado del punto de vista del sistema, que comprende identificar los objetos en un diseño orientado a objetos utilizando la información del servicio encapsulado en los puntos de vista.

Escenarios

Estos se utilizan para documentar el comportamiento del sistema cuando se le presentan eventos específicos. Cada evento de interacción distinto, o la selección de un servicio del sistema, se documentan como un escenario de eventos distinto. Los escenarios de eventos incluyen una descripción del flujo de datos y las acciones del sistema, y documenta las excepciones que puedan surgir.

Las convenciones para los diagramas utilizados en los escenarios de eventos son:

Los datos proporcionados desde un punto de vista o proporcionados a éste se representan como elipses.
Las entradas y salidas de la información de control se ubican en la parte superior de cada recuadro.
Las salidas de datos se ubican a la derecha de cada recuadro. Si no están encerradas, significa que pertenecen al sistema.
Las excepciones se muestran en la parte inferior del recuadro. Si existen varias excepciones posibles, éstas se encierran en un recuadro.
El nombre del siguiente evento esperado después de completar el escenario se muestra en un recuadro sombreado.

Los Casos de Uso son una técnica que se basa en escenarios para la obtención de requerimientos. Actualmente se han convertido en una técnica fundamental que se utiliza para analizar y describir modelos de sistemas orientados a objetos. En su forma más simple, un caso de uso identifica a los actores involucrados en una interacción y nombra al tipo de ésta.

Etnografía

Los sistemas de software no existen de forma aislada; se utilizan en un contexto social y organizacional, y los requerimientos de sistemas de software se derivan y se restringen acorde a ese contexto. Satisfacer esos requerimientos sociales y organizacionales es crítico para el éxito del sistema. Una razón de por qué muchos sistemas de software se entregan pero nunca se utilizan es porque no se toma en cuenta la importancia de este tipo de requerimientos.

La etnografía es una técnica de observación que se puede utilizar para entender los requerimientos sociales y organizacionales. Un analista se sumerge por sí solo en el entorno laboral donde el sistema se utilizará. El trabajo diario se observa y se hacen notas de las tareas reales en las que los participantes están involucrados. La etnografía es especialmente efectiva para descubrir dos tipos de requerimientos:

Los requerimientos que se derivan de la forma en la que la gente trabaja realmente más que de la forma en la que las definiciones de los procesos establecen que debería trabajar.
Los requerimientos que se derivan de la cooperación y conocimiento de las actividades de la gente.

Los estudios etnográficos pueden revelar los detalles de los procesos críticos que otras técnicas de obtención de requerimientos a menudo olvidan. Sin embargo, puesto que se centran en el usuario final, este enfoque no es apropiado para descubrir los requerimientos organizacionales o del dominio. La etnografía tampoco está diseñada para identificar nuevas propiedades a agregar al sistema. Por lo tanto, la etnografía no es un enfoque completo para la obtención de requerimientos y debe utilizarse en conjunto con otras técnicas, como el análisis de casos de uso.

Estrategia para la obtención de requerimientos

Hemos descrito un número considerable de técnicas para la obtención de requerimientos. A continuación sugiero una estrategia de cómo aplicar estas técnicas dentro de un proceso ordenado y que aproveche al máximo cada técnica. Esto evitará que los analistas con poca experiencia caigamos en un error muy común, que es el de pasar demasiado pronto a las entrevistas, lo cual es un desperdicio de tiempo.

Los pasos de la estrategia sugerida son:

Aprender todo lo que se pueda de los documentos, formularios, informes y archivos existentes. Es sorprendente lo que se puede aprender de un sistema sin necesidad de quitarle tiempo a la gente.
De ser posible, se observará el sistema en acción. No se plantearán preguntas. Tan sólo se observará y se tomarán notas o dibujos. Conviene asegurarse de que las personas observadas saben que no se les está evaluando. En caso contrario, harán su trabajo de manera más eficaz que lo normal.
Diseñar y distribuir cuestionarios para aclarar cuestiones que no se comprenden bien. Será también buen momento para solicitar opiniones sobre los problemas y las limitaciones. Los cuestionarios requieren que los usuarios inviertan una parte de su tiempo. Pero son ellos los que pueden elegir cuándo les viene mejor hacerlo.
Realizar entrevistas (o sesiones de trabajo en grupo, como JAD). Como ya se ha recogido una base de requerimientos iniciales en los pasos anteriores, se pueden utilizar las entrevistas para verificar y aclarar las cuestiones y los problemas de mayor dificultad. En este punto se pueden llegar a aplicar algunas de las otras técnicas cómo Escenarios, Tormenta de ideas, Puntos de Vista, ETHICS y Desarrollo de Prototipos.
Se verifican los requerimientos a través del uso de técnicas como Entrevistas, Observación y orientados a Puntos de Vista.

Esta estrategia no es intocable. Aunque habría que desarrollar una estrategia de investigación de hechos para todas las fases pertinentes del desarrollo de sistemas, cada proyecto tiene sus propias particularidades. A veces, la observación o los cuestionarios pueden no ser apropiados. Pero debería mantenerse la idea de recabar siempre todos los hechos que sea posible antes de concertar entrevistas.

Referencias

Flaaten, P. O., McCubbrey, D.J., O´Riordan, P.D., Burgués, K., “Foundations of Business Systems”. Chicago (EE.UU.), The Dryden Pres, 1989.
Raghavan, S., Zelesnik, G., Ford, G., “Lecture Notes on Requirements Elicitation”. CMU/SEI-94-EM-10, Pittsburgh (E.E.U.U.), Software Engineering Institute (Carnegie Mellon University), 1994.
Kontonya, G. & Sommerville I., “Requirements Engineering: Processes and Techniques”. John Wiley and Sons, 2002.
Kotonya, G. y Sommerville, I. (1996). “Requirements Engineering with viewpoints”. BCS/IEE Software Engineering J.

Bio

Cesar Arturo Guerra García es profesor-investigador en el área de Tecnologías de Información de la Universidad Politécnica de San Luis Potosí. Sus áreas de interés son Ingeniería de Software, Ingeniería de Requerimientos, Modelado de sistemas y Administración de Proyectos. Ha trabajado como desarrollador y líder de proyectos en IBM y Softtek. Egresado de la Maestría en Ciencias de la Computación del Centro de Investigación Científica y de Educación Superior de Ensenada, CICESE. guerra@upslp.edu.mx

Patrones de Casos de Uso.

Anonymous — Fri, 23 Nov 2007 19:30:00 +0000

Patrones de Casos de Uso.

Anonymous Fri, 11/23/2007 - 13:30

Publicado en

SG #06

Requerimientos

Autor

Saúl Cuesta

Al desarrollar o construir algo, como por ejemplo una casa o una máquina, es muy útil apoyarse en la experiencia anterior, ya sea de uno mismo o de otros. De esta manera sabremos que la solución va a funcionar, y tendremos identificados los problemas potenciales, así como soluciones para éstos. Estas soluciones a problemas comunes se conocen como patrones, y se utilizan en diversos aspectos del desarrollo de software. Ya en un artículo anterior de SG se habló sobre patrones de diseño, específicamente del patrón Modelo-Vista-Controlador. En esta ocasión, estudiaremos la aplicación de patrones al modelado de casos de uso, y en específico abordaremos el patrón CRUD.

Contrario a lo que se pudiera pensar, un patrón de casos de uso no describe un uso particular de un sistema. Más bien, captura técnicas para que el modelo sea mantenible, reusable, y entendible. Entonces, podemos decir que los patrones de casos de uso capturan mejores prácticas para modelar casos de uso.

La aplicación de patrones de casos de uso nos trae los siguientes beneficios:
• Aumentar la productividad.
• Reutilizar elementos existentes (en este caso fragmentos de modelos).
• Evitar el retrabajo por errores.
• No invertir tiempo en resolver problemas ya resueltos.
• Aplicar la teoría al trabajo práctico.
• Habilitar las herramientas de soporte para modelar el desarrollo.

Captura y Organización de Patrones

Para capturar y organizar los patrones de caso de uso, recomiendo ampliamente generar un repositorio de patrones donde capturen al menos la siguiente información para cada patrón:

• Nombre: el nombre descriptivo del patrón.
• Intento: captura cuál es el objetivo de aplicar el patrón.
• Características: estados de los patrones, si son simples o complejos, comunes o infrecuentes.
•Palabras claves: palabras clave que caractericen al patrón para facilitar su búsqueda.
• Tipo: si el patrón afecta la estructura del modelo o la descripción de un caso de uso.
•Modelo: un modelo de caso de uso a aplicar.
•Descripción: la descripción del modelo.
•Aplicabilidad: cuándo y cómo aplicar el patrón.
•Discusión: completa discusión sobre el patrón.
•Ejemplo: un ejemplo donde uno o más de los patrones se aplica.
•Modelo de análisis: diagrama con clases de análisis que proporciona una realización de los casos de uso.

Una vez que hemos hablado sobre lo que es un patrón de caso de uso, y la forma de documentarlos, estudiemos el patrón conocido como CRUD, en sus variantes completa y parcial.

Nombre: CRUD
Intento: este patrón se utiliza en los casos donde se quiere realizar altas, bajas, cambios y consultas a alguna entidad del sistema. Su nombre es un acrónimo de las palabras en inglés Create, Read, Update, Delete. Palabras clave: Creación, altas, bajas, cambios, catálogo

Modelo 1: CRUD Completo

Descripción: el patrón CRUD Completo consiste en un caso de uso para administrar la información (CRUD Información), nos permite modelar las diferentes operaciones para administrar una entidad de información, tales como crear, leer, cambiar y dar de baja.

Aplicabilidad: este patrón deberá ser usado cuando todas las operaciones contribuyen al mismo valor de negocio y todas son cortas y simples.

Modelo 2: CRUD parcial

Descripción: alguna de las alternativas del caso de uso puede ser modelada como caso de uso independiente.
Aplicabilidad: este patrón es preferible cuando uno de los flujos alternativos del caso del uso es más significativo, muy largo, o mucho más complejo que el patrón completo.
Discusión: muy a menudo los sistemas manejan información que, del punto de vista del sistema, se crea muy fácilmente. Después de un chequeo de sintaxis, o quizás un cierto chequeo sin importancia de un cálculo o regla de negocio, la información se almacena simplemente en el sistema. No es necesario realizar cálculos, verificaciones complejas, o recuperación avanzada de datos. La descripción del flujo es pequeña, y probablemente sólo haya una o dos trayectorias alternativas de menor importancia en el flujo. Las consultas, cambios, o bajas son operaciones igualmente simples.

¿Deben tales operaciones ser modeladas como un caso de uso? ¿Y deben incluirse en el modelo del sistema completo? La respuesta a ambas preguntas es sí. Son casos de uso porque son funciones que debe ser capaz de realizar el sistema. Alguien utilizará el sistema para administrar esa información. Por otra parte, deben ser incluidos en el modelo, ya que de otra manera estará incompleto. Y esto puede provocar que el proyecto no se lleve a cabo adecuadamente.

Afortunadamente, esto no significa que necesariamente cada operación se debe expresar como casos de usos separados. Según el patrón CRUD, los podemos agrupar. Este procedimiento tiene algunas ventajas obvias. Primero, el tamaño del modelo será reducido, hará más fácil de entender el modelo porque tiene menos casos. En segundo lugar, nadie estará interesado en un sistema que contiene solamente un subconjunto de estos casos de uso, ya que no generan el valor completo (por ejemplo, leer y dar de baja, pero no crear y cambiar). Agrupar estos flujos juntos en un caso como Administrar X se asegura de que las cuatro operaciones estarán incluidas en el modelo, y lo hace claro para el lector del modelo. Tercero, el valor de cada uno de los flujos por separado es muy pequeño, y podríamos estar cayendo en descomposición funcional; es la colección entera de estas operaciones la que da valor a los interesados.

Las cuatros operaciones no deben ser modeladas como caso de uso independientes.

La variación denominada CRUD: Parcial, indica que en caso de que solo algunas de las cuatro operaciones sean simples mientras que otras son complejas, se puede agrupar las operaciones simples en un caso de uso y dejar las otras modeladas como un caso de uso separado.

Observar también que esto es una situación típica donde un caso de uso no tiene solamente un flujo “básico”. Ninguno de los flujos se puede decir que es más “básico” o “normal” que los otros. Por lo tanto, un caso de uso CRUD tendrá típicamente cuatro flujos básicos, y posiblemente algunos flujos alternativos, como se demuestra en el ejemplo 1.

Una instancia de un caso de uso podrá realizar una de las siguientes operaciones (crear, leer, cambiar y dar de baja), y después dejar de existir. Esta misma instancia del caso de uso no continuará viviendo y esperando la operación siguiente que se realizará. Esta operación debe ser realizada por otra instancia del mismo caso de uso.

Como regla general, cuando no estamos seguros si combinar los diversos casos de usos en uno o crearlos como separados, la recomendación es mantenerlos como uno solo y después cuando se vea el tamaño y complejidad del caso de uso, se deberá tomar la decisión de separarlos si es necesario.

A continuación mostramos un ejemplo de un boceto de caso de uso utilizando el patrón CRUD. Por razones de espacio, no está completo. El objetivo es ejemplificar la aplicación del patrón.

Caso de Uso: Administrar Tarea

Este caso de uso permite registrar, listar, modificar, o eliminar la información de tareas realizadas.

Flujo Básico
El caso de uso tiene cuatro diversos flujos básicos:
Registrar tarea nueva
Modificar una tarea existente
Cancelar tarea
Consultar tarea fallida

Registrar tarea nueva
El caso de uso comienza cuando el usuario elige registrar una nueva tarea.
El sistema presenta una lista de posibles clases de tareas, y pregunta qué clase de tarea debe ser registrada, con qué nombre, y cuando se debe realizar.
El usuario provee la información requerida.
El sistema comprueba que el tiempo especificado es en el futuro y que el nombre de la tarea es único.
El sistema registra la nueva tarea y la marca como activa.
El caso de uso termina.

Modificar tarea
El caso de uso comienza cuando el usuario elige modificar una tarea ya registrada.
El sistema recupera los nombres de todas las tareas no marcadas como activo y las presenta al usuario. El usuario selecciona una de las tareas.
El sistema recupera la información sobre la tarea y la presenta al usuario.
El usuario modifica cualquiera de la información actual excepto el nombre de la tarea.
El usuario acepta la información.
El sistema comprueba si el tiempo especificado es en el futuro y almacena la información modificada.
El caso de caso de uso termina.

Cancelar tarea
El caso de uso comienza cuando el usuario elige cancelar una tarea.
El sistema recupera y despliega todas las tareas futuras.
El usuario selecciona una de las tareas.
El sistema recupera la información sobre la tarea y la presenta al usuario.
El usuario confirma la cancelación, el sistema elimina la tarea; si no se puede, no se hace ninguna modificación.
El caso de uso termina.

Consultar tarea fallida
El caso de uso comienza cuando el usuario elige vista de la lista de todas las tareas que han fallado.
El sistema recoge todas las tareas con el estado fallado y presenta sus nombres al usuario.
El caso de uso termina.

Flujos alternativos
Cancelar la operación
Nombre o Tiempo incorrecto

Otros Patrones de Caso de Uso

Existen varios patrones adicionales al CRUD que son utilizados para modelar sistemas. Esta es una lista de los más importantes:

• Reglas de negocio

• CRUD

• Login

• Reportes y Explotación de información

• Inclusión y Extensión

Conclusión

La técnica de casos de uso nos permite modelar y especificar los requerimientos de nuestro sistema. Tiene muchos beneficios, entre los más importantes: primero nos permite planear nuestro proyecto y segundo ayuda a llegar a acuerdos con los usuarios, para que los casos de uso sean mas claros y mantenibles es importante encontrar patrones y documentarlos, de esta manera cuando nos encontremos con un problema igual o parecido podamos resolverlos en menor tiempo. El concepto de patrones no es algo que solo es aplicable a la práctica de requerimientos. De hecho, la disciplina de requerimientos copia este concepto de la de análisis y diseño. Lo que se busca con los patrones es reutilizar lo aprendido en los nuevos proyectos y usarlos en la organización como estándares.

Referencias
• Pan-Wei Ng, Understanding types of use cases and artifacts. IBM Developerworks.
www-128.ibm.com/developerworks/rational/library/1809.html

Bio

Saúl Cuesta Rodríguez es consultor de ITERA especializado en las prácticas de requerimientos y modelado de negocios. Es graduado de la Universidad Tecnológica de Panamá como Ing. en Sistemas.

Requerimientos

La Importancia de la Ingeniería de Requerimientos

Publicado en

Autor

Fallos famosos

La sonda espacial Mars Climate Orbiter (MCO)

Misil antibalístico Patriot

Cohete Ariane 501

Archivo Virtual FBI

El principal motivo de fracaso

Una de las principales causas de defectos

El costo de reparación de los defectos

Tags

Los Niveles de Granularidad del Requerimiento Funcional

Publicado en

Autor

Los niveles de granularidad

Nivel de usuario

Nivel agregado

Nivel de subfunción

Importancia de la granularidad

Conclusión

Casos y Cosas de los Casos de Uso

Publicado en

Autor

Reordenando racimos de uvas

Un hermoso martillo dorado

A ritmo de “copy-paste”

Perdidos en el espacio

Rompiendo el principio de impenetrabilidad

Conclusiones

Referencias

Obtención de Requerimientos. Técnicas y Estrategia

Publicado en

Autor

Técnicas Para la Obtención de Requerimientos

Entrevistas

Desarrollo Conjunto de Aplicaciones ( JAD )

Desarrollo de Prototipos

Observación

Estudio de documentación

Cuestionarios

Tormenta de ideas ( Brainstorming )

ETHICS ( Implementación Efectiva de Sistemas Informáticos desde los puntos de vista Humano y Técnico )

Puntos de Vista

Escenarios

Etnografía

Estrategia para la obtención de requerimientos

Patrones de Casos de Uso.

Publicado en

Autor

Captura y Organización de Patrones

Caso de Uso: Administrar Tarea

Otros Patrones de Caso de Uso

Conclusión