Tema II Ciclo de Vida del Software

Transcripción

1 Tema II Ciclo de Vida del Software Procesos de Software

2 Bibliografía Calvo-Manzano, J.A., Cervera, J., Fernández, L., Piattini, M. Aplicaciones Informáticas de Gestión. Una perspectiva de Ingeniería del Software. Rama, 2004 Pressman, R. S., Ingeniería del Software. Un Enfoque Práctico.McGraw- Hill, I. Sommerville, ingeniería del Software. Pearson Addison Wesley. 7ma. Edición. Procesos de Software

3 Índice 1. Qué es el ciclo de vida del Software? 2. La norma Modelos de Ciclo de Vida Procesos de Software 3

4 Ciclo de Vida del SW Concepto Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software IEEE 1074 Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso ISO Procesos de Software 4

5 Qué es el Ciclo de Vida del SW? Es una sucesión de etapas por las que pasa el software en su desarrollo, desde que se concibe la idea hasta que el software deja de utilizarse. Cada etapa lleva asociada una serie de actividades y tareas que se deben realizar, y una serie de documentos que serán la salida de cada una de estas fases y que servirán de entrada a la fase siguiente. Procesos de Software 5

6 Índice 1. Qué es el ciclo de vida del Software? 2. La norma Modelos de Ciclo de Vida Procesos de Software 6

7 Qué es el Ciclo de Vida del SW? Según la norma ISO/IEC Standard 12207:2008: Software life-cycle processes propuesta por la ISO (International Organization for Standardization): Es un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, explotación y mantenimiento de un producto software, abarcando la vida del sistema desde la definición de requisitos hasta que se deja de utilizar Procesos de Software 7

8 MODELO DE PROCESOS DE REFERENCIA ISO/IEC 12207:2008 Proceso de Adquisición Procesos del Contexto del Sistema Procesos de Acuerdo Procesos de Proyecto Procesos de Técnicos Proceso de Planificación del Proyecto Proceso de Definición de Requisitos de Stakeholders Procesos Específicos del Software Procesos de Implementación SW Proceso de Implementación del Software Procesos de Soporte del SW Proceso de Gestión de la Documentación del Software Proceso de Suministro Proceso de Evaluación y Control del Proyecto Proceso de Análisis de Requisitos del Sistema Proceso de Análisis de Requisitos del Software Proceso de Gestión de la Configuración del Software Procesos Organizacionales de Proyecto Proceso de Gestión de la Decisión Proceso de Gestión de Riesgos Proceso de Diseño de la Arquitectura del Sistema Proceso de Implementación Proceso de Diseño de la Arquitectura del Software Proceso de Diseño Detallado del Software Proceso de Aseguramiento de la Calidad del Software Proceso de Verificación del Software Proceso de Gestión del modelo de Ciclo de Vida Proceso de Gestión de la Configuración Proceso de Integración del sistema Proceso de Construcción del Software Proceso de Validación del Software Proceso de Gestión de Infraestructuras Proceso de Gestión de la Información Proceso de Comprobación de Requisitos del Sistema Proceso de Integración del Software Proceso de Revisión del Software Proceso de Gestión de la cartera de Proyectos Proceso de Medición Proceso de Instalación del Software Proceso de Comprobación de Requisitos del Software Proceso de Auditoría del Software Proceso de Gestión de Recursos Humanos Proceso de Apoyo a la Aceptación del Software Proceso de Resolución de Problemas del Software Proceso de Gestión de la Calidad Proceso de Operación del Software Procesos de Reutilización del Software Proceso de Mantenimiento del Software Proceso de Retirada del Software Proceso de Ingeniería del Dominio Proceso de Gestión de Recursos Reutilizables Proceso de Gestión de Programas de Reutilización Procesos de Software

9 Índice 1. Qué es el ciclo de vida del Software? 2. La norma Modelos de Ciclo de Vida Procesos de Software 9

10 Modelos de Ciclo de Vida Qué es un modelo de ciclo de vida? Son estrategias de desarrollo que ayudan a organizar las diferentes etapas y actividades del ciclo de vida del software. Estos modelos ayudan al control y a la coordinación del proyecto. El modelo a utilizar depende del tipo de proyecto. Procesos de Software 10

11 Modelos de Ciclo de Vida Tipos Los modelos genéricos no son descripciones definitivas de procesos de software, son abstracciones útiles utilizadas para explicar diferentes enfoques del desarrollo de software. Modelo en Cascada. Modelos Evolutivos Modelo de Prototipos Modelo En Espiral Modelo Incrementales Modelo Incremental Modelos de Desarrollo Rápido de Aplicaciones Procesos de Software 11

12 Modelo en Cascada (Waterfall) Divide el proceso de desarrollo en un conjunto de etapas secuenciales. Una etapa no puede empezar hasta que no ha terminado la anterior. Al final de cada fase, el personal de desarrollo y los usuarios revisan el progreso del proyecto. En cada fase se genera todo un conjunto de documentos. Es un modelo dirigido por documentos -> Son los productos principales en cada etapa. Procesos de Software 12

13 Modelo en Cascada (Waterfall) Análisis Requerimientos Diseño Implementación Pruebas Mantenimiento Es el modelo más antiguo y más utilizado. Ha sido la base de muchos otros modelos. Procesos de Software 13

14 Modelo en Cascada (Waterfall) Visión profunda del problema desde el punto de vista de los desarrolladores y usuarios. Especifica la información sobre la cual el software se va a desarrollar. Análisis Requerimientos Diseño Implementación Pruebas Mantenimiento Procesos de Software 14

15 Modelo en Cascada (Waterfall) Análisis Requerimientos Permite describir cómo el software va a satisfacer los requerimientos Diseño Implementación Pruebas Mantenimiento Procesos de Software 15

16 Modelo en Cascada (Waterfall) Aquí es donde el Software a ser desarrollado se codifica Análisis Requerimientos Diseño Implementación Pruebas Mantenimiento Procesos de Software 16

17 Modelo en Cascada (Waterfall) Etapa donde el software es probado para verificar que es consistente con las definiciones Análisis Requerimientos Diseño Implementación Pruebas Mantenimiento Procesos de Software 17

18 Modelo en Cascada (Waterfall) Análisis Requerimientos Modificaciones al software producto de errores, adecuaciones, etc. Tipos de Mantenimiento: Correctivo Adaptativo - Perfectivo Diseño Implementación Pruebas Mantenimiento Procesos de Software 18

19 Modelo en Cascada Desventajas Definir todos los requisitos al inicio del proceso no es práctico ya que el cliente añade y modifica según le van surgiendo necesidades durante el proceso de desarrollo. El cliente nunca tiene claro lo que quiere! El cliente no ve el producto en funcionamiento hasta el final del proceso. La validación de los requisitos iniciales no se hace hasta el final. Poca o nula flexibilidad a cambios. Procesos de Software 19

20 Modelo en Cascada Cuándo es conveniente? Cuando tenemos proyectos complejos pero que se entienden y quedan bien definidos desde un comienzo. Cuando el equipo de desarrollo no está muy cualificado o es aún inexperto porque la estructura de trabajo que propone es muy ordenada y ayuda a minimizar esfuerzo. Cuando realizamos una migración de software desde un entorno tecnológico obsoleto. Procesos de Software 20

21 Modelo de Prototipos Un prototipo es una versión limitada del producto que permite a las partes responsables de su creación probarlo en situaciones reales y explorar su uso. Con este modelo hay un acercamiento al cliente. Gracias al prototipo el cliente puede hacerse una idea de cómo está evolucionando el producto y esto ayuda a refinar los requisitos del sistema. Con los prototipos definimos de forma clara y concreta qué quiere el cliente. Los requisitos del sistema. Procesos de Software 21

22 Especificación de Requerimientos y Prototipado Modelo de Prototipos Investigación Preliminar Análisis y Especificación Diseño básico del Prototipo Definición del problema, sus efectos organizacionales. Estudio de factibilidad Diseño y Construcción Evaluación Construcción prototipo Verificación y requerimientos Modificación Modificación del Prototipo Diseño Técnico Programación y Prueba Operación y Mantención Diseño detallado. Rediseño del Prototipo y documentación para programación y mantención Las especificaciones del diseño técnico son implementadas y probadas Instalación del sistema y modificaciones posteriores Procesos de Software 22

23 Modelo de Prototipos Procesos de Software 23

24 Modelo de Prototipos Desventajas El diseño rápido del prototipo hace que los desarrolladores utilicen herramientas que faciliten la rápida generación de código, dejando a un lado aspectos de calidad ( eficiencia, fiabilidad, mantenibilidad del código, etc.). Probablemente no se tendrá un código óptimo. Procesos de Software 24

25 Modelo de Prototipos Cuándo es conveniente? Se recomienda para clientes que quieren ver resultados a corto plazo. Cuando el cliente no sabe lo que quiere y los requisitos no están bien definidos desde el principio. Cuando los requisitos evolucionan muy rápidamente. Para sistemas on-line donde es más importante la parte de la interfaz con el usuario que las funcionalidades del sistema. Se recomienda utilizar este modelo sólo para la especificación de requisitos. Mejor continuar el desarrollo utilizando otro modelo. Procesos de Software 25

26 Modelo en Espiral Es una combinación de los dos anteriores. Es un modelo evolutivo del desarrollo, formado por un conjunto de vueltas de espiral. En las primeras vueltas el SW es un modelo en papel de la especificación de un producto. Aún no funciona. En las sucesivas vueltas, se desarrolla un prototipo. En la últimas iteraciones se obtienen versiones completas del producto. El número de actividades a realizar se incrementa notablemente a medida que nos alejamos del centro de la espiral. Las primera son menos costosas. La evaluación después de cada fase permite cambios. Procesos de Software 26

27 Modelo en Espiral Con este modelo obtenemos el producto final a partir de piezas más pequeñas. Incorpora el factor Riesgo -> es un modelo orientado a riesgos Tiene como objetivo vital pensar en las cosas que pueden ir mal en el desarrollo del software y saber cómo resolverlas. Procesos de Software 27

28 Modelo en Espiral PLANIFICACIÓN Determine objetivos alternativas y restricciones EVALUACIÓN DEL CLIENTE Planea la siguiente fase REVISIÓN Plan de requerimientos Plan del ciclo de vida Plan de Desarrollo Análisis de Riesgos Análisis de Riesgos Análisis de Riesgos Análisis de Riesgos Proto tipo 1 Concepto de Operación Validación de Requerimientos Plan de Integración V &V y Prueba Del Diseño Prueba de Aceptación Servicio Prototipo 2 Requerimientos de SW Prototipo 3 Simulaciones y modelos Prueba de Integración ANÁLISIS DE RIESGOS Evalúe alternativas, identifique y resuelva riesgos Prueba de Unidades Prototipo Operacional Diseño Diseño Detallado Codificación del Producto INGENIERÍA Desarrolla y verifica el siguiente nivel del producto Procesos de Software 28

29 Planificación: Modelo en Espiral Determinar los objetivos. Determinar las alternativas de desarrollo. Analizar las restricciones de cada alternativa. Análisis de riesgos: Fases Ver todos los puntos que pueden fallar. Evaluar las diferentes alternativas. Determinar y resolver o minimizar los riesgos. Identificación de los riesgos para cada alternativa, así como la manera de resolverlos. Procesos de Software 29

30 Ingeniería: Modelo en Espiral Fases Desarrollo del producto. En cada iteración el proyecto se va completando. Evaluación del cliente: Revisión para ver si está de acuerdo, o no, con los resultados obtenidos. Si todo va bien, se pasa a la siguiente fase. En la revisión participan todas las personas y organizaciones que tienen relación con el producto. Se planifica la siguiente vuelta. Previsión de los recursos necesarios. Procesos de Software

31 Es difícil establecer los hitos para determinar si podemos pasar a la siguiente vuelta de espiral. La evaluación de riesgos es una tarea compleja. Es difícil convencer a los clientes que un modelo evolutivo es controlable. No se aconseja para proyectos que tienen pocos riesgos. Demasiado coste. En definitiva, no es un modelo muy real ni claro. Modelo en Espiral Desventajas Procesos de Software

32 Modelo en Espiral Cuándo es conveniente? Cuando tenemos proyectos complejos, donde el problema no está muy bien definido y conlleva una serie de riesgos. Proyectos dinámicos Proyectos innovadores y ambiciosos. Procesos de Software

33 Modelo Incremental Combina elementos del modelo en cascada con la filosofía iterativa del modelo de prototipos Aplica secuencias lineales en forma escalonada mientras progresa el tiempo. Cada secuencia lineal produce un incremento en el software Se centra en la entrega de un producto operacional en cada iteración. Procesos de Software 33

34 Modelo Incremental Incremento 1 Análisis Diseño Código Pruebas Entrega del 1er Incremento Incremento 2 Análisis Diseño Código Pruebas Entrega del 2do. Incremento Incremento 3 Análisis Diseño Código Pruebas Entrega del 3er. Incremento Tiempo de Calendario Procesos de Software 34

35 Modelo Incremental Desventajas Siempre sabemos cuando se comienza, pero nunca cuando se termina El usuario puede seguir definiendo nuevos requerimientos. Procesos de Software

36 Modelo Incremental Cuándo es conveniente? Cuando el personal no está disponible para una implementación completa en la fecha límite que se ha establecido. Proyectos dinámicos Procesos de Software

37 Modelo DRA Resalta un ciclo de desarrollo corto. Es una adaptación a alta velocidad del modelo en cascada. Se logra un desarrollo rápido mediante un enfoque de construcción basado en componentes. Permite crear un sistema completamente funcional dentro de un período corto (60 a 90 días). Procesos de Software 37

38 Modelo DRA Procesos de Software 38

39 Modelo DRA Desventajas Proyectos grandes y escalables, se necesita suficientes recursos humanos para crear los equipos necesarios. Si los desarrolladores y los clientes no se comprometen en el tiempo > DRA falla Si no se puede modular en forma apropiada Cuando los riesgos técnicos son altos Procesos de Software

40 Modelo DRA Cuándo es conveniente? Cuando el problema se puede dividir en componentes. Cuando tengo definidos claramente los requerimientos. Cuando el equipo de desarrollo es grande. Procesos de Software

41 Cuál es el modelo mas adecuado? Cada proyecto de software requiere una forma particular de abordar el problema. Las propuestas comerciales y académicas actuales promueven procesos iterativos donde en cada iteración pueden utilizarse uno u otro modelo dependiendo de criterios. Procesos de Software 41

42 Nivel de efectividad del modelo CRITERIOS MODELO DE PROCESO Codificar y corregir Desarrollo En cascada Desarrollo Prototipos Desarrollo Espiral Desempeño con requisitos y arquitectura no predefinidos Produce software altamente fiable Gestión de riesgos Permite correcciones sobre la marcha Visión del progreso por el Cliente y el Jefe del proyecto Bajo Bajo Bajo Alto Medio Bajo Alto Bajo Bajo Bajo Alto Medio Medio Alto Alto Alto Alto Alto Medio Medio Procesos de Software 42