Ingeniería de Software | SDLC V-Modelo

El modelo V es un tipo de modelo SDLC donde el proceso se ejecuta de manera secuencial en forma de V. También se conoce como modelo de Verificación y Validación. Se basa en la asociación de una fase de prueba para cada etapa de desarrollo correspondiente. Desarrollo de cada paso asociado directamente a la fase de pruebas. La siguiente fase comienza solo después de la finalización de la fase anterior, es decir, para cada actividad de desarrollo, hay una actividad de prueba que le corresponde. 
 

V-Model

Verificación: Se trata de una técnica de análisis estático (revisión) realizada sin ejecutar código. Es el proceso de evaluación de la fase de desarrollo del producto para determinar si se cumplen los requisitos especificados. 

Validación: Implica técnica de análisis dinámico (funcional, no funcional), pruebas realizadas mediante código en ejecución. La validación es el proceso para evaluar el software después de completar la fase de desarrollo para determinar si el software cumple con las expectativas y los requisitos del cliente. 

Entonces, V-Model contiene fases de verificación en un lado y fases de validación en el otro lado. Las fases de Verificación y Validación están unidas por la fase de codificación en forma de V. Por eso se llama V-Modelo. 

Fase de diseño: 
 

  • Análisis de requisitos: esta fase contiene una comunicación detallada con el cliente para comprender sus requisitos y expectativas. Esta etapa se conoce como Recopilación de Requisitos.
  • Diseño del sistema: esta fase contiene el diseño del sistema y la configuración completa del hardware y la comunicación para desarrollar el producto.
  • Diseño arquitectónico: el diseño del sistema se desglosa en módulos que asumen diferentes funcionalidades. La transferencia de datos y la comunicación entre los módulos internos y con el mundo exterior (otros sistemas) se entiende claramente.
  • Diseño de Módulos: En esta fase el sistema se descompone en pequeños módulos. Se especifica el diseño detallado de los módulos, también conocido como Low-Level Design (LLD).

Fases de prueba: 
 

  • Pruebas unitarias: los planes de pruebas unitarias se desarrollan durante la fase de diseño del módulo. Estos planes de prueba de unidad se ejecutan para eliminar errores a nivel de código o unidad.
  • Pruebas de integración: después de completar las pruebas unitarias, se realizan las pruebas de integración. En las pruebas de integración, se integran los módulos y se prueba el sistema. Las pruebas de integración se realizan en la fase de diseño de la Arquitectura. Esta prueba verifica la comunicación de los módulos entre sí.
  • Pruebas del sistema: las pruebas del sistema prueban la aplicación completa con su funcionalidad, interdependencia y comunicación. Prueba los requisitos funcionales y no funcionales de la aplicación desarrollada.
  • Prueba de aceptación del usuario (UAT): UAT se realiza en un entorno de usuario que se asemeja al entorno de producción. UAT verifica que el sistema entregado cumpla con los requisitos del usuario y que el sistema esté listo para usarse en el mundo real.

Desafío industrial: a medida que la industria ha evolucionado, las tecnologías se han vuelto más complejas, cada vez más rápidas y en constante cambio; sin embargo, sigue existiendo un conjunto de principios y conceptos básicos que son tan aplicables hoy como cuando la TI estaba en su infancia. 
 

  • Defina con precisión y perfeccione los requisitos del usuario.
  • Diseñar y construir una aplicación de acuerdo con los requisitos del usuario autorizado.
  • Validar que la aplicación que habían construido cumpliera con los requisitos comerciales autorizados.

Principios del modelo V: 
 

  • De grande a pequeño: en V-Model, las pruebas se realizan en una perspectiva jerárquica, por ejemplo, los requisitos identificados por el equipo del proyecto, crean las fases de diseño de alto nivel y diseño detallado del proyecto. A medida que se completa cada una de estas fases, los requisitos que se definen se vuelven cada vez más refinados y detallados.
  • Integridad de datos/procesos: este principio establece que el diseño exitoso de cualquier proyecto requiere la incorporación y cohesión de datos y procesos. Los elementos del proceso deben identificarse en todos y cada uno de los requisitos.
  • Escalabilidad: este principio establece que el concepto V-Model tiene la flexibilidad para adaptarse a cualquier proyecto de TI, independientemente de su tamaño, complejidad o duración.
  • Referencias cruzadas: la correlación directa entre los requisitos y la actividad de prueba correspondiente se conoce como referencias cruzadas.
  • Documentación tangible: este principio establece que cada proyecto necesita crear un documento. Esta documentación es requerida y aplicada tanto por el equipo de desarrollo del proyecto como por el equipo de soporte. La documentación se utiliza para mantener la aplicación una vez que está disponible en un entorno de producción.

¿Por qué preferido? 
 

  • Es fácil de manejar debido a la rigidez del modelo. Cada fase de V-Model tiene resultados específicos y un proceso de revisión.
  • Seguimiento proactivo de defectos, es decir, los defectos se encuentran en una etapa temprana.

¿Cuándo usar? 
 

  • Donde los requisitos están claramente definidos y fijados.
  • El modelo V se utiliza cuando se dispone de amplios recursos técnicos con experiencia técnica.

ventajas: 
 

  • Este es un modelo altamente disciplinado y las Fases se completan una a la vez.
  • El modelo V se utiliza para proyectos pequeños donde los requisitos del proyecto son claros.
  • Simple y fácil de entender y usar.
  • Este modelo se centra en las actividades de verificación y validación en las primeras etapas del ciclo de vida, lo que mejora la probabilidad de crear un producto de buena calidad y sin errores.
  • Permite a la gestión de proyectos realizar un seguimiento del progreso con precisión.

Desventajas: 
 

  • Alto riesgo e incertidumbre.
  • No es bueno para proyectos complejos y orientados a objetos.
  • No es adecuado para proyectos donde los requisitos no son claros y contienen un alto riesgo de cambio.
  • Este modelo no admite la iteración de fases.
  • No maneja fácilmente eventos concurrentes.

Publicación traducida automáticamente

Artículo escrito por Dharmendra_Kumar y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *