Curso Uml 3.1 Modelos De Desarrollo De Software

29,762 views

Published on

Capitulo 3.1 Modelos de desarrollo software del worshop de 20 horas UML y Proceso Unificado.

Published in: Technology
6 Comments
44 Likes
Statistics
Notes
No Downloads
Views
Total views
29,762
On SlideShare
0
From Embeds
0
Number of Embeds
1,050
Actions
Shares
0
Downloads
0
Comments
6
Likes
44
Embeds 0
No embeds

No notes for slide

Curso Uml 3.1 Modelos De Desarrollo De Software

  1. 1. Curso UML Emilio Avilés Ávila http://www.techmi.es
  2. 2. Workshop (20 horas) Workshop UML y Proceso Unificad para empresas y profesionales
  3. 3. Temario <ul><li>Introducción </li></ul><ul><li>Diagramas </li></ul><ul><li>Proceso Unificado </li></ul><ul><ul><li>Modelo de proceso de desarrollo </li></ul></ul><ul><ul><li>Proceso unificado </li></ul></ul>
  4. 4. Tema 3 Proceso Unificado de desarrollo software
  5. 5. Objetivos <ul><li>Introducción </li></ul><ul><li>Diagramas </li></ul><ul><li>Proceso Unificado </li></ul><ul><ul><li>Modelo de proceso de desarrollo </li></ul></ul><ul><ul><li>Proceso unificado </li></ul></ul><ul><li>Definición de modelo de proceso de software. </li></ul><ul><li>Modelos iniciales. </li></ul><ul><li>El modelo lineal/ciclo de vida en cascada o secuencial. </li></ul><ul><li>Procesos evolutivos de software. </li></ul><ul><li>Ensamblado de componentes. </li></ul><ul><li>El modelo DRA. </li></ul><ul><li>El modelo RUP Visión General. </li></ul>
  6. 6. Tema 3.1 Modelo de procesos de ingeniería del software
  7. 7. 3.1 – Modelo de procesos <ul><li>Introducción </li></ul><ul><ul><li>UML se reconoce como un lenguaje de modelado , no como una metodología o un método. </li></ul></ul><ul><ul><li>La diferencia es que el lenguaje de modelado es una notación para expresar las ideas de diseño y análisis orientado a Objetos. </li></ul></ul><ul><ul><li>Un método o proceso software serían los consejos o las líneas a seguir a la hora de realizar el análisis y diseño orientado a objetos. </li></ul></ul>
  8. 8. 3.1 – Modelo de procesos <ul><li>Modelo de proceso del Software </li></ul><ul><ul><li>Criterios de selección: </li></ul></ul><ul><ul><ul><li>Tipo de proyecto </li></ul></ul></ul><ul><ul><ul><li>Métodos y herramientas disponibles </li></ul></ul></ul><ul><ul><ul><li>Controles a utilizar </li></ul></ul></ul><ul><ul><ul><li>Productos comprometidos </li></ul></ul></ul><ul><ul><ul><li>Tendencias en el mercado </li></ul></ul></ul><ul><ul><ul><li>Tipo de Cliente </li></ul></ul></ul><ul><ul><ul><li>Madurez del equipo de desarrollo </li></ul></ul></ul>
  9. 9. 3.1 – Modelo de procesos <ul><li>Modelo de proceso del Software </li></ul><ul><ul><li>Un Modelo adecuado evita… </li></ul></ul>
  10. 10. 3.1 – Modelo de procesos <ul><li>Modelo de proceso del Software </li></ul><ul><ul><li>Modelos iniciales. </li></ul></ul><ul><ul><li>El modelo lineal/ciclo de vida en cascada o secuencial. </li></ul></ul><ul><ul><li>Procesos evolutivos de software. </li></ul></ul><ul><ul><li>Ensamblado de componentes. </li></ul></ul><ul><ul><li>El modelo DRA. </li></ul></ul><ul><ul><li>El modelo RUP Visión General. </li></ul></ul>
  11. 11. 3.1 – Modelo de procesos <ul><li>Modelos iniciales: Codificar-Fijar </li></ul><ul><ul><li>Usado en los primeros días del desarrollo de software </li></ul></ul><ul><ul><li>El proceso implicaba </li></ul></ul><ul><ul><ul><li>Escribir código </li></ul></ul></ul><ul><ul><ul><li>Fijar o ajustar los problemas en el código </li></ul></ul></ul><ul><ul><li>Inconvenientes </li></ul></ul><ul><ul><ul><li>Baja estructura en código </li></ul></ul></ul><ul><ul><ul><li>Muchos ajustes </li></ul></ul></ul><ul><ul><ul><li>Tiempo de desarrollo </li></ul></ul></ul><ul><ul><ul><li>Dependencia a la capacidad del programador </li></ul></ul></ul><ul><ul><ul><li>Se empleaba en proyectos pequeños </li></ul></ul></ul><ul><ul><li>Gracias a este método se descubrieron las deficiencias y motivó la evolución en otros métodos </li></ul></ul>
  12. 12. 3.1 – Modelo de procesos <ul><li>Modelos iniciales: Por Etapas </li></ul><ul><ul><li>Desarrollado en 1956 para enfrentarse con la construcción de SAGE (Semi-AutomatedGroundEnvironment </li></ul></ul><ul><ul><li>Modelo lineal que considera que cada etapa debe ir después de la anterior. </li></ul></ul><ul><ul><li>Hace énfasis en que la información que se obtiene en cada etapa es la que se proporciona a la siguiente. </li></ul></ul><ul><ul><li>Cadena de producción de software. </li></ul></ul>
  13. 13. 3.1 – Modelo de procesos <ul><li>Modelos iniciales: Por Etapas </li></ul><ul><ul><li>Ventajas </li></ul></ul><ul><ul><ul><li>Evita pasar a una fase posterior sin tener terminada la actual. </li></ul></ul></ul><ul><ul><ul><li>Rígidamente dividido. </li></ul></ul></ul><ul><ul><ul><li>Estructura clara. </li></ul></ul></ul><ul><ul><li>Inconvenientes </li></ul></ul><ul><ul><ul><li>Modelo poco productivo. </li></ul></ul></ul><ul><ul><ul><li>Costo alto de identificación de errores en etapas avanzadas. </li></ul></ul></ul><ul><ul><ul><li>Sin resultados hasta el final del proceso. </li></ul></ul></ul>
  14. 14. 3.1 – Modelo de procesos <ul><li>Ciclo de vida en cascada </li></ul><ul><ul><li>También conocido como Ciclo de vida clásico o Modelo lineal </li></ul></ul><ul><ul><li>Desarrollado en 1970 buscando reducir costes y evolucionando con retroalimentación </li></ul></ul><ul><ul><li>Modelo más extensamente utilizado y de los más antiguos, en toda la ingeniería del software. </li></ul></ul><ul><ul><li>Las fases pueden variar en algunos aspectos </li></ul></ul>
  15. 15. 3.1 – Modelo de procesos <ul><li>Ciclo de vida en cascada </li></ul><ul><ul><li>Ventajas e inconvenientes similares al Modelo por etapas excepto la iteratividad . </li></ul></ul><ul><ul><li>En ambos modelos: </li></ul></ul><ul><ul><ul><li>Es difícil plasmar los requisitos. </li></ul></ul></ul><ul><ul><ul><li>Los proyectos no suelen seguir el flujo secuencial. </li></ul></ul></ul><ul><ul><ul><li>Infrautilización del personal. </li></ul></ul></ul><ul><ul><ul><li>El cliente no ve resultados hasta el final del proceso. </li></ul></ul></ul>
  16. 16. 3.1 – Modelo de procesos <ul><li>Modelo orientado a prototipos </li></ul><ul><ul><li>También conocido como Ciclo de vida por prototipos (CVP) o modelo de construcción de prototipos. </li></ul></ul><ul><ul><li>Propuesto en 1988. </li></ul></ul><ul><ul><li>Adecuado cuando se tienen objetivos generales con bajo nivel de requisitos. </li></ul></ul><ul><ul><li>Se utiliza el prototipo como mecanismo para definir requisitos cuando: </li></ul></ul><ul><ul><ul><li>el usuario no es capaz de detallar los requisitos de inicio, o </li></ul></ul></ul><ul><ul><ul><li>el propio equipo técnico tiene dudas de la eficacia de determinadas herramientas, bases de datos, sistemas operativos, lenguajes, etc. </li></ul></ul></ul><ul><ul><li>Cada prototipo se descarta parcial o totalmente. </li></ul></ul>
  17. 17. 3.1 – Modelo de procesos <ul><li>Modelo orientado a prototipos </li></ul>
  18. 18. 3.1 – Modelo de procesos <ul><li>Modelo orientado a prototipos </li></ul><ul><ul><li>Ventajas </li></ul></ul><ul><ul><ul><li>Versión operativa casi desde el inicio. </li></ul></ul></ul><ul><ul><ul><li>Alta integración del usuario con el proceso de desarrollo. </li></ul></ul></ul><ul><ul><ul><li>Coste relativamente bajo para cada versión. </li></ul></ul></ul><ul><ul><ul><li>Cambios de dirección en el desarrollo fáciles de realizar. </li></ul></ul></ul><ul><ul><li>Inconvenientes </li></ul></ul><ul><ul><ul><li>El usuario no valora adecuadamente el trabajo. </li></ul></ul></ul><ul><ul><ul><li>El sistema puede crecer desmedidamente. </li></ul></ul></ul><ul><ul><ul><li>No aplica ingeniería. </li></ul></ul></ul><ul><ul><ul><li>Se confunde el producto final con el prototipo. </li></ul></ul></ul>
  19. 19. 3.1 – Modelo de procesos <ul><li>Desarrollo evolutivo de prototipos </li></ul><ul><ul><li>Muy relacionada con el CVP pero es claramente distinto </li></ul></ul><ul><ul><li>Diferencia fundamental es que el desarrollo evolutivo busca reemplazar el viejo sistema con uno nuevo y el CVP no. </li></ul></ul><ul><ul><li>El prototipo se convertirá en el sistema </li></ul></ul>
  20. 20. 3.1 – Modelo de procesos <ul><li>Desarrollo evolutivo de prototipos </li></ul><ul><ul><li>Ventajas del modelo </li></ul></ul><ul><ul><ul><li>Versión operativa casi desde el inicio </li></ul></ul></ul><ul><ul><ul><li>Alta integración del usuario al desarrollo </li></ul></ul></ul><ul><ul><li>Problemas del modelo </li></ul></ul><ul><ul><ul><li>El usuario no valora adecuadamente el trabajo </li></ul></ul></ul><ul><ul><ul><li>El sistema puede crecer desmedidamente </li></ul></ul></ul><ul><ul><ul><li>No aplica ingeniería </li></ul></ul></ul>
  21. 21. 3.1 – Modelo de procesos <ul><li>Ciclo de vida en espiral </li></ul><ul><ul><li>Es un modelo evolutivo </li></ul></ul><ul><ul><ul><li>Versiones incrementales. Durante las ultimas versiones se produce un sistema cada vez más complejo. </li></ul></ul></ul><ul><ul><ul><li>Cada ciclo define puede definirse como un proyecto. </li></ul></ul></ul><ul><ul><ul><li>Cada inicio de ciclo presupone que el ciclo anterior está concluido. </li></ul></ul></ul><ul><ul><ul><li>Cada ciclo permite más de una iteración en la espiral. </li></ul></ul></ul><ul><ul><ul><li>Adecuado para sistemas grandes. </li></ul></ul></ul><ul><ul><ul><li>Usa prototipos para disminuir riesgos. </li></ul></ul></ul>
  22. 22. 3.1 – Modelo de procesos <ul><li>Ciclo de vida en espiral </li></ul><ul><ul><li>Ventajas </li></ul></ul><ul><ul><ul><li>El cliente evalúa el trabajo en cada ciclo. </li></ul></ul></ul><ul><ul><ul><li>Se llega al sistema final muy rápido. </li></ul></ul></ul><ul><ul><ul><li>Se analiza el momento de salirse del ciclo. </li></ul></ul></ul><ul><ul><li>Inconvenientes </li></ul></ul><ul><ul><ul><li>Salidas tempranas. </li></ul></ul></ul><ul><ul><ul><li>Salidas tardías. </li></ul></ul></ul><ul><ul><ul><li>Difícil convencimiento de clientes grandes. </li></ul></ul></ul><ul><ul><ul><li>Muy bueno y poco probado. </li></ul></ul></ul>
  23. 23. 3.1 – Modelo de procesos <ul><li>Ensamblado de componentes </li></ul><ul><ul><li>Orientado a la reutilización de componentes . </li></ul></ul><ul><ul><li>Los componentes se construyen en base a técnicas orientadas a objetos (cuando no se encuentran en la biblioteca de componentes). </li></ul></ul><ul><ul><li>Se puede utilizar junto con las técnicas anteriores </li></ul></ul>
  24. 24. 3.1 – Modelo de procesos <ul><li>El Modelo DRA: </li></ul><ul><ul><li>DRA: Desarrollo Rápido de Aplicaciones </li></ul></ul><ul><ul><li>Motivación </li></ul></ul><ul><ul><ul><li>Desarrollos que requieren años y resultan de poca calidad </li></ul></ul></ul><ul><ul><ul><li>Necesidad de un enfoque que pase de tiempos medidos en años a tiempos medidos en meses </li></ul></ul></ul><ul><ul><ul><li>El incorporar un mayor número de recursos humanos no incrementa la productividad proporcionalmente </li></ul></ul></ul>
  25. 25. 3.1 – Modelo de procesos <ul><li>El Modelo DRA: </li></ul><ul><ul><li>Metas </li></ul></ul><ul><ul><ul><li>Ofrecer productividad 10 veces mayor a la del promedio </li></ul></ul></ul><ul><ul><ul><li>Ofrecer un conjunto de herramientas y técnicas transferibles a cualquier organización para desarrollar en forma rápida y de manera repetible </li></ul></ul></ul><ul><ul><ul><li>Que la rapidez y calidad del desarrollo no dependa de gurús </li></ul></ul></ul>
  26. 26. 3.1 – Modelo de procesos <ul><li>El Modelo DRA: </li></ul><ul><ul><li>Ámbito </li></ul></ul><ul><ul><ul><li>Aplicable en el desarrollo de aplicaciones de negocios y sistemas de información. </li></ul></ul></ul><ul><ul><ul><li>No aplicable para el desarrollo de software altamente especializado como el de juegos o simuladores. </li></ul></ul></ul>
  27. 27. 3.1 – Modelo de procesos <ul><li>El Modelo DRA: </li></ul><ul><ul><li>Características </li></ul></ul><ul><ul><ul><li>Modelo lineal secuencial orientado a un ciclo rápido de desarrollo. </li></ul></ul></ul><ul><ul><ul><li>Basado en el empleo de componentes para poder entregar un modelo totalmente operativo en un corto periodo de tiempo. </li></ul></ul></ul><ul><ul><ul><li>Es fundamental poder modular la aplicación para que cada equipo pueda trabajar en diferentes modelos. </li></ul></ul></ul>
  28. 28. 3.1 – Modelo de procesos <ul><li>El Modelo DRA: Etapas </li></ul><ul><ul><li>Modelado de gestión : Consiste en determinar los flujos de información para responder a las siguientes preguntas: </li></ul></ul><ul><ul><ul><li>¿Que información conduce los procesos? </li></ul></ul></ul><ul><ul><ul><li>¿Qué información debe generar? </li></ul></ul></ul><ul><ul><ul><li>¿A dónde va esa información? </li></ul></ul></ul><ul><ul><ul><li>¿Quién la genera? </li></ul></ul></ul><ul><ul><li>Modelado de datos : En esta etapa se define los distintos objetos y sus relaciones entre ellos. </li></ul></ul><ul><ul><li>Modelado de procesos : En ella se definen los distintos procesos que transformaran la información de forma que estos procesos permitan añadir, modificar, borrar y recuperar objetos de datos. </li></ul></ul>
  29. 29. 3.1 – Modelo de procesos <ul><li>El modelo DRA </li></ul><ul><ul><li>Generación de la aplicación : </li></ul></ul><ul><ul><ul><li>El DRA se basa en crear software mediante el uso de componentes ya existentes y en el empleo de herramientas automáticas. </li></ul></ul></ul><ul><ul><li>Prueba : </li></ul></ul><ul><ul><ul><li>Poca duración debido a que mucho de los componentes ya están probados. </li></ul></ul></ul>
  30. 30. 3.1 – Modelo de procesos <ul><li>El modelo DRA: Equipos </li></ul>
  31. 31. 3.1 – Modelo de procesos <ul><li>Modelo de métodos formales </li></ul><ul><ul><li>Usa especificación matemática del software. </li></ul></ul><ul><ul><li>Notación matemática rigurosa. </li></ul></ul><ul><ul><li>Enfoque a la identificación de problemas </li></ul></ul><ul><ul><ul><li>Ambigüedad </li></ul></ul></ul><ul><ul><ul><li>Incompletitud </li></ul></ul></ul><ul><ul><ul><li>Inconsistencia </li></ul></ul></ul>
  32. 32. 3.1 – Modelo de procesos <ul><li>Proceso Unificado de Rational </li></ul><ul><ul><li>Basado en casos de uso </li></ul></ul><ul><ul><li>Centrado en la arquitectura </li></ul></ul><ul><ul><li>Iterativo e incremental </li></ul></ul>
  33. 33. 3.1 – Modelo de procesos <ul><li>CMM: Modelo de Madurez Capacidad </li></ul><ul><ul><li>Modelo de referencia desarrollado por el Software Engineering Institute (SEI) ligado a la Universidad de Carnegie-Mellon con la finalidad de: </li></ul></ul><ul><ul><ul><li>Evaluar la madurez de los procesos de desarrollo de software dentro de una organización </li></ul></ul></ul><ul><ul><ul><li>Proponer un plan para mejorar los procesos de desarrollo de software en base a una serie de niveles. </li></ul></ul></ul>
  34. 34. 3.1 – Modelo de procesos <ul><li>CMM: Modelo de Madurez Capacidad </li></ul><ul><ul><li>Premisas generales </li></ul></ul><ul><ul><ul><li>La calidad de un producto software está determinada, en buena medida, por la calidad del proceso usado para desarrollarlo y mantenerlo. </li></ul></ul></ul><ul><ul><ul><li>Un proceso software efectivo integra gente adiestrada y motivada con métodos establecidos y herramientas/equipos apropiados. </li></ul></ul></ul>
  35. 35. 3.1 – Modelo de procesos <ul><li>CMM: Conceptos </li></ul><ul><ul><li>Capacidad de los procesos software </li></ul></ul><ul><ul><ul><li>Describe el rango de resultados esperados que pueden ser alcanzados siguiendo un proceso de software </li></ul></ul></ul><ul><ul><ul><li>Proporciona un medio de predicción de resultados esperados en proyectos subsiguientes </li></ul></ul></ul><ul><ul><li>Rendimiento de los procesos software </li></ul></ul><ul><ul><ul><li>Representa los resultados reales logrados mediante un proceso software. </li></ul></ul></ul><ul><ul><li>Por lo tanto, el rendimiento se centra en los resultados alcanzados, mientras que la capacidad se centra en los resultados esperados. </li></ul></ul><ul><ul><li>Implica un crecimiento potencial de la capacidad de los procesos software. </li></ul></ul>
  36. 36. 3.1 – Modelo de procesos <ul><li>CMM: Conceptos </li></ul><ul><ul><li>Es ámbito en el que un determinado proceso es explícitamente definido, administrado, medido, controlado y hecho efectivo. </li></ul></ul><ul><ul><li>La madurez requiere una cultura organizacional y una infraestructura asociada </li></ul></ul><ul><ul><ul><li>La cultura organizacional es la manera en que se hacen las cosas (desarrolla y mantiene software) en una organización. </li></ul></ul></ul><ul><ul><ul><li>La infraestructura es el conjunto de estructuras, políticas, estándares, adiestramiento, facilidades y herramientas que emplea una organización para desarrollar software. </li></ul></ul></ul><ul><ul><li>Una organización madura es aquella en la que sus procesos de software están institucionalizados, siendo efectivos, utilizables y consistentemente aplicados en toda la organización. </li></ul></ul>
  37. 37. 3.1 – Modelo de procesos <ul><li>CMM: Madurez de una organización </li></ul>
  38. 38. 3.1 – Modelo de procesos <ul><li>CMM: Niveles de Madurez </li></ul><ul><ul><li>La madurez es un indicador de la capacidad del proceso software para lograr sus objetivos </li></ul></ul>
  39. 39. 3.1 – Modelo de procesos <ul><li>CMM: Nivel 1: Inicial </li></ul><ul><ul><li>Características: </li></ul></ul><ul><ul><ul><li>Ausencia de gestión en los proyectos. </li></ul></ul></ul><ul><ul><ul><li>El proceso de software es cambiante e irregular: abandono los planes  dedicación a la codificación y las pruebas. </li></ul></ul></ul><ul><ul><ul><li>Los planes, estimaciones y calidad son impredecibles. </li></ul></ul></ul><ul><ul><ul><li>El rendimiento depende de la capacidad individual de los miembros del grupo. </li></ul></ul></ul><ul><ul><ul><li>Se establecen programas de formación del personal de desarrollo y mantenimiento. </li></ul></ul></ul><ul><ul><ul><li>Sistema caótico. </li></ul></ul></ul><ul><ul><li>Resultados: </li></ul></ul><ul><ul><ul><li>Productividad y calidad escasa. </li></ul></ul></ul><ul><ul><ul><li>Riesgo máximo. </li></ul></ul></ul>
  40. 40. 3.1 – Modelo de procesos <ul><li>CMM: Nivel 2: Repetible </li></ul><ul><ul><li>Características: </li></ul></ul><ul><ul><ul><li>Los procesos de software son estables y repetibles. </li></ul></ul></ul><ul><ul><ul><li>La organización establece políticas de gestión de proyectos y procesos. </li></ul></ul></ul><ul><ul><ul><li>La planificación se basa en proyectos similares. </li></ul></ul></ul><ul><ul><ul><li>Existen estándares definidos y exigidos. </li></ul></ul></ul><ul><ul><ul><li>El proceso se enmarca en un sistema de gestión de proyectos basado en experiencias pasadas. </li></ul></ul></ul><ul><ul><ul><li>Se establecen los proceso de gestión del proyecto para hacer seguimiento de la panificación del coste y de la funcionalidad. </li></ul></ul></ul><ul><ul><li>Resultados: </li></ul></ul><ul><ul><ul><li>Productividad y calidad baja. </li></ul></ul></ul><ul><ul><ul><li>Riesgo alto. </li></ul></ul></ul>
  41. 41. 3.1 – Modelo de procesos <ul><li>CMM: Nivel 3: Definido </li></ul><ul><ul><li>Características: </li></ul></ul><ul><ul><ul><li>Los procesos son definidos: estandarizados, documentados e institucionalizados. </li></ul></ul></ul><ul><ul><ul><li>Los procesos de ingeniería y gestión son estables y se integran en uno. </li></ul></ul></ul><ul><ul><ul><li>Existe un entendimiento común de los procesos, funciones y responsabilidades. </li></ul></ul></ul><ul><ul><ul><li>La organización mantiene un grupo dedicado a la definición, mejora y difusión del proceso de ingeniería de software. </li></ul></ul></ul><ul><ul><li>Resultados : </li></ul></ul><ul><ul><ul><li>Productividad y calidad media. </li></ul></ul></ul><ul><ul><ul><li>Riesgo medio. </li></ul></ul></ul>
  42. 42. 3.1 – Modelo de procesos <ul><li>CMM: Nivel 4: Gestionado </li></ul><ul><ul><li>Características: </li></ul></ul><ul><ul><ul><li>Los procesos son medibles o cuantificables. </li></ul></ul></ul><ul><ul><ul><li>La productividad y la calidad se miden y registran para cada proyecto de la organización. </li></ul></ul></ul><ul><ul><ul><li>Se fijan metas cuantitativas de la calidad del software. </li></ul></ul></ul><ul><ul><ul><li>Mediante el uso de métricas de software, se crea una base cuantitativa para la evaluación y estimación en proyectos futuros. </li></ul></ul></ul><ul><ul><li>Resultados : </li></ul></ul><ul><ul><ul><li>Productividad y calidad alta. </li></ul></ul></ul><ul><ul><ul><li>Riesgo mínimo. </li></ul></ul></ul>
  43. 43. 3.1 – Modelo de procesos <ul><li>CMM: Nivel 5: Optimizado </li></ul><ul><ul><li>Características: </li></ul></ul><ul><ul><ul><li>Los procesos se mejoran continuamente. </li></ul></ul></ul><ul><ul><ul><li>La organización busca lograr el nivel máximo de capacidad. </li></ul></ul></ul><ul><ul><ul><li>Se incorporan nuevas tecnologías y métodos para mejorar los procesos. </li></ul></ul></ul><ul><ul><li>Resultados : </li></ul></ul><ul><ul><ul><li>Productividad y calidad total. </li></ul></ul></ul><ul><ul><ul><li>Riesgo nulo. </li></ul></ul></ul>
  44. 44. 3.1 – Modelo de procesos <ul><li>Niveles de madurez: </li></ul><ul><ul><li>Consecuencia de incremento en niveles </li></ul></ul><ul><ul><ul><li>La visibilidad de un proyecto (¿En que parte del proyecto estamos?) se incrementa a medida que se incrementa el nivel de madurez. </li></ul></ul></ul><ul><ul><ul><li>La diferencia entre resultados deseados y alcanzados decrece a medida que se incrementa el nivel de madurez. </li></ul></ul></ul><ul><ul><ul><li>Los tiempos de desarrollo decrecen y la productividad y calidad aumentan en los niveles de mayor madurez. </li></ul></ul></ul>
  45. 45. 3.1 – Modelo de procesos <ul><li>Niveles de madurez: </li></ul><ul><ul><li>Procesos o áreas claves por nivel </li></ul></ul>
  46. 46. 3.1 – Modelo de procesos <ul><li>Niveles de madurez: </li></ul><ul><ul><li>Consecuencias en una organización de sucesos comunes: </li></ul></ul>
  47. 47. Conclusiones <ul><li>Introducción </li></ul><ul><li>Diagramas </li></ul><ul><li>Proceso Unificado </li></ul><ul><ul><li>Modelo de proceso de desarrollo </li></ul></ul><ul><ul><li>Proceso unificado </li></ul></ul><ul><li>Definición de modelo de proceso de software. </li></ul><ul><li>Modelos iniciales. </li></ul><ul><li>El modelo lineal/ciclo de vida en cascada o secuencial. </li></ul><ul><li>Procesos evolutivos de software. </li></ul><ul><li>Ensamblado de componentes. </li></ul><ul><li>El modelo DRA. </li></ul><ul><li>El modelo RUP Visión General. </li></ul>

×