Modelo V (desarrollo de software)
Propuesto por Alan Davis, el modelo en V es el proceso de desarrollo de software que se define por ser la extensión del modelo de la cascada. En lugar de realizar sus procesos de manera lineal y descendente, los pasos del proceso son manejados de manera ascendente después de la fase de codificación, para crear la típica forma de V
Fases de la verificación
· Análisis de requisitos
En esta fase, los requisitos del sistema propuesto son analizados de acuerdo a las necesidades de los usuarios. Esta fase se refiere a establecer lo que tiene que realizarse para obtener un sistema ideal. Sin embargo, no se determina cómo el software será diseñado o construido. Generalmente, se entrevistan a los usuarios y un documento llamado “documento de las exigencias del consumidor” se genera. El documento describirá típicamente la funcionalidad del sistema, la interfaz, el funcionamiento, los datos y seguridad esperado por el usuario.
Los usuarios verifican cuidadosamente este documento pues serviría como la pauta para los diseñadores de sistema en la fase de diseño del sistema. Las pruebas de aceptación de usuario se diseñan en esta fase.
· Diseño del sistema
Los técnicos analizan y entienden el sistema propuesto estudiando el documento de las exigencias del consumidor. Calculan las posibilidades y las técnicas que pueden ser implementadas. Si alguno de los requisitos no puede ser llevado a cabo, el usuario es informado al respecto. Se encuentra una resolución y el documento de la exigencia del consumidor se corrige por consiguiente.
El documento de especificación de software que sirve como pilar para la fase de desarrollo se genera. Este documento contiene la organización general del sistema, estructuras del menú, estructuras de datos, etc. Puede también llevar a cabo ejemplos del panorama del negocio, ventanas de la muestra, etc. Otra documentación técnica como diagramas de entidad o diccionario de los datos también será producida en esta fase. Los documentos para la prueba del sistema se elaboran en esta fase.
· Diseño de la arquitectura
Esta fase se puede también llamar como diseño de alto nivel. La base para seleccionar la arquitectura idónea es que debe realizar todo que consista en una lista de módulos, una muestra funcionalidad de cada módulo, su interfaz, tablas de bases de datos, diagramas de la arquitectura, detalles tecnológicos a implementar, etc. El diseño de prueba de integración se realiza en esta fase.
· Diseño del módulo
Esta fase se puede también llamar como diseño de bajo nivel. El sistema de diseño está repartido en unidades más pequeñas o módulos y cada una de ellas se explica de modo que el programador pueda comenzar a codificar directamente. Las especificaciones del documento del programa de diseño de nivel bajo contendrán funcionalidades lógicas detalladas en cada módulo, en forma de pseudocódigo y contendrán: tablas de bases de datos, con todos los elementos, incluyendo su tipo y tamaño - todos los detalles del interfaz con referencias completas sobre su API, mensaje de error listados y terminales la entrada y las salidas para cada módulo. El diseño de prueba de unidad se desarrolla en esta etapa.
Fases de la validación
· Prueba de la unidad
Implica la primera etapa de prueba dinámica del proceso. Es el método por el cual cada unidad del código será examinado para determinar si es factible su aplicación al producto final o no
Implica el análisis del código escrito con la intención de eliminar errores. También verifica que los códigos sean eficientes y adhiere estándares de codificación. Se hace un análisis usando el diseño de prueba de unidad elaborado durante la fase de diseño del módulo. Esto se puede realizar por los probadores de software. Se realiza en forma de caja blanca (detalles de procedimiento de software y está ligado al código fuente)
· Prueba de la integración
Los módulos verificados de manera individual se probarán en conjunto para presentar averías en interfaces y en la interacción entre los componentes integrados. La prueba se genera en caja negra (pruebas de funcionalidad y qué está realizando el programa).
· Prueba del sistema
La prueba del sistema comparará las especificaciones del sistema contra el sistema real. El diseño de prueba del sistema se deriva de los documentos del diseño del sistema y se utiliza en esta fase. La prueba del sistema está a veces automatizado para usar herramientas de prueba. Una vez que se integren todos los módulos varios errores pueden presentarse. La prueba hecha en esta etapa se llama prueba del sistema.
· Prueba de aceptación de usuario
Se realiza:
- Para determinar si un sistema satisface los criterios del usuario
- Para permitirle al cliente determinar si acepta el sistema o no
- Para probar el software en el “del mundo real”
Propósito de la prueba de aceptación:
- Para verificar el sistema y/o posibles cambios según las necesidades originales
Procedimientos para conducir la prueba de aceptación:
Definir los criterios de la aceptación:
- Requisitos de funcionalidad
- Requisitos de rendimiento
- Requisitos de calidad del interfaz
- Requisitos de calidad en general del software
- Descripción del proyecto
- Responsabilidades del usuario
- Descripción de la aceptación
- Ejecución del plan de prueba de aceptación
Ventajas
El modelo V despliega un método bien estructurado en el cual cada fase se puede poner en ejecución por la documentación detallada de la fase anterior. Las actividades como diseño de prueba empiezan desde el principio del proyecto antes de la codificación y por lo tanto ahorran una cantidad enorme del tiempo del proyecto.
No hay comentarios:
Publicar un comentario