Tema 37.docx

Tema 37. Modelos de ciclo de vida: Clásico, Prototipos, Incremental, Espiral y Orientados a objetos. Métricas: Orientadas al tamaño, orientadas a la función y Orientadas a la calidad. [[https://www.istr.unican.es/asignaturas/is1/is1-t02-trans.pdf]](https://www.istr.unican.es/asignaturas/is1/is1-t02...

Tema 37. Modelos de ciclo de vida: Clásico, Prototipos, Incremental, Espiral y Orientados a objetos. Métricas: Orientadas al tamaño, orientadas a la función y Orientadas a la calidad. [[https://www.istr.unican.es/asignaturas/is1/is1-t02-trans.pdf]](https://www.istr.unican.es/asignaturas/is1/is1-t02-trans.pdf) Ciclo de vida: 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. Los modelos de ciclo de vida del software definen una serie de pasos que hay que dar de forma sistemática el desarrollo del software. Hablamos de ciclos de vida porque las actividades se repiten de forma cíclica a lo largo de la "vida útil" de todo el software. Hay varios modelos de ciclo de vida de software diferentes, algunos de los cuales son: El **modelo de ciclo de vida clásico** es un modelo secuencial lineal para el desarrollo de software que se basa en la premisa de que el desarrollo de software se puede dividir en etapas bien definidas y secuenciales. Cada etapa o fase empieza cuando se ha terminado la fase anterior. El punto de finalización de una fase es el inicio de la siguiente y lo marca la finalización de la documentación asociada. Para pasar a la siguiente fase es imprescindible terminar con los objetivos de la anterior ya que los resultados de cada fase marcarán los puntos de partida de la siguiente. Al final de cada fase el personal técnico y los usuarios tienen la oportunidad de revisar el progreso del proyecto. El modelo clásico se conoce comúnmente como el modelo de cascada y sigue el siguiente proceso secuencial: 1. Análisis del sistema: define los requisitos a nivel de sistema y obtiene a partir de ellos el subconjunto de requisitos del software a desarrollar. Supone el planteamiento de escenarios técnicos o alternativas viables de resolución del problema. 2. Análisis de requisitos: en esta etapa, se identifican y definen los requisitos del software a desarrollar, seguidos de su documentación y revisión por el cliente. En esta etapa se define el "qué" debe realizar el sistema. Identificando la información a procesar, las funciones a realizar, y las interfaces con otros sistemas existentes. También se definen los requisitos no funcionales, que serán los asociados a los factores de calidad que deberá contar nuestro software, como son el rendimiento, la seguridad, la escalabilidad. 3. Diseño: en esta etapa, definirá la estructura de datos, la arquitectura del software, el detalle de los procedimientos y la caracterización de la interfaz. En esta etapa se defina el "cómo" se implementará el sistema. 4. Codificación: en esta etapa, se escribe y codifica el código del software de acuerdo con el diseño y las especificaciones. 5. Pruebas: en esta etapa, se realizan pruebas para asegurarse de que el software funciona según lo previsto y cumple con los requisitos establecidos. 6. Mantenimiento: en esta etapa, se realizan correcciones y mejoras al software después de su lanzamiento. Esta etapa está activa mientras dura la vida útil del software. Tenemos tres tipos de mantenimientos: a. Mantenimiento correctivo: cuando se utiliza para la corrección de errores. b. Mantenimiento adaptativo: se produce en respuesta a un cambio en las especificaciones de requisitos o en el entorno tecnológico. c. Mantenimiento proactivo: se produce en respuesta a la detección de posibles cambios aun no definidos pero previsibles de dichas especificaciones o en los entornos tecnológicos. Este modelo tiene sus inconvenientes: - Los procesos reales difícilmente siguen un flujo secuencial que propone el modelo. - Es difícil para el cliente definir perfectamente desde el inicio todos los requisitos. - El cliente no tendrá una versión operativa disponible hasta el final las etapas finales. - Asume que no se cometen muchos errores en cada fase. El **modelo de ciclo de vida de prototipos** es un modelo iterativo e incremental para el desarrollo de software. Existen 3 tipos de ciclo de vida de prototipos: 1. Prototipos desechables: el prototipo se desecha una vez que se dan por definidos los requisitos del software. 2. Prototipos evolutivos: El prototipo va evolucionando hasta llegar al producto final. 3. Combinación de prototipos desechables y evolutivos: combinación de ambos. [Prototipos desechables] Este modelo se basa en la creación de prototipos del software antes de la fase de implementación, lo que permite obtener retroalimentación temprana y mejorar el diseño del software. Surge en respuesta a la necesidad de iniciar un desarrollo sin una especificación detallada de los requisitos. Supone la elaboración de un modelo o maqueta del sistema a partir de la recolección y refinamiento inicial de requisitos y un diseño rápido enfocado en los aspectos del software visibles para el usuario. Se busca una mejor recolección de requisitos que se quiere que se cumplan. Una vez construido dicho prototipo, es evaluado por parte del usuario y se reescriben los requisitos hasta llegar a un conjunto de requisitos completo. A continuación, el prototipo es desechado y a partir de los requisitos recopilados se seguirá un modelo en cascada para el desarrollo del sistema. El proceso típico del modelo de prototipos desechables es el siguiente: 1. Identificación de requisitos: en esta etapa, se identifican y definen los requisitos del software. 2. Diseño rápido: Con los requisitos identificados en la etapa anterior se realiza un diseño rápido. 3. Construcción del prototipo: en esta etapa, se desarrolla un prototipo del software que puede ser una versión simplificada del producto final. Este prototipo se utiliza para obtener retroalimentación temprana y mejorar el diseño del software. 4. Evaluación y reescritura de requisitos: en esta etapa, se recopilan comentarios y retroalimentación sobre el prototipo del software. Estos comentarios se utilizan para mejorar el diseño del software y para identificar nuevos requisitos o cambios en los requisitos existentes. De esta etapa pasamos a la etapa 2 hasta que consideramos que se tiene un conjunto completo de requisitos. 5. Modelo en cascada. [Prototipo evolutivo] - Se comienza diseñando e implementando las partes más destacadas del sistema: - La evaluación del prototipo proporciona la realimentación necesaria para aumentar y refinar el prototipo - El prototipo evoluciona y se transforma en el sistema final. El modelo de prototipos es útil cuando los requisitos del software no están completamente definidos o pueden cambiar durante el proceso de desarrollo. Sin embargo, este modelo puede ser más costoso y llevar más tiempo que otros modelos debido a la creación de múltiples prototipos y la retroalimentación temprana que se requiere. También tiene el problema que el usuario confunda el prototipo con el producto final, y fallos que pueden darse en un prototipo hecho de forma rápida pueda dar una visión de poca fiabilidad, o que un prototipo se haga con un diseño diferente y cuando vean el diseño final se queden satisfechos. El **modelo de ciclo de vida incremental** es un modelo iterativo e incremental para el desarrollo de software. Este modelo divide el desarrollo de software en pequeñas partes o incrementos que se desarrollan y entregan de forma independiente. Cada uno de estos incrementos se desarrolla siguiendo un modelo secuencial y trabaja sobre un subconjunto de la funcionalidad. El proceso típico del modelo incremental es el siguiente: 1. Análisis de requisitos: en esta etapa, se identifican y definen los requisitos del software a desarrollar. 2. Diseño inicial: en esta etapa, se desarrolla un diseño inicial del software que se utilizará para guiar el desarrollo del primer incremento. 3. Desarrollo e implementación del primer incremento: en esta etapa, se desarrolla y se entrega el primer incremento del software que cumple con un subconjunto de los requisitos del software. 4. Pruebas del primer incremento: en esta etapa, se realizan pruebas para asegurarse de que el primer incremento del software funciona según lo previsto y cumple con los requisitos establecidos. 5. Diseño y desarrollo de los incrementos siguientes: en esta etapa, se repiten los pasos 2 a 4 para cada incremento adicional del software, que incluye nuevos requisitos y funcionalidades. 6. Integración de los incrementos: en esta etapa, se integran todos los incrementos del software en una versión completa y funcional del software. 7. Pruebas finales: en esta etapa, se realizan pruebas finales para asegurarse de que el software integrado funciona según lo previsto y cumple con todos los requisitos. 8. Mantenimiento: en esta etapa, se realizan correcciones y mejoras al software después de su lanzamiento. El modelo de ciclo de vida incremental es útil cuando se desea obtener un producto de software funcional en etapas tempranas del desarrollo y cuando se pueden identificar y priorizar los requisitos del software. Sin embargo, este modelo también puede requerir más esfuerzo y recursos para integrar los incrementos del software y para garantizar que todos los requisitos se cumplan en la versión final del software. El **modelo de ciclo de vida en espiral** es un modelo iterativo e incremental para el desarrollo de software que se centra en la [evaluación de riesgos y en la adaptación continua durante el proceso de desarrollo]. Existen dos tipos de ciclo de vida en espiral: - Boehm que define 4 regiones de actividades diferentes para cada ciclo. - Pressman, es una variante del anterior con 6 regiones diferentes. [Modelo de espiral de Boehm] El modelo de espiral es muy útil cuando se desarrolla software complejo o de alta calidad que requiere una planificación cuidadosa y un enfoque riguroso. Se definen una serie de ciclos en los que cada ciclo se divide en cuatro regiones de actividades principales: 1. Planificación: Se determinan objetivos (rendimientos, funcionalidad, adaptación al cambio,..), alternativas (posibilidades de diseño, compra de software, reutilización del existente,...) y restricciones impuestas a cada alternativa. 2. Análisis de riesgos: supone la evaluación de las diferentes alternativas, teniendo en cuenta los objetivos a cumplir con las restricciones impuestas. Se identifican las áreas de incertidumbre del proyecto con sus riesgos asociados. Si existen riesgos, se realizará un análisis de los mismos. 3. Ingeniería: En función del tipo de riesgo en esta fase se podrá seguir el modelo en cascada o prototipos, etc... 4. Evaluación del cliente: este ciclo termina con la evaluación por parte del cliente. La dimensión angular del modelo define el avance en cada ciclo y la dimensión radial define el coste acumulado en los ciclos realizados hasta el momento. En este modelo se maneja el concepto de versiones, cada vez que se completa una versión se vuelven a estudiar requerimientos y se plantea la siguiente versión del mismo producto. [Modelo en espiral de Pressman] Al igual que el modelo en espiral de Boehm el software se desarrolla en una serie de entregas evolutivas. Durante las primeras iteraciones, lo que se entrega puede ser un modelo o prototipo. En las iteraciones posteriores se producen versiones cada vez más completas del sistema cuya ingeniería se está haciendo.  El primer circuito alrededor de la espiral da como resultado el desarrollo de una especificación del producto; las vueltas sucesivas se usan para desarrollar un prototipo y, luego, versiones cada vez más sofisticadas del software. Cada paso por la región de planeación da como resultado ajustes en el plan del proyecto. El costo y la programación de actividades se ajustan con base en la retroalimentación obtenida del cliente después de la entrega. Los **modelos de ciclo de vida orientados a objetos** Los modelos de ciclos de vida normalmente se basan en: el análisis y diseño estructurados, pero los objetos tienen una particularidad, y es que están basados en componentes que se relacionan entre ellos a través de interfaces, o lo que es lo mismo, son más modulares y por lo tanto el trabajo se puede dividir en un conjunto de mini proyectos. Además, hoy en día la tendencia es a reducir los riesgos, y en este sentido, el ciclo de vida en cascada no proporciona muchas facilidades. Debido a todo esto, el ciclo de vida típico en una metodología de diseño orientado a objetos es iterativo e incremental. Existen diferentes modelos orientados a objetos: - Modelo Fuente. - Modelo de Agrupamiento. - Modelo Remolino. - Modelo PinBall. El más popular es el modelo fuente que fue creado en 1990. Propone dos modelos de ciclo de vida: - Para el sistema completo. - Para cada clase o módulo: Cada clase puede estar en una fase diferente del ciclo de vida durante el desarrollo del sistema. Un proyecto se divide en las fases:  1. Planificación del negocio 2. Construcción: Es la más importante y se divide a su vez en otras cinco actividades - Planificación - Investigación - Especificación - Implementación - Revisión 3. Entrega La primera y la tercera fase son independientes de la metodología de desarrollo orientado a objetos. Además de las tres fases, existen dos periodos:  1. Crecimiento: Es el tiempo durante el cual se construye el sistema 2. Madurez: Es el periodo de mantenimiento del producto. Cada mejora se planifica igual que el periodo anterior, es decir, con las fases de Planificación del negocio, Construcción y Entrega. Cada clase puede tener un ciclo de vida sólo para ella debido a que cada una puede estar en una fase diferente en un momento cualquiera. La ventaja es que permite un desarrollo solapado e iterativo. **Modelo de agrupamiento** El agrupamiento es un conjunto de clases relacionadas con un objetivo común. Clúster: Unidad organizativa básica. Es un grupo de clases relacionadas o clústeres relacionados. El clúster es la unidad natural para el desarrollo por parte de un único desarrollador. Tiene un componente secuencial y un componente concurrente. - Existencia de diferentes subciclos de vida, que pueden solaparse en el tiempo. - Se aplica al clúster no al sistema completo. - El miniciclo de vida que gobierna el desarrollo de un clúster está formado por Especificación, Diseño, Implementación, Verificación/Validación y Generalización.  **Modelo Remolino** En la práctica los modelos de desarrollo son desordenados e implican múltiples iteraciones relacionadas. El modelo en cascada asume una sola dimensión de iteración, consistentes en la fase de proceso. Pueden Identificarse otras dimensiones: - Amplitud: tamaño del desarrollo - Profundidad: referida al nivel de abstracción o detalle. - Madurez: grado de comprensión, corrección y elegancia. - Alternativas: Diferentes soluciones a un problema. - Alcance: Propósitos y objetivos del sistema, ya que los requisitos van cambiando a lo largo del tiempo. Las diferentes dimensiones pueden anidarse de varias formas. Ejemplo: profundidad -- madurez -- amplitud Este proceso fractal (más que lineal), consiste en un desarrollo multiciclo en forma de remolino en lugar de una cascada, de ahí su nombre. **Modelo Pinball** Modelo muy didáctico señala que el pinball refleja la forma que se desarrolla el software. Pelota ====\> Proyecto o subproyecto Jugador ====\> Equipo de desarrollo Se procede de forma iterativa: 1. Encontrar clases, atributos, métodos y relaciones (actividades que pueden englobarse en la fase de análisis). 2. Definir colaboraciones, herencia, agregación y subsistemas (actividades de diseño). 3. Programación, prueba e implementación. Como en el pinball los pasos se pueden dar en cualquier orden y de forma simultánea. Existen dos estilos a la hora de jugar - A lo seguro ===\> Con tecnologías y métodos probados - Al límite ===\> Con más riesgo (se pueden conseguir beneficios espectaculares) El autor destaca que al igual que en el juego del pinball, la habilidad es el factor más importante. Los modelos de ciclo de vida orientados a objetos son útiles para el desarrollo de sistemas de software complejos y de alta calidad que requieren una planificación y un diseño detallados. Estos modelos también son útiles cuando se desea maximizar la reutilización de código y reducir el acoplamiento entre los módulos del software. Sin embargo, también pueden requerir más esfuerzo y recursos para el diseño y la implementación del software debido a la complejidad inherente de la POO. **Métricas** Métrica: Evaluación del grado en el cual un producto o proceso posee un atributo determinado. Una métrica es directa si se puede medir directamente del atributo y su valor no depende de la medida de otros atributos (longitud del código fuente, duración del proceso de prueba, número de defectos\...). Una métrica es indirecta si comprende la medición de varios atributos, es decir, si deriva de otros atributos (productividad, estabilidad de requisitos, densidad de defectos en un módulo, etc.) La posibilidad de medir es el fundamento de las disciplinas científicas y de ingeniería. Sin poder medir es muy difícil evaluar y experimentar las técnicas y los métodos de ingeniería del software. No se puede controlar lo que no se puede medir y no se puede predecir lo que no se puede medir. Existen muchas clasificaciones de las métricas, nosotros nos centraremos en las métricas orientadas al tamaño, a la función y a la calidad. Las **métricas orientadas al tamaño** son medidas directas al software y el proceso por el cual se desarrolla. Hay varias métricas orientadas al tamaño que se utilizan comúnmente en la industria del software, entre ellas: - Líneas de código (LOC): esta métrica mide el tamaño de un software en función del número de líneas de código que lo componen. Esta métrica es útil para estimar el esfuerzo necesario para desarrollar y mantener el software, pero no es una medida precisa de la complejidad o calidad del software. - Esfuerzo persona/mes: necesarias para llevar a término un proyecto software. - Coste en dinero del proyecto. - Número de páginas de documentación. - Número de errores encontrados antes de la entrega - Números de errores encontrados después de la entrega. Se pueden combinar estas medidas para obtener otras medidas, por ejemplo: - Productividad = KLDC/ persona-mes - Calidad = errores / KLDC - Costo=\$/KLDC - Documentación = páginas de documentación / KLDC Las métricas orientadas al tamaño no están aceptadas universalmente como el mejor modo de medir el proceso de desarrollo del software. La mayor parte de la discusión gira en torno al uso de las líneas de código como medida clave. La LDC se puede calcular fácilmente para todos los proyectos de desarrollo de software pero las medidas en LDC son dependientes del lenguaje de programación y perjudican a los programas más cortos. Las **métricas orientadas a la función** son medidas indirectas al software y el proceso por el cual se desarrolla. Están enfocadas a medir la funcionalidad del proceso y el producto. Unas de las primeras fueron las llamadas "Punto de Función" para un sistema de software. Los PF se obtienen utilizando una función empírica basada en medidas cuantitativas del software y valoraciones subjetivas de la complejidad del mismo. Al igual que se hacía antes con las KLDC se puede hacer con los PF: Productividad=personas-mes/PF Calidad=PF/ Errores Costo=\$/PF Documentación= Páginas de Doc/PF Puntos de caso de uso: Los casos de uso son la base para estimar el esfuerzo (en técnicos-- hora) de un proyecto software tomando de base los casos de uso de ese proyecto. El valor de punto de caso de uso también se obtiene de una función empírica donde se tiene en cuenta los actores en los casos de uso y ciertos factores cuyos valores vienen dados por valores en unas tablas predefinidas. Las **métricas orientadas a la calidad del software** son medidas indirectas al software y el proceso por el cual se desarrolla. Se utilizan para medir la calidad del software, se quiere medir en qué medida se cumple con los requisitos y las expectativas del usuario. Para ello utilizaremos los factores de calidad entre los que se encuentran: Corrección, Fiabilidad, Eficiencia, Integridad, Robustez, Facilidad de uso, Facilidad de mantenimiento, Facilidad de prueba, Portabilidad, Reusabilidad, Interoperabilidad. Algunas de las métricas orientadas a la calidad más comunes son: - Tasa de errores: Esta métrica se utiliza para medir la cantidad de defectos en el software por unidad de tamaño o funcionalidad entregada. Esta métrica ayuda a identificar las áreas problemáticas del software y a planificar mejoras en la calidad del software. - Tiempo medio entre fallos (MTBF): Esta métrica se utiliza para medir la confiabilidad del software en términos de la cantidad de tiempo promedio que transcurre entre los fallos del software. Esta métrica es importante para garantizar la confiabilidad del software y la satisfacción del usuario. - Tiempo medio de reparación (MTTR): Esta métrica se utiliza para medir la capacidad del software para recuperarse de los fallos y errores. Esta métrica es importante para garantizar la disponibilidad del software y minimizar el tiempo de inactividad. - Complejidad ciclomática: Esta métrica se utiliza para medir la complejidad del software en términos de su estructura y diseño. Esta métrica es útil para evaluar la facilidad de mantenimiento y comprensión del software. - Índice de mantenibilidad: Esta métrica se utiliza para medir la capacidad del software para ser modificado y mejorado sin afectar su funcionamiento. Esta métrica es importante para garantizar la capacidad del software para adaptarse a los cambios en las necesidades y expectativas del usuario. Principio del formulario Final del formulario Principio del formulario