NORMA ISO/IEC 14598 Y PRUEBAS DE SOFTWARE

Slide 1

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

Slide 4

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

Slide 5

• 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ón
• 4. 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

Slide 7

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

Slide 8

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

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

• 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 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 planeamiento
• El 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,

Slide 13

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

Slide 15

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

Slide 16

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

Slide 18

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

Slide 19

• 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

• 
• 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 prueba
• 5. Realización de un informe de la prueba
• TÉ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.

Slide 22

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.

Slide 25

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

BIBLIOGRAFIA

• 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