Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Ingeniería de Software - Modelo en V

No description
by

Marco Romero

on 27 March 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Ingeniería de Software - Modelo en V

Modelo en V
Ingeniería de Software
Introducción
Definición: En la construcción de un producto
de software el orden en que se realicen las distintas etapas y actividades para su desarrollo, define el ciclo de vida; esto va desde la concepción de la idea hasta la concretización de la misma.
¿Qué es el Modelo en V?
Es una representación gráfica del ciclo de vida del desarrollo de sistemas.
El Modelo V tiende a ser muy relacionado con el Modelo de Cascada puesto que es una evolución de este.
Se describen las actividades y resultados que deben producirse durante el desarrollo del producto.
El lado izquierdo de la V representa la descomposición de las necesidades, y la creación de las especificaciones del sistema.
El lado derecho de la V representa la integración de las piezas y su verificación.
Objetivos
Minimización de los riesgos del proyecto
Mejora la transparencia del proyecto y control del proyecto, especificando los enfoques estandarizados, describe los resultados correspondientes y funciones de responsabilidad. Permite una detección temprana de las desviaciones y los riesgos y mejora la gestión de procesos, reduciendo así los riesgos del proyecto.
Mejora y Garantía de Calidad
Como un modelo de proceso estándar, asegura que los resultados que se proporcionan sean completos y contengan la calidad deseada. Los resultados provisionales definidos se puede comprobar en una fase temprana. La uniformidad en el contenido del producto mejora la legibilidad, comprensibilidad y verificabilidad.
Reducción de los gastos totales
El esfuerzo para el desarrollo, producción, operación y mantenimiento de un sistema puede ser calculado, estimado y control de manera transparente mediante la aplicación de un modelo de procesos estandarizados. Reduciendo la dependencia en los proveedores y el esfuerzo para las siguientes actividades y proyectos.
Mejora de la comunicación entre todos los inversionistas
La descripción estandarizada y uniforme de todos los elementos pertinentes y términos es la base para la comprensión mutua entre todos los inversionistas. De este modo, se reduce la pérdida por fricción entre el usuario, comprador, proveedor y desarrollador.
Fases de Verificación
En esta fase se colectan los requisitos del sistema y se analizan las necesidades del usuario. Esta fase determina que debe realizar el “sistema ideal”, pero no determina como será diseñado o construido.
Análisis de Requisitos
Los técnicos analizan y entienden el funcionamiento o negocio del sistema propuesto, para ellos se basan en las exigencias del consumidor. Se calcula cada posibilidad y técnica que dichas exigencias pudieren ser ejecutadas.
Diseño del Sistema
El objetivo de esta fase es seleccionar “el puente entre los requerimientos y el código”.
Análisis de Requisitos
Codificar los fragmentos del sistema.
Diseño del módulo
Ventajas
• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.
• Es un modelo sencillo y de fácil aprendizaje.
• Hace explícito parte de la iteración y trabajo que hay que revisar.
• Especifica bien los roles de los distintos tipos de pruebas a realizar.
• Involucra al usuario en las pruebas.
Desventajas
• Es difícil que el cliente exponga explícitamente todos los requisitos.
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida.
• Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas.
• El producto final obtenido puede que no refleje todos los requisitos del usuario.
Consistencia
Dependerá de valor tomado por cada uno de los integrantes.
Exista una infraestructura necesaria para brindar el soporte requerido.
¿Cómo lo hago?
Una de las políticas principales de este modelo es comenzar a realizar las pruebas lo mas pronto posible.
Esto da lugar a que tanto los procesos de “verificación” y “validación”, se puedan integrar en cada fase del ciclo de vida, cumpliendo que “para cada fase de desarrollo debe existir un resultado verificable”.
Fases de Validación
Mediante el análisis de código se descubren primeros fallos , corregirlos hace una reducción de costos al proyecto total.
Prueba de Unidas
Probar los módulos separados (fragmentos del proyecto) en conjunto para detectar errores en interfaces y en la interacción de componentes integrados.
Prueba de Integración
Se realiza una comparación del sistema producido hasta el momento contra el sistema real, utilizando los documentos de diseño.
Prueba del Sistema
En caso de que no sea aceptado, se realizarán los cambios necesarios según las necesidades originales.
Prueba de aceptación
de Usuario
Esther Jimenez Molina
Nayeli Contreras Garrido
Full transcript