DIPLOMADO DE INGENIERÍA DE SOFTWAREMódulo 5 Aseguramiento de Calidad de Software

OBJETIVO

Al finalizar el módulo, los participantes: tendrán los conceptos básicos y prácticos  para tener una definición propia de: 'calidad de software', conocerán las técnicas y principios de verificación y validación, establecerán el proceso de aseguramiento de  la calidad y conocerán los procesos más importantes de certificación de software.

CONTENIDO TEMÁTICO Tema 1. Conceptos

fundamentales e calidad y terminología de los procesos de validación y verificación.

Tema 2. Principios y técnicas de pruebas.

Tema 3. Tipos de defectos y estrategias de pruebas.

Tema 4. La importancia de la verificación y validación en el aseguramiento de la calidad de software.

Tema 5 Aseguramiento del proceso contra aseguramiento del producto

Tema 6. Análisis y reporte de problemas.

Tema 7. Herramientas estadísticas para el control de calidad.

Tema 8. Estándares de calidad del proceso y del producto.

Tema 9. Procesos y entidades certificadoras de calidad de software.

Discusiones finales.

TEMA 1. CONCEPTOS FUNDAMENTALES Y TERMINOLOGÍA DE LOS PROCESOS DE VALIDACIÓN Y VERIFICACIÓN.

Los participantes conocerán las técnicas y principios de verificación y validación

CONCEPTOS FUNDAMENTALES

Aseguramiento de Calidad de Software (ACS) Patrón sistemático y

planificado de todas las acciones a seguir para proporcionar la confianza adecuada de que un producto de software o un elemento componente se realiza acorde a los requerimientos técnicos establecidos.

Calidad de Software

Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentos y con las características implícitas que se esperan de todo software desarrollado profesionalmente.

CALIDAD DE SOFTWARE

Enfatizar tres aspectos importantes:

1. Los requerimientos explícitos del software son los fundamentos a partir de los cuales se mide la calidad.

2. La falta de concordancia con los requerimientos explícitos es una falta de calidad.

3. Los estándares definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software.

Existe un conjunto de requerimientos implícitos que a menudo no se mencionan (ej., la necesidad de facilitar su mantenimiento).

Si el software no se ajusta a los requerimientos implícitos, la calidad del software queda incompleta.

CARACTERÍSTICAS DE CALIDAD

Calidad: Funcionalidad Mantenibilidad Eficiencia Portabilidad Confiabilidad Usabilidad Reusabilidad

VERIFICACIÓN Y VALIDACIÓN (V&V)

Conjunto de actividades que aseguran que el software implementa correctamente una función específica.

Pressman ¿Estamos construyendo el

producto correctamente?Bohem

Logra que el sistema refleje de forma adecuada los requerimientos especificados.

“you built it right”

Conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente.

Pressman ¿Estamos construyendo el

producto correcto?Bohem

Demuestra que el sistema, como está desarrollado, brindará los servicios tal y como han sido deseados.

“you built the right thing”

Verificación Validación

EJEMPLOS DE MÉTODOS PARA V&V

Inspecciones· Revisiones entre

paresPeer Auditorias Walkthroughs· Análisis Simulaciones· Testing· Demonstraciones

Discusiones con usuarios (revisiones formales)

Demostraciones de prototipos Presentaciones funcionales

(e.g., service delivery run-throughs, end-user interface demonstrations)·

Politeo de materiales de entrenamiento o capacitación

Pruebas de servicios Pruebas de componentes del

sistema realizadas por usuarios o principales involucrados

Verificación Validación

ACTIVIDADES DE V&V

Las actividades o dichos métodos: Se enfocan en asegurar que el sistema entrega

los servicios tal y como fue deseado en el ambiente de entrega esperado.

Normalmente se desarrollan de forma concurrente y probablemente utilicen porciones del mismo ambiente de pruebas.

Se pueden realizar repetidamente en multiples fases del desarrollo del sistema

EJEMPLOS DE COMPONENTES DEL SISTEMA QUE DEBEN SER VERIFICADOS Y VALIDADOS

Personas Procesos Equipos Software Consumibles

PRÁCTICAS DE VERIFICACIÓN

Preparar la verificación Dirigir o conducir la verificación Identificar las acciones correctivas Verificar incluye:

Probar el sistema Probar componentes seleccionados del sistema

ante todos los requerimientos elegidos; incluyendo acuerdos de servicio, requerimientos de servicio y requerimientos del sistema

PREPARACIÓN: ESTABLECER Y MANTENER ACERCAMIENTO Y AMBIENTE PARA V&V

Incluye: Selección Inspección Testing Análisis Demostración

De componentes del sistema: Productos de trabajo Procesos Recursos consumibles

Elegir servicios y componentes del sistema para: Ambiente de validación Procedimientos Criterios

Importante involucrar a: Usuarios finlaes Personal de primer contacto

con usuarios que entrega servicios.

Sus perspectivas en la entrega exitosa de los servicios varian significativamente de un rol a otro y entre los desarrolladores también.

Verificación Validación

PRODUCTOS DE TRABAJO TÍPICOS EN V&V

1. Lista de componentes del sistema seleccionados

2. Métodos para cada componente3. Ambiente4. Procedimientos5. Criterios

SUB – PRÁCTICAS PARA V&V

1. Seleccionar los componentes que serán V&V y los correspondientes métodos que se aplicarán a cada componente.

Los componentes del sistema se eligen con base en su contribución para lograr objetivos del proyecto, requerimientos y para identificar los riesgos del proyecto.

2. Establecer y mantener el ambiente para V&V

3. Establecer y mantener los procedimientos y el criterio para los componentes seleccionados.

TEMA 2. PRINCIPIOS Y TÉCNICAS DE PRUEBAS.

Identificarán las técnicas de pruebas efectiva y eficientemente calculando la cobertura de pruebas

OB

JETIV

OS

DE L

AS

PR

UEB

AS

Un programa de trabajo deja algo bonito difícil de encontrar.

Robert Dunn

Los errores en el software son más comunes, más generalizados y más molestos que en otras tecnologías.

David Parnas

1. La prueba es el proceso de ejecución de un programa con la intención de describir un error.

2. Un buen caso de pruebas es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.

3. Una prueba tiene éxito si descubre un error no detectado hasta entonces.

- Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo.

PRINCIPIOS DE LAS PRUEBAS

A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente.

Las pruebas deberían planificarse mucho antes de que empiecen.

El principio de Pareto es aplicable a la prueba del software.

Las pruebas deberían empezar por lo pequeño y progresar hacia lo grande.

No son posibles las pruebas exhaustivas. Para ser más eficaces, las pruebas deberían

ser realizadas por un equipo independiente.

FACILIDAD DE PRUEBA Operatividad

Cuanto mejor funcione, más eficientemente se puede probar.

Observabilidad Lo que ves es lo que

pruebas Controlabilidad

Cuanto mejor podamos controlar el sofware, más se puede automatizar y optimizar.

Capacidad de descomposición Controlando el ámbito de

las pruebas, podemos aislar más rápidamente los problemas y llevar a cabo mejores preubas de regresión

Simplicidad Cuanto menos haya que

probar, más rápidamente podremos probarlo

Estabilidad Cuanto menos cambios,

menos interrupciones a las pruebas.

Facilidad de comprensión Cuanta más información

tengamos, más inteligentes serán las pruebas.

DISEÑO DE CASOS DE PRUEBA

La operación interna se ajusta a las especificaciones.

Pruebas que se llevan a cabo sobre la interfaz del software.

Demostrar que las funciones del software son operativas: la entrada se acepta de forma adecuada y el resultado es correcto; la integridad de la información externa se mantiene.

Todos los componentes internos se comprueban de forma adecuada.

Se basa en el minucioso examen de los detalles procedimentales.

Se comprueban los caminos lógicos del sw: condiciones y/o bucles.

Son diseñadas después de que exista un diseño de componente (o código fuente). El detalle de la lógica del programa debe estar disponible.

Pruebas de caja negra Pruebas de caja blanca

BASIC NOTIONS Error

mistake made by human during implementation of a software system.

Failure incorrect behaviour of a program.

Fault incorrect code that caused a

failure. Incident

symptoms associated with a failure.

Bug an error or fault

Fault Directed testing finding bugs through failure

Test Case A test described by test data,

environment and expected result. Test Suite

a collection of test cases. Test Plan

document describing testing approach, test suites and test cases.

Test Strategy a way to identify test cases from

a specification or implementation. Test Effectiveness

relative ability of test strategy to find bugs.

Test Efficiency relative cost of finding a bug.

Test Coverage the percentage of testable

elements that have been tested.

TEMA 3. TIPOS DE DEFECTOS Y ESTRATEGIAS DE PRUEBAS.Determinaran las estrategias de prueba adecuadas

DEFEC

TO

S

Algunas enfermedades, como dicen los médicos, en su comienzo son difíciles de reconocer… pero con el paso del tiemp, cuando no se han reconocido y tratado al principio, se vuelven fáciles de reconocer pero difíciles de curar.

Niccolo Machiavelli

Defecto: Anomalía del producto

Fallo Un defecto en un dispositivo de

hardware o componente: por ejemplo, un corto circuito o un cable roto.

Un paso incorrecto, proceso o definición de datos en un programa de computadora.

Errores inadvertidos

Errores nuevamente generados

Errores amplificados 1: x

Porcentaje de

eficiencia de la

detección de errores

Pasos de desarrolloDefectos

DetecciónErrores de pasos anteriores

Errores pasados al siguiente paso

ERROR FALTA FALLA

Proceso de desarrollo de software

sw error sw fault sw failure

LAS NUEVE CAUSAS DE ERRORES DE SW

1. Definición de requerimientos incompleta2. Fallas de comunicación en: cliente –

desarrollador3. Desviación deliberada de los requerimientos

de software 4. Errores de diseño lógico5. Errores de código6. Incumplimiento entre documentación e

instrucciones de codificación7. Proceso de pruebas deficiente o limitado8. Errores de procedimiento9. Errores de documentación

ESTRATEGIAS DE PRUEBAS Proporcionan una plantilla

para la prueba. Características:

Inician a nivel módulo y trabajan hacia afuera, hacia la integración de todo el sistema basado en computadora.

Según el momento, son apropiadas diferentes técnicas de pruebas.

La realiza el responsable del desarrollo de sw, para grandes proyectos un grupo independiente de pruebas.

La prueba y depuración son diferentes, pero la 2da se debe incluir en la estrategia de prueba.

Debe incluir: Pruebas de bajo nivel que

verifiquen que todos los pequeños segmentos de código fuente se han implementado correctamente

Pruebas de alto nivel que validen las principales funciones del sistema frente a los requisitos del cliente.

Debe proporcionar: Guía al profesional y

conjunto de hitos para medir el progreso y mostrar problemas lo antes posible.

Pruebas: conjunto de actividades que se pueden planear y realizar sistemáticamente.

Plantilla para las pruebas: pasos, métodos específicos de diseño de casos de prueba

AS

PEC

TO

S E

STR

ATÉG

ICO

S

Los casos de uso describen un escenario para usar el software.

Especificar los requisitos del producto de manera cuantificable mucho antes de que comiencen las pruebas.

Establecer los objetivos de la prueba de manera explícita.

Comprender qué usuarios van a manejar el software y a desarrollar un perfil para cada categoría de usuario.

Desarrollar un plan de prueba que haga hincapié en la prueba de ciclo rápido.

Construir un software robusto diseñado para probarse a sí mismo.

Usar revisiones técnicas formales efectivas como filtro antes de la prueba.

Llevar a cabo revisiones técnicas formales para evaluar la estrategia de prueba y los propios casos de prueba.

Desarrollar un enfoque de mejora continua al proceso de prueba. Debería medirse la estrategia de prueba.

PRUEBAS DE UNIDAD.

Centra el proceso de verificación en la menor unidad de diseño del software: El componente de software o módulo.

Probar el flujo de datos de la interfaz del módulo.

Comprobar el impacto de los datos globales sobre el módulo.

Comprobar los caminos de ejecución.

Detectar errores debidos a:

cálculos incorrectos

comparaciones incorrectas

flujos de control inapropiados

PRUEBAS DE INTEGRACIÓN. Técnica sistemática para construir la

estructura del programa mientras que se llevan a cabo pruebas para detectar errores asociados con la interacción.

El objetivo es tomar los módulos probados mediante la prueba de unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño.

La prueba de integración deberá ser conducida incrementalmente.

El programa se construye y se prueba en pequeños segmentos en los que los errores son más fáciles de aislar y de corregir.

DESEMPEÑO. Peticiones :: utilizan recursos (hw y sw) Carga :: todos los usuarios de la aplicación en un determinado

momento sin importar su actividad. Número total de usuarios, no sólo los que están haciendo peticiones,

ya que todos los usuarios consumen recursos. Consumen memoria u otro tipo de mecanismo para almacenar el estado de

un cliente. Carga de picos :: número máximo de clientes dentro d un

período de tiempo. Al planear una prueba de desempeño, encontrar la carga pico y

porbar la aplicación contra esta carga es lo más importante. Rendimiento de procesamiento :: throughput, mide la cantidad

de peticiones servidas por unidad de tiempo. Esta métrica se caracteríza por tener un límite superior.

Ej. 5 cajeros y atención por cliente 1 min :: rendimiento 5 clientes por minuto.

Tiempo de respuesta :: tiempo desde que el usuario inicia un petición hasta que el resultado es visualizado. Relación entre: carga, rendimiento de procesamiento, y el mismo

tiempo de respuesta Punto de saturación :: el rendimiento permanece constante.

DESEMPEÑO.

Entender cuántos usuarios simultáneos soporta la aplicación y cuánto aumentan los tiempos de respuesta en los momentos de mayor tráfico son las principales motivaciones para realizar una prueba de desempeño.

Para mejorar el desempeño de una aplicación: optimizar o escalar

Optimización: modificar la aplicación para que consuma menos recursos o para minimizar los cuellos de botella.

Técnicas de escalamiento: añadir recursos. Ej. Aumentar número de servidores que hospedan la

aplicación. Escalamiento vertical más recursos al servidor (CPU o

memoria) Escalamiento horizontal más servidores para formar

cluster.

PER

FIL

ES

DE A

PLIC

AC

IÓN

:: PR

UEB

A D

EL S

ISTEM

A

Si has intentado encontrar verdaderamente fallos en el sistema y nunca has sometido tu software a una prueba real de resistencia, entonces has perdido mucho el tiempo.

Boris Beizer

¿Qué es lo que la aplicación necesita hacer bien?

Recuperación Fuerza el fallo del software de muchas formas

y verifica que la recuperación se lleva a cabo apropiadamente.

Automática.- evaluar inicialización; mecanismos de recuperación del estado del sistema; recuperación de datos y del proceso de rearranque.

Intervención humana.- evaluar los tiempos medios de reparación y sus límites aceptables.

Seguridad Verificar que los mecanismos de protección

incorporados en el sistema lo protegerán de accesos impropios.

Cifrado de datos, firewalls y bitácoras. Resistencia (Stress)

Diseñadas para enfrentar a los programas con situaciones anormales.

Ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o volúmenes anormales.

Rendimiento Tiempo de ejecución dentro del contexto de un

sistema integrado. Descubrir situaciones que lleven a

degradaciones y posibles fallos del sistema.

DESARROLLO DEL MANEJO DE PRUEBAS. La planeación de pruebas contempla realizar las pruebas de

funcionalidad y de integración primero, para asegurar que la apliación funciona correctamente.

Se desarrollan scripts de pruebas, considerando las siguientes recomendaciones: Desarrollar scripts pequeños Escribir scripts atómicos Permitir datos dinámicos

En general, la prueba de desempeño es un proceso iterativo: se prueba, se recolectan datos, se verifican, analizan y se optimiza; hasta alcanzar los objetivos de los escenarios de prueba.

Las pruebas de desempeño se deben conducir en los siguientes puntos del ciclo de desarrollo: Pruebas unitarias: por cada desarrollador antes de liberar sus

componentes, analizados por memoria y código. Pruebas de integración de la aplicación: carga con usuarios

proyectados. Pruebas de producción: ambiente lo más similar a la aplicación en

producción.

PR

UEB

AS

DE C

ON

FIG

UR

AC

IÓN

.

El arte del progreso está en mantener el orden el medio del cambio y mantener el cambio en medio del orden.

Alfred North Whitehead

Revisión de la configuración Asegurarse que todos los elementos

de la configuración del software: se han desarrollado apropiadamente,

se han catalogado y

están suficientemente detallados para soportar la fase de mantenimiento durante el ciclo de vida del software.

Auditoría

Las relaciones establecidas entre los objetos de configuración permiten al ingeniero de software evaluar el impacto del cambio

Identificación, control de versiones y control de cambios.

Se apoya de los informes de estado: Qué paso; quién lo hizo; cuándo paso;

qué más se vio afectado.

PRUEBAS DE COMPATIBILIDAD. Distribución de software Pruebas en la aplicación, que certifiquen su

correcto funcionamiento bajo las distintas configuraciones posibles; diferentes al ambiente de desarrollo.

Cientos de diferentes configuraciones tanto de software (Windows/Mac/Linux/Solaris, IE/Safari/Firefox), como de hardware (Intel,AMD,G5,Sparc) donde probar la aplicación facilte encontrar problemas antes que los clientes y usuarios finales lo hagan. Aplicación en sistemas de alta fiabilidad Desarrollos paralelos Desarrollo del software, las versiones de la aplicación

de ejecutan en equipos independientes, usando las mismas especificaciones

Se deben probar todas las versiones con los mismos datos, para asegurar que proporcionan una salida idéntica

PRUEBAS ALFA, BETA Y DE ACEPTACIÓN

Prueba de aceptación.- desarrollo de un software a la medida para un cliente; permitir que el cliente valide todos los requisitos. Las realiza el usuario final en lugar del

responsable del desarrollo del sistema. Puede ir desde un informal paso de prueba hasta

la ejecución sistemática de una serie de pruebas bien planificadas.

Puede tener lugar a lo largo de semanas o meses, descubriendo así errores acumulados que puedn ir degradando el sistema.

INTEGRACIÓN CONTINUA Y ECOSISTEMAS DE SOFTWARE

CONTINUOUS INTEGRATION

Martin Fowler GoF Patrones de Diseño Influencia en la industria. IoC ID

Integración Continua y Ecosistemas de Software

• CONTINUOUS INTEGRATION

Incluye: Control de versiones Automatización de Build’s Automatización de Pruebas unitarias Automatización de Pruebas de aceptación Automatización de Métricas

Integración Continua y Ecosistemas de Software

• ECOSISTEMAS DE SOFTWARE

Un ecosistema software es un espacio de trabajo en el que conviven una serie de herramientas que acompañadas de unas buenas prácticas permiten a un equipo de desarrollo modelar una metodología de trabajo.

LAS PRUEBAS EN EL DESARROLLO DE SOFTWARE

• Desarrollo guiado por pruebas (TDD).

Es una metodología de programación que involucra otras dos prácticas: escribir las pruebas primero (Test First Development) y refactorización (Refactoring).

TEMA 4. LA IMPORTANCIA DE LA VERIFICACIÓN Y VALIDACIÓN EN EL ASEGURAMIENTO DE CALIDAD DE SOFTWARE.Conocerán la importancia de las técnicas y principios de verificación y validación

TERMINOLOGÍA DE PRUEBAS DE SOFTWARE

Pruebas: identificación de discrepancias entre el software ejecutable y sus especificaciones.

Verificación: asegurarse que los productos de una fase en particular cumplan sus objetivos establecidos en una fase previa.

Validación: asegurarse que el sistema final cumpla con los requerimientos y necesidades.

Debugging: diagnosticar la naturaleza precisa de un error conocido y entonces corregirlo.

PLANEACIÓN Y EJECUCIÓN DE PRUEBAS :: V&V

Pruebas Unitarias

Pruebas de Aceptación

Pruebas de Integración

Pruebas de Sistema

Validación

Requerimiento de Calidad

Concepto

EspecificaciónRequerimientos

EspecificaciónFuncional

DiseñoTécnico

DiseñoDetallado

Construcción

Verificación de Calidad

TRES ELEMENTOS QUE SON ESENCIALES PARA LA PRUEBA DE SOFTWARE

Plan de pruebas Política de pruebas general Metodología de pruebas a ser usada Recursos requeridos

Descripción de pruebas Procedimientos de pruebas individuales Casos de pruebas individuales

Reportes de pruebas Documentación de la ejecución de pruebas y

resultados

PROBLEMAS POTENCIALES DURANTE LAS PRUEBAS DE SOFTWARE Diferentes objetivos entre desarrolladores y

probadores Los desarrolladores invariablemente cuestionaran

las competencias de los probadores y viceversa Los usuarios pueden cuestionar la competencia de

todos si ellos ven demasiados errores Los usuarios identifican nuevos requerimientos que

deben ser incorporados en el software La presión para cumplir el calendario es fuerte En un ambiente de contrato, la organización que

desarrolla busca por maneras de culpar al cliente por desviaciones

El desgaste es común, la gente sólo quiere terminar y salir de ahí

GUÍAS PARA LAS PRUEBAS DE SOFTWARE

Limitar qué puede y qué debe ser probado Monitorear la profundidad de las pruebas al

costo de un error no descubierto Remover los defectos antes de pruebas Evitar las pruebas excesivas Cumplir las necesidades de

Requerimientos bien escritos Buenos procedimientos de pruebas Probadores eficientes

Preparar documentación adecuada

ASEGURAMIENTO DE CALIDAD DE SOFTWARE Patrón, planeado y sistemático, de todas las actividades

necesarias para proveer la confidencialidad adecuada que un artefacto o producto está conforme a lo establecido por los requerimientos técnicos.

Conjunto de actividades diseñadas para evaluar el proceso por el cual los productos son desarrollados y manufacturados.

Conjunto de actividades, sistemáticas y planeadas para brindar confiabilidad en el proceso de desarrollo de software o en el proceso de mantenimiento de un

sistema para la establecer la funcionalidad acorde a los requerimientos.

El aseguramiento de calidad del software es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto (software) requiere para satisfacer los requerimientos dados de calidad por parte del cliente.

TEMA 5. ASEGURAMIENTO DEL PROCESO CONTRA ASEGURAMIENTO DEL PRODUCTO.Reconocerán una definición propia de calidad de software

Evaluarán la densidad de los defectos

ING

EN

IER

ÍA D

E S

ISTEM

AS

Y P

RO

CES

OS

La ingeniería de procesos de negocio comprende una planificación de la estrategía de la información, un análisis del área de negocio y un análisis específico de aplicación.

Éstos forman parte de la ingeniería del software.

Sistema de alta tecnología Componentes: hardware, software,

personas, bases de datos, documentación y procedimientos.

Ingeniería de sistemas Traducir las necesidades del cliente

en un modelo de sistema con uno o más componentes.

Visión global :: dominio de negocio o producto para establecer los requisitos básicos.

Visión de dominio :: cada elemento se analiza individualmente y se asigna a uno o más componentes.

Ingeniería de procesos de negocio Arquitecturas para facilitar el uso de la

información eficazmente en un negocio. Arquitecturas minuciosas de datos, de

aplicación e infraestructura tecnológica que satisfaga las necesidades de la estrategía de negocio y los objetivos de cada área de negocio.

ING

EN

IER

ÍA D

E P

RO

DU

CTO

Especificación del sistema

Documento que sirve de base para las tareas de ingeniería que se realizarán posteriormente.

La ingeniería de software pretende proporcionar un marco de trabajo para construir software con mayor calidad.

La ingeniería de productos es un enfoque de la ingeniería de sistemas que inicia con el análisis del sistema. Identificar las necesidades del

cliente Determinar la viabilidad económica

y técnica Asignar funciones y rendimientos al

software, hardware, personas y bases de datos (componentes de ingeniería)

Ingeniería de requisitos Intensa comunicación entre el

cliente y el ingeniero de sistemas Identificación, análisis y negociación,

especificación, modelización, validación y gestión.

ADMINISTRACIÓN DE LOS COMPONENTES DE LA CALIDAD DE SOFTWARE Control del progreso del proyecto

Control de las actividades de las administración de riesgos

Control de la agenda, de los recursos y del presupuesto del proyecto

Métricas de la calidad del software Métricas del proceso Métricas del producto

Costos de las calidad del software Controlar los costos asociados con la prevención de

errores (antes de que ocurran) y la detección de errores (una vez que se presentaron)

Evaluar los daños económicos de fallas en el software para actualizar el presutpuesto del aseguramiento de calidad de software.

MÉTRICAS EN LA CALIDAD DE SOFTWARE

Objetivos

Clasificación

Métricas del proceso

Métricas del producto

Implementación y limitantes de las métricas de software

OBJETIVOS Y REQUERIMIENTOS DE MÉTRICAS DE CALIDAD EXITOSAS Objetivos de las métricas de calidad

Brindar soporte al control del desarrollo del proyecto y al mantenimiento del software.

Cumplir en las funcionalidades requeridas y dentro del tiempo y presupuesto contempaldo para el proyecto.

Entregar métricas acumuladas y analizadas para establecer acciones preventivas y correctivas a través de la organización.

Requerimientos para métricas de calidad exitosas Requerimientos generales

Relevante; válidas; confiables; comprensibles; excluyentes Requerimientos operativos

Fácil y sencillo para obtener los datos; datos propios de la operación; libre de intereses particulares de algún miembro del equipo.

MÉTRICAS EN LA CALIDAD DE SOFTWARE

Métricas del proceso Calidad

Bitácoras

Productividad

Métricas del producto Métricas de productividad y efectividad de los

servicios en producción

Metricas de mantenimientos correctivos

Métricas de productividad y efectividad en mantenimiento correctivo del software

MÉTRICAS DEL PROCESO Métricas del proceso

Calidad

1. Métricas de densidad de errores

2. Métricas de severidad de errores

3. Métricas de efectividad para remover los errores

Bitácoras Lograr hitos en los tiempos establecidos en la calendarización

del proyecto.

Productividad Métricas directas, relacionadas con la productividad del

capital humano.

Métricas indirectas, se enfocan en el reuso del software

Productividad (desarrollo; puntos de función)

Efectividad (reuso de código o documentación)

FAC

TO

RES

DE C

ALID

AD

DE M

CC

ALL

Es interesante anotar que los factores de calidad de McCall son válidos hoy como cuando fueron los primeros propuestos en los años 70. Además, es razonable indicar que los factores que afectan a la calidad del software no cambian.

Todo programa hace algo correctamente, que puede no ser lo que necesitamos que haga.

Anónimo

Facilidad de mantenimientoFlexibilidadFacilidad de prueba

PortabilidadReusabilidadIneroperatividad

Corrección Fiabilidad Usabilidad Integridad Eficiencia

FACTORES DE CALIDAD DE MCCALLAspectos de un producto de software

Factor Breve descripción

Características operativas

Corrección Hasta dónde satisface un programa su especificación y logra los objetivos propuestos por el cliente.

Fiabilidad Hasta dónde se puede esperar que un programa lleve a cabo su función con la exactitud requerida.

Eficiencia La cantidad de recursos informáticos y de ódigo necesarios para que un programa realice su función.

Integridad Hasta dónde se puede controla el acceso al softwae o a los datos por personas no autorizadas.

Usabilidad(facilidad de manejo)

El esfuerzo necesaro para aprender a operar con el sistema, preparar los datos de entrada e interpretar las salidas.

Capacidad de cambios o revisión del producto

Facilidad de mantenimiento

El esfuerzo necesario para localizar y arreglar un error en un programa.

Flexibilidad El esfuerzo necesario para modificar un progrmaa que ya está en funcionamiento.

Facilidad de prueba El esfuerzo necesario para probar un programa y asegurarse de que realiza correctamente su función.

Adaptabilidad a nuevos entornos o transición del producto

Portabilidad El esfuerzo necesario para transferir el programa de un entorno hw/sw a otro entorno diferente.

Reusabilidad Hasta dónde se puede volver a emplear un progrmaa (o partes) en otras aplicaciones.

Interoperatividad El esfuerzo necesario para acoplar un sistema con otro.

CÓ

MO

CA

RA

CTER

IZA

R E

L P

RO

CES

O D

E

SO

FTW

AR

E

Seleccione un marco de trabajo del proceso común que se adecue al producto, al personal y al proyecto.

TEMA 6. ANÁLISIS Y REPORTE DE PROBLEMAS.Evaluarán la densidad de los defectos

CORRECCIÓN DE DEFECTOS, ACCIONES PREVENTIVAS Y CORRECTIVAS

Correción de defectos

Es la solución inmediata de defectos detectados en un proyecto o sistema de software.

Acciones preventivas o correctivas

Tienen un alcance mayor; pretenden inicializar y guiar el desempeño de acciones en la organización que eliminen las causas de faltas conocidas o potenciales.

TIPOS DE RECURSOS INTERNOS SUJETOS A CORRECCIONES O ACCIONES PREVENTIVAS Y CORRECTIVAS

Proceso de desarrollo de software

Mantenimiento de software

Procedimientos en infraestructura de SQA

Procedimientos de administración de la calidad de software

Actualizar procedimientos relevantes

Cambiar las prácticas en el desarrollo y mantenimiento del software y actualizar las instrucciones de trabajo.

Cambiar o modernizar herramientas de trabajo

Mejorar métodos para reportar contenidos y frecuencias (detección temprana de faltas y reducir los daños).

Iniciar entrenamientos, repetirlos o actualizar al staff.

PLANTILLAS EN EL ASEGURAMIENTO DE CALIDAD DE SOFTWARE

Los documentos realizados para las revisiones son más completos. Como resultado, el equipo se puede concentrar

más en mejorar para el producto final. Las revisiones a los documentos se facilitan,

pues la estructura es estándard y bien conocida por los revisores. Los revisores se concentran en el contenido.

Los formatos principales son: El plan de pruebas La descripción de las pruebas Reportes de pruebas

LISTAS DE VERIFICACIÓN EN EL ASEGURAMIENTO DE CALIDAD

Brindan soporte para asegurar que los documentos están realizados de forma completa y para mejorar la calidad del documento, en la medida que los elementos relevantes que deben ser revisados están listados.

Conducen las sesiones de revisión y es menos problemático cuando los tópicos y sus prioridadees ya están definidas y son bien conocidas por los participantes. Una revisión eficiente se trabaja sobre los

comentarios de análisis de los revisores.

ELEMENTOS PARA MÉTRICAS DE PRUEBAS

Los responsables de las pruebas deben fiarse de las métricas de análisis, diseño y código para que les guíen en el diseñó y ejecución de los casos de prueba.

Las métricas de la prueba desembocan en las siguientes categorías:1. Métricas que ayudan a determinar el número

de pruebas requeridas en los distintos niveles de la preuba;

2. Métricas para cubrir la prueba de un componente dado.

TEMA 7. HERRAMIENTAS ESTADÍSTICAS PARA EL CONTROL DE CALIDAD.Evaluarán la densidad de los defectos

HERRAMIENTAS ESTÁDISTICAS BÁSICAS PARA LA CALIDAD

Kauru Ishikawa promulgó la utilización de siete herramientas básicas de la calidad: Gráficas de barras e histogramas Listas de verificación Diagramas de Pareto Diagramas de dispersión Diagramas causa-efecto Estratificación Gráficos de control

HERRAMIENTAS ESTÁDISTICAS BÁSICAS PARA LA CALIDAD

Kauru Ishikawa promulgó la utilización de siete herramientas básicas de la calidad: Diagramas de Pareto

Regla 80/20. Si se tiene un problema con muchas causas, podemos

decir que el 20% de las causas resuelven el 80 % del problema y el 80 % de las causas solo resuelven el 20 % del problema.

Diagramas causa-efecto o diagramas de espina de pescado o diagramas de Ishikawa Muestran la relación entre un problema de calidad de

importancia clave y las posibles causas que lo originan. Primero se determinan las categorías de causas y luego causas específicas en los niveles en que sea necesario.

TEMA 8. ESTÁNDARES DE CALIDAD DEL PROCESO Y DEL PRODUCTO.Establecerán el proceso de aseguramiento de calidad

BENEFICIOS DE USAR ESTÁNDARES EN EL ASEGURAMIENTO DE CALIDAD DE SOFTWARE

Habilidades para utilizar las metodologías y procedimientos profesionales más sofisticados y comprensibles.

Mejor entendimiento, colaboración y cooperación entre usuarios de los mismos estándares: Entre miembros del equipo y entre equipos del

proyecto. Entre desarrolladores del software y

participantes extenos en el proyecto. Entre proveedores y clientes.

CONTRIBUCIONES REALIZADAS POR EL USO DE ESTÁNDARES

Brindar metodologías profesionales para su uso en el proceso de desarrollo y su administración.

Certificación en servicios de aseguramiento de calidad basados en auditorias de calidad por parte de profesionales independientes.

Herramientas para reconocer las capacidades propias de logros en la planeación y organización de un sistema de aseguramiento de calidad.

COMPARATIVO :: CLASES DE ESTÁNDARES EN SQA

Características

Estándares de administración de calidad

Estándare para los procesos del proyecto

La unidad meta Administración del desarrollo y mantenimiento del software y las unidades específicas de SQA

Equipo de proyecto para desarrollo y mantenimiento de software

Enfoque principal

Organización de los sistemas de SQA, infraestructura y requerimientos

Metodolgías para realizar proyectos de desarrollo y mantenimiento de software

Objetivos del estándar

Qué a lograr Cómo a desempeñar

Metas del estándar

Asegurar la calidad del software de proveedores e inventariar las capacidades de sus procesos de software

Asegurar la calidad de un proeycto de software específico

Ejemplos ISO 9000-3; CMMI; ISO/IEC 12207; IEEE Std 1012-1998

EJEMPLOS DE ESTÁNDARES EN USO

ISO 9000-3 IEEE Std 730-1998

Planes para aseguramiento de caldiad de software

IEEE/IEA 12207 IEEE Std 1012-1998

Verificación y validación de software

IEEE Std 1045-1992 Métricas de

productividad de software

Administración de la calidad de software

Ciclo de vida del desarrollo de software

TENDENCIAS EN EL DESARROLLO DE ESTÁNDARES Joint ventures

IEEE/ANSI

ISO/IEC

IEEE/ISO

Adopción de estándares internacionales , como estándares nacionales, por institutos nacionales de estándares

Aplicación de estándares en la industria de software con cobertura mundial:

ISO/IEC 9000-3 :: Estándares de certificación de calidad para organizaciones de desarrollo y mantenimiento de software.

ISO/IEC 15504 :: Inventario de capacidades en procesos de software

ISO/IEC/IEEE 12207 :: Prácticas en el desarrollo de software

ESTÁNDAR DE CALIDAD ISO 9001 Está expresado en términos generales, y puede ser

interpretado por los desarrolladores de diversos productos.

Para la industria del software los estándares relevantes son: ISO 9001. Quality Systems – Model for Quality

Assurance in Design, Development, Production, Installation and Servicing.

Describe el sistema de calidad utilizado para mantener el desarrollo de un producto que implique diseño.

ISO 9003. Guidelines for Application of ISO 9001 to the Developments, Supply and Maintainance of Software.

Documento específico para el desarrollador de software. ISO 9004. Quality Management and Quality System

Elements – Part 2 -. Directrices para los servicios en software, como soporte de

usuarios.

TEMA 9. PROCESOS Y ENTIDADES CERTIFICADORAS DE CALIDAD DE SOFTWARE.Conocerán los procesos más importantes de certificación de software

CMMI Define practicas y bjetivos que han

demostradro ser útiles en la industria Dirigido primordialmente a organizaciones grandes Se enfoca en procesos:

explícitos, documentados, reproducibles, medibles y auto-mejorables

Esencial para la industria del outsourcing Tecnológicamente neutral

ÁREAS DE PROCESO DE CMMI Cada nivel de madurez requiere que

se cumpla con ciertas áreas de proceso (Key process areas)

Una área de proceso es unconjunto de

prácticas relacionadas que son ejecutadas de forma conjunta

para conseguir un conjunto de objetivos Una área de proceso propone qué hacer mas NO cómo

hacerlo Cada área requiere

Cumplir con los 5 niveles posibles de capacidad (Objetivos Generales) Cumplir con los requerimientos específicos (Objetivos Específicos)

OBJETIVOS PARTICULARES DE CADA ÁREA Cada área señala una serie de

objetivos a cumplir u objetivos particulares

Éstos puntualizan las particularidades que

describen lo que se debe implementar

para satisfacer el propósito del área

CMMI® FOR SERVICES, VERSION 1.2CMMI-SVC, V1.2

The Three Critical Dimensions

CMMI® FOR SERVICES, VERSION 1.2CMMI-SVC, V1.2

CMMI® FOR SERVICES, VERSION 1.2CMMI-SVC, V1.2

CMMI Model Components

CMMI® FOR SERVICES, VERSION 1.2CMMI-SVC, V1.2

Comparison of Capability and Maturity Levels

MARCOS DE REFERENCIA PARA TI

CMMI – SCAMPI MoProSoft –

EvalProSoft eSCM-CL / eSCM-SP ITIL PSP TSP COBIT SPICE Etc.

EL CASO DEL JAVA COMMUNITY PROCESS

Mecanismo regulador de la plataforma java Integrado por industrias e individuos Alta vinculaciòn con el ambito empresarial Basado en especificaciones

JSR. Java Specification Request

Ejemplo institucional de un marco ad hoc para el aseguramiento de la calidad de cada especificación.

DISCUSIONES FINALES