ASEGURAMIENTO DE LA CALIDAD DEL

SOFTWARE

F.Javier Zarazaga Soria

Proyectos

Departamento de Informtica e Ingeniera en Sistemas

ndice

Introduccin
Plan de aseguramiento de la calidad del
software
Estndares
Revisiones y auditorias
Medidas de calidad del software
Normas de calidad ISO 9000 y CMMI
La funcin del proyecto

Gestin de la Calidad
Control
Cierre
del Proyecto
Gestin del Proyecto
Control

Gestin de Configuraciones

Verificacin y Validacin

Actividades de desarrollo:
o Anlisis
o Diseo
o Implementacin
Inicio del . Fin del
Proyecto Proyecto

2 de mar de 2010
Problemas de calidad del software (I)

Los requisitos se cambian durante el desarrollo del

proyecto
Aparecen nuevos datos que eran desconocidos
El cliente no se involucra en el proyecto. No hay
forma de que apruebe nada
Cada analista o programador trabaja a su modo, no
hay manera de entender ni reusar nada
Nunca encontramos las versiones y ficheros que
buscamos tras finalizar el proyecto
Al final las prisas, y los problemas en las pruebas
Los cambios rpidos de ltima hora generan nuevos
problemas
Problemas de calidad del software (II)

No podemos valorar como de bueno es un

producto
No se aprovecha la experiencia de un
proyecto para hacer el siguiente
Hay que sistematizar el proceso de
desarrollo, pero evitar la burocracia
(paradoja)
No sabemos que hacer para mejorar el
desarrollo
Se quiere implantar un sistema de calidad,
pero faltan conocimientos, experiencia y
recursos
...
Calidad del proceso y del producto
La calidad del proceso y la del producto
estn muy estrechamente relacionadas
Se requiere normalmente un buen proceso
para producir un buen producto
Para bienes de manufactura, el proceso es el
principal determinante de la calidad
Para diseos, tambin estn involucrados
otros factores Desarrollo
tecnolgico

Calidad del Calidad del producto Calidad del

proceso personal
Coste, tiempo
y calendario
Calidad basada en el proceso, ciclo PDCA

Ciclo PDCA (Plan Do Check Act)

PLANIFIQUE lo que quiere realizar
REALICE lo que planific
COMPRUEBE los resultados de su accin
ACTE para modificar lo que hace y planificar con
el fin de asegurar los mejores resultados
Desarrollar Valorar la calidad
Definir el proceso
el producto del producto

Calidad Estandarizar el
Mejorar el proceso No Si
OK proceso
 Ciclo de mejora continua de Deming
Objetivos y
Estrategias

PELIGRO!! PELIGRO!!
Mejora sin Objetivos sin
implantar PLANIFICAR mtodos

Mantener y CAMBIO Sistemas

mejorar para la
mediante el DE
ACTUAR CULTURA REALIZAR gestin de
trabajo en procesos
equipo

VERIFICAR
PELIGRO!! PELIGRO!!
Acumulacin de Burocracia y
informacin recogida sin falta de
objetivos indicadores
Medida de resultados
Recogida de datos y anlisis
mediante tcnicas y
herramientas de apoyo

Fuente: Oakland, J., "Total Quality Management" (2 ed.), Butterworth-Heinemann, Oxford (UK), 1993.
 Calidad del SW y garanta de calidad
Garanta de calidad:

Modelo sistemtico y bien planificado de todas las acciones

necesarias para proporcionar la adecuada seguridad de que
el elemento o producto responde a los requerimientos tcnicos equipamiento
establecidos instalaciones?
[IEEE std 730-1989]
cdigo
procedimientos manuales de usuario
y documentos tcnicos
estndares

requisitos producto
del proceso de desarrollo software
usuario

Calidad del software:

Totalidad de caractersticas de un producto software que tienen

que ver con su capacidad para satisfacer las necesidades
del cliente
[IEEE std 730-1989]
Actividades de gestin de calidad

Aseguramiento de calidad
Establecer procedimientos y estndares de calidad para
la organizacin
Actividades de aseguramiento de la calidad: proceso de
verificar que estos estndares son aplicados
Planificacin de la calidad
Seleccionar procedimientos y estndares aplicables
para
proyectos particulares y modificar estos cuando se
requiera
Control de calidad
Asegurar que los procedimientos y estndares son
seguidos por el equipo de desarrollo de software
 Beneficios de un programa de ACS
Beneficio principal: asegurar a la gerencia que el proceso
establecido oficialmente est siendo realmente
implementado.
Objetivos del ACS:
Mejorar la calidad del software monitorizando apropiadamente
el software y el proceso de desarrollo que lo produce
Asegurar la completa concordancia con los estndares y
procedimientos establecidos para el software y el proceso de
desarrollo
Asegurar que cualquier inadecuacin en el producto, el
proceso, o los estndares son puestos en conocimiento de la
gerencia para que dichas inadecuaciones puedan ser resueltas
ACS NO ES responsable de producir productos de calidad o
hacer planes de calidad (estas son funciones de desarrollo)
ACS ES responsable de comprender los planes, verificar su
ejecucin y monitorizar las prestaciones de las tareas
individuales
Ejemplos de elementos a comprobar (I)

ACS debe planificar las revisiones lo antes

posible dentro del proyecto
Criterios de seleccin para la planificacin
del ACS: riesgo
reas comunes de riesgo:
novedad, complejidad, capacidad y experiencia
del personal, procedimientos manuales y
madurez de la organizacin
 Ejemplos de elementos a comprobar (II)
El personal de ACS debe concentrarse en comprobar los elementos
que tienen
el gran
proyecto se influencia
encuentra en la calidad del producto:
los test se encuentran especificados
organizado adecuadamente y con
y llevados a cabo rigurosamente;
un ciclo de vida apropiado;
los problemas son registrados y
los miembros del equipo de
rastreados;
desarrollo tienen tareas y
responsabilidades definidas; los proyectos utilizan herramientas,
tcnicas y mtodos adecuados;
estn implementados los planes
de documentacin; el software es almacenado en
bibliotecas controladas;
la documentacin contiene lo que
debe contener; el software es almacenado a salvo y
con seguridad;
se han seguido estndares de
documentacin y codificacin; software de suministradores externos
cumple con los estndares aplicables;
se han observado estndares,
prcticas y convenciones; se guardan registros apropiados de
todas las actividades;
se han recogido y utilidado datos
de medida para mejorar productos el personal est formado
y procesos; apropiadamente;
tienen lugar revisiones y estn minimizados los riesgos del
auditoras y son conducidas proyecto.
adecuadamente;
Diferencias entre ACS y VVS

ACS y VVS son actividades de revisin en el proyecto

Estandares
Planes ACS
Informes
Revisar productos de ACS
de salida frente a
estndares y planes

Productos Productos
de Actividad de desarrollo de salida
entrada

VVS
Informes
Revisar productos de de VVS
salida frente a
productos de entrada

Revisin completa NO es posible

depende del tipo de proyecto
p.e. software crtico de seguridad necesita revisiones
ms rigurosas
Plan de aseguramiento de la calidad
Plan de Aseguramiento
de la Calidad del Software

Documenta los planes para las actividades de

asfd a sf asdf asdf as df as df as dfasdf asf asfd f
asdf asdfasdfa sdf asdf asdf asdf asd fs dfff fadsfa
asdfasdf asdfasdf asdffsd asdf asdf asdf asdf asd
as df sadf asdf asdfsdf asdfasdf asdfasdf asdffsd
asdf asdf asd f as fasdf as df sadf asdf asdfsdf a
asdfasdf asdffsd asdf asdf asdf asdf asd f as fah

ACS
sadf asdf asdfsdf asdfasdf asdfasdf asdffsd asdf
asdf asdf asd f as fasdf as df sadf asdf asdfsdf
asdfasdf asdfasdf asdffsd asdf asdf asdf asdf a
as fasdf as df sadf asdf asdfsdf asdfasdf asdfas
asdffsd asdf asdf asdf asdf asd f as fasdf as df s
asdf asdfsdf asdfasdf asdfasdf asdffsd asdf asdf
asdf asdf asd f as fasdf as df sadf asdf asdfsdf

ESA exige un plan para cada fase de

asdfasdf asdfasdf asdffsd asdf asdf asdf asdf asd
as fasdf as df sadf asdf asdfsdf asdfasdf asdfasdf
asdffsd asdf asdf asdf asdf asd f as fasdf as df sa
asdf asdfsdf asdfasdf asdfasdf asdffsd asdf asdf
asdf asdf asd f as fasdf as df sadf asdf asdfsdf

desarrollo
RS, DA, DD, TR

El tamao y contenido del PACS debe reflejar

la complejidad del proyecto
Tratar de no repetir informacin explicada en
otros documentos

Responsabilidades
Producido por el personal de ACS
Revisado por el personal a quien informa el
personal del ACS
 PACS: Contenido (ESA)

Introduccin
Estndares, prcticas, convenciones y mtricas
Revisiones y auditorias
Test
Notificacin de problemas y acciones
correctivas
Herramientas, tcnicas y mtodos
Control de cdigo, medios y suministradores
Formacin
Gestin de riesgos Se puede insertar material adicional en apndices
Si nada en una seccin poner: No aplicable
PACS - Estndares

Identifican los estndares, prcticas, convenciones y

mtricas utilizadas para especificar calidad del software
Explican cmo ACS revisar la calidad requerida
Normalmente son referencias a otros planes o
documentos del proyecto o de la organizacin
Para la ESA se clasifican en:
Estndares de documentacin
Estndares de diseo
Estndares de codificacin
Estndares de comentarios
Estndares de test y prcticas
Mtricas seleccionadas de aseguramiento de calidad
Establecimiento de cmo se va a monitorizar la conformidad
Todos ellos deben ser conformes con las restricciones
impuestas por la ESA (PSS-05-0)
Estndares de software

Son clave para una gestin de calidad efectiva

Pueden ser internacionales, nacionales, de la
organizacin o del proyecto
Los estndares del producto definen caractersticas
que deberan exhibir todos los componentes, p.e. un
estilo de programacin comn
Los estndares del proceso definen como el proceso
de software debe ser establecido
Ejemplos: Ficha de revisin de diseo Conduccin de revisin del diseo

Estndares de nombrado de documentos Sometimiento de documentos a la GC

Formato de encabezamiento de procedimientos Proceso de release de versiones

Estndar de estilo de programacin en Ada Proceso de aprobacin del plan del proyecto

Formato del plan del proyecto Proceso de control de cambios

Ficha de requerimiento de cambio Proceso de registro de tests

 Importancia y problemas de los estnd.
Importancia de los estndares
Encapsulacin de las buenas
prcticas de la organizacin.
Evita la repeticin de
pasados errores.
Entorno para el proceso de
AC - involucra la revisin de
la conformidad con el
estndar.
Proporciona continuidad.
Nuevo personal puede
comprender la organizacin
comprendiendo los
estndares aplicados
Problemas con los estndares
No visto como relevante y
puesto al da por los
ingenieros de software.
Involucra demasiada
burocracia de relleno de
fichas.
No soportado por
herramientas de software
de forma que se exige un
tedioso trabajo manual
para mantener los
estndares.
Desarrollo de los estndares

Involucrar a los usuarios (desarrolladores) en su

desarrollo. Los ingenieros deberan comprender
las razones subyacentes en el estndar.
Revisar los estndares y su uso de forma regular.
Los estndares pueden quedar desfasados
rpidamente y esto reduce su credibilidad entre
sus usuarios.
Estndares detallados deberan tener alguna
herramienta de soporte. El excesivo trabajo de
oficina es la queja ms significativa contra los
estndares.
Ej. de estnd.: estndares de doc.

Particularmente importantes
Son la manifestacin tangible del software
Estndares del proceso de documentacin
Cmo los documentos van a ser
desarrollados, validados y mantenidos
Estndares de documentos
Se refiere al contenido, estructura y
apariencia de los documentos
Estndares de intercambios de documentos
Cmo los documentos van a ser
almacenados, e intercambiados entre
diferentes sistemas
de documentacin
Estndares del proceso de doc.

Estado 1: Creacin

Incorporar
Crear borrador Revisin del Reescribir el
comentarios de
inicial borrador borrador
la revisin

Documento aprobado

Estado 2: Refinamiento
Correccin de
Producir el Revisar el
las pruebas
borrador final borrador final
del texto

Documento aprobado

Estado 3: Produccin

Producir las
Composicin Revisin de la Imprimir las
impresiones
del texto composicin copias
maestras
 Estndares de documentos

Estndares de documentos
De identificacin
cmo se les ponen identificadores nicos
De estructura
De presentacin
fuentes y estilos, uso de logos, etc.
De actualizacin
define cmo se reflejan en el documento los cambios con
respecto a versiones previas
Estndares de intercambio de doc.
Estndares de intercambio de documentos
Los documentos son producidos utilizando diferentes
sistemas en diferentes computadores
Estndares de intercambio permiten que las versiones
electrnicas sean intercambiadas, enviadas por correo
electrnico,
Necesidad de archivado. El tiempo de vida de los
procesadores de textos puede ser mucho menor que el
del software a documentar
PACS - Revisiones y auditoras

Mtodo principal para validar la calidad de un proceso o

de un producto
Examen de parte o todo de un proceso o sistema y su
documentacin para encontrar problemas potenciales
Una persona o grupo de personas examina parte o todo
un sistema de software y su documentacin asociada
los equipos de revisin deben ser relativamente pequeos
y las revisiones deberan ser pequeas
Los comentarios hechos durante la revisin deberan ser
clasificados en:
Sin accin, Reparar, Reconsiderar diseo completo
La revisin debe ser registrada y los registros mantenidos
El software o los documentos pueden ser firmados en
la revisin lo que significa que gestin ha aprobado el
progreso al siguiente estado de desarrollo
PACS - Mtricas de calidad del software

Mtrica de software: es cualquier tipo de medida

relacionada con un sistema de software, proceso o
documentacin relacionada, p.e.:
lneas de cdigo en un programa
ndice Fog (mide el grado de legibilidad de un manual de
producto)
nmero de personas-da para desarrollar un componente
nmero de fallos detectados en un producto de software
entregado
Permiten cuantificar el software y el proceso de
desarrollo de software
La calidad del software es el grado en que posee una
combinacin deseada de atributos
Metodolog. de mtricas de calidad de SW

IEEE Standard for a Software Quality Metrics

Methodology, ANSI/IEEE Std 1061-1992
Establecer los requisitos de calidad del software
se selecciona, prioriza y cuantifica una lista de
requisitos de calidad
sern usados para guiar y controlar el desarrollo
del sistema y en la entrega para comprobar si el
sistema rene los requisitos de calidad
especificados en el contrato
Identificar mtricas de calidad del software
Metodolog. de mtricas de calidad de SW

Implementar las mtricas de calidad del software

se encuentran o desarrollan herramientas, se
recolectan los datos, y se aplican las mtricas en
cada fase del desarrollo del software
Analizar los resultados de las mtricas de calidad del
software
se analizan los resultados de las mtricas y se
notifican para ayudar en el control del desarrollo y
valorar el producto final
Validar las mtricas de calidad del software
los resultados estimados de las mtricas se
comparan con los reales para determinar si las
mtricas predictivas reflejan de forma precisa sus
factores asociados
Mtricas de calidad y atributos del SW

Existe relacin entre lo que podemos medir y

lo que queremos conocer
Puede ser difcil de relacionar lo que
podemos medir con los atributos de calidad
deseables Nmero de prmetros CALIDAD DE SOFTW.
del procedimiento
Mantenibilidad
Complejidad FACTOR i FACTOR n
ciclomtica
Fiabilidad
Tamao del programa CRITERIO i CRITERIO n
en lneas de cdigo
Portabilidad
MTRICAS
Nmero de mensajes
de error
Usabilidad
Longitud del manual
de usuario
Ejemplos de factores
Factor Descripcin

Eficiencia Atributo que mide la relacin entre el nivel de prestaciones y la cantidad de

recursos utilizados bajo condiciones dadas.

Funcionalidad Atributo que mide la existencia de ciertas propiedades y funciones que

satisfacen necesidades de los usuarios dadas o implicadas.

Mantenibilidad Atributo que mide el esfuerzo necesario para modificaciones especficas.

Portabilidad Atributo que mide la habilidad del software para ser transferido de un
entorno a otro.

Fiabilidad Atributo que mide la capacidad del software para mantener su nivel de
prestaciones bajo condiciones dadas para un periodo de tiempo
establecido.

Usabilidad Atributo que mide el esfuerzo necesario para utilizarlo .

Ejemplos de subfactores 1
Factor Subfactor Descripcin

Eficiencia Economa de Capacidad del software para realizar funciones especficas bajo condiciones
tiempo establecidas o implicadas, dentro de adecuados mrgenes de tiempo.

Economa de Capacidad del software para realizar funciones especficas bajo condiciones
recursos establecidas o implicadas, utilizando cantidades apropiadas de recursos.

Funcionalidad Completitud Grado en el que el software posee las necesarias y suficientes funciones para
satisfacer las necesidades del usuario.

Correccin Grado al que todas las funciones de software estn especificadas.

Seguridad Grado al que el software puede detectar y prevenir fugas de informacin,

prdidas de informacin, utilizacin ilegal y destruccin de recursos del
sistema.

Compatibilidad Grado en que el nuevo software puede ser instalado sin cambiar entornos y
condiciones que fueron preparadas para el nuevo software.

Interoperabilidad Grado en el que el software puede ser conectado y operado fcilmente con
otros sistemas.
Ejemplos de subfactores 2
Factor Subfactor Descripcin

Mantenibilidad Correctibilidad Grado de esfuerzo requerido para corregir errores en el software y solucionar
las reclamaciones de los usuarios.

Expandabilidad Grado de esfuerzo requerido para mejorar o modificar la eficiencia o las

funciones del software.

Testabilidad Esfuerzo requerido para hacer el test del software

Portabilidad Independencia Grado en el que el software no depende de entornos de hardware especficos.

del hardware

Independencia Grado en el que el software no depende de entornos de software especficos.

del software

Instalabilidad Esfuerzo requerido para ajustar el software a un nuevo entorno.

Reusabilidad Grado en el que el software puede ser reusado en aplicaciones distintas de la

original.
Ejemplos de subfactores 3
Factor Subfactor Descripcin

Fiabilidad Nodeficiencia Grado en el que el software no contiene errores indetectados.

Tolerancia a Grado en el que el software continuar funcionando sin producirse un error de

errores sistema que pueda causar dao a los usuarios. Tambin, el grado en el que el
software incluye funciones para operacin degradada y recuperacin.

Disponibilidad Grado en el que el software permanece operable en presencia de fallos de

sistema.

Usabilidad Comprensibilidad Cantidad de esfuerzo de usuario requerido para comprender el software.

Facilidad de Grado para el que el esfuerzo de usuario requerido para comprender el

aprendizaje software est minimizado.

Operabilidad Grado en el que la operacin del software encaja con el propsito, el ambiente
y las caractersticas psicolgicas de los usuarios incluyendo factores
ergonmicos como color, forma, sonido, etc.

Comunicatividad Grado en el que el software est diseado de acuerdo a las caractersticas

psicolgicas de los usuarios.
Recoleccin de datos

Un programa de mtricas debe estar basado en un

conjunto de datos del producto y del proceso
Los datos deben ser recolectados inmediatamente y,
si es posible, automticamente
Exactitud de los datos:
No recoger datos innecesarios.
Las preguntas a contestar deben ser decididas
previamente y los datos requeridos deben estar
identificados
Informar al personal porque estan siendo recogidos los
datos.
No deben formar parte de la evaluacin del personal
No confiar los datos a la memoria
Recolectar los datos cuando son generados, no despus
de que el proyecto ha finalizado
Anlisis de los resultados de las medidas

El anlisis incluye:
Interpretar los resultados
Identificar la calidad del software
Hacer predicciones de calidad del software
(durante el desarrollo)
Asegurar la conformidad con los requisitos

Observaciones:
No siempre es obvio saber que significan los
datos. Analizar los datos recogidos es muy difcil
Estadsticos profesionales deberan ser
consultados si estn disponibles
ISO 9001

Conjunto de estndares internacionales para la

gestin de calidad
Aplicables a un gran rango de organizaciones desde
fabricacin a industrias de servicio
ISO 9001 es aplicable a organizaciones que disean,
desarrollan y mantienen productos
Elaborada por el Comit Tcnico ISO/TC176 de ISO
La ISO 9001 es un modelo genrico de proceso de
calidad que debe ser instanciado para cada
organizacin
ISO 9000 son los fundamentos y el vocabulario
empleado en la norma ISO 9001 (v. 2005)
ISO 9001: Historia

Tiene origen en la norma BS 5750, publicada

en 1979 por British Standards Institution
Cuarta versin: la actual ISO 9001:2008
(15/11/2008)
Tercera versin: ISO 9001:2000 (15/12/2000)
Segunda versin: ISO 9001:94 - ISO 9002:94 -
ISO 9003:94 (01/07/1994)
Primera versin: ISO 9001:87 - ISO 9002:87 -
ISO 9003:87 (15/03/1987)
ISO 9001: Evolucin

1 y 2 versin de ISO 9001 => 3 normas

ISO 9001 --> organizaciones con diseo de producto
ISO 9002 --> organizaciones sin diseo de producto
pero con produccin/fabricacin.
ISO 9003 --> organizaciones sin diseo de producto
ni produccin/fabricacin (comerciales).
3 versin unifica en un nico estndar, sobre
el cual se realizan posteriormente las
exclusiones.
ISO 9001: Evolucin

Proceso de fabricacin
Requisitos Desarrollo Inspeccin Mantenimiento
del del producto Produccin y Instalacin y
usuario test servicio

Diseo ISO 9003

ISO 9002

ISO 9001
Diseo Implementacin

Requisitos Diseo Diseo Mantenimiento

del alto bajo Codificacin Test Instalacin y
usuario nivel nivel servicio

Proceso de desarrollo de software

ISO 9000-3
Guidelines for the application of ISO 9001 to
the development, supply and maintenance of
software
Por qu evoluciona?

Crtica al modelo de 20 elementos:

No til para pequeas empresas
Muy manufacturera
Muchas normas de gua

Versiones tres y cuatro:

Gestin por procesos
Mas all de la certificacin y hacia el TQM
Facilitar el uso de sistemas mltiples de gestin
Objetivos de la evolucin

Satisfaga las necesidades de las partes

interesadas
Utilizables por todo tamao de organizaciones
Utilizable por todos los sectores
Simple y fcil de entender
Compatible con otros sistemas
Conexin entre la gestin de la calidad y los
procesos de negocios
Principios de la norma

1. Enfoque al cliente
2. Liderazgo
3. Participacin del personal
4. Enfoque basado en los procesos
5. Enfoque de sistema para la gestin
6. Mejora continua
7. Enfoque basado en hechos para la toma de
decisin
8. Relaciones mutuamente beneficiosas con
el proveedor
Estructura de la norma

1. Guas y descripciones generales

2. Normativas de referencia.
3. Trminos y definiciones.
4. Sistema de gestin
contiene los requisitos generales y los requisitos
para gestionar la documentacin.
5. Responsabilidades de la Direccin
6. Gestin de los recursos
7. Realizacin del producto
8. Medicin, anlisis y mejora
5. Responsabilidades de la Direccin

Requisitos que debe cumplir la direccin de la

organizacin:
definir la poltica, asegurar que las
responsabilidades y autoridades estn definidas,
aprobar objetivos, el compromiso de la direccin
con la calidad, etc.
1. Requisitos generales
2. Requisitos del cliente
3. Poltica de calidad
4. Planeacin
5. Responsabilidad, autoridad y comunicacin
6. Revisin gerencial
6. Gestin de los recursos

la Norma distingue 3 tipos de recursos sobre

los cuales se debe actuar: RRHH,
infraestructura, y ambiente de trabajo
1. Requisitos generales
2. Recursos humanos
3. Infraestructura
4. Ambiente de trabajo
 7. Realizacin del producto

Requisitos puramente productivos, desde la

atencin al cliente, hasta la entrega del
producto o el servicio.
1. Planeacin de la realizacin del producto y/o
servicio
2. Procesos relacionados con el cliente
3. Diseo y desarrollo
4. Compras
5. Operaciones de produccin y servicio
6. Control de dispositivos de medicin, inspeccin y
monitoreo
 8. Medicin, anlisis y mejora

equisitos para los procesos que recopilan

informacin, la analizan, y que actan en
consecuencia.
Mejorar continuamente la capacidad de la
organizacin para suministrar productos que
cumplan los requisitos.
la organizacin busca sin descanso la satisfaccin
1. Requisitos generales
2. Seguimiento y medicin
3. Control de producto no conforme
4. Anlisis de los datos para mejorar el desempeo
5. Mejora
ISO 9001 - Certificacin

Los estndares y procedimientos de calidad deberan

estar documentados en un manual de calidad de la
organizacin
Organizaciones especializadas pueden certificar que
un manual de calidad de la organizacin es conforme
con los estndares ISO 9001
Los clientes estan incrementando la demanda de que
los sumnistradores dispongan de la certificacin ISO
9001
ISO 9000 y gestin de calidad

ISO 9000
quality models

instantiated as

documents
Organization Organization
quality manual quality process

is used to develop instantiated as

Project 1 Project 2 Project 3 Project quality

quality plan quality plan quality plan management

Supports
Sistema de calidad

Establecer, documentar y mantener al da un

sistema de calidad
Preparar e implantar procedimientos
documentados coherentes con los requisitos
ISO y con la poltica de calidad
Planificar la forma en la que se han de
cumplir los requisitos del sistema de calidad
El SEI de CMU

SEI (Software Engineering Institute), instituto

fundado por el US DoD (Dept. Of Defense) asociado
con la Universidad de Carnegie Mellon
Su misin es promocionar la transferencia de tecnologa
de software particularmente a contratistas de defensa
Su trabajo ha tenido gran influencia en la mejora del
proceso
CMMI

Capability Maturity Model Integration (Integracin del

Modelo de Capacidad y Madurez)
Modelo para la mejora o evaluacin de los procesos de
desarrollo y mantenimiento de sistemas y productos de
software.
Desarrollado por el Instituto de Ingeniera del Software
de la Universidad Carnegie Mellon (SEI), y publicado en
su primera versin en enero de 2002.
Es empleado para guiar las mejoras de procesos durante
el desarrollo de un proyecto, un departamento o hasta
una organizacin
Origen del CMMI (I)

Durante los aos 90 SEI desarroll modelos

especficos para la mejora y medicin de la
madurez en varias reas:
CMM-SW: CMM for software
P-CMM: People CMM.
SA-CMM: Software Acquisition CMM.
SSE-CMM: Security Systems Engineering CMM.
T-CMM: Trusted CMM
SE-CMM: Systems Engineering CMM.
IPD-CMM: Integrated Product Development CMM.
Origen CMMI (II)

1987 1991 1993 1995 1997 2000 2002

CMMI-SE/SW
First CMM SW-CMM v1.1
Version 1.0
Published Published
Published

Model Refined CMMI-SE/SW/IPPD/A

CMMI Initiative
and Published as Version 1.1
Launched
SW-CMM v1.0 Published

Software Acquisition (SA-CMM),

Systems Engineering (SE-CMM),
Integrated Product Development (IPD-CMM),
Organizational Workforce Capability Development (People CMM)
Developed
Origen del CMMI (III)

CMMI se desarroll para facilitar y simplificar

la adopcin de varios modelos de forma
simultnea.
Su contenido integra y da relevo a la
evolucin de sus predecesores:
CMM-SW (CMM for Software)
SE-CMM (Systems Engineering Capability Maturity
Model)
IPD-CMM (Integrated Product Development)
..sobre CMM (I)
El modelo de Capacidad y Madurez, es un mtodo de
definir y y gestionar los procesos a realizar por una
organizacin.
El modelo de calidad CMM aparece con la necesidad
de mitigar los problemas que se presentan
continuamente al momento de contratar empresas
desarrolladoras de software, por la progresiva
elevacin de costos y desfase de las fechas de
entrega.
Este modelo establece un conjunto de prcticas o
procesos clave agrupados en reas Clave de Proceso
(KPA - Key Process Area).
..sobre CMM (II)
Para cada rea de proceso define un conjunto de buenas
prcticas que habrn de ser:
Definidas en un procedimiento documentado
Provistas (la organizacin) de los medios y formacin
necesarios
Ejecutadas de un modo sistemtico, universal y uniforme
(institucionalizadas)
Medidas
Verificadas
A su vez estas reas de Proceso se agrupan en cinco
"niveles de madurez", de modo que una organizacin que
tenga institucionalizadas todas las prcticas incluidas en
un nivel y sus inferiores, se considera que ha alcanzado
ese nivel de madurez.
..sobre CMM (III)

Los niveles son:

1 - Inicial
2 Repetible
3 - Definido
4 - Gestionado
5 - Optimizado
As es como el modelo CMM establece una medida del
progreso conforme avanza, en niveles de madurez.
Cada nivel a su vez cuenta con un nmero de reas de
proceso que deben lograrse. El alcanzar estas reas se
detecta mediante la satisfaccin o insatisfaccin de
varias metas claras y cuantificables.
Estructura de los CMM (I)

El modelo para software (CMM-SW)

Establece 5 niveles de madurez para clasificar a las
organizaciones, en funcin de qu reas de
procesos consiguen sus objetivos y se gestionan
con principios de ingeniera
Es lo que se denomina un modelo escalonado, o
centrado en la madurez de la organizacin.
Estructura de los CMM (II)

El modelo para ingeniera de sistemas (SE-

CMM)
Establece 6 niveles posibles de capacidad para una
de las 18 reas de proceso implicadas en la
ingeniera de sistemas.
No agrupa los procesos en 5 tramos para definir el
nivel de madurez de la organizacin, sino que
directamente analiza la capacidad de cada proceso
por separado.
Es lo que se denomina un modelo continuo.
Estructura de CMMI

En el equipo de desarrollo de CMMI haba

defensores de ambos tipos de
representaciones.
El resultado fue la publicacin del modelo con
dos representaciones: continua y escalonada.
Son equivalentes, y cada organizacin puede
optar por adoptar la que se adapte a sus
caractersticas y prioridades de mejora.
Representacin continua

La visin continua de una organizacin mostrar la

representacin de nivel de capacidad de cada una
de las reas de proceso del modelo.
Representacin escalonada

La visin escalonada definir a la organizacin

dndole en su conjunto un nivel de madurez del 1 al 5.
reas de proceso

Conjunto de prcticas relacionadas que son

ejecutadas de forma conjunta para conseguir
un conjunto de objetivos
Las reas de proceso que ayuda a mejorar o
evaluar CMMI son 25
Se agrupan en 4 categoras segn su
finalidad:
Gestin de proyectos
Ingeniera
Gestin de procesos
Soporte a las otras categoras
reas de proceso
Componentes (I)
Componentes (II)

Componentes Requeridos
Objetivo genrico: Los objetivos genricos
asociados a un nivel de capacidad establecen lo
que una organizacin debe alcanzar en ese nivel de
capacidad.
Objetivo especfico: Los objetivos especficos se
aplican a una nica rea de proceso y localizan las
particularidades que describen que se debe
implementar para satisfacer el propsito del rea de
proceso.
Componentes (III)

Componentes Esperados
Prctica genrica: Una prctica genrica se aplica a
cualquier rea de proceso porque puede mejorar el
funcionamiento y el control de cualquier proceso.
Prctica especfica: Una prctica especfica es una
actividad que se considera importante en la
realizacin del objetivo especfico al cual est
asociado.
Las prcticas especficas describen las
actividades esperadas para lograr la meta
especfica de un rea de proceso
Componentes (III)

Componentes Informativos (I)

Propsito
Notas introductorias
Nombres
Tablas de relaciones prctica - objetivo
Prcticas
Productos tpicos
Sub-prcticas: Una sub-prctica es una descripcin
detallada que sirve como gua para la interpretacin
de una prctica genrica o especifica.
Componentes (IV)

Componentes Informativos (II)

Ampliaciones de disciplina: Las ampliaciones
contienen informacin relevante de una disciplina
particular y relacionada con una prctica
especifica.
Elaboraciones de prcticas genricas: Una
elaboracin de una prctica genrica es una gua de
cmo la prctica genrica debe aplicarse al rea de
proceso.
Niveles de Capacidad (representacin continua)

Los 6 niveles definidos en CMMI para medir la capacidad de

los procesos son:
0.- Incompleto: El proceso no se realiza, o no se consiguen sus
objetivos.
1.- Ejecutado: El proceso se ejecuta y se logra su objetivo.
2.- Gestionado: Adems de ejecutarse, el proceso se planifica, se
revisa y se evala para comprobar que cumple los requisitos.
3.- Definido: Adems de ser un proceso "gestionado" se ajusta a
la poltica de procesos que existe en la organizacin, alineada
con las directivas de la empresa.
4.- Cuantitativamente gestionado: Adems de ser un proceso
definido se controla utilizando tcnicas cuantitativas.
5.- Optimizado: Adems de ser un proceso cuantitativamente
gestionado, de forma sistemtica se revisa y modifica o cambia
para adaptarlo a los objetivos del negocio.
 Niveles de Capacidad (representacin continua)

El nivel de capacidad de un rea de un

proceso implementado suele respresentarse
como una barra de progreso
This point
Capability Level

3 represents
a higher level
2 of maturity
than this point
1 in a specific
process area
0

Process Area n 5
Capability

4
Process
3
2
1
0

RM PP PMC etc
Process Area
Niveles de Madurez (representacin escalonada)

Nivel 1: Inicial
No hay proceso
Cada proyecto es un mundo
Estilo de gestin: I did it in my way
Nivel 2: Repetible
Hay planificacin y seguimiento de proyectos
Los proyectos son repetibles
Nivel 3: Definido
El proceso se documenta y estandariza en toda la empresa
Nivel 4: Gestionado
Se realiza una gestin de calidad
Calidad y productividad se miden
Nivel 5: Optimizado
Mejora continua
Niveles de Madurez (representacin escalonada)

5
optimizado
4
gestionado
3
definido
2
repetible
1
inicial
Equivalencia entre representaciones

Para conseguir Nivel de Madurez 2, todas las reas de

proceso asignadas a este nivel deben estar a Nivel de
Capacidad 2 o superior
Para conseguir Nivel de Madurez 3, todas las reas de
proceso asignadas a los niveles 2 y 3 deben estar a
Nivel de Capacidad 3 o superior
Para conseguir Nivel de Madurez 4, todas las reas de
proceso asignadas a los niveles 2, 3 y 4 deben estar a
Nivel de Capacidad 3 o superior
Para conseguir Nivel de Madurez 5, todas las reas de
proceso deben estar a Nivel de Capacidad 3 o superior
SCAMPI (I)

1. Planificacin inicial.
1.1.Desarrollo de un plan.
1.2.Preparacin del equipo
1.3.Informacin a los participantes
1.4. Administrar un cuestionario de evaluacin y
examinar resultados.
1.5.Documento inicial.

2 de mar de 2010
SCAMPI (II)

2. Evaluacinon-site
2.1.Preparacin
2.2. Entrevistas
2.3.Consolidacin de la informacin
2.4. Preparacin y redactado de lo encontrado
2.5.Determinar la clasificacin y presentacin
(opcional)
3. Exposicin de los resultados
3.1.Presentacin al sponsor
3.2.Presentacin al Director de la empresa (opcional)

2 de mar de 2010
SCAMPI (III)
Bibliografa

Mary Beth Chrissis, Mike Konrad, Sandy

Shrum. CMMI: Guidelines for Process
Integration and Product Improvement.
Addison-Wesley. 2006 (2nd edition)
Dennis M. Ahern, Aaron Clouse, Richard
Turner. CMMI Distilled: A Practical
Introduction to Integrated Process
Improvement. Addison-Wesley. 2003 (2nd
edition)

2 de mar de 2010
2 de mar de 2010