3.1 Marco de Referencia para el desarrollo de software 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.

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 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 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.

La orientación de las pruebas a la solución de errores. Etapa 1: Hasta 1956 La 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”.

La orientación de las pruebas a la demostración Etapa 2: 1957-1978 La 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.

La orientación de las pruebas a la detección. Etapa 3: 1979-1982 La 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.

La orientación de las pruebas a la evaluación Etapa 4: 1983 -1987 La 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) .

La orientación de las pruebas a la prevención Etapa 5: 1988 La 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