Els Cicles de Vida del SW: MODELO EN V

MODELO EN V

Introducción

Que pasaría, si en la construcción de nuestra casa, nosotros como obreros, empezásemos a colocar ladrillos, allí donde nos pareciese correcto, pues que si no lo pensamos dos veces, quizás después tengamos que tirar algunas paredes, para meter la bañera.

Esto es lo que pasa con la programación, al ser algo abstracto, no tangible, no le damos demasiada importancia y empezamos a escribir código, sabiendo donde queremos llegar, pero sin saber con certeza cual camino elegir.

De aquí la importancia de los modelos o metodologías de programación.

Concepto Modelo en V

El “modelo en V” se desarrolló para terminar con algunos de los problemas que se detectaron utilizando el enfoque de cascada tradicional.

Uno de estos problemas, era que los defectos estaban siendo encontrados demasiado tarde en el ciclo de vida, ya que las pruebas no se introducían hasta el final del proyecto.

El “modelo en V” dice que las pruebas necesitan empezarse lo más pronto posible en el ciclo de vida.

En definitiva, el “modelo en V” es un modelo que demuestra cómo las actividades de prueba (verificación y validación) se pueden integrar en cada fase del ciclo de vida.

En los niveles del 1 al 4, para cada fase del desarrollo, existe una fase paralela de verificación o validación. Esta estructura obedece al principio de que para cada fase del desarrollo debe existir un resultado verificable.

En la misma estructura se advierte también que la proximidad entre una fase del desarrollo y su fase de verificación correspondiente va decreciendo a medida que aumenta el nivel dentro de la V. La longitud de esta separación intenta ser proporcional a la distancia en el tiempo entre una fase y su homóloga de verificación.

El nivel 1 está orientado al “cliente”. El inicio del proyecto y el fin del proyecto constituyen los dos extremos del ciclo. Se compone del análisis de requisitos y especificaciones, se traduce en un documento de requisitos y especificaciones.

El nivel 2 se dedica a las características de funcionamiento del software. Podemos decir que el software es un lienzo en blanco, y sabiendo lo que el cliente quiere, nosotros como programadores delimitamos los contornos, hacemos un esbozo de la interfaz del software y comprobamos con el cliente que vamos por buen camino, se traduce en un documento de análisis funcional.

El nivel 3 define los componentes hardware y software del sistema final, a cuyo conjunto se denomina arquitectura del sistema. Siguiendo el símil, podríamos decir que una vez tenemos, el esbozo del dibujo, elegiremos nuestras herramientas para pintar: tipo de pintura, grosor del pincel, colores que usaremos.

El nivel 4 es la fase de implementación, en la que se desarrollan los elementos unitarios o módulos del programa. Una vez tenemos clara la idea del cliente, el esbozo y las herramientas adecuadas podemos empezar a codificar el código.

Cascada VS Modelo en V

Comparando con el modelo en cascada, las etapas individualmente son las mismas. Sin embargo hay una gran diferencia. En vez de ir para abajo de una forma lineal las fases del proceso vuelven hacia arriba tras la fase de codificación, formando una V, ya que para cada una de las fases de diseño se ha encontrado un homólogo en las fases de pruebas. Las cuales, no deben dejarse para el final, tras la codificación.

Ventajas e Inconvenientes

Ventajas:

- Simplicidad y sencillez, fácil de utilizar

- Ya que las pruebas son paralelas al desarrollo.

- Fácil y rápida detección de fallos.

- Alta probabilidad de éxito. Poco riesgo.

- Involucra al cliente/usuario en el desarrollo

- Rígido y robusto, bueno para pequeños proyectos, y desarrolladores con poca experiencia.

Inconvenientes:

- Rígido, al igual que el de cascada, no apto para grandes proyectos.

- El alto numero de pruebas, pueden ser costosas (dinero y tiempo), para su eficacia.

- El cliente, puede que no especifique bien sus requisitos. Cambios de idea o necesidades.