Modelos de desarrollo de software
- 1. MODELOS DE DESARROLLO DE SOFTWARE<br />MODELO SECUENCIAL LINEAL<br />Este es también llamado \" Modelo Clásico\" , \" Modelo Tradicional\" o \" Modelo en Cascada\" .<br />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 contribuyen a la satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la fase. Las flechas muestran el flujo de información entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrás representan la retroalimentación. <br />Características:<br />Planear un proyecto antes de embarcarse en él. <br />Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura interna. <br />Documentar los resultados de cada actividad. <br />Diseñar un sistema antes de codificarlo. <br />Testear un sistema después de construirlo.<br />Ventaja:<br />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.<br />Desventajas:<br />Los cambios introducidos durante el desarrollo pueden confundir al equipo profesional en las etapas tempranas del proyecto. Si los cambios se producen en etapa madura (codificación o prueba) pueden ser catastróficos para un proyecto grande. <br />No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos (etapa de inicio); y el modelo lineal lo requiere. La incertidumbre natural en los comienzos es luego difícil de acomodar. <br />El cliente debe tener paciencia ya que el software no estará disponible hasta muy avanzado el proyecto. Un error detectado por el cliente (en fase de operación) puede ser desastroso, implicando reinicio del proyecto con altos costos.<br />Critica:<br />Este es un modelo en el cual se debe usar cuando todos los requerimientos han sido establecidos claramente de entrada.<br />MODELO DE CONSTRUCCION DE PROTOTIPOS<br />El prototipado de requerimientos es la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rápida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten con el prototipo. Estos individuos luego proveen la retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del prototipo proporcionado, quienes capturan en la documentación actual de la especificación de requerimientos la información entregada por los usuarios para el desarrollo del sistema real. El prototipado puede ser usado como parte de la fase de requerimientos (determinar requerimientos) o justo antes de la fase de requerimientos (como predecesor de requerimientos). En otro caso, el prototipado puede servir su papel inmediatamente antes de algún o todo el desarrollo incremental en modelos incremental o evolutivo. <br />El Prototipado ha sido usado frecuentemente en los 90, porque la especificación de requerimientos para sistemas complejos tienden a ser relativamente dificultoso de cursar. Muchos usuarios y clientes encuentran que es mucho más fácil proveer retroalimentación convenientemente basada en la manipulación, leer una especificación de requerimientos potencialmente ambigua y extensa. <br />Escuchar al clienteValidar prototipoConstruir prototipo<br />Diferente del modelo evolutivo donde los requerimientos mejor entendidos están incorporados, un prototipo generalmente se construye con los requerimientos entendidos más pobremente. <br />Desventajas:<br />Cliente cree que es el sistema.<br />Peligro de familiarización con malas elecciones iniciales (quick and dirty).<br />Critica:<br />Se debe usar cuando inicialmente no están claros los requerimientos. Para así definir claramente de entrada las reglas con el cliente. <br />MODELOS EVOLUTIVOS<br />Se adaptan más fácilmente a los cambios introducidos a lo largo del desarrollo.<br />Iterativos<br />En cada iteración se obtienen versiones más completas del SW.<br />3.1. MODELO INCREMENTAL<br />Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores. 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. <br />Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma específica de observar el desarrollo de algún otro incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la figura. <br />El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos: <br />Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande. <br />Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos. <br />Si un error importante es realizado, sólo la última iteración necesita ser descartada. <br />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. <br />Si un error importante es realizado, el incremento previo puede ser usado. <br />Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento. <br />En la figura se muestra un refino del diagrama previo, bajo un esquema temporal, para obtener finalmente el esquema del Modelo de ciclo de vida Iterativo Incremental, con sus actividades genéricas asociadas. Aquí se observa claramente cada ciclo cascada que es aplicado para la obtención de un incremento; estos últimos se van integrando para obtener el producto final completo. Cada incremento es un ciclo Cascada Realimentado, aunque, por simplicidad, en la figura 5 se muestra como secuencial puro.<br />Se observa que existen actividades de desarrollo (para cada incremento) que son realizadas en paralelo o concurrentemente, así por ejemplo, en la figura, mientras se realiza el diseño detalle del primer incremento ya se está realizando en análisis del segundo.<br />Ventajas:<br />El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.<br />Desventajas:<br />El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.<br />Critica:<br />En este modelo se debe especificar con precisión todo lo que el sistema va a hacer antes de desarrollarlo. Lo cual lo hace manejable y disminuiría los costos.<br />3.2. MODELO EN ESPIRAL<br />Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la construcción de prototipos, pero conservado aquellas propiedades del modelo en cascada.<br />El modelo en espiral fue desarrollado por Boehm, quien lo describe así:<br />El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios.<br />Características:<br />Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo.<br />Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.<br />El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles. <br />Funcionamiento del modelo Espiral<br /> <br />En cada vuelta tomamos en cuenta:<br />Los Objetivos: Que necesidad debe envolver el programa.<br />Alternativas: Los varios métodos de alcanzar los objetivos de manera exitosa, a través de diferentes puntos como son:<br />Características: experiencia del personal, exigencias a efectuar. <br />Formas de gestión del programa. <br />Riesgo tomado con cada alternativa. <br />Desarrollar y Verificar: Programar y probar el programa .<br />Se planificaran los siguientes pasos y se volverá a empezar la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones la radial y la angular:<br />Angular=Avance del proyecto Software, dentro de un ciclo. <br />Radial=Aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando. <br />Este sistema es muy utilizado en proyectos largos como pueden ser la creación de un Sistema Operativo. Y que necesitan constantes cambios.<br />Al ser un modelo de Ciclo de Vida orientado al riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique sea capaz de detectar y catalogar correctamente dicho riesgo.<br />Desventajas:<br />Requiere mucha experiencia y habilidad para la evaluación de los riesgos, lo cual es requisito para el éxito del proyecto. <br />Es difícil convencer a los grandes clientes que se podrá controlar este enfoque evolutivo. <br />Critica:<br />Este modelo es útil para grandes proyectos pero no ha sido utilizado tanto como el lineal secuencial o el de prototipos. Tiene similitud con el modelo en cascada, pero aquí lo enfoca en un sistema más real.<br />3.3. MODELO WINWIN<br />Una variante interesante del Modelo Espiral previamente visto es el \" Modelo Espiral Win-Win\" (Barry Boehm). El Modelo Espiral previo (clásico) sugiere la comunicación con el cliente para fijar los requisitos, en que simplemente se pregunta al cliente qué necesita y él proporciona la información para continuar; pero esto es en un contexto ideal que rara vez ocurre. Normalmente cliente y desarrollador entran en una negociación, se negocia coste frente a funcionalidad, rendimiento, calidad, etc.<br />\" Es así que la obtención de requisitos requiere una negociación, que tiene éxito cuando ambas partes ganan\" .<br />Las mejores negociaciones se fuerzan en obtener \" Victoria & Victoria\" (Win & Win), es decir que el cliente gane obteniendo el producto que lo satisfaga, y el desarrollador también gane consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este modelo requiere fuertes habilidades de negociación.<br />El modelo Win-Win define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral; se definen las siguientes actividades:<br />1 - Identificación del sistema o subsistemas clave de los directivos(*) (saber qué quieren). <br />2 - Determinación de \" condiciones de victoria\" de los directivos (saber qué necesitan y los satisface) <br />3 - Negociación de las condiciones \" victoria\" de los directivos para obtener condiciones \" Victoria & Victoria\" (negociar para que ambos ganen). <br />(*) Directivo: Cliente escogido con interés directo en el producto, que puede ser premiado por la organización si tiene éxito o criticado si no.<br />El modelo WinWin hace énfasis en la negociación inicial, también introduce 3 hitos en el proceso llamados \" puntos de fijación\" , que ayudan a establecer la completitud de un ciclo de la espiral, y proporcionan hitos de decisión antes de continuar el proyecto de desarrollo del software.<br />Critica:<br />En este modelo las actividades que se definen son importantes como lo son: la identificación del sistema, la determinación de las condiciones y la negociación de estas.<br />3.4. MODELO DE DESARROLLO CONCURRENTE<br />Como el modelo espiral, el modelo concurrente provee una meta-descripción del proceso software. Mientras que la contribución primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribución del modelo concurrente es su capacidad de describir las múltiples actividades del software ocurriendo simultáneamente. <br />Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algún tiempo del proceso de desarrollo de software. <br />Los requerimientos son usualmente \" líneas de base\" , cuando una mayoría de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a los requerimientos son comunes y frecuentes (después de todo, los problemas reales cambian, y nuestro entendimiento de los problemas desarrollados también). Es desaconsejado detener el diseño en este camino cuando los requerimientos cambian; en su lugar, existe una necesidad de modificar y rehacer líneas de base de los requerimientos mientras progresa el diseño. Por supuesto, dependiendo del impacto de los cambios de los requerimientos el diseño puede no ser afectado, medianamente afectado o se requerirá comenzar todo de nuevo. <br />Durante el diseño de arquitectura, es posible que algunos componentes comiencen a ser bien definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede ser posible comenzar el diseño detallado en esos componentes estables. Similarmente, durante el diseño detallado, puede ser posible proceder con la codificación y quizás regular testeando en forma unitaria o realizando testeo de integración previo a llevar a cabo el diseño detallado de todos los componentes. <br />En algunos proyectos, múltiples etapas de un producto se han desarrollado concurrentemente. Por ejemplo, no es inusual estar haciendo mantención de la etapa 1 de un producto, y al mismo tiempo estar haciendo mantención sobre un componente 2, mientras que se está haciendo codificación sobre un componente 3, mientras se realiza diseño sobre una etapa 4, y especificación de requisitos sobre un componente 5. <br />Critica:<br />Este modelo se utiliza cuando las actividades están ocurriendo simultáneamente así, se posibilita el conocimiento del estado real en el que se encuentra el proyecto. <br />