Semana 9 – Validación y Verificación

Introducción
La complejidad de los diseños software es algo que está creciendo en los últimos años de
forma imparable. Los clientes piden software más sofisticado y con menos errores.

M enos Errores

Software más
sofisticadodo

El proceso de validación y verificación es una parte crucial de la vida de un proyecto software y

acaba ocupando, aproximadamente, dos terceras partes del tiempo que se dedica al total.

Esto hace crucial el estudio de nuevas técnicas que sean capaces de agilizar el proceso de
validación y conseguir así, una mejora exponencial de la productividad y la calidad de los
diseños.

Para lograr un buen proceso de calidad, se hace necesario plantearse la Calidad del Software
desde una perspectiva global, albergando el ciclo de vida completo del producto, teniendo en
cuenta tanto la calidad final del mismo como la del proceso de desarrollo.

Por lo tanto, contar con metodologías, estándares, buenas prácticas, normativas y directrices
correctas resulta fundamental para construir el armazón que permite desarrollar y poner en
producción un producto software de calidad porque de esta forma, los errores y los costes
serán menores y la agilidad y eficacia crecerán. Es decir, no basta con probar y probar, sino con
probar con criterio. Cuando se une un buen proceso con un buen producto, el éxito está
prácticamente asegurado

Definición
La verificación y validación es el nombre que se da a los procesos de comprobación y análisis
que aseguran que el software que se desarrolla está acorde a su especificación y cumple las
necesidades de los clientes. La verificación y validación es un proceso de ciclo de vida
completo. Inicia con las revisiones de los requerimientos y continúa con las revisiones del
diseño y las inspecciones del código hasta la prueba del producto. Existen actividades de en
cada etapa del proceso de desarrollo del software.

La verificación y la validación no son la misma cosa

Verificación
¿Estamos construyendo el producto correctamente? 

El papel de la verificación comprende comprobar que el software está de acuerdo con su

especificación. Se comprueba que el sistema cumple los requerimientos funcionales y no
funcionales que se le han especificado.

¿Qué se debe tener en la verificación?

 Consistencia: vigilar que la información sea coherente.
 Precisión: corrección de la sintaxis.
 Completitud: lagunas en capacidad deductiva.

Lo que se hace en la verificación:

 Identifica desviaciones con estándares y requerimientos.
 Recolecta datos para mejorar el proceso.
 Verifica que el producto:
o Cumpla con los requerimientos.
o Cumpla con los atributos de calidad.
o Se ajuste a las regulaciones, estándares y procedimientos definidos.

Validación
¿Estamos construyendo el producto concreto?

La validación es un proceso más general. Se debe asegurar que el software cumple las

expectativas del cliente. Va más allá de comprobar si el  sistema está acorde con su
especificación, para probar que el software  hace lo que el usuario espera a diferencia de lo
que se ha especificado

La validación también es una evaluación del sistema o de componentes, solo que es en el

transcurso o al final del proceso del desarrollo, donde se determina si cumple con lo
especificado.
 Aspectos en la validación
 Construir el sistema correcto.
 Evaluar la conformidad con la especificación de requisitos.

¿Dónde se realiza la verificación?

Específicos para proyectos de TI, a continuación se presentan algunas de las áreas en las que se
realiza la verificación.

Situación de Actores Definición Producción

verificación
Revisión de la Miembros del Una revisión por pares es Documentación de
documentación equipo de donde los miembros del prueba lista para
de la prueba control de equipo revisan el trabajo compartir con los
(revisión por calidad de los demás para equipos externos.
pares) asegurarse de que no haya
errores en la
documentación.
Revisión de Equipo de Este es un paso necesario Requisitos finalizados
requisitos desarrollo / no solo para asegurarse de que están listos para
funcionales / cliente para que los requisitos se hayan ser consumidos por el
comerciales requisitos recopilado y / o siguiente paso: diseño.
comerciales. correctamente, sino
también para asegurarse
de que sean factibles o no.
Revisión de Equipo de Después de la creación del El diseño está listo para
diseño desarrollo diseño, el equipo de implementarse en un
desarrollo lo revisa a sistema de TI.
fondo para asegurarse de
que se puedan cumplir los
requisitos funcionales a
través del diseño
propuesto.
Tutorial de código Desarrollador Una vez escrito, el código Código listo para
individual se revisa para identificar pruebas unitarias.
cualquier error sintáctico.
Esto es de naturaleza más
informal y lo realiza el
desarrollador individual en
el código desarrollado por
uno mismo.
Inspección de Equipo de Esta es una configuración Código listo para
código desarrollo más formal. Los probar.
desarrolladores y expertos
en la materia verifican el
código para asegurarse de
que esté de acuerdo con
los objetivos comerciales y
funcionales que persigue
el software.
Revisión del plan Equipo de El equipo de control de Un documento de plan
de prueba control de calidad revisa de pruebas listo para
 (interno del calidad internamente un plan de compartir con los
equipo de control prueba para asegurarse de equipos externos
de calidad) que sea preciso y (Gestión de proyectos,
completo. Análisis de negocio,
desarrollo, Medio
ambiente, cliente, etc.)
Revisión del plan Project Un análisis formal del Un documento del plan
de prueba Manager, documento del plan de de prueba firmado o
(externo) Business prueba para asegurarse de aprobado en función
Analyst y que el cronograma y otras del cual se basará la
Developer. consideraciones del actividad de prueba.
equipo de control de
calidad estén en
consonancia con los de los
otros equipos y con todo
el proyecto.
Revisión final de Analista de Una revisión de la Documentación de
la documentación negocio y documentación de prueba prueba lista para ser
de prueba equipo de para asegurarse de que los ejecutada.
desarrollo. casos de prueba cubren
todas las condiciones
comerciales y los
elementos funcionales del
sistema.

El objetivo de la verificación y validación

El objetivo final es crear el producto adecuado. Más que eso, se trata de garantizar que el
producto tenga la calidad, la seguridad y la protección necesarias para garantizar que siga
siendo el producto correcto.

La verificación es parte del proceso de desarrollo de software que garantiza que el trabajo sea
correcto. La verificación del software generalmente incluye:

 Conformidad con los estándares de la industria, asegurando que el proceso y los

artefactos cumplan con las pautas.
 Revisiones, tutoriales, inspecciones.
 Código estático análisis y otras actividades sobre artefactos producidos durante el
desarrollo.
 Hacer cumplir los estándares de arquitectura, diseño y codificación

La validación demuestra que el producto final cumple con los requisitos. Esos requisitos
abarcan la funcionalidad más la confiabilidad, el rendimiento, la seguridad y la protección.

Para los productos físicos, la validación incluye que los clientes vean, prueben el producto ellos
mismos. Pero para el software, la validación consiste en la ejecución del software y la
demostración de su ejecución. Por lo general, involucra:

 Ejecución de código para demostrar la funcionalidad correcta.

 Ejecución en entornos objetivo.
 Rendimiento, infiltración y otras pruebas no funcionales.
  Pruebas de aceptación a los clientes de forma directa y frecuente.
 Usando artefactos de procesos de verificación para ilustrar trazabilidad de
requisitos para finalizar la funcionalidad, especialmente para funciones específicas
de seguridad y protección.

Es importante comprender las diferencias entre los objetivos de verificación y validación, y que
el desarrollo de software necesita ambos.

Estas actividades son una parte importante del esfuerzo que se dedica al desarrollo de
software. Las organizaciones siempre buscan optimizarlas sin comprometer la seguridad, la
protección o la calidad.

Cómo abordar la verificación y validación

El modelo V
Una evolución del modelo en cascada que demuestra como las fases de prueba se
relacionan con las de análisis y desarrollo.

Este modelo pone de manifiesto como el desarrollo de las pruebas debe efectuarse de
manera paralela al desarrollo del programa. En contraste, un modelo clásico centra la
atención en lo que se produce, mientras el modelo en V lo hace en la actividad. Es un
modelo ideal para proyectos pequeños por su robustez, claridad y sencillez.

El modelo entonces se divide en los siguientes 4 niveles:

 El nivel 1 orientado al “cliente”. Indican el inicio y el fin del proyecto. Se

compone del análisis de requisitos que proporciona el cliente los cuales se
traducen en un documento de requisitos y especificaciones.
 El nivel 2 se dedica a las características funcionales del sistema. El sistema se
interpreta como una caja negra caracterizando aquellas funciones que son
directa o indirectamente visibles para el usuario.
 El nivel 3 define los componentes hardware y software del sistema final, a cuyo
conjunto se denomina arquitectura del sistema. Se definen aquellos elementos
que son necesarios para cumplir con las funcionalidades del nivel 2.
 El nivel 4 es la fase de implementación, en la que se desarrollan los elementos
unitarios o módulos del programa. Una vez definidos los componentes este es
el punto en el que el desarrollador comienza a crear la aplicación.
Este modelo pone de manifiesto el orden cronológico que deben seguir las fases de un
proyecto, impidiendo descender a nivel siguiente si dicho nivel no ha sido completado en la
rama de desarrollo. Tampoco permite ascender en la rama de prueba si la validación anterior
no ha sido completada.

El modelo V muestra el enfoque para una verificación y validación más formal, que
utiliza el desarrollo de software crítico para la seguridad. Ilustra las actividades en cada
etapa de desarrollo y las relaciones entre ellas.

El modelo V de desarrollo de software que muestra la relación entre cada fase y la validación inferida en
cada etapa de prueba.

El modelo V es bueno para ilustrar la relación entre las etapas de desarrollo y las
etapas de validación. En cada etapa de prueba, se validan partes más completas del
software con la fase que lo define. Sin embargo, el modelo V podría implicar un
método de desarrollo en cascada.

La verificación, por otro lado, asegura que cada etapa esté completa y realizada
correctamente:
 E
l modelo V de desarrollo de software que muestra la relación de verificación entre cada etapa de desarrollo.

La verificación implica revisiones, recorridos, análisis, trazabilidad, pruebas y cobertura

de código, y otras actividades para asegurarse de que los equipos estén construyendo
el proceso y el producto correctamente.

Por ejemplo, la ejecución de pruebas unitarias es una actividad de validación, y

garantizar la trazabilidad, la cobertura del código y el progreso de las pruebas de las
pruebas unitarias es la verificación.

El papel clave de la verificación es garantizar que la construcción entregue los

artefactos desde la etapa anterior a la especificación y en cumplimiento con las pautas
de la empresa y la industria.

Metodologías Ágiles.
Las metodologías ágiles son filosofías de trabajo que engloban un conjunto de métodos que
permite adaptar el modo de trabajo a las condiciones del proyecto, aportando flexibilidad y
eficiencia.

En el año 2001, se reunieron importantes desarrolladores de software y pusieron sus

conocimientos en común sobre los mejores métodos de desarrollo creando el Manifiesto Ágil,
en el que se establecieron 12 principios, y cuya filosofía se puede resumir en cuatro ideas
principales

1. Valorar a los individuos e interacciones sobre los procesos y herramientas.

Los procesos y las herramientas son muy importantes, proporcionan métodos para
ejecutar el proceso con eficiencia. Sin embargo, estas características pierden todo su valor
si no van acompañadas de buenos desarrolladores que son los responsables últimos de
realizar las tareas, y cuyo conocimiento y talento serán clave para lograr buenos
resultados.
Los procesos deben ser una ayuda y una guía, deben adaptarse a la organización y al
equipo, y no al revés. Además, no pueden ser rígidos, ya que la sociedad cambia
rápidamente, y los profesionales deben poder hacer propuestas innovadoras para agilizar
procesos.

2. Valorar el software funcionando sobre la documentación extensiva.

El valor que aporta un software en funcionamiento nunca podrá ser superado por la
documentación que se haya podido realizar previamente.

Durante el proceso de desarrollo es importante ir comprobando las funcionalidades que va

adquiriendo el proyecto, tal y como se lleva a cabo en la fase de prototipado de la
metodología Design Thinking.

Ver anticipadamente el comportamiento de las funcionalidades diseñadas y poder

interactuar con los prototipos enriquece el proceso y ofrece la oportunidad de generar
nuevas ideas.

La documentación es importante y en muchos casos necesaria, pero nunca debe

convertirse en una carga que frene la agilidad de los procesos de producción ni en una
barrera para la comunicación directa entre las personas del equipo.

3. Valorar la colaboración con el cliente sobre la negociación contractual.

En un mercado cambiante y en procesos de desarrollo prolongados, la relación del equipo
con el cliente no puede limitarse a un contrato, que no puede ser mucho más que una
 formalidad, sino que el propio cliente debe ser un miembro más del equipo, con una
colaboración activa.

De esta forma, el proyecto se enriquecerá con el conocimiento y la experiencia del cliente

y los posibles cambios que se requieran se llevarán a cabo con mucha mayor rapidez.

La comunicación continua y la flexibilidad del proceso permiten alcanzar un producto de

mayor calidad de la forma más eficiente y mejoran la satisfacción del cliente, que habrá
estado presente durante todo el proceso.

4. Valorar la respuesta ante el cambio en lugar de seguir un plan.

En el método de trabajo tradicional se valora en gran medida una buena planificación
previa y herramientas de control para no desviarse del plan. Este sistema deja de ser
adecuado cuando se opera en un entorno cambiante e inestable, en el que hay una
evolución rápida y continuada. Las metodologías ágiles valoran más la capacidad de
respuesta y una gestión flexible con capacidad de anticipación y adaptación al cambio.
Estas nuevas filosofías ponen de manifiesto una nueva forma de trabajo que ha ido
cogiendo fuerza en la gestión de proyectos generando submetodologías, donde destaca
DevOps.

DevOps
DevOps surge como un acrónimo del inglés de development (desarrollo) y operations
(operaciones). Es una práctica de ingeniería de software que tiene como objetivo unir el
desarrollo con la operación software. La principal característica de DevOps es la
automatización y el control de todos los pasos de construcción software desde la integración,
las pruebas… hasta la implementación

El proyecto sigue una constante realimentación, como ilustra la imagen. Esto se representa
como un bucle infinito donde los pasos dentro del ciclo de vida de un proyecto (planificar,
construir, implementar, comunicar…) se dan a lo largo de todo el tiempo alimentándose unos
de los otros.
Ya no se sigue una gestión lineal y la planificación de trabajo realizada va modificándose
constantemente a medida que avanza el proyecto.

Canalizaciones híbridas de DevOps para software crítico para la seguridad

En muchas organizaciones de software integrado, la implementación de un proceso
totalmente ágil no es compatible con las restricciones que les imponen los estándares de
seguridad y protección de la industria. Los artefactos, el código, los resultados de las pruebas y
la documentación a menudo requieren y establecen fechas de entrega. El progreso se basa en
estos entregables (hitos).

En algunos casos, como los grandes proyectos militares y de defensa, los entregables de hitos
se incorporan al contrato y a los acuerdos de pago. Aunque esto implica un enfoque en
cascada, no hay razón para limitar el desarrollo de software. Los equipos pueden usar modelos
híbridos para lograr hitos de entregables utilizando métodos iterativos y ágiles internamente.
La razón para plantear esto en una discusión sobre verificación y validación es que los equipos
pueden aprovechar muchos de los beneficios de la integración y las pruebas continuas en
aplicaciones complejas críticas para la seguridad.

Parte de eso es cambiar la verificación y validación de la izquierda lo más temprano posible en

el proceso de desarrollo. Por ejemplo, no hay razón para retrasar las pruebas unitarias hasta
que todas las unidades estén codificadas o esperar para analizar el código con análisis estático
hasta que esté listo para la integración.

De manera similar, los desarrolladores deben intentar las pruebas de integración tan pronto
como estén listos los componentes probados por la unidad. La combinación de la
automatización con un enfoque continuo e iterativo proporciona enormes beneficios para la
validación y verificación del software.

El modelo V muestra el enfoque para una verificación y validación más formal, que utiliza el
desarrollo de software crítico para la seguridad.

Verificación acelerada
La verificación implica el trabajo para garantizar que cada fase de desarrollo cumpla con la
especificación del paso anterior. En términos de codificación y prueba de software, la
verificación es asegurarse de que el código satisfaga el diseño del módulo y, en última
instancia, el diseño de alto nivel y los requisitos anteriores.

Además, la verificación asegura el cumplimiento de los requisitos a nivel de proyecto. Dichos

requisitos incluyen el cumplimiento de los estándares de la industria, la gestión de riesgos, la
trazabilidad y las métricas (cobertura y cumplimiento del código).

 Utilice el análisis estático lo antes posible para garantizar la calidad y la seguridad a

medida que los desarrolladores escriben código. Además, el análisis estático evita
errores y vulnerabilidades futuros, lo que reduce el impacto posterior de los errores
que se pasaron por alto durante la inspección y las pruebas.
  Automatización del cumplimiento de los estándares de codificación para reducir el
esfuerzo manual y acelerar las inspecciones de códigos.

 Trazabilidad bidireccional para todos los artefactos para asegurarse de que los

requisitos tengan código y pruebas para demostrar que se están cumpliendo. Las
métricas, los resultados de las pruebas y los resultados del análisis estático se rastrean
hasta los componentes y viceversa.

 Cobertura de código y prueba para asegurarse de que se implementen todos los

requisitos y para asegurarse de que la implementación se pruebe según sea necesario.

 Informes y análisis para ayudar a la toma de decisiones y realizar un seguimiento del

progreso. La toma de decisiones debe basarse en los datos recopilados de los procesos
automatizados.

 Generación de documentación automatizada desde análisis y resultados de pruebas

para respaldar el cumplimiento de estándares y procesos.

 Automatización del cumplimiento de estándares para reducir los gastos generales y la

complejidad mediante la automatización de los procesos más repetitivos y tediosos.
Además, las herramientas pueden realizar un seguimiento del historial del proyecto y
relacionar los resultados con los requisitos, los componentes de software, las pruebas
y las desviaciones registradas.

Validación acelerada
La validación es demostrar que un producto cumple con sus requisitos cuando la ejecución del
código es necesaria ya sea de forma aislada para pruebas unitarias o en varias etapas de
integración. Automatizar estos conjuntos de pruebas es un gran ahorro de tiempo para el
desarrollo de software integrado.

La validación requiere la ejecución en el hardware de destino. La optimización de las pruebas

de regresión aprovecha al máximo los recursos, las personas y el hardware disponibles.

 Automatización de todas las suites de prueba minimiza las pruebas manuales y

reduce el cuello de botella de las pruebas debido a la disponibilidad limitada de
hardware.

 Ejecución de pruebas basadas en host y destino admite diferentes técnicas de

validación según sea necesario.

 Prueba de cambio a la izquierda comienza tan pronto como los equipos desarrollan el

código. Aprovecha los marcos de pruebas unitarias y genera automáticamente arneses
para probar tan pronto como el código esté listo. El soporte para el desarrollo basado
en pruebas y las pruebas continuas está disponible a medida que madura el proceso
de una organización.

 Gestione el cambio con la ejecución inteligente de pruebas para centrarse en las

pruebas solo para el código que cambió y los dependientes afectados.

 Trazabilidad bidireccional entre código, pruebas, resultados de análisis estáticos y

requisitos y soporte para herramientas de gestión del ciclo de vida de las aplicaciones
(ALM) en toda la empresa.
Bibliografía
http://validacionsoftware.blogspot.com/2012/08/introduccion.html

https://es.parasoft.com/blog/verification-vs-validation-in-embedded-software/

http://ramon-gzz.blogspot.com/2012/08/verificacion-y-validacion-de-software.html

https://academica-e.unavarra.es/xmlui/bitstream/handle/2454/40278/
TFE_Laura_Merino_Desarrollo%20de%20un%20Proceso%20de%20Validaci%C3%B3n%20y
%20Verificaci%C3%B3n%20Software.pdf?sequence=1&isAllowed=y

https://spa.myservername.com/exact-difference-between-verification