V-Model (desarrollo de software) - V-Model (software development)
| Desarrollo de software |
|---|
En el desarrollo de software , el modelo V representa un proceso de desarrollo que puede considerarse una extensión del modelo en cascada y es un ejemplo del modelo V más general . En lugar de moverse hacia abajo de forma lineal, los pasos del proceso se doblan hacia arriba después de la fase de codificación , para formar la típica forma de V. El V-Model demuestra las relaciones entre cada fase del ciclo de vida del desarrollo y su fase de prueba asociada . Los ejes horizontal y vertical representan el tiempo o la integridad del proyecto (de izquierda a derecha) y el nivel de abstracción (la abstracción de grano más grueso hacia arriba), respectivamente.
Fases de la definición del proyecto
Análisis de requerimientos
En la fase de análisis de requisitos , el primer paso en el proceso de verificación, los requisitos del sistema se recopilan mediante el análisis de las necesidades de los usuarios . Esta fase se ocupa de establecer qué debe realizar el sistema ideal. Sin embargo, no determina cómo se diseñará o construirá el software. Por lo general, se entrevista a los usuarios y se genera un documento denominado documento de requisitos del usuario.
El documento de requisitos del usuario normalmente describirá los requisitos funcionales, de interfaz, rendimiento, datos, seguridad, etc. del sistema, según lo esperado por el usuario. Los analistas de negocios lo utilizan para comunicar a los usuarios su comprensión del sistema. Los usuarios revisan cuidadosamente este documento, ya que este documento serviría como guía para los diseñadores del sistema en la fase de diseño del sistema. Las pruebas de aceptación del usuario se diseñan en esta fase. Consulte también Requisitos funcionales .
Existen diferentes métodos para recopilar requisitos de metodologías tanto blandas como duras, que incluyen; entrevistas, cuestionarios, análisis de documentos, observación, prototipos desechables, casos de uso y vistas estáticas y dinámicas con los usuarios.
Diseño de sistemas
El diseño de sistemas es la fase en la que los ingenieros de sistemas analizan y comprenden el negocio del sistema propuesto mediante el estudio del documento de requisitos del usuario. Descubren posibilidades y técnicas mediante las cuales se pueden implementar los requisitos del usuario. Si alguno de los requisitos no es factible, se informa al usuario del problema. Se encuentra una resolución y el documento de requisitos del usuario se edita en consecuencia.
Se genera el documento de especificación de software que sirve como modelo para la fase de desarrollo. Este documento contiene la organización general del sistema, las estructuras de menú, las estructuras de datos, etc. También puede contener ejemplos de escenarios comerciales, ventanas de muestra e informes para ayudar a la comprensión. En esta fase también se producirá otra documentación técnica como diagramas de entidades y diccionario de datos. Se preparan los documentos para la prueba del sistema.
Diseño arquitectónico
La fase del diseño de la arquitectura de la computadora y la arquitectura del software también puede denominarse diseño de alto nivel. La base para seleccionar la arquitectura es que debe realizar todo lo que normalmente consiste en la lista de módulos, la funcionalidad breve de cada módulo, sus relaciones de interfaz , dependencias , tablas de base de datos , diagramas de arquitectura, detalles de tecnología, etc. Se lleva a cabo el diseño de prueba de integración en la fase particular.
Diseño de módulo
La fase de diseño del módulo también se puede denominar diseño de bajo nivel. El sistema diseñado se divide en unidades o módulos más pequeños y se explica cada uno de ellos para que el programador pueda comenzar a codificar directamente. El documento de diseño de bajo nivel o las especificaciones del programa contendrán una lógica funcional detallada del módulo , en pseudocódigo :
- tablas de base de datos, con todos los elementos, incluido su tipo y tamaño
- todos los detalles de la interfaz con referencias completas de API
- todos los problemas de dependencia
- listados de mensajes de error
- entradas y salidas completas para un módulo.
El diseño de la prueba unitaria se desarrolla en esta etapa.
Fases de validación
En el modelo V, cada etapa de la fase de verificación tiene una etapa correspondiente en la fase de validación. Las siguientes son las fases típicas de validación en el V-Model, aunque pueden ser conocidas por otros nombres.
Examen de la unidad
En el modelo V, los planes de prueba unitarios (UTP) se desarrollan durante la fase de diseño del módulo. Estos UTP se ejecutan para eliminar errores a nivel de código o de unidad. Una unidad es la entidad más pequeña que puede existir de forma independiente, por ejemplo, un módulo de programa. La prueba unitaria verifica que la entidad más pequeña puede funcionar correctamente cuando está aislada del resto de los códigos / unidades.
Pruebas de integración
Los planes de prueba de integración se desarrollan durante la fase de diseño arquitectónico. Estas pruebas verifican que las unidades creadas y probadas de forma independiente puedan coexistir y comunicarse entre sí. Los resultados de las pruebas se comparten con el equipo del cliente.
Prueba del sistema
Los planes de pruebas del sistema se desarrollan durante la fase de diseño del sistema. A diferencia de los planes de prueba de unidad e integración, los planes de prueba del sistema están compuestos por el equipo comercial del cliente. System Test asegura que se cumplan las expectativas de la aplicación desarrollada. Toda la aplicación se prueba por su funcionalidad, interdependencia y comunicación. La prueba del sistema verifica que se cumplan los requisitos funcionales y no funcionales. Las pruebas de carga y rendimiento, las pruebas de estrés, las pruebas de regresión , etc., son subconjuntos de las pruebas del sistema.
Pruebas de aceptación del usuario
Los planes de prueba de aceptación del usuario (UAT) se desarrollan durante la fase de análisis de requisitos. Los planes de prueba están compuestos por usuarios comerciales. UAT se realiza en un entorno de usuario que se asemeja al entorno de producción, utilizando datos realistas. UAT verifica que el sistema entregado cumpla con los requisitos del usuario y que el sistema esté listo para usarse en tiempo real.
Crítica
El V-Model ha sido criticado por los defensores de Agile y otros como un modelo inadecuado de desarrollo de software por numerosas razones. Las críticas incluyen:
- Es demasiado simple para reflejar con precisión el proceso de desarrollo de software y puede llevar a los gerentes a una falsa sensación de seguridad. El V-Model refleja una visión de la gestión de proyectos del desarrollo de software y se adapta a las necesidades de los directores de proyectos, contables y abogados en lugar de a los desarrolladores o usuarios de software.
- Aunque los principiantes lo entienden fácilmente, esa comprensión temprana es útil solo si el principiante adquiere una comprensión más profunda del proceso de desarrollo y cómo el V-Model debe adaptarse y ampliarse en la práctica. Si los practicantes persisten con su visión ingenua del V-Model, tendrán grandes dificultades para aplicarlo con éxito.
- Es inflexible y fomenta una visión rígida y lineal del desarrollo de software y no tiene una capacidad inherente para responder al cambio.
- Proporciona solo una ligera variante del modelo en cascada y, por lo tanto, está sujeto a las mismas críticas que ese modelo. Proporciona un mayor énfasis en las pruebas y, en particular, la importancia de la planificación temprana de las pruebas. Sin embargo, una crítica práctica común del V-Model es que lleva a que las pruebas se compriman en ventanas estrechas al final del desarrollo cuando las etapas anteriores se han superado pero la fecha de implementación permanece fija.
- Es consistente con, y por lo tanto fomenta implícitamente, enfoques ineficientes e ineficaces de las pruebas. Implica implícitamente la redacción de guiones de prueba por adelantado en lugar de pruebas exploratorias; anima a los evaluadores a buscar lo que esperan encontrar, en lugar de descubrir lo que realmente está allí. También fomenta un vínculo rígido entre los niveles equivalentes de cualquiera de las ramas (por ejemplo, los planes de prueba de aceptación del usuario que se derivan de los documentos de requisitos del usuario), en lugar de alentar a los evaluadores a seleccionar la forma más eficaz y eficiente de planificar y ejecutar las pruebas.
- Carece de coherencia y precisión. Existe una confusión generalizada sobre qué es exactamente el modelo V. Si uno se reduce a aquellos elementos en los que la mayoría de la gente estaría de acuerdo, se convierte en una representación trivial e inútil del desarrollo de software. El desacuerdo sobre los méritos del V-Model a menudo refleja una falta de comprensión compartida de su definición.
Estado actual
Los partidarios del V-Model argumentan que ha evolucionado con el tiempo y respalda la flexibilidad y la agilidad durante todo el proceso de desarrollo. Argumentan que, además de ser un enfoque altamente disciplinado, promueve el diseño, el desarrollo y la documentación meticulosos necesarios para construir productos de software estables. Últimamente, está siendo adoptado por la industria de dispositivos médicos.
Ver también
Referencias
Otras lecturas
- Roger S. Pressman: Ingeniería de software: el enfoque de un profesional , The McGraw-Hill Companies, ISBN 0-07-301933-X
- Mark Hoffman y Ted Beaumont: Desarrollo de aplicaciones: Gestión del ciclo de vida del proyecto , Mc Press, ISBN 1-883884-45-4
- Boris Beizer: Técnicas de prueba de software. Segunda edición, International Thomson Computer Press, 1990, ISBN 1-85032-880-3