Verificación - jddiosvivar.files.wordpress.com · lugar al ciclo Deming, el cual fue utilizado ......
53
Verificación 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.
Transcript of Verificación - jddiosvivar.files.wordpress.com · lugar al ciclo Deming, el cual fue utilizado ......
Verificación3.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.
Etapa 1: Hasta 1956La orientación de las pruebas a la solución de
errores.
Durante los comienzos de la TI, a pesar
de ser notoria la aparición de problemas
relacionados con el software desarrollado,
éstos fueron dados de lado en pro de los
aspectos hardware.
El primer artículo basado en las pruebas
del software fue escrito por Alan Turing
en 1949 En este artículo se hablaba de
“pruebas de corrección”.
Etapa 2: 1957-1978La orientación de las pruebas a la demostración
En 1957, Charles Baker distinguió el concepto de “depuración” del de “prueba” en su revisión “Mathematical Tables and Other Aids to Computation”. En la cual se destacaba que la verificación de los programas perseguía dos objetivos fundamentales:
“Asegurar el funcionamiento de la aplicación”
“Asegurar que la aplicación resolvía el problema para el que había sido planteada”.
En esta etapa, debido a que llevar a cabo
las pruebas suponía un esfuerzo
comprendido de entre un 30% y un 50%
como mínimo, del coste total de un
desarrollo software. Autores como Ince y
Jessop llegaron a la conclusión de que si el
proceso de pruebas pudiese ser
automático se reduciría significativamente
su coste.
A mediados de los años 70 distintos
autores presentaron metodologías para la
generación automática de datos de
prueba orientados a la trayectoria en las
publicaciones.
Etapa 3: 1979-1982La orientación de las pruebas a la detección.
En 1979, Myers describió el modelo
orientado a la detección de pruebas y
definió éstas como “el proceso de
ejecutar un programa con la intención de
encontrar errores”.
En 1982, surge una nueva metodología
orientada a la automatización de casos de
prueba denominada “aleatoria”. Publicada
en “Automatic generation of random
selfchecking test cases” por Bird y Muñoz.
Etapa 4: 1983 -1987La orientación de las pruebas a la evaluación
En 1983, el “Institute for Computer Sciences
and Technology of the National Bureau of
Standars” publica una línea de investigación
especialmente orientada a los sistemas de
procesamiento de información federal (FIPS).
En la cual se describe una metodología que
integra el análisis, la revisión y las actividades
de prueba con el fin de ofrecer una
evaluación del producto a lo largo del ciclo
de vida del software.
Filosofía de FIPS
“Ninguna técnica de verificación y
validación puede garantizar la corrección,
es decir, un software libre de errores. Sin
embargo, una cuidadosa elección de
técnicas para un proyecto especifico
puede ayudar a asegurar el desarrollo y el
mantenimiento de la calidad del software
de un proyecto”
En 1979, dado el desarrollo de las pruebas
hasta ese momento, Glenford J. Myers
promovió que la Ingeniería del Software
separase las disciplinas fundamentales del
desarrollo del software de la verificación
y validación, disciplina que abarcaría las
pruebas del software.
Ese mismo año, un grupo del comité
técnico de ingeniería del software del
IEEE comenzó a trabajar en un estándar
para la documentación de las pruebas del
software.
Como resultado, el estándar ANSI/IEEE
STD 829-1983 fue publicado en 1983
especificando el contenido y el formato
de ocho documentos estándares.
Las principales diferencias existentes
entre la propuesta ofrecida en el estándar
ANSI/IEEE STD 829-1983 y las prácticas
realizadas por aquel entonces, residían en
las especificaciones de la planificación y el
diseño de las pruebas.
En 1984 el congreso del gobierno americano
aprobó la creación de un organismo de
investigación para el desarrollo de modelos
de mejora para los problemas en el
desarrollo de los sistemas de software, y
evaluar la capacidad de respuesta y fiabilidad
de las compañías que suministran software al
Departamento de Defensa (DoD), dando
lugar al Instituto de Ingeniería del Software
(SEI).
Años más tarde, un segundo grupo
perteneciente al IEEE comenzó a
desarrollar un estándar basado en las
pruebas unitarias. Como resultado, el
estándar ANSI/IEEE STD 1008-1987 fue
publicado en 1987.
Un año después de comenzarse a
desarrollar el estándar orientado a las
pruebas unitarias, en 1985 sus autores
introdujeron aquel proceso a lo largo de
los distintos niveles de prueba existentes,
dando como resultado una metodología
conocida como “el proceso de evaluación
y de pruebas sistemáticas” (STEP) .
Etapa 5: 1988La orientación de las pruebas a la prevención
En 1989, Watts Humphrey y Ron Radice
extendieron los principios desarrollados
por Deming para su aplicación a la
industria del software a través de sus
trabajos en IBM y en el SEI.
Ya en la década de los 90, es publicado el
libro “Software Testing Techniques” el
cual hace gala de un gran catalogo de
técnicas de prueba
En 1991, Hetzel estableció el proceso de
pruebas como la planificación, el diseño, la
implementación y la ejecución de las
pruebas y sus entornos.
Pero 1991 fue un año especialmente
significativo ya que también vio la luz el
proyecto comenzado años más tarde por
el SEI, el Modelo de Madurez de las
Capacidades para el Software (SW-CMM,
Capability Maturity Model for Software).
Calidad del Software
Según IEEE para la ingeniería de
software
“El grado con el cual un sistema,
componente o proceso cumple con los
requerimientos y con las necesidades y
expectativas del usuario ”
Actividades Principales
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 Sw
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 Sw
Planificación
Implementación
Pruebas
Documentación
Despliegue
Mantenimiento
Modelos de desarrollo de Sw
Modelo en casada
Modelo lineal secuencial
RUP
Debido a la imposibilidad humana de
trabajar y comunicar de forma perfecta, el
desarrollo de software ha de ir
acompañado de una actividad que
garantice la calidad.
Los proyectos de desarrollo de software
han padecido tradicionalmente problemas
de calidad, tanto en el propio proceso de
desarrollo como en los productos de
entrega.
Primer problema
El primer problema pone de manifiesto
una falta de calidad en el proceso de
gestión de los proyectos de software:
Cuanto menor es ésta, peor es el grado
de adherencia a los plazos y a los
esfuerzos.
Segundo Problema
El segundo problema indica la falta de
calidad de los productos desarrollados:
cuanto menor es ésta, mayor es el
número de defectos y, consecuentemente,
mayor será el número de fallos que
aparecerán durante la ejecución del
software.
Para hacer frente a esta situación la
comunidad involucrada en el desarrollo
del software ha reaccionado con diversas
iniciativas metodológicas, Como:
Definición de Modelos de
Referencia De esta forma nació el Modelo CMMI,
diseñado por el SEI, que establece cinco
niveles de madurez, especificando para
cada uno de ellos los objetivos que deben
ser cubiertos para que una organización
pueda ser calificada con el nivel de
madurez correspondiente.
Se calcula que el 75% de las
organizaciones dedicadas al desarrollo de
software está en el nivel de madurez 1, es
decir, en el más bajo.
Normas y Guías
El establecimiento de normas y guías para el desarrollo de software, Éstas han sido promovidas o generadas por entidades de reconocido prestigio (IEEE, CEI, BSI, AENOR) y se han orientado a definir el ciclo de vida del software, a normalizar la terminología o a desarrollar aspectos específicos del ciclo de vida, tales como la documentación, la verificación y validación o las pruebas de componentes.
Como resultado de estas iniciativas, las
empresas han ido tomando consistencia
de la necesidad de mejorar los procesos
de desarrollo de software demandado
nuevos servicios a las empresas
consultoras de TI.
Características del enfoque
Las pruebas no son una fase aislada del
proyecto si no que constituyen en sí un
proyecto con su propio ciclo de vida.
Los equipos de desarrollo y de pruebas
son independientes, con funciones y
perfiles diferenciados.
Antes de la ejecución de las pruebas se
lleva a cabo todo un proceso
metodológico que facilita y asegura el
éxito de las mismas.
En el momento de la ejecución, está todo
previsto, tanto los aspectos funcionales
como técnicos, evitándose la
improvisación.
Para alcanzar mayores niveles de
eficiencia en el desarrollo de software, es
de considerar un planteamiento más
extenso y profundo de lo que
habitualmente se conoce como fase de
pruebas, ya que aunque no garantice por
sí misma la calidad de sw implantado si
aporta beneficios .
Beneficios
Objetivos de costos
Plazos
Calidad final
Producto final
MoProSoft. Modelo de procesos
para la industria del sw Modelo para la mejora y evaluación de
procesos de desarrollo y mantenimiento
de sistemas y productos de software.
Desarrollado por la Asociación mexicana
para la calidad en ingeniería de Sw.
Considera que modelos como CMMI e
ISO/IEC 15504 no son apropiados para
pequeñas y medianas empresas.
Criterios para la elaboración de
este modelo de procesos: La estructura de procesos resultante
debe ser acorde a la estructura generalmente empleada por las organizaciones de la industria del sw.
La alta dirección tiene un papel importante a través de la planeación estratégica.
El modelo considera la gestión como proveedora de recursos, procesos y proyectos.
El modelo integra con calidad y consistencia los elementos indispensables para la definición de los procesos y las relaciones entre ellos.
El modelos destaca la importancia de la gestión de recursos, con especial relevancia en aquellos que componen el conocimiento de la organización: productos generados por proyectos, datos de los proyectos…
Se basa en los modelos de procesos ISO
9001:2000
