UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA 301404 INGENIERA DE SOFTWARE

ACTIVIDAD 12: LECCIN EVALUATIVA UNIDAD 3 CONTEXTO1 GARANTA DE CALIDAD DEL SOFTWARE La calidad del software es una compleja mezcla de ciertos factores que varan para las diferentes aplicaciones y los clientes que las solicitan. La garanta de calidad es una actividad esencial en cualquier empresa que produce productos que van a ser usados por otros. Antes del siglo veinte, la garanta de calidad era responsabilidad nica de la persona que construa el producto. La primera funcin de control y de garanta de calidad formal fue introducida por los laboratorios Bell en 1916 y se extendi rpidamente por todo el mundo de las manufacturas. Hoy en da, cada compaa tiene un mecanismo que asegura la calidad de sus productos de hecho, durante la pasada dcada, se han usado ampliamente como tcticas de mercado la declaracin explcita de mensajes que ponan de manifiesto la calidad ofrecida por las compaas. La historia de la garanta de calidad en el desarrollo de software ha sido paralela a la historia en la fabricacin de hardware. Durante los primeros aos de informacin (los 50 y los 60), la calidad era responsabilidad nicamente del programador. Durante los aos 70 se introdujeron estndares de garanta de calidad para el software en los contratos militares de desarrollo de software y se han extendido rpidamente en los desarrollos de software del mundo comercial. La SQA forma parte de una funcin ms amplia de garanta de calidad y engloba actividades que desbordan muchas disciplinas tcnicas. En el desarrollo de software la responsabilidad de la garanta de calidad del software corresponde a muchos constituyentes de una organizacin Ingenieros de software, gestores del proyecto, clientes y las personas que trabajan dentro del grupo de SQA. La garanta de calidad del software es la gua de preceptos de gestin y de las disciplinas de diseo de la garanta de calidad para el espacio tecnolgico y la aplicacin de la ingeniera de software. La capacidad de garantizar la calidad es la medida de la madurez de la disciplina de ingeniera. Al finalizar de seguir esa gua antes mencionada, lo que se obtiene es la madurez de la ingeniera de software. TCNICAS DE PRUEBA DEL SOFTWARE La fase de pruebas es una de las ms costosas del ciclo de vida software. En sentido estricto, deben realizarse pruebas de todos los artefactos generados durante la construccin de un producto, lo que incluye especificaciones de requisitos, casos de uso, diagramas de diversos tipos y, por supuesto, el cdigo fuente y el resto de productos que forman parte de la aplicacin (p.ej., la base de datos). Obviamente, se aplican diferentes tcnicas de prueba a cada tipo de producto software. El estndar ISO/IEC 12207 (ISO/IEC 1995) identifica tres grupos de procesos en el ciclo de vida software: Procesos principales, grupo en el que incluye los procesos de Adquisicin, Suministro, Desarrollo, Operacin y Mantenimiento. Procesos de la organizacin, en donde se encuentran los procesos de Gestin, Mejora, Infraestructura y Formacin. Procesos de soporte o auxiliares, en donde estn los procesos de Documentacin, Gestin de la Configuracin, Auditora, Resolucin de Problemas, Revisin Conjunta, Aseguramiento de la Calidad, Verificacin, Validacin.
1

Resumen organizado por: Ing. Pilar Alexandra Moreno. Docente ECBTI Cead Duitama. Zona centro Boyac. Julio de 2012

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA 301404 INGENIERA DE SOFTWARE

No define, como vemos, un proceso de Pruebas como tal, sino que aconseja, durante la ejecucin de los procesos principales o de la organizacin, utilizar los procesos de soporte. Entre stos se encuentran los procesos de Validacin y de Verificacin: El proceso de Validacin tiene como objetivo determinar si los requisitos y el sistema final cumplen los objetivos para los que se construy el producto, respondiendo as a la pregunta el producto es correcto? El proceso de Verificacin intenta determinar si los productos software de una actividad se ajustan a los requisitos o a las condiciones impuestas en actividades anteriores. De este modo, la pregunta a la que responde este proceso es se est construyendo el producto correctamente? MTRICAS TCNICAS DEL SOFTWARE Algunas de las actividades de desarrollo del proyecto de software comprenden medicin y mtricas, estimacin, anlisis de riesgo, planificacin del programa, seguimiento y control. El recopilar datos (investigacin histrica), calcular mtricas (LDC, PF, mtricas de calidad, orientadas a objetos, etc.) y evaluar mtricas, son algunos de los pasos que deben realizarse al comenzar un producto. Hoy da es cada vez ms frecuente la consideracin de mtricas de software, es por eso que se estn implementando en la actualidad, llevando consigo puntos dbiles (aumento de esfuerzo...) y fuertes (alta calidad, reusabilidad, madurez...) que estn experimentado los ingenieros y desarrolladores de software. El uso de stas se ha adoptado con xito en el amplio mercado de desarrollo de software introduciendo reconocimientos y consideraciones por parte de desarrolladores y usuarios, y estableciendo la necesidad de un enfoque ms disciplinado y de una alta calidad. As muchos particulares y compaas desarrolladoras de software, estn reconociendo la importancia del uso de las mtricas, aunque de igual modo siguen sin conocer el alcance de madurez y calidad del producto final y la disciplina de ingeniera madura que llega a alcanzar con la aplicacin de los distintos mtodos y tcnicas y la interpretacin de los resultados que proyecta el uso de las mtricas. METRICAS DE CALIDAD DEL SOFTWARE Cada uno de los factores de calidad del software puede ser evaluado mediante un conjunto de mtricas basadas en la observacin del software. Para cada criterio McCall propuso una serie de mtricas, aunque, muchas de ellas tienen un carcter subjetivo. Las mtricas pueden ser una simple lista de comprobacin de ciertas caractersticas asociadas a cada factor de calidad. Mc Call propuso un esquema de graduacin mediante una escala que va de cero (bajo) a 10 (alto) para puntuar cada caracterstica y obtener un valor para cada factor. Modelos parecidos al de McCall proponen la norma IEEE 1061 y la norma ISO 9126. Segn Fenton (1997) una mtrica es una asignacin de un valor a un atributo de una entidad de softwa re, ya sea un producto o un proceso. En todos los casos las mtricas representan medidas indirectas de la calidad, ya que miden posibles manifestaciones externas de esa calidad y muchas veces son mediciones subjetivas. Bsicamente se tienen mtricas basadas en el texto del cdigo y mtricas basadas en la estructura de control del cdigo. Un ejemplo de las primeras son las que toman como indicador de tamao las lneas de cdigo, como indicador de documentacin las lneas de comentarios, etc. Las mtricas basadas en la estructura del cdigo de control pueden basarse en la arquitectura del sistema, llamadas entre mdulos, etc. o, tambin, en la estructura interna de cada mdulo utilizando el grafo de control. Una actividad muy importante de la gestin de calidad del software se centra en la identificacin y evaluacin (medicin) de los riesgos potenciales que pueden producir un impacto negativo en el software y hacer que falle. En este entorno distinguimos dos conceptos:

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA 301404 INGENIERA DE SOFTWARE

1. Fiabilidad del software. Se define como la probabilidad de operacin libre de fallos de un programa de computadora en un entorno determinado y durante un tiempo especificado. La fiabilidad utiliza funciones para determinar la probabilidad de que ocurra un fallo en el software, pero la ocurrencia de un fallo no tiene por qu llevar asociado un accidente. 2. La seguridad del software examina de qu forma los fallos producen condiciones que pueden llevar a accidentes. El anlisis del rbol de fallos es un modelo grfico para determinar los estados del sistema peligrosos que pueden conducir a accidentes. Una vez estudiados los riesgos se debe crear una lista adicional de requerimientos diciendo lo que NO debe suceder para garantizar la seguridad del sistema.