Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
La bsqueda de soluciones a estos retos ha continuado por muchos aos. Despus de dos
dcadas de promesas insatisfechas acerca de la productividad y de la calidad que se obtiene
de aplicar nuevas metodologas y tecnologas de software, las organizaciones se estn
11
El Instituto de Ingeniera de Software (SEI por sus siglas en ingls: Software Engineering
Institute) cuya misin es proveer liderazgo en el progreso del estado de la prctica de
ingeniera de software para mejorar la calidad de los sistemas que dependen del software,
se ve involucrado en la solucin de estos problemas, ya que la misin de su programa de
procesos de software as lo establece: Proveer liderazgo en la asistencia
de las
12
que las organizaciones de software pasen de procesos inmaduros hacia la madurez de stos,
de forma disciplinada.
lucha con fuego). Estas organizaciones rutinariamente exceden los tiempos de entrega, ya
que no hacen estimados realistas, adems de que no cuentan con bases objetivos para juzgar
la calidad de los productos, comprometen la calidad y funcionalidad del producto a cambio
de entregar en las fechas establecidas [Carnegie00].
necesidades del cliente, tanto actuales como futuras. El propsito del CMM es describir el
buen manejo y prcticas de ingeniera estructurndolos en un esquema de madurez. La
madurez del proceso de software de una organizacin ayuda predecir la capacidad de
resolver las metas del proyecto.
2.2.1 Estructura
La estructura del modelo de capacidad de madurez organiza sus prcticas complejas en
unas cuantas categoras. Las divisiones principales del modelo son 5 niveles de madurez y
cada nivel es descompuesto a su vez en un conjunto reas claves del proceso (KPA por sus
siglas en ingls Key Process Areas), las cuales estn organizadas de acuerdo a sus
caractersticas. En la figura 1.1 se muestra esta distribucin [Carnegie00].
15
Niveles de Madurez
indican
contiene
n
reas Clave del Proceso
Capacidad del
Proceso
organizadas
por
logran
Caractersticas
Comunes
Metas
dirigen
contienen
Prcticas
Clave
Implementacin o
Institucionalizacin
describen
Actividades
Activida
des
Los niveles definen una escala para medir la madurez del proceso de software de una
organizacin y evalan la capacidad de procesos de software [Carnegie00]:
2.3.1 Inicial
En este nivel, las buenas prcticas dependen del recurso humano directamente. El proceso
de software no est documentado y tiene un ambiente inestable en el desarrollo y
mantenimiento. Existe una baja probabilidad de cumplir objetivos del proyecto (Tiempo,
costos, recursos).
2.3.2 Repetible
La repeticin de xitos es en base a proyectos anteriores; los procesos efectivos son bien
definidos, documentados, practicados y medidos pero an pueden mejorar; adems existen
polticas para la administracin de proyectos; sigue habiendo cajas negras pero ya son
definidas y revisadas, an no se cuenta con mtricas para servicios
16
2.3.3 Definido
El proceso es estndar, consistente, estable y repetible. La capacidad se logra basndose en
el entendimiento de las actividades, roles y responsabilidades en un proceso de software
bien definido. Tiene mtricas definidas para los productos y los servicios que ofrece la
empresa; la organizacin cuenta con un programa de capacitacin para todos sus miembros
2.3.4 Administrado
El proceso, a la par que el producto y servicios, es medido y opera dentro de un lmite
cuantificable. Se cumple con planes y programas de mejora. Se hace una distincin entre
los procesos principales y los de apoyo.
2.3.5 Optimizado
Este nivel se dedica al mejoramiento continuo de su proceso a la par de su madurez, lo cual
se da gracias al uso o implementacin de nuevas tecnologas o mtodos.
Existen 18 KPAs distribuidas a lo largo de los niveles 2 -5 (El nivel 1 no tiene ninguna
17
debido a las caractersticas que posee). Cada una de estas tiene distintas metas que cumplir,
a continuacin se detalla cada una de acuerdo al nivel que pertenece y ms adelante se
mencionan las metas que les corresponden.
18
23
Coordinacin intergrupal: Los requerimientos del cliente son acordados por todos
los grupos afectados; los compromisos entre los grupos de ingeniera son acordados
por los grupos afectados; el grupo de ingeniera identifica, da seguimiento y
resuelve los asuntos entre los grupos.
2. 5 Caractersticas comunes
Por conveniencia, las prcticas que describen las reas clave del proceso, son organizadas
por caractersticas comunes, las cuales son atributos que indican si la implantacin e
institucionalizacin de un rea clave del proceso es efectiva, repetible y duradera
[Carnegie00]. En esta seccin se darn detalles de estas clasificaciones y se mencionarn
las prcticas que le corresponden.
2.5.1 Compromisos
Describen acciones que la organizacin debe realizar para asegurarse de que el proceso es
establecido y de que perdurar. Tpicamente involucra establecer polticas organizacionales
y de liderazgo.
En el nivel 2, las polticas escritas que debe establecer la organizacin son las siguientes:
C2.1
25
C2.2
C2.3
C2.4
C2.5
C2.6
C2.7
subcontrato de software.
C3.1
de la organizacin.
C3.2
procesos relacionados.
C3.3
C3.4
En este nivel se establecen polticas para los proyectos, las cuales requieren que el
C3.5
C3.6
C3.7
C3.8
A su vez, la gerencia tiene polticas que establecen patrocinar las actividades de los
C4.1
El proyecto debe seguir una poltica organizacional escrita para medir y controlar
C4.2
La organizacin debe seguir una poltica escrita para analizar la capacidad del
En el nivel 5 tanto la organizacin como cada proyecto dentro de ella mantienen las
siguientes polticas:
C5.1 Siguen
27
C5.2
C5.3
Para cada proyecto se establece la responsabilidad para analizar los requerimientos del
sistema y dirigirlos hacia el software, el hardware u otros componentes del sistema.
H2.1
H2.2
H2.3
H2.4
H2.5
H2.6
H2.7
H2.8
H2.9
H2.10
29
H2.11
H3.1
H3.2
H3.3
Los gerentes del software reciben la capacitacin requerida para administrar los
H3.4
Los miembros del staff tcnico de ingeniera de software reciben capacitacin para
H3.5
H3.6
H3.7
Las herramientas de soporte utilizadas por los diferentes grupos de ingeniera son
H3.8
Todos los lderes de tareas de cada grupo de ingeniera reciben orientacin en los
H3.9
conducir stas.
H3.10
Los revisores que participan en las revisiones entre colegas reciben la capacitacin
necesaria en cuanto a los objetivos, principios y mtodos de las revisiones entre colegas.
H4.1
31
H4.2
H4.3 Existe
H4.4
H4.5
Los miembros del grupo de ingeniera de software y otros grupos relacionados con
En el nivel 5, las habilidades descritas segn el modelo CMM, son las siguientes:
H5.1
de defectos.
H5.2
32
H5.3
H5.4
H5.5
Existe apoyo para recolectar y analizar la informacin necesaria para evaluar los
cambios tecnolgicos.
H5.6
productos, est disponible para apoyar los anlisis realizados para evaluar y seleccionar
cambios en la tecnologa.
H5.7
33
A2.1
que sean incorporados en el proyecto de software y los usa como base para los planes,
actividades y productos a desarrollar; ste grupo participa en la propuesta de equipo del
proyecto.
A2.2
A2.3
tamao manejable.
A2.4
A2.5
A2.6
Estimados del tamao del esfuerzo de los productos de software, costos, recursos
A2.7
Los riesgos de software asociados con el costo, horario, recursos y aspectos tcnicos
34
A2.8
Son preparados los planes de las facilidades de ingeniera del producto de software
y herramientas de soporte.
A2.9
A2.10
A2.11
A2.12
son comunicados a los miembros del grupo de ingeniera de software y a otros grupos
relacionados con el software.
A2.13
A2.14
A2.15
35
A2.16
A2.17 El
documentado.
A2.18
A2.19
contratista principal.
A2.20
A2.21
A2.22
A2.23
36
A2.24
A2.25
A2.26
A2.27
A2.28
A2.29
A2.30
37
A2.31
A2.32
A3.1
A3.2
A3.3
A3.4
nivel organizacional.
A3.5
organizacin.
A3.6
A3.7
A3.8
A3.9
A3.10
A3.11
A3.12
proceso de software.
A3.13
A3.14
procedimiento documentado.
A3.15
capacitacin organizacional.
A3.16
A3.17 Se
usado para determinar cundo los individuos ya poseen los conocimientos y las
habilidades requeridas para el ejecutar los roles asignados.
A3.18
A3.19
A3.20
procedimiento documentado.
A3.21
El plan de desarrollo de software del proyecto, que describe el uso del proceso de
40
A3.22
A3.23
estimar.
A3.24
A3.25
procedimiento documentado.
A3.26
un procedimiento documentado.
A3.27
Las dependencias crticas y las rutas crticas del calendario de software del
A3.28
A3.29
acciones necesarias para llevar el desempeo y los resultados del proyecto de software
en lnea con las necesidades actuales y proyectadas del negocio, el cliente y los usuarios.
A3.30
A3.31
A3.32
con el proceso de software definido para el proyecto, para incluir los requerimientos de
software y para formar un marco de referencia para la codificacin.
A3.33
A3.34
para el proyecto.
A3.35
A3.36
A3.37
42
A3.38
Los datos de los defectos identificados en las revisiones entre colegas y en las
A3.39
A3.40
cliente y los usuarios finales, segn sea apropiado, para establecer los requerimientos del
sistema.
A3.41
A3.42
A3.43
A3.44
Los productos producidos como una entrada para otros grupos de ingeniera se
revisan por representantes de los grupos que las reciben, para asegurar que los productos
43
A3.45
A3.46
A3.47
A4.1
A4.2
A4.3
A4.4
A4.5
A4.6
A4.7
A4.8
A4.10
para los productos de software a travs del ciclo de vida del software.
A4.11
compara contra las metas cuantitativas de calidad de los productos, sobre la base de
eventos.
A4.12
software del proyecto las metas cuantitativas de calidad del proyecto de software para
los productos.
45
A5.1
prevencin de defectos.
A5.2
Al inicio de una tarea de software, los miembros del equipo que realizan la tarea se
renen para prepararse para llevar acabo sus actividades tanto de tareas como de
prevencin de defectos.
A5.3
documentado.
A5.4
A5.5
A5.6
A5.7
Los miembros del grupo de ingeniera de software y otros grupos relacionados con
46
A5.8
tecnolgico.
A5.9
trabaja con los proyectos de software para identificar reas de cambio tecnolgico.
A5.10
nuevas tecnologas.
A5.11
A5.12
A5.13
A5.14
A5.15
A5.16
A5.17
A5.18
A5.19
A5.20
procedimiento documentado.
A5.21
A5.22
Cuando sea apropiado, las mejoras al proceso de software se instalan como pilotos
A5.23
documentado.
A5.24
A5.25
Describe las prcticas bsicas de medicin que son necesarias para determinar el estado
relacionado con los procesos. Estas medidas son utilizadas para controlar y mejorar los
procesos.
M2.1
M2.2
M2.3
49
M3.1
definicin de procesos.
M3.2 Determinar
M3.3
M4.1
M5.1
M5.2
tecnolgico de la organizacin.
M5.3 Determinar
50
V2.1
administracin de la configuracin,
V2.2
V2.3
V2.4
51
V3.1
V3.2
V3.3
Las actividades del programa de capacitacin y sus entregables son revisadas y/o
V3.4
V3.5
El administrador del proyecto revisa tanto de forma peridica como por evento las
V4.1
V4.2
V4.3
V5.1
V5.2
El administrador del proyecto hace revisiones tanto de forma peridica como por
evento.
53
V5.3 El
Los equipos de evaluacin lo utilizan para identificar los riesgos de seleccionar entre
diversos contratistas para el negocio y para vigilar los contratos.
La alta gerencia lo deber utilizar para entender las actividades necesarias para realizar un
programa de mejoramiento en el proceso de software de la organizacin.
El personal tcnico lo ocupar como gua que le ayude a definir y mejorar los procesos del
software.
A travs de los cinco niveles, el proceso de capacidad interacta con personas, tecnologa y
medidas mientras la organizacin madura, en la siguiente tabla se muestra la manera en que
se relacionan [Carnegie00]:
54
Nivel 2
Nivel 3
Nivel 4
Nivel 5
Existen o son
usados pocos
procesos
estables.
Administracin
integrada e ingeniera
de procesos son
usados en toda la
organizacin
Tienen el lema
Just do it
Los problemas
son reconocidos y
corregidos en
cuanto ocurren
Orgenes de
problemas
individuales son
entendidos y
eliminados.
Orgenes
comunes de
problemas son
entendidos y
eliminados
El xito depende
de individuos
considerados
como hroes
El xito depende
de individuos;
hay soporte en el
sistema
administrativo
Los proyectos en
grupo trabajan
juntos; tal vez como
un grupo integrado
Existe un fuerte
sentimiento de
trabajo en grupo
para cada
proyecto
Existe un fuerte
sentimiento de
trabajo en grupo
en toda la
organizacin
La idea de
Luchar contra
fuego se ha
eliminado
completamente
Los compromisos
son entendidos y
administrados
El entrenamiento es
planeado y provisto
de acuerdo a los roles
Las relaciones
entre disciplinas
no estn
coordinadas, tal
vez podran ser
adversas
La gente est
entrenada
Introducir nueva
tecnologa es
riesgoso
Establecimiento
de soporte de
tecnologa,
actividades
estables
Nuevas tecnologas
son evaluadas en una
base cualitativa
Nuevas
tecnologas son
evaluadas en una
base cualitativa
Nuevas
tecnologas son
presentadas e
implementadas de
manera continua
La coleccin de
datos y el
anlisis son ad
hoc
La planeacin y
administracin de
datos son usados
en proyectos
individuales
La informacin es
coleccionada y es
utilizada en todos los
procesos definidos
La recoleccin y
definicin de
informacin es
estandarizada
alrededor de toda
la organizacin
La informacin
es usada para
evaluar y
seleccionar
mejoras en los
procesos
La informacin es
sistemticamente
compartida en todos
los proyectos
La informacin
es usada para
entender los
procesos de
manera
cuantitativa y
para
estabilizarla.
Mtricas
Tecnologa
Personal
Proceso
Nivel 1
Todos estn
involucrados con
el mejoramiento
del proceso
Tabla 1. Relacin entre personal, tecnologa y mtricas a lo largo de los niveles de CMM.
55