1. Ciencias de la Ingeniería
Trabajo de Investigación
Método V
Cátedra
Administración de Proyectos
Tutor
Ing. Richard Ramírez Anormaliza
Alumna
Mayra Romero Alava
Noveno Semestre

2. Método en V
El método en V son procesos que representan los pasos en el desarrollo del ciclo de vida de un
proyecto donde “V” significa verificación y validación, es similar al modelo de cascada por su
rigidez y contiene iteraciones. Está compuesto por las actividades y los resultados que se deben
obtener durante el desarrollo del proyecto, el lado izquierdo consta de las necesidades y
especificaciones del sistema; el lado derecho consta de la integración de las piezas y su
verificación.
La versión actual del Método-V es el Método-V XT terminada en Febrero del 2005. No se compara
con CMMI ya que esta solo describe “qué” se ha hecho, el Método-V describe el “cómo” y el
“cuándo” y “quién” es el responsable de haberlo hecho.
Objetivos del Método en V
La administración federal alemana desarrollo este método con el fin de regular los procesos del
desarrollo de software en la cual se plantean las actividades y los resultados que se obtienen con
el proyecto entre las cuales tenemos:
 Minimización de los riesgos del proyecto: mejora la transparencia y control del
proyecto, se describen resultados y las responsabilidades de cada función, permite que se
detecten a tiempo los riesgos y las correcciones de los procesos reduciendo riesgos en el
proyecto.
 Mejoramiento y garantía de calidad: es un modelo de procesos estándares que nos
asegura obtener resultados con la calidad deseada.
 Reducción de los gastos totales durante todo el proyecto y sistema de ciclo de vida:
todo el proceso del ciclo de vida de un sistema lo podemos calcular y controlar mediante la
aplicación de procesos estandarizados, así se reducen la dependencia de los proveedores.
 Mejora de la comunicación entre todos los inversionistas: mediante la descripción
estandarizada de los términos.
Partes del método
El método V representa el ciclo de vida del desarrollo del sistema. La corriente de especificación
(parte izquierda) consiste en:
 Especificaciones de requerimiento de usuario
 Especificaciones funcionales
 Especificaciones de diseño
La corriente de pruebas (parte derecha), por su parte consiste en: Calificación de instalación
 Calificación operacional
 Calificación de rendimiento
La corriente de desarrollo depende del tipo de sistema y del alcance del desarrollo pero
generalmente consiste en personalización, configuración, o codificación.
Modelos del ciclo de vida
Los modelos del ciclo de vida se crearon con el objetivo de facilitar la metodología entre el cliente y
la compañía para reflejar las etapas de desarrollo y la documentación que se requiere de esta
manera se valida cada etapa antes de que se empiece con las siguientes, de aquí decimos que el

3. modelo en V proviene del principio que establece que los procedimientos utilizados para probar si
la aplicación cumple las especificaciones ya deben haberse creado en la fase de diseño.
Tipos de prueba
A medida que se involucre un nuevo sistema un gran número de pruebas del software evalúan el
sistema. Los principales tipos de pruebas de software. Los procedimientos utilizados para asegurar
que la aplicación cumple con todas las especificaciones se crean en la fase de diseño son:
:
 Componente
 Interfaz
 Sistema
 Aceptación
 Publicación
Etapas de método en V
Las etapas de este modelo son casi las mismas que en el modelo de cascada.
 Caso de negocios El primer paso en el desarrollo de negocios es una investigación
seguida por un "Business Case", producido por el cliente para un sistema. Esto plantea un
nuevo sistema, o cambiar a un sistema existente, que se prevé producirá beneficios
empresariales, y se esbozan los costes previstos en el desarrollo y funcionamiento del
sistema.
 Requerimientos: El paso siguiente consiste en una amplia definición de un conjunto de
"requisitos", que es una declaración por parte del cliente de lo que el sistema deberá
alcanzar para satisfacer las necesidades. Estos involucran tanto funcionales y no
funcionales requisitos. Para más detalles, en el artículo de requisitos.
 Análisis de necesidades y definición: Es aquí donde se detalla los requisitos del sistema
que deben ser desarrollados. Los requisitos son recogidos mediante el análisis de las
necesidades del usuario final y la posibilidad de ponerlas en práctica. El objetivo de esto es
generar una especificación de requisitos del documento que se utiliza como insumo para la
próxima fase del modelo.
 Diseño del sistema: Antes de iniciar cualquier aplicación debe estar ya diseñado el
sistema. Los componentes de software tienen que ser definidas para satisfacer las
necesidades del usuario final y la posible escalabilidad del sistema. En esta fase se
generan diversos documentos, uno para cada disciplina o software.
 Diseño de software: Se definen todos los estados del sistema, tales como su inicio,
paralizaciones, las condiciones de error, los modos de diagnostico, la actividad y
comportamiento del software.
 Codificación: Basados en el documento de diseño de software se pone en marcha el
desarrollo de los módulos definidos.
 Software de integración y verificación: Cada unidad es desarrollada de forma
independiente y se puede probar su funcionalidad. Esta se llama unidad de pruebas, se
verifica si los módulos o unidades verificando si cumplen las especificaciones. Los módulos
se integran en un sistema completo y probado para verificar si todo cooperan como se
esperaba.

4.  Verificación del sistema: Después de que la integración ha superado las pruebas
correspondientes incluyendo el sistema completo tiene que ser evaluada con sus requisitos
iníciales.
 Operación y mantenimiento: Se entrega al cliente el sistema para que lo utilice por
primera vez, el cliente deberá comprobar si sus necesidades se satisfacen como se
esperaba pero también se validara si los requerimientos se han creado en el principio.
Todos los problemas que no se daba en las fases anteriores se resolverán en esta última
fase,
Pruebas para las etapas del método en V.
Comprenden diferentes tipos de prueba para cada etapa de desarrollo:
 Pruebas de componentes: Prueba de componentes también llamado pruebas unitarias.
Se trata de comprobar que cada característica especificada en el “Diseño de componentes”
se ha implementado en el componente.
 Interfaz de pruebas: Debido a que los componentes están construidos y probados
entonces son unidos comprobar que estos funcionen entre sí.
 ¿Qué puede esperar un componente de otro componente en términos de
servicios?
 ¿Cómo se les dará?
 Cómo manejar condiciones no estándar, es decir, errores
 Prueba del sistema: Una vez que todo el sistema se ha construido entonces tiene que
ser probado haciendo referencia a las especificaciones que se plantearon, para comprobar
si entrega las características requeridas. Las pruebas del sistema implican varios tipos de
pruebas especiales para ver si todos los requisitos se cumplen.
 ¿El rendimiento - Son los criterios de desempeño se reunió?
 ¿Puede manejar grandes volúmenes de información?
 ¿La documentación útil para el sistema?
 ¿El sistema se mantienen estables en circunstancias adversas?
 Prueba de aceptación: El cliente es quien debe hacer siempre las pruebas de aceptación
no los programadores, ya que el cliente es la única persona capacitada y que conoce lo
que necesita, esta prueba es similar a los sistemas de pruebas en que todo el sistema esta
activado pero la diferencia es el enfoque de este, aquí se verifica:
 El sistema de control comprobara que el sistema que se especifico ha sido
entregado.
 Y si el sistema ofrece lo que se solicito.
 Prueba de lanzamiento: Esta prueba se debe realizar Incluso si el sistema cumple con
todas las necesidades. Esto trata de ver si el sistema nuevo trabajara en el entorno
empresarial existente. Estas pruebas se suelen ejecutar por el equipo de operaciones.
 Prueba de regresión: Los tipos de pruebas anteriores podrían repetirse en muchos
niveles a fin de entregar el valor final para la empresa. Esto se hace cada vez que un
sistema se ve alterado.

5. Conclusión
En conclusión el método V nos sirve de gran utilidad para el desarrollo de los proyectos, ya que por
medio de este podemos realizar las pruebas necesarias y asegurar que el proyecto está siguiendo
el rumbo correcto.
Este método representa una ventaja porque cada etapa de nuestro proyecto consta de una prueba
para asegurarse de que podemos pasar al siguiente nivel y no corregir problemas de etapas
anteriores al final del proyecto. De esta forma regulamos el proceso de desarrollo de software y nos
proporcionan una guía para la planificación y realización de proyectos

7. Grafico de Método V