INGENIERÍA DE SOFTWARE MODELO V INGENIERÍA DE SOFTWARE

MODELO V El V-modelo es una representación gráfica de la los sistemas de ciclo de vida de desarrollo. En él se resumen las principales medidas que deben adoptarse en relación con las prestaciones correspondientes en la validación del sistema computarizado armazón. El VEE es un proceso que representa la secuencia de pasos en un proyecto de desarrollo del ciclo de vida. Se describen las actividades y resultados que deben producirse durante el desarrollo del producto. El lado izquierdo de la VEE representa la descomposición de las necesidades, y la creación de las especificaciones del sistema. El lado derecho de la V representa la integración de las piezas y su verificación. V significa "Verificación y validación" . Es muy similar al modelo de la cascada Clásico ya que es muy rígida y contiene una gran cantidad de iteración.

OBJETIVO DEL MODELO V   Minimización de los riesgos del proyecto: El V-modelo mejora la transparencia del proyecto y control del proyecto, especificando los enfoques estandarizados y describir los resultados correspondientes y funciones de responsabilidad. Que permite un reconocimiento temprano de la planificación de las desviaciones y los riesgos y mejora la gestión de procesos, reduciendo así el riesgo del proyecto. Mejora y garantía de calidad del proyecto: Como un modelo de proceso estándar, el V-modelo asegura que los resultados que se proporcionan son completos y tienen la calidad deseada. Los resultados provisionales definidos se puede comprobar en una fase temprana. El contenido del producto uniformes mejorará la legibilidad, comprensibilidad y verificabilidad.

Reducción de los gastos totales durante todo el proyecto y sistema de ciclo de vida: El esfuerzo para el desarrollo, producción, operación y mantenimiento de un sistema puede ser calculado, estimado y controlados de manera transparente mediante la aplicación de un modelo de proceso estandarizado. Los resultados obtenidos son uniformes y fácilmente volvió. Esto reduce la dependencia de los adquirentes en el proveedor y el esfuerzo para las posteriores actividades y proyectos. Mejora de la comunicación entre todos los interesados: La descripción estandarizada y uniforme de todos los elementos pertinentes y términos es la base para la comprensión mutua entre todos los interesados. De este modo, se reduce la pérdida de fricción entre el usuario, comprador, proveedor y desarrollador.

ANALISIS Este modelo muestra relación entre las distintas fases en el proceso de desarrollo de software y añade dos partes importantes que son: La verificación: que tiene relación con la pregunta ¿Se está haciendo correctamente el producto? La validación: que tiene relación con la pregunta ¿ Se está haciendo el producto? , es decir, la demostración de que el software cumple exactamente con lo que pretende.

REPRESENTACIÓN GRÁFICA

CARACTERÍSTICAS Puede notarse que su primera mitad es similar al Modelo en Cascada, y la otra mitad tiene como finalidad hacer pruebas e integración asociado a cada una de las etapas de la mitad anterior. Se puede identificar una ventaja principal con respecto al Modelo Cascada más simple, y se refiere a que este modelo involucra chequeos de cada una de las etapas del modelo de cascada.

VENTAJAS En el modelo la 1ra mitad es similar al Modelo en Cascada, y la otra mitad tiene como finalidad hacer pruebas e integración de cada una de las etapas de la mitad anterior. La ventaja principal con respecto al modelo en cascada es simple, ya que este modelo involucra chequeos de cada una de las etapas del modelo de cascada. Los requisitos se validan con las pruebas de aceptación(“User Acceptance Test”) El Análisis y diseño de arquitectura se validan con las pruebas de IST (Integration & System test), mientras que las pruebas a nivel de componentes y a más bajo nivel se realizan en las fases de pruebas de “Assembly” y “Unit Test” respectivamente.

DESVENTAJAS Se toma toda la complejidad del problema de una vez y no en iteraciones o ciclos de desarrollo. Los problemas más comunes son casi los mismos del Modelo cascada y es que no contempla la posibilidad de retornar a etapas inmediatamente anteriores, cosa que en la realidad puede ocurrir. El riesgo es mayor que el de otros modelos, pues en lugar de hacer pruebas de aceptación al final de cada etapa, las pruebas comienzan a efectuarse luego de haber terminado la implementación, lo que puede traer como consecuencia un “roll-back” de todo un proceso que costó tiempo y dinero.

El mantenimiento se realiza en el código fuente. El modelo no contempla la posibilidad de retornar a etapas inmediatamente anteriores, cosa que en la realidad puede ocurrir. Se toma toda la complejidad del problema de una vez y no en iteraciones o ciclos de desarrollo, lo que disminuye el riesgo. A pesar de todo lo antes mencionado, definitivamente se trata de un modelo más robusto y completo que el Modelo de Cascada, y puede producir software de mayor calidad que con el modelo de cascada. Las revisiones de proyectos de gran complejidad son muy difíciles. Si se comete un error en la fase de análisis no se descubre hasta la entrega, produciendo un gasto inútil de recursos.

COMPLEMENTOS Hay factores que no quedan claramente reflejados en el ciclo de vida ni en las técnicas de desarrollo estas son:      El cumplimiento de los plazos de entrega. La calidad (número de errores en el Software).     El coste del proyecto. En definitiva se trata de un modelo más robusto y completo que el Modelo de Cascada, y puede producir software de mayor calidad que con el modelo de cascada (todo depende de la empresa ,el tipo de proyecto y el sector). En el modelo V podemos ver las mismas fases del modelo cascada pero con una mejor relación entre ellas.

LIMITES Los siguientes aspectos no están cubiertos por el V-Modelo, que debe ser regulado por otra parte, o el V-modelo debe adaptarse en consecuencia: La colocación de los contratos de servicios no está regulado. La organización y ejecución de la operación, mantenimiento, reparación y eliminación del sistema no están cubiertos por la V-Modelo. Sin embargo, la planificación y la preparación de un concepto de estas tareas están regulados en la V-Modelo. El V-Modelo se ocupa de desarrollo de software dentro de un proyecto en lugar de una organización.