DETALLE DE UN PROCESO DE DESARROLLO DE SOFTWARE

ANALISIS

• Características

• Documentos

• Especificaciones

• Diagrama de caso de uso

• Escenarios-subescenarios

• Prototipos

DISEÑO (PRELIMINAR Y DETALLADO)

• Modelo de clases y objetos

o diagramas de secuencia

o diagramas de colaboración

• Diagramas de clases y consultas de patrones de diseño

o modelo de comportamiento de clases y objetos

o diagramas de actividades

o diagramas de estado

• construcción de modelo

o diagramas de componentes

o diagramas de despliegue

IMPLEMENTACION

• Decisiones que se toman a partir de los diagramas de componentes y de

despliegue

• Implementa las clases de componentes a partir de los diagramas de objetos

• Prueba

o Prueba unitaria de cada clase

 o Prueba de módulos

o Prueba de integración

• Mantenimiento

o Informes de errores

o Nueva especificación de requisitos

ANALISIS ORIENTADO A OBJETOS (AOO)

[BOSCH 94]

 “ es un método de análisis que examina los requisitos desde la

perspectiva de las clases y objetos que se encuentran en el vocabulario
del dominio del problema “

• Documentos básicos

o Documentos de análisis

o Especificaciones de requisitos o requerimientos

o Diagramas de caso de uso

o Escenarios y sub escenarios

o Prototipos y su evolución (todos deberán estar identificados y

codificados)

• Documentos de análisis

o Contiene el documento en que aporta el cliente

o Las actas de reuniones de trabajo

o Secretaria

o Aprobar el acta de cada uno

ESPECIFICACIONES DE REQUISITOS O REQUERIMIENTOS

[JACOBSON CAP 6]

 “ la captura de requisitos es el proceso de averiguar, normalmente en

circunstancias difíciles lo que se debe construir “

• La especificación de requisitos es un documento mas técnico y elaborado de

los documentos de análisis.

• Codificar requisitos

• Utilizar una especificación jerárquica

o Nivel 1: casos de uso

o Nivel 2: escenarios

o Nivel 3: sub-escenarios

DIAGRAMAS DE CASO DE USO (I)

• Es uno de los cinco tipos de diagrama UML, que se utiliza para el modelado

• Se corresponde inicialmente con requisitos del primer nivel

• Se suelen codificar con el mismo código que el requisito

• Los casos de uso representan una vista externa del sistema

• Se sacan durante reuniones entre el desarrollador y el cliente para que al

final todos coincidan

• El modelado con casos de uso fue desarrollado por Jacobson en 1992

DIAGRAMAS DE CASO DE USO (II)

Sistema que se desea modelar

•
 Un actor es una clase

Caso de uso

Interacción

Limites del sistema

DESCRIPCION DEL CASO DE USO

Hay:

1. Pedidos

2. Informes

3. Averías

4. Reservas

5. Subgerencia

6. Información para el usuario

7. Actividad
SISTEMAS

• Sistema Servidor: está formado por una maquina Windows NT que es

atacado por un sistema cliente constituido por maquinas.

• Sistema Cliente: los programas de aplicación residen en la maquina “cliente”

que atacan a servidor donde se encuentra instalado en gestor de la base de
datos junto con la base de datos correspondiente.

INTERFASES

• Interfaz de administrador: le permite acceder a todas las acciones que

presenta la aplicación.

• Interfaz dependiente: solo tiene acceso a algunas de las funciones de la

aplicación.

• Interfaz mecánico: tendrá acceso solamente a las reparaciones de la

aplicación.

CASOS DE USO RATIONAL ROSE

• Tiene una acción para ir introduciendo los casos de uso

• Permite el manejo de autores que se traducirán al sistema como clase

• Cada sistema recibe un nombre y está ligado a una ventana

ESCENARIOS U SUBESCENARIOS

• Cada caso de uso da lugar a múltiples escenarios

• Se codifican
 • Los escenarios también se pueden utilizar para probar el sistema en la fase
de pruebas

• No es necesario hacer todos los escenarios y subescenarios

DIAGRAMA DE CASOS DE USO (III)

• La relación “EXTEND” se utiliza cuando un caso de uso es similar a otro caso

se uso pero le añade una característica nueva

• La relación “USE” se utiliza cuando se tiene una parte del comportamiento

común o más de un caso de uso

PROTOTIPOS

• Consiste en crear un modelo o maqueta del sistema que se construye para

evaluar mejor los requisitos.

• Estos modelos son o prototipos, suelen consistir en versiones reducidas,

demos o conjuntos de pantallas

Existen tres razones principales para emplear Prototipado, ordenadas por

frecuencias de uso.

• Prototipos de interfaz de usuario: sirve para asegurarse de que esta bien

diseñado y satisface las necesidades de quien debe usarlo.

• Modelo de rendimiento: sirve para evaluar el posible rendimiento de un

diseño técnico

• Prototipado funcional