UNIDAD IV MODELOS DE PROCESOS DE SOFTWARE
CONTENIDO Modelos Tradicionales 4.1 Modelo de cascada 4.2 Modelo de espiral 4.3 Modelo incremental 4.4 Proceso de desarrollo unificado 4.5. Proceso de Software Personal Modelos Ă giles 4.6 Programming Xtreme 4.7 SCRUM
4.1. MODELO DE CASCADA
Se denomina modelo en cascada porque su característica principal es que no se comienza con un paso hasta que no se ha terminado el anterior. El modelo en Cascada establece que el software debe ser construido, rigurosamente, a través de una transformación sucesiva de documentos, siguiendo una estrategia lineal de desarrollo. Primero saber qué se quiere y después, cuando se conozca todo lo que se quiere, empezar a construirlo.
MODELO DE CASCADA: Ventajas y Desventajas
VENTAJAS
La Ventaja de este método radica en su sencillez ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.
MODELO DE CASCADA: Ventajas y Desventajas
DESVENTAJAS Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicación del paradigma.
MODELO DE CASCADA: Ventajas y Desventajas
DESVENTAJAS
Normalmente, es difícil para el cliente establecer explícitamente al principio todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos.
MODELO DE CASCADA: Ventajas y Desventajas
DESVENTAJAS El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estará disponible una versión operativa del programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso.
4.2. MODELO DE ESPIRAL (ORIGINAL BOHEM) El modelo espiral propuesto originalmente por Boehm en 1988, es un modelo de proceso de software evolutivo ha sido desarrollado para cubrir las mejores características tanto del ciclo de vida clásico, como de la creación de prototipos, añadiendo al mismo tiempo un nuevo elemento: el análisis de riesgo.
MODELO DE ESPIRAL Análisis de Riesgos
Planificación Análisis de riesgo Análisis de riesgo
Prototipo Operativo
Análisis de riesgo Prototipo 3
Revisión AR
Prototipo 2
Prototipo 1 Plan de Simulaciones, Modelos, Estándares requisitos, Concepto de Plan de ciclo operación Requisitos de vida de Software Plan de Validación Diseño del de producto desarrollo requisitos de software Diseño detallado
Plan de prueba e Integració n
Evaluación del Cliente
Codificación Verificación y validación de Prueba de Unidad diseño Prueba de Integración Prueba de aceptación Implementación
4.2 Modelo de Espiral de Boehm Sommerville, Ian (2005), Ingeniería de software, Ed. Addison Wesley 7ª ed
Ingeniería
REGIONES O SECTORES DEL MODELO EN ESPIRAL
Planificación. Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones, se analizan e identifican los riesgos. Si el análisis de riesgo indica que hay una incertidumbre en los requisitos, se puede usar la creación de prototipos en el cuadrante de ingeniería para dar asistencia tanto al encargado de desarrollo como al cliente.
Análisis de riesgo. El proyecto se revisa y se toma la decisión de si se debe continuar con un ciclo posterior de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto.
Ingeniería. En este sector se desarrolla y se valida. Después de la evaluación de riesgos, se elige un modelo para el desarrollo del sistema.
Evaluación del cliente. El cliente evalúa el trabajo de ingeniería (cuadrante de evaluación de cliente) y sugiere modificaciones. Sobre la base de los comentarios del cliente se produce la siguiente fase de planificación y de análisis de riesgo. En cada bucle alrededor de la espiral, la culminación del análisis de riesgo resulta en una decisión de "seguir o no seguir".
MODELO INCREMENTAL
El modelo incremental aplica secuencias lineales de forma escalonada mientras avanza el tiempo. Corrige la necesidad de una secuencia no lineal de pasos de desarrollo. Cada secuencia lineal produce un incremento del software.
MODELO INCREMENTAL
Requerimientos
Análisis y Diseño
Codificación
Pruebas
Desarrollo
El modelo incremental entrega el software en partes pequeñas, pero utilizables, llamadas “incrementos”. En general, cada incremento se construye sobre aquel que ya ha sido entregado. El modelo incremental se centra en la entrega de un producto operacional con cada incremento. Los primero incrementos son versiones “incompletas” del producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación.
El Proceso Unificado de Desarrollo de Software
¿Qué es RUP? Requisitos del usuario
Proceso de desarrollo de software
Sistema de software
• UP es un proceso de desarrollo de software : – Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quién hace qué, cuándo y cómo). • Objetivos: – Asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles. Dirigido por casos de uso, centrado en la arquitectura, iterativo (mini-proyectos) e incremental (versiones).
Las mejores prácticas • UP pretende implementar las mejores prácticas actuales en ingeniería de software: – – – – – –
Desarrollo iterativo del software Administración de requerimientos Uso de arquitecturas basadas en componentes Modelamiento visual del software Verificación de la calidad del software Control de cambios
Desarrollo iterativo • El software moderno es complejo y novedoso. No es realista usar un modelo lineal de desarrollo como el de cascada. • Un proceso iterativo permite una comprensión creciente de los requerimientos a la vez que se va haciendo crecer el sistema. • UP sigue un modelo iterativo que aborda las tareas más riesgosas primero. • Con esto se logra reducir los riesgos del proyecto y tener un subsistema ejecutable tempranamente.
Administración de requerimientos • UP describe cómo: – Obtener los requerimientos – Organizarlos – Documentar requerimientos de funcionalidad y restricciones – Rastrear y documentar decisiones – Captar y comunicar requerimientos del negocio
• Los casos de uso y los escenarios indicados por el proceso han probado ser una buena forma de captar requerimientos y guiar el diseño, la implementación y las pruebas.
Arquitecturas basadas en componentes • El proceso se basa en diseñar tempranamente una arquitectura base ejecutable. • La arquitectura debe ser: – – – –
Flexible Fácil de modificar Intuitivamente comprensible Promueve la reutilización de componentes
• UP apoya el desarrollo basado en componentes, tanto nuevos como preexistentes.
Modelamiento visual • Modelamiento visual comportamiento de componentes.
de la
la estructura y el arquitectura y los
• Bloques de construcción: – Ocultan detalles – Permiten la comunicación en el equipo de desarrollo – Permiten analizar la consistencia: • entre las componentes • entre diseño e implementación
• UML es la base del modelamiento visual de UP.
Verificación de cualidades • No sólo la funcionalidad es esencial, también el rendimiento y la confiabilidad. • UP ayuda a planificar, diseñar, implementar, ejecutar y evaluar pruebas que verifiquen estas cualidades. • El aseguramiento de la calidad es parte del proceso de desarrollo y no la responsabilidad de un grupo independiente.
Control de cambios • Los cambios son inevitables, pero es necesario evaluar si Êstos son necesarios y rastrear su impacto. • UP indica como controlar, rastrear y monitorear los cambios dentro del proceso iterativo de desarrollo.
Ciclos y fases • UP divide el proceso de desarrollo en ciclos, teniendo un producto al final de cada ciclo. • Cada ciclo se divide en cuatro Fases: – – – –
Inicio Elaboración Construcción Transición
• Cada fase concluye con un hito bien definido donde deben tomarse ciertas decisiones.
Fases de RUP
Fases de RUP: Inicio • Se establece la oportunidad y alcance el proyecto. • Se identifican todas las entidades externas con las que se trata (actores) y se define la interacción a un alto nivel de abstracción: – Identificar todos los casos de uso – Describir algunos en detalle
• La oportunidad del negocio incluye: – – – –
Criterios de éxito Identificación de riesgos Estimación de recursos necesarios Plan de las fases incluyendo hitos
Fases de RUP: Inicio Productos: •
• •
Un documento de visión general: – Requerimientos generales del proyecto – Características principales – Restricciones Modelo inicial de casos de uso (10% a 20 % listos). Glosario.
•
• • •
Caso de negocio: – Contexto – Criterios de éxito – Pronóstico financiero Identificación inicial de riesgos. Plan de proyecto. Uno o más prototipos.
Fases de RUP: Inicio Hito: Objetivos del Ciclo de Vida
Inicio
Elaboración
Construcción
Transición
• Las partes interesadas deben acordar el alcance y la estimación de tiempo y costo. • Comprensión de los requerimientos plasmados en casos de uso.
Fases de RUP: Elaboración • Objetivos: – – – –
Analizar el dominio del problema Establecer una arquitectura base sólida Desarrollar un plan de proyecto Eliminar los elementos de mayor riesgo para el desarrollo exitoso del proyecto
• Visión de “una milla de amplitud y una pulgada de profundidad” porque las decisiones de arquitectura requieren una visión global del sistema.
Fases de RUP: Elaboración Productos: •
•
Es la parte más crítica del proceso: – Al final toda la ingeniería “dura” está hecha – Se puede decidir si vale la pena seguir adelante A partir de aquí la arquitectura, los requerimientos y los planes de desarrollo son estables.
•
•
Ya hay menos riesgos y se puede planificar el resto del proyecto con menor incertidumbre. Se construye una arquitectura ejecutable que contemple: – Los casos de uso críticos – Los riesgos identificados
Fases de RUP: Elaboración Productos: • • •
Modelo de casos de uso (80% completo) con descripciones detalladas. Otros requerimientos no funcio-nales o no asociados a casos de uso. Descripción de la Arquitectura del Software.
• • • •
Un prototipo ejecutable de la arquitectura. Lista revisada de riesgos y del caso de negocio. Plan de desarrollo para el resto del proyecto. Un manual de usuario preliminar.
Fases de RUP: Elaboración Hito:
Arquitectura de Ciclo de Vida
Concepción
Elaboración
Construcción
Transición
• Condiciones de éxito de la elaboración: – ¿Es estable la visión del producto? – ¿Es estable la arquitectura? – ¿Las pruebas de ejecución demuestran que los riesgos han sido abordados y resueltos? – ¿Es el plan del proyecto algo realista? – ¿Están de acuerdo con el plan todas las personas involucradas?
Fases de RUP: Construcción • En esta fase todas las componentes restantes se desarrollan e incorporan al producto. • Todo es probado en profundidad. • El énfasis está en la producción eficiente y no ya en la creación intelectual. • Puede hacerse construcción en paralelo, pero esto exige una planificación detallada y una arquitectura muy estable.
Fases de RUP: Construcción Productos: •
El producto de software integrado y corriendo en la plataforma adecuada.
•
Manuales de usuario.
•
Una descripción del “release” actual.
Fases de RUP: Construcción Hito:
Capacidad Operacional Concepción
Elaboración
Construcción
Transición
• Se obtiene un producto Beta que debe decidirse si puede ponerse en ejecución sin mayores riesgos. • Condiciones de éxito: – ¿El producto está maduro y estable para instalarlo en el ambiente del cliente? – ¿Están los interesados listos para recibirlo?
Fases de RUP: Transición • El objetivo es traspasar el software desarrollado a la comunidad de usuarios. • Una vez instalado surgirán nuevos elementos que implicarán nuevos desarrollos (ciclos). • Incluye: – – – – –
Pruebas Beta para validar el producto con las expectativas del cliente Ejecución paralela con sistemas antiguos Conversión de datos Entrenamiento de usuarios Distribuir el producto
Fases de RUP: Transición Objetivos: • Obtener autosuficiencia de parte de los usuarios. • Concordancia en los logros del producto de parte de las personas involucradas. • Lograr el consenso cuanto antes para liberar el producto al mercado. Concepción
Elaboración
Construcción
Transición
Producto
Definiciones Trabajador • Un trabajador define el comportamiento y las responsabilidades de un individuo. • Es como un “sombrero” que la persona usa durante el proyecto: – Una persona puede tener varios sombreros – Es el rol que desempeña en un momento dado
• Responsabilidades: – Hacer una serie de actividades – Ser el responsable de una serie de artefactos
Definiciones Actividades •
•
Una actividad es una unidad de trabajo que se asigna a un trabajador. Ej.: – Crear o modificar un artefacto Una actividad lleva entre un par de horas y un par de días, involucra un solo trabajador y un número pequeño de artefactos.
•
•
Las actividades se consideran en la planificación y evaluación del progreso del proyecto. Ejemplos: – Planificar una iteración - Administrador de proyecto – Encontrar actores y casos de uso Analista – Revisar el diseño - Revisor de diseño – Ejecutar pruebas de performance - Ing. de pruebas de performance
Asignación de actividades Recurso
Trabajador
Actividad
Pablo
Diseñador
Diseño de Objetos
María
Autor de Casos de Uso
Detallar un Caso de Uso
José
Diseñador de Casos de Uso
Diseñar un Caso de Uso
Silvia
Revisor de Diseño
Revisar el Diseño
Arquitecto
Análisis de Arquitectura Diseño de Arquitectura
Eduardo
Artefactos
•
• •
Elementos de información producidos, modificados o usados por el proceso. Son los productos tangibles del proyecto. Son usados por los trabajadores para realizar nuevas actividades y son el resultado de esas actividades.
•
Ejemplos: – Un modelo, como el modelo de casos de uso o el modelo de diseño. – Un elemento del modelo, como una clase o un caso de uso. – Un documento tal como el Caso del Negocio o la Arquitectura del Software. – Código fuente. – Código ejecutable.
Flujos de trabajo •
•
•
Una lista de actividades, trabajadores y artefactos constituye un proceso. Un flujo de trabajo es una secuencia de actividades que produce un resultado valioso. No siempre es posible representar flujos de trabajo.
Análisis de Arquitectura
Diseño de Arquitectura
Describir Concurrencia
Describir Distribución
Arquitecto Análisis de Casos de Uso
Diseño de Casos de Uso
Diseñador de Casos de Uso Análisis de Objetos
Diseño de Objetos
Diseñador
Revisor de Diseño
Revisar el Análisis
Revisar el Diseño
Revisar la Arquitectura
Flujos de trabajo esenciales Flujos de Trabajo de IngenierĂa
Flujos de Trabajo de Apoyo
Flujos de trabajo • Existen habitualmente problemas de comunicación entre ingenieros de software e ingenieros de negocios. • RUP proporciona un lenguaje y proceso común para estos dos ámbitos. • Para el modelamiento del negocio se usan “business use cases” (casos de uso del negocio): – La forma en que el software dará apoyo al negocio.
Requerimientos • Los desarrolladores y clientes deben acordar qué es lo que el sistema debe hacer: – Relevar requerimientos – Documentar funcionalidad y restricciones – Documentar decisiones – Identificar actores – Identificar casos de uso
Imprimir Informe
Cliente
Operador
Reciclar Administrar Depósito
• Los casos de uso describen la funcionalidad. • Los requerimientos no funcionales se incluyen en una especificación complementaria.
Análisis y diseño •
Descripción de cómo se implementará el sistema: un plano
•
Diseñar y validar la arquitectura es una tarea esencial.
•
Debe: – Ejecutar las tareas y funciones descritas en los casos de uso – Satisfacer todos los requerimientos – Flexible a cambios
•
•
El diseño se centra en la noción de arquitectura.
El modelo de diseño consta de – Clases estructuradas en paquetes – Diseños de subsistemas con interfaces definidas (componentes) – Forma de colaboración entre las clases.
Implementación • Propósito: – Definir la organización del código – Implementar clases y objetos en forma de componentes (fuente, ejecutables, etc.) – Probar las componentes desarrolladas – Integrar las componentes en un sistema ejecutable
Pruebas •
•
Propósito: – Verificar la interacción entre los objetos – Verificar la integración apropiada de componentes – Verificar que se satisfacen los requerimientos – Identificar los defectos y corregirlos antes de la instalación RUP describe como planear y ejecutar estas pruebas.
•
RUP propone probar las componentes desde el principio: – Confiabilidad, funcionalidad y performance
•
Las pruebas de regresión son importantes en desarrollos iterativos.
•
Rational tiene herramientas para automatizar algunas pruebas.
Distribución •
Producir un producto y hacerlo llegar a sus usuarios finales.
•
Incluye varias actividades: – Producir un “release” – Empaquetar el software – Distribuir el software – Instalar el software – Apoyar a los usuarios
•
A veces también incluye: – Realizar pruebas beta – Migración de datos – Aceptación formal
•
La mayor parte de la distribución ocurre durante la transición.
•
Este es uno de los flujos de trabajo menos documentados en RUP.
Administración de proyectos • Es el arte de balancear objetivos contrarios, manejar riesgos y producir software que satisface a clientes y usuarios. • Existen pocos proyectos realmente exitosos. • RUP incluye: – Un framework para manejo de proyectos de software – Guías para planificación, provisión de personal, ejecución y monitoreo de planes – Un framework para manejar riesgos
Administración de configuración y cambios • Forma de controlar los artefactos producidos por las personas que trabajan en el proyecto. • Algunos problemas habituales: – Actualizaciones simultáneas – Múltiples versiones
• RUP da guías para: – Desarrollos en paralelo – Automatizar la construcción – Administrar defectos
Ambiente • Ambiente y herramientas de desarrollo que harán posible llevar a cabo el proyecto. • RUP guía en la configuración de un ambiente de proceso apropiado a cada proyecto.
MODELOS DE PROCESO PERSONALES Y EN EQUIPO Proceso de Software Personal (PSP) y Proceso de Software en Equipo(PSE)
PSP El mejor proceso de Software es el que estรก cerca de la gente que realizarรก el trabajo
Proceso de Software Personal
El proceso personal de software Es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la productividad personal de los programadores o ingenieros de software, en tareas de desarrollo y mantenimiento de sistemas. Está alineado y diseñado para emplearse en organizaciones con modelos de procesos CMMI o ISO 15504. Se puede considerar como la guía de trabajo personal para ingenieros de software en organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad de procesos que implica la medición cualitativa y mejora de procesos.
DESVENTAJAS
Uno de los mayores problemas que tiene es la gran cantidad de datos que hay que tomar. El PSP tiene obsesión por la toma de datos y elaboración de tablas. El PSP se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual. La naturaleza humana y la inercia organizacional, ya que es un reto intelectual y demanda un grado de compromiso (por parte de los profesionales y sus Jefes) que no siempre es posible obtener.
PSP (Personal Software Process) •Proporciona una serie de principios al ingeniero para llevar a cabo un proceso personal disciplinado •Asiste a los ingenieros en la realización de planes precisos •Determina los pasos que los ingenieros deben seguir para mejorar la calidad del producto •Establece bancos de pruebas para medir la mejora del proceso personal, y •Determina el impacto que los cambios del proceso tienen sobre el rendimiento del ingeniero
PSP
En resumen…
El Personal Software Process (PSP) es un proceso diseñado a nivel personal que se aplica a tareas estructuradas Con PSP, los desarrolladores utilizan procesos definidos y medibles. Se toma información de tamaño, tiempo y defectos al momento de realizar el trabajo. Se utilizan los datos para: Planear y monitorear el trabajo. Administrar la calidad de los productos que se producen. Medir y mejorar el desempeño.
Team Software Process
El Team Software Process (TSP) es un proceso de desarrollo para equipos de ingeniería Es una solución basada en procesos para resolver problemas típicos de negocio. Predecibilidad de costo y tiempo. Mejora de productividad y ciclos de desarrollo. Mejora de calidad de productos. A diferencia de otros métodos: Mejora el desempeño tanto de equipos como individuos. Es disciplinado y ágil. Provee beneficios inmediatos y medibles. Acelera las iniciativas de mejora de procesos organizacionales.
TSP (Team Software Process)
PSP y PSE
Equipo 1
Realizar una página web para un negocio de Fotografia, que permita al fotógrafo comercializar su negocio. El cliente no está en Morelia sino en el DF, por lo que la comunicación será continua pero a distancia. La página deberá contar con un catálogo de sus trabajos, contacto, mensajes directo al correo del interesado, etc.
Equipo 2 ď ˝
ď ˝
Programa que permita dar seguimiento al proceso de titulaciĂłn de los alumnos del depto. De Sistemas, que genere reportes estadisticos, y permita mandar correos acerca del seguimiento del proceso a cada alumno. Recuerde que hay diferentes opciones dependiendo del plan de estudios.
Equipo 3
Realizar un software multimedia que permita aprender la lógica programacional, y los fundamentos de POO, que sea interactivo, contenga pruebas de conocimientos con resultados inmediatos (similar a un examen de certificacion) y que permita al alumnos iniciar sus pasos en el área de Programación.
Equipo 4
Realizar un sistema que permita llevar la gestión de la oficina de Docencia del depto. De Sistemas. Las actividades son:
Relación de maestros y sus actividades, materias, indices de reprobación por materia por semestre. Mejores promedios de alumnos por semestre Proceso de titulación de los alumnos y su seguimiento Proceso de Tutorías Círculos de estudio Promoción de cursos para actualización de maestros
MODELOS ÁGILES eXtreme Programming
SCRUM
Modelos Ágiles
Las metodologías ágiles surgen como contraposición a las metodologías clásicas o también llamadas pesadas. Así en 2001 bajo el manifiesto ágil se definieron una serie de valores y principios que deberían cumplir todas las metodologías ágiles aplicadas en el Software. Estos principalmente surgen de la idea de aligerar a los proyectos de software de burocracia, dando más importancia y responsabilidad a las piezas claves de un proyecto, que son el cliente y los programadores. Intentan evitar que ocurran problemas muy comunes con las metodologías pesadas, donde al acabar un proyecto tenemos más documentación que lineas de código.
El Manifesto Ágil – una declaración de valores Individuos Individuos ee interacciones interacciones
sobre
Procesos Procesos yy herramientas herramientas
Software Software que que funciona funciona
sobre
Documentación Documentación exhaustiva exhaustiva
Colaboración Colaboración con con el el cliente cliente
sobre
Negociación Negociación de de contratos contratos
sobre
Seguimiento Seguimiento de de un un plan plan
Responder Responder ante ante el el cambio cambio
Fuente: www.agilemanifesto.org
SCRUM
Scrum es un proceso รกgil que nos permite centrarnos en ofrecer el mรกs alto valor de negocio en el menor tiempo.
Referencias a Scrum ď ˝ ď ˝
Diapositivas (Primer repaso) Diapositivas (Segundo repaso)