Verificación y Validación de Software
Tarea 4 Propuesta del producto integrador (Anteproyecto)
March 13, 2023
OBJETIVO
Aplicar los conocimientos vistos en clase para verificar y validar un proyecto de desarrollo
de software que produzca una aplicación o sistema que resuelva cierta problemática o necesi-
dades de información
REQUISITOS
1. Presentar en un documento la descripción general del proyecto de la clase en donde
se incluya antecedentes, motivación, justificación ası́ como los objetivos, hipótesis,
alcances, beneficios, etc.
2. Describir cada una de las distintas funciones que la aplicación o sistema propuesto
pretende realizar. La descripción puede hacerse ya sea empleando una tabla o listado
como se muestra en los siguientes ejemplos. La aplicación o sistema debe contar
con al menos 4 funciones principales, una consulta, una alta (registro), una
actualización o modificación y una eliminación de cierta información.
3. Mencionar el o los lenguajes de programación, frameworks, herramientas y ambientes
de desarrollo que se estarán considerando emplear para la implementación del proyecto.
4. Adicionalmente, mencionar cualquier herramienta o framework para la realización de
pruebas de software que se piense utilizar para verificar y validar el desarrollo del
producto en caso de que ya se sepa.
De acuerdo a Pressman, una especificación de requerimientos de software es un documento
que contiene una descripción detallada de todas las funciones del software que se va a de-
sarrollar antes de que el proyecto comience. Actualmente, existe una gran cantidad de
formatos para documentar la especificación de requerimientos de software. A continuación
se muestran algunos ejemplos sobre como documentar dichas especificaciones, sin embargo,
es posible utilizar cualquier otro formato similar a los mostrados.
1
EJEMPLO 1
EJEMPLO 2
2
EJEMPLO 3
NOTA: Hasta aquı́ comprende la Tarea 4
La siguiente información corresponde al producto integrador que se entregará hacia el final
del semestre el cual consiste en dos partes principales que son el documento y la exposición.
El documento del proyecto deberá contener las siguientes secciones en donde para cada una
se muestra la cantidad máxima de puntos que se podrá asignar en base al contenido
1. Introducción [5]
2. Especificación de requerimientos [5]
3. Especificación de diseño(s) [15]
4. Implementación o codificación [10]
5. Pruebas de software [20]
6. Conclusiones [10]
7. Referencias [5]
La sumatoria de puntos de las secciones anteriores da como máximo 70 en donde los 30
restantes corresponden a la exposición del proyecto cuya fecha y hora se definirán hacia el
final del semestre.
3
La sección de Especificación de diseño(s) deberá contener el o los modelos de diseño
considerados como necesarios para entender la estructura o arquitectura de la solución a im-
plementar. Esta sección podrá incluir representaciones gráficas de dichos modelos en forma
de diagramas de flujo, diagramas de clases, diagramas E-R, diagramas de secuencia, casos
de uso, algoritmos, entre otras representaciones.
En la sección de implementación o codificación solo incluir algunas partes del código de
las funciones mas importantes. No incluir todo el código de la aplicación.
La parte de Pruebas de software es la más importante del documento cuyo contenido
deberá ser el siguiente:
• La descripción de todos los casos de prueba diseñados y ejecutados para comprobar el
correcto funcionamiento de la aplicación
• Cada caso de prueba deberá venir acompañado de impresiones de pantalla que muestren
el resultado obtenido
• Las pruebas se pueden realizar empleando alguna(s) de las herramientas de apoyo
investigadas en la tarea 5 (JUnit, NUnit, Selenium, etc.)
• Esta sección también deberá contener la normalización de todas las relaciones de la
base de datos hasta la 3FN
A continuación se muestran algunos ejemplos acerca de la documentación de casos de prueba
de software (pruebas de sistema y pruebas unitarias).
EJEMPLO 1
El ejemplo anterior es de un caso de prueba para una condición de error o no válida. El
siguiente ejemplo 2 muestra un caso de prueba para una condición válida o exitosa.
4
EJEMPLO 2
Por lo regular, para cada requerimiento se deben diseñar y ejecutar dos casos de prueba, uno
para una condición válida y otro para una no válida, aunque también va a depender de la
funcionalidad especı́fica de cada requerimiento. A continuación se muestran algunos otros
ejemplos de formatos para documentar los casos de prueba. Sin embargo, al igual que con la
definición de requerimientos existe una gran diversidad de formas de documentar los casos
de prueba.
REFERENCIAS
• R. S. Pressman, Ingenierı́a de Software - Un enfoque práctico, 7ma. edición, McGraw
Hill Educación, 2010
• Ian Sommerville, Ingenierı́a de Software, 9na. edición, Pearson Educación, 2011
• [Link]
5
EJEMPLO 3
6
7
8
9
