El documento describe el Proceso Unificado para el desarrollo de software. Este proceso es simple, basado en componentes de software interconectados a través de interfaces. Utiliza UML para los diagramas y es iterativo e incremental, dividiendo el proyecto en pequeñas iteraciones. Cada iteración identifica casos de uso clave y desarrolla la arquitectura correspondiente a través de distintas fases hasta entregar una versión del producto.

1. PROCESO UNIFICADO
De desarrollo de Software.
ANÁLISIS Y DISEÑO DE SISTEMAS – AÑO 2017
1

2. PROCESO UNIFICADO EN POCAS PALABRAS
 Es un proceso de desarrollo de software, simple basado en
componentes software interconectados a través de una
interface.
 Utiliza el UML para sus Esquemas, un lenguaje que produce
dibujos comparables a esquemas de otras disciplinas
técnicas.
 Sus características principales: Orientado a casos de uso,
centrado en la arquitectura y es iterativo e incremental.
2

3. DIRIGIDO POR CASOS DE USO
 Para construir un sistema con éxito debemos conocer lo que
nuestros futuros usuarios necesitan.
 Guían el diseño del sistema desde el inicio con el Análisis,
pasando por el desarrollo la implementación y prueba.
 Se desarrollan a la vez que la arquitectura del sistema.
3

4. CENTRADO EN LA ARQUITECTURA.
 Simulando a la arquitectura de edificios, se describe mediante
diferentes vistas del sistema en construcción.
 Debe haber interacción entre los casos de uso y la
arquitectura. Deben evolucionar en paralelo.
 Una arquitectura ejecutable es una implementación parcial
del sistema, construida para demostrar algunas funciones y
propiedades.
4

5. ES ITERATIVO E INCREMENTAL
 Es práctico dividir el proyecto en partes miniproyectos, de
estas pequeñas iteraciones resultan de un incremento.
 En cada iteración los desarrolladores identifican los casos de
uso más relevantes
 Comprende: casos de uso y escenarios diseños de opciones
de arquitectura, codificación y prueba, evaluación en la
entrega de cada ejecutable acompañado de su respectiva
documentación.
5

6. LA VIDA DEL PROCESO UNIFICADO
 La vida de un proceso consta de ciclos, cada ciclo de cuatro
fases , cada fase en iteraciones y cada ciclo concluye con
una versión del producto.
6

7. EL PRODUCTO
 Cada versión es un producto entregable, es decir que tiene un
cuerpo codificado, se ejecuta y posee manual.
 El producto terminado incluye los requisitos, casos de uso
especificaciones no funcionales, casos de prueba, el modelo de
arquitectura y el visual con UML.
 Es conclusión son todos los elementos mencionado, estos que
permiten a los usuarios utilizar y modificar el sistema a elección.
7

8. FASES DENTRO DE UN CICLO
 Las fases son: Inicio, elaboración, construcción y transición. Cada
fase termina con un HITO y este se determina por la disponibilidad
de un conjunto de artefactos.
 Fase inicio: se desarrolla una descripción del producto final es el
estudio de la oportunidad. Se define funcionalidad y capacidades del
producto.
 Fase Elaboración: Se especifican la mayoría de los casos de uso
del producto y se diseña la arquitectura del programa. Se planifica
contando con los recursos mínimos disponibles para que funcione.
 Fase de Construcción: Se crea el producto y la arquitectura crece
de las bases has tae convertirse en el sistema completo. Se
documenta.
 La fase de Transición. El producto se transforma en Versión Beta,
se corrigen problema e implementa mejoras, se completan los
manuales de usuario.
8

9. DESARROLLO DIRIGIDO POR CASOS DE USO EN
POCAS PALABRAS
 La captura de requisitos tiene dos objetivos: Encontrar los
verdaderos requisitos y representarlos de modo adecuado.
 Cada tipo de usuario es representado por un actor.
 Un caso de uso es una secuencia de acciones que el sistema
lleva a cabo para ofrecer algún resultado de valor para el
actor.
 El modelo de caso de uso en la fase de Análisis y diseño se
transforma en modelo de Análisis y se compone por
clasificadores que se pueden describir con diagramas de
estado.
9

10. MODELO DE ANÁLISIS Y MODELO DE DISEÑO
 Modelo de Análisis: Es una especificación detallada de los
requisitos y funciona como primera aproximación del modelo
de diseño. SE utiliza para crear un modelo robusto y flexible.
Se diferencia del de Diseño porque es un modelo conceptual.
Puede ser transitorio o mantenerse a lo largo del ciclo de vida
del sistema
 Modelo de Diseño: Es jerárquico contiene relaciones
habituales en UML: asociación, generaciones y
dependencias. Es también un esquema de la implementación.
Los Desarrolladores diseñan las clases y las realizaciones de
casos de uso. Implementan las clases diseñadas mediante el
código fuente, a partir del cual se pueden producir los
ejecutables. Los ingenieros verifican que el sistema
implemente la funcionalidad descrita en los casos de uso.
10

11. ¿POR QUÉ CASOS DE USO?
 Las dos razones fundamentales :
 Proporcionan un medio sistemático e intuitivo de
capturar requisitos funcionales que aportan valor
añadido. El modelo de los casos de usos se utiliza para
conseguir un acuerdo con los usuarios y clientes sobre
Que debería hacer el sistema para el usuario.
 Dirigen todo el proceso de desarrollo: no sólo inician el
procesos sino que lo enlazan. Par obtener los casos de
uso correctos hay que hacer un buen trabajo durante el
flujo de los requisitos.
11

12. PARA CAPTURAR LOS REQUISITOS QUE APORTAN VALOR
AÑADIDO
 Los mejores casos de uso son los que añaden mayor valor al
negocio que aplicara el sistema.
 Usar un lenguaje simple hace más fácil la lectura y propuesta
de cambios.
 Involucra a usuarios, clientes y desarrolladores.
 Pensamos en un modelo de casos de uso como una
especificación completa de todas las formas posibles de
utilizar el sistema.
 El modelo de caso de uso nos ayuda a delimitar el sistema.
12

13. LA CAPTURA DE CASOS DE USO
 El modelo de caso de uso representa los requisitos
funcionales: ayuda a clientes, usuarios y desarrolladores a
ponerse de acuerdo de como usar el sistema.
 Los actores son el entorno del sistema: los actores pueden
ser personas, sistemas o hardware externo, se comunican
con el sistemas mediante el envío y recepción de mensajes
 Los casos de uso especifican el sistema: especifica una
secuencia de acciones, que el sistema puede llevar a cabo, y
que producen un resultado de valor para un actor concreto.
También se utilizan como contenedores de requisitos no
funcionales tales como rendimiento, disponibilidad, exactitud
etc.
13

14. ANÁLISIS, DISEÑO E IMPLEMENTACIÓN PARA
REALIZAR LOS CASOS DE USO
 Creación del modelo de análisis a partir de los casos de
uso: en cada iteración elegimos un conjunto de casos de uso
y lo reflejamos en el modelo de análisis.
 Rendimiento adecuado y evolución futura.
 Los diagramas de clases se utilizan generalmente para
mostrar clases y sus relaciones
14

15. ANÁLISIS, DISEÑO E IMPLEMENTACIÓN PARA
REALIZAR LOS CASOS DE USO
 Cada clase debe cumplir todos sus roles de
colaboración: de dedica a la recopilación de todos los roles
para que no haya repeticiones y si se cambia alguna de ellas,
el desarrollador debe verificar que siga cumpliendo sus roles.
Los roles ayudan a mantener la integridad del análisis.
 Creación del modelo de Diseño a partir del Modelo de
Análisis: El modelo de diseño se crea teniendo como primer
entrada el modelo de análisis, se adapta al entorno de
implementación y define clasificadores.
15

16. GRÁFICOS EJEMPLO DE MODELO DE ANÁLISIS
CONVERTIDO A MODELO DE DISEÑO.
16

17. GRAFICO EJEMPLO DE DIAGRAMA DE CLASES EN
EL MODELO DE DISEÑO
17

18. ANÁLISIS, DISEÑO E IMPLEMENTACIÓN PARA
REALIZAR LOS CASOS DE USO
 Creación del modelo de implementación a partir del
modelo de Diseño: Durante el flujo de trabajo de
implementación se desarrolla lo necesario para obtener un
ejecutable. Está formado por componentes que presupone un
contexto de la arquitectura definido por sus interfaces. Se
implementan en un lenguaje de programación orientado a
objetos.
18

19. PRUEBAS DE CASOS DE USO
 Durante la prueba verificamos que el sistema implementa
correctamente su especificación: Esta compuesto por
casos de prueba y procedimientos de prueba.
 Mediante la identificación temprana de los casos de uso, se pueden
ir planificando las actividades de prueba. Existen algunas
herramientas que generan los casos de prueba a partir del modelo
de diseño.
19

20. PARA TERMINAR…
BREVE COMPARACIÓN
Modelo de Análisis
 Conceptual.
 Genérico.
 Tres Estereotipos: Control,
Entidad e interfaz.
 Menos Formal
 Más económico.
 Menos capas
 Dinámico: algo centrado en
secuencias.
 Bosquejo del diseño.
 Trabajo “de a pie”.
 Mantenimiento no sostenido
durante el ciclo de vida.
 Define una entrada esencial.
Modelo de Diseño
 Físico
 No genérico.
 Número indefinido de
estereotipos.
 Más Formal
 Más Caro
 Más capas
 Dinámico: Muy centrado en
secuencias.
 Manifiesto del diseño.
 Creado como programación
visual.
 Mantenimiento sostenido
durante el ciclo de vida.
 Da forma al sistema
manteniendo estructura
definida en el análisis.
20

21. Análisis y diseño de Sistemas
Tema: Proceso Unificado en el desarrollo de
software.
Prof: Andrea Cattaneo.
Alumno: Trejo Sonia A.
2 Año Tec. Analista y Programador de Sistemas.
IES 9-023
Año 2017.
21