Descargar como PDF, PPTX
Más contenido relacionado
Similar a Modelo de desarrollo de software
Modelo de desarrollo de software
- 1. UNIDAD IV I-2013 Modelos dedesarrollo de software Prof. Yaskelly Yedra INGENIERÍA DE SOFTWARE Actividades en el proceso de desarrollo de software
- 2. 2 Modelo de procesode DS 1. Modelo secuencial 2. Modelo de proceso incremental 3. Modelo de proceso evolutivo 4. Modelos basados en transformaciones 5. Modelos especializados en proceso 6. Proceso Unificado (PU) Modelo en Cascada
- 3. 3 Modelo en Cascada Encadenamientosecuencial de las actividades Cada etapa produce documentos que son la entrada a la siguiente. Para desarrollar una etapa debe concluirse la anterior. El modelo original no se adapta a ciertas aplicaciones. Los costos al descubrir errores en etapas avanzadas son muy altos (es rígido). Se incorporan variantes al modelo.
- 4. 4 Validación Instalación, Explotación Test ypruebas previas a la Operación Operación y Mantenimiento Estudio de Viabilidad Análisis Especificación Requisitos del Software Diseño Especificación de diseño Diseño Preliminar y Detallado Codificación Aplicación Codificación y Depuración A alguien se le ha ocurrido la Brillante idea de Informatizar ¿? Investigación Inicial, Identificación de Necesidades, Encuesta, etc. Requisitos del Sistema Modelo en Cascada
- 5. 5 Definición de Requisitos Diseño delSoftware y del Sistema Implementación y Prueba de unidades Integración y Prueba del Sistema Operación y Mantenimiento Modelo en Cascada • Separa y secuencia las fases, (no es estrictamente secuencial, a veces se solapan las etapas) • También se le conoce como “modelo lineal secuencial” o “ciclo de vida clasico”
- 6. 6 Modelo en Cascada Definición Análisis Diseño Desarrollo Pruebas Mantenim. Definiciónde requisitos: • Las restricciones y metas del sistema se definen a partir de la interacción con el interesado. • Se comprende la naturaleza de la aplicación y el dominio de información, así como su funcionalidad, rendimiento e interconexión • Se reúnen todos los requisitos que debe cumplir el software
- 7. 7 Modelo en Cascada Definición Análisis Diseño Desarrollo Pruebas Mantenim. Seconcentra en cuatro características básicas: Estructura de datos Arquitectura del software Representaciones de interfaz Detalle procedimental (algoritmo)
- 8. 8 Modelo en Cascada Definición Análisis Diseño Desarrollo Pruebas Mantenim. •Se llama también Implementación • Generación de código entendible por la máquina • Actualmente se investiga mucho sobre la manera de generar código automáticamente
- 9. 9 Modelo en Cascada Definición Análisis Diseño Desarrollo Pruebas Mantenim. •Proceso de depuración de programas • Chequear la validez de las sentencias • Pruebas para detectar errores, asegurando que a partir de los datos de entrada si se genere la salida deseada
- 10. 10 Modelo en Cascada Definición Análisis Diseño Desarrollo Pruebas Mantenim. •Corrección de errores no detectados en la etapa de pruebas • Posibles mejoras funcionales debidas a nuevos requisitos del cliente • En esta fase se vuelven a aplicar todas las etapas anteriores sobre el software existente
- 11. 11 Modelo en cascada:ventajas-desventajas El gran problema de este modelo es la dificultad de realizar cambios después que el proceso ha avanzado Partición inflexible del proyecto en etapas Dificultad de responder a los cambios de los requisitos del cliente Se retrasa la localización y corrección de errores Inflexibilidad del modelo: dificultad para responder a cambios en los requisitos Este modelo es apropiado cuando los requisitos están bien definidos
- 12. 12 Modelo de procesode DS 1. Modelos secuencial 2. Modelo de proceso incremental 3. Modelo de proceso evolutivo 4. Modelos basados en transformaciones 5. Modelos especializados en proceso 6. Proceso Unificado (PU) Modelo Incremental Modelo DRA
- 13. 13 Modelo de ProcesoIncremental Aplica el enfoque del modelo en cascada, pero aplicado en forma iterativa Cada secuencia lineal produce incrementos que agregan funcionalidades adicionales o mejoras al sistema Cada etapa debe cumplir con sus requisitos Incrementos parciales de la herramienta completa las diferentes versiones del proyecto El modelo de proceso incremental, al igual que la construcción de prototipos y otros enfoques evolutivos, es iterativo por naturaleza.
- 14. 14 Modelo de ProcesoIncremental Incremento 2 Incremento n ... ... ... ... Análisis Diseño Código Pruebas Análisis Diseño Código Pruebas Análisis Diseño Código Pruebas Incremento 1 Entrega del 1er incremento Entrega del 2do incremento Entrega de n-ésimo incremento
- 15. 15 Modelo de ProcesoIncremental Ventajas: Los clientes no tienen que esperar hasta que el sistema se entregue completamente para comenzar a hacer uso de él. Los clientes pueden usar los incrementos iniciales como prototipo para precisar los requisitos posteriores del sistema. Minimización del riesgo de falla en el proyecto porque los errores se van corrigiendo progresivamente. Desventaja: Adaptación de los requisitos del cliente para lograr incrementos pequeños (no mas de 20.000 líneas de código) que añadan funcionalidad al sistema. Nota: Una evolución de este enfoque se conoce como Programación Extrema (XP-Extreme Programming).
- 16. 16 Modelo de procesode DS 1. Modelos secuencial 2. Modelo de proceso incremental 3. Modelo de proceso evolutivo 4. Modelos basados en transformaciones 5. Modelos especializados en proceso 6. Proceso Unificado (PU) Modelo Incremental Modelo DRA
- 17. 17 Modelo de DesarrolloRápido de Aplicaciones (DRA) Basado en el Modelo en Cascada, pero con una aplicación más rápida, basada en componentes o generación de código. Modelo llevado a cabo por varias equipos de trabajo que siguen las etapas del proceso de manera simultanea. Modelo aplicable a la construcción de sistemas de información fácilmente modularizables. El Modelo DRA necesita clientes y desarrolladores comprometidos con el proceso. Varios equipos de desarrolladores de software trabajan en paralelo sobre diferentes funciones del sistema
- 18. 18 Modelo de DesarrolloRápido de Aplicaciones (DRA) Equipo No. 1 Equipo No. 2 Equipo No. N.. Comunicación Planeación Modelado Modelado del negocio Modelado de los datos Modelado del proceso Modelado Modelado del negocio Modelado de los datos Modelado del proceso Modelado Modelado del negocio Modelado de los datos Modelado del proceso 60-90 días Despliegue Integración Entrega Retroalimentación Construcción Reutilización de componentes Generación automática de código Pruebas Construcción Reutilización de componentes Generación automática de código Pruebas Construcción Reutilización de componentes Generación automática de código Pruebas
- 19. 19 Modelo de DesarrolloRápido de Aplicaciones (DRA): Desventajas No funciona para proyectos a grandes escala, necesitaría suficiente RRHH para crear el número correcto de equipos. Si los desarrolladores y clientes no se comprometen con las actividades necesarias para completar el sistema en un marco de tiempo muy breve, el proyecto DRA fallaría. Si un sistema no se puede modular en forma apropiada, la construcción de los componentes para el DRA será problemática El DRA sería inapropiado cuando los riesgos técnicos son altos (integración de nuevas tecnologías)
- 20. 20 Modelo de procesode DS 1. Modelos secuencial 2. Modelo de proceso incremental 3. Modelo de proceso evolutivo 4. Modelos basados en transformaciones 5. Modelos especializados en proceso 6. Proceso Unificado (PU) Construcción de prototipos Modelo espiral Modelo de desarrollo concurrente
- 21. 21 Los modelos evolutivosse caracterizan porque permiten a los ingenieros del software, desarrollar de manera iterativa, nuevas versiones del software cada vez más completas Las actividades de especificación, desarrollo y validación se entrelazan en vez de separarse, esto permite una rápida retroalimentación entre ellas Existen dos tipos de desarrollo evolutivos: Desarrollo exploratorio Prototipos desechables Desarrollo Evolutivo: Prototipado
- 22. 22 Desarrollo exploratorio (prototipadoexploratorio o evolutivo) El objetivo es trabajar con clientes hasta evolucionar a un sistema final, a partir de una especificación inicial El sistema empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente Prototipaje desechable Persiguen objetivos más bien de exploración, por lo que poseen un corto ciclo de vida. Permiten crear opciones individuales de requisitos, diseño e implementación repentinas, de modo de satisfacer un nuevo requerimiento para luego ser desechado. La razón de su empleo radica en aprender lecciones necesarias a un costo mínimo. Desarrollo Evolutivo: Prototipado
- 23.
- 24. 24 Recolección y refinamiento de requisitos Diseño Rápidode la aplicación Construcción de prototipos El cliente evalúa el prototipo Desarrollo del producto final Desarrollo Evolutivo: Prototipado
- 25. 25 El proceso noes visible Los administradores tienen que hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión del sistema. A menudo los sistemas tienen una estrategia definida Los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en él se convierte cada vez en una tarea difícil y costosa. Desarrollo Evolutivo: Prototipado Desventajas
- 26. 26 Desarrollo Evolutivo: Prototipado Ventajas Sedetectan malos entendidos entre los desarrolladores y los usuarios Se detectan servicios no detectados antes Dificultades de uso o servicios confusos pueden ser identificados y refinados Staff de desarrollo de software puede encontrar requisitos incompletos o inconsistentes con el desarrollo del prototipo El prototipo sirve como una base de la especificación para la producción de un sistema de calidad
- 27. 27 Desarrollo Evolutivo: Prototipado Problemas Poca visibilidad en el proceso Los sistemas están pobremente especificados Se requieren habilidades especiales. Aplicabilidad Para sistemas interactivos pequeños o medianos. Para partes de sistemas grandes (p.ej. la interfaz de usuario). Para sistemas de corta vida.
- 28. 28 Modelo de procesode DS 1. Modelos secuencial 2. Modelo de proceso incremental 3. Modelo de proceso evolutivo 4. Modelos basados en transformaciones 5. Modelos especializados en proceso 6. Proceso Unificado (PU) Construcción de prototipos Modelo espiral Modelo de desarrollo concurrente
- 29. 29 Modelo en Espiral Conjugala naturaleza iterativa de la construcción de prototipos con los aspectos controlados y sistemáticos del Modelo en Cascada. Se desarrolla en una serie de entregas evolutivas, puede ser en forma de documento o prototipo. Durante las ultimas iteraciones se produce versiones cada vez más completas Se divide en un conjunto de actividades del marco de trabajo que define el equipo de desarrollo de IS
- 30. 30 Modelo en Espiral Proveeuna visión del proceso que soporta la gestión de riesgos. RIESGO: circunstancia potencialmente adversa que puede impactar al proceso y al producto GESTION DE RIESGOS: disciplina que identifica, trata y elimina los potenciales riesgos Se centra en identificar y eliminar los riesgos en el desarrollo de software Es cíclico y en cada nivel se asegura mayor robustez, mientras que disminuye su grado de riesgo
- 31. 31 El proceso serepresenta como una espiral en lugar de una secuencia de actividades Cada vuelta en la espiral representa una fase en el proceso Ninguna fase es fija, tal como la especificación o el diseño - las vueltas en la espiral son elegidas dependiendo lo que se requiera Se evalúan los riesgos explícitamente y se resuelven a lo largo del proceso Modelo en Espiral
- 32. 32 Fases del Modelode Espiral Planteamiento de Objetivos Se identifican los objetivos específicos para cada fase del proyecto. Identificación y reducción de riesgos. Los riesgos clave se identifican y analizan, y la información sirve para minimizar los riesgos. Desarrollo y Validación. Se elige un modelo apropiado para la siguiente fase del desarrollo. Planeación. Se revisa el proyecto y se trazan planes para la siguiente ronda del espiral.
- 33. 33 33 I Identifica Objetivos, alternativas, restricciones II Evalúa alternativas, identifica y resuelve riesgos IV Revisiónde resultados y Planificación de la siguiente fase III Desarrolla, verifica requisitos, plan del ciclo de vida Análisis de riesgo Prototipo 1 Prototipo 2 Prototipo 3 PrototipoAnálisis de riesgo Análisis de riesgo Análisis de riesgo Diseño detallado Plan de desarrollo Integración y plan de test Validación del diseño Diseño requisitos Validación de req. Código Test Unitario Integración y test Simulación, modelación Elmodeloespiral progreso Incepción liberación
- 34. 34 Ventajas del Modelode Espiral Ventajas Centra su atención en la reutilización de componentes y eliminación de errores en información descubierta en fases iniciales. Útil para proyectos grandes. Permite usar el prototipado en todas las etapas de la evolución para reducir el riesgo. Mantiene el enfoque sistemático de los pasos sugeridos por el modelo lineal secuencial, pero lo incorpora dentro de un marco iterativo más real.
- 35. 35 Ventajas del Modelode Espiral Desventajas Requiere de experiencia en la identificación de riesgos. Requiere refinamiento para uso generalizado Difícil de convencer a los clientes de que es controlable. Requiere mucha habilidad para el análisis de riesgos y de esta habilidad depende su éxito. No ha sido utilizado tanto como el lineal secuencial o el de prototipos. Se necesita mucha experiencia
- 36. 36 Ventajas del Modelode Espiral Evolución del Modelo Espiral Para aplicaciones basadas en web
- 37. 37 Modelo de procesode DS 1. Modelos secuencial 2. Modelo de proceso incremental 3. Modelo de proceso evolutivo 4. Modelos basados en transformaciones 5. Modelos especializados en proceso 6. Proceso Unificado (PU) Construcción de prototipos Modelo espiral Modelo de desarrollo concurrente
- 38. 38 Modelo de DesarrolloConcurrente Provee una meta descripción del proceso de software Mientras que en el Espiral la principal contribución es que las actividades del software ocurran repetidamente, en el Concurrente es la capacidad de describir las múltiples actividades del software que ocurren simultáneamente. Dado que los requisitos cambian, es muy probable que una vez haya comenzado la fase de diseño, sea necesario incorporar cambios. En estos casos NO se debe detener el diseño, sino que se debe continuar “si es posible” al mismo tiempo que se modifican los requisitos. En este modelo, diversas actividades pueden estar ocurriendo concurrentemente, pero se encuentran en diferentes estados.
- 39. 39 Modelo de DesarrolloConcurrente Ninguna Bajo Desarrollo Cambios en espera Bajo Revisión Bajo Modificación En línea base Realizado Representa un estado de una actividad de IS Actividad de análisis
- 40. 40 Modelo de procesode DS 1. Modelo secuencial 2. Modelo de proceso incremental 3. Modelo de proceso evolutivo 4. Modelos basados en transformaciones 5. Modelos especializados en proceso 6. Proceso Unificado (PU)
- 41. 41 Harramientas CASE Acrónimo deComputer Aided Software Engineering (Ingeniería del software asistida por ordenador). Tecnología software que proporciona la automatización de las tareas de desarrollo, mantenimiento y dirección del software. El CASE proporciona un conjunto de herramientas bien integradas que ahorran trabajo, enlazando y automatizando todas las fases del ciclo de vida del software. Ejemplos de CASE Herramientas de diagramación Diccionario de datos Herramientas de validación de especificaciones Generadores de código Generadores de documentación
- 42. 42 Surge como consecuenciade la aparición del CASE y de los generadores de código. Este ciclo de vida puede considerarse como una serie de transformaciones: El objetivo del sistema se transforma en especificaciones de requisitos. Las especificaciones de requisitos se transforman en especificaciones de diseño. Las especificaciones de diseño se transforman en código. Modelo Basado en Transformaciones
- 43. 43 Modelo Basado enTransformaciones Ventajas Posibilidad de comprobación de errores en etapas iniciales del desarrollo. Posibilidad de realizar el mantenimiento a nivel de especificación, evitando tener que modificar un código que esté pobremente estructurado después de repetidos procesos de optimización. Soporte para la validación de los requisitos. Soporte de reusabilidad. Potencia la especificación orientada al problema.
- 44. 44 Modelo Basado enTransformaciones Desventajas Requieren especificaciones iniciales muy detalladas. Restringen el ámbito de la aplicación. Requieren una maduración previa del proceso de desarrollo.
- 45. 45 Modelo de procesode DS 1. Modelos secuencial 2. Modelo de proceso incremental 3. Modelo de proceso evolutivo 4. Modelos basados en transformaciones 5. Modelos especializados en proceso 6. Proceso Unificado (PU) Modelo basado en componentes Modelo de métodos formales
- 46. 46 Modelo Basado enComponentes Se basa en la reutilización de componentes Requiere de una librería de componentes La reutilización puede ser de componentes de especificación, de programas, etc. La reusabilidad permite reducir el tiempo y los costos asociados a la construcción de productos de software Requiere de herramientas de asistencia para las nuevas actividades que se generan.
- 47. 47 Modelo Basado enComponentes La tecnología de objetos proporciona el marco de trabajo técnico para un modelo de proceso basado en componentes para la IS. El paradigma orientado a objetos enfatiza en la creación de clases que encapsulan tanto los datos como los algoritmos que se utilizan para manejar los datos. Si se diseñan e implementan las clases correctamente, podrían ser reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados en computadores.
- 48. 48 Modelo Basado enComponentes El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo en espiral. Es evolutivo por naturaleza y exige un enfoque iterativo para la creación de software. Configura aplicaciones desde componentes preparados de software. El modelo basado en componentes conduce a la reutilización del software, proporcionando beneficios a los ingenieros de software.
- 49. 49 Un sistema estáintegrado a partir de componentes Etapas del proceso Analisis de componentes Modificación de requisitos Diseño del sistema con reuso Desarrollo e integración Modelo Basado en Componentes Análisis de componentes Especificación de requisitos Modificación de requisitos Desarrollo e integración Validación del sistema Diseño del sistema con reutilización
- 50. 50 Ventaja Optimiza lostiempos de respuesta a los requisitos del cliente y facilita la labor del programador pues hay un alto aprovechamiento del código. Facilita mantenimiento del software. Desventaja Puede no tenerse los componentes adecuados para los requisitos del sistema. Si las nuevas versiones de los componentes no están bajo el control de quien los utiliza se pierde parte de la evolución del sistema. Modelo Basado en Componentes
- 51. 51 Modelo Basado enComponentes Evolución del Modelo Espiral aplicado a la reutilización de componentes Planificación Análisis de Riesgo Construcción y adaptación de la ingeniería Evaluación Del Cliente Comunicación con el Cliente Identificar componentes candidatos Construir la iteración del sistema Poner nuevos componentes en la biblioteca Extraer Componentes Si están disponibles Buscar Componentes en biblioteca Extraer Componentes Si No están disponibles
- 52. 52 Modelo de procesode DS 1. Modelos secuencial 2. Modelo de proceso incremental 3. Modelo de proceso evolutivo 4. Modelos basados en transformaciones 5. Modelos especializados en proceso 6. Proceso Unificado (PU) Modelo basado en componentes Modelo de métodos formales
- 53. 53 Modelo de MétodosFormales El proceso de desarrollo se basa en la transformación matemática formal de la especificación del sistema a un programa ejecutable Facilita la verificación de programas a través de un riguroso análisis matemático. La ejecución de este tipo de modelos requiere mucho tiempo y esfuerzo. Especificación formal Definición de requisitos Transformación formal Integración y prueba del sistema
- 54. 54 Modelo de MétodosFormales Ventaja Demostraciones formales de propiedades. Especificaciones sin ambigüedades. Útiles para sistemas críticos, dónde la seguridad debe garantizarse antes que el sistema sea puesto en funcionamiento. Desventaja Difícil especificar algunos aspectos del sistema tales como la interfaz de usuario La ejecución de este tipo de modelos requiere mucho tiempo y esfuerzo. Pocos desarrolladores dominan el algebra y las matemáticas para la especificación formal.
- 55. 55 Modelo de procesode DS 1. Modelos secuencial 2. Modelo de proceso incremental 3. Modelo de proceso evolutivo 4. Modelos basados en transformaciones 5. Modelos especializados en proceso 6. Proceso Unificado (PU) Dirigido por caso de uso Centrado en la arquitectura Iterativo e incremental
- 56. 56 El Proceso Unificado(PU) Quién está haciendo, Qué es lo que está haciendo, Cuándo debe hacerlo, y Cómo obtener un cierto objetivo. trabajadores artefactos fases del proceso encadenamiento de actividades. Define: Modelo, documento, código o pieza de información producido en el proceso de desarrollo de software
- 57. 57 Está basado encomponentes e interfaces bien definidas Utiliza el Lenguaje Unificado de Modelado (UML) Aspectos característicos: – Dirigido por casos de uso – Centrado en la arquitectura – Iterativo e incremental El Proceso Unificado (PU) Ivar Jacobson, Grady Booch, James Rumbaugh, “El Proceso Unificado de Desarrollo Software”, Addison Wesley, 1999
- 58. 58 Caso de uso:Fragmento de funcionalidad que proporciona al usuario/cliente un resultado importante Modelo de casos de uso: Funcionalidad total del sistema ¿Qué debe hacer el sistema … para cada usuario? Guían el proceso de desarrollo Dirigido por casos de uso El Proceso Unificado (PU)
- 59. 59 Describe diferentes vistasdel sistema Incluye los aspectos estáticos y dinámicos más significativos La arquitectura y los casos de uso evolucionan en paralelo Responsable: el arquitecto: Empieza por la parte que no es específica de los casos de uso Trabaja con casos de uso claves Progresa con la especificación de más casos de uso Centrado en la arquitectura El Proceso Unificado (PU) Proyección de la organización y estructura de un sistema enfocándose en aspectos particulares
- 60. 60 Arquitectura: Vistas El ProcesoUnificado (PU) Para modelar un sistema desde diferentes vistas se debe responder: ¿Qué vistas se requiere? Para cada vista: ¿Qué artefactos producir? ¿Con qué notación?
- 61. 61 Se divide eltrabajo en mini-proyectos Cada mini-proyecto es una iteración que resulta en un incremento La iteración Trata un conjunto de casos de uso Trata los riesgos más importantes En cada iteración se persiguen unos objetivos concretos El Proceso Unificado (PU) Iterativo e incremental
- 62. 62 Beneficios de unproceso iterativo controlado: Coste del riesgo a un solo incremento Reduce el riesgo de no sacar el producto en el calendario previsto Acelera el ritmo de desarrollo Se adapta mejor a las necesidades del cliente El Proceso Unificado (PU) Iterativo e incremental
- 63. 63 El Proceso Unificado(PU) Iterativo e incremental Permite desarrollar un sistema a través de refinamientos sucesivos e incorporación de nuevas funcionalidades, creando una solución efectiva, en múltiples iteraciones. Alto nivel de reuso Apendizaje del grupo del proyecto durante el desarrollo del software Adaptación a requisitos cambiantes Mitigación de los riesgos y realización de las pruebas en etapas tempranas del desarrollo del software.
- 64. 64 El Proceso Unificado(PU) Modelado del Negocio Implementación Prueba Entrega Análisis y Diseño Disciplinas Fundamentales Requisitos Fases Elaboración Construcción TransiciónInicio Iteraciones y disciplinas
- 65. 65 El Proceso Unificado(PU) tiempo Inicio Elaboración Construcción Transición Define el alcance y factibilidad del proyecto. (análisis de requisitos). Fases del ciclo de vida
- 66. 66 El Proceso Unificado(PU) tiempo Inicio Elaboración Construcción Transición Planifica el proyecto, especifica las características y la arquitectura base. (Análisis y diseño) Fases del ciclo de vida
- 67. 67 El Proceso Unificado(PU) Fases del ciclo de vida tiempo Inicio Elaboración Construcción Transición Construye el producto (implementación)
- 68. 68 El Proceso Unificado(PU) Fases del ciclo de vida tiempo Inicio Elaboración Construcción Transición Entrega del producto al cliente o a los usuarios.
- 69. 69 El Proceso Unificado(PU) 69 Modelado del Negocio Implementación Prueba Entrega Análisis y Diseño Disciplinas Fundamentales Requisitos Fases Elaboración Construcción TransiciónInicio Iteraciones y disciplinas Esbozar: Modelo de Casos de Uso Especificaciones complementarias Glosario
- 70. 70 El Proceso Unificado(PU) 70 Modelado del Negocio Implementación Prueba Entrega Análisis y Diseño Disciplinas Fundamentales Requisitos Fases Elaboración Construcción TransiciónInicio Iteraciones y disciplinas Refinar: Modelo de Casos de Uso Especificaciones Complementarias Glosario
- 71. 71 El Proceso Unificado(PU) 71 Modelado del Negocio Implementación Prueba Entrega Análisis y Diseño Disciplinas Fundamentales Requisitos Fases Elaboración Construcción TransiciónInicio Iteraciones y disciplinas Esbozar: Modelo de Diseño Documento de la Arquitectura
- 72. 72 El Proceso Unificado(PU) 72 Modelado del Negocio Implementación Prueba Entrega Análisis y Diseño Disciplinas Fundamentales Requisitos Fases Elaboración Construcción TransiciónInicio Iteraciones y disciplinas Refinar: Modelo de Diseño
- 73. 73 El Proceso Unificado(PU) 73 Modelado del Negocio Implementación Prueba Entrega Análisis y Diseño Disciplinas Fundamentales Requisitos Fases Elaboración Construcción TransiciónInicio Iteraciones y disciplinas Esbozar: Modelo de implementación
- 74. 74 El Proceso Unificado(PU) 74 Modelado del Negocio Implementación Prueba Entrega Análisis y Diseño Disciplinas Fundamentales Requisitos Fases Elaboración Construcción TransiciónInicio Iteraciones y disciplinas Refinar: Modelo de implementación
- 75. 75 El Proceso Unificado(PU) Artefactos que se producen
- 76. 76 El Proceso Unificado(PU) Inclusión de la construcción de la interfaz
- 77. 77 Cascada Separa ysecuencia las fases Evolutivo Especificación y desarrollo son intercalados De transformaciones Un modelo formal del sistema es transformado en otro modelo de más bajo nivel de abstracción Basado en componentes El sistema es producto de ensamblaje de componentes Modelo de proceso de DS (conclusiones)
- 78. 78 ¿Qué modelo utilizar? Para sistemas bien comprendidos se puede aplicar el Modelo en Cascada. La fase de análisis de riesgos es relativamente fácil. Con Requisitos estables y sistemas de seguridad críticos, se pueden utilizar Modelos Formales. Con especificaciones incompletas, se puede utilizar el Modelo de Prototipaje. Pueden utilizarse modelos híbridos en distintas partes del desarrollo.
- 79. 79 Modelos de ProcesosHíbridos Los sistemas grandes están hechos usualmente de varios subsistemas. No es necesario utilizar el mismo modelo de proceso para todos los subsistemas. El prototipado es recomendado cuando existen especificaciones de alto riesgo. El modelo de cascada es utilizado en desarrollos bien comprendidos.