Diseño de Proceso Unificado

1. ANALISIS Y DISEÑO DE
SISTEMAS
Nombre: Henrique Malla Santiago Alberto
Nombre la Prof.: Cataneo Andrea

2. PROCESO UNIFICADO
Es un proceso que:
 Proporciona guía para ordenar las actividades.
 Dirige las tareas de cada desarrollador por separado y del
equipo como un todo.
 Especifican los artefactos que deben desarrollarse.
 Ofrece criterios para el control y la medición de los productos y
actividades del proyecto.
El proceso unificado se puede definir como un marco de trabajo genérico que puede
especializarse para una gran variedad de sistemas de software, para diferentes
áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de
aptitud y diferentes tamaños de proyectos.

3. El Proceso Unificado:
 Esta basado en componentes, el software en
construcción esta formado por componentes software
interconectados a través de la interfaz.
 Utiliza el Lenguaje Unificado de Modelado (UML).
 Esta dirigido por caso de uso, centrado en la
arquitectura, e iterativo e incremental
caso de uso
Definen los objetivos y dirigen el trabajo de cada iteración.
arquitectura
Proporciona la estructura sobre la cual guiar las
iteraciones.
iterativo e incremental
Por que se hace el trabajo en mini proyectos, cada mini
proyecto es una iteración que resulta en un incremento. Las
iteraciones hacen referencia a pasos en el flujo de trabajo, y
los incrementos, al crecimiento del producto.

4. Cada clase consta de 4 fases: Inicio, Elaboración, Construcción y
Transición.
Cada ciclo produce una nueva versión del producto, y cada versión
es un producto preparado para su entrega. Consta de un cuerpo de
Código Fuente incluido en componentes que puede compilarse y
ejecutarse, además de Manuales y otros productos Asociados.
El producto terminado incluye los requisitos, Casos de uso,
Especificaciones no funcionales y Casos de prueba, incluyendo el
modelo de la arquitectura y el Modelo Visual.

5. DIAGRAMA DEL PROCESO UNIFICADO
Requisitos
Fases
Análisis
Diseño
Implementación
Prueba
RESUMEN
Final

6. Actor
Requisitos
Se utiliza el modelo de casos de uso:
Se plantean todos los casos de uso y su relación
con el usuario. Ayuda al cliente, a los usuarios y a los Desarrolladores a llegar a un
acuerdo sobre como utilizar el sistema. Cada tipo de usuario se representa mediante
un . Los actores y casos de uso forman el modelo de casos de uso.
Ejemplo:
DIAGRAMA
Actor
Sacar
Dinero
Ingresar
Dinero
Transferencia
entre
cuentas
Cliente del
Banco
casos de uso

7. Análisis
Utiliza el Modelo de Análisis:
Se refinan los casos de uso con mas detalles y se establece la
asignación inicial de funcionalidad del sistema a un conjunto de objetos que proporcionan el
comportamiento. Una forma de trabajar es identificar y describir en primer lugar los casos de
uso para una iteración, después de leer la descripción de cada caso de uso, y proponer los
clasificadores y asociaciones necesarias para llevar a cabo el caso de uso. Cada clasificador
desempeña uno o varios roles en una realización de caso de uso.
Ejemplo:
Sacar
dinero
Modelo de
caso de uso
Sacar
dinero
Modelo de
análisis
Salida
Retirada de
efectivo Cuenta
Especificado
por
DIAGRAMAInterfaz del
cajero
Participante
Clase de
interfaz
Clase de
Gestor
Clase de
Entidad

8. Diseño
Se utiliza:
Modelo de Diseño: a)-La estructura estática del sistema en forma de subsistema, clase
e interfaz. B)- Los casos de uso reflejados como colaboraciones entre los subsistema, clase e
interfaz.
Modelo de
Análisis Interfaz del
cajero
Salida Cuenta
Dispositivo de
visualización
Teclado
Sensor de
salida
Alimentador de
salida
Gestor del
cliente
Contador de
efectivo
Gestor de
transacción
Modelo de
Diseño
Retirada
de efectivo
Lector de
tarjetas
Cuenta
Clase
persistente
Retirada de
efectivo Gestor de
cuenta

9. Modelo de despliegue:
Define los nodos físicos (ordenadores) y la
correspondencia de los componentes con esos nodos. La fase de
diseño (y los modelos UML resultantes) expande y detalla los modelos
de análisis tomando en cuenta todas las implicaciones y restricciones
técnicas. El propósito del diseño es especificar una solución que
trabaje y pueda ser fácilmente convertida a código fuente y construir
una arquitectura simple y fácilmente extensible. Las clases definidas
en el análisis fueron detalladas, y se añadieron nuevas clases para
manejar áreas técnicas como la base de datos, interfaz del usuario,
comunicación, dispositivos, etc.
DIAGRAMA

10. Implementación
Utiliza el Modelo de Implementación:
Incluye componentes y la correspondencia de
las clases con los componentes. Durante el Flujo de trabajo de implementación
desarrollamos todos lo necesario para obtener un sistema ejecutable:
componentes ejecutables, componentes de fichero(código fuente, guiones Shell,
etc.) componentes de tabla (elementos de la base de datos), etc.
Gestor del
cliente
Alimentador de
salida
Sensor de
salida
Contador de
efectivo
<<ejecutable>>
Cliente.exe
<<file>>
Cliente.c
<<file>>
Salida.c
Modelo de
ImplementaciónModelo de
diseño
DIAGRAMA

11. Prueba
Se utiliza el modelo de prueba:
Donde se describen los casos de prueba que verifican
los casos de uso. Un caso de prueba es un conjunto de entrada de prueba, condiciones
de ejecución y resultados esperados, desarrollados para un objetivo concreto, tal como
probar un camino concreto a través de un caso de uso. Un procedimiento de prueba es
una especificación de como llevar a cabo la preparación, ejecución y evaluación de
resultados de un caso de prueba particular.
Modelo de
casos de uso
Modelo de
Prueba
Sacar Dinero Sacar Dinero-
Flujo básico
DIAGRAMA

12.  Descripción del producto final a partir de una buena idea y se presenta el
análisis de negocio para el producto. Se prioriza el Modelo de caso de uso
simplificado que contenga los casos de uso mas críticos.
 Se especifican en detalle los casos de uso y se diseña la arquitectura del
sistema. Durante esta fase del desarrollo, se realizan los casos de uso mas
críticos que se identificaron en la fase de inicio. El resultado de esta fase
es una línea base de la arquitectura.
 En esta fase, la línea base de la arquitectura crece hasta convertirse en el
sistema completo. Al final de esta fase, el producto contiene todos los
casos de uso que la dirección y el cliente han acordado para el desarrollo
de esta versión.
 Cubre el periodo durante el cual el producto se convierte en versión beta,
en esta versión usuarios con experiencia prueban el producto e informan de
errores encontrados y los desarrolladores se encargan de corregirlos. En
esta fase se debe dirigir la fabricación, formación de cliente, proporcionan
una línea de ayuda y corrección de defectos. Estos defectos se dividen en
los que tienen suficiente impacto para justificar una versión incrementada
(versión Delta) y las que pueden corregirse en las siguientes versiones
INICIO
ELABORACION
CONSTRUCCION
TRANSICION
DIAGRAMA

13. Los casos de uso dirigen el proceso. Durante el flujo de trabajo
de los requisitos, los desarrolladores pueden los requisitos en la
forma de casos de uso. Los jefes de proyecto pueden después
planificar el proyecto en términos de los casos de uso con los
cuales trabajan los desarrolladores. Durante el diseño y el
Análisis, los desarrolladores crean realizaciones de casos de uso
en términos de clases y subsistemas. Los componentes se
incorporan en los incrementos, y cada uno de ellos realiza un
conjunto de caso de uso. Por ultimo, los ingenieros de prueba
verifican que el sistema implementado los casos de uso correctos
para los usuarios. Los casos de uso enlazan todas las actividades
del desarrollo y dirigen el proceso de desarrollo.
DIAGRAMA

14. GRACIAS