ADSI

EL DESARROLLO DEL SOFTWARE ORIENTADO A OBJETOS







APRENDICES:
ELIZABETH GUARIN CARREÑO
LEIDY MARCELA PIÑEROS
ANGIE MARTIN
JONATHAN FERNANDO AGUDELO







CENTRO DE DISEÑO Y METROLOGIA
ANALISIS Y DESARROLLO DE SISTEMAS DE INFORMACION
BOGOTA 04 DE MARZO 2014




EL DESARROLLO DEL SOFTWARE ORIENTADO A OBJETOS




APRENDICES:
ELIZABETH GUARIN CARREÑO
LEIDYMARCELA PIÑEROS
ANGIE MARTIN
JONATHAN FERNANDO AGUDELO



TRABAJO:
CASOS DE USO


TUTOR:
JULIO CÉSAR SIERRA GONZÁLEZ


CENTRO DE DISEÑO Y METROLOGIA
ANALISIS Y DESARROLLO DE SISTEMAS DE INFORMACION

BOGOTA 04 DE MARZO 2014
El Proceso de Captura de Requerimientos

Empezamos con una visión general del problema que estamos resolviendo y las áreas clave de funcionalidad que debemostratar en cualquier solución. Este es nuestro documento de visión, y debería ser de solo algunas páginas de longitud.
Por ejemplo la visión general de un cajero automático (automated teller machine; ATM) puede ser que debería soportar lo siguiente.
Depósitos monetarios, reembolsos monetarios y consultas de cuenta por los clientes.
Mantenimiento del equipamiento por los ingenieros del banco, ydescarga de depósitos y carga de dinero por la sucursal local del banco.
Auditorias de todas las actividades enviadas al sistema central del banco.
Desde esta visión general podemos extraer las actividades principales del sistema, y los agentes externos (personas, equipamiento) que están involucradas en estas actividades. Estas actividades son conocidas como casos de uso y los agentes externos sonconocidos como actores.
Los actores pueden ser personas o maquinas. Desde un punto de vista práctico es beneficioso conocer la parte implicada detrás de cada máquina, puesto que solo ellos serán capaces de tratar con el proceso de captura de requerimientos.
Los casos de uso deberías ser actividades significativas para el sistema. Por ejemplo el uso por el cliente del Cajero Automático es un casode uso. Introducir un numero PIN no lo es.
Hay una zona intermedia entre estos dos extremos. Como veremos a menudo es útil dividir casos de uso muy grandes en pequeños subcasos de uso. Por ejemplo podemos tener subcasos de uso cubriendo depósitos de dinero, retiradas de dinero y consultas de cuenta.
No hay una regla clara y rápida. Algunos arquitectos preferirán un pequeño número de casos deuso relativamente grandes, otros en cambio preferirán un gran número de pequeños casos de uso. Una regla útil a primera vista es que cualquier proyecto practico debería requerir no más de alrededor de 30 casos de uso (si necesita más, debería ser dividido en proyectos separados).
Luego mostramos la relación entre casos de uso y actores en uno o más diagramas de casos de uso. Para un proyecto grandepuede ser necesario más de un diagrama. Normalmente los grupos de casos de uso relacionados son mostrados en un mismo diagrama.
Debemos luego dar una especificación más detallada de cada caso de uso. Esto cubre su comportamiento normal, comportamientos alternativos y cualquier precondición y postcondición. Esto se refleja en un documento conocido como especificación de caso de uso o escenario decaso de uso.
Finalmente, puesto que los casos de uso son funcionales en su naturaleza, necesitamos un documento para capturar los requerimientos no funcionales (capacidad, rendimiento, necesidades de entorno, etc). Estos requerimientos son capturados en un documento conocido como una especificación suplementaria de requerimientos.
Pasos del Proceso
Los pasos en el proceso de captura derequerimientos pueden ser resumidos como sigue.
Captura una vista general del problema, y las características deseadas de su solución en el documento de visión.
Identificar los casos de uso y actores desde el documento de visión y mostrar sus relaciones en uno o más diagramas de casos de uso.
Da especificaciones de casos de uso detalladas para cada caso de uso, cubriendo el comportamiento normal y...