NORMA ISO/IEC 14598 Y PRUEBAS DE SOFTWARE

NORMA ISO/IEC 14598 Y PRUEBAS DE SOFTWARE LEIDER ALEXANDER PACHECO. COD. 13520627 TUTOR:  GEOVANNI CATALÁN EVALUACIÓN DE SOFTWARE GRUPO: 301569A_288 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA (UNAD) INGENIERÍA DE SISTEMAS CEAD TUNJA 2016

HISTORIA

 En el año de 1987 la Oficina Internacional para la Estandarización (ISO) y la Comisición Electrotécnica Internacional (IEC), constituyeron un comité técnico conjunto con la finalidad de proponer normas internacionales en el campo de las tecnologías de la información y los equipos denominado ISO/IEC.En 1994, se determina la revisión de la norma ISO/IEC 9126 debido a que se estaban desarrollando normas internacionales en el área de evaluación de la calidad de productos. Como resultado de la revisión, se producen dos series de normas la una ISO/IEC 9126 referida al modelo de calidad del producto software y la ISO/IEC 14598 referida a la evaluación de la calidad del producto. La publicación completa de ambas series, se iniciaron en julio de 1998 y concluyeron en abril de 2004, con 4 normas en las serie 9126 y 6 normas en la serie 14598. Cada una de estas normas está dividida en características y sub-características internas, externas y de usabilidad que hacen posible definir las métricas asociadas a cada una de estas y el tipo de pruebas que se deben llevar a cabo en la evaluación de software. 

 Norma USO/IEC 14598

Define al modelo de calidad como un conjunto de características que conforman la base para especificar requerimientos de calidad y evaluar la calidad; muestra un modelo de calidad de dos niveles para las características y sub-características y en el tercer nivel presenta las métricas con la medición de sus atributos. 

958e1232-3fe4-47d7-8825-06aad2d7e6be (image/png)

Caption: : Esquema general de un modelo de calidad del software

Garvin presenta un enfoque interesante y muy influyente, con cinco visiones de la calidad:  1. La visión trascendental que puede ser reconocida pero no definida 2.  La visión del usuario como la adecuación al propósito del usuario 3. La visión del productor como conformidad con la especificación4. La visión del producto basada en las características observables del producto 5. La visión basada en el valor que el cliente está dispuesto a pagar por ella.

CICLO DE VIDA DE LA CALIDAD

000c7716-91c3-4f5c-b375-f06614591778 (image/png)

cc587f60-53b3-43b9-92ee-dc1872c07a72 (image/png)

Caption: : CARACTERÍSTICAS DE LA CALIDAD INTERNA Y EXTERNA

6d0d8cd3-2362-4d4d-b2a1-e60a9af8c970 (image/png)

Caption: : CARACTERÍSTICAS DE LA CALIDAD EN USO ISO/IEC 9126

 ISO/IEC 14598

Proporciona un marco de trabajo para evaluar la calidad de todos los tipos de productos de software e indica los requisitos para los métodos de medición y para el proceso de evaluación

928801f6-0e81-4511-85bf-7dc19c776452 (image/png)

 Básicamente provee una visión general de las otras cinco partes y explica la relación entre la evaluación del producto software y el modelo de calidad definido en la ISO/IEC 9126. También hace la presentación del proceso de evaluación desglosado en los siguientes pasos: Establecer los requerimientos de evaluación, especificar la evaluación, planear la evaluación, Ejecutar la evaluación.

ISO/IEC 14598 – Parte 1: Visión General:

ISO/IEC 14598 – Parte 2: Planificación 

Esta parte contiene los requerimientos y las guías para las funciones de soporte tales como el planeamiento y gestión para la evaluación del producto del software. Aquí se planifican las mediciones y las actividades de evaluación, específicamente se incluye: Preparación de las políticas, definición de objetivos organizacionales y de mejora, identificación de la tecnología, asignación de responsabilidades, Identificación e implementación de técnicas de evaluación para software desarrollado y adquirido, entrenamiento en tecnología, recopilación de datos y herramientas, comparación y administración de mejoras dentro de la organización.

ISO/IEC 14598 – Parte 3.

El Proceso para desarrolladores: Esta parte provee los requerimientos y las recomendaciones para la evaluación del producto software cuando la evaluación es conducida en paralelo con el desarrollo y llevada a cabo por el desarrollador. Esta parte se enfoca en el uso de indicadores que pueden predecir la calidad final del producto midiendo los productos intermedios que se desarrollan durante el ciclo de vida. Aquí se cubre la planeación y evaluación de mediciones internas y externas con el fin de asegurar de que la calidad del producto sea incorporada en la fase de desarrollo. Una vez identificadas las características fundamentales de calidad y el marco de trabajo, deben ser definidas las etapas siguientes: Organización Planeamiento del Proyecto y requerimientos de Calidad, Especificaciones Diseño y planeamientoEl plan debe incluir: Cronogramas, asignación de responsabilidades, uso de herramientas, bases de datos y entrenamiento especializado requerido, aquí se especifica la precisión de las mediciones y técnicas estadísticas. También debe considerarse como los resultados de las mediciones impactarán en el desarrollo, los planes de contingencia y de mejora. Montaje y pruebas,

ISO/IEC 14598 – Parte 4. El proceso para compradores: Esta parte provee los requerimientos y las recomendaciones para que la evaluación del producto software sea conducida en función a los compradores que planean adquirir o reusar un producto de software existente o pre-desarrollado.ISO/IEC 14598 - Parte 5: El Proceso para Evaluadores: Esta parte provee los requerimientos y recomendaciones para la evaluación del producto software cuando la evaluación es conducida por evaluadores independientes.ISO/IEC 14598 - Parte 6: Documentación de los Módulos de Evaluación: Esta parte provee las guías para la documentación del módulo de evaluación. Estos módulos representan la especificación del modelo de calidad y las correspondientes métricas internas y externas que serán aplicadas a una evaluación en particular. 

PRUEBAS DE SOFTWARE

La calidad es un concepto que se deriva de un conjunto de sub-conceptos. En el caso de la calidad del software, el término es difícil de definir. Con el fin de concretar a qué nos referimos con calidad de un sistema software, se subdivide en atributos: • Funcionalidad – Habilidad del software para realizar el trabajo deseado.• Fiabilidad – Habilidad del software para mantenerse operativo (funcionando).• Eficiencia – Habilidad del software para responder a una petición de usuario con la velocidad apropiada. • Usabilidad – Habilidad del software para satisfacer al usuario.• Mantenibilidad – Habilidad del software para poder realizar cambios en él fácilmente y con una adecuada proporción cambio/costo.• Portabilidad – Habilidad del software para operar en diferentes entornos informáticos.

Se dan dos evaluaciones durante el proceso de desarrollo: Verificaciones y Validaciones. Según el IEEE Std 729-1983 éstas se definen como:• Verificación: Proceso de determinar si los productos de una cierta fase del desarrollo de software cumplen o no los requisitos establecidos durante la fase anterior. • Validación: Proceso de evaluación del software al final del proceso de desarrollo para asegurar el cumplimiento de las necesidades del cliente.

Teniendo esto en cuenta, en un producto software vamos a tener diferentes visiones de la calidad: • Necesaria o Requerida: La que quiere el cliente. • Programada o Especificada: La que se ha especificado explícitamente y se intenta conseguir. • Realizada: La que se ha conseguido. El objetivo es conseguir que las tres visiones coinciden. A la intersección entre la calidad Requerida y la calidad Realizada se le llama calidad Percibida, y es la única que el cliente valora. Toda aquella calidad que se realiza pero no se necesita es un gasto inútil de tiempo y dinero. Tanto para la realización de verificaciones como de validaciones se pueden utilizar distintos tipos de técnicas. En general, estas técnicas se agrupan en dos categorías: • Técnicas de Evaluación Estáticas: Buscan faltas sobre el sistema en reposo. Esto es, estudian los distintos modelos que componen el sistema software buscando posibles faltas en los mismos. Así pues, estas técnicas se pueden aplicar, tanto a requisitos como a modelos de análisis, diseño y código.• Técnicas de Evaluación Dinámicas: Generan entradas al sistema con el objetivo de detectar fallos, cuando el sistema ejecuta dichas entradas. Los fallos se observan cuando se detectan incongruencias entre la salida esperada y la salida real. La aplicación de técnicas dinámicas es también conocida como pruebas de software o testing y se aplican generalmente sobre código puesto que es, hoy por hoy, el único producto ejecutable del desarrollo.

TÉCNICAS DE EV ESTÁTICA

Los defectos que se buscan al evaluar estáticamente los productos software son: Para los requisitos: o Corrección. Los requisitos especifican correctamente lo que el sistema debe hacer. o Compleción. Especificación completamente el problema. Está especificado todo lo que tiene que hacer el sistema y no incluye nada que el sistema no deba hacer. En dos palabras: no falta nada; no sobra nada o Consistencia. No hay requisitos contradictorios. o Ambigüedad. Los requisitos no pueden estar sujetos a interpretación. o Claridad. Se entiende claramente lo que está especificado.

Para el diseño:o Corrección:  El diseño no debe contener errores. o Compleción. El diseño debe estar completo. Ya sea que diseña todo el sistema marcado por los requisitos; ya sea no diseñando ninguna parte no indicada en los requisitos. De nuevo, nada falta, nada sobra.o Consistencia. Al igual que en los requisitos, el diseño debe ser consistente entre todas sus partes. No puede indicarse algo en una parte del diseño, y lo contrario en otra.o Factibilidad. El diseño debe ser realizable. Debe poderse implementar.o Trazabilidad. Se debe poder navegar desde un requisito hasta el fragmento de diseño donde éste se encuentra representado.

Código Fuente: o Corrección. El código no debe contener errores. Los errores de corrección se pueden referir a dos aspectos. Defectos de “escritura”, es decir, lo que habitualmente se conoce por “programa que no funciona”. Por ejemplo, bucles infinitos, variable definida de un tipo pero utilizada de otro, contador que se sale de las dimensiones de un array, etc. Defectos con respecto al diseño: el diseño no realiza lo que el diseño establece. La corrección se puedar de tres formas: Compleción. El código debe estar completo. Una vez más, nada falta ni nada sobra (con respecto, en este caso, al diseño) . Consistencia. Al igual que en los requisitos y diseño, el código debe ser consistente entre todas sus partes. Trazabilidad. Se debe poder navegar desde un requisito hasta el fragmento de código donde éste se ejecute, pasando por el fragmento de diseño.

TÉCNICAS DE EV DINÁMICA

8f7afad5-3e2f-4fe3-beea-f58232cc5823 (image/png)

Caption: : Como se ha indicado anteriormente, a la aplicación de técnicas de evaluación dinámicas se le denomina también prueba del software. Concretamente la Prueba de software se puede definir como una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas (configuración de la prueba), registrándose los resultados obtenidos.

PARA PROBAR UN SOFTWARE:

1. Diseño de las pruebas.2. Generación de los casos de prueba.3. Definición de los procedimientos de la prueba.4. Ejecución de la prueba5. Realización de un informe de la pruebaTÉCNICAS DE PRUEBA Técnicas de caja blanca o estructurales, que se basan en un minucioso examen de los detalles procedimentales del código a evaluar, por lo que es necesario conocer la lógica del programa. Técnicas de caja negra o funcionales, que realizan pruebas sobre la interfaz del programa a probar, entendiendo por interfaz las entradas y salidas de dicho programa. No es necesario conocer la lógica del programa, únicamente la funcionalidad que debe realizar. 

26a3a07f-bd3d-4808-aad4-ec39322905d9 (image/jpg)

Caption: :

PRUEBAS DE CAJA BLANCA 

O Estructurales: A este tipo de técnicas se le conoce también como Técnicas de Caja Transparente o de Cristal. Este método se centra en cómo diseñar los casos de prueba atendiendo al comportamiento interno y  estructura del programa. Se examina así la lógica interna del programa sin considerar los aspectos de rendimiento. Criterios:  Cobertura de Sentencias: Se escriben casos de prueba suficientes para que cada sentencia en el programa se ejecute, al menos, una vez. - Cobertura de Decisión: Se escriben casos de prueba suficientes para que cada decisión en el programa se ejecute una vez con resultado verdadero y otra con el falso.  Cobertura de Condiciones: Se escriben casos de prueba suficientes para que cada condición en una decisión tenga una vez resultado verdadero y otra falso.  Cobertura Decisión/Condición: Se escriben casos de prueba suficientes para que cada condición en una decisión tome todas las posibles salidas, al menos una vez, y cada decisión tome todas las posibles salidas, al menos una vez.  Cobertura de Condición Múltiple: Se escriben casos de prueba suficientes para que todas las combinaciones posibles de resultados de cada condición se invoquen al menos una vez.  Cobertura de Caminos: Se escriben casos de prueba suficientes para que se ejecuten todos los caminos de un programa. Entendiendo camino como una secuencia de sentencias encadenadas desde la entrada del programa hasta su salida. 

PRUEBAS DE CAJA NEGRA

También conocidas como Pruebas de Comportamiento, estas pruebas se basan en la especificación del programa o componente a ser probado para elaborar los casos de prueba. El componente se ve como una “Caja Negra” cuyo comportamiento sólo puede ser determinado estudiando sus entradas y las salidas obtenidas a partir de ellas.Criterios:− Particiones de Equivalencia. − Análisis de Valores Límite. − Métodos Basados en Grafos. − Pruebas de Comparación. − Análisis Causa-Efecto. 

 PARTICIONES DE EQUIVALENCIA Es un método de prueba de Caja Negra que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. La partición equivalente se dirige a una definición de casos de prueba que descubran clases de errores, reduciendo así el número total de casos de prueba que hay que desarrollar. ANÁLISIS DE VALORES LÍMITE  Las condicione límite son aquellas que se hayan en los márgenes de la clase de equivalencia, tanto de entrada como de salida. Por ello, se ha desarrollado el análisis de valores límite como técnica de prueba. Esta técnica nos lleva a elegir los casos de prueba que ejerciten los valores límite. Por lo tanto, el análisis de valores límite complementa la técnica de partición de equivalencia de manera que: - En lugar de seleccionar cualquier caso de prueba de las clases válidas e inválidas, se eligen los casos de prueba en los extremos.  - En lugar de centrase sólo en el dominio de entrada, los casos de prueba se diseñan también considerando el dominio de salida. 

ESTANDARES  Y MODELOS DE CALIDAD. Recuperado de: http://datateca.unad.edu.co/contenidos/301569/AVA_2014_II_-_301569/AVA_ESTANDARES_Y_MODELOS_DE_CALID... TÉCNICAS DE EVALUACIÓN DE SOFTWARE. Recuperado de: http://www.grise.upm.es/htdocs/sites/extras/12/pdf/Documentacion_Evaluacion_7.pdf

BIBLIOGRAFIA