SDLC - Modelo V
El modelo V es un modelo SDLC en el que la ejecución de los procesos se realiza de forma secuencial en forma de V. También se conoce comoVerification and Validation model.
El V-Model es una extensión del modelo en cascada y se basa en la asociación de una fase de prueba para cada etapa de desarrollo correspondiente. Esto significa que para cada fase del ciclo de desarrollo, existe una fase de prueba directamente asociada. Este es un modelo muy disciplinado y la siguiente fase comienza solo después de completar la fase anterior.
V-Model - Diseño
Bajo el V-Model, la correspondiente fase de prueba de la fase de desarrollo está planificada en paralelo. Entonces, hay fases de Verificación en un lado de las fases 'V' y Validación en el otro lado. La fase de codificación une los dos lados del modelo V.
La siguiente ilustración muestra las diferentes fases en un modelo V del SDLC.
Modelo V - Fases de verificación
Hay varias fases de verificación en el modelo V, cada una de las cuales se explica en detalle a continuación.
Análisis de requisitos comerciales
Esta es la primera fase del ciclo de desarrollo en la que los requisitos del producto se entienden desde la perspectiva del cliente. Esta fase implica una comunicación detallada con el cliente para comprender sus expectativas y requisitos exactos. Esta es una actividad muy importante y debe gestionarse bien, ya que la mayoría de los clientes no están seguros de lo que necesitan exactamente. losacceptance test design planning se realiza en esta etapa, ya que los requisitos comerciales se pueden utilizar como entrada para las pruebas de aceptación.
Diseño de sistemas
Una vez que tenga los requisitos del producto claros y detallados, es hora de diseñar el sistema completo. El diseño del sistema comprenderá y detallará la configuración completa del hardware y la comunicación para el producto en desarrollo. El plan de prueba del sistema se desarrolla en base al diseño del sistema. Hacer esto en una etapa anterior deja más tiempo para la ejecución real de la prueba más adelante.
Diseño arquitectonico
Las especificaciones arquitectónicas se entienden y diseñan en esta fase. Por lo general, se propone más de un enfoque técnico y, en función de la viabilidad técnica y financiera, se toma la decisión final. El diseño del sistema se divide en módulos que asumen diferentes funciones. Esto también se conoce comoHigh Level Design (HLD).
La transferencia de datos y la comunicación entre los módulos internos y con el mundo exterior (otros sistemas) se entiende y define claramente en esta etapa. Con esta información, se pueden diseñar y documentar pruebas de integración durante esta etapa.
Diseño de módulo
En esta fase, se especifica el diseño interno detallado de todos los módulos del sistema, denominado Low Level Design (LLD). Es importante que el diseño sea compatible con los otros módulos de la arquitectura del sistema y los otros sistemas externos. Las pruebas unitarias son una parte esencial de cualquier proceso de desarrollo y ayudan a eliminar el máximo de fallas y errores en una etapa muy temprana. Estas pruebas unitarias se pueden diseñar en esta etapa en función de los diseños de los módulos internos.
Fase de codificación
La codificación real de los módulos del sistema diseñados en la fase de diseño se retoma en la fase de Codificación. El lenguaje de programación más adecuado se decide en función del sistema y los requisitos arquitectónicos.
La codificación se realiza según las directrices y estándares de codificación. El código pasa por numerosas revisiones de código y está optimizado para un mejor rendimiento antes de que la compilación final se registre en el repositorio.
Fases de validación
Las diferentes fases de validación en un modelo V se explican en detalle a continuación.
Examen de la unidad
Las pruebas unitarias diseñadas en la fase de diseño del módulo se ejecutan en el código durante esta fase de validación. La prueba unitaria es la prueba a nivel de código y ayuda a eliminar errores en una etapa temprana, aunque no todos los defectos pueden ser descubiertos por la prueba unitaria.
Pruebas de integración
Las pruebas de integración están asociadas con la fase de diseño arquitectónico. Se realizan pruebas de integración para probar la coexistencia y comunicación de los módulos internos dentro del sistema.
Prueba del sistema
La prueba del sistema está directamente asociada con la fase de diseño del sistema. Las pruebas del sistema verifican toda la funcionalidad del sistema y la comunicación del sistema en desarrollo con sistemas externos. La mayoría de los problemas de compatibilidad de software y hardware se pueden descubrir durante la ejecución de esta prueba del sistema.
Test de aceptación
Las pruebas de aceptación están asociadas con la fase de análisis de requisitos comerciales e implican probar el producto en el entorno del usuario. Las pruebas de aceptación descubren los problemas de compatibilidad con los otros sistemas disponibles en el entorno del usuario. También descubre los problemas no funcionales, como la carga y los defectos de rendimiento en el entorno del usuario real.
V- Modelo ─ Aplicación
La aplicación del modelo V es casi la misma que la del modelo en cascada, ya que ambos modelos son de tipo secuencial. Los requisitos deben ser muy claros antes de que comience el proyecto, ya que generalmente es costoso regresar y hacer cambios. Este modelo se utiliza en el campo del desarrollo médico, ya que es un dominio estrictamente disciplinado.
Los siguientes indicadores son algunos de los escenarios más adecuados para utilizar la aplicación V-Model.
Los requisitos están bien definidos, claramente documentados y fijados.
La definición del producto es estable.
La tecnología no es dinámica y el equipo del proyecto la comprende bien.
No hay requisitos ambiguos o indefinidos.
El proyecto es corto.
V-Model - Pros y contras
La ventaja del método V-Model es que es muy fácil de entender y aplicar. La sencillez de este modelo también facilita su gestión. La desventaja es que el modelo no es flexible a los cambios y en caso de que haya un cambio de requisito, que es muy común en el mundo dinámico actual, se vuelve muy costoso realizar el cambio.
Las ventajas del método V-Model son las siguientes:
Este es un modelo muy disciplinado y las fases se completan una a la vez.
Funciona bien para proyectos más pequeños donde los requisitos se entienden muy bien.
Simple y fácil de entender y usar.
Fácil de manejar debido a la rigidez del modelo. Cada fase tiene entregables específicos y un proceso de revisión.
Las desventajas del método V-Model son las siguientes:
Alto riesgo e incertidumbre.
No es un buen modelo para proyectos complejos y orientados a objetos.
Modelo deficiente para proyectos largos y en curso.
No es adecuado para los proyectos donde los requisitos tienen un riesgo de cambio de moderado a alto.
Una vez que una aplicación está en la etapa de prueba, es difícil volver atrás y cambiar una funcionalidad.
No se produce ningún software que funcione hasta tarde durante el ciclo de vida.