Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Proceso unificado de desarrollo de software

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Cargando en…3
×

Eche un vistazo a continuación

1 de 27 Anuncio

Más Contenido Relacionado

Presentaciones para usted (20)

Similares a Proceso unificado de desarrollo de software (20)

Anuncio

Más reciente (20)

Proceso unificado de desarrollo de software

  1. 1. PROCESO UNIFICADO DIRIGIDO POR CASOS DE USO, CENTRADO EN LA ARQUITECTURA, ITERATIVO E INCREMENTAL.
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 21. Una clase que participa en varias realizaciones de caso de uso en el modelo de análisis
  22. 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. 23. Realizaciones de caso de uso en los modelos de análisis y diseño
  24. 24. Los subsistemas agrupan a las clases
  25. 25. Creación del modelo de implementación a partir del modelo de diseño
  26. 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. 27. Análisis y Programación de Sistemas FIGUERO, Araceli

×