1. Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software.
1.1. El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del 70. Desde entonces muchos equipos de desarrollo han seguido este modelo. Sin embargo, ya desde 10 a 15 años atrás, el modelo cascada ha sido sujeto a numerosas críticas, debido a que es restrictivo y rígido, lo cual dificulta el desarrollo de proyectos de software moderno.
2. Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.
2.1. Un modelo de ciclo de vida del software:
2.2. Describe las fases principales de desarrollo de software.
2.3. Define las fases primarias esperadas de ser ejecutadas durante esas fases.
2.4. Ayuda a administrar el progreso del desarrollo.
2.5. Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.
3. Modelo Espiral
3.1. El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos: Determinar qué quieres lograr. Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor. Seguir la alternativa seleccionada en el paso 2. Establecer qué tienes terminado.
3.1.1. El modelo espiral captura algunos principios básicos o caracteristicas:
3.1.2. Decidir qué problema se quiere resolver antes de viajar a resolverlo.
3.1.3. Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
3.1.4. Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
3.1.5. No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y
3.1.6. Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.
3.1.7. El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatible
4. modelo cascada
4.1. Este es el más básico de todos los modelos, y sirve como bloque de construcción para los demás modelos de ciclo de vida. La visión del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuye a la satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la fase.
4.1.1. El modelo de ciclo de vida cascada, captura algunos principios básicos o características:
4.1.2. Planear un proyecto antes de embarcarse en él.
4.1.3. Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura interna.
4.1.4. Documentar los resultados de cada actividad.
4.1.5. Diseñar un sistema antes de codificarlo.
4.1.6. Testear un sistema después de construirlo.
4.1.7. Una de las contribuciones más importantes del modelo cascada es para los administradores, posibilitándoles avanzar en el desarrollo, aunque en una escala muy bruta.
5. modelo de desarrollo incremental
5.1. El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo,no demanda una forma específica de observar el desarrollo de algún otro incremento.
5.1.1. El modelo de desarrollo incremental provee algunas caracteristicas significativas para los proyectos:
5.1.2. Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
5.1.3. Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.
5.1.4. Si un error importante es realizado, sólo la última iteración necesita ser descartada.
5.1.5. Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.
5.1.6. Si un error importante es realizado, el incremento previo puede ser usado.
5.1.7. Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento
6. Modelo de prototipos
6.1. El Modelo de prototipos, en Ingeniería de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará
6.1.1. Etapas: Plan rápido. Modelado, diseño rápido Construcción del Prototipo Desarrollo, entrega y retroalimentación Comunicación Entrega del desarrollo final
6.1.1.1. Ventajas Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina Se puede reutilizar el código Inconvenientes: El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacción a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado. En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final..
7. Modelo orientado a objetos
7.1. Los tipos de Modelos de ciclos de vida normalmente se basan el 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.
7.1.1. COMPONENTES DEL MODELO DE ESTRUCTURA DE OBJETOS El componente básico del OSM es la clase de objetos. Se distinguen tres tipos de clase: *Objetos Entidad. *Objetos de Interfaz. *Objetos de Control.
7.1.1.1. Este modelo identifica : *las clases de objetos en la aplicación. *como las clases de objetos se asocian unas con otras. *como se comunican los objetos. *Los detalles de cada clase de objetos, incluyendo atributos y operaciones. Durante el proceso de análisis y diseño, el OSM es definido en sucesivos niveles incrementales de detalle, hasta que el nivel necesario para la complementación es alcanzado
7.1.1.1.1. Durante el ciclo de desarrollo se aportan los siguientes elementos al modelo: Análisis del Negocio: se reconocen objetos claves del negocio y generan las abstracciones en las clases apropiadas (objetos entidad). Análisis de Requerimientos: se identifican asociaciones estructurales entre objetos y nuevas clases (entidad). Diseño lógico: Se incorporan todas las clases necesarias para la aplicación incluyendo los objetos de interfaz y de control. Diseño Físico: se incorporan todos los detalles remanentes para la complementación física de cada clase de objetos.
8. modelo agil
8.1. El desarrollo ágil de software envuelve un enfoque para la toma de decisiones en los proyectos de software, que se refiere a métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan con el tiempo según la necesidad del proyecto
8.1.1. Algunos métodos ágiles de desarrollo de software: Adaptive Software Development (ASD) Agile Unified Process Crystal Clear Feature Driven Development (FDD) Lean Software Development (LSD) Kanban (desarrollo) Open Unified Process (OpenUP) Programación Extrema (XP) Método de desarrollo de sistemas dinámicos (DSDM) Scrum G300 6D-BUM