Instituto Tecnológico Superior de

Acayucan

ITSA

(Extensión Jáltipan)

Alumno: Angel Teodoro Guzmán García

Docente: MTI. Feliciano Sánchez Mendoza

Asignatura: Verificación y validación de

software.

Grupo: 803-C

Carrera: Sistemas Computacionales

Índice
Introducción.....................................................................................3

3
3.1 Marco de Referencia para el desarrollo de software.............4
3.2 Herramientas para apoyar al proceso y la ejecución de las
revisiones de software....................................................................5
3.3 Manejo de Requerimientos (Verificación)...............................7
3.4 Verificación en este proceso....................................................8
3.5 Entradas propuestas para el proceso de verificación de
requerimientos................................................................................9
3.6 Método de verificación............................................................10
3.7 Aspectos a verificar en esta etapa.........................................11
3.8 Entendimiento de problema (Verificación)...........................12
3.9 Revisión general de requerimientos......................................12
Bibliografía.....................................................................................13

3
Introducción.
La verificación de software es una disciplina más estrecha y compleja de la
ingeniería de software cuyo objetivo es asegurar que el software pueda
satisfacer completamente todos los requerimientos esperados.
Hay dos acercamientos fundamentales en la verificación de software:
 Verificación dinámica, también conocida como prueba de
experimentación, útil para encontrar bugs.
 Verificación estática, también conocida como análisis. Esta es útil para
probar si un programa es correcto aunque puede resultar en falsos
positivos.
Una revisión técnica formal (RTF) es un medio efectivo para mejorar la calidad
del software.
Los objetivos de la RTF son:
 Descubrir errores en la función, la lógica o la implementación de
cualquier representación del software.
 Verificar que el software bajo revisión alcanza sus requisitos.
 Garantizar que el software ha sido representado de acuerdo con ciertos
estándares predefinidos.
 Conseguir un software desarrollado de forma uniforme.
 Hacer que los proyectos sean manejables.
Tiene por finalidad comprobar que los requisitos del software poseen todos los
atributos de calidad enunciados a continuación.
 Consistentes.
 Completos.
 Precisos.
 Realistas.
 Verificables
Estas actividades pretenden evitar los altos costos que significaría el tener que
corregir una vez avanzado el desarrollo.
Se verifican las prácticas con auxilio de cuestionarios y entrevistas acordes con
los requisitos establecidos y con base en los resultados se determina el nivel
de madurez de capacidades de los procesos verificados. Las inspecciones de
software se pueden planificar y ejecutar en diversas etapas del desarrollo.
La verificación se da en torno a tres procesos básicos:
Inspección: Es una revisión técnica a fondo, rigurosa y formal, diseñada para
identificar problemas tan cerca de su punto de origen como sea posible.

3
Medición: Es el proceso por medio del cual se miden la mayor cantidad de
atributos del producto y proceso, con el fin de tener información cuantificable
útil para la mejora continua.
Administración de la configuración: Es el proceso por el cual se determina si la
especificación es consistente con las necesidades del cliente.
Incluye verificar trazabilidad entre la especificación y el documento de
requerimientos.
Se trabaja con un bosquejo completo del documento a diferencia de la
verificación del análisis.
Se realizan las siguientes verificaciones en el documento de requerimientos:
 Validez: compromiso con el usuario, que valide que es lo que quiere.
 Consistencia: que no haya contradicciones.
 Realismo: que se puedan implementar (incluye: tecnología, presupuesto
y calendario).
 Verificabilidad: Diseñar conjunto de pruebas para demostrar que el
sistema cumple esos requerimientos.

3.1 Marco de Referencia para el desarrollo de software.

Verificación: Es la acción de verificar (comprobar o examinar la verdad de
algo). La verificación suele ser el proceso que se realiza para revisar si una
determinada cosa está cumpliendo con los requisitos y normas previstos.
Antecedentes
 La industria del software, a diferencia de otras industrias, tiene muy poco
tiempo de vida.
 Desde hace ya más de 50 años, en 1930 Walter Shewhart comenzó a
trabajar en la mejora de procesos estableciendo los principios del control
estadístico de la calidad.
 Glenford J. Myers en 1979 promovió que la Ingeniería del Software
separase las disciplinas fundamentales del desarrollo del software de la
verificación y validación del mismo.
 Los principios de Shewhart fueron refinados por W. Edwards Deming
dando lugar al ciclo Deming, el cual fue utilizado entre otras cosas para
la mejora continua de la calidad dentro de una empresa.
 Estos pasos son: Planear, Hacer, Verificar y Actuar.
 En 1988, el Dr. Dave Gelperin y el Dr. William C. Hetzel realizaron una
clasificación basada en los más influyentes modelos de pruebas
publicados hasta la fecha.
Actividades Principales

3
  Garantía de calidad. El establecimiento de un marco de trabajo de
procedimientos y estándares organizacionales que conduce a software
de alta calidad.
 Planificación de la calidad. La selección de procedimientos y estándares
adecuados a partir de este marco de trabajo y la adaptación de éstos
para un proyecto software específico.
 Control de calidad. La definición y fomento de los procesos que
garanticen que los procedimientos y estándares para la calidad del
proyecto son seguidos por el equipo de desarrollo de software.
Proceso para el desarrollo de Software
También denominado ciclo de vida del desarrollo de software es una
estructura aplicada al desarrollo de un producto de software. Hay varios
modelos a seguir para el establecimiento de un proceso para el desarrollo
de software, cada uno de los cuales describe un enfoque diferente para
diferentes actividades que tienen lugar durante el proceso.
Actividades de desarrollo de Software
 Planificación
 Implementación
 Pruebas
 Documentación
 Despliegue
 Mantenimiento
Modelos de desarrollo de Software
 Modelo en casada
 Modelo lineal secuencial
 RUP

3.2 Herramientas para apoyar al proceso y la ejecución de las

revisiones de software.
¿Que son las revisiones?
Son el conjunto de actividades que suceden como resultado del análisis, el
diseño y la codificación y que sirven para depurar las actividades de ingeniería
del software.
Objetivos de una revisión:
• Señalar la necesidad de mejoras en el producto
• Continuar las partes de un producto en las que no es necesaria o no es
deseable una mejora
• Conseguir un trabajo técnico de una calidad más uniforme, o al menos más
predecible, que la que puede ser conseguida sin revisiones, con el fin de hacer
más manejable el trabajo técnico.

3
Paso de desarrollo.
En cada paso del proceso de desarrollo de software, se presentan errores que
pasan inadvertidos y que producen un mayor número de errores si las
revisiones no lo detectan.

Errores amplificados.
Los errores amplificados corresponden, a aquellos errores que pasan
inadvertidos desde pasos anteriores. De igual forma se representa el
porcentaje de eficiencia de la detección de errores.
Revisión técnicas formales.
Una revisión técnica formal (RTF) es un medio efectivo para mejorar la calidad
del software.
Los objetivos de la RTF son:
 Descubrir errores en la función, la lógica o la implementación de
cualquier representación del software.
 Verificar que el software bajo revisión alcanza sus requisitos.
 Garantizar que el software ha sido representado de acuerdo con
ciertos estándares predefinidos.
 Conseguir un software desarrollado de forma uniforme.
 Hacer que los proyectos sean manejables.
 La RTF incluye:
• Recorridos
• Inspecciones
• Revisiones cíclicas
• Evaluaciones técnicas del software
 Cada RTF debe estar debidamente planificada, controlada y atendida
por el grupo encargado de cada RTF.
Directrices de revisión.
Revisar el producto, no al Se deben señalar los errores de
productor. forma constructiva y no dificultar el
proceso de revisión. Es importante
mantener el control de la reunión y
descartar situaciones que se escapen

3

Fijar una agenda y mantenerla.
Limitar el debate y las
impugnaciones.
Enunciar áreas problemas pero no
intentar resolver los problemas
que se pongan de manifiesto.
Tomar notas escritas.
Limitar el número de participantes
e insistir en la preparación
anticipada
Desarrollar una lista de
comprobación para cada producto
que haya de ser revisado.
Disponer recursos y una agenda
para las RTF.
Capacitación y entrenamiento de
los revisores.
. Revisar las revisiones anteriores
3.3 Manejo de Requerimientos (Verificación).
Validación de requisitos
Este proceso generalmente se realiza una vez obtenida una primera versión de
la documentación de requisitos.
Revisión de los requisitos.
de control.
Se debe tener un plan de trabajo
antes de la reunión. Se debe seguir
el orden del plan para que la reunión
tenga éxito y cumplir con los tiempos
asignados al plan.
No se debe perder tiempo debatiendo
situaciones que no presenten
unanimidad, es importante registrar el
hecho y dedicar otros tiempos para
su debate.
La resolución de problemas se debe
programar para otros espacios
después de la reunión de revisión
Es buena idea utilizar diferentes
herramientas para la toma de notas,
por ejemplo, pizarras, tableros,
computador, para que se pueda
hacer seguimiento a la asignación de
prioridades.
Se debe limitar el número de
revisores, los cuales deben estar
preparados para cada reunión y
participar activamente en el proceso
de revisión.
Se deben desarrollar listas de
comprobación para los documentos
de análisis, diseño, codificación y
pruebas.
Cada RTF debe estar planificada e
involucrar modificaciones.
Todas las personas que participen en
el proceso de revisión deben recibir
un entrenamiento que se debe basar
en:
 El proceso
 · Psicología humana
Son beneficiosas porque permiten
descubrir problemas del proceso de
revisión.
3
Consisten en una o varias reuniones, planificadas donde se intenta confirmar
que los requisitos poseen los atributos de calidad deseados.
El resultado final de las reuniones de revisión es un documento que contiene la
lista de defectos localizados y una lista de acciones recomendadas.
La revisión de los requisitos es uno de los mejores métodos de validación de
requisitos ya que permiten:
1. Descubrir una gran cantidad de defectos en los requisitos.
2. Reducir los costos de desarrollo entre un 20% y un 30%
3. Reducir el tiempo de pruebas entre un 50% y un 90%
Dichas reuniones se realizan en 7 pasos
1. Preparar el plan de revisión (las tareas a realizar, planificación temporal
y las personas participantes).
2. Distribuir el documento a revisar (generalmente el único documento a
revisar será el documento de especificación).
3. Preparar la reunión generalmente es muy diferente para quien la realice.
4. Realizar la reunión de revisión. El formato de la reunión puede ser muy
diverso, puede ser una total falta de control o puede ser muy formalizado
y sujeto a protocolos de actuación.
5. Identificar los defectos y acciones a realizar. La lista de defectos y
acciones recomendadas es el documento final obtenido en las revisiones
de requisitos.
6. Realizar correcciones que sean precisas: el promotor de la reunión debe
evaluar y llevar a cabo las acciones recomendadas que han surgido en
la reunión.
7. Informar de las modificaciones realizadas: una vez que los defectos han
sido subsanados, se envía un informe de tareas realizadas y una copia
corregida de los documentos de especificación a los participantes de la
reunión.
Métodos más habituales.
Revisión de requisitos: consisten en reuniones donde el equipo de analistas
intentan localizar los errores en los documentos de la especificación.
Prototipado: consiste en construir una maqueta del futuro sistema a partir de
requisitos recogidos en la especificación. (Evaluada por el cliente y usuarios)
Generación de casos de prueba: consiste en la definición de casos de prueba
que permitan verificar el complimiento de los requisitos funcionales.

3.4 Verificación en este proceso.

¿En qué consiste la verificación de procesos?
Se verifican las prácticas implantadas en los procesos de la organización con
auxilio de cuestionarios y entrevistas acordes con los requisitos establecidos en
la norma aplicable.

3
Con base en los resultados obtenidos de esta investigación, se determina el
nivel de madurez de capacidades de los procesos verificados hasta el nivel
objetivo requerido, según la solicitud de la organización.
Las inspecciones de software se pueden planificar y ejecutar en diversas
etapas del desarrollo. La ejecución de este proceso dará como resultado un
conjunto de defectos, con los cuales se debe lograr un análisis y conclusiones
para la mejora de los procesos específicos y, de forma general, del proceso de
desarrollo de software.
Al final, se emite un dictamen de cumplimiento formalizando el resultado
obtenido, mismo que proporciona certidumbre en la capacidad de la
organización para cumplir sus objetivos.
Es el proceso de prueba del software para asegurar que cumple su
especificación.
 Identificar los casos y escenarios de la prueba.
 Si el software funciona correctamente.

3.5 Entradas propuestas para el proceso de verificación de

requerimientos.
Fagan propone un proceso de inspección constituido por las siguientes
actividades:
1. .Vista general
2. Preparación
3. Inspección
4. Re-trabajo
5. Seguimiento
Verificación de Requerimientos no funcionales:
 Son difíciles de verificar.
 Se deben expresar de manera cuantitativa utilizando métricas que se
puedan probar de forma objetiva (esto es IDEAL).
Propiedad Medida
Rapidez Transacciones por seg.
Tamaño KB.
Fiabilidad Tiempo promedio entre fallas.
Robustez Probabilidad de datos corruptos después de
la falla.
Portabilidad Número de sistemas.
Facilidad de uso Tiempo de capacitación.

Técnicas – Validación de Requerimientos.Revisiones de Requerimientos

Participan representantes

3
  Del cliente: operadores, quienes realicen entradas, utilicen salidas, y sus
gerentes.
 Del equipo de desarrollo: analistas de requerimientos, diseñadores,
encargados de pruebas y gestión de configuración.
Incluye:
 Revisar objetivos del sistema.
 Evaluar alineamiento de requerimientos con los objetivos (necesidad).
 Revisar el ambiente de operación y las interfaces con otros sistemas.
 Funciones completas, restricciones realistas.
 Evaluar riesgos.
 Considerar:
* Pruebas del sistema.
* Cambios en los requerimientos en el proyecto, su verificación y
validación
Medición de Requerimientos
La medición de requerimientos está enfoca a tres áreas: producto, proceso y
recursos.
Los productos de los requerimientos (definición y especificación) pueden ser
evaluados en primer lugar considerando el número de requerimientos.
De manera similar se puede medir la cantidad de cambios introducidos a los
requerimientos. Un gran número de cambios indica cierta inestabilidad o
incertidumbre en la comprensión de lo que el sistema debe hacer o cómo
comportarse.
También es bueno evaluar la incertidumbre por tipo de requerimiento. Esto
permite seccionar.

3.6 Método de verificación.

Métodos formales.
En los cuales se trata de determinar analíticamente que las transformaciones
realizadas sean correctas.
Métodos basados en la simulación.
En los cuales se trata de determinar la corrección del sistema a través de la
simulación, ya sea lógica o eléctrica. Estos métodos suponen la generación de
un testbench (banco de pruebas) que deben tener una serie de patrones de
test.
Métodos basados en la emulación.
Los cuales son similares a la simulación excepto en que la emulación se lleva a
cabo sobre prototipos hardware, y la simulación sobre netlist lógicos y/o
eléctricos.

3
3.7 Aspectos a verificar en esta etapa
Aspectos a considerar en requerimientos
Los requerimientos son lo que el software debe hacer y/o características que el
software debe tener.
 Deben ser consistentes, completos, realizables y verificables.
 Que los requerimientos expresan las necesidades y las restricciones
puestas en un producto.
 En los requerimientos funcionales se considera que describa las
funciones que el software debe realizar.
 En cuanto a los requerimientos no funcionales son las restricciones a las
posibles soluciones.
Verificación del cumplimiento de los requerimientos
 Ayudan a realizar revisión de técnicas antes de iniciar su diseño
 Identificando los aspectos más débiles y los que pueden generar
problemas; como debe estar completos, ayuda a asegurar que no
existen requerimientos que no se puedan comprobar.
Calidad
 La calidad del software es el grado o medida en que el producto cumple
con sus especificaciones.
 “La calidad implica excelencia, es decir, que el software funcione
correctamente y cumpla con todos los requisitos del cliente”.
 Los requisitos del software son la base de las medidas de la calidad.
 Los estándares especificados definen un conjunto de criterios de
desarrollo que guían la forma en que se aplica la ingeniería del software,
Si no se distinguen esos criterios no habrá calidad del software.
 Existe un conjunto de requisitos implícitos que a menudo no se
mencionan, si no se alcanzan estos requerimientos podría la calidad
quedar en entredicho. Los requisitos son llamados por los usuarios
finales llaman elementos obvios, los cuales el diseñador no debe dejar
pasar sin explicación
Comprobación y análisis de sistemas
 Inspecciones del software: analizan y comprueban las representaciones
del sistema como el documento de requerimientos, los diagramas de
diseño y el código fuente del programa.
 Las inspecciones de software y los análisis automatizados son técnicas
estáticas puesto que no requieren que el sistema se ejecute.
 Las pruebas del software: Llevan a cabo una implementación del
software con los datos de prueba y examinan las salidas del software y
su comportamiento operacional para comprobar que se desempeñe
conforme a lo requerido.

3
3.8 Entendimiento de problema (Verificación).
¿Por qué falla el software?
No hace lo requerido (o hace algo que no debería)
Razones:
 Las especificaciones no estipulan exactamente lo que el cliente precisa.
 Requerimiento no se puede implementar.
 Faltas en el diseño.
 Faltas en el código.
 La idea es detectar y corregir estas faltas ates de liberar el producto.
Identificación y corrección de defectos
Identificación de defectos: Es el proceso para determinar que defectos
causaron la falla.
Corrección de defectos: Es el proceso de cambiar el sistema para remover los
defectos.

3.9 Revisión general de requerimientos.

El proceso de recopilar, analizar y verificar las necesidades del cliente para un
sistema es llamado Ingeniería de Requerimientos. La meta de la ingeniería de
requerimientos (IR) es entregar una especificación de requisitos de software
correcta y completa.
Los requerimientos deben ser:
 Especificados por escrito. Como todo contrato o acuerdo entre dos
partes posibles de probar o verificar. Si un requerimiento no se puede
comprobar, entonces ¿cómo sabemos si cumplimos con él o no?
 Descritos como una característica del sistema a entregar. Esto es, que
es lo que el sistema debe de hacer (y no como debe de hacerlo). Lo más
abstracto y conciso posible. Para evitar malas interpretaciones.
La revisión de requerimientos trata de mostrar que estos realmente definen el
sistema que el cliente desea. Coincide principalmente con el análisis ya que
este implica encontrar problemas con los requerimientos. La validación de
requerimientos es importante debido a errores en el documento de
requerimientos pueden conducir a importantes costes al repetir el trabajo
cuando son descubiertos durante el desarrollo o después de que el sistema
esté en uso.
Durante el proceso de REVISION de requerimientos, se deben llevar acabo
verificaciones sobre requerimientos en el documento de requerimientos. Estas
verificaciones comprenden:
1. Verificaciones de validez: Un usuario puede pensar que se necesitan un
sistema para llevar acabo ciertas funciones. sin embargo el

3
 razonamiento y el análisis pueden identificar que se requieren funciones
adicionales o diferentes.
2. Verificaciones de consistencia: Los requerimientos en el documento no
deben contradecirse. Esto es, no deben haber restricciones propuestas
por el usuario del sistema.
3. Verificaciones de completitud: El documento de requerimientos debe
incluir requerimientos que definan todas las funciones y restricciones
propuestas por el usuario del sistema.
4. Verificación del realismo: Utilizando el conocimiento de la tecnología
existente, los requerimientos deben verificarse para asegurar que se
pueden implementar. Estas verificaciones también deben tener en
cuenta el presupuesto y la confección de agendas para el desarrollo del
sistema.
5. Verificabilidad: Para reducir la posibilidad de discusiones entre el cliente
el contratista, los requerimientos del sistema siempre deben redactarse
de tal forma que seas verificables. Esto significa que debe poder escribir
en conjunto de pruebas que demuestren que el sistema a entregar
cumple cada uno de los requerimientos especificados.

Bibliografía
Ramiírez Vivar, J. d. (2 de Junio de 2014). Wordpress.com. Obtenido de
https://jddiosvivar.files.wordpress.com/2014/06/3-3-manejo-de-
requerimientos.pdf
Ramírez Vivar, J. d. (2 de Junio de 2014). Wordpress.com. Obtenido de
https://jddiosvivar.files.wordpress.com/2014/06/3-2-herramientas-para-el-
apoyo-de-proceso-y-la-ejecucion-de-revisones-des-software.pdf
Ramírez Vivar, J. d. (2 de Junio de 2014). Wordpress.com. Obtenido de
https://jddiosvivar.files.wordpress.com/2014/06/3-4-verificacic3b3n-en-
este-proceso.pdf
Ramírez Vivar, J. D. (2 de Junio de 2014). Wordpress.com. Obtenido de
https://jddiosvivar.files.wordpress.com/2014/06/3-1-marco-de-referencia-
para-el-desarrollo-de-software.pdf