Es un modo sistemtico para realizar, gestionar y administrar un proyecto de software con el objetivo de obtener altas posibilidades de xito. Una metodologa de desarrollo revela:

La divisin de un proyecto en etapas Acciones que corresponden a cada una de las etapas Entradas y salidas para cada una de las etapas Pautas para administrar el proyecto

Se requiere de una metodologa de desarrollo de software porque:Se deben ajustar los sistemas informticos a las exigencias del mercado atendiendo a un plan de trabajo.Se debe administrar y supervisar el proceso de desarrollo de software con el nimo de retroalimentarlo constantemente. El software ahora es ms complejo y esta caracterstica requiere de pautas que faciliten el logro de objetivos. Se requiere de anlisis, planificacin, gestin de recursos y documentacin para evitar el aumento en tiempo de desarrollo y mala calidad del producto final.

Descompone la actividad global del proyecto en etapas que son realizadas linealmente, es decir, cada etapa se realiza una vez: a continuacin de la etapa anterior y antes de la etapa siguiente.Las actividades de cada una de las etapas son independientes y no hay retroalimentacin entre ellas, aunque pueden permitirse procesos de retroalimentacin correctiva.Hay rigidez con respecto a lo que va a suceder en cada una de las etapas antes de comenzarlas, lo que permite reducir la posibilidad de errores durante la codificacin y la necesidad de requerir informacin de los usuarios.Se destaca la sencillez de su gestin y administracin en el desarrollo de programas pequeos.No es apto para desarrollos que suponen retroalimentacin entre etapas por los costos que pueden presentarse al retomar una etapa anterior.

Admite iteracionesDespus de cada etapa se realiza una o varias revisiones para comprobar si se puede pasar a la siguiente.Es un modelo rgido, poco flexible y con muchas restricciones.Se destaca la sencillez de su planificacin.Provee un producto con un elevado grado de calidad sin necesidad de un personal altamente calificado.Se debe contar con todos los requerimientos al comienzo del proyectoSi se han cometido errores y no se detectan en la fase siguiente, es costoso volver atrs para realizar la correccin.Los resultados no se observan hasta que no se encuentren las etapas finales del ciclo; por eso, cualquier error detectado trae retraso y aumento de costos.Es un ciclo adecuado para desarrollar software del cual se tienen los requerimientos desde el comienzo.

VENTAJAS. Excelente cuando se tiene un producto estable y se conoce la tecnologa. Es un mtodo muy estructurado que funciona bien con gente de poca experiencia. Provee estabilidad en los requerimientos. La planeacin se puede hacer anticipadamente. Recomendado para elaboracin de proyectos grandes.

DESVENTAJAS. Tiene poca flexibilidad. Los proyectos en la prctica raramente siguen un flujo secuencial. Siempre es difcil para el cliente mostrar los requerimientos explcitamente y con mucha anticipacin. El cliente debe tener paciencia. Es flexible y no motiva al cambio. Poco apropiado para aplicaciones para la toma de decisiones. Los usuarios tienen una participacin limitada.

Un prototipo es un producto parcial o provisionalEl objetivo de esta metodologa de ciclo de vida es lograr un producto intermedio antes de realizar el producto final con el propsito de conocer como respondern las funcionalidades previstas para el producto final.Antes de adoptar esta metodologa de ciclo de vida debe evaluarse si vale la pena adoptar el esfuerzo de crear un prototipo.Se utiliza en la elaboracin de productos con innovaciones importantes o en el uso de tecnologas nuevas o poco probadas, en las que la incertidumbre sobre los resultados a obtener impiden el uso de una metodologa secuencial.Es til en actividades de migracin de programas para adoptar sus nuevas funcionalidades.La ventaja de esta metodologa radica en que no es necesario conocer las especificaciones o tecnologa a utilizar.La desventaja radica en la dificultad de administracin y en el alto costo.

Es un mtodo menos formal de desarrollo.El prototipo es una tcnica para comprender las especificaciones.Un prototipo puede ser eliminado.Un prototipo puede llegar a ser parte del producto final. Se caracteriza por ser un diseo rpido que conduce a la construccin de un prototipo, el cual es evaluado por el usuario para una retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar.La iteracin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

VENTAJAS. tiles cuando los requerimientos son cambiantes. Cuando no se conoce bien la aplicacin. Cuando el usuario no se quiere comprometer con los requerimientos. Cuando se quiere probar una arquitectura o tecnologa. Cuando se requiere rapidez en el desarrollo.

DESVENTAJAS. No se conoce cuando se tendr un producto aceptable. No se sabe cuantas iteraciones sern necesarias. Da una falsa ilusin al usuario sobre la velocidad del desarrollo. El prototipo deber ir acompaado de otro modelo pasa su desarrollo. Sus desventajas son que debido a que el usuario ve que el prototipo funciona piensa que este es el producto terminado y no entienden que recin se va a desarrollar el software.

Puede considerarse una evolucin del modelo por prototiposSe basa en una serie de ciclos repetitivos para ir ganando madurez en el producto final.Toma ms en cuenta el concepto de riesgo que aparece debido a la incertidumbre o la ignorancia de los requerimientos proporcionados al principio del proyecto o que surgirn durante el desarrollo.A medida que avanza el espiral, se obtienen prototipos que van ganando la satisfaccin del cliente.Consta de cuatro actividades que envuelven las etapas: planificacin (relevamiento de requerimientos iniciales o luego de una iteracin), anlisis de riesgo (de acuerdo con el relevamiento de requerimientos se decide si se continua con el desarrollo), Implementacin (se desarrolla un prototipo basado en los requerimientos) y evaluacin (el cliente evala el prototipo).

Se caracteriza principalmente por: Un enfoque cclico para el crecimiento incremental del grado de definicin e implementacin de un sistema, mientras que disminuye su grado de riesgo. Un conjunto de puntos de fijacin para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.

El modelo espiral captura algunos principios bsicos: Decidir qu problema se quiere resolver antes de resolverlo. Examinar tus mltiples alternativas de accin y elegir una de las ms convenientes. Evaluar qu tienes hecho y qu tienes que haber aprendido despus de hacer algo. No ser tan ingenuo para pensar que el sistema que ests construyendo ser "EL" sistema que el cliente necesita. Conocer (comprender) los niveles de riesgo, que tendrs que tolerar.

VENTAJAS. El producto avanza a pasos firmes solucionando el riesgo en cada iteracin. El producto termina con todos los riesgos resueltos. Se pueden incluir otros mtodos de desarrollo en las iteraciones. A medida que el costo aumenta, los riesgos se reducen. Se tienen puntos de control en cada iteracin.

La idea detrs de este modelo es el desarrollo de una implantacin del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. En la Figura 14 se observa cmo las actividades concurrentes: especificacin, desarrollo y validacin, se realizan durante el desarrollo de las versiones hasta llegar al producto final.Una ventaja de este modelo es que se obtiene una rpida realimentacin del usuario, ya que las actividades de especificacin, desarrollo y pruebas se ejecutan en cada iteracin.Este modelo es efectivo en proyectos pequeos (menos de 100.000 lneas de cdigo) o medianos (hasta 500.000 lneas de cdigo) con poco tiempo para su desarrollo y sin generar documentacin para cada versin.

Existen dos tipos de desarrollo evolutivo:

Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene ms claras. El sistema evoluciona conforme se aaden nuevas caractersticas propuestas por el usuario.

Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no estn claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos.

VENTAJAS.La especificacin puede desarrollarse de forma creciente.Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.Es ms efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.

DESVENTAJAS.Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rpido, no es efectivo producir documentos que reflejen cada versin del sistema.Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento.Se requieren tcnicas y herramientas: Para el rpido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.

Al igual que el modelo en espiral, esta metodologa es evolutivaConcibe la iteracin entre las etapasConfigura aplicaciones desde componentes preparados de software llamados clases.La tecnologa de objetos proporciona el marco de trabajo tcnico para esta metodologa.Enfatiza en la creacin de clases que encapsulan tanto los datos como los algoritmos que se utilizan para manejarlos.Puntualiza en la reusabilidad del cdigo

Es un proceso que comprende el desarrollo iterativo, la construccin de prototipos y el uso de herramientas CASE. Tradicionalmente, el desarrollo rpido de aplicaciones tiende a englobar tambin la usabilidad, utilidad y la rapidez de ejecucin.

El Desarrollo Rpido de Aplicaciones (DRA) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto.

DRA es una adaptacin a Alta velocidad en el que se logra el desarrollo rpido utilizando un enfoque de construccin basado en componentes. Si se comprenden bien los requisitos y se limita el mbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional dentro de periodos cortos de tiempo.

Cuando se utiliza principalmente para aplicaciones de sistemas de informacin, el enfoque DRA comprende las siguientes fases:Modelado de gestin: El flujo de informacin entre las funciones de gestin se modela de forma que responda a las siguientes preguntas: Qu informacin conduce el proceso de gestin? Qu informacin se genera? Quin la genera? A dnde va la informacin?.Modelado de datos: Se definen las caractersticas (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.Modelado de proceso: Las descripciones del proceso se crean para aadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicacin entre los objetos.Generacin de aplicaciones: El DRA asume la utilizacin de tcnicas de cuarta generacin. En lugar de crear software con lenguajes de programacin de tercera generacin, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). Pruebas de entrega: Como el proceso DRA enfatiza la reutilizacin, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas.

VENTAJAS Comprar puede ahorrar dinero en comparacin con construir. Los entregables pueden ser fcilmente trasladados a otra plataforma.Visibilidad temprana. Mayor flexibilidad. Menor codificacin manual. Mayor involucramiento de los usuarios. Posiblemente menos fallas. Posiblemente menor costo. Ciclos de desarrollo ms pequeos. Interfaz grfica estndar.

DESVENTAJAS Comprar puede ser ms caro que construir. Costo de herramientas integradas y equipo necesario.Menos eficiente. Menor precisin cientfica.Prototipos pueden no escalar, un problema maysculo.Dependencia en componentes de terceros: funcionalidad de ms o de menos, problemas legales.

Mills sugiri el enfoque incremental de desarrollo como una forma de reducir la repeticin del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema. Es una combinacin del Modelo de Cascada y Modelo Evolutivo.

Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema.

Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

VENTAJAS. Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento. Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema. Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento. Las partes ms importantes del sistema son entregadas primero, por lo cual se realizan ms pruebas en estos mdulos y se disminuye el riesgo de fallos. La solucin se va mejorando en forma progresiva a travs de las mltiples iteraciones.

DESVENTAJAS. Cada incremento debe ser pequeo para limitar el riesgo (menos de 20.000 lneas). Cada incremento debe aumentar la funcionalidad. Es difcil establecer las correspondencias de los requisitos contra los incrementos. Es difcil detectar las unidades o servicios genricos para todo el sistema.

Una metodologa puede seguir uno o varios modelos de ciclo de vida, es decir, el ciclo de vida indica qu es lo que hay que obtener a lo largo del desarrollo del proyecto pero no cmo hacerlo.

La metodologa indica cmo hay que obtener los distintos productos parciales y finales