INTEGRACIÓN, VERIFICACIÓN Y

VALIDACIÓN DEL SISTEMA

Víctor A. Dueñas Robles

TAC
Auditoría Informática
 [INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA] TAC

INTRODUCCIÓN

Este trabajo de ampliación de conocimientos trata sobre como partiendo de la

ingeniería del software y más concretamente sobre las últimas fases de los distintas
metodologías de desarrollo que suelen converger finalmente en las pruebas de
integración del sistema podemos conseguir que durante la auditoría realizada a
nuestro sistema no se detecten errores graves o que no se cumple la función
informática para la que estaba diseñado el sistema.

En este trabajo también veremos que dependiendo del modelo de desarrollo de

software que apliquemos la forma en la que aplicaremos la verificación y validación del
sistema se realizará en distintos momentos aunque la integración siempre se suele
realizar en las fases finales de desarrollo.

Antes de seguir desarrollando el tema debemos de comprender los siguientes

conceptos:

AUDITORÍA INFORMÁTICA

La auditoría informática es el proceso de recoger, agrupar y evaluar evidencias para

determinar si un sistema de información salvaguarda el activo empresarial, mantiene
la integridad de los datos, lleva a cabo eficazmente los fines de la organización, utiliza
eficientemente los recursos, y cumple con las leyes y regulaciones establecidas.

También permiten detectar de forma sistemática el uso de los recursos y los flujos de
información dentro de una organización y determinar qué información es critica para
el cumplimiento de su misión y objetivos, identificando necesidades, duplicidades,
costes, valor y barreras, que obstaculizan flujos de información eficientes.

Auditar consiste principalmente en estudiar los mecanismos de control que están

implantados en una empresa u organización, determinando si los mismos son
adecuados y cumplen unos determinados objetivos o estrategias, estableciendo los
cambios que se deberían realizar para la consecución de los mismos. Los mecanismos
de control pueden ser directivos, preventivos, de detección, correctivos o de
recuperación ante una contingencia.

Los objetivos de la auditoría Informática son:

 El control de la función informática

 El análisis de la eficiencia de los Sistemas Informáticos
 La verificación del cumplimiento de la Normativa en este ámbito
 La revisión de la eficaz gestión de los recursos informáticos.

2 Víctor A. Dueñas Robles

 [INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA] TAC

La auditoría informática sirve para mejorar ciertas características en la empresa como:

 Eficiencia
 Eficacia
 Rentabilidad
 Seguridad

INGENIERÍA DEL SOFTW ARE

“Ingeniería de Software es el estudio de los principios y metodologías para el

desarrollo y mantenimiento de sistemas software” (Zelkovitz, 1978)

“Ingeniería de software es la aplicación práctica del conocimiento científico al

diseño y construcción de programas de computadora y a la documentación
asociada requerida para desarrollar, operar y mantenerlos. Se conoce también
como Desarrollo de Software o Producción de Software” ( Bohem, 1976).

“Ingeniería de Software trata del establecimiento de los principios y métodos de la

ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en
máquinas reales” (Bauer, 1972).

“Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al

desarrollo, operación y mantenimiento del software; es decir, la aplicación de la
ingeniería al software” (IEEE, 1993).

INTEGRACIÓN DEL SIST EMA

Pruebas integrales o pruebas de integración son aquellas que se realizan en el ámbito

del desarrollo de software una vez que se han aprobado las pruebas unitarias.
Únicamente se refieren a la prueba o pruebas de todos los elementos unitarios que
componen un proceso, hecha en conjunto, de una sola vez.

Consiste en realizar pruebas para verificar que un gran conjunto de partes de software
funcionan juntos.

Las pruebas de integración (algunas veces llamadas integración y testeo I&t) es la fase
del testeo de software en la cual módulos individuales de software son combinados y
testeados como un grupo. Son las pruebas posteriores a las pruebas unitarias y
preceden el testeo de sistema.

3 Víctor A. Dueñas Robles

 [INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA] TAC

VERIFICACIÓN

La verificación consiste en el conjunto de técnicas que empleamos para averiguar si el

software que estamos desarrollando funciona adecuadamente y se está desarrollando
según los requisitos fijados en la fase de análisis.

VALIDACIÓN

La validación sin embargo se centra en comprobar si el software que estamos

desarrollando cumple todos los requisitos que se fijaron en la fase de análisis y realiza
la función para la que se creó.

Para entenderlo mejor durante el proceso de verificación podemos detectar que

nuestro software funciona correctamente pero en el proceso de validación podemos
detectar que no realiza la función que deseamos.

SITUACIÓN ACTUAL

Para comprender el papel que realiza la integración, validación y verificación primero

debemos de conocer algunos modelos de desarrollo de software y en que fases se
aplican estas técnicas.

MODELOS DE DESARROLLO SOFTWARE

Los modelos de desarrollo de software son distintos paradigmas que nos indican cómo
realizar el ciclo de vida del software.

Algunos de estos modelos son los siguientes:

4 Víctor A. Dueñas Robles

 [INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA] TAC

MODELO DE LAS FASES

En Ingeniería de software el desarrollo en

cascada, también llamado modelo en
cascada, es el enfoque metodológico que
ordena rigurosamente las etapas del ciclo
de vida del software, de tal forma que el
inicio de cada etapa debe esperar a la
finalización de la inmediatamente
anterior.

En el dibujo de las fases del modelo

podemos ver como al final de cada fase
se activa o la verificación o la validación y
también como en la fase de integración
realizamos las Pruebas de integración

Este modelo no sólo abarca el proceso de

desarrollo sino también la implantación
del software dentro del sistema.

DESARROLLO EN ESPIRAL

Las actividades de este modelo se

conforman en una espiral, en la que
cada bucle o iteración representa un
conjunto de actividades. Las
actividades no están fijadas a priori,
sino que las siguientes se eligen en
función del análisis de riesgo,
comenzando por el bucle interior.

En cada iteración se realizan cuatro

tareas

- Determinar o fijar objetivos :

 Fijar también los productos
definidos a obtener: requerimientos, especificación, manual de usuario.
 Fijar las restricciones.
 Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.
 Hay una cosa que solo se hace una vez: planificación inicial o previa.

5 Víctor A. Dueñas Robles

 [INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA] TAC

- Análisis del riesgo:

 Se estudian todos los riesgos potenciales y se seleccionan una o varias
alternativas propuestas para reducir o eliminar los riesgos.
- Desarrollar, verificar y validar (probar):
 Tareas de la actividad propia y de prueba.
 Análisis de alternativas e identificación resolución de riesgos.
 Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo
para el desarrollo, el que puede ser cualquiera de los otros existentes, como
formal, evolutivo, cascada, etc. Así si por ejemplo si los riesgos en la interfaz
de usuario son dominantes, un modelo de desarrollo apropiado podría ser la
construcción de prototipos evolutivos. Si lo riesgos de protección son la
principal consideración, un desarrollo basado en transformaciones formales
podría ser el más apropiado.
- Planificar:
 Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos
con las fases siguientes y planificamos la próxima actividad.

DESARROLLO POR ETAPAS

El modelo de desarrollo de software por etapas es similar al Modelo de prototipos ya

que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se
diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto
y por tanto se van desarrollando simultáneamente con las diferentes versiones del
código.

Pueden distinguirse las siguientes fases:

 Especificación conceptual
 Análisis de requerimientos
 Diseño inicial
 Diseño detallado, codificación, depuración y liberación

Estas diferentes fases se van repitiendo en cada etapa del diseño.

La mayor diferencia con respecto al modelo de desarrollo por prototipos es la

diferenciación de distintos estados dentro del ciclo de desarrollo del software, estas
son las fases:

- Plan operativo: Etapa donde se define el problema a resolver, las metas del
proyecto, las metas de calidad y se identifica cualquier restricción aplicable al
proyecto.

6 Víctor A. Dueñas Robles

 [INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA] TAC

- Especificación de requerimientos: Permite entregar una visión de alto nivel

sobre el proyecto, poniendo énfasis en la descripción del problema desde el
punto de vista de los clientes y desarrolladores. También se considera la
posibilidad de una planificación de los recursos sobre una escala de tiempos.
- Especificación funcional: Especifica la información sobre la cual el software a
desarrollar trabajará.
- Diseño: Permite describir como el sistema va a satisfacer los requerimientos.
Esta etapa a menudo tiene diferentes niveles de detalle. Los niveles más altos
de detalle generalmente describen los componentes o módulos que formarán
el software a ser producido. Los niveles más bajos, describen, con mucho
detalle, cada módulo que contendrá el sistema.
- Implementación: Aquí es donde el software a ser desarrollado se codifica.
Dependiendo del tamaño del proyecto, la programación puede ser distribuida
entre distintos programadores o grupos de programadores. Cada uno se
concentrará en la construcción y prueba de una parte del software, a menudo
un subsistema. Las pruebas, en general, tiene por objetivo asegurar que todas
las funciones están correctamente implementadas dentro del sistema.
- Integración: Es la fase donde todos los subsistemas codificados
independientemente se juntan. Cada sección es enlazada con otra y, entonces,
probada. Este proceso se repite hasta que se han agregado todos los módulos y
el sistema se prueba como un todo.
- Validación y verificación: Una vez que el sistema ha sido integrado, comienza
esta etapa. Es donde es probado para verificar que el sistema es consistente
con la definición de requerimientos y la especificación funcional. Por otro lado,
la verificación consiste en una serie de actividades que aseguran que el
software implementa correctamente una función específica. Al finalizar esta
etapa, el sistema ya puede ser instalado en ambiente de explotación.
- Mantención: La mantención ocurre cuando existe algún problema dentro de
un sistema existente, e involucraría la corrección de errores que no fueron
descubiertos en las fases de prueba, mejoras en la implementación de las
unidades del sistema y cambios para que responda a los nuevos
requerimientos. Las mantenciones se puede clasificar en: correctiva,
adaptativa, perfectiva y preventiva.

7 Víctor A. Dueñas Robles

 [INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA] TAC

INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN E N LOS MODELOS DE DESARROLLO

En el apartado anterior hemos visto los distintos modelos de desarrollo de software y

como en ellos aparecen las fases de integración, verificación y validación.

Dependiendo del modelo la verificación y la validación se realizan como una etapa

aparte o al finalizar cada una de las etapas.

En lo único que si suelen coincidir todos es en que la integración es una fase aparte
dentro del ciclo de vida del software.

COMO REALIZAR LA VERIFICACIÓN Y VALIDACIÓN

Para realizarla utilizaremos las recomendaciones de los documentos de la ESA

(European Space Agency ) y los del IEEE.

La ESA ha escrito una amplia serie de documentos sobre cómo se debe de desarrollar
el software de es esta agencia y utilidades para mejorarlo.

Dentro de todos los documentos que esta agencia provee nos centraremos en ECSS-E-
40

En el caso del IEEE nos centraremos en el documento IEEE Std 1012-1998.

Según los documentos citados anteriormente debemos de tener en cuenta los

siguientes pasos para realizar la verificación y validación

DIFERENCIA ENTRE VERIFICACIÓN Y VALIDACIÓN, NIVEL DE CONFIANZA.

Verificación:

 Confirmación mediante examen y evidencias objetivas que un elemento

cumple con los requisitos específicos.
 El proceso de verificación debe asegurar que para cada actividad existen las
entradas y especificaciones adecuadas, y que las salidas de esa actividad son
correctas y consistentes con dichas entradas y especificaciones.
 ¿Estamos construyendo el producto correctamente?

Validación:

 Confirmación mediante examen y evidencias objetivas que un Sw cumple con

los requisitos particulares para un uso específico.
 El proceso de validación asegurar que en el producto final Sw las funciones
baseline y los rendimientos requeridos están correcta y completamente
implementados.
 ¿Estamos construyendo el producto correcto?
8 Víctor A. Dueñas Robles
 [INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA] TAC

Objetivo final:

Tener confianza en que el software va a funcionar. El nivel de confianza requerido

depende de:

Propósito del sistema:

- cuan crítico es el software para la organización

- Expectativas del usuario
- En cuanto el Sw no puede fallar. La moral del usuario a este respecto es baja y
pierde confianza.

HERRAMIENTAS, WORKBENCH

- Pruebas de cobertura: Rational Coverage – Purify

- Busqueda de errores: depuradores. Suelen ir incluidos en el IDE del lenguaje

que estemos empleando.
- Medidas de rendimiento: gprof
- Herramientas de generación de vectores de test o passwords

TIPOS DE TÉCNICAS

ERROR/FIABILIDAD

Tipos de estrategia que son radicalmente distintas

- Búsqueda del error: Pretende buscar en qué funciona mal el software

- Análisis de la fiabilidad: Pretende determinar cuan bueno es el software

El error:

- Descubrir un error

9 Víctor A. Dueñas Robles

 [INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA] TAC

- Buena prueba es la que tiene una alta probabilidad de demostrar un error no

descubierto hasta entonces
- Una prueba que tiene éxito es la que descubre un error
- Una prueba no demuestra que no hay errores

Técnicas de fiabilidad

- Test estadístico
- Se emplea para determinar el rendimiento y la fiabilidad del programa.
- Se realiza sobre las condiciones reales de trabajo y con las frecuencias de
entrada y salida reales.
- Después de la ejecución de los test, se realiza un análisis de los fallos o defectos
encontrados para determinar la fiabilidad del sistema (cuantas veces se ha
colgado, no necesariamente errores de código).

ANÁLISIS/MEDIDA

Análisis

- Técnicas que analizan la consistencia

- El programa utiliza la sintaxis correcta, emparejamiento de parámetros, estilo,
translación de especificaciones.

Medida

- Técnicas que miden alguna propiedad de los elementos software

INSPECCIONES DE SOFTWARE O ESTÁTICAS, REVISIONES: REVISIÓN PEER2PEER,

INSPECCIÓN FAGAN, WALKTHROUGH, AUDITORIAS

INSPECCIONES DE SOFTWARE O ESTÁTICAS:

o Tiene como objeto: documentos, modelos, código

o Se aplica en todas las fases, esto es muy importante porque permite
iniciar las V&V antes de escribir una sola línea de código, que es lo que
hay que hacer.

REVISIONES PEER2PEER: REVISIONES CRUZADAS

Inspecciones -inspección de Fagan: Son inspecciones para evaluar el código de

sentencia en sentencia.

Tiene las siguientes 6 fases:

- Planificación:

10 Víctor A. Dueñas Robles

 [INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA] TAC

Cuando el desarrollador completa su un ""producto de trabajo"", se forma

un grupo de inspección y se designa un moderador.

El moderador asegura que el ""producto de trabajo"" satisfaga el criterio de

inspección. Se le asignan diferentes roles a las personas que integran el grupo
de inspección, así como la planificación de tiempos y recursos necesarios .

- Overview:

Si los inspectores no están familiarizados con el desarrollo del proyecto, un

vista general es necesaria en éste momento. Este es un paso opcional, pero no
menos importante ya que en esta etapa se dará al grupo de inspección un
"background" y el contexto a cubrir por las inspecciones.

- Preparación:

Los inspectores se preparan individualmente para la evaluación en la reunión,

estudiando los productos de trabajo y el material relacionado. Aquí es
aconsejable la utilización de listas de chequeos para ayudar a encontrar
defectos comunes, y .

El tiempo que pueda llevar esta etapa va a depender de cuan familiarizado esté
el inspector con el trabajo que debe analizar.

- Examen:

En esta etapa, los inspectores se reúnen para analizar su trabajo individual en

forma conjunta. El moderador deberá asegurarse que todos los inspectores
están suficientemente preparados. La persona designada como lector presenta
el "producto de trabajo", interpretando o parafraseando el texto, mientras que
cada participante observa en busca de defectos.

Es recomendable que este examen no dure más de 2 horas ya que la atención

en busca de defectos va disminuyendo con el tiempo. Al terminar con la
reunión, el grupo determina si el producto es aceptado o debe ser retrabajado
para una posterior inspección.

- Retrabajo:

El autor corrige todos los defectos encontrados por los inspectores.

- Seguimiento:

El moderador chequea las correcciones del autor. Si el moderador está

satisfecho, la inspección está formalmente completa, y el "producto de trabajo"
es puesto bajo el control de configuración.

11 Víctor A. Dueñas Robles

 [INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA] TAC

WALKTHROUGS

Es una inspección como la de Fagan pero con las siguientes características:

o El análisis es presentado por el propio desarrollador

o El mecanismo para conducir la inspección es el desarrollo de un
escenario sobre el código.
o El desarrollo de la prueba sirve para iniciar la discusión.

WALKTHOUGHT COGNITIVO

Es un walkthrougt (ver tema anterior) pero guiado solo a través del análisis de
los pasos de un GUI.

Tomando los revisores el papel de usuarios y siguiendo el proceso a través de

un escenario o de un test.

AUDITORIAS

Sobre todo realizadas por elementos externos. Buscan inconsistencia en todo

el proceso (calidad, configuración, manuales de estilo) y son también una
técnica de validación.

ESTÁTICAS - ANÁLISIS: ANÁLISIS DE CONFIANZA, EJECUCIÓN SIMBÓLICA, PRUEBAS

FORMALES, TRACEABILIDAD, CHECKLIST

ANÁLISIS DE CONFIANZA

Identificar peligros y proponer métodos para reducir el riesgo de que estos

riesgos se produzcan. No es exactamente el análisis de riesgos que se realiza en
la etapa de planificación pues el primero está orientado a los riesgos para que
el proyecto llegue a buen término, mientras que este está orientado a que los
problemas puros de la operación del software

- Análisis de los peligros - implica el uso de guías para identificar peligros, sus
raíces y posibles contramedidas.
- Análisis del riesgo - Yendo más allá, identifica las consecuencias y la
probabilidad de que ocurra.

EJECUCIÓN SIMBÓLICA

12 Víctor A. Dueñas Robles

 [INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA] TAC

La ejecución simbólica es un método de análisis estático del código en el que se

recorre la ejecución del código pero en vez de que con valores de un escenario,
se realiza asignando símbolos a las variables.

PRUEBAS FORMALES

Consiste en emplear técnicas matemáticas para expresar, investigar y analizar el

diseño, documentación y el comportamiento del software y del hardware.

TRACEABILIDAD

Tanto hacia delante como hacia atrás

CHECKLIST

Se deben de elaborar listas de verificación con los puntos a tener en cuenta.

PRUEBAS DEL SOFTWARE O DINÁMICAS

Son distintas pruebas realizadas con el programa en ejecución.

MÉTODOS DE PRUEBAS

PRINCIPIOS, PERFILES DE FALLO, PRIORIZACIÓN Y CATEGORIZACIÓN, FACILIDAD,

TIPOS, PROPÓSITO

PRINCIPIOS

Tiene que seguir una traceabilidad hasta los requisitos

Planificarse antes de que empiecen

El principio de Pareto es aplicable:

o 80% de los errores en el 20% de los módulos. El problema es encontrar

esos módulos

No son posibles las pruebas exhaustivas.

PERFILES DE FALLO, PRIORIZACIÓN Y CATEGORIZACIÓN DEL ERROR

A medida que se van haciendo las pruebas y se recogen los datos de los errores,
se pueden emplear los perfiles de fallos para dar prioridad y categorizar los
errores descubiertos La prioridad indica la severidad del problema.

13 Víctor A. Dueñas Robles

 [INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA] TAC

Las categorías de los fallos proporcionan una descripción de un error, de

manera que se puedan llevar a cabo análisis estadísticos de errores.

FACILIDAD DE LA PRUEBA

En un proceso de prueba es muy importante seguir unos principios que hagan

la prueba lo más sencilla posible para minimizar su coste:

- Cuanto mejor funciona más fácil es de probar.-

- Lo que ves es lo que pruebas
- A mayor control del software más fácil es el proceso de pruebas
- Controlar el ámbito de pruebas hace que sea más fácil probar
- Cuanto menos haya que probar más fácil es probarlo
- Cuantos menos cambios menos interrupciones en las pruebas
- Cuanta más información, más inteligentes son las pruebas.

TIPOS

En cuanto al conocimiento del elemento a probar:

o Caja blanca: Consiste en comprobar que se ha pasado al menos una vez

por todas las sentencias.
o Caja negras: Se identifican objetos abstractos en la aplicación que se
conectan y se evalúa la progresión de la aplicación

En cuanto a su propósito:

o Prueba de defectos
o Análisis de la fiabilidad

INTEGRACIÓN DEL SOFT WARE

Método sistemático para construir la estructura del programa, mientras se prueba la

interacción de cada uno de los módulos y su estructura se ve como un gran árbol.

Estrategias

Big-bang

Incrementales – Descendente

- El módulo principal es el conductor de la prueba.

- Necesita emplear módulos dummy para suplir los que no se han desarrollado
todavía.

14 Víctor A. Dueñas Robles

 [INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA] TAC

- Se van sustituyendo los módulos dummy por los reales uno a uno
- Se sigue una estrategia de regresión
- Tipos:
o Primero en profundidad
o Primero en anchura

Ascendente

- Los módulos inferiores (las hojas del arbol) se asocian en grupos por función.
- A estos grupos se les añade un controlador
- Y se sigue el proceso hacia arriba

Combinación guiada por los módulos críticos

PRUEBA DE SISTEMA: DELEGACIÓN, RECUPERACIÓN, SEGURIDAD, RESISTENCIA,

ESPECIALES: C/S

Delegación de culpabilidad

- No solo incumben al proceso Software sino al Hardware también.

- Como el equipo es interdisciplinar cuando no funciona un componente hay
una delegación de culpabilidad.

Estrategias para manejar este problema:

- Diseñar caminos de manejo de errores de toda la información procedentes de

otros sistemas.
- Simular previamente pruebas que introduzcan datos corruptos en el sistema o
errores de interfaz.
- Participar en el proceso de diseño de pruebas del sistema para asegurar que el
Software se prueba de acuerdo a especificaciones.

Prueba de recuperación:

- Cuánto tarda en recuperarse de una caída del sistema

Prueba de seguridad:

- Evitar intrusiones no autorizadas dentro del sistema

Prueba de resistencia

- Pruebas de carga
- Situaciones anormales
- Prueba de sensibilidad
- Prueba de rendimiento

15 Víctor A. Dueñas Robles

 [INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA] TAC

PROBLEMA

A día de hoy la auditoría de sistemas es una que se aplica de forma muy diferente
dependiendo del sistema y que cuenta con muy pocas herramientas que permitan
realizar tareas de forma automática.

Es por tanto un proceso engorroso en el que la calidad con la que se realice dependerá
de la capacidad del personal que la hace.

Otro de los mayores problemas es que los procesos de validación y verificación hacen
que el desarrollo del software sea proporcionalmente más lento según el rigor con el
que se realicen la validación y la verificación.

CONCLUSIONES

A día de hoy y según se va madurando el desarrollo de software cabría esperar que las
empresas gastasen más recursos en asegurar que su software es de calidad y tuviesen
un mayor rigor en cuanto al ciclo de vida del software se refiere.

También se podría esperar que existiesen unas herramientas intuitivas para realizar la
validación y verificación del software.

La realidad es bastante distinta. Las compañías se centran más en desarrollar su

software rápido y ponerlo pronto en el mercado antes de que su calidad sea
totalmente probada.

Existen muchos ejemplos sobre esta tendencia y el más próximo a todos sería el
Windows Vista que desde primer momento se noto que era un sistema operativo a
medio terminar y que todas las novedades que iba a traer se quedaron en novedades
visuales.

Otro ejemplo desastroso es la actual tendencia del mercado de videojuegos de esta

generación en el que casi todos los videojuegos salen casi sin testear y son los propios
jugadores los que se van encontrando los errores. En algunos juegos esto casi es de
risa como es el caso de Assasain`s creed que hasta que salió su actualización el
personaje de movía de forma errática.

Yo creo que los procesos de verificación y validación han sido sustituidos por las
actualizaciones y por desgracia para todos el papel de los auditores recae ahora en los
usuarios que en vez de cobrar se encuentran con un “trabajo” a medias por el que han
pagado.

16 Víctor A. Dueñas Robles

 [INTEGRACIÓN, VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA] TAC

REFERENCIAS

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software

http://es.wikipedia.org/wiki/Pruebas_de_integraci%C3%B3n

http://es.wikipedia.org/wiki/Auditor%C3%ADa_inform%C3%A1tica

http://es.wikipedia.org/wiki/Modelo_en_cascada

http://es.wikipedia.org/wiki/Desarrollo_en_espiral

http://www.fceia.unr.edu.ar/ingsoft/unidad21-4.pdf

http://es.wikipedia.org/wiki/Desarrollo_por_etapas

http://www.esa.int/TEC/Software_engineering_and_standardisation/TECBUCUXBQE_
2.html

http://www.math.unipd.it/~tullio/IS-1/ECSS-E-40A.pdf

http://standards.ieee.org/reading/ieee/std_public/description/se/1012-
1998_desc.html

http://bmrc.berkeley.edu/purify/docs/html/installing_and_gettingstarted/3-
pureCov.html

http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html#SEC2

Apuntes asignatura Ingeniería del Software

17 Víctor A. Dueñas Robles