Menú

¿Qué es STLC V-Model?

what is stlc v model

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

¿Qué es STLC V-Model?

Una de las principales desventajas de modelo STLC cascada fue que los defectos se encontraron en una etapa muy posterior del proceso de desarrollo, ya que las pruebas se realizaron al final del ciclo de desarrollo. Se volvió muy difícil y costoso arreglar los defectos, ya que se encontró en una etapa muy posterior. Para superar este problema, se introdujo un nuevo modelo de desarrollo llamado 'Modelo V'

El modelo V es ahora uno de los procesos de desarrollo de software más utilizados. La introducción del modelo V ha demostrado la implementación de pruebas desde la fase de requisitos. El modelo V también se denomina modelo de verificación y validación.

STLC V-Modelo

Lo que vas a aprender:

Verificación y validación

Para comprender el modelo V, primero comprendamos qué es la verificación y validación en el software.

Verificación : La verificación es una técnica de análisis estático. En esta técnica, las pruebas se realizan sin ejecutar el código. Los ejemplos incluyen: revisiones, inspección y recorrido.

Validación : La validación es una técnica de análisis dinámico en la que las pruebas se realizan ejecutando el código. Los ejemplos incluyen técnicas de prueba funcionales y no funcionales.

Modelo V

En el modelo V, las actividades de desarrollo y QA se realizan simultáneamente. No hay una fase discreta llamada Prueba, sino que la prueba comienza desde la fase de requisitos. Las actividades de verificación y validación van de la mano.

Para comprender el modelo V, veamos la siguiente figura:

Modelo STLC V

cómo devolver matrices en java

En un proceso de desarrollo típico, el lado izquierdo muestra las actividades de desarrollo y el lado derecho muestra las actividades de prueba. No debería equivocarme si digo que en la fase de desarrollo tanto la verificación como la validación se realizan junto con las actividades de desarrollo reales.

Ahora entendamos la figura:

Lado izquierdo

Como se dijo anteriormente, las actividades del lado izquierdo son actividades de desarrollo. Normalmente sentimos qué pruebas podemos hacer en la fase de desarrollo, pero esta es la belleza de este modelo que demuestra que las pruebas también se pueden realizar en todas las fases de las actividades de desarrollo.

Análisis de requisitos : En esta fase se recopilan, analizan y estudian los requisitos. Aquí, cómo se implementa el sistema, no es importante, pero lo que se supone que debe hacer el sistema, es importante. Sesiones de lluvia de ideas / tutorial, las entrevistas se realizan para tener claros los objetivos.

  • Actividades de verificación : Revisión de requisitos.
  • Actividades de validación : Creación de UAT ( Prueba de aceptación del usuario ) Casos de prueba
  • Artefactos producidos : Documento de comprensión de requisitos, casos de prueba UAT.

Requisitos del sistema / diseño de alto nivel : En esta fase, se construye el diseño de alto nivel del software. El equipo estudia e investiga cómo se podrían implementar los requisitos. También se estudia la viabilidad técnica de los requisitos. El equipo también presenta los módulos que se crearían / ​​dependencias, necesidades de hardware / software

  • Actividades de verificación : Revisiones de diseño
  • Actividades de validación : Creación de Plan de prueba del sistema y casos, Creación de métricas de trazabilidad
  • Artefactos producidos : Casos de prueba del sistema, informes de viabilidad, plan de prueba del sistema, requisitos de hardware y software y módulos a crear, etc.

Diseño arquitectonico: En esta fase, basada en el diseño de alto nivel , Se crea la arquitectura del software. Los módulos, sus relaciones y dependencias, los diagramas de arquitectura, las tablas de la base de datos y los detalles de la tecnología se finalizan en esta fase.

  • Actividades de verificación : Revisiones de diseño
  • Actividades de validación : Plan de pruebas de integración y casos de prueba.
  • Artefactos producidos : Documentos de diseño, planes de prueba de integración y casos de prueba, diseños de tablas de bases de datos, etc.

Diseño de módulo / Diseño de bajo nivel: En esta fase, todos y cada uno de los módulos de los componentes del software se diseñan individualmente. Los métodos, clases, interfaces, tipos de datos, etc. se finalizan en esta fase.

  • Actividades de verificación : Revisiones de diseño
  • Actividades de validación : Creación y revisión de casos de prueba unitarios.
  • Artefactos producidos : Casos de prueba unitarios,

Implementación / Código : En esta fase, se realiza la codificación real.

  • Actividades de verificación : Revisión de código, revisión de casos de prueba
  • Actividades de validación : Creación de casos de prueba funcionales.
  • Artefactos producidos : casos de prueba, lista de verificación de revisión.

Lado derecho

El lado derecho muestra las actividades de prueba o la fase de validación. Empezaremos desde abajo.

Examen de la unidad: En esta fase, se ejecutan todos los casos de prueba unitarios, creados en la fase de diseño de bajo nivel.

* La prueba unitaria es una técnica de prueba de caja blanca, donde se escribe un fragmento de código que invoca un método (o cualquier otro fragmento de código) para probar si el fragmento de código está dando el resultado esperado o no. Esta prueba la realiza básicamente el equipo de desarrollo. En caso de cualquier anomalía, los defectos se registran y se rastrean.

Artefactos producidos : Resultados de la ejecución de la prueba unitaria

Pruebas de integración : En esta fase se ejecutan los casos de prueba de integración que se crearon en la fase de diseño arquitectónico. En caso de anomalías, los defectos se registran y se rastrean.

Prueba de integración: La prueba de integración es una técnica en la que los módulos probados por la unidad se integran y se prueban si los módulos integrados están dando los resultados esperados. En palabras más simples, valida si los componentes de la aplicación funcionan juntos como se esperaba.

Artefactos producidos : Resultados de la prueba de integración.

Prueba de sistemas : En esta fase se ejecutan todos los casos de prueba del sistema, casos de prueba funcionales y casos de prueba no funcionales. En otras palabras, aquí se realiza la prueba real y completa de la aplicación. Los defectos se registran y se rastrean para su cierre. Los informes de progreso también son una parte importante de esta fase. Las métricas de trazabilidad se actualizan para comprobar la cobertura y el riesgo mitigado.

Artefactos producidos : Resultados de prueba, registros de prueba, informe de defectos, informe de resumen de prueba y matrices de trazabilidad actualizadas.

Pruebas de aceptación del usuario : Las pruebas de aceptación están básicamente relacionadas con las pruebas de requisitos comerciales. Aquí se realizan pruebas para validar que se cumplen los requisitos comerciales en el entorno del usuario. Pruebas de compatibilidad y, a veces, pruebas no funcionales ( Carga, estrés y volumen ) también se realizan pruebas en esta fase.

Artefactos producidos : Resultados UAT, matrices de cobertura empresarial actualizadas.

¿Cuándo usar el modelo V?

El modelo V es aplicable cuando:

  • El requisito está bien definido y no es ambiguo.
  • Los criterios de aceptación están bien definidos.
  • El proyecto es de tamaño corto a mediano.
  • La tecnología y las herramientas utilizadas no son dinámicas.

Pros y contras de usar el modelo V

PROSCONTRAS
- El desarrollo y el progreso es muy organizado y sistemático.-No apto para proyectos más grandes y complejos
- Funciona bien para proyectos de tamaño pequeño a mediano.- No apto si los requisitos no son consistentes.
- Las pruebas comienzan desde el principio, por lo que las ambigüedades se identifican desde el principio.- No se produce ningún software de trabajo en la etapa intermedia.
- Fácil de gestionar ya que cada fase tiene objetivos y metas bien definidos.- No hay disposición para realizar análisis de riesgos, por lo que existen incertidumbres y riesgos.

Lectura recomendada

^