algunas trasparencias de I. Sommerville
Transcripción
algunas trasparencias de I. Sommerville
Procesos del software (selección de alguna de las trasparencias de Sommerville) ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Modelos de proceso del software genéricos ● El modelo de cascada • ● Desarrollo evolutivo • ● Las actividades de especificación, desarrollo y validación se llevan a cabo concurrentemente. Ingeniería de software basada en los componentes • ● Se trata de fases de especificación de desarrollo distintas y separadas. El sistema se articula a partir de componentes ya existentes Hay muchas variantes de estos modelos, por ejemplo, un desarrollo formal en el que el proceso de cascada se usa pero la especificación es una especificación formal que se refina a través de varias fases hasta conseguir un diseño implementable. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 2 Modelo de cascada definición De requerimientos Diseño de sistemas de sistemas y software Implementación y prueba de unidades Integración y prueba del sistema Operación y mantenimiento ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 3 Fases del modelo de cascada ● ● ● ● ● ● Definición y análisis de los requerimientos Diseño de sistemas y software Implementación y prueba de unidades Integración y prueba del sistema Operación y mantenimiento El principal inconveniente del modelo de cascada es la dificultad de acomodar el cambio después de que el proceso está en proceso. Una fase tiene que estar completa antes de pasar a la siguiente fase. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 4 Problemas del modelo de cascada ● ● ● ● La Inflexibilidad al dividir el proyecto en distintas etapas hace difícil responder al cambio en los requerimientos del cliente. Entonces, este modelo sólo e apropiado cuando los requerimientos se han entendido bien y los cambios están bastante limitados durante el proceso de diseño. Muy pocos sistemas de negocios tienen requerimientos estables El modelo de cascada se usa principalmente para grandes proyectos de ingeniería de sistemas en los que un sistema se desarrolla en varios sitios. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 5 Desarrollo evolutivo ● Desarrollo exploratorio • ● El objetivo es trabajar con el cliente y evolucionar hacia un sistema final desde un esbozo inicial de especificación. Se debe empezar con unos requerimientos bien comprendidos y añadir nuevos atributos acordes con las propuestas del cliente. Prototipos desechables • El objetivo es entender los requerimientos del sistema. Se debe empezar con requerimientos que no se comprenden del todo hasta clarificar lo que realmente se necesita. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 6 Desarrollo evolutivo Actividades concurrente s Especificación Esbozo de la descripción Desarrollo Validación ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Versión inicial Versiones intermedias Versión final Slide 7 Desarrollo evolutivo ● Problemas • • • ● Falta de visibilidad del proceso; A menudo los sistemas tienen una estructura deficiente; Pueden ser necesarias técnicas especiales especiales (P.Ej.: en lenguajes para la rápida creación de prototipos). Aplicabilidad • • • Para sistemas interactivos pequeños o de tamaño medio; Para partes de grandes sistemas (P.Ej.: la interfaz del usuario); Para sistemas de corta vida ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 8 Iteración de procesos ● ● ● Los requerimientos del sistema SIEMPRE evolucionan en el transcurso de un proyecto, así que la iteración del proceso en el que las primeras etapas son revisadas siempre es parte del proceso para grandes sistemas La iteración puede aplicarse a cualquier modelo de proceso genérico Dos aproximaciones (relacionadas) • • Desarrollo incremental; Desarrollo en espiral. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 9 Desarrollo incremental ● ● ● En lugar de desarrollar el sistema como una sola unidad, el desarrollo y entrega se dividen en incrementos con cada parte de incremento de desarrollo de la funcionalidad requerida Los requerimientos del usuario se priorizan y los requerimientos de mayor prioridad se incluyen en los primeros incrementos. Una vez el desarrollo de un incremento ha comenzado, los requerimientos se congelan aunque los requerimientos para sucesivos incrementos pueden continuar evolucionando. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 10 Desarrollo incremental Definir esbozo de requerimientos Desarrollar incrementos del sistema Asignar requerimientos a los incrementos Validar incrementos Diseñar arquitectura del sistema Integrar incrementos Validar sistema Sistema final Sistema incompleto ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 11 Ventajas del desarrollo incremental ● ● ● ● Los clientes no tienen que esperar hasta que el sistema completo se entregue para sacar provecho de él. El primer incremento satisface los requerimientos más críticos de tal forma que el software está disponible para su uso inmediato. Los primeros incrementos actúan como prototipo para ayudar a obtener los requerimientos para incrementos posteriores. Bajo riesgo de fallar en el proyecto total Los servicios de alta prioridad del sistema tienden a ser más probados. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 12 Programación extrema ● ● ● Una aproximación al desarrollo basado en el desarrollo y entrega de una pequeñísima parte de los incrementos de funcionalidad. Depende de la constante mejora del código, la implicación del usuario en el equipo de desarrollo y la programación por parejas. Tratado en el tema 17 ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 13 Desarrollo en espiral ● ● ● ● el proceso se representa como una espiral en lugar de como una secuencia de actividades con retroceso. Cada vuelta en la espiral representa una fase en el proceso No hay fases fijas tales como la especificación o el diseño – las vueltas en la espiral se escogen dependiendo de lo que se refiere. Los riesgos se valoran explícitamente y se resuelven durante el proceso. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 14 Modelo en espiral para el proceso de Software Determinar objetivos, alternativas y restricciones Evaluar alternativas e identificar y resolver riesgos Análisis de riesgos Análisis de riesgos Análisis de riesgos RREVISIÓN Análisi Prototipo 2 s de riesgo Prototipo 1 s Plan de requerimientos Plan de ciclo de vida Concepto de operación Simulaciones, modelos, pruebas comparativas Requerimiento s del software Plan de desarrollo Validación de requerimientos Planear la siguiente fase Integración y plan de prueba Diseño de V&V servicio ©Ian Sommerville 2004 Prototipo operacional Prototipo 3 Prueba de aceptación Diseño del producto Diseños detallado código Prueba de unidades prueba de integración Desarrollo, verificar producto del siguiente nivel Software Engineering, 7th edition. Chapter 4 Slide 15 Sectores del modelo en espiral ● Definición de objetivos • ● Evaluación y reducción de riesgos • ● Los riesgos se valoran y colocan en un sitio que reduzca los riesgos clave Desarrollo y validación • ● Se definen los objetivos específicos para cada fase. Se escoge un modelo de desarrollo para el sistema que puede ser cualquiera de los modelos genéricos. Planeación • El proyecto se revisa y la siguiente fase de la espiral es planeada. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 16 El Proceso Unificado Racional ● ● Es un modelo de proceso moderno que deriva del trabajo sobre el UML y procesos asociados. Normalmente se describe desde 3 perspectivas • • • Una perspectiva dinámica que muestra las fases en el tiempo; Una perspectiva estática que muestra las actividades de proceso. Una perspectiva práctica que sugiere buenas prácticas para usar durante el proceso. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 17 Modelo de fase RUP Fase de iteración o evolución Origen ©Ian Sommerville 2004 Elaboración construcción Software Engineering, 7th edition. Chapter 4 Transición Slide 18 Fases RUP ● Origen • ● Elaboración • ● Desarrollo y comprensión del ámbito del problema y de la arquitectura del sistema. Construcción • ● Establecer el caso del negocio para el sistema Diseño, programación y prueba del sistema. Transición • Despliegue del sistema en su entorno de explotación. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 19 Buena práctica del RUP ● ● ● ● ● ● Desarrollo del software de forma evolutiva Requerimientos de dirección Usar arquitecturas basadas en componentes. Modelos de software visuales Verificar la calidad del software Controlar los cambios para el software ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 20 Puntos clave ● ● ● ● ● Los procesos de software son las actividades implicadas en la producción y evolución de un sistema de software Los modelos de proceso de software son representaciones abstractas de esos procesos Las actividades generales son la especificación, diseño e implementación, validación y evolución. Los ejemplos incluyen el modelo de cascada, el desarrollo evolutivo y la ingeniería de software basada en los componentes. Los modelos de proceso evolutivos describen los procesos de software como un ciclo de actividades. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 21