Universidad Tecnológica Nacional

Facultad Regional Córdoba

Cátedra de Ingeniería de Software
Docentes: Laura Covaro & Judith Meles

Aseguramiento de Calidad de
Proceso y de Producto

Judith Meles
Aseguramiento de Calidad de Proceso y de
Producto (PPQA): Cobertura
Definición
Calidad en el Desarrollo
Calidad de Software
Principios de Calidad
Calidad
de Visiones y Perspectivas
Producto Estándares de Calidad
Calidad de Modelos de Calidad
CMMI
PPQA Proceso de Proceso
Modelos de Mejora IDEAL
Auditorías
Aseguramiento
Revisiones Técnicas
de Calidad
Testing
CMMI vs
AGILE
 ¿Qué es la calidad?
Todos los aspectos y características de un
producto o servicio que se relacionan con su
habilidad de alcanzar las necesidades manifiestas
o implícitas

3
La calidad es relativa a las personas, a su edad, a
las circunstancias de trabajo, el tiempo…

El tiempo varía las percepciones

¿Qué cosas ocurren frecuentemente en los
proyectos de desarrollo de software?
• Atrasos en las entregas
• Costos Excedidos
• Falta cumplimiento de los compromisos
• No están claros los requerimientos
• El software no hace lo que tiene
que hacer
• Trabajo fuera de hora
• Fenómeno del 90-90
• ¿Dónde está ese componente?
Situación de Proyectos de Software

Retrasados
100% en Tiempo

80% Excedidos en No alcanzan

Presupuestos los Objetivos

Cancelados o
60% Abortados

40% 90 %
50 % 50 %
30 %
20%

0%
Un Software de Calidad satisface…
▫ Las expectativas del Cliente
▫ Las expectativas del Usuario
▫ Las necesidades de la gerencia
▫ Las necesidades del equipo de desarrollo y
mantenimiento
▫ Otros interesados…
Principios
 La calidad no se ‘inyecta’ ni se compra, debe estar embebida.
 Es un esfuerzo de todos
 Las personas son la clave para lograrlo
 Capacitación
 Se necesita sponsor a nivel gerencial
 Pero se puede empezar por uno
 Se debe liderar con el ejemplo
 No se puede controlar lo que no se mide
 Simplicidad, empezar por lo básico
 El aseguramiento de la calidad debe planificarse
 El aumento de las pruebas no aumenta la calidad
 Debe ser razonable para mi negocio
8
 ¿Calidad para quién?
Visión
Del Usuario

Visión De Visión Visión Del

Manufactura Trascendental Producto

Visión
Basada en el
valor

 9
 10

Todo lo que este fuera de dicha coincidencia será

desperdicio o insatisfacción.

GESTIÓN
DE LA
CALIDAD
Calidad en el Software
Modelos para crearlos

Modelos para mejorarlos

Modelos para evaluarlos

Proceso

Revisiones Técnicas
Técnicas y
Herramientas
Auditorías

Proyecto
Revisiones
Técnicas
Para
Aseguramiento
de Calidad
Modelos para medirlos Técnicas y
Auditorías (De
Configuración)
Herramientas

Para Control de
Producto Calidad
Testing
12
 ISO/IEC 25000: Modelos
▣ Calidad en Uso (ISO 25010: 2011)
▣ Calidad de producto (ISO 25010:2011)
▣ Calidad de Datos (ISO 25012:2008)

Calidad de
Producto

Calidad en Calidad de
uso Datos
 Calidad de
Producto

Adecuación Eficiencia de Compatibilida

d
Usabilidad Fiabilidad Seguridad Mantenibilidad Portabilidad
Funcional Desempeño

Completitud Comportamient Reconocimient Confidencialida

Coexistencia Madurez Modularidad Adaptabilidad
Funcional o Temporal o de corrección d

Corrección Utilización de Interoperabilida Facilidad de

Aprendizaje Disponibilidad Integridad Reusabilidad
Funcional Recursos d instalación

Capacidad de
Pertinencia Tolerancia a
Capacidad Operabilidad No repudio Analizabilidad ser
Funcional fallos
reemplazado

Protección
Capacidad de Capacidad de
frente errores Autenticidad
Recuperación ser modificado
de usuario

Responsabilida Capacidad de
Estética
d ser probado

Accesibilidad

Modelo de Calidad de Producto (En uso) – ISO 25010

Modelos de Calidad de Producto
Modelo de Barbacci / SEI

Performance

Seguridad

Confiabilidad
Local (único atributo) óptimo
15 Global (múltiple atributo) óptimo
 Modelos de Calidad de Producto
CALIDAD DEL SOFTWARE (MCCALL)
Facilidad de Portabilidad
Mantenimiento Reusabilidad
Flexibilidad Interoperatividad
Facilidad de Prueba
Revisión del Transición del
Producto Producto

Operación del
Producto
Corrección - Fiabilidad - Usabilidad (facilidad de manejo) -
Integridad - Eficiencia
16
17
Lo que sirve a unos...

puede no servir a otros...

 El proceso es el único factor <<controlable>> al mejorar la
calidad del software y su rendimiento como organización

Producto

Características Condiciones del

del Cliente negocio

Proceso

Personas Tecnología
Entorno de
desarrollo
19
Proceso sin definir
 Definición de un Proceso de Software
Proceso: La secuencia de pasos
ejecutados para un propósito
dado (IEEE)
Proceso de Software: Un
conjunto de actividades,
métodos, prácticas, y B
transformaciones que la gente A D
usa para desarrollar o C Procedimientos y métodos
mantener software y sus
productos asociados (Sw-CMM)

Personas con
habilidades, PROCESO
entrenamiento y
motivación Herramientas y
Equipos
¿Cómo lo definimos?
Un proceso sin definir

Etapa 1 Etapa 2 Etapa 3 Etapa 4

Tarea 1.2 •¿Quiénes deben participar ?

Tarea 1.1 Tarea 1.5 •¿Qué deben hacer ?
Tarea 1.4
Tarea 1.3 •¿Cuándo lo deben hacer?
•¿Cómo lo deben hacer ?
¿Cómo es un proceso para Construir Software?
<<include>>

Registrar Alquiler de Validar Socio

Película

Empleado de <<extend>>
Video

Validar Socio por

Teclado Validar Socio con Tarjeta
Registrar Socio

Cliente

Registrar Devolución de
Película Brindar Consulta de
Película

SISTEMA PROBADO
MODELOS SISTEMA
Ingeniería
Implementación Prueba Despliegue

1. 1. Depósito $ 100.- Boleta Crédito en la cuenta corriente en pesos.

2345
2. Depósito $ 150.- Crédito en la caja de ahorros en pesos
Boleta
3. Depósito $ 200.- Crédito a cuenta única en pesos
2347
Boleta
2352
2. Idem variación 1.1 Boleta Crédito a cuenta corriente en dólares
2351
Idem variación 1.2. Crédito a caja de ahorros en dólares

MODELOS
Boleta
2349

Plan
de Prueba CASOS DE PRUEBA SISTEMA
FUNCIONANDO
<<include>>

Registrar Alquiler de Validar Socio

Película

Empleado de <<extend>>
Video

Validar Socio por

Teclado Validar Socio con Tarjeta
Registrar Socio

Cliente

Registrar Devolución de
Película Brindar Consulta de
Película

Planificación y Seguimiento de Proyectos

Administración de Configuraciones
Aseguramiento de la Calidad
 “Lo que no está controlado no está hecho”
Watts Humphrey

2
4
 Administración de la Calidad del Software
• Concerniente con asegurar que se alcancen los niveles
requeridos de calidad para el producto de software.
• Implica la definición de estándares y procesos de calidad
apropiados y asegurar que los mismos sean respetados.
• Debería ayudar a desarrollar una “cultura de calidad” donde
la calidad es vista como una responsabilidad de todos y cada
uno.
 Reporte del Grupo de Aseguramiento de Calidad
(GAC)
• No debería reportar al Gerente de Proyectos.
• No debería haber más de una posición entre la
Gerencia de Primer Nivel y el GAC.
• Cuando sea posible, el GAC debería reportar alguien
realmente interesado en la calidad del software.
 Actividades de la Administración de
Calidad de Software

• Aseguramiento de Calidad
▫ Establecer estándares y procedimientos organizacionales de
calidad.
• Planificación de Calidad
▫ Selecciona los procedimientos y estándares aplicables para
un proyecto en particular y los modifica si fuera necesario.
• Control de Calidad
▫ Asegura que los procedimientos y estándares son respectados
por el equipo de desarrollo de software.
Funciones del Aseguramiento de Calidad de Software
• Prácticas de Aseguramiento de Calidad
▫ Desarrollo de herramientas adecuadas, técnicas, métodos y estándares
que estén disponibles para realizar las revisiones de Aseguramiento de
Calidad.
• Evaluación de la planificación del Proyecto de Software
• Evaluación de Requerimientos
• Evaluación del Proceso de Diseño
• Evaluación de las prácticas de programación
• Evaluación del proceso de integración y prueba de software
• Evaluación de los procesos de planificación y control de proyectos
• Adaptación de los procedimientos de Aseguramiento de calidad para
cada proyecto.
 La Administración de Calidad y
el Desarrollo de Software

Proceso de Desarrollo de
Software

Proceso de Administración
de Calidad

Estándares y Plan de Calidad Informes de Revisión de Calidad

procedimientos
 Procesos basados en calidad
Definir Desarrollar Evaluar calidad
Procesos Producto del Producto

Mejorar NO
Calida
SI
Estandarizar
d OK?
Procesos Procesos
 Calidad de Procesos en la Práctica
• Definir procesos estándares tales como:
▫ Cómo deberían conducirse revisiones
▫ Cómo debería realizarse la administración de configuración, etc.
• Monitorear el proceso de desarrollo para asegurar que los
estándares sean respetados.
• Reportar en el proceso a la Administración de Proyectos y al
responsable del software.
• No use prácticas inapropiadas simplemente porque se han
establecido los estándares.
 Estándares y Aseguramiento de Calidad
• Los estándares son la clave para la administración de
calidad efectiva.
• Pueden ser estándares internacionales, nacionales,
organizacionales o de proyecto.
• Estándares de Producto definen las características que todos
componentes deberían exhibir, ej. estilos de programación
común.
• Estándares de Procesos definen cómo deberían ser
implementados los procesos de software.
 Planificación de la Calidad
• Un plan de calidad define los productos de
calidad deseados y como serán evaluados , y
define los atributos de calidad más significativos.
• El plan de calidad debería definir el proceso de
evaluación de la calidad.
• Define cuales estándares organizacionales
deberían ser aplicados , como así también si es
necesario utilizar nuevos estándares.
Control de Calidad
• Este implica el control del proceso de desarrollo
para asegurar que se siguen los estándares y
procedimientos .
• Existen dos enfoques para el control de
calidad:
▫ Revisiones de Calidad;
▫ Evaluaciones de Software Automáticas y
mediciones.
Revisiones de Calidad
• Este es el principal método de validación de la calidad de
un proceso o un producto.
• Un grupo examina parte de un proceso o producto y su
documentación para encontrar potenciales problemas.
• Existen diferentes tipos de revisiones con diferentes
objetivos
▫ Inspecciones para remoción de defectos (producto);
▫ Revisiones para evaluación de progreso (producto y proceso);
▫ Revisiones de Calidad (producto y estándares).
Calidad en el Software
Modelos para crearlos

Modelos para mejorarlos

Modelos para evaluarlos

Proceso

Revisiones Técnicas
Técnicas y
Herramientas
Auditorías

Proyecto
Revisiones
Técnicas
Para
Aseguramiento
de Calidad
Modelos para medirlos Técnicas y
Auditorías (De
Configuración)
Herramientas

Para Control de
Producto Calidad
Testing
3
7
Mejora de Procesos

• Algunos modelos para la Mejora de Procesos son:

▫ SPICE: Software Process Improvment Capability
Evaluation.
▫ IDEAL: Initiating, Diagnosing, Establishing,
Acting, Leveraging.

3
8
 Modelo IDEAL
Learning
Revise Document
Organizational & Analyze
Approach Lessons Define
Processes
& Measures Acting
Stimulus for Set Context Establish Plan &
Improvement & Establish Improvement Execute
Sponsorship Infrastructure Pilots

Initiating Appraise &

Characterize
Plan,
Execute,
Current & Track
Practice Installation
Establish Process
Develop Action Teams
Recommendations
& Document Plan Actions
Phase Results Set Priorities
& Strategies
Diagnosing Establishing
3
9
4
0
Modelo de Calidad
CMMI ® (Capability Maturity Model Integration)
▫ Es la evolución del SW_CMM ®
▫ Lo emite el Software Engineering Institute – SEI, que es una
entidad fundada por el DoD de USA en conjunto con la
universidad de Carnegie Mellon.
▫ Este instituto se funda en 1984.
▫ La versión vigente es la 1.3 y fue liberada en Noviembre del
2010
▫ ISACA ® compra el CMMI Institute, desde este año 2020, la
versión vigente es Versión 2.0 de ISACA®
• Uno de los modelos más implementado en
todo el mundo.
• No es una norma, y no se “certifica”, sólo se
evalúa a través de profesionales reconocidos
por el SEI como Lead Appraisers
CMMI: Constelaciones
CMMI-DEV provee la
guía para medir, CMMI-SVC provee la
monitorear y guía para entregar
administrar los servicios , internos o
procesos de CMMI-SVC externos
desarrollo
CMMI-ACQ provee
la guía para
permitir
seleccionar y
CMMI-DEV CMMI-ACQ administrar
adquirir
productos y
servicios
16 Áreas de Proceso fundacionales, comunes a
todas
% de PA´S de CMMI-DEV son reutilizadas;
77% % de inversión es potencialmente reusable!
 CMMI: Representaciones
Por Etapas 6

5
Continua
4

3 Serie2

0
1
AP AP 2 AP3 AP
4 5
AP 6
AP

5 Niveles, de 1 a 5
Definidos por un conjunto de Áreas de
Proceso.
Niveles indican “Madurez Organizacional”
Similar al SW-CMM
Provee una única clasificación que facilita
comparaciones entre organizaciones.
Provee una secuencia probada de mejoras.
6 Niveles de 0 a 5
Definidos por cada Áreas de Proceso.
Niveles indican “Capacidad” de un
Área de Proceso.
Similar al EIA/IS-731
Permite comparaciones sobre la base
de cada AP.
Permite elegir el orden de las mejoras.
 CMMI - Roles - Grupos

Tamaño de la Organización

Rol

Grupo
Lo importante es que exista alguien responsable de cubrir las
actividades de cada uno de los roles o grupos.
CMMI – Representación por Etapas
CMMI: Niveles de la Representación por Etapas
Productividad
• foco en la mejora de procesos y Calidad
5 Optimizado
Cuantita-
• procesos medidos y controlados
4 tivamente
Administrado
• procesos caracterizados por la organización
3 Definido • son proactivos
• procesos caracterizados por proyectos
2 Administrado
• es a menudo reactiva
• procesos impredecibles
1 Inicial
• pobremente controlado
• reactivo Riesgo
Áreas de Proceso por Nivel para CMMI V 1.3
➢ Administración de Performance Organizacional
Optimizado ➢Análisis Causal y Resolución.

Cuantitativamente ➢ Performance del Proceso Organizacional

➢ Desarrollo de Requerimientos ➢ Gestión Cuantitativa del Proyecto
Administrado ➢ Solución Técnica
➢ Integración de Producto
➢ Verificación
➢ Validación
➢ Foco en el Proceso Organizacional
Definido
➢ Definición del Proceso Organizacional
➢ Capacitación Organizacional
➢ Administración Integrada de Proyectos
➢ Administración de Riesgos
➢ Análisis y Resolución de Decisiones
➢ Administración de Requerimientos.
➢ Planeamiento de Proyectos.
➢ Monitoreo y Control de Proyectos.
Administrado
➢ Administración de Acuerdo con el Proveedor.
➢ Medición y Análisis
➢Aseguramiento de Calidad del Proceso y del Producto.
➢ Administración de Configuración.
CMMI – DEV V1.3
Nivel Categoría
Administración de Proyectos Soporte Administración de Procesos Ingeniería

5 ▪ Análisis y Causal y Resolución ▪ Administración de

Optimizado
(CAR) Performance Organizacional
(OID)

4 ▪ Administración Cuantitativa ▪ Performance del Proceso

Cuantitativamente
del Proyecto (QPM) Organizacional (OPP)
Administrado

3 ▪ Administración de ▪Análisis y Resolución de Decisión ▪ Definición del Proceso • Desarrollo de

Definido
Riesgos (RSKM) (DAR) Organizacional (OPD) Requerimientos (RD)
▪Administración ▪ Foco en el Proceso • Solución Técnica (TD)
Integrada de Organizacional (OPF) • Integración de Producto (PI)
Proyectos (IPM) ▪ Capacitación Organizacional
(OT) • Verificación (VER)
• Validación (VAL)

2 ▪Administración ▪ Aseguramiento de calidad de

Administrado
de Requerimientos Proceso y de Producto (PPQA)
(REQM) ▪ Administración de
▪Planificación de Configuración (CM)
Proyectos (PP) ▪ Medición y Análisis (MA)
▪ Monitoreo y
Control de
Proyectos (PMC)
▪ Administración de
Acuerdo con el
Proveedor (SAM)

1 Procesos sin definir o improvisados

Inicial
Calidad en el Software
Modelos para crearlos

Modelos para mejorarlos

Modelos para evaluarlos

Proceso

Revisiones Técnicas
Técnicas y
Herramientas
Auditorías

Proyecto
Revisiones
Técnicas
Para
Aseguramiento
de Calidad
Modelos para medirlos Técnicas y
Auditorías (De
Configuración)
Herramientas

Para Control de
Producto Calidad
Testing
Puntos Claves

El software puede analizarse desde varias perspectivas: como

proceso, como producto … la calidad también.
La calidad del software es difícil de medir.
El software como proceso es el fundamento para mejorar la
calidad.
Trabajar con calidad es más barato que hacerlo sin calidad.

5
2
Puntos Claves

• La mejora de procesos exitosa requiere compromiso

organizacional y cambio organizacional.
• Existen varios modelos disponibles para dar soporte a
los esfuerzos de mejora.
• La mejora de procesos en el software ha demostrado
retornos de inversión sustanciales.
5
3
Y lo Ágil ???
 Uniendo los dos
mundos…se puede?
Ágil
CMMI
CMMI cara a cara con Ágil Referencias:
• “Nivel 1” Verde : Da soporte,
Negro: Neutral,
▫ Identificar el alcance del trabajo
Rojo: Desigual
▫ Realizar el trabajo

• “Nivel 2”
▫ Política Organizacional para planear y ejecutar
▫ Requerimientos, objetivos o planes
▫ Recursos adecuados
▫ Asignar responsabilidad y autoridad
▫ Capacitar a las personas
▫ Administración de Configuración para productos de trabajo elegidos
▫ Identificar y participar involucrados
▫ Monitorear y controlar el plan y tomar acciones correctivas si es necesario
▫ Objetivamente monitorear adherencia a lo procesos y QA de productos y/o servicios
▫ Revisar y resolver aspectos con el nivel de administración más álto
CMMI cara a cara con Ágil Referencias:
Verde : Da soporte,
Negro: Neutral,
• “Nivel 3” Rojo: Desigual
▫ Mantener un proceso definido
▫ Medir la performance del proceso

• “Nivel 4”
▫ Establecer y mantener objetivos cuantitativos para el proceso
▫ Estabilizar la performance para uno o más subprocesos para determinar su
habilidad para alcanzar logros
• “Nivel 5”
▫ Asegurar mejora continua para dar soporte a los objetivos
▫ Identificar y corregir causa raíz de los defectos
Hipótesis
• Tolerancia de CMMI a Ágil
▫ Hay áreas de proceso que:
 Hay soporte,
 Otras Neutrales,
 Otras en conflicto
▫ Soporte a evaluación en un ambiente Ágil

• Tolerancia de Agile a CMMI

▫ Está la puerta abierta???
▫ Es posible???
“CAOS” “LEY”
“CREATIVIDAD” “DISCIPLINA”
Diferencias
• “Valores
CMMI MÉTODOS ÁGILES
esenciales” →
→ Medir y mejorar el proceso →
→ Respuestas a clientes

[Mejores Procesos →
→ Mínima sobrecarga

Mejor Producto] →
→ Refinamiento de Requerimientos

- Metáforas
- Casos de negocio

→
→ Características de las personas →
→ Características de las personas

- Disciplinados - Comfortable
- Siguen reglas - Creative
- Aversión al riesgo - Risk Takers

→
→ Comunicación →
→ Comunicación

- Organizacional - Person to Person

- Macro - Micro

→
→ Gestión de Conocimiento →
→ Gestión de Conocimiento

- Activos de proceso - Personas

Diferencias
CMMI MÉTODOS ÁGILES
• “Características”

→
→ Mejora Organizacionalmente →
→ Mejora en el Proyecto

-Uniformidad - Tradición Oral

-Nivelación - Innovación

→
→ Capacidad/Madurez →
→ Capacidad/Madurez

- Éxito por Predictibilidad - Éxito por darse cuenta de oportunidades

→
→ Cuerpo de Conocimiento →
→ Cuerpo de Conocimiento
- Cruzando dimensiones - Personal
- Estandarizado - Evolucionando
- Temporal
•-

→
→ Reglas de Atajo →
→ Reglas de Atajo

- Desalentadas - Alentadas
Diferencias
CMMI MÉTODOS ÁGILES
• Características”
→
→ Comités →
→ Individuos

→
→ Confianza del Cliente →
→ Confianza del Cliente

- En la Infraestructura del Proceso - Sw funcionando, Participantes

→
→ Cargado al frente →
→ Conducido por Pruebas

- Mover a la derecha - Mover a la izquierda

→
→ Alcance de la vista →
→ Alcance de la vista
[Involucrado, Producto] [Involucrado, Producto]

- Amplio - Pequeño
- Inclusivo - Focalizado
- Organziacional

→
→ Nivel de Discusión →
→ Nivel de Discusión

- Palabras - Trabajo en mano

- Definiciones
- Duradero
- Exhaustivo
Diferencias
• Enfoque
CMMI MÉTODOS ÁGILES

→
→ Descriptivo →
→ Prescriptivo

→
→ Cuantitativo →
→ Cualitativo

- Número científicos y duros - Conocimiento tácito

→
→ Universalidad →
→ Situacional

→
→ Actividades →
→ Producto

→
→ Estratégico →
→ Táctico

→
→ “¿Cómo lo llamaremos?” →
→ “Sólo hazlo!”

→
→ Gestión de Riesgos →
→ Gestión de Riesgos

- Proactiva - Reactiva
Diferencias
CMMI MÉTODOS ÁGILES

→
→ Foco de Negocio →
→ Foco de Negocio

• “Foco” - Interna
- Reglas
- Externo
- Innovación

→
→ Predictibilidad →
→ Performance

→
→ Estabilidad →
→ Velocidad
Similitudes
• Meta: Organizaciones de alto desempeño
• Ambas planean
• Ambas son CMMs (Consultant Money Makers)
• Ambas tienen reglas [Reglas = Requerimientos del proceso]
▪ La violación tiene serias repercusiones
▪ ‘SEPG’ (Grupo de proceso de ingeniería de software) & ‘Política
de Proceso’
• Ninguno es completo
• No nuevas ideas
▪ Basadas en la experiencia
• Ninguno es aplicable a “cualquier proyecto”