Modelando el proceso y el Ciclo de Vida Puntos a tratar El proceso de desarrollar software (organización y disciplina en las actividades) contribuyen a la calidad del software y a la velocidad con que se desarrolla * Significado del Proceso * Modelos de Proceso de Software * Herramientas y Técnicas * Modelado en la Práctica Ing. de Software CH2-1

Significado del Proceso Conjunto ordenado de tareas como Proceso: serie de pasos con actividades, restricciones y recursos que producen una salida de cierto tipo. Cuando el proceso involucra la construcción de un producto, a veces se menciona como Ciclo de Vida (del producto). Ing. de Software

Siguiendo un Proceso Un proceso es un conjunto de procedimientos (receta), organizado para construir productos que satisfacen una seria de objetivos y estándares. Los procesos son importantes porque imponen consistencia y estructura en un conjunto de actividades. Sabemos cómo hacer algo bien y queremos forzar que otros lo hagan de la misma forma. Ing. de Software

Escribiendo un Proceso (un “programa” que otros deben seguir) Prescribir todas las actividades principales Usa recursos sujeto a restricciones Puede estar compuesto de subprocesos Cada actividad tiene un criterio de entrada y otro de salida Las Actividades están organizadas en una secuencia. Establecer los objetivos de cada actividad. Ing. de Software

Modelos de Proceso de Software Prescripciones de la forma en que el desarrollo de software debería llevarse a cabo. Descripciones de la forma en que el desarrollo se lleva a cabo realmente. Cada modelo de desarrollo de software incluye los requerimientos del sistema como entrada y el producto librado al uso como salida. Ing. de Software

Modelo Cascada ANALISIS DE REQUERIMIENTOS DISEÑO DEL SISTEMA DISEÑO DE PROGRAMAS IMPLEMENTACION DE PROGRAMAS PRUEBA UNITARIA Y DE INTEGRACION PRUEBA DEL SISTEMA PRUEBA DE ACEPTACION OPERACION Y MANTENIMIENTO Ing. de Software

(Proceso de desarrollo en la realidad) ANALISIS DE REQUERIMIENTOS DISEÑO DEL SISTEMA DISEÑO DE PROGRAMAS IMPLEMENTACION DE PROGRAMAS PRUEBA UNITARIA PRUEBA DE INTEGRACION PRUEBA DEL LIBRAR AL USO MANTENIMIENTO Ing. de Software

Cascada c/prototipos Validar Verificar PROTOTIPADO ANALISIS DE REQUERIMIENTOS DISEÑO DEL SISTEMA Validar DISEÑO DE PROGRAMAS Verificar IMPLEMENTACION DE PROGRAMAS PROTOTIPADO PRUEBA UNITARIA Y DE INTEGRACION PRUEBA DEL SISTEMA PRUEBA DE ACEPTACION OPERACION Y MANTENIMIENTO Ing. de Software

Modelo V OPERACION Validar requerimientos Y MANTENIMIENTO ANALISIS DE DISEÑO DEL SISTEMA DISEÑO DE PROGRAMAS IMPLEMENTACION DE PROGRAMAS PRUEBA UNITARIA Y DE INTEGRACION PRUEBA DEL PRUEBA DE ACEPTACION OPERACION Y MANTENIMIENTO Verificar diseño Validar requerimientos Ing. de Software

Modelo de Prototipación LISTA DE REVISIONES PROTOTIPAR REQUERIMIENTOS DISEÑO SISTEMA PRUEBA LIBRADO AL USO DEL SISTEMA (a veces informales o incompletos) revisar prototipo revisión de usuario/ cliente Ing. de Software

(orientada al problema) Especificación Operacional: los requerimientos se ejecutan utilizando un producto de software Ejecutar y Revisar ESPECIFICACION OPERACIONAL (orientada al problema) ESPECIFICACION TRANSFORMADA (orientada a la implementación) PRUEBA SISTEMA LIBRADO AL USO REQUERIMIENTOS DEL SISTEMA (a veces informales o incompletos) Ing. de Software

Modelo Transformacional Comparar con requerimientos; actualizar si se necesita REGISTRO FORMAL DEL DESARROLLO Secuencia de transformaciones + sus justificaciones TRANSFORM. N . ESPECIFICACION FORMAL TRANSFORM. 2 PRUEBA TRANSFORM. 1 SISTEMA LIBRADO AL USO REQUERIMIENTOS DEL SISTEMA (a veces informales o incompletos) Ing. de Software

Desarrollo en Fases DESARROLLA- Sistemas en Desarrollo DORES USUARIOS Sistemas en Producción DESARROLLA- DORES USUARIOS Construir liberación 1 Usar Lib. 1 liberación 2 Usar Lib. 2 liberación 3 Usar Lib. 3 Tiempo Ing. de Software

Incrementos e Iteraciones DESARROLLO INCREMENTAL DESARROLLO ITERATIVO Ing. de Software

Modelo Espiral Planificar Determinar Objetivos, Alternativas y Restricciones Evaluar Alternativas y Riesgos start Requirims, plan ciclo/vida Presupto1 Alternativas1 Restriccs1 An. Riesgos1 An.Riesgos2 An.Riesgos3 Análisis de Riesgos4 Restriccs2 Restriccs3 Restriccs4 Prespto2 Prespto3 Prespto4 Alternativas2 Alternativas3 Alternativas4 Prototipo1 Proto- tipo2 tipo3 tipo4 Concepto de operacion Reqs. de Software Requers. Validados Plan de Desarrollo Plan de Integracion y Pruebas Diseño de Software Diseño Validado, y verificado Diseño Detallado Codificación Prueba Unitaria Prueba del Sistema Prueba de Aceptación Implantación Modelo Espiral Ing. de Software

RAD - Desarrollo Rápido de Aplicaciones El Desarrollo rápido de aplicaciones (o RAD) definido por James Martin a principios de la década de 1980, consiste en un ciclo de desarrollo corto basado en tres fases (Requisitos, Diseño y Construcción) con un plazo de entrega ideal de 90 a 120 días como máximo. Ing. de Software

DSDM (Método de Desarrollo de Sistema Dinámico) El se desarrolló para completar lo que le faltaba al método RAD al proporcionar una estructura que tome en cuenta el ciclo de desarrollo completo. Las características principales del método DSDM son las siguientes: Participación del usuario Desarrollo iterativo y creciente Frecuencia de entrega mejorada Pruebas integradas en cada fase La aceptación de los productos entregados depende directamente del cumplimiento de los requisitos. Ing. de Software

Método: Proceso Unificado Es un proceso de desarrollo iterativo y creciente. Esto significa que el proyecto se divide en fases más cortas y que se envía una nueva versión gradual al final de cada fase. Este enfoque está basado en el modelo UML para la descripción de la arquitectura del software (funcional, de aplicación y física) y para el desarrollo del caso del usuario. Dicho modelo describe los requisitos y las demandas del usuario. Ing. de Software

RUP. Proceso Unificado Racional Es un método de desarrollo iterativo promovido por la compañía Rational Software, que fue comprada por IBM. El método RUP especifica, principalmente, la constitución del equipo y las escalas de tiempo, así como un número de modelos de documento. Ing. de Software

Método XP El método XP (Programación extrema) define un conjunto de prácticas óptimas para el desarrollo de aplicaciones en excelentes condiciones al colocar al cliente en el centro del proceso de desarrollo, manteniendo una cercana relación con dicho cliente. La Programación extrema se basa en los siguientes conceptos: Los equipos de desarrollo trabajan directamente con el cliente durante ciclos cortos de una o dos semanas como máximo. La entrega de las versiones del software ocurre muy temprano y en intervalos muy cortos para maximizar la interacción con el usuario. Existe una fuerte colaboración entre el equipo de desarrollo mientras trabaja en el código. El código se prueba y depura a lo largo del proceso de desarrollo. Existen indicadores que miden el progreso del proyecto para poder actualizar el plan de desarrollo. Ing. de Software

Modelo de Proceso y de Ciclo de Vida La preocupación por el “Proceso” (fin de los ’80) es más reciente que la definición del “Ciclo de Vida” (fin de los ’60) En general se asocia a la noción de modelo de proceso un mayor detalle y precisión Los modelos previos presentan en general poco nivel de detalle y fueron propuestos originalmente como modelos de Ciclo de Vida Ing. de Software

Herramientas y Técnicas para el Modelado de Procesos Elegir un lenguaje o notación Tener claro objetivos del modelo Detalle (granularidad) Describir-prescribir Predecir (requiere agregar relaciones cuantitativas entre elementos) Ejecutar (asistir en el uso) Vamos a ver algunos ejemplos… Ing. de Software

Preguntas 1. How does the description of a system relate to the notion of process models? For example, how do you decide what the boundary should be for the system described by a process model? 2. For each of the process models described in this lesson, what are the benefits and drawbacks of using the model? 3. For each of the process models described in this lesson, how does the model handle a significant change in requirements late in development? 4. Should a development organization adopt a single process model for all of its software development? Discuss the pros and cons. 5. Consider the processes introduced in this lesson. Which ones give you the most flexibility to change in reaction to changing requirements? Ing. de Software

Modelo ETVX Entry Task Verification eXit Entry: Condiciones necesarias para poder cumplir una tarea Task: Tarea que se lleva a cabo Quién y con qué responsabilidad Verification: Criterios para verificar que concluyó de forma adecuada (a veces se le menciona como Validation) eXit: Resultados a obtener Ing. de Software

Notación de Lai Artefacto, subartefacto, Actividad,subActividad, Rol, Operación, Análisis Tablas de estado muestran información referida a cuán completo está un artefacto en un instante dado Tablas de estado muestran cómo puede operar el proceso sobre los artefactos Diagramas de transición de estado muestran cómo se relacionan unos estados con otros (máquina de estados compuestos) Formularios para definir cada tipo de elemento (en los que se especifican las relaciones) Ing. de Software

Lai- relaciones entre elementos proceso artefacto Sub-actividad Sub-artefacto Ejecuta Manipula Actividad Artefacto Rol Ejecuta Operación cambia Ejecuta Refiere a Análisis compuesto por Estado- A(rtefacto) Refiere a controla Estado-P(roceso) Ing. de Software

Lai – Formulario para operación Componente Definición Pre-Condición Predicado en Estado-A para poder realizarla Artefacto El artefacto manipulado por la operación Acción La función a ser relizada por la operación Rol Lista de roles habilitados Post-Condición Predicados sobre Estado-A Ing. de Software

Modelo de Factores que inciden en la productividad (Abdel-Hamid 96) Porción de personal experiente % completado del proyecto Productividad potencial nominal de personal nuevo Productividad potencial nominal de personal experiente Multiplicador de aprendizaje Productividad potencial promedio nominal Productividad potencial Productividad de Desarrollo Porción real de persona-día en el proyecto Pérdidas por motivación y comunicación Esfuerzo adicional de comunicación Tamaño del equipo Presión del Calendario Sobre/bajo Tolerancia del trabajo Ing. de Software

Estructura del Desarrollo de Software (Abdel-Hamid 96) PRODUCCION DE SOFTWARE GESTION DE RRHH Pérdidas del Proceso Productividad potencial Tasa de incorporación de personal Tasa de bajas Detección y Corrección de Errores Tasa de Desarrollo de SW Productividad Real Mezcla de experiencia del personal Esfuerzo de Q A Personal Tasa de Errores Aprendizaje Presión del Calendario Productividad Percibida Nivel de Personal percibido como necesario Tareas percibidas como terminadas Nivel de precisión en medir el avance Fecha Planificada de Terminación Ajustes a Personal y Calendario Esfuerzo faltante percibido Fecha estimada de Terminación Estado percibido del proyecto CONTROL PLANIFICACION Ing. de Software

Modelado de Proceso ¿Para qué? Entender el proceso (real o propuesto) Revelar inconsistencias, problemas (base para la mejora) Simulación del proceso y planificación del proyecto Poco nivel de detalle adicional necesario Factores que afectan la productividad global. Relaciones (cuantificadas) entre los factores. Soportados por sw que simulan el proceso. Guía en la ejecución real del proceso Se precisa agregar múltiples detalles Ing. de Software