Resumen de Proceso unificado de desarrollo de Software basado en Capítulos I y III del Libro homónimo de Jacobson, Booch y Rumbaugh. Analisis y Diiseño de Sistemas

1. PROCESO
UNIFICADO
DIRIGIDO POR CASOS DE USO, CENTRADO EN LA
ARQUITECTURA, ITERATIVO E INCREMENTAL.

2. La tendencia actual en el software lleva a la construcción de sistemas más grandes y más
complejos. Esto es debido a que las computadoras son mas potentes cada año.
También lo queremos más rápido, conseguirlo es difícil, el problema se reduce a la dificultad
que afrontan los desarrolladores para coordinar las múltiples cadenas de trabajos de un gran
proyecto de software.
Necesita un proceso que integre las múltiples facetas del desarrollo, necesita un método común,
un proceso que:
 Proporcione una guía para ordenar las actividades de un equipo.
 Dirija las tareas de cada desarrollador por separado y del equipo como un todo.
 Especifique los artefactos que deben desarrollarse.
 Ofrezca criterios para el control y la medición de los productos y actividades del proyecto.
La presencia de un proceso bien definido y bien gestionado es una diferencia esencial entre
proyectos hiperproductivos y otros que fracasan.

3. Proceso Unificado en pocas palabras
• Es un proceso de desarrollo de software.
• Es un marco de trabajo genérico que pude
especializarse para una gran variedad de
software.
• Esta basado en componentes
interconectados a través de interfaces bien
definidas.
• Las tres claves del proceso unificado para
ser único son: dirigido por casos de uso,
centrado en la arquitectura, iterativo e
incremental.

4. Esta dirigido por casos de uso
• Para construir un sistema con éxito debemos conocer lo que sus futuros usuarios necesitan y
desean, el termino usuario no sólo hace referencia a usuarios humanos sino a otros sistemas.
• Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un
resultado importante.
• Los casos de uso representan los requisitos funcionales.
• Puede decirse que una especificación funcional contesta a la pregunta: ¿Qué debe hacer el
sistema? La estrategia de los casos de uso puede describirse añadiendo tres palabras al final de
esta pregunta: ¿…para cada usuario?
• Los casos de uso no son sólo una herramienta para especificar los requisitos, también guían su
diseño, implementación y prueba.
• Aunque es cierto que los casos de uso guían el proceso, no se desarrollan aisladamente.

5. Está centrado en la arquitectura
• El concepto de arquitectura de software incluye los aspectos estáticos y dinámicos.
• La arquitectura es una vista del diseño completo con las características más importantes.
• Los casos de uso y la arquitectura deben equilibrarse para obtener un producto con éxito,
deben evolucionar en paralelo.
• Los arquitectos modelan el sistema para darle una forma, sus funciones son:
 Crear un esquema en borrador, comenzando por la parte que no es especifica de los casos de uso.
 Trabaja con un subconjunto de los casos de uso especificados, aquellos que representan las funciones
claves.
 A medida que los casos de uso se especifican y maduran, se descubre más de la arquitectura.
Esto continua hasta que se considere que la arquitectura es estable.

6. Iterativo e Incremental
• Supone que es un gran esfuerzo que puede durar entre varios meses hasta posiblemente un
año o más. Es practico dividir el trabajo en partes más pequeñas o miniproyectos.
• Para una efectividad máxima, las iteraciones deben estar controladas.
• En cada iteración, los desarrolladores identifican y especifican los casos de uso relevantes, y
crean un diseño.
• Son muchos los beneficios de un proceso iterativo controlado:
 La iteración controlada reduce el coste del riesgo a los costes de un solo incremento.
 Reduce el riesgo de no sacar al mercado el producto en el calendario previsto.
 Acelera el ritmo del esfuerzo de desarrollo en su totalidad.
 Reconoce una realidad que a menudo se ignora – las necesidades del usuario no pueden definirse desde
el principio-

7. La vida del Proceso Unificado
• Se repite a lo largo de una serie de
ciclos que constituyen la vida de un
sistema
• Cada ciclo consta de 4 fases: inicio,
elaboración, construcción y
transición.

8. El producto
• Cada ciclo produce una nueva
versión del sistema, y cada versión es
un producto separado para su
entrega.
• El producto terminado incluye los
requisitos, casos de uso,
especificaciones no funcionales y
casos de prueba.
• Aunque los componentes ejecutables
sean los artefactos más importantes
desde la perspectiva del usuario, no
son suficientes por si solos.

9. Fases dentro del ciclo
• Cada ciclo se desarrolla a lo largo de un tiempo, este
tiempo se divide en 4 fases. Cada fase termina en un
hito, cada hito se determina por la disponibilidad de
un conjunto de artefactos.
• Los hitos tiene muchos objetivos, el más crítico es
tomar las deciciones cruciales antes de que el trabajo
pase a la siguiente fase.
• Esta fase responde a las siguientes preguntas:
 ¿Cuáles son las principales funciones del sistema para sus
usuarios más importantes?
 ¿Cómo podría ser la arquitectura del sistema?
 ¿Cuál es el plan del proyecto y cuánto costará desarrollar
el producto?

10. Un proceso integrado
• Esta basado en componentes.
• Utiliza el nuevo estándar de modelado visual.
• El Proceso Unificado ha establecido un marco de trabajo que integra todas sus
diferentes facetas.
• UML se sostiene sobre 3 ideas básicas:
 Casos de uso.
 Arquitectura.
 Desarrollo iterativo e incremental.

11. Un proceso dirigido por casos de uso
• Los casos de uso han sido adoptados casi
universalmente para la captura de requisitos
de sistemas de software en general, y además
basados en componentes en particular.
• Son la entrada funcional cuando se
identifican y especifican clases, subsistemas e
interfaces.
• Para cada iteración , nos guía a través del
conjunto completo de flujos de trabajo, desde
la captura de requisitos, pasando por el
análisis, diseño e implementación, hasta la
prueba, enlazando estos diferentes flujos de
trabajo.

12. Desarrollo dirigido por casos de uso
• La captura de requisitos tiene 2 objetivos: encontrar los verdaderos requisitos
y representarlos de un modo adecuado para los usuarios, cliente y
desarrolladores.
• El modelo de diseño posee las siguientes características:
 Es jerárquico, pero también contiene relaciones que atraviesan la jerarquía.
 Las relaciones de los casos de uso son estereotipos de colaboraciones.
 El modelo de diseño también es un esquema de la implementación.

13. ¿Por qué casos de uso?
• Las dos razones fundamentales:
 Proporcionan un medio sistemático e intuitivo de capturar requisitos funcionales
centrándose en el valor añadido para el usuario.
 Dirigen todo el proceso de desarrollo debido a que la mayoría de las actividades como
el análisis, diseño y prueba se llevan a cabo partiendo de los casos de uso.

14. Para capturar los requisitos que aportan valor
añadido
• Los casos de uso permiten la identificación del software que cumple los objetivos del
usuario.
• Si comenzamos un sistema sin pensar en los casos de uso que emplean los usuarios, será
difícil decir si esas funciones son importantes o incluso son buenas.
• Aquello que añade un valor negativo o que permite al usuario hacer cosas que no debería
poder hacer no es un caso de uso.
• Los casos de uso son intuitivos. Los usuarios y los clientes no tienen que aprender una
notación compleja.
• El modelo de caso de uso se utiliza, para conseguir un acuerdo con los usuarios y clientes
sobre qué debería hacer el sistema para el usuario.

15. Para dirigir el proceso
• Los casos de uso ayudan a los programadores a encontrar las clases. Las clases se recogen de las
descripciones de los casos de uso a medida que las leen los desarrolladores.
• También ayudan a desarrollar interfaces de usuarios.
• Los casos de uso no solo inician un proceso de desarrollo sino que lo enlazan.
• Son un importante mecanismo para dar soporte a la trazabilidad a través de todos los modelos.

16. Para idear la arquitectura y más…
• Los casos de uso:
 nos ayudan a llevar a cabo el desarrollo iterativo.
 También nos ayudan a idear la arquitectura.
 Se utilizan como punto de partida para escribir el manual de usuario.

17. La captura de los casos de uso
• Nos centramos, en la captura de requisitos funcionales en la forma de casos
de uso, aunque también es necesario capturar otros tipos de requisitos.
• Durante el flujo de trabajo delos requisitos identificamos las necesidades de
usuarios y clientes como requisitos.
• Los requisitos funcionales se expresan como casos de uso en un modelo de
casos de uso, y además los requisitos o bien se “adjuntan” a los casos de uso
a los que afectan, o bien se guardan en una lista aparte o se describen de
alguna otra forma.

18. El modelo de casos de uso representan los
requisitos funcionales
• La mayoría de los sistemas tienen
muchos usuarios, estos se
representan con actores.
• Un diagrama de casos de uso
describe parte del modelo de casos
de uso y muestra un conjunto de
casos de uso y actores con una
asociación entre cada par actor/caso
de uso que interactúan.

19. Los actores son el entorno del sistema
• No todos los actores representan a personas.
• Los actores se comunican con el sistema mediante el envió y recepción de mensajes hacia y desde
el sistema según éste lleva a cabo los casos de uso.
• Podemos encontrar y especificar todos los actores examinando a los usuarios que utilizaran el
sistema y otros sistemas deben interactuar con él.
Los casos de uso especifican el sistema
• Los casos de uso están diseñados para cumplir los deseos del usuario cuando utiliza el sistema.
• Un caso de uso especifica una secuencia de acciones, incluyendo variantes, que el sistema puede
llevar a cabo, y que producen un resultado observable de valor para un actor concreto.

20. Análisis, diseño e implementación para realizar
los casos de uso
• Durante el análisis y el diseño,
transformamos el modelo de caso de uso
mediante un modelo de análisis en un
modelo de diseño.
Creación del modelo de
análisis a partir de los casos de
uso
• El modelo de análisis crece
incrementalmente a medida que se analizan
más y más casos de uso.

21. Una clase que participa en varias realizaciones
de caso de uso en el modelo de análisis

22. Cada clase debe cumplir todos sus roles de
colaboración
• Las responsabilidades de una clase son sencillamente la recopilación de todos
los roles que cumplen en todas las realizaciones de los casos de uso.
• Los desarrolladores responsables de analizar y realizar los casos de uso son
los responsables de especificar los roles de las clases. También deben
asegurar que las clases que realizan los casos de uso con la calidad adecuada.
Creación del modelo de diseño a partir del modelo de análisis
• El modelo de diseño se crea tomando el modelo de análisis como entrada
principal, pero se adapta al entorno de implementación elegido.

23. Realizaciones de caso de uso en los modelos de
análisis y diseño

24. Los subsistemas agrupan a las clases

25. Creación del modelo de implementación a
partir del modelo de diseño

26. Prueba de casos de uso
• El caso de prueba especifica la entrada, los resultados esperados, y otras
condiciones relevantes para verificar el flujo básico del caso de uso.

27. Análisis y Programación de Sistemas
FIGUERO, Araceli