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.
-
El cliente, no recibe nada que funcione hasta el final de proyecto.
No hay prototipos.
¿En
que casos se utiliza?
Es
un sistema flexible y robusto a la vez, apto para pequeños proyectos
tanto individuales como de equipo (2-5 personas).
También
es muy sencillo, útil para nuevos desarrolladores con poca
experiencia en el uso de metodologías.
Referencias:
Links
Interesantes:
