Facultad de Ciencias e Ingeniera

CALIDAD DE SOFTWARE
Alumnos:
LEON DOMPER, Carlos
VELA CHUNG, Hilary
Catedrtico:

- Csar Palacios Chvez.

Contenido
Modelo de Capacidad y Madurez........................................................................2
I.

NIVELES DE MADUREZ..............................................................................2

SCAMPI - MTODO ESTNDAR DE EVALUACIN DE CMMI PARA MEJORA DE

PROCESOS.......................................................................................................... 4
I.

OBJETIVOS................................................................................................. 4

II.

CLASES DE MTODOS............................................................................... 5

III.

SCAMPI LEADER APPRAISER...................................................................6

ISO/IEC 15504.................................................................................................... 7
I.

LOS NIVELES DE MADUREZ.......................................................................7

II.

PUNTOS FUERTES Y PUNTOS DBILES.......................................................8

III.

ASPECTOS COMUNES Y COMPARATIVAS DE MODELOS...........................9

INGENIERA DE REQUISITOS.............................................................................11
I.

FASES DE IMPLEMENTACIN...................................................................11

MODELO DE CAPACIDAD Y MADUREZ

El Modelo de Madurez de Capacidades o CMM (Capability Maturity Model), es
un modelo de evaluacin de los procesos de una organizacin. Fue
desarrollado inicialmente para los procesos relativos al desarrollo e
implementacin de software por la Universidad Carnegie-Mellon para el SEI
(Software Engineering Institute).
El SEI es un centro de investigacin y desarrollo patrocinado por el
Departamento de Defensa de los Estados Unidos de Amrica y gestionado por
la Universidad Carnegie-Mellon. CMM es una marca registrada del SEI.
Este modelo establece un conjunto de prcticas o procesos clave agrupados en
reas Clave de Proceso (KPA - Key Process Area). Para cada rea de proceso
define un conjunto de buenas prcticas que habrn de ser:

I.

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

NIVELES DE MADUREZ

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.
Los niveles son:
1. Inicial. Las organizaciones en este nivel no disponen de un ambiente
estable para el desarrollo y mantenimiento de software. Aunque se
utilicen tcnicas correctas de ingeniera, los esfuerzos se ven minados
por falta de planificacin. El xito de los proyectos se basa la mayora de
las veces en el esfuerzo personal, aunque a menudo se producen
fracasos y casi siempre retrasos y sobrecostes. El resultado de los
proyectos es impredecible.
2. Repetible. En este nivel las organizaciones disponen de unas prcticas
institucionalizadas de gestin de proyectos, existen unas mtricas
bsicas y un razonable seguimiento de la calidad. La relacin con
subcontratistas y clientes est gestionada sistemticamente.
3. Definido. Adems de una buena gestin de proyectos, a este nivel las
organizaciones disponen de correctos procedimientos de coordinacin
entre grupos, formacin del personal, tcnicas de ingeniera ms
detalladas y un nivel ms avanzado de mtricas en los procesos. Se
implementan tcnicas de revisin por pares (peer reviews).
4. Gestionado. Se caracteriza porque las organizaciones disponen de un
conjunto de mtricas significativas de calidad y productividad, que se
2

usan de modo sistemtico para la toma de decisiones y la gestin de

riesgos. El software resultante es de alta calidad.
5. Optimizado. La organizacin completa est volcada en la mejora
continua de los procesos. Se hace uso intensivo de las mtricas y se
gestiona el proceso de innovacin.
As es como el modelo CMM establece una medida del progreso, conforme al
avance en niveles de madurez. Cada nivel a su vez cuenta con un nmero de
reas de proceso que deben lograrse. El alcanzar estas reas o estadios se
detecta mediante la satisfaccin o insatisfaccin de varias metas claras y
cuantificables. Con la excepcin del primer nivel, cada uno de los restantes
Niveles de Madurez est compuesto por un cierto nmero de reas Claves de
Proceso, conocidas a travs de la documentacin del CMM por su sigla inglesa:
KPA. Cada KPA identifica un conjunto de actividades y prcticas
interrelacionadas, las cuales cuando son realizadas en forma colectiva
permiten alcanzar las metas fundamentales del proceso. Las KPAs pueden
clasificarse en 3 tipos de proceso: Gestin, Organizacional e Ingeniera.
Las prcticas que deben ser realizadas por cada rea Clave de Proceso estn
organizadas en 5 Caractersticas Comunes, las cuales constituyen propiedades
que indican si la implementacin y la institucionalizacin de un proceso clave
es efectivo, repetible y duradero.
Estas 5 caractersticas son: i) Compromiso de la realizacin, ii) La capacidad de
realizacin, iii) Las actividades realizadas, iv) Las mediciones y el anlisis, v) La
verificacin de la implementacin.
Las organizaciones que utilizan CMM para mejorar sus procesos disponen de
una gua til para orientar sus esfuerzos. Adems, el SEI proporciona formacin
a evaluadores certificados (Lead Assesors) capacitados para evaluar y
certificar el nivel CMM en el que se encuentra una organizacin. Esta
certificacin es requerida por el Departamento de Defensa de los Estados
Unidos, pero tambin es utilizada por multitud de organizaciones de todo el
mundo para valorar a sus subcontratistas de software.
Se considera tpico que una organizacin dedique unos 18 meses para
progresar un nivel, aunque algunas consiguen mejorarlo. En cualquier caso
requiere un amplio esfuerzo y un compromiso intenso de la direccin.
Como consecuencia, muchas organizaciones que realizan funciones de factora
de software o, en general, outsourcing de procesos de software, adoptan el
modelo CMM y se certifican en alguno de sus niveles. Esto explica que uno de
los pases en el que ms organizaciones certificadas existan sea India, donde
han florecido las factoras de software que trabajan para clientes
estadounidenses y europeos.

SCAMPI - MTODO ESTNDAR DE EVALUACIN

DE CMMI PARA MEJORA DE PROCESOS
Para llevar a cabo la evaluacin basada en CMMI el SEI ha diseado el Mtodo
Estndar de Evaluacin de CMMI para Mejora de Procesos (Standard CMMI
Appraisal Method for Process Improvement, SCAMPI), que consiste en una serie
de mtodos formales para la evaluacin del modelo, que pueden usarse para
evaluar:

Si los procesos tal y como estn definidos son adecuados segn los
requisitos de CMMI
Cmo esos procesos se estn desplegando en la organizacin
Cmo los procesos estn institucionalizados en la organizacin

El uso de SCAMPI nos permite:

I.

Comprender mejor el nivel de competencia en ingeniera de una

organizacin, identificando los puntos fuertes y dbiles de sus procesos
actuales.
Relacionar esos puntos fuertes y dbiles con el modelo CMMI.
Priorizar planes de mejora.
Centrarse en las mejoras ms importantes que haya que acometer
segn el nivel de madurez de la organizacin y de los recursos
disponibles.
Obtener para la organizacin su clasificacin en uno de los niveles del
modelo.
Identificar riesgos de desarrollo y adquisicin relativos a las limitaciones
de la organizacin.

OBJETIVOS

Los objetivos de SCAMPI son:

Proveer un mtodo de certificacin comn e integrado capaz de

soportar certificaciones en el contexto de mejoras de procesos internos,
seleccin de proveedores y monitoreo de procesos.
Proveer un mtodo eficiente de certificacin capaz de ser implementado
dentro de restricciones razonables de performance.

Para poder cumplir con el mtodo de evaluacin SCAMPI, el trabajo se debe

organizar en tres fases
1. Planificar y preparar la certificacin: lleva de 3 a 5 meses
2. Conducir la certificacin: ejecucin de la evaluacin y reportes los
resultados preeliminares
3. Reportar los resultados de la certificacin: reportes de los resultados
finales.
Las tareas a realizar dentro del SCAMPI son:
4

1. Desarrollar un plan de certificacin.

2. Determinar los indicadores de implementacin de las prcticas (PIIs)
3. Entrevistas, con los empleados, gerencia y dems participantes.
4. Seleccionar y preparar el equipo de certificacin.
5. Obtener y analizar evidencia objetiva preeliminar
6. Preparar una coleccin de evidencia objetiva.
7. Examinar la evidencia
8. Verificar y validar la evidencia
9. Documentar la evidencia
10.Generar reportes de los resultados de la evaluacin
11.Publicar los resultados de la evaluacin
12.Empaquetar y archivar los instrumentos de certificacin.
Adelantndonos al prximo captulo, podemos decir que la herramienta a
construir podr ser usada como apoyo para ejecutar varias de estas
actividades, como por ejemplo para examinar la evidencia, documentar la
evidencia, generar reportes etc.

II.

CLASES DE MTODOS

En funcin de su grado de adaptacin y rigurosidad se distingue entre:

SCAMPI-C: Mide la idoneidad de los procesos, mediante entrevistas o

revisin documental. Es el mtodo idneo para poder obtener una foto
rpida del estado de los procesos en una organizacin para comenzar
un programa de mejora de procesos.
SCAMPI-B: Permite evaluar la idoneidad y el grado de despliegue de los
procesos, mediante entrevistas o revisin documental. Es recomendable
para hacer auditoras de los procesos de una organizacin antes de
afrontar el proceso de certificacin con la evaluacin formal.
SCAMPI-A: Es el ms formal que mide la idoneidad, despliegue e
institucionalizacin de los procesos. Es el necesario para poder obtener
un certificado de un determinado nivel de madurez.

El mtodo formal de evaluacin SCAMPI-A tiene una serie de requisitos

aadidos:

Debe ser realizado por una persona acreditada por el SEI como SCAMPI
Leader Appraiser
Se debe formar un equipo de evaluacin (Assessment Team Members)
de al menos 4 personas, y todos sus miembros deben haber pasado el
curso oficial de introduccin a CMMI.
El equipo de evaluacin debe tener una experiencia mnima (6 aos de
experiencia media y 25 aos en total en desarrollo de software, 10 aos
en gestin) en las disciplinas que son objeto de la evaluacin
Para garantizar la objetividad de las evaluaciones, las personas que
participan como equipo de evaluacin no pueden tener responsabilidad
sobre los proyectos seleccionados y personas a entrevistar.

A pesar de que el mtodo SCAMPI Clase A cumple con todos los

requerimientos definidos por el SEI para esta clase de mtodos en el
documento Appraisal Requirements for CMMI, (ARC) algunos casos de
estudio han demostrado que el uso de este mtodo de evaluacin involucra
altos costos y consume mucho tiempo para poder obtener resultados. Por
tanto, no es factible para muchas organizaciones emplear una evaluacin
Clase A, sobre todo en pequeas organizaciones, por lo que para estos casos
una evaluacin Clase B o C es la ms adecuada.
Todos los SCAMPIs deben ser supervisados por agentes autorizados del SEI,
inclusive C y B para garantizar interpretaciones correctas y autorizadas.

III.

SCAMPI LEADER APPRAISER

Las evaluaciones de las organizaciones se llevan a cabo por supervisores de

evaluacin externos que tienen la autorizacin del SEI. Estos supervisores han
recibido la formacin necesaria y tienen acceso a mtodos de evaluacin,
materiales de formacin, asistencia tcnica y actualizacin formativa
proporcionados por el SEI. A travs de su participacin en evaluaciones de
organizaciones y de los mecanismos de realimentacin previstos en los
mtodos de evaluacin, los supervisores de evaluacin contribuyen a la
mejora continua de la tecnologa de evaluacin del SEI.
Para que un profesional tenga la consideracin de supervisor de evaluacin
SCAMPI debe estar en posesin del informe favorable que acredite que ha
superado el plan formativo para supervisores de evaluacin diseado por el
SEI. Para acceder a esta formacin son necesarios los siguientes requisitos:
1. El SEI debe haber aceptado como asociada para servicios de evaluacin
SCAMPI a la organizacin a la que el profesional pertenezca.
2. Completar con xito el proceso de seleccin, acreditando los
conocimientos mnimos requeridos. Se exige haber formado parte de un
equipo de evaluacin SCAMPI en al menos dos evaluaciones en los dos
aos inmediatamente anteriores a la solicitud.
3. Aprobar un curso de introduccin a CMMI.
4. Aprobar un curso de conocimientos intermedios de CMMI.

ISO/IEC 15504
El ISO/IEC 15504, tambin conocido como Software Process Improvement
Capability Determination, abreviado SPICE, en espaol, Determinacin de la
Capacidad de Mejora del Proceso de Software es un modelo para la mejora,
evaluacin de los procesos de desarrollo, mantenimiento de sistemas de
informacin y productos de software.
Este modelo establece conjuntos predefinidos de procesos con objeto de
definir un camino de mejora para una organizacin. En concreto, establece 6
niveles de madurez para clasificar a las organizaciones. Al ser un modelo para
el desarrollo software, toma como base el modelo de procesos ISO/IEC
12207:2008 (Systems and software engineering -- Software life cycle
processes).

I.

LOS NIVELES DE MADUREZ

La norma ISO 15504 permite realizar evaluaciones usando niveles de madurez,

la evaluacin ms extendida en la actualidad.
Los niveles de madurez son conjuntos predefinidos de procesos que ayudan a
una organizacin a mejorar en el desarrollo software evolucionando por los
distintos niveles.
En este modelo, se han establecido 6 niveles, y en cada nivel se ha definido
una serie de procesos que indican la madurez de la organizacin. Como se
observa en la siguiente tabla, el nivel inferior (nivel 0) se corresponde con una
organizacin inmadura, los siguientes niveles van haciendo crecer a la
organizacin en su madurez, hasta el mximo nivel, el nivel 5.
Nivel

Estado

Nivel 0 - Organizacin La organizacin no tiene un implementacin efectiva de los

inmadura

procesos

Nivel 1 - Organizacin La organizacin implementa y alcanza los objetivos de los

bsica

procesos

Nivel 2 - Organizacin La organizacin gestiona los procesos y los productos de trabajo

gestionada

se establecen, controlan y mantienen

Nivel 3 - Organizacin La organizacin utiliza procesos adaptados basados en

establecida
Nivel 4 - Organizacin
predecible

estndares
La organizacin gestiona cuantitativamente los procesos

Nivel 5 - Organizacin La organizacin mejora continuamente los procesos para

optimizando

cumplir los objetivos de negocio

La consecucin de los niveles de madurez es de forma escalonada, esto

significa que para alcanzar un determinado nivel de madurez deben haberse
alcanzado tambin los niveles inferiores.

II.

PUNTOS FUERTES Y PUNTOS DBILES

Como ha quedado recogido en los apartados anteriores, SPICE ha sido un

proyecto de lenta maduracin, que ha variado mucho desde su borrador inicial
en 1995, hasta los modelos que estn acabando de ser publicados. Muchas de
las crticas o mejoras propuestas a lo largo de estos aos por diversos autores,
han sido recogidas as como ciertos aspectos positivos (como la representacin
continua del modelo) han sido adoptadas por otros.
Cabe destacar el considerable nmero de estudios de evaluacin emprica
realizados, pudiendo revisar sus conclusiones ms significativas en [33], en
cuanto a validez predictiva, veracidad de la capacidad, demostracin de su
capacidad para identificacin de fuerzas, debilidades y riesgos as como dirigir
y priorizar el proceso de mejora.
Segn ISO 9001, evaluando su versin 1.0, sus mayores contribuciones han
sido:

Primer modelo de procesos de 2 dimensiones, dimensiones independientes

para los procesos y la capacidad.
El resultado de una evaluacin de proceso puede ser representado por un
perfil de proceso, una grfica de 2 dimensiones.
Inicialmente recoga una escala refinada de procesos de 9 atributos y 6
niveles, que posteriormente fue mejorada con la desaparicin de la escala de
procesos y la adopcin de los PRMs.
Define un conjunto de criterios de conformidad para permitir la comparacin
de modelos externos de procesos y encontrar requisitos comunes.
Por el contrario, temas abiertos eran:
Pensaba que el dominio de procesos debera ser ms amplio para abarcar
todos los posibles ciclos de vida (algo no necesario por la adopcin de modelos
externos, los PRMs) y que era difcil que todos los atributos de proceso fueran
universales, aplicables a todos los procesos y prcticas base.
La dimensin capacidad ha alcanzado un alto grado de dificultad y existen
solapamientos con la dimensin procesos.
La complejidad de las evaluaciones (y por consiguiente el costo) es
significativa-mente ms alta que en otros modelos.
Por ltimo, en sus conclusiones, al valorar el panorama de distintos estndares
existentes, afirma la necesidad de pruebas de la efectividad y el impacto de la
adopcin de estos modelos de mejora tanto en la ingeniera del software como
en otros campos y resalta la necesidad de bsqueda de integracin y facilidad
para la evolucin que deben adoptar los estndares, aspectos que, aunque no
lo recoja el autor, estn resueltos por SPICE frente a otros modelos.
En el Modelo de Capacidad de Procesos se afirma que el desarrollo de ISO
15504 ha acercado a lo mejor de los expertos internacionales en evaluacin de
procesos, y a travs de la sinergia de estas relaciones ha llevado a
significativos avances en el estado del arte y en la argumentacin terica del
proceso.

III.

ASPECTOS COMUNES Y COMPARATIVAS DE MODELOS

Aqu pretendemos reflexionar sobre la esclavitud creativa de los estndares, la

base terica o rigurosidad formal de los modelos, sobre las comparativas
existentes entre modelos, as como recoger documentos que realizan mapeos
entre modelos.
Hay una corriente de autores que consideran que los estndares reducen la
autonoma de los desarrolladores, siendo experimentada como una carga,
restricciones coercitivas, ahogando la creatividad requerida en el desarrollo de
software innovador, veneran al proceso, ignorando a las personas. Frente a
esta postura, est la que defiende que esta interdependencia (frente al trabajo
9

autnomo) toma una forma colaborativa, niveles de proceso maduros llevan a

un proceso de desarrollo ms socializado, el esfuerzo colaborativo aumenta la
eficiencia y efectividad.
Otra crtica habitual es que muchas veces en el mbito de la mejora de
procesos, los medios se olvidan del fin. Debe evitarse que el verdadero
objetivo de mejorar el pro-ceso se desplace a la misin artificial de alcanzar un
mayor nivel de madurez.
Tambin se critica la ausencia de base terica formal y la vaguedad del
soporte emprico. Aunque la aparicin de la Teora de la Evaluacin, un marco
terico de propsito general que define los diferentes tipos de mtodos de
evaluacin y sus parmetros, ha aportado resultados iniciales esperanzadores,
ninguno de los actuales mtodos de evaluacin, la siguen. En este ltimo
estudio aparece una comparativa de rigurosidad formal de los modelos ms
difundidos as como un experimento de aplicacin comparativa.
Por otro lado, es difcil discernir en el estudio de los resultados empricos, la
parte correspondiente de la mejora a la aplicacin de un estndar, en lugar de
otro.
No existen comparativas actualizadas entre los modelos estudiados, por lo
que, como referencia, se aportan una taxonoma comparativa y una
recopilacin de estudios comparativos, tanto cuantitativos como cualitativos,
econmicos y tcnicos de diferentes estndares.
En cuanto a comparativas y mapeos entre reas clave, con la desaparicin de
la dimensin Proceso, esta carece de sentido con SPICE por lo que entre ISO
9001 y CMM destacaremos a organizaciones de desarrollo software. Destaca la
sinergia entre ambos y el que cada vez ms compaas consideren el uso
conjunto de CMMI e ISO 9000 para aumentar la eficacia del proceso de mejora.
A modo de resumen, presentamos un cuadro comparativo con las principales
caractersticas de cada modelo:
ISO 9001:2000
mbito
aplicacin
En su favor

En su contra

Procesos

Validacin

de

Genrico
El ms extendido
y sencillo
Simple, general,
no gua paso a paso

Estructura propia

Encuestas
satisfaccin

CMMI
Software
y
Sistemas
El de mayor
prestigio
Difcil
de
entender,
mayor
inversin,
prescriptivo
Estructura propia

Encuestas
satisfaccin y casos

ISO 15504
Software
y
Sistemas
Ms
consensuado
y
probado
Difcil
en
capacidad,
complejo
para
evaluar
Delega en ISO
12207, por mayor
aplicabilidad
Trials
y
esfuerzo emprico
10

Objetivo

Representacin

Tcnicas anlisis
Mtodo
para
mejora de procesos

Cumplimiento
de requisitos de
calidad
por
procesos
Plana

Guas y listas de
comprobacin
Ninguno, gua
ISO 9004

de estudio
Mejora
del
proceso,
determinacin
capacidad
contratista
Continua y por
etapas
Cuestionarios de
evaluacin
IDEAL,
mapa
guiado

Valoracin del
proceso y gua para
la mejora.

Continua
(por
etapas a nivel de
proceso)
Varios
SPICE 4 Parte

11

INGENIERA DE REQUISITOS
En la ingeniera de sistemas y la ingeniera de software, la Ingeniera de
requisitos o Ingeniera de requerimientos comprende todas las tareas
relacionadas con la determinacin de las necesidades o de las condiciones a
satisfacer para un software nuevo o modificado, tomando en cuenta los
diversos requisitos de las partes interesadas, que pueden entrar en conflicto
entre ellos.
Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a
una mala traduccin del ingls. La palabra requirement debe ser traducida
como requisito, mientras que requerimiento se traduce al ingls como request.
El propsito de la ingeniera de requisitos es hacer que los mismos alcancen un
estado ptimo antes de alcanzar la fase de diseo en el proyecto. Los buenos
requisitos deben ser medibles, comprobables, sin ambigedades o
contradicciones, etc.

I.

FASES DE IMPLEMENTACIN

Desde un punto de vista conceptual, las actividades son de cinco clases.

Obtener requisitos: a travs de entrevistas o comunicacin con clientes

o futuros usuarios, para saber cules son sus expectativas.
Analizar requisitos: detectar y corregir las carencias o falencias
comunicativas, transformando los requisitos obtenidos de entrevistas y
requisitos, en condiciones apropiadas para ser tratados en el diseo.
Documentar requisitos: igual que todas las etapas, los requisitos deben
estar debidamente documentados.
Verificar los requisitos: consiste en comprobar la implementacin de los
requerimientos.
Validar los requisitos: comprobar que los requisitos implementados sean
funcionales para lo que inicialmente se construy el producto.

12