Es un desarrollo de sistemas modelo diseado para simplificar la comprensin de la complejidad asociada con desarrollo de sistemas. En los sistemas de ingeniera que se utiliza para definir un procedimiento uniforme para el producto o el desarrollo del proyecto.

.

El modelo V se utiliza para regular el proceso de desarrollo de software dentro de la administracin federal de Alemania. Hoy en da sigue siendo el estndar para el alemn proyectos de la administracin federal y la defensa, as como los desarrolladores de software dentro de la regin

El concepto de la V-modelo ha sido desarrollado de forma simultnea, pero independiente, en Alemania y en los Estados Unidos a finales de 1980:

El alemn V-modelo fue desarrollado originalmente por IABG en Ottobrunn, cerca de Munich, en cooperacin con la Oficina Federal de Tecnologa de Defensa y Adquisiciones en Coblenza, por el Ministerio Federal de Defensa.

Fue tomada por el Ministerio Federal del Interior para el dominio civil de las autoridades pblicas en el verano de 1992.

Los EE.UU. en V Modelo, tal como se documenta en 1991 en los procedimientos para el Consejo Nacional de la Ingeniera de Sistemas (NCOSE, ahora INCOSE a partir de 1995), fue desarrollado para los sistemas de satlite que involucran hardware, software, y la interaccin humana.

Una caracterstica fundamental de los EE.UU. en V modelo es que el movimiento del tiempo y la madurez de izquierda a derecha y uno no puede moverse hacia atrs en el tiempo. Todos iteracin es a lo largo de una lnea vertical a niveles superiores o inferiores en la jerarqua del sistema, como se muestra en la figura. Esto ha demostrado ser un aspecto importante del modelo. La expansin del modelo a un concepto de doble-Vee es tratado en la referencia.

Ventajas Los usuarios de la V-Modelo participar en el desarrollo y el mantenimiento. Un tablero de control de cambios mantiene pblicamente. El tablero de control de cambios se rene una vez al ao y procesa todas las solicitudes de cambio recibidas en el V-modelo.

En cada inicio del proyecto, el V-modelo puede ser adaptado en un proyecto especfico, siendo posible porque es la organizacin y el proyecto independiente.

El V-Modelo ofrece asistencia concreta sobre cmo implementar una actividad y sus fases de trabajo, definiendo explcitamente los eventos necesarios para completar un paso de trabajo:. Cada esquema de actividades contiene las instrucciones, recomendaciones y explicaciones detalladas de la actividad

Desventajas

Los siguientes aspectos no estn cubiertos por la V-modelo, que debe ser regulado, adems de, o el V-modelo debe adaptarse en consecuencia:

La colocacin de los contratos de servicios no est regulado.

La organizacin y ejecucin de la operacin, mantenimiento, reparacin y eliminacin del sistema no estn cubiertos por la V- modelo. Sin embargo, la planificacin y la preparacin de un concepto para estas tareas estn reguladas en el Modelo V.

El modelo V aborda el desarrollo de software dentro de un proyecto en lugar de toda una organizacin.

CONCEPTO: El modelo en espiral del proceso del software que originalmente fue propuesto por Boehm (1988), El modelo en espiral es una delas metodologas ms recomendables para el desarrollo y creacin de un programa, ya que consta de pocas etapas o fases, las cuales se van realizando en una manera continua y cclica.

Cada ciclo de la espiral se divide en 4 etapas: DEFINICION DE OBJETIVOS: Para esta fase del proyecto se definen los objetivos especficos. Se identifican las restricciones del procesos y el producto, y se estipula un plan detallado de administracin. Se identifican los riesgos del proyecto. Dependiendo de esos riesgos, se planean estrategias alternativas.

EVALUACION Y REDUCCION DE RIESGOS: Se lleva a cabo un anlisis detallado para cada uno de los riesgos del proyecto. Se definen los pasos para reducir dichos riesgos. Por ejemplo si existe el riesgo de tener requerimientos inapropiados, se desarrolla un prototipo del sistema.

DESARROLLO Y VALIDACION: Despus de la evaluacin de riesgos, se elige un modelo para el desarrollo del sistema. Por ejemplo, si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podra ser la construccin de prototipos evolutivos. Si los riesgos de proteccin son la principal consideracin, un desarrollo basado en transformaciones formales podra ser el mas apropiado, y as sucesivamente. El modelo de cascada es el mas apropiado para el desarrollo si el mayor riesgo identificado es la integracin de los subsistemas.

PLANEACION: El proyecto se revisa y se toma la decisin de si se debe continuar conLas tareas requeridas para definir recursos, el tiempo, determinacin de los objetivos, alternativas y restricciones y otra informacin relacionadas con el proyecto.

Identificacin del sistema o subsistemas clave de los directivos.Determinacin de las condiciones de victoria de los directivos.Tipo de metodologa en espiral

El modelo en espiral WINWIN de Boehm, define un conjunto de actividades de negociacin al principio de cada paso alrededor de la espiral. Ms que una simple actividad de comunicacin con el cliente se definen las siguientes actividades:

Negociacin de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados(incluyendo el equipo del proyecto de software).El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijacin que ayudan a establecer la completitud de un ciclo alrededor del espiral proporcionan mitos de decisin

VENTAJASEl modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor durante riesgos en cada uno de los niveles evolutivos.

El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa de evolucin del producto.El modelo en espiral demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas.

DesventajasResulta difcil convencer a grandes clientes de que el enfoque evolutivo es controlable.Debido a su elevada complejidad no se aconseja utilizarlo en pequeos sistemas.Genera mucho tiempo en el desarrollo de sistemas

BIBLIOGRAFA

SOMMERVILLE, Ian. Ingeniera de software. Pearson Educacion.6 Edicin, Mxico, 2002, Pg. 712

http://es.geocities.com/modeloespiral/resumen.ht

http://74.125.47.132/search?q=cache:uusARBBEfWsJ:comunidad.uach.mx

http://es.geocities.com/modeloespiral/variante3.htm