DOCUMENTACIÓN DE CASOS DE USO - …pegasus.javeriana.edu.co/~CIS1410IS08/Final/Anexo 2. Documento...
Transcript of DOCUMENTACIÓN DE CASOS DE USO - …pegasus.javeriana.edu.co/~CIS1410IS08/Final/Anexo 2. Documento...
DOCUMENTACIÓN DE CASOS DE USO
HERRAMIENTA PARA LA ADMINISTRACIÓN DE REQUERIMIENTOS DE LOS PROYECTOS DE LAS ASIGNATURAS DE INGENIERÍA Y ARQUITECTURA
DE SOFTWARE DE LA PONTIFICIA UNIVERSIDAD JAVERIANA.
CARLOS DAVID DUARTE ALFONSO
PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C
2014
Documentación de casos de uso
2
Historial De Cambios
El historial de cambios es una tabla que muestra la evolución y seguimiento del documento, todos los cambios realizados permiten elaborar, corregir y controlar la calidad del documento por parte del autor.
Versión Fecha Sección del documento
modificada Descripción de
cambios Responsable
V 0.1.0 22/02/2014 Línea base documento de casos de uso
Estructura general del documento
Carlos Duarte
V 0.1.0
25/02/2014
Definición plantilla de documentación casos de uso
Carlos Duarte
V 0.2.0
25/02/2014
Capítulo 1 y 2
Elaboración de la introducción y lista de casos de uso.
Carlos Duarte
V 0.3.0 26/02/2014 Capítulo 5 Documentación de casos de uso.
Carlos Duarte
V 0.3.1 26/02/2014 Capítulo 5.1 Documentación de casos de uso administración de requerimientos.
Carlos Duarte
V 0.3.2. 26/02/2014 Capítulo 5.2 Documentación de casos de uso gestión de riesgos.
Carlos Duarte
V 0.4.0 27/02/2014 Capítulo 3 Elaboración del análisis de los actores
Carlos Duarte
V 0.5.0 27/02/2014 Capítulo 4 Diagrama de casos de uso.
Carlos Duarte
V 0.5.1 09/03/2014 Capítulo 1 y 2 Corrección de estos dos capítulos.
Carlos Duarte
V 0.6.0 13/03/2014 Capítulo 5 Corrección casos de uso Carlos Duarte
V 0.6.1 15/03/2014 Capítulo 3 Corrección actores Carlos Duarte
V 1.0.0 29/03/2014 Documento en general Entrega Carlos Duarte Tabla 1 Historial de Cambios
Documentación de casos de uso
3
Tabla de Contenido
Historial De Cambios .............................................................................................................................. 2
Lista de tablas ........................................................................................................................................... 4
1. Introducción ...................................................................................................................................... 5
2. Listas de casos de uso ................................................................................................................... 6
2.1. Casos de uso administración de requerimientos ........................................................... 6
2.2. Casos de uso gestión de riegos en los requerimientos ................................................ 9
3. Actores .............................................................................................................................................. 10
4. Diagrama casos de uso ................................................................................................................ 11
5. Documentación casos de uso .................................................................................................... 12
5.1. Documentación casos de uso de administración de requerimientos ..................... 12
5.1.1. Proceso caso de uso Crear línea base de requerimientos ................................. 12
5.1.2. Documentación caso de uso Crear línea base de requerimientos ................... 13
5.1.3. Proceso caso de uso Crear control de versiones de los requerimientos....... 14
5.1.4. Documentación caso de uso Crear control de versiones de los
requerimientos ................................................................................................................................ 15
5.1.5. Proceso caso de uso Asociar problema a un requerimiento ............................. 16
5.1.6. Documentación caso de uso Asociar problema a un requerimiento ............... 16
5.1.7. Proceso caso de uso Editar problema a un requerimiento ................................ 18
5.1.8. Documentación caso de uso Editar problema a un requerimiento .................. 18
5.1.9. Proceso caso de uso Eliminar problema a un requerimiento ............................ 20
5.1.10. Documentación caso de uso Eliminar problema a un requerimiento .......... 20
5.1.11. Proceso caso de uso Generar reporte de los problemas en los
requerimientos ................................................................................................................................ 22
5.1.13. Proceso caso de uso Generar matriz de trazabilidad ...................................... 23
5.2. Documentación casos de uso gestión de riesgos ........................................................ 25
5.2.1. Documentación casos de uso identificación de riesgos .................................... 25
5.2.2. Documentación casos de uso técnicas de mitigación ........................................ 26
6. Referencias ...................................................................................................................................... 27
Documentación de casos de uso
4
Lista de tablas
Tabla 1 Historial de Cambios ..................................................................................................... 2
Tabla 2 Funcionalidades ............................................................................................................ 6
Tabla 3 Lista casos de uso Administración ................................................................................ 8
Tabla 4 Lista casos de uso Gestión de Riesgos ........................................................................10
Tabla 5 Análisis actor Gerente ..................................................................................................10
Tabla 6 Análisis de Actor Arquitecto ..........................................................................................11
Tabla 7 Análisis de Actor Desarrollador ....................................................................................11
Tabla 8 Caso de uso Crear línea base de requerimientos .........................................................14
Tabla 9 Caso de uso Crear control de versiones a los requerimientos ......................................15
Tabla 10 Caso de uso Crear control de cambios ......................... Error! Bookmark not defined.
Tabla 11 Caso de uso Asignar problema a un requerimiento ....................................................18
Tabla 12 Caso de uso Editar problema a un requerimiento .......................................................19
Tabla 13 Caso de uso Eliminar problema a un requerimiento ...................................................21
Tabla 14 Caso de uso Generar reporte de los problemas en los requerimientos ......................23
Tabla 15 Caso de uso Generar matriz de trazabilidad...............................................................25
Documentación de casos de uso
5
1. Introducción
El presente documento, tiene como objetivo definir, priorizar y documentar los nuevos casos de uso que tiene la herramienta ERMT [4] para esta nueva versión del producto, para lo cual, se define el nombre de esta nueva iteración como “ERMT 2.0”, y “ERMT 1.0” al producto que ya existía, con el fin de diferenciarlos y simplificar la ambigüedad. Para esta nueva versión de ERMT 2.0, se estableció la incorporación de nuevas funcionalidades con base a las actividades de la administración de requerimientos y gestión de riesgos de los mismos. En este documento también se lleva a cabo una comparación de los casos de uso que ya existían previamente en ERMT 1.0, frente la incorporación que tiene ERMT 2.0.
Documentación de casos de uso
6
2. Listas de casos de uso
En este capítulo se muestran los casos de uso que permiten a ERMT 2.0 administrar los requerimientos y gestionar los riesgos de los mismos. Para tener más claridad acerca de los casos de uso que van a permitir estas dos grandes funcionalidades, es necesario explicar el objetivo y las actividades que tienen estos dos procesos, para lo cual es explica en detalle cada uno de estos.
A continuación se muestra una tabla donde se puede ver las funcionalidades existentes frente a las nuevas, para cual se establece ERMT 1.0 como la herramienta que ya existe y ERMT 2.0 como la continuación de esta:
ERMT 1.0 ERMT 2.0
Almacenamiento y Consulta de requerimientos
Línea base de requerimientos
Generación de reportes en Excel Control del conjunto de las versiones de los requerimientos.
Generación de grafos de implementación
Proceso de control de cambios
Generación de reportes del estado de cada requerimientos y del estado del proyecto en general
Seguimiento de los problemas en los requerimientos
Importación de archivos csv Matriz de trazabilidad de requerimientos
Priorización de requerimientos Identificación de riesgos
Localización de archivos mediante la trazabilidad
Técnicas de mitigación de riesgos
Relación entre requerimientos
Definición de tipos de requerimientos
Listas de validación y verificación Tabla 2 Funcionalidades
2.1. Casos de uso administración de requerimientos
El objetivo de la administración de requerimientos es de prever y adaptarse a los cambios reales que siempre se puede esperar con el fin de minimizar su impacto perjudicial en el proyecto. La administración de requerimientos incluye todas las actividades que mantienen la integridad, exactitud y actualización de los acuerdos en los requerimientos a lo largo del proyecto. Las actividades básicas de la administración de requerimientos están en cuatro categorías principales [3]:
Control de versiones
Definición de un esquema de identificación de la versión.
Seguimiento individual a las versiones de requerimientos.
Documentación de casos de uso
7
Seguimiento al conjunto de versiones de requerimientos.
Control de cambios
Proponer cambios.
Análisis del impacto.
Toma de decisiones.
Actualización de los requerimientos individuales.
Actualización del conjunto de requerimientos.
Actualización de los planes.
Medición de la volatilidad de los requerimientos.
Seguimiento del estado de los requerimientos
Definir posibles estados de los requerimientos.
Llevar un registro de cada requerimiento.
El seguimiento de la distribución del estado de todos los requerimientos.
Trazabilidad de requerimientos
Definir enlaces a otros requerimientos.
Definir enlaces a otros elementos.
Buenas prácticas de ingeniería de requerimientos [3] [5] [10] Gestión de requerimientos Establecer un proceso de control de cambios: El proceso de cambios debe definir cómo se proponen los cambios de requerimientos, para luego analizarlos y resolverlos. Administrar todos los cambios propuestos a través de este proceso. Realizar un análisis de los efectos del cambio: Evaluar cada cambio de los requisitos propuestos para evaluar el efecto que tendrá en el proyecto. Utilizar una matriz de trazabilidad para identificar los demás requerimientos, elementos de diseño, código fuente y las pruebas que podría necesitar modificar. Identificar las tareas necesarias para implementar el cambio y estimar el esfuerzo necesario para llevar a cabo estas tareas. Establecer una línea base y control de versiones para el conjunto de requerimientos: Una línea base define un conjunto de requerimientos acordados normalmente para un lanzamiento o iteración especifica. Después de definir una línea base de requerimientos, los cambios deben hacerse solo a través del proceso de control de cambios del proyecto. Dar a cada versión de la especificación de requerimientos un identificador único para evitar confusión entre los proyectos y líneas base y entre las versiones anteriores y actuales. Mantener un historial de cambios: Conservar un historial de los cambios realizados a cada requerimiento individual. A veces es necesario volver a una versión anterior de un requerimiento o quiere saber cómo el requerimiento llegó a estar en su forma actual. Es importante anotar las fechas las fechas en que se modificaron los requerimientos, los cambios que se hicieron, quien realizó el cambio, y por qué.
Documentación de casos de uso
8
Seguimiento del estado de los requerimientos: Crear un repositorio con un registro para cada requerimiento de cualquier tipo que afecte a la ejecución. Guardar los atributos clave sobre cada requerimiento, incluyendo su estado (propuesto, aprobado, implementado o verificado), para que se pueda supervisar el número de requerimientos de cada categoría de estado en cualquier momento. El seguimiento del estado de cada requerimiento proporciona información sobre el estado general del proyecto debido a que se mueve a través del desarrollo y las pruebas del sistema. Seguimiento de los problemas en los requerimientos: Supervisar el estado de los problemas en los requerimientos para determinar el estado general de los requerimientos. Mantener una matriz de trazabilidad de requerimientos: Una matriz de trazabilidad de requerimientos es útil para confirmar que todos los requerimientos se aplican y se verifican. También es útil durante el mantenimiento, cuando un requerimiento tiene que ser modificado. La matriz de trazabilidad de requerimientos también puede conectarse a requerimientos funcionales con requerimientos de nivel superior a partir de los cuales se derivaron y para otros requerimientos relacionados. [3] Usar una herramienta de gestión de requerimientos: Las herramientas de gestión de requerimientos comerciales permiten almacenar diferentes tipos de requerimientos en una base de datos. Tales herramientas ayudan a implementar y automatizar muchas de las prácticas de la gestión de requerimientos. [7]
Luego de poner en contexto que objetivo, actividades y las buenas prácticas que debe tener la administración de requerimientos, se propuso crear por lo menos un caso de uso, para cada categoría ya mencionada, con el objetivo de abarcar en una mayor medida este proceso y se cumplan los objetivos específicos del proyecto. Ver documento SPMP
En la siguiente tabla se muestran los casos de uso correspondientes a la administración de requerimientos con su respectivo identificador único. [3]
ID CASO DE USO CASO DE USO
CU 001 Crear línea base de requerimientos
CU 002 Crear control de versiones a los requerimientos
CU 003 Crear control de cambios
CU 004 Asignar problema a un requerimiento
CU 005 Editar problema a un requerimiento
CU 006 Eliminar problema a un requerimiento
CU 007 Generar reporte de los problemas en los requerimientos
CU 008 Crear matriz de trazabilidad Tabla 3 Lista casos de uso Administración
Documentación de casos de uso
9
2.2. Casos de uso gestión de riegos en los requerimientos
La gestión del riesgo consiste en la aplicación de herramientas y procedimientos para contener los riesgos del proyecto dentro de los límites aceptables. Proporciona un enfoque estándar para identificar los factores de riesgo y de documentos, evaluar su gravedad potencial, y proponer estrategias para la mitigación de los mismos. [3] La preparación para la gestión de riesgos en los requerimientos implica dos pasos principales [11] [12]:
Identificar los tipos de riesgos: La idea de gestión de los riesgos en los requerimientos no es nueva, pero los modelos tradicionales se han convertido en demasiados simplistas. Investigaciones recientes sugieren que los proyectos de TI de hoy en día, se enfrentan a tres tipos distintos de riesgos en los requerimientos [11]:
Identidad: Los riesgos de identidad son aquellos que a menudo conducen a considerables brechas de comunicación entre los desarrolladores y los usuarios, además la distancia física, conceptual y cultural que hay entre los implicados. Un alto riesgo en esta área se produce cuando no se sabe o no se puede identificar requerimientos clave. [11]
Volatilidad: Durante la mayoría de proyectos de TI, los requerimientos cambian como: las partes interesadas a aprender más acerca de la solución o condiciones internas o externas para el cambio de uso del sistema de TI. Riesgos de volatilidad son expresiones que indican la estabilidad del requerimiento. Los riesgos altos indican que los requerimientos pueden cambiar fácilmente. [11]
Complejidad: Los riesgos de complejidad, reflejan cómo se conceptualizan y se estructuran los requerimientos, los riesgos altos indican que es difícil de entender, especificar y comunicar los requerimientos. [11]
Técnicas de mitigación de los riesgos: La segunda etapa de preparación es la de organizar una caja de herramientas adecuadas para la resolución de los riesgos. Algunas técnicas de mitigación ya se definieron para el proyecto, pero hay que evaluar qué tan bien se aplican a los diferentes tipos de riesgo. Por lo cual se han categorizado técnicas disponibles de acuerdo al propósito del proyecto. [11]
Descubrimiento: Estas técnicas centradas en el cliente ayudan a identificar o predecir las necesidades del cliente, haciendo hincapié en la identificación y la comprensión inicial de las necesidades, incluyendo aquellas que son esenciales a los usuarios. [11]
Priorización: Esta técnica permite establecer que requerimientos tienen un mayor riesgo de no poder ser desarrollados o cuales son más críticos para satisfacer las necesidades de los usuarios. [11]
Experimentación: Esta técnica permite en ayudar a evaluar y estabilizar los requerimientos a través de la experimentación y la retroalimentación del usuario final. La idea básica es construir un prototipo, registrar los comentarios, e iterativamente mejorar
Documentación de casos de uso
10
la solución hasta que se ha alcanzado un nivel satisfactorio de aceptación del usuario. [11]
Especificación: Esta técnica se basa en la abstracción de los requerimientos mediante
texto o representación gráfica (modelo entidad – relación, diagrama casos de uso, entre otros). [11]
En la siguiente tabla se muestran los casos de uso correspondientes a la gestión de riegos en los requerimientos con su respectivo identificador único. [3]
ID CASO DE USO CASO DE USO
CU 009 Identificar tipo de riesgo
CU 010 Generar técnica de mitigación Tabla 4 Lista casos de uso Gestión de Riesgos
3. Actores
Este capítulo se realiza un análisis de los actores que interactúan directamente con la aplicación, para lo cual se hace una descripción, motivación del modelado, propósito del uso en la herramienta y casos de uso asociados. En ERMT 1.0, se especificaron dos actores, los cuales eran “estudiante” y “profesor” [4], para esta nueva versión se estableció que solo estuviera el actor estudiante, ya que el profesor no interactuaba directamente con la herramienta. El actor “estudiante” se decidió dividirlo en “Arquitecto”, “Desarrollador” y “Gerente”, debido a que en las materias de ingeniería y arquitectura de software de la pontificia universidad javeriana, existen estos roles dentro del proyecto que se realiza a lo largo del semestre y son los que directamente interactúan con la herramienta. A continuación se explica en detalle cada actor:
Nombre del Actor Gerente
Descripción Este actor es el encargado de planear y ejecutar de manera correcta el proyecto software a lo largo del semestre.
Motivación del modelado El gerente representa la interacción del usuario con la aplicación. Ya que debe evaluar, prever y controlar los riegos que existan en los requerimientos del proyecto.
Propósito del uso en la herramienta
El objetivo principal del gerente es de identificar los riegos que pueda tener el proyecto y como puede asumirlos o reducir su impacto en el proyecto.
Casos de uso asociados CU 007, CU 009, CU 010. Tabla 5 Análisis actor Gerente
Nombre del Actor Arquitecto
Documentación de casos de uso
11
Descripción Este actor es quien crea, analiza y diseña la arquitectura que soporte y solucione los requerimientos asociados al proyecto se software.
Motivación del modelado El arquitecto representa la interacción del usuario con la aplicación. Por lo que es de vital importancia su modelado, ya que esto permite saber cómo interactúa de forma detallada con los casos de uso que surgen de este.
Propósito del uso en la herramienta
El objetivo principal del arquitecto es identificar las diferentes relaciones que tienen los requerimientos con otros elementos del sistema.
Casos de uso asociados CU 004, CU 005, CU 006, CU 008. Tabla 6 Análisis de Actor Arquitecto
Nombre del Actor Desarrollador
Descripción Este actor es el encargado de construir un software eficiente y la medida, el cual cumpla con todos los requerimientos del cliente en el tiempo acordado.
Motivación del modelado El desarrollador representa la interacción del usuario con la aplicación.
Propósito del uso en la herramienta
El objetivo principal del desarrollador es identificar el estado y los problemas asociados a los requerimientos, para minimizar el riesgo de fracaso en el proyecto.
Casos de uso asociados CU 001, CU 002, CU 003. Tabla 7 Análisis de Actor Desarrollador
4. Diagrama casos de uso
En este capítulo está el diagrama de casos de uso, el cual muestra la interacción de los actores con la aplicación y sus correspondientes casos de uso. Es importante resaltar que para ERMT 2.0 se van a utilizar algunos casos de uso que ya existen en ERMT 1.0, con el fin de no volver a reescribir funcionalidades que ya tiene la aplicación. A continuación se muestra el diagrama de casos de uso de ERMT 2.0, los cuales se representan con el color azul. Los casos de usos de color rojo son lo que existen en ERMT 1.0, los cuales van a ser usados para esta nueva versión.
Documentación de casos de uso
12
Figura 1 Diagrama Casos de uso
Para visualizar en mayor resolución el diagrama de casos de uso ver diagrama casos de uso.
5. Documentación casos de uso
En este capítulo se explica en detalle cada uno de los casos de uso listados en el capítulo dos. A continuación se presenta la correspondiente documentación de cada caso de uso ya mencionado y la debida justificación del proceso para cada uno de estos. Cada casa de uso es documentado con base a la plantilla de “Cockburn”. [1]
5.1. Documentación casos de uso de administración de requerimientos
5.1.1. Proceso caso de uso Crear línea base de requerimientos
Una línea base define un conjunto de requerimientos acordados normalmente para un lanzamiento o iteración especifica. Es necesario dar a cada versión de la especificación de requerimientos un identificador único para evitar confusión entre los proyectos y líneas base y entre las versiones anteriores y actuales. [6]
Documentación de casos de uso
13
5.1.2. Documentación caso de uso Crear línea base de requerimientos
Id Caso de Uso CU 001 Nombre Crear línea base de requerimientos
Proyecto ERMT 2.0 Fecha 25/02/2014
Autor Carlos Duarte Versión 1.0
Prioridad Alta
Objetivo en contexto Este caso de uso permite al actor crear una línea base de requerimientos funcionales y no funcionales.
Actores Principales Desarrollador
Entradas Conjunto de requerimientos, nombre, versión y observación.
Salidas Mensaje de éxito de la creación de línea base de requerimientos.
Pre-Condiciones
Post-Condiciones Condición final de éxito La línea base es creada.
Condición final de fallo La línea base no pudo ser creada.
Flujo básico de éxito
No. Actor No. Sistema
1
Este caso de uso comienza cuando el desarrollador elige la opción de crear línea base de requerimientos.
2 El desarrollador previamente selecciona un conjunto de requerimientos que desea ser la línea base.
3 El desarrollador define el nombre de la línea base.
4 El desarrollador define el correspondiente número de
Documentación de casos de uso
14
versionamiento. (Puede ser antes de cada iteración o entrega)
5 La aplicación despliega el formulario, el cual contiene el nombre del proyecto (Ya viene predefinido), la versión y una observación.
6 El actor llena los campos del formulario, eligiendo la versión de los requerimientos que desee y la observación de la correspondiente versión.
7 La aplicación almacena la línea base de requerimientos con la respectiva información suministrada por el desarrollador y la fecha de creación.
8 La aplicación muestra el mensaje de éxito de creación.
Variaciones (Caminos de excepción)
1.0.E.7 La aplicación envía un mensaje de error al desarrollador.
1. El desarrollador recibe el mensaje de error por parte de la aplicación, indicando que el nombre de la línea base ya existe.
2. El desarrollador vuelve al paso 6.
Extensiones CU 002, CU 003, CU020. Tabla 8 Caso de uso Crear línea base de requerimientos
5.1.3. Proceso caso de uso Crear control de versiones de los requerimientos
El control de versiones comienza cuando se elabora un requerimiento o un documento para conservar un historial de los cambios realizados. Cada versión de los requerimientos debe ser identificada. Los cambios deben estar claramente documentados y comunicados a todos los afectados. Asegurar de que el identificador de versión cambia cada vez que se hace una actualización. Cada versión de un documento de requerimientos o cada requerimiento en una herramienta debe incluir un historial de revisiones que identifica los cambios realizados, la fecha de cada cambio, la persona que hizo el cambio y el motivo de cada cambio. [3]
Documentación de casos de uso
15
5.1.4. Documentación caso de uso Crear control de versiones de los requerimientos
Id Caso de Uso CU 002 Nombre Crear control de versiones a los requerimientos
Proyecto ERMT 2.0 Fecha 25/02/2014
Autor Carlos Duarte Versión 1.0
Prioridad Alta
Objetivo en contexto Este caso de uso permite al actor crear un control de versiones para los requerimientos funcionales y no funcionales.
Actores Principales Arquitecto
Entradas Ninguna
Salidas Mensaje de éxito de la creación del control de versiones.
Pre-Condiciones Debe existir por lo menos un requerimiento funcional o no funcional creado con anterioridad.
Post-Condiciones Condición final de éxito
Condición final de fallo
Flujo básico de éxito
No. Actor No. Sistema
1
Este caso de uso comienza cuando el arquitecto selecciona la opción de control de versiones.
2 El arquitecto selecciona un conjunto de requerimientos.
3 El arquitecto define el nombre que identifica el conjunto de requerimientos seleccionados.
4 El arquitecto define el versionamiento y una observación correspondiente al conjunto de requerimientos.
5 La aplicación valida que los requerimientos no estén repetidos.
6 La aplicación almacena el conjunto de requerimientos con la respectiva información suministrada por el desarrollador y la fecha de creación.
Variaciones (Caminos de excepción)
2.0.E.5 La aplicación envía un mensaje de error al arquitecto.
1. El arquitecto recibe el mensaje de error por parte de la aplicación, indicando que un requerimiento esta repetido.
2. El arquitecto vuelve al paso 1.
Extensiones CU 001 Tabla 9 Caso de uso Crear control de versiones a los requerimientos
Documentación de casos de uso
16
5.1.5. Proceso caso de uso Asociar problema a un requerimiento
El análisis de los problemas en los requerimientos, es el proceso de comprensión de los problemas del mundo real y las necesidades del usuario y proponer soluciones para satisfacer esas necesidades.
El objetivo del análisis del problema en los requerimientos es obtener una mejor comprensión del problema para ser resuelto, antes de que comience el desarrollo.
Identificar la causa raíz, o el problema detrás del problema.
Identificación de los actores en el sistema es un paso clave en el análisis de problemas en los requerimientos. [5]
Addison Wesley en su libro “Managing Software Requirements” [5] propone un formato para llevar un registro de los problemas en los requerimientos, el cual consiste en describir el problema, especificar los stakeholders que se ven afectados por el problema, la posible solución a ese problema y como se solucionó ese problema. Con base a este formato, los casos de uso 4, 5, 6 y 7 se basan en este.
5.1.6. Documentación caso de uso Asociar problema a un requerimiento
Id Caso de Uso CU 004 Nombre Asignar problema a un requerimiento
Proyecto ERMT 2.0 Fecha 17/03/2014
Autor Carlos Duarte Versión 1.0
Prioridad Media
Documentación de casos de uso
17
Objetivo en contexto Este caso de uso permite al arquitecto asignar un problema a un requerimiento específico.
Actores Principales Arquitecto
Entradas El arquitecto debe haber abierto un proyecto previamente.
Salidas Ninguna
Pre-Condiciones Debe existir por lo menos un requerimiento creado en el proyecto.
Post-Condiciones Condición final de éxito El problema se asignó a un requerimiento.
Condición final de fallo El problema no se asignó a un requerimiento.
Flujo básico de éxito
No. Actor No. Sistema
1 El arquitecto selecciona la opción “Problemas en los requerimientos”.
2
Este caso de uso comienza, cuando el arquitecto selecciona la opción “Asignar problema a un requerimiento”.
3 La aplicación muestra una ventana al arquitecto, donde le muestra la lista de requerimientos asociados al proyecto.
4 El arquitecto selecciona un requerimiento asociado al proyecto.
5 La aplicación muestra en la misma ventana, un formulario donde le indica al arquitecto los siguientes campos que debe llenar:
Descripción del problema.
Stakeholders afectados por el problema.
Posible solución.
6 El arquitecto debe llenar todos los campos ya mencionados y guardar los cambios.
7 La plataforma almacena la información del problema en la base de datos y le asigna la fecha en que se realizó la asignación.
8 La plataforma muestra por pantalla un mensaje de éxito de la operación.
Variaciones (Caminos de excepción)
5.0.E.3 La aplicación envía un mensaje de error al arquitecto.
Documentación de casos de uso
18
1. La aplicación muestra por pantalla un mensaje de error al arquitecto, indicando que el requerimiento escogido ya tiene asignado un problema.
2. El arquitecto regresa al paso 4.
Extensiones No aplica Tabla 10 Caso de uso Asignar problema a un requerimiento
5.1.7. Proceso caso de uso Editar problema a un requerimiento
5.1.8. Documentación caso de uso Editar problema a un requerimiento
Id Caso de Uso CU 005 Nombre Editar problema a un requerimiento
Proyecto ERMT 2.0 Fecha 17/03/2014
Autor Carlos Duarte Versión 1.0
Prioridad Media
Objetivo en contexto Este caso de uso permite al arquitecto editar un problema a un requerimiento específico.
Actores Principales Arquitecto
Entradas El arquitecto debe haber abierto un proyecto previamente.
Salidas Ninguna
Pre-Condiciones Debe existir por lo menos un requerimiento creado en el proyecto y este debe tener un problema asignado.
Post-Condiciones Condición final de éxito El problema asignado a un requerimiento se pudo editar.
Condición final de fallo El problema asignado a un requerimiento no se pudo editar.
Flujo básico de éxito
No. Actor No. Sistema
Documentación de casos de uso
19
1 El arquitecto selecciona la opción “Problemas en los requerimientos”.
2
Este caso de uso comienza, cuando el arquitecto selecciona la opción “Editar problema a un requerimiento”.
3 La aplicación muestra una ventana al arquitecto, donde le muestra la lista de requerimientos asociados al proyecto y que tienen asignado un problema.
4 El arquitecto selecciona un requerimiento asociado al proyecto.
5 La aplicación muestra en la misma ventana, un formulario donde le indica al arquitecto los espacios que puede editar:
Descripción del problema.
Stakeholders afectados por el problema.
Posible solución.
6 La aplicación además muestra un campo adicional, donde el arquitecto debe explicar el motivo del cambio.
7 El arquitecto debe llenar todos los campos ya mencionados y guardar los cambios.
8 La aplicación almacena la información del problema en la base de datos y le asigna la fecha en que se realizó la asignación.
9 La aplicación muestra por pantalla un mensaje de éxito de la operación.
Variaciones (Caminos de excepción)
No aplica
Extensiones CU 004. Tabla 11 Caso de uso Editar problema a un requerimiento
Documentación de casos de uso
20
5.1.9. Proceso caso de uso Eliminar problema a un requerimiento
5.1.10. Documentación caso de uso Eliminar problema a un requerimiento
Id Caso de Uso CU 006 Nombre Eliminar problema a un requerimiento
Proyecto ERMT 2.0 Fecha 17/03/2014
Autor Carlos Duarte Versión 1.0
Prioridad Media
Objetivo en contexto Este caso de uso permite al arquitecto eliminar un problema a un requerimiento específico.
Actores Principales Arquitecto
Entradas El arquitecto debe haber abierto un proyecto previamente.
Salidas Ninguna
Pre-Condiciones Debe existir por lo menos un requerimiento creado en el proyecto y este debe tener un problema asignado.
Post-Condiciones Condición final de éxito El problema asignado a un requerimiento se pudo eliminar.
Condición final de fallo El problema asignado a un requerimiento no se pudo eliminar.
Flujo básico de éxito
No. Actor No. Sistema
1 El arquitecto selecciona la opción “Problemas en los requerimientos”.
2
Este caso de uso comienza, cuando el arquitecto selecciona la opción “Eliminar problema a un requerimiento”.
Documentación de casos de uso
21
3 La aplicación muestra una ventana al arquitecto, donde le muestra la lista de requerimientos asociados al proyecto y que tienen asignado un problema.
4 El arquitecto selecciona un requerimiento asociado al proyecto.
5 La aplicación muestra en la misma ventana, la información correspondiente al problema que existe en ese requerimiento.
6 La aplicación además muestra un campo adicional, donde el arquitecto debe explicar cómo se solucionó el problema.
7 El arquitecto debe llenar el campo ya mencionado.
8 La aplicación elimina el problema en el requerimiento y le asigna la fecha en que se realizó la eliminación.
9 La aplicación muestra por pantalla un mensaje de éxito de la operación.
Variaciones (Caminos de excepción)
No aplica
Extensiones CU 004, CU 005. Tabla 12 Caso de uso Eliminar problema a un requerimiento
Documentación de casos de uso
22
5.1.11. Proceso caso de uso Generar reporte de los problemas en los requerimientos
5.1.12. Documentación caso de uso Generar reporte de los problemas en los requerimientos
Id Caso de Uso CU 007 Nombre Generar reporte de los problemas en los requerimientos
Proyecto ERMT 2.0 Fecha 18/03/2014
Autor Carlos Duarte Versión 1.0
Prioridad Alta
Objetivo en contexto Este caso de uso permite al gerente generar un reporte de los problemas en los requerimientos.
Actores Principales Gerente
Entradas El gerente debe haber abierto un proyecto previamente.
Salidas Documento el cual contiene toda la información de los problemas correspondientes a los requerimientos en un proyecto.
Pre-Condiciones Debe existir por lo menos un requerimiento creado en el proyecto y este debe tener un problema asignado.
Post-Condiciones Condición final de éxito Se pudo generar el reporte
Condición final de fallo No se pudo generar el reporte
Flujo básico de éxito
No. Actor No. Sistema
1
Este caso de uso comienza, cuando el gerente selecciona la
Documentación de casos de uso
23
opción “Generar reporte”. Este paso incluye CU 0031.
2 La aplicación muestra en una ventana, los diferentes tipos de reportes que se pueden generar
3 El gerente selecciona la opción “Generar reporte de los problemas en los requerimientos”.
4 La aplicación consulta los datos correspondientes a los problemas en los requerimientos
5 La aplicación genera un archivo en Excel con el correspondiente reporte.
6 La aplicación muestra en una ventana, donde le permite al gerente digitar el nombre del reporte y definir su ubicación en el equipo.
7 El gerente digita el nombre del archivo y selecciona la carpeta donde quedará almacenado en el equipo.
Variaciones (Caminos de excepción)
No aplica
Extensiones CU 004, CU 005, CU 006, CU 0031. Tabla 13 Caso de uso Generar reporte de los problemas en los requerimientos
5.1.13. Proceso caso de uso Generar matriz de trazabilidad
Los enlaces de trazabilidad permiten seguir la vida de un requerimiento tanto hacia delante como hacia atrás, desde el origen hasta la implementación. Generalmente se distinguen cuatro tipos de enlaces de trazabilidad:
Hacia adelante desde los requerimientos: La responsabilidad para el logro de los requerimientos debe ser asignada a los componentes del sistema, así tal responsabilidad es establecida y el impacto del cambio de requerimientos puede ser evaluado.
Hacia atrás a los requerimientos: La conformidad de los componentes del sistema con los requerimientos debe ser verificada [10]
Documentación de casos de uso
24
5.1.14. Documentación caso de uso Generar matriz de trazabilidad
Id Caso de Uso CU 008 Nombre Generar matriz de trazabilidad
Proyecto ERMT 2.0 Fecha 18/03/2014
Autor Carlos Duarte Versión 1.0
Prioridad Alta
Objetivo en contexto Este caso de uso permite al arquitecto generar una matriz de trazabilidad de requerimientos.
Actores Principales Arquitecto
Entradas El arquitecto debe haber abierto un proyecto previamente.
Salidas Documento el cual contiene la matriz de trazabilidad
Pre-Condiciones Debe existir por lo menos un requerimiento creado en el proyecto.
Post-Condiciones Condición final de éxito Se pudo generar la matriz
Condición final de fallo No se pudo generar la matriz
Flujo básico de éxito
No. Actor No. Sistema
1
El arquitecto selecciona la opción “Trazabilidad”.
2 Este caso de uso comienza, cuando el arquitecto selecciona la opción “Generar matriz de trazabilidad”.
3 La aplicación muestra en una ventana dos opciones de matriz de trazabilidad:
1. Con casos de uso
4 El arquitecto selecciona la matriz de trazabilidad.
5 La aplicación consulta las relaciones existentes dependiendo la selección del arquitecto.
Documentación de casos de uso
25
6 La aplicación genera un archivo en Excel con la correspondiente matriz.
7 La aplicación muestra en una ventana, donde le permite al arquitecto digitar el nombre de la matriz y definir su ubicación en el equipo.
8 El arquitecto digita el nombre del archivo y selecciona la carpeta donde quedará almacenado en el equipo.
Variaciones (Caminos de excepción)
No Aplica
Extensiones CU 002, CU 023, CU 031. Tabla 14 Caso de uso Generar matriz de trazabilidad
5.2. Documentación casos de uso gestión de riesgos
5.2.1. Documentación casos de uso identificación de riesgos
Id Caso de Uso CU 009 Nombre Identificar tipo de riesgo
Proyecto ERMT 2.0 Fecha 18/03/2014
Autor Carlos Duarte Versión 1.0
Prioridad Alta
Objetivo en contexto Este caso de uso permite al gerente identificar el tipo de riesgo correspondiente a un requerimiento.
Actores Principales Gerente
Entradas El gerente debe haber abierto un proyecto previamente.
Salidas Ninguna
Pre-Condiciones Debe existir por lo menos un requerimiento creado en el proyecto.
Post-Condiciones Condición final de éxito El riesgo se asignó a un requerimiento.
Condición final de fallo El riesgo no se asignó a un requerimiento.
Flujo básico de éxito
No. Actor No. Sistema
1
El gerente selecciona la opción “Asignar riesgo”.
2 La aplicación muestra por pantalla la lista de requerimientos asociados al proyecto.
3 El gerente selecciona el o los requerimientos asociados al riesgo.
Documentación de casos de uso
26
4 La aplicación muestra por pantalla los tres tipos diferentes de riegos:
1. Identidad 2. Volatilidad 3. Complejidad
Para la cual, la aplicación le permite al gerente seleccionar dos diferentes escalas:
1. Alta 2. Baja
5 El gerente selecciona el nivel de escala para cada tipo de riesgo.
6 La aplicación muestra un mensaje por pantalla indicando el mensaje de éxito.
Variaciones (Caminos de excepción)
9.0.E.2 La aplicación envía un mensaje de error al gerente.
1. El gerente recibe el mensaje de error por parte de la aplicación, indicando que no existen requerimientos asociados al proyecto.
2. El gerente vuelve al paso 1.
Extensiones CU 010
5.2.2. Documentación casos de uso técnicas de mitigación
Id Caso de Uso CU 010 Nombre Generar técnica de mitigación
Proyecto ERMT 2.0 Fecha 18/03/2014
Autor Carlos Duarte Versión 1.0
Prioridad Baja
Objetivo en contexto Este caso de uso permite al gerente generar la técnica de mitigación correspondiente al riesgo del requerimiento.
Actores Principales Gerente
Entradas El gerente debe haber abierto un proyecto previamente.
Salidas Ninguna
Pre-Condiciones Debe existir por lo menos un requerimiento creado en el proyecto y este debe tener asignado un riego.
Post-Condiciones Condición final de éxito La técnica de mitigación se asignó a un requerimiento.
Condición final de fallo La técnica de mitigación no se asignó a un requerimiento.
Flujo básico de éxito
Documentación de casos de uso
27
No. Actor No. Sistema
1
El gerente selecciona la opción “Generar técnica de mitigación”.
2 La aplicación muestra por pantalla la lista de requerimientos que tienen asociados un riesgo.
3 El gerente selecciona el requerimiento para escoger la técnica de mitigación.
4 La aplicación muestra por pantalla los cuatro tipos diferentes de técnicas de mitigación:
1. Descubrimiento 2. Priorización 3. Experimentación 4. Especificación
5 Para cada técnica de mitigación se tendrá una escala de: Alto, Medio, Bajo, la cual corresponde el nivel de énfasis para cada técnica.
6 La aplicación muestra un mensaje por pantalla indicando el mensaje de éxito.
Variaciones (Caminos de excepción)
10.0.E.2 La aplicación envía un mensaje de error al gerente.
1. El gerente recibe el mensaje de error por parte de la aplicación, indicando que no existen riesgos asociados a los requerimientos.
2. El gerente vuelve al paso 1.
Extensiones CU 009
6. Referencias
[1] A. Cockburn, Writing effective use cases. Boston: Addison-Wesley, 2001. [2] D. Kulak and E. Guiney, Use cases: requirements in context. Boston: Addison-Wesley, 2004. [3] K. E. Wiegers and J. Beatty, Software requirements. 2013. [4] “ERMT.” [Online]. Available: http://pegasus.javeriana.edu.co/~CIS1010IS05/index.html. [5] D. Leffingwell and D. Widrig, Managing software requirements: a use case approach. Boston: Addison-Wesley, 2003.
Documentación de casos de uso
28
[6] M. F. Rabbi and K. O. Bin Mannan, “A Review of Software Risk Management for Selection of Best Tools and Techniques,” in Ninth ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing, 2008. SNPD ’08, 2008, pp. 773–778.
[7] M. Hoffmann, N. Kuhn, M. Weber, and M. Bittner, “Requirements for requirements management tools,” in Requirements Engineering Conference, 2004. Proceedings. 12th IEEE International, 2004, pp. 301–308. [8] “Systems and Software Engineering - Life Cycle Processes - Risk Management,” Std ISO IEC 16085 - 2006, pp. c1–36, 2006.
[9] “Systems and software engineering – Life cycle processes –Requirements engineering,” ISO/IEC/IEEE 29148:2011(E), pp. 1–94, 2011. [10] J. Beatty and A. Chen, Visual Models for Software Requirements: An Rml Handbook. [s.l.]: Microsoft Pr, 2012. [11] L. Mathiassen and T. Tuunanen, “Managing Requirements Risks in IT Projects,” IT Professional, vol. 13, no. 6, pp. 40–47, Nov. 2011.
[12] B. W. Boehm, “Software risk management: principles and practices,” IEEE Software, vol. 8, no. 1, pp. 32–41, Jan. 1991.