Recomendaciones para elaborar modelo de CUspp.centramerica.com/pp/bancofotos/300-3010.pdf · PLAN...

Guía para la Elaboración de Casos de Uso Disciplina de Requerimientos

Guia Elaboracion Casos de Uso 01/06/2010 22:32:00 Página 2 de 16

Historial de Revisión

Fecha Versión Descripción Autor

01-Julio-08 1.1 Adecuacion del documento Susy Silva

28-Agosto-08 1.2 Redaccion Susy Silva


Tabla de Contenido

INTRODUCCIÓN ........................................................................................................................ 4

PROPÓSITO ................................................................................................................................... 4 ALCANCE ..................................................................................................................................... 4

PRE-CONDICIONES (PARA EMPEZAR EL MODELADO DE CASOS DE USO) ......... 4

¿ ES UN PROYECTO NUEVO O UN MANTENIMIENTO ? .................................................................... 5

¿ EN QUÉ FASE DEL CICLO DE INGENIERÍA DEL SOFTWARE ESTÁS ? ............................................. 5

¿ CUÁNTA GENTE ESTÁ DEDICADA AL ESFUERZO DE INGENIERÍA DE REQUERIMIENTOS ? ............ 7

PLAN DE ACTIVIDADES ................................................................................................................. 7

PROCESO DE ELABORACIÓN DE CASOS DE USO ........................................................... 8

ENCONTRAR ACTORES ................................................................................................................. 8 Mecanismos para identificar actores...................................................................................... 8

Puntos de control .................................................................................................................... 9 ENCONTRAR CASOS DE USO........................................................................................................ 11

Elaborar el outline del escenario principal .......................................................................... 12

Flujos Alternos ...................................................................................................................... 12 Actualizar los documentos .................................................................................................... 12

ESTÁNDARES PARA LA ESCRITURA DE CASOS DE USO ............................................ 12

NOMBRE DE LOS CASOS DE USO ................................................................................................ 13

NOMBRE DE ARCHIVOS .............................................................................................................. 13 DESCRIPCIÓN DEL FLUJO BÁSICO .............................................................................................. 13

REFERENCIAS FLUJOS ALTERNOS .............................................................................................. 13 USO DE DICCIONARIO Y/O GLOSARIO DE TÉRMINOS .................................................................. 14 PRE-CONDICIONES Y POST-CONDICIONES ................................................................................... 14 REFERENCIAS A OTROS DOCUMENTOS ........................................................................................ 14

RELACIONES ENTRE CASOS DE USO ............................................................................................ 14


Guía de Elaboración de Casos de Uso

Introducción El propósito de este documento es presentar las guías para la elaboración de los Casos de Uso a utilizar dentro de los proyectos.

Propósito

Este documento describe cómo identificar y elaborar los Reportes de Caso de Uso y pretende ser una ayuda para todos aquellos que tengan que elaborar o interpretar casos de uso . Para los Ingenieros de Requerimientos representa una norma a seguir para la elaboración del artefacto, que implica que se homologuen criterios y enriquecer el documento de acuerdo a las peticiones del cliente y su experiencia, durante las fases que el proceso unificado de rational implique. Este documento complementa las especificaciones descritas en el template de Especificación de Casos de Uso siguiendo la metodología de la disciplina de requerimientos del proceso unificado de Rational, el cual deberá tomarse como formato oficial para la elaboración de este artefacto. El propósito de este documento es definir los estándares y proporcionar las mejores prácticas para la elaboración de los Casos de Uso dentro de un proyecto.

Alcance

Este documento únicamente cubre guías para hacer casos de uso que empiezan de cero (nuevos proyectos o mantenimientos adaptativos (es decir, cuando el mantenimiento involucra nueva funcionalidad completamente).

Pre-condiciones (para empezar el modelado de casos de uso)

Antes de Iniciar el esfuerzo de Ingeniería de Requerimientos es necesario identificar lo siguiente:


¿ Es un proyecto nuevo o un mantenimiento ? ¿ En qué fase del ciclo de Ingeniería del SW se encuentra ? ¿ Cuánta gente está dedicada al esfuerzo de Ingeniería de Requerimientos ? Sobre el plan de actividades

Analizar el plan de actividades y tiempos del proyecto

Identificar la duración y término de la Fase de Inception Identificar la duración y término la Fase de Elaboration

¿ Es un proyecto nuevo o un mantenimiento ?

Si es un Proyecto Nuevo Deberá generarse el documento de Visión enfocándose principalmente en los siguientes puntos: Descripción de Stakeholders Necesidades Definición del problema Restricciones al proyecto Esto con la finalidad de conocer las necesidades de negocio y mapear los casos de uso para que cubran exactamente las necesidades de los Stakeholders. Así mismo deberá empezarse con el modelo de casos de uso de manera general.

Si es un mantenimiento

Implica funcionalidad nueva (desde cero)

Deberá empezarse con el modelo de Casos de Uso

Implica cambiar funcionalidad específica

Si se cuenta con el modelo de casos de uso deberá modificarse el reporte de caso de uso y analizarse con cuáles otros casos de uso puede tener relación para realizar su modificación, si es que aplica.

¿ En qué fase del ciclo de Ingeniería del Software estás ?

Dependiendo de la Fase de Ingeniería en la que se encuentre el proyecto, se deben enfocar los esfuerzos de modelado de casos de uso (y del resto de la Ingeniería de Requerimientos).


Fase de Incepcion Por ejemplo, en la fase de Inception, no se debe intentar levantar todo el detalle de los requerimientos del proyecto (se estaría cayendo en el ciclo clásico y antiguo de cascada). Se debe empezar por tener una idea general del proyecto centrándose en los siguientes puntos: modelo de casos de uso, bosquejo de los casos de uso principales, priorizar las características del producto, medir los riesgos y obtener las restricciones del proyecto. A continuación se define las actividades principales que debes hacer en cada una de las fases.

Inception

Primer bosquejo del modelo de casos de uso Glosario (Vocabulario Inicial) Flujo de eventos (bosquejo) de los casos de uso críticos

Boceto de la Interfaz de Usuario de los CU principales (si aplica) Visión (principales necesidades de los usuarios involucrados y los usuarios finales y

características del producto)

Elaboration

Refinamiento del Modelo de Casos de Uso (Gráfico) (Revisado y aceptado formalmente)

Detalle del 80% de los Casos de Uso (Revisados e idealmente aceptados formalmente)

Reporte de Casos de Uso terminados y verificados (de los CU Principales / Críticos ) Prototipo del Sistema (si aplica) Glosario (Vocabulario Incial)

Construction

Administración formal de cambios (analizar impacto del cambio) Flujos de Eventos Modificados Glosario modificado


¿ Cuánta gente está dedicada al esfuerzo de Ingeniería de Requerimientos ?

La meta principal de todos los proyectos deberá ser:

Crear software de calidad en el tiempo, con los recursos asignados y cubriendo las necesidades reales de nuestros Stakeholders

De ahí que es importante NO COMPROMETERSE A HACER MÁS DE LO QUE SE PUEDA con base en los recursos y tiempo que tenemos. Es importante analizar la complejidad del software, la importancia que éste tiene para la organización y se definan en forma adecuada los tiempos y recursos asignados. Si con base en el análisis del problema y con la detección de algunos de los casos de uso se observa que es casi imposible sacar el proyecto es importante ajustar las expectativas de los Stakeholders.

Plan de actividades

Todo proyecto deberá contar con un plan de trabajo que determine actividades y tiempo y que será administrado y controlado por un Líder de Proyecto, Gerente o cualquier otro responsable asignado. El área de Requerimientos deberá:

Analizar el plan de actividades y tiempos del proyecto Conocer las responsabilidades y el alcance de las mismas Identificar los puntos de verificación y los criterios de evaluación Identificar los hitos, productos o cualquier otro artefacto que se espere como

entregable en cada una de estas actividades

Conocer la duración y término de la Fase de Inception Conocer la duración y término de la Fase de Elaboration De ser posible, deberá establecerse un plan de trabajo interno para completar

estas actividades y tiempos así como reportar el avance de las mismas al administrador


Proceso de Elaboración de Casos de Uso

Las actividades generales que deberán ser cubiertas para la Elaboración de los Casos de Uso son:

Encontrar actores Encontrar Casos de uso (identificar metas de los actores) Describir las interacciones entre actores y casos de uso Empaquetar a los casos de uso y actores Crear los diagramas de casos de uso necesarios Desarrollar borradores de Casos de Uso Evaluar los resultados

Encontrar Actores

Un actor es todo aquello que tiene interacción directa con el sistema. Un actor puede ser una persona, dispositivo u otro sistema.

Mecanismos para identificar actores

Para encontrar actores se recomienda:

1. De los Stakeholders identificados, verificar cuáles de ellos interactuarán en forma directa (mediante algún desarrollo o como operadores) con el sistema de información. Ese subconjunto de Stakeholders son actores.

2. Responder las siguientes preguntas:

¿ Quién utilizará el sistema ? ¿ Quién entregará información al sistema ?

¿ A quién le debe entregar información el sistema ? ¿ Quién mantendrá la información del sistema? (quién trabajará con todos

esos caso de uso de soporte dedicados a la administración de catálogos) ¿ Quién soportará y administrará el sistema? (quién trabajará con los casos

de uso de administración de usuarios, configuración del sistema, respaldos, etc..)

¿ El sistema interactuará con otros sistemas ? ¿ El sistema utilizará algún dispositivo (hardware) ?


¿ En qué lugar de la organización se utilizará principalmente el sistema ? 1

Puntos de control

Usuarios Multifacéticos vs. Actores Una misma persona (especificador) puede estar jugando al mismo tiempo más de un rol en la organización. La diferencia entre un actor y un usuario, es que el actor representa un tipo de usuario más que a la persona misma. Muchos usuarios pueden jugar el mismo rol, lo que significa que todos ellos deben estar representados por un solo actor. Acciones: Identificar los roles que juega un usuario y separarlos en el diagrama de actores Especificar en forma detallada lo que cada rol requiere del sistema Nombramiento Un actor aunque representa a un grupo de personas en una organización no debe nombrarse en plural. Acciones: Nombrar los actores en singular Los nombres de los actores deben corresponder a un rol. Si no es así, cambiar los

nombres. Un actor no debe tener el nombre de una persona

Validación de Cobertura Para validar la cobertura en el análisis de actores es importante que tomar en cuenta la siguiente clasificación: Actores Primarios Usuarios que ejecutan la funcionalidad principal del sistema (la razón de ser de la aplicación).

1 Una buena práctica para esto es localizar el organigrama del área y obtener los puestos y responsables, ya que

regularmente algunos de ellos tienden a ser actores potenciales del sistema. Regularmente estos organigramas proporcionan información para la mejor comprensión del problema que se intenta resolver y además son una referencia, en algunos casos, para resolver dudas.


Actores Secundarios Usuarios que ejecutan funcionalidad secundaria del sistema (administrar usuarios, administrar catálogos, cargar datos, hacer respaldos, etc...). Acciones: Verificar con respecto al tamaño del proyecto y áreas en la organización (en las que

estará operando el sistema), si el número actual de actores es realmente significativo con respecto al tamaño y tipo de proyecto.

o Muchos actores para un proyecto pequeño (10 C.U). Deberán revisarse y ajustarse los casos de uso utilizando la generalización, por ejemplo.

o Muy pocos actores para un proyecto pequeño (10-20 C.U) puede que necesite revisar y ajustar.

o Etc... (definan sus propias métricas de tamaño de proyecto)

Verificar si existen actores de ambas clasificaciones (principales y secundarios). Verificar si el proyecto tiene relaciones con dispositivos u otros sistemas y validar

que estos se encuentran definidos como actores Realizar una verificación final una vez concluida la definición de los casos de uso ya

que podrían haber surgido nuevos actores no identificados en el primer esfuerzo. Verificar, una vez modelados los casos de uso, si cada actor está relacionado con al

menos un caso de uso Eliminar actores que no sean mencionados en la descripción de los casos de uso o

que no tengan al menos una relación con algún caso de uso Verificar si se puedes mencionar al menos a 2 personas (instancias reales) que

jueguen el rol de cada uno de los actores. Si esto no pasa, verificar si el actor no es real ya que más bien puede ser parte de otro actor.

Verificar si varios actores juegan roles similares con respecto al sistema. Si esto pasa, deberá intentarse fusionar a los actores en un solo actor utilizando generalización (herencia).

Verificar si varios actores juegan roles similares con respecto a un mismo caso de uso. Si es así, utilizar la generalización entre actores.

Verificar si un actor en particular tiene varios propósitos para utilizar (de diversas formas) un caso de uso. Si esto es así, analizar si debe dividirse el actor y/o caso de uso.

Validación de Alcance La definición de actores permite identificar los límites del sistema en desarrollo. Deberán identificarse como actores únicamente aquellos quienes se comuniquen en forma directa con el sistema. Si se está incluyendo roles que están alrededor del sistema pero que no interactúan en forma directa, se está cayendo en el error de mezclar el negocio con el sistema. Acciones:


Verficiar para cada uno de los actores que estos tengan interacción directa con el sistema. Si no es así deberán ser elimínados del modelo de casos de uso

Validación de Especificador Si la definición del sistema completo (actores, funcionalidad, característica, etc.) se está llevando a cabo por una sola persona deberá ser considerado como un riesgo potencial. Acciones: Verificar si se cuenta con un solo especificador. De ser así definirlo desde un inicio

como un riesgo potencial y comunicarlo al líder de proyecto. Identificar posibles especificadores por parte del área usuaria.

Generales

Algunas características que debes tener bien claras del actor:

Alcance del actor en el proyecto Ambiente en el cual el actor estará utilizando el sistema (grandes errores en la Ing.

de SW, es crear aplicaciones que no podrán ser utilizadas en forma óptima en el ambiente real del actor).

El número de usuarios representado por éste actor. Este número denotará el factor de relevancia del actor con respecto al resto de los actores y con respecto al proyecto.

La frecuencia en la cual el actor utilizará el sistema. Nivel de experiencia del actor (especificador) en el dominio del problema. Nivel general del actor en conocimientos de sistemas (cómputo) Conocer cuáles otras aplicaciones utiliza el actor.

Encontrar casos de uso

La actividad de definición de Casos de Uso se centra básicamente en identificar para cada uno de los actores, las diversas formas en las que espera utilizar el sistema. Las actividades generales pueden centrarse en:

Hacer una lista de las metas del actor Identificar para qué va a utilizar el actor el sistema Identificar si el actor obtendrá, cambiará, modificará o eliminará información del

sistema


Elaborar el outline del escenario principal

Elaborar el bosquejo del flujo básico de los casos de uso principales (en caso de que el sistema incluya menos de 6 casos de uso elaborar el bosquejo de cada uno de ellos)

Revisar y Validar estos artefactos con el usuario

Flujos Alternos

Para poder identificar los posibles flujos alternos se sugiere apoyar de las siguientes

preguntas:

¿Qué puede estar mal?¿ Cómo deberá responder el sistema ante los posibles errores?

¿Cuáles son algunas de las situaciones opcionales que se pueden presentar en el caso de uso?

¿Cuáles son algunas de las situaciones no comunes en el caso de uso pero que puedan llegar a presentarse?

¿El actor del caso de uso, es la persona indicada para resolver los posibles errores?

¿Deberá estar relacionado algún otro actor que entre en acción en ciertas ocasiones?

Condiciones de falla

Completar el escenario principal y realizar una lluvia de ideas de todas las fallas que pueden ocurrir en cada una de las actividades. En primera instancia deberán identificarse las fallas sin enfocarse en el cómo deberán manejarse estos eventos por el sistema

Identificar los flujos alternos opcionales Manejo de errores

Describir obligatoriamente la forma en que el sistema responderá a cada una de las condiciones de falla

Actualizar los documentos

Actualizar y completar el reporte de casos de uso con las pre y pos condiciones, requerimientos especiales y referencias a otros documentos

Estándares para la escritura de casos de uso Las siguientes secciones definen la estandarización para la escritura de los casos de uso.


Nombre de los Casos de Uso

Describir todos los casos de uso desde la perspectiva del actor y no del sistema Describir todos los casos de uso mediante un nombre representativo utilizando un

verbo en infinitivo al inicio, el cual deberá estar acompañado obligatoriamente por el sustantivo al que el verbo califica. Ejem. Generar Cotización

Nombre de archivos

Describir los archivos generados para la documentación de los casos de uso bajo el siguiente nomenclatura:

CUMOD001 Nombre del caso de uso | | |---- Consecutivo numérico del caso de uso | |---- Módulo del sistema XXXX (ver estándares de módulos del sistema) |---- Identificador del artefacto Casos de Uso

Descripción del Flujo Básico

Cada una de las actividades del flujo básico debe representar una interacción completa entre el usuario y el sistema

El nivel de detalle debe ser suficiente para que el diseñador no tenga que realizar más investigaciones con el usuario, ese detalle no debe ir necesariamente incluido en la descripción de las actividades, sino que debe complementarse con el documento de Reglas de Negocio, Diccionario de Datos y Glosario de Términos (deben estar muy bien descritas las relaciones con los otros documentos)

o El sistema valida que el cliente cubre los requisitos para otorgarle el crédito (ver Reglas Negocio, BR010. Otorgamiento de Crédito)

o Si el proyecto está utilizando RequisitePro, debe hacer la liga en las matrices

El descripción de los flujos dentro del caso de uso debe describirse en tiempo presente:

o El sistema solicita los sig. datos del cliente: Nombre, Dirección o El vendedor captura los datos

En las descripciones del flujo básico no deberán usarse términos técnicos como tabla, campo, subrutina, grid, pantalla, ya que este documento debe ser suficientemente claro tanto para usuarios de negocio como para el equipo de desarrollo.

Referencias Flujos Alternos

Cuando se haga referencia a algún flujo alterno, en la descripción de las actividades del flujo básico, deberá colocares de la siguiente forma según el caso:


Para hacer mención a los flujos alternos, se deberá utilizar un prefijo formado por dos caracteres que identifica el tipo de flujo alterno y dos números que corresponden a un consecutivo por tipo de flujo alterno.

Los prefijos a utilizar de acuerdo al tipo de flujo alterno son los siguientes: o AO## Flujo alterno opcional o AG## Flujo alterno general o AE## Flujo alterno de excepción.

Si es un flujo opcional se representa de la siguiente manera: Si Condición se

ejecuta el flujo alterno “AO01<nombre del flujo alterno>”.

Si es un flujo de excepción o general se representa solamente una referencia de

la siguiente forma: [AE01 ], [AG01], donde 01 es un numero consecutivo.

Dichas referencias deben tener una hiperliga a la descripción del flujo alterno.

Uso de Diccionario y/o Glosario de Términos

En el reporte del caso de uso se PROHIBE escribir sentencias como: “ Se captura la información del cliente “, “Se capturan los datos del cliente”. Se debe documentar exactamente cuál es la información del cliente que se requiere:

o Ejem. Nombre, Dirección.

Si se coloca solo la leyenda de campos del cliente y dichos datos se encuentran en un diccionario de datos o en el glosario, debe existir una referencia al documento en cuestión.

Pre-condiciones y Post-condiciones

Tanto las precondiciones como las poscondiciones deben ser expresadas también en términos de negocio y/o estados que deben tener los objetos de negocio para que pueda iniciarse el caso de uso o que deben existir al concluir la ejecución de este

Solo se colocan las pre-condiciones y post-condiciones si son estrictamente necesarios para que el caso de uso inicie

Referencias a otros documentos

En esta sección deben colocarse las referencias (preferentemente hiperligas) a los documentos que complementan la información del caso de uso. Normalmente debe existir referencia al Glosario de Términos correspondiente, al documento de reglas de negocio, al diccionario de datos, a formatos de impresión, y a documentos que detallen algoritmos

No deberán incluirse pantallas, diagramas de casos de uso o diagramas de comunicación en los reportes de casos de uso. Esto evitará la posible inconsistencia entre los que se usan en los Storyboards

Las pantallas y diagramas de comunicación deben de estar en el Storyboard del flujo del proyecto

Relaciones entre casos de uso


Todos los casos de uso deben de tener relación al menos con un actor ( Los casos de uso base).

Si existen casos de uso de administración de catálogos, debe existir un caso de uso para cada función administrativa de cada uno de ellos (Altas, bajas, cambios, consultas, etc..)

No son permitidas las relaciones entre casos de uso a excepción de:

o Include Siempre se van ha ejecutar cuando se ejecute el paso del caso de uso

base en el que se hace referencia al caso de uso <<include>>.

Un include puede invocarse en el flujo principal o en un alterno opcional. No puede ejecutarlo un actor No es un caso de uso completo (es parte de otro caso de uso) Es siempre invocado por el caso de uso base El caso de uso <<include>> debe estar relacionado al menos con 2

casos de uso, si no es así no es un include y los pasos deben ser regresados al caso de uso base.

o Extends Agrega funcionalidad al caso de uso base, pero no es determinante para

que se ejecute (es potencialmente opcional). Cuándo un flujo alterno opcional es muy grande y complejo se puede

sacar como un caso de uso <<extends>>

Es opcional (no siempre se ejecutan).

o Generalization.


La estructura de los casos de uso hijos es la misma, solo la forma en la que se deben ejecutar algunos de los pasos cambia de uno a otro.

Se crea un padre que tenga el mismo outline de los dos hijos (todos iguales, tanto los hijos como el padre) y los pasos que son iguales conservan la descripción en el padre, los pasos que son diferentes son descritos en los hijos.

La generalización se aplica mayormente a los actores.

Recomendaciones para elaborar modelo de CUspp.centramerica.com/pp/bancofotos/300-3010.pdf · PLAN...

Documents

Transcript of Recomendaciones para elaborar modelo de CUspp.centramerica.com/pp/bancofotos/300-3010.pdf · PLAN...