INTRODUCCION A LA TEORÍA

DE LA CALIDAD
Ingeniera Alma Lucrecia Olivet López (PhD)
Docente
Ingeniera Alma Lucrecia Olivet López (PhD)
Docente
Mindmapping

CALIDAD
Definiciones de Calidad

La totalidad de las características de un producto o servicio

que le confieren aptitud para satisfacer necesidades
establecidas e implícitas
ISO

Calidad de software es cumplir con los

requerimientos del cliente más la formalidad del
proceso con que fue desarrollado
SEI
 Definiciones de Calidad
Una definición de calidad de software es:

El conjunto medible de atributos del

producto y del proceso de producción, los cuales permiten determinar con
claridad los costos, beneficios y riesgos potenciales de su desarrollo,
utilización/comercialización y posterior evolución.
Atributos de Calidad de Productos y
Procesos

Calidad

Producto Proceso
• • Definido
Requerimientos
• • Documentado
Mantenibilidad
• • Soportado
Confiabilidad
• • Conocido
Seguridad
• • Practicado
Rendimiento
• • Medido
Disponibilidad
• Mejorable
 Problemas y costos de la No calidad

• Problemas • Costos relacionados

• Requerimientos no • Altos costos de retrabajo

cumplidos, mal • Altos costos de soporte
interpretados • Costos de oportunidad
• Entregas tardías
• Pérdida de mercados
• Diseños mal realizados
• Defectos recurrentes
• Errores detectados por los
clientes
• Errores de alto riesgo
• Malas políticas de testing
Costo de Calidad
Costos asociados a la Calidad:
• Prevención
• Planificación de calidad
• RTF
• Equipos de Pruebas
• Formación
• Evaluación
• Inspección en el proceso y entre procesos
• Calibrado y mantenimiento del equipo
• Pruebas
• Fallos
• Internos (Retrabajo, Reparación, Análisis de fallos)
• Externos (Resolución de quejas, Sustitución de productos, Soporte)
Procesos principales de la gestión
de calidad
• Planificación de la calidad: identificación de los estándares de calidad y de
cómo satisfacerlos.
• Aseguramiento de la calidad: evaluación del desempeño completo del
proyecto para brindar confianza en que el proyecto cumplirá con los estándares
de calidad.
• Control de calidad: verificación del cumplimiento de los estándares de calidad
y modo de eliminar causas de desempeño insatisfactorio.
 Planificación de la calidad
• Entradas:
• Políticas de calidad
• Enunciación del alcance
• Descripción del producto • Técnicas y herramientas:
• Estándares y regulaciones – Análisis costo/beneficio
• Otras salidas de procesos – Estudios comparativos
– Diagramas de flujo
• Salidas: – Diseño de experimentos
• Plan de gestión de la calidad – Costo de la calidad
• Definiciones operativas
• Listas de verificación
• Entradas a otros procesos
 Aseguramiento de la calidad
• Entradas:
• Plan de gestión de la calidad
• Resultados de las mediciones
de control de calidad
• Definiciones operativas • Técnicas y herramientas:
– Técnicas y herramientas de
la planificación de la
• Salidas: calidad
• Mejora de la calidad – Auditorías de la calidad
 Control de la calidad
• Entradas:
• Resultados de los trabajos
• Plan de gestión de la calidad • Técnicas y herramientas:
• Definiciones operativas
– Inspección
• Listas de verificación
– Gráficos de control
– Diagramas de Pareto
• Salidas: – Muestreo estadístico
• Mejora de la calidad – Diagramas de flujo
• Decisiones de aceptación – Análisis de tendencias
• Reproceso
• Listas de verificación
completadas
• Ajustes al proceso
Herrramientas para la planificación de la
calidad
Diagramas causa-efecto

Tiempo Máquinas Método Material

Defecto

Energía Mediciones Personal Ambiente

Causas potenciales Efecto

Herramienta creada por Ishikawa para analizar

por categorías los factores principales que influyen
en un proceso, evitando prestar atención solamente
a algunas causas.
 Herrramientas para el control de la
calidad
Diagramas de pareto

16
14
12
10
8
6
4
2
0
1 2 3 4 5 6 7
Problemas

Herramienta creada por Pareto, es un gráfico de barras que

muestra en forma descendente y de izquierda a derecha
la importancia de cada categoría de datos que permite armar
la curva ABC conocida como 20-80
 Control de calidad del software
(SQA) Pressman

• Para garantizar la calidad del software necesitamos:

• Enfoque a la gestión de calidad
• Tecnología (métodos y herramientas) de ingeniería de Software y
un equipo de SQA
• Revisiones técnicas formales durante todo el proceso
• Una estrategia de pruebas
• Control de documentación del software y de los cambios
realizados
• Procedimientos
• Mecanismos de medición y de generación de informes
Control de calidad del software
(SQA)

CALIDAD

De proceso

De producto
 Actividades del control de
calidad del software (SQA)
1. Establecimiento de un plan de SQA para el proyecto con:
a. Evaluaciones a realizar
b. Auditorías y revisiones a realizar
c. Estándares a aplicar en el proyecto
d. Procedimientos para información y seguimiento de errores
e. Documentos a producir
f. Realimentación de información de desarrollo
 Actividades del control de
calidad del software (SQA)
2. Participación del grupo SQA en el desarrollo de la descripción
del proceso de software (proceso vs políticas, procesos de
negocios, etc)
3. Revisión de las actividades de ingeniería de software para
verificar su ajuste al proceso definido.
4. Auditoría de los procesos de software.
5. Aseguramiento de la documentación de los desvíos del
producto y aplicación del procedimiento establecido.
6. Registro de lo que no se ajuste e informe a los superiores.
7. Coordinación del control y gestión de cambios
8. Colaboración en la recopilación y el análisis de las métricas del
software.
Revisiones técnicas formales
• Objetivos:
• Descubrir errores en la función, la lógica o la
implementación de cualquier representación del
software.
• Verificar que el software bajo revisión alcanza sus
requirimientos.
• Garantizar que el software ha sido representado de
acuerdo a ciertos parámetros estándares predefinidos.
• Conseguir un software desarrollado de forma uniforme.
• Hacer que los proyectos sean más manejables.
Revisiones técnicas formales
• Forma:
• Reunión de revisión para:
• Aceptar el producto
• Rechazar el producto
• Aceptar provisionalmente el producto

• Registro de la revisión:
• ¿Qué fue revisado?
• ¿Quién lo revisó?
• ¿Qué se descubrió y cuáles fueron las conclusiones?
 Revisiones técnicas formales
• Directrices para la revisión:
• Revisar el producto, no al productor
• Fijar una agenda y mantenerla
• Limitar el debate y las impugnaciones
• Enunciar áreas de problemas, pero no intentar resolver cualquier problema
• Tomar notas escritas
• Limitar el número de participantes e insistir en la preparación anticipada
• Desarrollar una lista de comprobación para cada producto que se vaya a
revisar
• Disponer de recursos y tiempo para las RTFs, que se deben planificar junto con
el proceso de ingeniería de software.
• Llevar a cabo un buen entrenamiento de todos los revisores en el proceso de
revisión (técnica) y en psicología humana (ej. Trabajo en equipo).
• Revisar las revisiones anteriores.
Proceso
Jefe de Revisión
de una RTF Líder de Proyecto

Productor

El líder evalúa si el producto está en condiciones de pasar a

El líder evalúa si el producto está una RTF.
en condiciones de pasar a una Distribuye las copias a los revisores.
RTF. Agenda la RTF.
Revisores

El productor le informa al Proceso de una

líder que ha terminado su
producto.
Revisión Técnica Formal

Registrador Los revisores realizan la revisión

previa a la reunión.

Toma las anotaciones correspondientes para generar:

La lista de sucesos de revisión y el informe sumario de
revisión.
Le pasa los informes al productor para que realice las
correcciones pertinentes.
Archiva la documentación para futuros controles. Se realiza la RTF.
 Estándares de calidad
• Otros aspectos de calidad:
• Fiabilidad del software (Probabilidad de operación libre de fallos, en
un entorno y tiempo determinado):
• TMEF = TMDF + TMDR (tiempo medio entre fallos = tiempo medio de
fallo + tiempo promedio de reparación)

• Disponibilidad del software (Probabilidad de que un prg funcione

de acuerdo con los req en un momento dado):
• Disponibilidad= TMDF/(TMDF+TMR) *100
Estándares de calidad - Normas ISO
• ISO 9001: es un estándar que describe el sistema de calidad
utilizado para mantener el desarrollo de un producto que
implique diseño.
• ISO 9000-3: es un documento específico que interpreta ISO
9001 para el desarrollador de SW.
• ISO 9000-4: soporta las directrices para el servicio de
soporte a usuarios.
 Factores de Calidad según ISO
9126
• · Funcionalidad : Adaptación, Exactitud, Interoperación,
Seguridad.
• · Confiabilidad: Madurez, Tolerancia a Defectos, Facilidad
de Recuperación.
• · Eficiencia: Comportamiento en el Tiempo, de los Recursos.
• · Facilidad de Uso: Facilidad de Comprensión, de Aprendizaje, de
Operación.
• · Facilidad de Mantenimiento: Facilidad de Análisis, de Cambios,
de Pruebas, Estabilidad.
• · Portabilidad: Adaptabilidad, Facilidad de Instalación, de
Reemplazo.
Árbol de las características de
calidad del software. IEEE 1976 Independiente
del HW
Autocontenido
Seguro
Portabilidad
Compelto
Integro/Robusto
Confiabilidad
Consistente
Utilidades Para el uso Eficiencia Trazable
Generales Ingeniería
Eficiente con el HW

Humana Accesible
Comunicativo
Testeable Auto descriptivo
Para el Estructurado
Mantenimiento Comprensible Conciso
Legible
Modificable Escalable
 CMM
Calidad del Software
Ingeniería del Software
UCSA
 Qué es un modelo de
procesos?
Un modelo es una colección estructurada de elementos que describen
las caractéristicas de un proceso eficiente y eficaz.

Un buen modelo de procesos contiene un gran cantidad de experiencia

de campo dentro de su estructura.
Qué es CMM
 Una aplicación del sentido común para el gerenciamiento de
procesos y conceptos de mejora de la calidad del desarrollo y
mantenimiento del software

 Una guía desarrollada por y para la comunidad profesional del

software

 Un modelo para la mejora organizacional

 Una estructura confiable y consistente para evaluar y mejorar

las capacidades de una organización
Qué puedo hacer con
CMM ?
 Ayudar a la comunicación, al establecer un lenguaje común
en el ámbito organizacional

 Facilitar poner el foco de atención en cuestiones críticas

 Proveer recomendaciones generales

 Ayudar a priorizar acciones de mejora

Niveles de Madurez
Estructura del CMM
Nivel de Madurez
Contiene

Areas claves
Debe alcanzar
Objetivos

Facilidades comunes para la implantación

Actividades a
ejecutar
Compromiso Habilidades Medición y Verificación de
Para ejecutar necesarias Análisis Implantación
CMM Nivel 1: Inicial
• Ambiente inestable que carece de prácticas de management
• Los compromisos no están bajo control
• Los éxitos se basan en el talento individual y el esfuerzo de los
héroes

• Las buenas prácticas y estándares son frecuentemente sacrificadas por

otras prioridades del management
• Usualmente se cuenta con cronogramas

• La capacidad del proceso es impredecible

• Los objetivos de cronograma, costos y calidad no se hallan
definidos
 CMM Nivel 2: Repetible
• La necesidad es establecer una administración efectiva del proyecto
de software
• Los procesos de Administración de Proyectos están definidos e
implementados
• Las políticas organizacionales guían los proyectos
• Las prácticas exitosas usadas en proyectos previos, puede ser
repetidas.
 CMM Nivel 3: Definido
• Los procesos de software están definidos, documentados, y son
aplicados a través de toda la organización.
• Comprensión compartida de como funciona el proceso y roles
establecidos
• La capacidad de los procesos satisface objetivos de cronograma,
costos, y funcionalidad
 CMM Nivel 4: Administrado
• La efectividad del proceso es medida.

• El control estadístico del proceso es iniciado.

• Se sigue un proceso que apunta a las causas de desviaciones en el

producto.
 CMM Nivel 5: Optimizado
• Los factores que imposibilitan la realización, son identificados y
eliminados.

• La mejora continua está institucionalizada

• La transición a nuevas tecnologías es practicada rutinariamente

 Conclusiones
 El CMM codifica buenas prácticas existentes

 Es independiente de la tecnología y del área

 Es difícil salir del nivel 1

 Se puede ser exitoso en el nivel 1

 Se puede ser un fracaso en el nivel 3

 Es aplicable a todo tipo y tamaño de organizaciones de software

Los problemas de CMM y la solución
Problemas de CMM
• Las disciplinas de Software y Sistemas nuncan han
sido bien integradas
• La Importancia e influencia del software en los
sistemas se ha incrementado dramáticamente

La solución: CMMI
• Integrar las disciplinas de software y sistemas en un
marco de mejoras a los procesos.
• Proveer un marco de trabajo para introducir nuevas
disciplinas según necesidades.
Mejoras de CMMI sobre CMM
Enfasis en mejoras medibles para lograr objetivos del negocio

Han sido agregadas Areas de Procesos para poner más enfasís en

algunas prácticas importantes
Gestión de Requerimientos
Ingeniería de Procesos
Análisis de las decisiones

CMMI es significativamente más grande que el CMM:

Más objetivos y prácticas
Más áreas de proceso
Más detalles
 Ventajas del CMMI
Arquitectura del modelo más robusta y con mayor nivel de detalle

Aplicable a más de una disciplina

Mejor atención a las áreas de ingeniería

La representación continua permite focalizar mejoras de acuerdo a los objetivos

del negocio
Desventajas del CMMI
• Tamaño y complejidad mucho mayor que modelos vigentes

• El proceso de avaluación es más costoso en tiempo y

esfuerzo

• La complejidad de la evaluación continua puede atentar

contra la definición de objetivos concretos de madurez
Conclusiones
• Si usted viene del mundo del CMM trabaje con el modelo
por niveles
• Si usted tiene bien claros los objetivos de su negocio y las
debilidades de sus procesos, y además entiende las
relaciones entre las áreas de proceso, la representación
continua puede ser una buena alternativa
• Para ambos casos, defina un plan de migración sobre la
base de su madurez actual y una buena comprensión de su
negocio/productos
Gestión de configuración
del software

Ingeniería del Software

[Link] Gouget
UCSA
2006
Gestión de Configuración de
Software
Definición

“La gestión de configuración es una actividad de

auto protección que se aplica a lo largo del
proceso de la Ingeniería de Software y que tiene
como objetivo identificar, organizar y controlar las
modificaciones que sufre el software que
construye un equipo.”

Babich y Pressman
Gestión de Configuración de
Software
Definición

Gestión de configuración

NO ES

Mantenimiento del Software

Actividades de la GCS
1. Identificar el cambio
2. Controlar el cambio
3. Garantizar que el cambio se implementa
adecuadamente
4. Informar del cambio a los interesados.
Elementos de Configuración
• La Ingeniería del software produce:

• Programas
• Datos
• Documentos

Todos ellos se transforman en elementos de configuración

del software.
Los cambios
“Sin importar en qué momento del ciclo de vida nos
encontremos, el sistema cambiará y el deseo de cambiarlo
persistirá a lo largo de todo el ciclo de vida”.

• Los cambios se producen por:

• Nuevos requerimientos del negocio
• Nuevas necesidades del usuario
• Reorganización comercial
• Restricciones de presupuestos o planificaciones
Los cambios
La GCS es un conjunto de actividades desarrolladas
para gestionar los cambios a lo largo del ciclo de
vida del software.

La GCS es una actividad de garantía de calidad que

se aplica en todas las fases del proceso de la
ingeniería del software.
Líneas de Base
Una línea de base es una especificación o producto
que se ha revisado formalmente, y que de ahí en
adelante sirve como base para un desarrollo
posterior y que puede cambiarse solamente a
través de procedimientos formales de control de
cambios.
Líneas de Base
• La Línea de base es un punto de referencia en el
desarrollo del software que queda marcado con la
aprobación de uno o más elementos de
configuración del soft.

• Se pueden establecer por ejemplo al terminar cada

fase del ciclo de vida que se esté utilizando.
 Líneas de Base

Ingeniería del Sistema Especificación

Del sistema

Análisis de Requisitos Especificación

de requisitos

Diseño del Software Especificación

Del diseño

Código
Codificación fuente
Planes,
Prueba procedimientos,
datos de pruebas
Entrega Sistema en
funcionamiento
Elementos de configuración
Ejemplos
• Especificación del sistema
• Plan del Proyecto de Software
• Especificación de requisitos del software:
• Modelo del análisis
• Especificaciones de Procesos
• Prototipos
• Manual de usuario
• Especificación del diseño
• Listados de códigos fuentes
• Especificación de las pruebas
• Manuales de operación y ejecución
• Programas ejecutables
• Descripción de la base de datos
Etc....
Líneas de Base y Elementos de Configuración
Relación

Una línea de base

Varios elementos
De configuración
El proceso de la GCS
1. Identificación los elementos de configuración
2. Control de versiones
3. Control de cambios
4. Auditorías de Configuración:
1. Revisiones formales
2. Auditorías de configuración
5. Generación de informes
El proceso de la GCS
1.- Identificación los elementos de
configuración

1. Identificar y organizar los objetos como básicos y

compuestos (colección de básicos y compuestos)

2. Identificar al objeto con un nombre que lo

identifique unívocamante.

3. Identificar las relaciones entre los objetos.

4. Documentarlos con gráficos o notaciones.

 El proceso de la GCS
2.- Control de versiones

1. Combina procedimientos y herramientas para gestionar

las versiones de los objetos de configuración creados
durante el proceso de ingeniería de software.
2. Cada versión del software es un colección de ECS y cada
versión puede estar compuesta de diferentes variantes.
3. A cada componente se le asigna una tupla de atributos,
lista de características que definen si se ha de utilizar el
componente cuando se va a construir una determinada
versión del software.
 El proceso de la GCS
3.- El proceso del Control de cambios

• Combina procedimientos humanos y herramientas.

• Elementos del control de cambios:
• Petición del cambio
• Autoridad de control de cambios (ACC)
• Orden de Ingeniería de cambios (OCI)
• Procesos de alta y baja de objetos (control de acceso y
sincronización)
• Nivel del cambio: informal (antes de la línea de base), a
nivel del proyecto (cambio local) o formal (cuando el
software está en los clientes).
El Proceso Formal del Control de Cambios

El usuario reconoce la necesidad del cambio

El usuario pide el cambio

El desarrollador lo evalúa

Se genera un informe de cambios

La autoridad de control de cambios decide

Se genera la orden Se rechaza

de cambio el cambio

Se informa al
usuario
El Proceso Formal del Control de Cambios
Se genera la orden de cambio

Se identifican los elementos de configuración afectados

Se dan de baja los ECS (sincronización)

Se realiza el cambio

Se audita el cambio

Se aprueba el cambio

Se dan de alta los ECS afectados

Se incluyen cambios en producción

Se revisan los cambios en todos los ECS

Se distribuye una nueva versión con los cambios

 El proceso de la GCS
4.- Auditorías de Configuración

1. Revisiones técnicas formales: es una reunión con

determinadas premisas que se centra en la corrección
técnica del ECS que ha sido modificado, evaluando su
consistencia con otros ECS, las omisiones o efectos
secundarios.
2. Auditorías de configuración: es una actividad
independiente que es llevada a cabo por el grupo de
garantía de calidad y tiene como objetivo asegurar que se
ha hecho, revisado, implementado y comunicado
correctamente el cambio, de acuerdo a los estándares.
El proceso de la GCS
5.- Generación de informes de estado de
configuración (IEC)

Es una actividad que documenta (contabiliza):

•¿Qué pasó?
•¿Quién lo hizo?
•¿Cuándo pasó?
•¿Qué más se vio afectado?
en cada paso del proceso formal del control de
cambios.

Su objetivo es el de mejorar la comunicación entre todas las

personas involucradas en el proyecto.