DOCUMENTACIÓN DE CASOS DE USO - …pegasus.javeriana.edu.co/~CIS1410IS08/Final/Anexo 2. Documento de... · Documentación de casos de uso 2 Historial De Cambios El historial de cambios

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


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


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


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.


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.


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é.


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

SPMP%20V%201.0.0.docx


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


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


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.


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.


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.


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]

Diagrama%20CU.jpg

Diagrama%20CU.jpg


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


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]


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



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



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.


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


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



Prioridad Media


17

Objetivo en contexto Este caso de uso permite al arquitecto asignar un problema a un requerimiento específico.


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.



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.


5.0.E.3 La aplicación envía un mensaje de error al arquitecto.


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



Prioridad Media

Objetivo en contexto Este caso de uso permite al arquitecto editar un problema a un requerimiento específico.



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.




19


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.


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.


No aplica

Extensiones CU 004. Tabla 11 Caso de uso Editar problema a un requerimiento


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



Prioridad Media

Objetivo en contexto Este caso de uso permite al arquitecto eliminar un problema a un requerimiento específico.



Salidas Ninguna


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.




2

Este caso de uso comienza, cuando el arquitecto selecciona la opción “Eliminar problema a un requerimiento”.


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.


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.


No aplica

Extensiones CU 004, CU 005. Tabla 12 Caso de uso Eliminar problema a un requerimiento


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



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.


Post-Condiciones Condición final de éxito Se pudo generar el reporte

Condición final de fallo No se pudo generar el reporte



1

Este caso de uso comienza, cuando el gerente selecciona la


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.


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]


24

5.1.14. Documentación caso de uso Generar matriz de trazabilidad

Id Caso de Uso CU 008 Nombre Generar matriz de trazabilidad



Prioridad Alta

Objetivo en contexto Este caso de uso permite al arquitecto generar una matriz de trazabilidad de requerimientos.



Salidas Documento el cual contiene la matriz de trazabilidad


Post-Condiciones Condición final de éxito Se pudo generar la matriz

Condición final de fallo No se pudo generar la matriz



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.


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.


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



Prioridad Alta

Objetivo en contexto Este caso de uso permite al gerente identificar el tipo de riesgo correspondiente a un requerimiento.



Salidas Ninguna


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.



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.


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.


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



Prioridad Baja

Objetivo en contexto Este caso de uso permite al gerente generar la técnica de mitigación correspondiente al riesgo del requerimiento.



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.



27


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.


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.


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.

Documents

DOCUMENTACIÓN DE CASOS DE USO - …pegasus.javeriana.edu.co/~CIS1410IS08/Final/Anexo 2. Documento de... · Documentación de casos de uso 2 Historial De Cambios El historial de cambios