Ciencias de la IngenieríaTrabajo de Investigación

Método VCátedra

Administración de ProyectosTutor

Ing. Richard Ramírez AnormalizaAlumna

Mayra Romero Alava

Noveno Semestre

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 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.

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.

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

Grafico de Método V

Bibliografía

http://es.wikipedia.org/wiki/M%C3%A9todo_en_V http://presencias.net/indpdm.html?http://presencias.net/invest/ht3017f.html