ISIII_CAP6.2 de Aseguramiento de La Calidad de Software

Ingenieria de Software III Facultad Politecnica

CAPITULO 6

Métricas y Estándares de Calidad


Métricas del producto para el SW

Introducción

La medición es un elemento clave en

cualquier proceso de ingeniería

Las medidas se emplean para:

comprender mejor los atributos de los modelos

que se crean, y

evaluar la calidad de los productos de la

ingeniería o de los sistemas que se construyen


Calidad General

Calidad del software es el cumplimiento de:

los requisitos de funcionalidad y desempeño

explícitamente establecidos,

de los estándares de desarrollo explícitamente

documentados, y

de las características implícitas que se esperan

de todo software desarrollado profesionalmente


Calidad General (Cont.)

3 Puntos Importantes: Los requisitos del SW son la base de las medidas de

calidad.

La falta de concordancia con estos requisitos es una falta de calidad

Los estándares especificados definen un conjunto de criterios de desarrollo que guían la ingeniería del sw

Si no se siguen los criterios, el resultado será, casi seguramente, la falta de calidad

A menudo se pasa por alto un conjunto de requisitos implícitos (por ejemplo, el deseo de alcanzar la facilidad de uso)

Si el sw cumple con los requisitos explícitos pero no con los implícitos, la calidad del sw estará en duda


Factores de Calidad de McCall

McCall, Richards y Walters [MCC77]

propusieron una clasificación útil de los

factores que afectan la calidad del SW.

Estos factores se concentran en tres

aspectos:

sus características operativas,

su capacidad para experimentar cambios,

su capacidad para adaptarse a nuevos entornos.



Revisión del producto Transición del producto

Operación del producto

Facilidad de mantenimiento

(¿Puedo arreglarlo?)

Flexibilidad

(¿Puedo modificarlo?)

Facilidad de prueba

(¿Puedo probarlo?)

Portabilidad

(¿Podré utilizarlo en otra maquina?)

Facilidad de reutilización

(¿Podré reutilizar parte del SW?)

Interoperabilidad

(¿Podré comunicarlo con otros Sist.?)

Corrección Facilidad de uso Eficiencia

confiabilidad Integridad



Corrección: (¿Hace lo que se le pide?) El grado

en que el programa cumple con su especificación

y satisface los objetivos que propuso el cliente

Confiabilidad: (¿Lo hace de forma fiable todo el

tiempo?) El grado en que se esperaría que un

programa desempeñe su función con la precisión

requerida

Eficiencia: (¿Qué recursos hardware y software

necesito?) La cantidad de código y de recursos de

cómputo necesarios para que un programa realice

su función



(Cont.)

Integridad: (¿Puedo controlar su uso?) El grado con

que puede controlarse el acceso al software o a los

datos a personal no autorizado

Facilidad de uso: (¿Es fácil y cómodo de manejar?)

El esfuerzo necesario para aprender, operar y

preparar los datos de entrada de un programa e

interpretar la salida

Facilidad de mantenimiento: El esfuerzo necesario

para localizar y corregir un error en un programa

Flexibilidad: El esfuerzo necesario para modificar un

programa en operación



(Cont.)

Facilidad de prueba: El esfuerzo que demanda

probar un programa con el fin de asegurar que

realiza su función

Portabilidad: El esfuerzo necesario para transferir

el programa de un entorno de hardware o software

a otro

Facilidad de reutilización: El grado en que un

programa (o partes de él) puede reutilizarse entre

otras aplicaciones

Interoperabilidad: El esfuerzo necesario para

acoplar un sistema con otro


Factores de Calidad del Estándar

ISO 9126

Se desarrolló como un intento por identificar los atributos de calidad para el software

Identifica seis atributos claves de calidad:

Funcionalidad: El grado en que el sw satisface las necesidades que indican los siguientes subatributos: idoneidad, exactitud, interoperabilidad, cumplimiento y seguridad

Confiabilidad: La cantidad de tiempo en que el sw está disponible para usarlo según los siguientes subatributos: madurez, tolerancia a fallas y facilidad de recuperación



ISO 9126 (Cont.)

Facilidad de uso: La facilidad con que se usa el

sw de acuerdo con los siguientes subatributos:

facilidad de comprensión, facilidad de aprendizaje

y operabilidad

Eficiencia: El grado en que el sw emplea en

forma óptima los recursos del sistema, como lo

indican los siguientes subatributos:

comportamiento en el tiempo, comportamiento de

los recursos



ISO 9126 (Cont.)

Facilidad de mantenimiento: La facilidad con

que se repara el sw de acuerdo con los siguientes

subatributos: facilidad de análisis, facilidad de

cambio, estabilidad y facilidad de prueba

Portabilidad: La facilidad con que se lleva el sw

de un entorno a otro según los siguientes

subatributos: adaptabilidad, facilidad para

instalarse, cumplimiento, facilidad para

reemplazarse


Gestión de la Calidad

El aseguramiento de la calidad de

software (Software Quality Assurance

SQA) y la Verificación & Validación

(V&V) son los principales procesos de

esta área de conocimiento


SQA: Aseguramiento de Calidad

del software

Componentes:

monitorear el cumplimiento de las actividades

definidas en el plan de SQA asociado a cada

proyecto de desarrollo,

garantizar la calidad de los productos de trabajo

y monitorear los procesos utilizados para producir

software.


SQA

Verificación: ¿Estamos construyendo el

producto correctamente?

Validación: ¿estamos construyendo el

producto correcto?


El Grupo SQA

Sirve como el representante del cliente mira el producto desde el punto de vista del

cliente.

Asiste al grupo de desarrollo para lograr un producto final de buena calidad.

Trata de responder preguntas del tipo: ¿se satisfacen los criterios de calidad

especificados?

¿se ha desarrollado en base a los estándares establecidos?


Plan de SQA

Preparar el plan de SQA: evaluaciones, auditorías, estándares,

procedimientos de reporte de errores, documentos, etc.

El plan se prepara durante la etapa de planeación del proyecto.

El plan es revisado por todas las partes interesadas.

El plan es la base de todas las actividades de SQA.


Detalle de las actividades de

SQA

Plan de SQA : mapa para institucionalizar la garantía de calidad del software. Es una plantilla para definir las actividades de SQA aplicables a cada proyecto de software.

El plan incluye:

Sección Gestión: Tareas y actividades de SQA dentro del proceso de software y los roles y responsabilidades relativas a la calidad del producto.

Sección Documentación: Detalle de los productos de trabajo del proceso de software que podrán ser revisados.

Sección Estándares, Prácticas y Convenciones: Detalle de lo que está acordado y establecido para el proceso y los productos a obtener. (Ejemplos: estándares de documentación, estándares de codificación, pasos para la revisión, métricas a obtener, etc.)


Detalle de las actividades de

SQA

Sección Revisiones y Auditorias: Revisiones que se

llevarán a cabo durante el proceso y los responsables

de cada una de ellas. (Ejemplos: Revisiones de

documentación, revisiones técnico formales

(RTF’s),etc.)

Sección de Pruebas: Plan y procedimiento de

Pruebas del Software y de gestionar los defectos

detectados.

Sección Métodos y Herramientas que soportan las

actividades de SQA


Revisiones Técnicas Formales

Las revisiones técnicas constituyen una de

las actividades más importantes de SQA.

Propósito:

descubrir errores (función, lógica o

implementación);

verificar que el software satisface los requisitos;

asegurar que se cumplen los estándares

predefinidos;

hacer más manejable los proyectos.


Análisis costo/beneficio de

SQA

Costos de SQA: prevención y evaluación.

Beneficios de SQA: asociados a la

disminución de rework (menos defectos y

mayor confiabilidad).


Ejemplos de Categorías de

Errores

IES Especificación errónea o incompleta

MCC Mala interpretación de comunicación con el cliente

IDS Desviación intencional de la especificación

VPS Violación del estándar de programación

EDR Error de representación de los datos

IMI Interfaz de módulo inconsistente

EDL Error en el diseño lógico

IET Testeo erróneo o incompleto

IID Documentación errónea o incompleta

PLT Error en lenguaje

HCI Interfaz ambigua o incompleta


Checklist

El checklist debe completarse al finalizar cada etapa del ciclo de vida del software:

Nota:

(1) Sí La actividad o tarea fue realizada en su totalidad.

(2) No La actividad o tarea no fue completada.

(3) N/A La actividad no se aplica al desarrollo del proyecto de software.

La información contenida en el checklist debe servir como base para informar sobre el estado de avance de las actividades de SQA en el proyecto.


Checklist: Especificación de Requerimientos

1.- Identificación del proyecto y producto

Proyecto:

Producto:

2.- Inspector

Nombre: • Rol

• Moderador Secretario

• Observador InspectorE-mail: Fono:

3.- Checklist

SI NO N/A

• Adherencia

¿ El documento se adhiere a los estándares establecidos?

• Claridad

¿ En el modelo conceptual no existen características o conceptos irrelevantes?

¿Se muestra el ciclo de vida de un objeto a través del diagrama de secuencia?

¿ La especificación es clara y fácil de comprender?

¿ Se refleja el comportamiento del sistema en la especificación?




Proyecto:

Producto:

2.- Inspector

Nombre: • Rol



3.- Checklist

SI NO N/A

• Completitud

¿ Están especificados todos los requerimientos y restricciones?

¿ Están priorizados los requerimientos y restricciones?

¿ Están definidos correc-tamente los criterios de prioridad?

¿ Están todos los conceptos necesarios para que el sistema opere correctamente?

¿ Los requerimientos ayudan a cumplir con el propósito del sistema?

¿ Se especifican todas las funciones que se necesitan para cumplir con los objetivos del

sistema?

¿ Las instancias creadas en los contratos (poscondiciones) provienen del modelo conceptual y

están expresadas en tiempo pasado?

¿ Existe un contrato por cada operación del sistema que aparece en el diagrama de secuencia?

¿ Están especificados los requerimientos de interfaz?




Proyecto:

Producto:

2.- Inspector

Nombre: • Rol



3.- Checklist

SI NO N/A

• Factibilidad

¿ Es posible llevar a cabo los requerimientos con las herramientas, técnicas, recursos humanos

y no humanos y calendarización previamente fijada?

• Correctitud

¿ El diagrama de secuencia muestra todo el comportamiento del sistema con los actores

externos y con otros sistemas?

¿ Los requerimientos reflejan las necesidades del cliente?


• Checklist: Diseño interfaz hombre-máquina


Proyecto:

Producto:

2.- Inspector

Nombre: • Rol

Moderador Secretario

Observador InspectorE-mail: Fono:

3.- Checklist

SI NO N/A

• Adherencia

¿ Se utilizaron las metodologías y técnicas acordadas para desarrollar el diseño?

• Claridad

¿ El diseño representa las interfaces?

¿ Está totalmente documentado el diseño?

• Completitud

¿ El diseño cumple con todos los requerimientos relacionados a la interfaz?

¿ Se utilizan mensajes de error?

¿ Se modelaron todas las interfaces?

¿ Existe un modelo de la interfaz considerado para el usuario final: 1) descripción de los conocimientos técnicos

del usuario, 2) información sobre tutoriales y manuales de usuario, 3) tareas que el usuario debe

desempeñar?

• Consistencia


Grupo SQA

Muchas organizaciones empiezan a crear grupos de SQA.

Estas personas actúan como representantes interno del cliente.

Es responsabilidad del grupo SQA ayudar a los Ing., a lograr una alta calidad en el programa o aplicación de software determinado.

Este grupo tiene una serie de actividades que se presentan a continuación.


Actividades

SQA

Preparación de

Plan SQA

Desarrollo de la

descripción del

proceso de

software

Revisión de

software

Actividades de

verificación DocumentaciónReporte de no

conformidad

Grupo SQA


Estándares de calidad

IEEE 730 Software Quality Assurance Plans

IEEE 730.1 Guide for Software Assurance Planning

IEEE 982.1 Standard Dictionary of Measures to Produce Reliable Software

IEEE 1061 Standard for a Software Quality Metrics Methodology

ISO/IEC 12119 Information Technology-Software Packages-Quality Requirements and Testing

ISO/IEC 14598-1 Information Technology-Evaluation of Software Products-General Guide

ISO/IEC 25030 Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Quality requirements


Estándares de calidad De la Serie ISO 9000:

ISO/IEC 9000-3 Lineamientos para la aplicación de la Norma ISO 9001 en el

desarrollo, suministro y mantenimiento del Software

ISO/IEC 9000-4 Guía para la gestión de un programa de seguridad de

funcionamiento

ISO/IEC 10007 Directrices para la gestión de la configuración

ISO/IEC 9126-1 Software Quality Characteristics and Metrics

ISO/IEC 12207 Software Life Cycle Processes

ISO/IEC 14102 Information Technology - Guidelines for the evaluation and

selection of CASE tools

ISO/IEC 15026 System and Software Integrity Levels

ISO/IEC 15271 Guide to ISO/IEC Software Life Cycle Processes

ISO/IEC 15504 Software Process Assessment

ISO/IEC 15846 Software Configuration Management

ISO/IEC 17799 Seguridad Informática

Otras normas internacionales:

CMM [SEI]: Estándar que sirve de guía para la mejora en el proceso de Desarrollo de

Software.

CMMI [SEI]: Estándar basado en CMM pero con una visión más integral.


CMM - CMMI

Capability Maturity Model

Capability Maturity Model Integration


Software Engineering Institute

SEI

Financiado por el Departamento de Defensa

de Estados Unidos en la Carnegie Mellon

University, desde 1984

(http://www.sei.cmu.edu).

Su primer director su Watts Humphrey,

CMMI del SEI

http://www.sei.cmu.edu/cmmi/


Producto del SEI

Modelo de Madurez del Proceso de

Software:

desarrollado para evaluar las capacidades de una

organización de software,

para identificar las áreas más importantes de

mejoramiento,

tratando el proceso completo de desarrollo de

software como un proceso que puede ser:

controlado, medido y mejorado.

http://www.sei.cmu.edu/cmmi/


Modelo de Madurez

Para mejorar sus capacidades, las organizaciones

de software deben:

comprender el estado actual de sus procesos de software,

desarrollar una visión de los procesos deseados,

establecer una lista de las acciones de mejoramiento

requeridas en orden de prioridad,

producir un plan para cumplir dichas acciones,

comprender los recursos necesarios para ejecutar el plan.

Herramienta: framework de madurez.


Proceso de Mejora Continuo:

CMM y CMMICMM (Década del ’90): Características

• Mide la capacidad del proceso seguido para desarrollar software incrementando la predictibilidad en

cuanto a costos, tiempos y calidad lograda.

• Es el modelo más utilizado en la industria de software.

• No contempla todas las necesidades de la organización, por lo que se fueron agregando otros

modelos que daban solución a los problemas detectados.

CMMI (A partir del 2001): Características

• Sirve como guía única para la mejora de múltiples disciplinas tales como la Ingeniería de sistemas

(SE), Ingeniería de software (SWE), el desarrollo integrado entre el producto y el proceso (IPPD) y la

gestión de compras y control de proveedores.

Objetivos que se persiguen:

• Determinar el nivel de madurez del Proceso de Desarrollo (Indicador de calidad)

• Servir de guía en el Proceso de Desarrollo permitiendo la Mejora Continua de la organización.


CMM

Califica el grado de madurez de los métodos y del personal interno de la empresa para desarrollar un sistema

El CMM establece cinco niveles progresivos para los procesos relacionados con la construcción de aplicaciones informáticas, hasta alcanzar la madurez total: 1-Inicial

2-Repetible

3-Definido

4- Gestionado

5-En Mejora Continua.


Proceso de Mejora Continuo:

CMMI

Gestión básica de proyectos

Nivel 1: Inicial

Nivel 2: Gestionado

Nivel 3: Definido

Nivel 4: Gestionado

de forma cuantitativa

Nivel 5: Optimizado

Procesos estandarizados

Procesos analizados y medidos

Mejora continua de los procesos

5 Niveles de Madurez

28 Áreas Claves de Proceso


Detalle de los Niveles de

Madurez:

NIVEL 1: Inicial (a medida)

Basado en las competencias y acciones individuales de las personas

NIVEL 2: Gestionado (Gestión básica de proyectos)

• Gestión de Requisitos del producto y del proyecto

• Planificación de los proyectos

• Seguimiento y Control de los proyectos de software

• Gestión de Subcontratación de producto y servicios

• Selección y Control de los proveedores

• Medición y análisis

• Aseguramiento de la calidad del producto y del proceso

• Gestión de Configuración del Software


Nivel 3: Definido (estandarización de procesos)

• Desarrollo de los requisitos del cliente y del producto

• Diseño, desarrollo y puesta en práctica de soluciones técnicas

• Aseguramiento de la integración del producto

• Verificación y Validación

• Enfoque hacia la gestión de procesos

• Institucionalización del proceso a nivel organización

• Educación y entrenamiento para mejorar la eficiencia y eficacia

• Gestión integrada de los proyectos

• Gestión de riesgos

• Análisis sistemático y puesta en práctica de decisiones acordadas

• Ambiente organizativo adecuado para el desarrollo integrado del producto

y el proceso

• Formación de un equipo para el desarrollo integrado

• Gestión integrada de proveedores


Madurez:



Madurez:

Nivel 4: Gestionado de forma cuantitativa

• Evaluación de los procesos de la organización (datos del

rendimiento de los procesos)

• Gestión cuantitativa de los proyectos

• Gestión cuantitativa de los proveedores

Nivel 5: Optimización (mejora continua de los procesos)

• Innovación y despliegue a lo largo de toda la organización (mejoras

incrementales y su posterior generalización)

• Gestión de cambios tecnológicos

• Análisis y resolución de las causas que generan los diferentes

problemas y errores


Tiempo para Madurar

Tiempo promedio para alcanzar cada nivel

de CMM:

nivel 1 a nivel 2: 2 a 3 años;

nivel 2 a nivel 3: 1.5 a 2.5 años;

nivel 3 a nivel 4: ?

nivel 4 a nivel 5: ?

ISIII_CAP6.2 de Aseguramiento de La Calidad de Software

Documents

Transcript of ISIII_CAP6.2 de Aseguramiento de La Calidad de Software