1. UNIVERSIDAD TECNONOLÓGICA DEL ESTADO DE ZACATECAS
UNIDAD ACADÉMICA DE PINOS
TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN
Materia
INTRODUCCION AL ANALISIS Y DESARROLLO DE SISTEMAS
Tema
MODELO EN V
Nombre completo del Alumno :
Guadalupe del Rosario López Guerrero
Mónica de los Ángeles Ramírez Moreno
Adolfo Ángel Colunga Medellín
Héctor Daniel Hernández Zapata
Grado: 2° Grupo: A
Nombre del Docente : Susana Sánchez Luevano
Fecha de entrega : 15/02/2013

2.  Es una variación del modelo en cascada que muestra
cómo se relacionan las actividades de prueba con el
análisis y el diseño., la codificación forma el vértice de
la V, con el análisis y el diseño a la izquierda y las
pruebas y el mantenimiento a la derecha.

4. Fase # 1 :está orientado al “cliente”. El
inicio del proyecto y el fin del proyecto
constituyen los dos extremos del ciclo.
Se componen del análisis de requisitos y
especificaciones, se traduce en un
documento de requisitos y
especificaciones.
Fase # 2: se dedica a las características
funcionales del sistema propuesto.
Puede considerarse el sistema como una
caja negra, y caracterizarla únicamente
con aquellas funciones que son directa o
indirectamente visibles por el usuario
final, se traduce en un documento de
análisis funcional.

5. Fase # 3 : Fase # 4 :define los componentes
es la fase de hardware y software
implementación, en la del sistema final, a
que se desarrollan los cuyo conjunto se
elementos unitarios o denomina
arquitectura módulos del programa del
sistema.

6. La letra “V” significa Verificación y validación.
• 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.
•Es muy similar al modelo de la cascada clásico ya que es
muy rígido y contiene una gran cantidad de iteraciones.

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

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

9. Sirve para indicar en qué fase de desarrollo se
deben definir las pruebas correspondientes.
También sirve para saber a qué fase de desarrollo
hay que volver si se encuentran fallos en las
pruebas correspondientes.