SlideShare una empresa de Scribd logo
2
Lo más leído
7
Lo más leído
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
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
Metodo v
Grafico de Método V

Más contenido relacionado

PDF
Proceso unificado y modelo V
PDF
Spm life cycle phase
PPTX
Modelos de proceso de desarrollo de software
PPTX
Spiral Model
PPTX
Software Process Models
PDF
Modelo espiral win win
PPTX
Software Engineering Process Models
PPTX
Software development process models
Proceso unificado y modelo V
Spm life cycle phase
Modelos de proceso de desarrollo de software
Spiral Model
Software Process Models
Modelo espiral win win
Software Engineering Process Models
Software development process models

La actualidad más candente (20)

PPT
DOC
Plan de desarrollo software
PDF
Ciclo de vida cascada
DOCX
Comparison of the Waterfall, Spiral, and Prototype SDLC Models
PPTX
Ventajas y desventajas de moprosoft
PPTX
4 p’s of management spectrum and the w5hh principle
PPTX
Ch5 system modeling
PPTX
Spiral model
PPTX
Game development (Game Architecture)
PPT
Agile development, software engineering
PPTX
Water fall model
PPTX
Artefacts of the Process
PPTX
Waterfall Model PPT in Software Engineering
PPTX
Mejores Prácticas en el Desarrollo del Software
PPTX
Software Project Management
PPTX
Incremental model
PPT
Tipos de ciclos de vida
PPT
UNIT-4design-concepts-se-pressman-ppt.PPT
PPTX
Metodologia orientada a objetos
PDF
Introducción a las Pruebas Software
Plan de desarrollo software
Ciclo de vida cascada
Comparison of the Waterfall, Spiral, and Prototype SDLC Models
Ventajas y desventajas de moprosoft
4 p’s of management spectrum and the w5hh principle
Ch5 system modeling
Spiral model
Game development (Game Architecture)
Agile development, software engineering
Water fall model
Artefacts of the Process
Waterfall Model PPT in Software Engineering
Mejores Prácticas en el Desarrollo del Software
Software Project Management
Incremental model
Tipos de ciclos de vida
UNIT-4design-concepts-se-pressman-ppt.PPT
Metodologia orientada a objetos
Introducción a las Pruebas Software
Publicidad

Similar a Metodo v (20)

DOCX
Mayra romero
PDF
Emilio granizo proceso unificado y modelo v
PDF
Proceso unificado y modelo v
PDF
Proceso unificado y modelo v
PPSX
Prueba a los programas
PPTX
Prueba a los programas
PPTX
Prueba a los programas
DOCX
Modelo de cascadaa
PPT
Aseguramiento De Calidad Mp
PPTX
Prubea de software
PPT
3 Clase Ciclo De Vida Del Software - http://blog.juliopari.com/
PPTX
Sqm
PPT
Auditoria ii
PPT
Auditoria ii
PPTX
Morocha cartelera
PPTX
Tegnologia tema i INTRODUCCION tegnologia.
DOCX
Epa aqui
DOCX
Taller 3 calidad_de_software_jcom
PPSX
Ciclo de vida
Mayra romero
Emilio granizo proceso unificado y modelo v
Proceso unificado y modelo v
Proceso unificado y modelo v
Prueba a los programas
Prueba a los programas
Prueba a los programas
Modelo de cascadaa
Aseguramiento De Calidad Mp
Prubea de software
3 Clase Ciclo De Vida Del Software - http://blog.juliopari.com/
Sqm
Auditoria ii
Auditoria ii
Morocha cartelera
Tegnologia tema i INTRODUCCION tegnologia.
Epa aqui
Taller 3 calidad_de_software_jcom
Ciclo de vida
Publicidad

Metodo v

  • 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