Comportamiento Organizacional

Comportamiento
Organizacional (CMMI)
2
CARRERAS PROFESIONALES
CIBERTEC
C OMPORTA MIEN TO OR GA NIZA C IONA L ( CMMI) 3
NDICE Pg.
Presentacin 5
Red de contenidos 6
Unidad 1: Niveles de madurez CMMI y reas de proceso 7
Tema 1: Niveles de madurez de CMMI 8

1.1 Introduccin a CMMI 8
1.2 Especificacin de los 5 Niveles de madurez 9
Tema 2: reas de proceso de CMMI 13

2.1 Componentes del rea de proceso 13
2.2 reas de proceso 15
Unidad 2: CMMI y el ciclo de vida del desarrollo del SW 23
Tema 3. Ciclo de vida del desarrollo del SW 24

3.1 Ciclo de vida del software 24
3.2 El papel de la certificacin de la calidad del software en sus etapas 25
de desarrollo
Tema 4: Gestin y Calidad 27

4.1 Procesos de gestin de proyectos e ingeniera de software 27
4.2 Procesos de aseguramiento de la calidad del producto y del 40
proceso
Unidad 3: Arquitectura del Modelo CMMI 43
Tema 5: Objetivos y prcticas genricas 44

Tema 6: Objetivos y prcticas especficas 64
Unidad 4: reas de proceso de nivel 2 65

Tema 7: reas de proceso de nivel 2 66


Unidad 7: reas de proceso de nivel 5 y evaluacin SCAMPI 105

Tema 11: Evaluacin SCAMPI para CMMI 110
Tema 12: Otros estndares y modelos de referencia 114
CIBERTEC CARRERAS PROFESIONALES

4
CIBERTEC
PRESENTACIN
Comportamiento Organizacional pertenece a la lnea formativa y se dicta en

la carrera de Administracin y Sistemas. Brinda todos los conceptos
relacionados con la mejora de procesos, gestin de proyectos y aseguramiento
de la calidad del producto y proceso de software.
Brinda herramientas que ayudan a la definicin del proceso de software e

incorpora buenas prcticas para la produccin del mismo.
El manual para el curso ha sido diseado bajo la modalidad de unidades de

aprendizaje, las que se desarrollan durante semanas determinadas. En cada una
de ellas, hallar los logros, que debe alcanzar al final de la unidad; el tema
tratado, el cual ser ampliamente desarrollado; y los contenidos, que debe
desarrollar, es decir, los subtemas. Por ltimo, se encontrarn las actividades
que se deber desarrollar en cada sesin, que permitirn reforzar lo aprendido
en la clase.
El curso es terico prctico: consiste en sesiones conceptuales complementadas

de ejercicios. En primer lugar, se inicia con la descripcin del modelo, los
diferentes niveles de madurez y las reas de proceso del modelo CMMI. En
segundo lugar, se contina con la explicacin y reconociendo de artefactos por
etapas del ciclo de vida de desarrollo del software alineado con las prcticas del
modelo CMMI. Luego, se prosigue a conocer los objetivos y prcticas genricas
y especficas de cada rea de proceso. Por ltimo, se concluye con la
clasificacin y explicaciones de stas por niveles.

6
RED DE CONTENIDOS
Comportamiento Organizacional
Niveles de Ciclo de vida Arquitectura Arquitectura

madurez CMMI del Modelo Evaluacin
del Desarrollo del Modelo
y reas de de SW y sus CMMI reas SCAMPI
CMMI
proceso artefactos de proceso
Evaluacin
SCAMPI
Niveles de CV de desarrollo reas de
Prcticas
madurez de software proceso Nivel 2
Genricas
Otros
reas de
reas de Gestin y estndares y
Prcticas proceso Nivel 3
Proceso calidad modelos
Especficas
reas de
proceso Nivel 4
reas de
proceso Nivel 5
CIBERTEC
UNIDAD DE
APRENDIZAJE
NIVELES DE MADUREZ CMMI Y REAS DE
PROCESO
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al trmino de la unidad, el alumno, clasifica y explica los diferentes niveles de

madurez y reas de proceso del modelo CMMI.
TEMARIO
Tema 1: Niveles de madurez de CMMI

1.1 Introduccin a CMMI
1.2 Especificacin de los 5 Niveles de Madurez
Tema 2: reas de proceso de CMMI

2.1 Componentes del rea de proceso
2.2 reas de proceso
ACTIVIDADES PROPUESTAS
1. Elaborar un cuadro comparativo de las representaciones continua y por

etapas.
2. Identificar los factores de decisin que se usan para elegir entre una
representacin u otra.

8
1. NIVELES DE MADUREZ DE CMMI
1.1. Introduccin a CMMI
Ahora, ms que nunca, las compaas desean entregar mejores

productos y servicios en menos tiempo y ms baratos. Sin embargo, al
mismo tiempo, en el entorno de alta tecnologa del siglo veintiuno, casi
todas las organizaciones se han encontrado construyendo productos y
servicios cada vez ms complejos. Hoy en da, es raro que las
compaas desarrollen por s mismas todos los componentes que
forman parte de un producto o servicio. Frecuentemente, algunos se
construyen en la compaa y otros se adquieren; despus todos los
componentes se integran en el producto o servicio final. Por ello, las
organizaciones deben ser capaces de gestionar y controlar este
complejo proceso de desarrollo y de mantenimiento.
Los problemas que estas organizaciones encuentran implican soluciones

que conciernen a toda la empresa y que requieren una aproximacin
integrada. La gestin eficaz de los activos es crtica para el xito de su
actividad. En esencia, estas organizaciones desarrolladoras de
productos y servicios necesitan una manera de gestionar una
aproximacin integrada para sus actividades de desarrollo, como parte
para lograr sus objetivos estratgicos.
En el mercado actual, existen modelos de madurez, estndares,
metodologas y guas que pueden ayudar a una organizacin a mejorar
su modo de operar. Sin embargo, la mayora de las aproximaciones de
mejora disponibles se centra en una parte especfica de su actividad y
no adopta una aproximacin sistmica a los problemas a los que se
enfrenta la mayora. Concentrndose en mejorar un rea de negocio,
estos modelos desafortunadamente han perpetuado los canales y las
barreras que existen en el seno de las organizaciones.
El Capability Maturity Model Integration (CMMI de aqu en adelante)
proporciona una oportunidad para evitar o eliminar estos canales y
barreras, apoyndose en los modelos integrados que trascienden
CIBERTEC
disciplinas. El CMMI para Desarrollo contempla las buenas prcticas

relativas a las actividades de desarrollo y mantenimiento aplicadas a
productos y servicios. Trata las prcticas que cubren el ciclo de vida del
producto desde la concepcin hasta la entrega y el mantenimiento. El
nfasis lo pone en el trabajo necesario para construir y mantener el
producto completo.
Nacido en el Software Engineering Institute y perteneciente a la

Carnegie Mellon University, CMMI es la nueva generacin de una lnea
de modelos de madurez que se inici a principios de los noventa con el
famoso CMM-SW (Capability Maturity Model for Software Engineering).
1.2. Especificacin de los 5 niveles de madurez
En su investigacin para ayudar a las organizaciones a desarrollar y a

mantener productos y servicios de calidad, el Software Engineering
Institute (SEI) ha identificado varias dimensiones, sobre las que una
organizacin puede enfocarse para mejorar su actividad.
La Figura 1 ilustra las tres dimensiones crticas sobre las cuales

tpicamente se concentran las organizaciones: las personas, los
mtodos y procedimientos, y las herramientas y equipamiento.
Pero, qu es lo que sustenta todo el conjunto? Los procesos utilizados
en su organizacin. stos le permiten alinear el modo de operar de la
misma, evolucionar e incorporar los conocimientos de cmo hacer mejor
las cosas. Los procesos le permiten tambin explotar mejor sus recursos
y comprender las tendencias de su actividad.

10
Figura 1: Tres dimensiones crticas
Comprendiendo los niveles

Los niveles se utilizan en CMMI para describir un camino evolutivo
recomendado para una organizacin que quiera mejorar los procesos
que utiliza para desarrollar y mantener sus productos y servicios.
Tambin, pueden ser el resultado de la actividad de calificacin de las
evaluaciones. stas se pueden realizar para organizaciones, incluyendo
compaas (generalmente pequeas) completas o grupos ms
pequeos, tal como un grupo de proyectos o una seccin dentro de una
compaa.
CMMI soporta dos caminos de mejora:
Representacin Continua: camino que permite a las organizaciones

mejorar en forma incremental los procesos que corresponden a un rea
o reas de proceso individual seleccionada por la organizacin.
Representacin por etapas: camino que permite a las organizaciones

mejorar un conjunto de procesos relacionados, tratando de forma
incremental conjuntos sucesivos de reas de proceso.
CIBERTEC
Para la representacin continua, se utiliza el trmino nivel de

capacidad; en cambio para la representacin por etapas, nivel de
madurez.
Independientemente de qu representacin se seleccione, el concepto

de niveles es el mismo. Caracterizan a la mejora desde un estado mal
definido hasta uno que utiliza informacin cuantitativa para determinar y
gestionar las mejoras que se necesitan para satisfacer los objetivos de
negocio de una organizacin.
Para alcanzar un nivel particular, una organizacin debe satisfacer todas
las metas apropiadas del rea o conjunto de reas de proceso que son
objeto de la mejora, independientemente de si es un nivel de capacidad
o de madurez.
Ambas representaciones, tambin, proporcionan caminos para

implementar la mejora de procesos, que permiten lograr los objetivos de
negocio. Asimismo, ofrecen el mismo contenido esencial y utilizan los
mismos componentes del modelo.
CMMI plantea que las organizaciones pueden ubicarse en alguno de
cinco posibles niveles de madurez, dependiendo del grado de
sofisticacin de sus procesos (ver Fig. 2) A su vez, cada uno -con
excepcin del inicial- queda caracterizado por un conjunto de reas de
proceso que agrupan prcticas que, al ser ejecutadas colectivamente,
permiten cumplir con algn objetivo que es considerado importante para
el modelo.

12
Figura 2: Niveles de madurez
Adems de ver las reas de proceso por nivel de madurez, el modelo

propone una vista alternativa (llamada continua) en donde stas se
encuentran agrupadas por categoras (ver Fig. 3).
CIBERTEC
Figura 3: reas de proceso por categora
2. REAS DE PROCESO DE CMMI
2.1. Componentes del rea de proceso
Los componentes del modelo se agrupan en tres categoras: requerido,

esperado e informativo, que indican cmo interpretarlos.
Componentes requeridos
Los componentes requeridos describen lo que una organizacin debe
realizar para satisfacer un rea de proceso. Este logro se debe
implementar de forma visible en los procesos de una organizacin. Los
componentes requeridos en CMMI son las metas especficas y los
objetivos genricos. La satisfaccin de objetivos se utiliza en las

14
evaluaciones como base para determinar si un rea de proceso ha sido

realizada y satisfecha.
Componentes esperados
Los componentes esperados describen lo que una organizacin puede
implementar para lograr un componente requerido. Asimismo, guan a
los que implementan mejoras o realizan evaluaciones. Aparte de ello,
incluyen las prcticas especficas y genricas.
Antes de que los objetivos puedan considerarse satisfechos, las
prcticas tal como se describen o prcticas aceptables alternativas a
ellas, debern estar presentes en los procesos planificados e
implementados de la organizacin.
Componentes informativos
Los componentes informativos proporcionan detalles que ayudan a las
organizaciones a comenzar a pensar en cmo aproximarse a los
componentes requeridos y esperados. Las sub-prcticas, los productos
de trabajo tpicos, las ampliaciones, las elaboraciones de las prcticas
genricas, los ttulos de metas y prcticas, las notas de metas y
prcticas, y las referencias son ejemplos de componentes informativos
del modelo.
El glosario de trminos del CMMI no es un componente requerido ni
esperado ni tampoco informativo de los modelos del mismo. Se debern
interpretarse en el contexto del componente del modelo en el que
aparecen.
Los componentes del modelo as, como la relacin entre ellos, se

pueden presentar en forma esquemtica como se muestra en la
siguiente figura.
CIBERTEC
Figura 4. Componentes del modelo CMMI
2.2. rea de proceso
Un rea de proceso es un grupo de prcticas relacionadas en un rea

que, cuando se implementan de forma conjunta, satisface un grupo de
objetivos considerados importantes para la mejora en ese campo.
Existen 22 reas de proceso:
1. Anlisis causal y resolucin (CAR)
2. Gestin de configuracin (CM)
3. Anlisis de decisiones y resolucin (DAR)
4. Gestin integrada del proyecto + IPPD (IPM + IPPD)1
5. Medicin y anlisis (MA)
6. Innovacin y despliegue en la organizacin (OID)
7. Definicin de procesos de la organizacin + IPPD (OPD + IPPD)1
8. Enfoque en procesos de la organizacin (OPF)
9. Rendimiento del proceso de la organizacin (OPP)

16
10. Formacin organizativa (OT)

11. Integracin de producto (PI)
12. Monitorizacin y control del proyecto (PMC)
13. Planificacin de proyecto (PP)
14. Aseguramiento de la calidad de proceso y de producto (PPQA)
15. Gestin cuantitativa de proyecto (QPM)
16. Desarrollo de requerimientos (RD)
17. Gestin de requerimientos (REQM)
18. Gestin de riesgos (RSKM)
19. Gestin de acuerdos con proveedores (SAM)
20. Solucin tcnica (TS)
21. Validacin (VAL)
22. Verificacin (VER)
2.2.1. Elementos del rea de proceso
Declaraciones de propsitos
Describen la finalidad del rea de proceso. Son componentes
informativos.
Notas introductorias
Describen los conceptos principales cubiertos por el rea de proces. Son
componentes informativos.
reas de proceso relacionadas

Listan las referencias a las que estn en relacin y reflejan las relaciones
de alto nivel entre stas. Es un componente informativo.
CIBERTEC
Metas especficas
Describen las caractersticas nicas que deben estar presentes para
satisfacer el rea de proceso. Son componentes requeridos del modelo
que se utilizan en las evaluaciones para ayudar a determinar si se
satisface un rea de proceso. Solamente, son elementos requeridos del
modelo la declaracin de meta especfica. El ttulo de una meta
especfica (precedido por el nmero del objetivo) y todas las notas
asociadas a la meta se consideran componentes informativos del
modelo.
Metas genricas
Se denominan as porque la misma declaracin de sta se aplica a
mltiples reas de proceso. Describen las caractersticas que deben
estar presentes para institucionalizar los procesos que las implementan.
Son componentes requeridos del modelo y se utilizan en las
evaluaciones para determinar si se satisface un rea de proceso.
Resmenes de metas y prcticas especficas

Proporcionan un resumen de alto nivel de las metas especficas, que son
componentes requeridos; y de las prcticas especficas, que son
componentes esperados. es un componente informativo.
Prcticas especficas
Son descripciones de una actividad que se consideran importantes para
alcanzar la meta especfica asociada. Describen las actividades que se
espera que produzcan la consecucin de las metas especficas de un
rea de proceso. Son componentes esperados del modelo.
Productos de trabajo tpicos

Muestran los resultados de una prctica especfica. Estos ejemplos se
denominan as porque, a menudo, hay otros productos de trabajo que
son igual de eficaces, pero no estn en la lista. Son componentes
informativos del modelo.

18
Subprcticas
Son descripciones detalladas que proporcionan una gua para interpretar
e implantar una prctica especfica o genrica.
Las subprcticas pueden tomar un carcter prescriptivo, pero realmente
son componentes informativos indicados slo para proporcionar ideas
que puedan ser tiles para la mejora de proceso.
Prcticas genricas
Se denominan as porque la misma se aplica a mltiples reas de
proceso. Son descripciones de una actividad que se considera
importante para el logro de la meta genrica asociada. Son
componentes esperados del modelo.
Elaboraciones de las prcticas genricas

Aparecen despus de una prctica genrica en un rea de proceso, para
proporcionar una gua sobre cmo la primera debera aplicarse de forma
exclusiva a la segunda. Son componentes informativos del modelo.
Componentes informativos de soporte

En muchos sitios, se necesita ms informacin para describir un
concepto.
Este material informativo se presenta como uno de los siguientes
componentes:
Notas
Ejemplos
Ampliaciones
Referencias
Esquema de numeracin
Las metas especficas y genricas se numeran secuencialmente.
Cada meta especfica empieza con el prefijo SG (p. ej. SG 1).
Cada meta genrica empieza con el prefijo GG (p. ej. GG 2).
Cada prctica especfica empieza con el prefijo SP, seguido por un
nmero en la forma x.y (p. ej. SP 1.1). La x es el mismo nmero de la
CIBERTEC
meta a la que pertenece la prctica especfica. La y es el nmero de

secuencia de la prctica especfica para la meta correspondiente.
Un ejemplo de numeracin de prctica especfica est en el rea de

proceso de Planificacin de proyecto. La numeracin de la primera
prctica especfica es SP 1.1 y la segunda SP 1.2.
Cada prctica genrica empieza con el prefijo GP, seguido por un

nmero en la forma x.y (p.ej. GP 1.1). La x corresponde al nmero de la
meta genrica. La y es el nmero de secuencia de la prctica genrica
para la meta correspondiente. Por ejemplo, la primera prctica genrica
asociada con GG 2 se numera GP 2.1 y la segunda GP 2.2.

20
Figura 5.a. Elementos del rea de proceso
CIBERTEC
Figura 5.b. Elementos del rea de proceso

22
Figura 5.c. Elementos del rea de proceso
CIBERTEC
UNIDAD DE
APRENDIZAJE
EL CICLO DE VIDA DEL DESARROLLO DE SW Y SUS
ENTREGABLES
Al trmino de la unidad, el alumno, clasifica y explica los artefactos utilizados

en las etapas correspondientes al ciclo de vida de desarrollo de software
alineado con las prcticas del modelo CMMI.
TEMARIO
Tema 3: El ciclo de vida del desarrollo de software

3.1 Ciclo de vida del software
3.2 El papel de la certificacin de la calidad del software en sus etapas de
desarrollo
Tema 4: Gestin y Calidad

4.1 Procesos de gestin de proyectos e ingeniera de software
4.2 Procesos de aseguramiento de la calidad del producto y del proceso

24
3. INTRODUCCIN AL CICLO DE VIDA DEL SW
3.1. Ciclo del vida del software
El trmino ciclo de vida del software describe su desarrollo, desde la

fase inicial hasta la final. El propsito de este programa es definir las
distintas fases intermedias que se requieren para validar el desarrollo
de la aplicacin, es decir, para garantizar que el software cumpla los
requisitos para la aplicacin y verificacin de los procedimientos de
desarrollo: se asegura que los mtodos utilizados sean apropiados.
Estos programas se originan en el hecho de que es muy costoso

rectificar los errores que se detectan tarde dentro de la fase de
implementacin. El ciclo de vida permite que se detecten lo antes
posible y, por lo tanto, permite a los desarrolladores concentrarse en la
calidad del software, en los plazos de implementacin y en los costos
asociados.
El ciclo de vida bsico de un software consta de los siguientes

procedimientos:
Definicin de objetivos: se encarga de definir el resultado del

proyecto y su papel en la estrategia global.
Anlisis de los requisitos y su viabilidad: su funcin es recopilar,
examinar y formular los requisitos del cliente y analizar cualquier
restriccin que se pueda aplicar.
Diseo general: son requisitos generales de la arquitectura de la
aplicacin.
Diseo en detalle: es la definicin precisa de cada subconjunto de
la aplicacin.
Programacin (programacin e implementacin): es la
implementacin de un lenguaje de programacin para crear las
funciones definidas durante la etapa de diseo.
CIBERTEC
Prueba de unidad: es la prueba individual de cada subconjunto de

la aplicacin para garantizar que se implementaron de acuerdo con
las especificaciones.
Integracin: su funcin es garantizar que los diferentes mdulos se
integren con la aplicacin. ste es su propsito, la cual est
cuidadosamente documentada.
Prueba beta (o validacin): se encarga de garantizar que el
software cumpla con las especificaciones originales.
Documentacin: sirve para documentar informacin necesaria
para los usuarios del software y para desarrollos futuros.
Implantacin: se refiere al despliegue o puesta en marcha de la
aplicacin por parte de los usuarios.
Mantenimiento: estn dirigidos para todos los procedimientos
correctivos (mantenimiento correctivo) y las actualizaciones
secundarias del software (mantenimiento continuo).
El orden y la presencia de cada uno de estos procedimientos en el ciclo

de vida de una aplicacin dependen del tipo de modelo de ciclo de vida
acordado entre el cliente y el equipo de desarrolladores.
3.2. El papel de la certificacin de la calidad del software en sus

etapas de desarrollo
Un proceso de certificacin de la calidad de software debe considerar

un conjunto de actividades planificadas y sistemticas que prueben y
aporten la confianza en que la aplicacin (software) satisfar los
requisitos dados de calidad y que son los que el usuario final espera
recibir.
Ello implica que el aseguramiento de calidad debe estar presente en
Mtodos y herramientas de anlisis, diseo, programacin y prueba

Inspecciones tcnicas formales en todas las etapas del proceso de
desarrollo del software: anlisis, diseo, programacin y pruebas

26
Control de la documentacin del software y de los cambios

realizados
Procedimientos para ajustarse a los estndares establecidos
Mecanismos de medida (mtricas)
Registro de auditoras y realizacin de informes
A continuacin, se mostrar una visin general sugerida de los procesos

de TI.
Figura 6: Visin general del proceso de TI
Estos procesos tienen tres grandes frentes que cubrir:
Los procesos que se derivan de la ingeniera de software

Los procesos que se derivan de la gestin de los proyectos
Los procesos que se derivan los procesos de aseguramiento de la calidad
CIBERTEC
4. GESTIN Y CALIDAD
4.1. PROCESOS DE GESTIN DE PROYECTOS E INGENIERA

DE SOFTWARE
ANLISIS DE LA NECESIDAD
Sus objetivos son los siguientes:
Comprender los problemas de los usuarios y proponer soluciones

que cubran sus necesidades
Conseguir la mayor comprensin posible antes de que empiece el
desarrollo
Explorar y comprender el entorno del cliente
El anlisis de la necesidad comprende lo siguiente:
1.- Identificacin del problema
2.- Identificacin de las partes implicadas
3.- Delimitacin de la solucin
4.- Identificacin de las restricciones
PLANIFICACIN DE LA DEMANDA
Consiste en la priorizacin de Requerimientos por parte de los

Lderes Usuarios y Sistemas (Cartera de Proyectos alineados al Plan
Estratgico de Negocios).
Se revisan y negocian los presupuestos y prioridades por unidades
de negocio.
El sistema realiza la planificacin de la demanda basada en la
capacidad instalada, la cual se ver reflejada en el plan de trabajo.
Esta etapa termina con una hoja de compromiso de requerimientos
priorizados y un plan de trabajo detallado.

28
ANLISIS
El objetivo es crear una variedad de representaciones que muestran

los requisitos del software para la informacin, la funcin y el
comportamiento.
Es importante porque sirve para validar los requisitos en mltiples
dimensiones incrementando la posibilidad de encontrar errores,
identificar inconsistencias y descubrir omisiones.
Presenta dos diferentes filosofas: Anlisis Estructurado y/o anlisis
Orientado a Objetos
La etapa de anlisis de sistemas de informacin, por ser la raz del ciclo

de vida del desarrollo de aplicaciones, constituye tambin la base de un
sistema bien consolidado. Al igual que los cimientos de una casa
precariamente construida, si el anlisis es llevado de manera superficial
y/o no se toman en cuenta medidas de control que permitan asegurar
que estn siendo captados claramente los requerimientos y expectativas
del usuario final, es muy probable que el software termine siendo
rechazado al trmino de su desarrollo o dejado de usar en poco tiempo
cuando ste traiga ms problemas que facilidades para quienes
terminan siendo los usuarios directos.
Es importante tener en cuenta que es necesario ayudar al usuario a

manifestar claramente sus necesidades, pues, muchas veces, las
diferencias de lenguaje utilizado en la captacin de requerimientos
(lenguaje tcnico de los desarrolladores vs. lenguaje de usuario) llevan
a la captacin errnea o confusa de las verdaderas necesidades del
usuario final.
Se debe recordar que lo ms probable es que el usuario no cuente con

todos los detalles que necesita o, ms an, quizs no tenga clara la idea
de lo que solicitar. Es por ello que el especialista debe asegurarse de
hacer las preguntas clave para captar lo que realmente el cliente
necesita y no lo que l cree que requiera.
CIBERTEC
El usuario debe aprobar la redaccin de los requerimientos a nivel

bsico.
Es necesario e importante aclarar que los profesionales responsables de

la ejecucin de proyectos no satisfacen expectativas, sino las
transforman en requerimientos. Es por ello que los analistas deben
poseer la capacidad necesaria para cumplir esto.
Ejemplo 1:
Expectativa: el usuario requiere que el software sea amistoso.

Requerimiento: el software debe de contar con botones de navegacin
y con ayudas en cada una de las pantallas.
Ejemplo 2:
Expectativa: el software no debe ser lento.
Requerimiento: los reportes ejecutivos no deben tardar ms de 30

segundos.
Es por ello que en la etapa de anlisis deben aplicarse las siguientes medidas
de control de calidad:
1) Es de mxima importancia que el proceso o procesos sobre los cuales va a

operar el sistema se encuentren claramente definidos y documentados
(normalizados). Su verificacin y exigencia es uno de los primeros pasos hacia
el software de calidad.
2) Es sabido que para la captacin de los requerimientos es necesario que se

lleven a cabo juntas con los usuarios lderes de los procesos involucrados.
Cada reunin de levantamiento de informacin, debe de generar un entregable:
acta y/o un formulario donde se registren todos los acuerdos de dicha sesin.
Cabe resaltar que estas actas deben de ser documentos formales, ya que en

30
muchos casos sirven de apoyo o de referente para determinados

procedimientos de control.
Es recomendable usar formularios para el registro de los requerimientos.
Los requerimientos son de dos tipos:
Requerimientos funcionales: relacionados con los objetivos que se

buscan alcanzar con el uso de la aplicacin.
Requerimientos tcnicos: relacionados con la operatividad misma de los
aplicativos involucrados (requerimientos tcnicos). Se detalla cmo es que
se llegar a atender el requerimiento funcional. Cabe resaltar que un
requerimiento funcional puede involucrar uno o ms tcnicos.
A continuacin, se muestran algunos formularios propuestos para el registro de

los requerimientos funcionales y tcnicos:
Luego de llevadas a cabo las reuniones de levantamiento de informacin, es

necesario que se elabore un documento base que consolide todos los
requerimientos, alcances y observaciones obtenidas de los usuarios. En
algunas metodologas de desarrollo de proyectos, los llaman Project Charter;
en otras, Documento de Anlisis. Este es el documento principal del proyecto.
Contiene las pautas principales del sistema: objetivos, alcances, entregables,
exclusiones, suposiciones, diagramas de flujo, Stakeholders (grupos de
inters), etc.
Se recomienda que, en esta etapa, se consideren los siguientes entregables:
Verificacin del alcance: aceptacin de los lineamientos y lmites del

proyecto.
Documento base: aceptacin del documento donde se detalla el anlisis del
software llevado a cabo por el equipo del proyecto.
Lista de requerimientos: aceptacin de los requerimientos funcionales y
tcnicos.
CIBERTEC
Una vez aprobada esta documentacin debe de almacenarse en el portafolio

del proyecto, de manera que se asegure su calidad en cada una de las etapas.
Esta aceptacin debe de ser hecha con carcter formal por los clientes o por
los usuarios finales del proyecto.
DISEO
Se desarrolla una descripcin de la estructura interna y la organizacin del

sistema (base para su construccin).
Es importante porque permite modelar el sistema o producto que se va a
construir.
Comprende dos actividades intermedias: Diseo de la arquitectura del
software y el diseo detallado del software.
Paralelamente, se inician el Manual de usuario y del sistema.
En esta etapa, se deben definir todas las caractersticas necesarias para la

realizacin y entrega del producto.
Ejemplo:
Supongamos que se ha encargado a un grupo de profesionales la construccin
de una nueva casa. Como resultado del anlisis, se concluy lo siguiente:
El rea del terreno es de 200 metros cuadrados.
El cliente desea lo siguiente:
o Una casa amplia tres pisos
o En el primer piso, el rea social y de servicio
o En el segundo piso, los cuartos (cuatro)
o En el tercer piso, sala de estudio
Asumamos que el equipo encargado de construir la casa presente los planos.

Nosotros, los clientes,los aprobamos y, finalmente, volvemos a ver a los
profesionales cuando la casa est construida. Qu pasara con el proyecto?
Lo ms probable es que nosotros, como clientes, estemos descontentos dado
que nuestra casa no qued como nosotros la habamos imaginado y, lo que es
peor, qued como los profesionales se lo imaginaron lo que traera como
consecuencia, entre otros temas: prdida de dinero y tiempo, descontento,

32
frustracin y la sensacin de que el nivel de profesionalismo del equipo

responsable de la construccin es totalmente precaria. En estas circunstancias,
todos perdemos: nosotros (el usuario), como clientes, y el proveedor (los
profesionales en sistemas).
De manera similar, puede pasar en un proyecto de software. Luego de que el
cliente aprueba el anlisis, se le contacta cuando el sistema ya est construido.
Si esto ocurre, se tendr como consecuencia que no se cumpla con sus
expectativas y, seguramente, se escucharn frases ya conocidas:
Por parte del usuario:
- Esto no es lo que yo quera.
- No me entendiste lo que yo te quise decir.
- Pero se supona
- Este sistema no me sirve para nada: no cumple ni siquiera con mis

requerimientos bsicos.
- Mejor estaba el sistema antiguo.
- Mejor lo sigo haciendo manualmente.
CIBERTEC
Por parte del equipo de Desarrollo de sistemas:
- En el documento de anlisis, deca que el sistema iba a ser as.
- Usted me aprob el documento de anlisis.
- El sistema no inclua esa pantalla
Para evitar estos contratiempos y malos entendidos, se recomienda lo

siguiente:
Prototipos funcionales: donde se muestren las pantallas preferentemente con

datos (pueden ser datos ficticios).
Navegacin: se debe navegar en los prototipos, de manera que el usuario
pueda percibir el flujo funcional que podra tener su sistema.
A travs de los prototipos, el usuario podr retroalimentar y observar cualquier

detalle que el equipo de desarrollo haya podido pasar por alto.
Con los prototipos, el usuario podr aterrizar y comprobar que sus
expectativas han sido cubiertas a travs de los requerimientos recogidos en la
etapa de anlisis.
Finalmente, con los prototipos se consigue lo siguiente:
a) Tener una idea ms tangible de cmo ser el sistema finalmente
funcionando
b) Emitir un juicio sobre lo acertado de la interpretacin de sus
requerimientos y hacer recomendaciones, sugerencias y cambios al
respecto antes de que comience el desarrollo oficial.
c) Identificar detalles que no podan preverse fcilmente sin tener un
sistema corriendo frente a uno.
Hay que aadir que los prototipos son un primer gran paso hacia el
aseguramiento de la calidad, pues debe simular de la manera ms exacta
posible el comportamiento del sistema que se est desarrollando. Debe ser
aprobado por el usuario, por escrito, siempre y cuando ste cumpla con sus
expectativas.

34
Puede suceder que con los prototipos surjan cambios que pudiesen afectar el
alcance y lo definido en la etapa de anlisis. Ser labor del equipo del proyecto
evaluar si stos se encuentran dentro del alcance del proyecto o no. En el caso
de que se acepten los cambios, debe revisarse y, si es necesario, modificar la
documentacin presentada en la etapa de anlisis. En consecuencia, el equipo
del proyecto deber de aprobar nuevamente dicha documentacin. De la
misma forma, en el caso de que las observaciones no se acepten por estar
fuera de los lmites del proyecto, es necesario que quede formalmente
documentado y aceptado por los usuarios de que stas no sern incluidas en el
proyecto.
Adicionalmente, en esta etapa, se deben definir los procesos de desarrollo,

tareas y responsabilidades de los equipos de desarrollo. Dichos procesos
pueden estar estandarizados, por lo cual puede certificarse que el trabajo se
realiza bajo alguna norma de calidad, como puede ser ISO 9000-3:1993, que
establece guas de accin para la aplicacin de ISO 9001, orientada al
desarrollo, suministro y manutencin de software.
En esta etapa, la calidad aumenta en la medida que se realiza una alta

especificacin de los procesos y se propone una estrecha tolerancia a la
modificacin estableciendo los mtodos correctivos a las desviaciones
ocurridas.
Se recomienda que se consideren los siguientes entregables:
- Prototipo del proyecto
- Cronograma del proyecto
- Documentos base del proyecto (en el caso se hayan suscitado cambios

en el alcance)
- Especificaciones funcionales de cada una de los componentes del

proyecto: Debe establecerse el comportamiento del sistema en todas las
situaciones posibles de cada uno de sus componentes (todas las posibles
variantes de una situacin en particular). stas deben revisarse
CIBERTEC
detalladamente con el usuario para asegurarse que se estn cubriendo

correctamente los diferentes comportamientos del sistema.
- Casos de prueba funcionales: se encarga de elaborar casos de prueba

de comportamiento del sistema. No deben ser tcnicos. Se elaboran luego
de terminado el prototipeo. Usa como base las especificaciones funcionales.
- Especificaciones de programacin: (documentacin tcnica, para los

programadores)
Al igual que en la etapa de anlisis, cada uno de estos entregables deben de

ser aprobados formalmente por los usuarios finales del proyecto.
CONSTRUCCIN
En esta etapa, es cuando el equipo de programacin inicia la creacin del

software.
Se codifica todos los componentes especificados en el diseo de procesos,
siguiendo las normas y estndares establecidos.
Se obtienen los componentes codificados y, luego, se prueban de acuerdo
con las especificaciones en las etapas anteriores.
Paralelamente, se continan con las modificaciones que sean necesarias al
Manual de usuario y del Sistema.
En esta etapa, es donde se llevan a cabo las pruebas informales del software y
se da cuando el programador prueba que el cdigo fuente escrito compile y se
asegura que el programa no aborte en su ejecucin. Si bien es cierto estas
pruebas informales son parte del desarrollo de un software, stas no deben de
ser las nicas que garanticen el buen funcionamiento de un programa.
En esta etapa, se recomienda lo siguiente:
- El programador siga las especificaciones de programacin, facilitadas por el

Jefe responsable de dicha tarea.

36
- El programador siga los estndares de programacin as como la metodologa

ya pudiese existir en la organizacin. En el caso de que no se cuente con
metodologa ni estndares, se recomienda que, antes de iniciar cualquier
proyecto de construccin del software, stos ya se encuentren definidos, ya
que, de lo contrario, la probabilidad de encontrar errores de programacin
aumenten.
- El programador codifique lo menos posible. Es mejor que ste utilice libreras

y/o componentes ya existentes.
- El programador debe de asegurarse que las especificaciones funcionales se

estn cumpliendo.
- El Jefe responsable de los programadores, de forma aleatoria o de acuerdo

con su criterio, revise el cdigo fuente de los aplicativos, de manera que se
asegure de que se estn cumpliendo con los estndares, metodologas y las
normas fijadas para una adecuada programacin.
Los entregables de esta etapa deben ser los siguientes:
- Programas culminados
- Documentacin de las pruebas realizadas por el programador
- Documentacin de que el aplicativo cumple con las especificaciones

funcionales
- Documentacin de los aplicativos revisados por los Jefes de los

programadores
CERTIFICACIN
Verifica que los aplicativos nuevos o modificados, que utilizar el usuario

final, tengan los niveles de calidad requeridos.
Asegura el nivel de calidad del sistema y la conformidad del cliente.
La certificacin de calidad implica verificar los resultados especficos del

proyecto para determinar si stos cumplen con los estndares de calidad
CIBERTEC
relevantes e identificar maneras de eliminar las causas de los resultados

insatisfactorios. Esto debe ser realizado durante todo el proceso. Los
resultados del proyecto incluyen tanto los referidos al producto del proyecto,
tales como entregables, y a los referidos a la direccin del proyecto, tales como
los desempeos de costo y cronograma.
La certificacin de calidad sugiere una vigilancia permanente a todo el proceso

de desarrollo y ciclo de vida del software. Esta meta puede alcanzarse
mediante frecuentes inspecciones a las metodologas de trabajo y uso de
herramientas, revisiones de prototipos y testeo exhaustivo de los productos
finales.
La certificacin de calidad permite realizar las rectificaciones pertinentes al

desarrollo en cuanto ste empieza a desviarse de sus objetivos.
En la certificacin de calidad, se deben tener presente los costos que ste

involucra. Si se piensa en las tareas que se debe realizar en este control,
puede observase que es necesario llevar a cabo actividades de bsqueda de
problemas, testeo, realimentacin, rectificacin, elaboracin, modificacin y
estudio de la documentacin; entre otras actividades. Todas ellas tienen costos
involucrados (incluso, puede darse la inclusin de equipos destinados al
aseguramiento de la calidad).
Sin embargo, debe existir un compromiso, ya que un excesivo costo en el

control de la calidad puede hacer que este proceso se torne ineficiente. Pero,
por otra parte, el mejoramiento de la calidad implica reducir los costos, ya que
se tendra un cierto nivel de calidad ya asegurado.
Finalmente, y como consecuencia de la naturaleza del proceso de desarrollo de

productos software, el asegurar la calidad en sus primeras etapas involucra que
los costos del control en las etapas posteriores tender a disminuir al tener
menos aspectos que controlar, pues, nuevamente, la calidad estara asegurada
en sus bases.

38
El equipo encargado de controlar la calidad debe de tener en cuenta lo

siguiente:
Prevencin: es todo acto que ayude a mantener todos los errores fuera
del proceso.
Pruebas: ayuda a evitar que los errores lleguen a manos del cliente.
Los entregables de esta etapa deben ser los siguientes:

- Mejora de la calidad: implica tomar acciones para incrementar la efectividad
y eficiencia del proyecto para brindar beneficios adicionales. En muchos
casos, esto requerir preparar requerimientos de cambio o la realizacin de
acciones correctivas y ser manejada de acuerdo con los procedimientos de
control de cambios.
- Decisiones de aceptacin: se refiere cuando los aplicativos probados

sern aceptados o rechazados. Estos ltimos pueden requerir re- procesos.
El reproceso es la accin llevada a cabo para lograr que un artculo
defectuoso o no conforme cumpla los requerimientos o especificaciones. El
reproceso imprevisto es una de las causas frecuentes de sobrecostos y
retrasos. El equipo de proyecto debe de hacer todo esfuerzo razonable para
minimizarlo.
- Listas de verificacin completada: incluyen los documentos donde se
puede corroborar todo aquello que ha sido probado (listas de chequeo).
- Ajustes del proceso: implican acciones correctivas o preventivas inmediatas,
como resultado de las mediciones de control de calidad. En algunos casos,
pueden requerir ser manejados de acuerdo con el procedimiento de control
de cambios.
Ms adelante, se detallarn las distintas metodologas existentes para llevar a

cabo las pruebas de software.
El siguiente grfico muestra distintos factores a validar y verificar durante el

ciclo de vida de una aplicacin de software.
CIBERTEC
PRODUCCIN
Mover componentes a libreras de produccin (Incluir informe de cierre)

Actualizar Schedule, parmetros del sistema, conversin de archivos, etc.
Implementar la(s) solucin(es) en servidores
Monitorear los ambientes de produccin y seguimiento del uso del
aplicativo
Monitorear consumo de recursos y performance
La Certificacin de Software en el ciclo de vida de los Sistemas
Verificacin de Verificacin de
Documento Funcional, Tcnico, programas (pruebas unitarias/integracin),
Certificacin manual de instalacin
Anlisis Diseo Construccin Certificacin
Validacin
Programas
UP (Certificacin)
Validacin Manuales
Documento Manual de Instalacin
Especificaciones Funcionales Build Document, Manual de
(Procedimiento de validacin Sistemas
de documentos) Manual de Errores, Manual del
Usuario
Norma
Figura 7: Certificacin del software en el ciclo de vida del software

40
Figura 8 Entregables del desarrollo de software
4.2. PROCESOS DE ASEGURAMIENTO DE LA CALIDAD DEL

PRODUCTO Y PROCESO
La funcin de aseguramiento de calidad (QA) ayuda a
Dar una visin objetiva de que los procesos (los nuevos, as como
aquellos que presumiblemente estn bien consolidados):
Son eficaces
Se siguen por parte del personal y de los proyectos
Promover la mejora continua y establecer mtodos de trabajo

efectivos, consensuados con personal clave de la organizacin
(por ejemplo el Equipo de Procesos, metodologas, etc.)
CIBERTEC
Informar a la direccin de problemas detectados en la implantacin

de los procesos, de manera que se analicen las causas y se
emprendan las acciones correctivas/de mejora pertinentes
Asegurar que las soluciones son eficientes, de alta calidad y

recogen los requisitos del cliente
Reconocer, controlar y/o mitigar cualquier riesgo que ponga en

peligro el xito de un proyecto
QA no valida los productos, sino que verifica que se desarrollen

siguiendo los procesos definidos
La organizacin y su direccin tiene que creer en el valor de los

procesos y la fidelidad a los mismos, porque la calidad de los productos
depende de la calidad de los procesos usados para desarrollarlos y/o
mantenerlos.
Por lo tanto, un proyecto que ejecuta las actividades, de manera

conforme a unos procesos bien definidos y controlados, est
construyendo un producto de mayor calidad
QA verifica que los productos se construyen siguiendo los procesos

definidos, detectando no-conformidades cuanto antes posible, ayudando
a resolver estas no-conformidades y asegurndose que se corrijan y no
se repitan. De esta forma, se est garantizando el incremento de la
calidad entregada al cliente y consecuentemente la reduccin de los
costes de correccin.

42
CIBERTEC
UNIDAD DE
APRENDIZAJE
ARQUITECTURA DEL MODELO CMMI
Al trmino de la unidad, el alumno comprende, reconoce y explica la estructura

por niveles del modelo CMMI.
TEMARIO
Tema 5: Objetivos y Prcticas genricas

5.1. Especificacin de los objetivos y prcticas genricas
Tema 6: Objetivos y Prcticas especficas

6.1. Especificacin de los objetivos y prcticas especficas

44
5. OBJETIVOS Y PRCTICAS GENRICAS
5.1. Especificacin de los objetivos y prcticas genricas
En la representacin por niveles (ver Fig. 8), cada uno contiene varias reas
de proceso, las que, a su vez, quedan definidas por uno o varios objetivos
especficos y uno genrico. Cada uno de ellos, est vinculado con un
conjunto de prcticas, llamadas especficas y genricas, respectivamente.
Figura 8. Estructura de la representacin por niveles
5.2. Objetivos y Prcticas Genricas
Los objetivos y prcticas genricas tienen que ver con el grado de

institucionalizacin de los procesos (compromiso con la ejecucin,
capacidad para ejecutar, direccin de la ejecucin, verificacin de la
ejecucin). Son llamados as porque son los mismos en todas las reas de
proceso (aunque hay aspectos especficos para cada una de ellas). Cumplir
con un objetivo genrico de un rea de proceso determinada implica tener
un mayor control de la planificacin e implementacin de los procesos
vinculados a sa. En el nivel 2, el objetivo (GG) y las prcticas genricas
(GP) son los siguientes:
CIBERTEC
GG 2 Institucionalizar un proceso administrado

El proceso est institucionalizado como uno gestionado.
1. GP 2.1 Establecer polticas organizacionales
Establecer y mantener una poltica de la organizacin para planificar

y realizar el proceso
Su propsito es definir las expectativas de la organizacin en
relacin con el proceso y hacerlas visibles a aquellos en la
organizacin que estn afectados. En general, la direccin es
responsable de establecer y comunicar los principios, guas,
orientacin y expectativas para la organizacin. No toda orientacin
de la direccin llevar la etiqueta poltica. Lo que se espera es la
existencia de una orientacin apropiada de la organizacin,
independientemente de cmo sea llamada o comunicada.
2. GP 2.2 Planificar el proceso
Establecer y mantener el plan para realizar el proceso
Su propsito es determinar lo que se necesita para realizar el

proceso y lograr los objetivos establecidos, elaborar un plan para
realizar el proceso, detallar una descripcin del proceso y acordar el
plan con las partes interesadas relevantes.
Las implicaciones prcticas de la aplicacin de una prctica

genrica varan para cada rea de proceso. Por ejemplo, la
planificacin descrita por esta prctica genrica, como se aplica al
rea de proceso de Monitorizacin y control de proyecto, puede ser
llevada a cabo completamente por los procesos asociados con el
rea de proceso de Planificacin de proyecto. Sin embargo, cuando
se aplica al rea de proceso de Planificacin de proyecto, establece
una expectativa de que se ha planificado el proceso de planificacin
del proyecto en s mismo. Por lo tanto, esta prctica genrica puede
bien reforzar las expectativas establecidas en otros lugares del
CMMI o establecer nuevas expectativas que deberan tratarse.
Establecer un plan incluye documentarlo y realizar una descripcin

46
del proceso. Mantenerlo incluye su actualizacin para reflejar las

acciones correctivas o cambios en los requerimientos o en los
objetivos.
Para realizar el proceso, el plan normalmente incluye:

Descripcin del proceso
Estndares y requerimientos para los productos de trabajo y
los servicios del proceso
Metas especficas para el rendimiento del proceso (p. ej.
calidad, escala de tiempo, tiempo de ciclo y utilizacin de
recurso)
Dependencias entre las actividades, los productos de trabajo
y los servicios del proceso
Recursos (incluyendo financiacin, personas y herramientas)
necesarios para realizar el proceso
Asignacin de responsabilidad y de autoridad
Formacin necesaria para realizar y dar soporte al proceso
Productos de trabajo a controlar y nivel de control a aplicar
Requerimientos de medicin para proporcionar una visin del
rendimiento del proceso, sus productos de trabajo y sus
servicios
Involucrar a las partes interesadas identificadas
Actividades de monitorizacin y control del proceso
Actividades de evaluacin objetiva del proceso
Actividades de revisin de la gerencia para el proceso y para
los productos de trabajo
CIBERTEC
Subprcticas
A. Definir y documentar el plan de realizacin del proceso

Este plan puede ser un documento independiente, incorporado en
uno ms completo o asignarlo en otros. En el caso de que el plan
est distribuido en varios documentos, hay que asegurarse que se
conserva una visin coherente de quin lo ha hecho. Los
documentos pueden estar en papel o en formato electrnico.
B. Definir y documentar la descripcin del proceso

La descripcin del proceso, que incluye los estndares y
procedimientos relevantes, puede incluirse como parte del plan de
realizacin del proceso o referenciarse en el mismo.
C. Revisar el plan con las partes interesadas relevantes y

obtener su acuerdo
Esto incluye la revisin de que el proceso planificado satisface las
polticas aplicables, los planes, los requerimientos y los estndares
para proporcionar aseguramiento a las partes interesadas
relevantes.
D. Corregir el plan, segn sea necesario
3. GP 2.3 Proveer Recursos
Proporcionar recursos adecuados para realizar el proceso,

desarrollar los productos de trabajo y proporcionar los servicios del
proceso
Su propsito es asegurar que los recursos necesarios, para realizar

el proceso tal y como se definieron en el plan, estn disponibles
cuando se necesiten. Los recursos incluyen financiacin adecuada,
instalaciones fsicas apropiadas, personal cualificado y herramientas
apropiadas.

48
La interpretacin del trmino adecuado depende de muchos

factores y puede cambiar con el tiempo. Los recursos inadecuados
pueden tratarse incrementando stos o eliminando requerimientos,
restricciones y compromisos.
4. GP 2.4 Asignar responsabilidades
Asignar la responsabilidad y la autoridad para realizar el proceso,

desarrollar los productos de trabajo y proporcionar los servicios del
proceso.
Su propsito es asegurar que existe responsabilidad para realizar el

proceso y lograr los resultados especificados a lo largo de la vida de
ste. Las personas asignadas deben tener la autoridad apropiada
para realizar las responsabilidades asignadas.
La responsabilidad puede asignarse usando descripciones

detalladas del trabajo o en documentos operativos, tales como el
plan de realizacin del proceso. La asignacin dinmica de
responsabilidades es otra forma legtima de realizar esta prctica
genrica, siempre y cuando la asignacin y la aceptacin estn
aseguradas durante la vida del proceso.
Subprcticas
A. Asignar la responsabilidad y la autoridad en su totalidad para

realizar el proceso
B. Asignar la responsabilidad y la autoridad para realizar las tareas

especficas del proceso
C. Confirmar que las personas a las que se les asign

responsabilidad y autoridad las comprenden y las aceptan
CIBERTEC
5. GP 2.5 Entrenar al personal
Formar, segn sea necesario, a las personas para realizar o dar

soporte al proceso
Su propsito es asegurar que las personas tengan las habilidades y

la experiencia necesaria para realizar o dar soporte al proceso.
Las personas que realizarn el trabajo reciben una formacin

apropiada.
Se proporciona una formacin general para orientar a las personas

que interactan con los que realizan el trabajo.
Ejemplos de mtodos para proporcionar formacin incluyen el

autoestudio, la autoformacin dirigida, a su propio ritmo, instruccin
programada, formacin en el puesto de trabajo, tutora y formacin
formal en el aula.
La formacin da soporte a la realizacin satisfactoria del proceso

estableciendo una comprensin comn del proceso e impartiendo
las habilidades y conocimientos necesarios para realizar el proceso.
Para ms informacin sobre la formacin de las personas para

realizar o dar soporte al proceso, consltese el rea de proceso de
formacin organizativa.
6. GP 2.6 Administrar la configuracin
Poner los productos de trabajo designados del proceso bajo los

niveles de control apropiados
Su propsito es establecer y mantener la integridad de los

productos de trabajo designados del proceso (o de sus
descripciones) a lo largo de su vida til.
stos se encuentran especficamente identificados en el plan de

realizacin del proceso, junto con una especificacin del nivel
apropiado de control.
Diferentes niveles de control son apropiados para distintos

productos de trabajo y en momentos diferentes. Para stos, puede

50
ser suficiente mantener el control de versiones (es decir, la versin

del producto de trabajo en uso en un momento dado, pasado o
presente, se conoce y los cambios se incorporan de una forma
controlada). ste se encuentra, generalmente, bajo el control
exclusivo del propietario del producto de trabajo (que puede ser un
individuo, un grupo o un equipo).
Algunas veces, puede ser crtico que los productos de trabajo se

pongan bajo gestin de configuracin formal o de referencia (lnea
base). Este tipo de control incluye la definicin y el establecimiento
de lneas base en puntos predeterminados. stas se revisan y
acuerdan formalmente, y sirven como base para desarrollos
posteriores de los productos de trabajo designados.
Para ms informacin sobre poner los productos de trabajo bajo

gestin de configuracin, consltese el rea de proceso de Gestin
de configuracin.
Son posibles niveles adicionales de control entre el de versin y la

gestin de configuracin formal. Un producto de trabajo identificado
puede estar bajo diversos niveles de control en diferentes
momentos.
7. GP 2.7 Identificar e involucrar a los interesados
Identificar e involucrar, cmo se planific, a las partes interesadas

relevantes del proceso
Su propsito es establecer y mantener la involucracin prevista de

las partes interesadas durante la ejecucin del proceso.
Consiste en involucrar a las partes interesadas relevantes, lo cual

sugiere actividades tales como
Planificacin
Decisiones
Compromisos
Comunicaciones
CIBERTEC
Coordinacin
Revisiones
Evaluaciones
Definiciones de requerimientos
Resolucin de problemas/cuestiones
Para ms informacin sobre la planificacin del proyecto para

involucrar a las partes interesadas, consltese el rea de proceso
de Planificacin de proyecto.
El objetivo de planificar el involucramiento de las partes interesadas

es asegurar que se realizan las interacciones necesarias al proceso,
a la vez que no se permite un nmero excesivo de grupos e
individuos afectados que impidan la ejecucin del proceso.
Subprcticas
A. Identificar a las partes interesadas relevantes a este proceso y su

involucramiento apropiado
Las partes interesadas relevantes se identifican entre los
proveedores de entradas (inputs), los usuarios de las salidas
(outputs) y los que realizan las actividades en el proceso. Una vez
que se identifican las partes interesadas relevantes, se planifica el
nivel apropiado de su involucramiento en las actividades.
B. Compartir estas identificaciones con los planificadores del

proyecto o con otros planificadores, segn sea apropiado
C. Involucrar a las partes interesadas relevantes, segn lo

planificado
8. GP 2.8 Monitorear y controlar los procesos
Monitorizar y controlar el proceso frente al plan para realizar el

proceso y tomar las acciones correctivas apropiadas.

52
Su propsito es realizar la monitorizacin y el control directo del

proceso, da a da. Se mantiene una visibilidad apropiada del
mismo, por lo que se pueden tomar acciones correctivas apropiadas
cuando sea necesario. Ello involucra medir los atributos apropiados
del proceso o de los productos de trabajo producidos por ste.
Para ms informacin sobre la monitorizacin y el control del

proyecto y la toma de acciones correctivas, consltese el rea de
proceso de Monitorizacin y control de proyecto.
Para ms informacin sobre la medicin, consltese el rea de

proceso de Medicin y anlisis.
Subprcticas
A. Medir el rendimiento real frente al plan de realizacin del proceso.

Las medidas son del proceso, de sus productos de trabajo y de sus
servicios.
B. Revisar los logros y los resultados del proceso frente al plan de

realizacin del proceso
C. Revisar las actividades, el estado y los resultados del proceso con

el nivel de gerencia inmediato responsable del proceso e identificar
los problemas.
stas proporcionar al nivel de gerencia inmediato la visibilidad
apropiada del proceso. Pueden ser peridicas o por eventos.
D. Identificar y evaluar los efectos de las desviaciones significativas

del plan de realizacin del proceso
E. Identificar los problemas en el plan de realizacin del proceso y

en la ejecucin del mismo
CIBERTEC
F. Tomar acciones correctivas cuando los requerimientos y los

objetivos no se satisfacen, cuando se identifican problemas o
cuando el progreso difiere significativamente del plan de realizacin
del proceso
Hay riesgos inherentes que deberan considerarse antes de que se

tome cualquier accin correctiva. sta puede incluir lo siguiente:
Tomar acciones correctoras para reparar los productos de

trabajo o los servicios defectuosos
Cambiar el plan de realizacin del proceso
Ajustar los recursos incluyendo personas, herramientas y
otros recursos
Negociar los cambios de los compromisos establecidos
Asegurar el cambio a los requerimientos y objetivos que
tienen que satisfacerse
Finalizar el esfuerzo
G. Seguir las acciones correctivas hasta el cierre.
9. GP 2.9 Evaluar adhesin objetivamente
Evaluar objetivamente la adherencia del proceso frente a la

descripcin del proceso, estndares y procedimientos, y tratar las
no conformidades
Su propsito es proporcionar un aseguramiento creble de que el

proceso se implement como estaba planificado y se adhiere a su
descripcin de proceso, estndares y procedimientos. Se
implementa, en parte, evaluando los productos de trabajo
seleccionados del proceso.
Las personas que no son directamente responsables de gestionar o

realizar las actividades del proceso evalan tpicamente la
adherencia.

54
En muchos casos, la adherencia se evala por personas que se

encuentran dentro de la organizacin, pero externas al proceso o al
proyecto, o que son externas a la entidad. Como resultado de ello,
el aseguramiento creble de la adherencia puede proporcionarse,
incluso, en los momentos en los que el proceso se encuentra bajo
estrs (p. ej., cuando se est retrasado o con el presupuesto
superado).
10. GP 2.10 Revisar el estado con la alta gerencia
Revisar con el nivel directivo las actividades, el estado y los

resultados del proceso, y resolver los problemas
Su propsito es proporcionar la visibilidad apropiada del proceso al

nivel directivo.
El nivel directivo incluye a aquellos niveles de gerencia en la

organizacin situados por encima del inmediato de gerencia
responsable del proceso. En particular, incluye a los directivos.
Estas revisiones son ellos, que proporcionan la poltica y la gua
global del proceso, y no para los que realizan la monitorizacin y el
control directo diario del proceso.
Diferentes directores tienen diferentes necesidades de informacin

sobre el proceso. Estas revisiones ayudan a asegurar que se
puedan tomar decisiones informadas sobre la planificacin y la
realizacin del mismo. Por tanto, se espera que sean peridicas o
por eventos.
En los niveles 3, 4 y 5, a los anteriores se agregan los siguientes:
CIBERTEC
GG 3 Institucionalizar un proceso definido

El proceso est institucionalizado como un proceso
definido.
11. GP 3.1 Establecer un proceso definido

Establecer y mantener la descripcin de un proceso
definido
Su propsito es establecer y mantener una descripcin del

proceso que se adapta a partir del conjunto de procesos
estndar de la organizacin para tratar las necesidades de
una instanciacin especfica. La organizacin debera tener
procesos estndar que cubran el rea de proceso, as
como guas de adaptacin para cumplir con las
necesidades de un proyecto o de una funcin de la
organizacin. Con un proceso definido, se reduce la
variabilidad en la forma que se realizan los procesos en la
organizacin y pueden compartirse con eficacia los activos
de proceso, los datos y el aprendizaje.
Para ms informacin sobre el conjunto de procesos

estndar de la organizacin y las guas de adaptacin,
consltese el rea de proceso de Definicin de procesos de
la organizacin.
Para ms informacin sobre el establecimiento y el

mantenimiento del proceso definido del proyecto,
consltese el rea de proceso de Gestin integrada de
proyecto.
Las descripciones del proceso definido proporcionan la

base para planificar, realizar y gestionar las actividades, los
productos de trabajo y los servicios asociados con el
proceso.

56
Subprcticas
A. Seleccionar del conjunto de procesos estndar de la
organizacin aquello que cubran el rea de proceso y que
cumplan mejor las necesidades del proyecto o funcin de la
organizacin
B. Establecer el proceso definido adaptando los procesos

seleccionados de acuerdo con las guas de adaptacin de
la organizacin
C. Asegurar que los objetivos del proceso de la

organizacin estn tratados apropiadamente en el proceso
definido
D. Documentar el proceso definido y los registros de la

adaptacin
E. Corregir la descripcin del proceso definido segn sea

necesario
12. GP 3.2 Recolectar informacin para mejoras

Recoger productos de trabajo, medidas, resultados de
medicin e informacin de mejora procedente de la
planificacin y realizacin del proceso para dar soporte al
uso futuro y a la mejora de los procesos y de los activos de
proceso de la organizacin.
Su propsito consiste en recoger informacin y artefactos

derivados de la planificacin y realizacin del proceso.
Esta prctica genrica se realiza para que la informacin y
los artefactos puedan incluirse en los activos de proceso de
la organizacin y estar disponibles para aqullos que estn
(o vayan a estar) planificando y realizando procesos
CIBERTEC
idnticos o similares. La informacin y los artefactos se

almacenan en el repositorio de medicin de la organizacin
y en la biblioteca de activos de proceso de la organizacin.
Para ms informacin sobre el repositorio de medicin y la
biblioteca de activos de proceso de la organizacin,
productos de trabajo, medidas e informacin de mejora que
se incorporan a los activos de proceso de la organizacin,
consltese al rea de proceso de Definicin de procesos de
la organizacin.
Para ms informacin sobre la contribucin de los
productos de trabajo, medidas y experiencias
documentadas a los activos de proceso de la organizacin,
consltese al rea de proceso de Gestin integrada de
proyecto
Subprcticas
A. Almacenar medidas de proceso y de producto en el
repositorio de medicin de la organizacin
Son, bsicamente, aquellas que se definen en el conjunto
comn de medidas para el de procesos estndar de la
organizacin.
B. Enviar la documentacin para su inclusin en la

biblioteca de activos de proceso de la organizacin
C. Documentar las lecciones aprendidas de los procesos

para su inclusin en la biblioteca de activos de proceso de
la organizacin
D. Proponer mejoras a los activos de proceso de la

organizacin

58
GG 4 Institucionalizar un proceso gestionado

cuantitativamente
El proceso est institucionalizado como un proceso
gestionado
cuantitativamente.
GP 4.1 Establecer objetivos cuantitativos para el

proceso
Establecer y mantener los objetivos cuantitativos para el
proceso, los cuales abordan la calidad y el rendimiento del
proceso sobre la base de las necesidades del cliente y de
los objetivos del negocio
Su propsito es determinar y obtener un acuerdo de las

partes interesadas relevantes sobre los objetivos
cuantitativos especficos para el proceso. stos pueden
expresarse en trminos de calidad del producto, calidad del
servicio y rendimiento del proceso.
Para ms informacin sobre cmo se fijan los objetivos
cuantitativos en los subprocesos del proceso definido del
proyecto, consltese el rea de proceso de Gestin
cuantitativa de proyecto.
Los objetivos cuantitativos pueden ser especficos al
proceso o pueden definirse para un alcance ms amplio (p.
ej. para un conjunto de procesos).
En el ltimo caso, pueden asignarse a algunos de los
procesos incluidos.
Estos objetivos cuantitativos son los criterios usados para
juzgar si los productos, servicios y rendimiento del proceso
satisfarn a los clientes, los usuarios finales, la direccin de
la organizacin y los implementadotes de los procesos.
Van ms all de los objetivos tradicionales del producto
final. Tambin, cubren los intermedios, que se usan para
CIBERTEC
gestionar el logro de los objetivos en el tiempo. Reflejan, en

parte, el rendimiento constatado del conjunto de procesos
estndar de la organizacin. stos deberan ser fijados a
los valores que probablemente se logren cuando los
procesos involucrados estn estables y dentro de sus
lmites naturales.
Subprcticas
A. Establecer los objetivos cuantitativos que pertenecen al
proceso
B. Asignar los objetivos cuantitativos al proceso o sus
subprocesos
GP 4.2 ESTABILIZAR EL RENDIMIENTO DEL

SUBPROCESO
Estabilizar el rendimiento de uno o ms subprocesos para
determinar su capacidad y lograr los objetivos cuantitativos
establecidos de calidad y de rendimiento del proceso
Su propsito es estabilizar el rendimiento de uno o ms
subprocesos del proceso definido, los cuales son
contribuidores crticos del rendimiento general, utilizando
tcnicas estadsticas y otras tcnicas cuantitativas
apropiadas. La estabilizacin de los subprocesos
seleccionados da soporte a la prediccin de la capacidad
del proceso para lograr los objetivos cuantitativos
establecidos de calidad y de rendimiento del proceso.
Para ms informacin sobre la seleccin de los
subprocesos para la gestin estadstica, la monitorizacin
del rendimiento de los subprocesos y otros aspectos de
estabilizacin del rendimiento del subproceso, consltese el
rea de proceso de Gestin cuantitativa de proyecto.
Un subproceso estable no muestra ninguna indicacin
significativa de las causas especiales de variacin del

60
proceso. Es predecible dentro de los lmites establecidos

por las restricciones naturales. En un subproceso estable,
las variaciones se deben a un sistema constante de causas
aleatorias y la magnitud de las variaciones puede ser
pequea o grande.
Predecir la capacidad del proceso para lograr los objetivos
cuantitativos establecidos, requiere una comprensin
cuantitativa de las contribuciones de los subprocesos que
son crticos para lograr stos, y establecerlos y gestionarlos
frente a objetivos cuantitativos intermedios en el tiempo.
Las medidas seleccionadas del proceso y del producto se
incorporan al repositorio de medicin de la organizacin
para dar soporte al anlisis del rendimiento del proceso y la
toma de decisiones futuras basadas en hechos.
Subprcticas
A. Gestionar estadsticamente el rendimiento de uno o ms
subprocesos, que son contribuidores crticos al rendimiento
general del proceso.
B. Predecir la capacidad del proceso para lograr sus
objetivos cuantitativos establecidos, considerando el
rendimiento de los subprocesos gestionados
estadsticamente.
C. Incorporar las mediciones seleccionadas del rendimiento
del proceso en las lneas base de rendimiento del proceso
de la organizacin.
GG 5 Institucionalizar un proceso de optimizacin

Est institucionalizado como un proceso en optimizacin.
GP 5.1 Asegurar la mejora continua del proceso

Asegurar la mejora continua del proceso para satisfacer los
objetivos de negocio relevantes de la organizacin.
CIBERTEC
Su propsito es seleccionar y desplegar sistemticamente

mejoras de procesos y de tecnologa, que contribuyan a
cumplir los objetivos establecidos de calidad y de
rendimiento del proceso.
Para ms informacin sobre la seleccin y el despliegue de
mejoras incrementales e innovadoras que mejoren de
forma medible los procesos y las tecnologas de la
organizacin, consltese el rea de proceso de Innovacin
y despliegue en la organizacin.
La optimizacin de los procesos, que son giles e
innovadores, depende de la participacin de una fuerza de
trabajo autorizada y alineada con los valores y objetivos de
negocio de la organizacin. La capacidad de la
organizacin para responder con rapidez a los cambios y
oportunidades se mejora con la bsqueda de formas para
acelerar y compartir el aprendizaje. Esto es parte inherente
del rol de cada persona, lo que se traduce en un ciclo de
mejora continua.
Subprcticas
A. Establecer y mantener objetivos cuantitativos de mejora
de procesos que den soporte a los objetivos de negocio de
la organizacin.
Pueden ser especficos de un proceso individual o definirse
para un alcance ms amplio (para un conjunto de
procesos). Con los procesos individuales, se contribuye a
lograr estos objetivos, que son especficos de un proceso
individual y son normalmente asignados a partir de los
objetivos cuantitativos establecidos para un alcance ms
amplio.
stos se derivan, bsicamente, de los objetivos de negocio
de la organizacin y de una detallada comprensin de la
capacidad del proceso. Son los criterios usados para juzgar
si el rendimiento del proceso est mejorando

62
cuantitativamente la capacidad de la organizacin para

cumplir sus objetivos de negocio. Se establecen a menudo
a valores superiores a los del rendimiento actual del
proceso y para lograrlos pueden ser necesarias mejoras
tecnolgicas incrementales e innovadoras. Tambin,
pueden ser corregidos frecuentemente para seguir
impulsando la mejora del proceso (cuando se logra un
objetivo, puede fijarse un nuevo valor que sea de nuevo
superior al rendimiento del nuevo proceso).
Estos objetivos de mejora de procesos pueden ser iguales
a, o un refinamiento de, los establecidos en la prctica
genrica Establecer objetivos cuantitativos para el
proceso con tal que pueden servir como factores y criterios
para la mejora con xito del proceso.
B. Identificar las mejoras de procesos que daran como

resultado mejoras medibles para el rendimiento del mismo
Incluyen cambios incrementales y mejoras tecnolgicas
innovadoras. stas, normalmente, se llevan a cabo como
esfuerzos que se planifican, realizan y gestionan por
separado. A menudo, se llevan a cabo pilotos.
Estos esfuerzos, generalmente, tratan reas especficas de
los procesos que estn determinadas por el anlisis del
rendimiento del proceso y por la identificacin de
oportunidades especficas para mejoras medibles
significativas.
C. Definir estrategias y gestionar el despliegue de las

mejoras de proceso seleccionadas sobre la base de los
beneficios cuantificados previstos, en los costes e impactos
estimados y en el cambio medido del rendimiento del
proceso
Los costes y los beneficios, que son bsicamente
considerados con respecto a los objetivos cuantitativos de
CIBERTEC
mejora de los procesos de la organizacin, de estas

mejoras se estiman cuantitativamente y se miden los
costes y los beneficios reales. Las mejoras se hacen tanto
al conjunto de procesos estndar de la organizacin como
a los procesos definidos.
La gestin del despliegue de las mejoras de procesos
incluye pilotar los cambios e implementar los ajustes
necesarios donde sea apropiado, tratar las barreras
potenciales y reales para el despliegue, y minimizar la
interrupcin a los esfuerzos en curso y gestionar los
riesgos.
GP 5.2 Corregir las causas raz de los problemas

Identificar y corregir las causas raz de los defectos y de
otros problemas en el proceso
Su propsito es analizar los defectos y otros problemas que

se encontraron en un proceso gestionado,
cuantitativamente, para corregir las causas raz de estos
tipos de defectos y problemas, y para prevenirlos .
Para ms informacin sobre la identificacin y la correccin
de las causas raz de los defectos seleccionados,
consltese el rea de proceso de Anlisis causal y
resolucin. Incluso, aunque el rea de proceso de Anlisis
causal y resolucin est en un contexto de proyecto,
tambin se puede aplicar a los procesos en otros
contextos.
El anlisis de las causas raz pueden aplicarse
beneficiosamente tambin a los procesos que no se
gestionan cuantitativamente. Sin embargo, el enfoque de
esta prctica genrica es actuar sobre un proceso
gestionado cuantitativamente, aunque las causas raz
puedan encontrarse fuera de ese proceso.

64
5.3. OBJETIVOS Y PRCTICAS ESPECFICAS
Los objetivos y prcticas especficas estn vinculados a un rea de

proceso determinada. Son considerados elementos que deben ser
satisfechos para implementar exitosamente los procesos
relacionados con un rea de proceso en particular. Por ejemplo, en el
rea Administracin de Requerimientos (REQM), los objetivos y
prcticas son los siguientes:
CIBERTEC
UNIDAD DE
APRENDIZAJE
REAS DE PROCESO DE NIVEL 2
Al trmino de la unidad, el alumno clasifica y explica las reas de proceso de

nivel 2 de CMMI
TEMARIO
Tema 7: reas de proceso de nivel 2

7.1. Administracin de Requerimientos (REQM)
7.2. Planificacin de Proyectos (PP)
7.3. Monitoreo y Control de Proyecto (PMC)
7.4. Medicin y Anlisis (MA)
7.5. Aseguramiento de la Calidad de Productos y Procesos (PPQA)
7.6. Administracin de la configuracin (CM)
7.7. Administracin de acuerdos con proveedores (SAM)
1. Desarrolle un anlisis de dos reas de proceso de nivel 2. Luego justifique su

anlisis por cada prctica especfica.

66
7. REAS DE PROCESO DE NIVEL 2
En una organizacin que haya alcanzado este nivel de madurez, se

encontrar una disciplina para la gestin de proyectos que se mantiene
an en periodos de estrs. Los recursos estarn capacitados para hacer
su trabajo,y habr polticas organizacionales formalmente establecidas,
cuyo cumplimiento ser monitoreado. Habr visibilidad de las
actividades realizadas, y los proyectos se ejecutarn siguiendo un plan y
de acuerdo con un proceso formalmente establecido.
Si bien el establecimiento de estndares organizacionales recin es

contemplado en el siguiente nivel, aqu se identificarn procesos
definidos en el contexto de cada proyecto. Por supuesto, que pueden
definirse procesos ms o menos generales (que puedan ser usados por
ms de un proyecto), pero el modelo no lo prescribe por la sencilla razn
de que primero es necesario poner orden dentro de cada proyecto para
luego ordenar el resto de la organizacin (el foco de nivel 3).
Las reas de proceso del nivel 2 son siete en total, las cuales se
describirn rpidamente en las prximas secciones.
7.8. Administracin de Requerimientos (REQM)

Esta rea de proceso tiene como propsito mantener bajo control los
requerimientos que el producto a desarrollar deber satisfacer. Las
prcticas, incluidas aqu, apuntan a que los requerimientos no solo estn
claramente identificados, sino tambin que todos los involucrados en el
proyecto (el cliente, el equipo de proyecto, etc.) estn de acuerdo con su
significado. Adicionalmente, los requerimientos deben ser la entrada a
las actividades de planificacin (ver Planificacin del Proyecto (PP)) y a
las tcnicas incluidas en nivel 3.
Un tema fundamental planteado en esta rea de proceso es que

cualquier cambio realizado a los requerimientos se efecte de manera
controlada (por ejemplo, solamente un grupo reducido de personas
debera proponer cambios) y que el resto de los artefactos del proyecto
(planes, especificaciones, diseo, etc.) se mantengan consistentes.
CIBERTEC
Otro aspecto importante incluido en esta rea es el de trazabilidad

bidireccional. Cuando los requerimientos son correctamente
administrados, se debera estar en condiciones de relacionar cul ha
sido el origen de los requerimientos, cul es la relacin entre los
requerimientos de bajo y alto nivel (por ejemplo, cules son derivados y
de cul requerimiento), cules son los artefactos relacionados con los
requerimientos (por ejemplo, especificaciones, documentos de diseo o
planes) y cules componentes del producto implementan cada
requerimiento. Esta prctica es sumamente importante para poder
realizar un buen anlisis de impacto ante posibles cambios y
fundamental para determinar si el alcance del proyecto ha sido cubierto
o no (han sido satisfechos todos los requerimientos?).
En esta rea, hay solamente un objetivo especfico SG 1 Administrar

Requerimientos-y cinco prcticas:
Desde el punto de vista prctico, el rea de proceso se satisface

poniendo en marcha algn tipo de mecanismo o sistema que:
Identifique cules son los canales vlidos para ingresar

requerimientos al proyecto.
Identifique quines son las fuentes oficiales de

requerimientos.
Controle los cambios (no cualquiera estara en condiciones de

generar un cambio a un requerimiento).

68
Permita determinar si todos los involucrados tienen la misma

visin respecto al significado de los requerimientos (por
ejemplo, mediante la aprobacin de algn tipo de documento
formal)..
Mantenga la trazabilidad entre los requerimientos y otros

artefactos (incluyendo al producto y sus componentes).
Si bien a esta altura no es necesario definir ninguna tcnica de

especificacin en particular (tema atacado recin en el nivel 3), lo ms
usual es que se avance en esa direccin para tener, efectivamente,
requerimientos para administrar.
Vale aclarar que, para este modelo, los requerimientos se clasifican en

tres categoras: los del usuario (aquellos que formula el usuario y que,
por ejemplo, pueden ser documentados en una minuta de reunin), los
del producto (derivados a partir de los primeros, generalmente descritos
en un lenguaje ms cercano al equipo de proyecto) y los de los
componentes del producto (derivados de los anteriores).
En algunas organizaciones, los usuarios suelen volcar sus necesidades

en algn tipo de herramienta (por ejemplo, en un workflow), las que,
posteriormente, sern elaboradas por el equipo de proyecto y
formalizadas en algn tipo de documento con un nivel de detalle
suficiente para conducir las actividades tcnicas y de gestin (por
ejemplo, una visin o un acuerdo de Proyecto).
7.9. Planificacin del Proyecto (PP):

Esta rea de proceso tiene como propsito establecer y mantener el
plan que ser empleado para ejecutar y monitorear el proyecto. El plan
se desarrolla sobre la base de los requerimientos administrados por el
rea REQM (ver seccin anterior)
CIBERTEC
Dentro de esta rea de proceso, se incluyen todas las actividades

necesarias para determinar el alcance del proyecto (funcionalidad a
desarrollar, actividades incluidas y excluidas, etc.), estimar esfuerzo y
costos, establecer el cronograma, identificar riesgos y obtener el
compromiso de todos los involucrados respecto al plan de proyecto. Sus
objetivos y prcticas especficas son las siguientes:
Las actividades de esta rea suelen implementarse mediante la

combinacin de varios elementos. Por un lado, ser necesario
establecer algn tipo de mecanismo de estimacin que emplee como
input los requerimientos del proyecto. Tambin, ser necesario
formalizar el plan de proyecto (que no es solamente el cronograma), el

70
ciclo de vida a emplear (por lo menos, fases e hitos) y los mecanismos

de aprobacin.
Si bien no est explcitamente indicado en el modelo, el establecimiento

de una funcin tipo PMO (Project Management Office) podra actuar
como facilitador de la implementacin de esta rea de proceso y de la
siguiente (Monitoreo y Control del Proyecto (PMC).
7.10. Monitoreo y Control del Proyecto (PMC)

No tiene sentido formular planes para algo que no se tiene intenciones
de gestionar. Esta rea de proceso es complementaria y una
consecuencia- de Planificacin del Proyecto (PP): su propsito es
monitorear la ejecucin del proyecto empleando para ello el plan- y
gestionar acciones correctivas en el caso de detectarse desvos.
Para cumplir con estos objetivos ser necesario implementar prcticas

de seguimiento, tales como el reporte de horas trabajadas en el
proyecto, el informe de avance peridico, revisiones en puntos
particulares del proyecto (por ejemplo, al final de cada fase), etc. Si bien
CIBERTEC
esto suena sencillo, conseguir cambiar la cultura (que en general

favorece la no-visibilidad de los proyectos) es una tarea dursima.
La PMO (Project Management Office) tambin puede jugar un papel

importante aqu, realizando el seguimiento a alto nivel- de los proyectos
en ejecucin, y generando los indicadores correspondientes -ver
Medicin y Anlisis (MA)-.
Por supuesto que, al igual que el rea de proceso anterior, es

imprescindible identificar personas dentro de la organizacin que puedan
cubrir el rol de lder o gerente de proyecto. Esto puede sonar
redundante, pero es bastante habitual encontrar organizaciones que ni
siquiera reconocen la existencia del rol.
Medicin y Anlisis (MA)
Una premisa presente en todos los movimientos de calidad es que lo

que no puede medirse no puede mejorarse. Esta rea de proceso
apunta, justamente, a desarrollar y mantener capacidades de medicin
que permitan satisfacer las necesidades de informacin de la
organizacin. Sus objetivos y prcticas son las siguientes:

72
Estos objetivos pueden satisfacerse bsicamente mediante la puesta en

marcha de un programa de mtricas que defina:
Objetivos de la organizacin (por ejemplo, aumentar la

productividad un X% o disminuir los defectos en produccin un
Z%)
Mtricas que permitan determinar si se cumplen o no con los

objetivos (por ejemplo, productividad, densidad de defectos, etc.)
Mecanismos de obtencin de las mtricas (procedimientos

manuales, aplicaciones, orgenes de datos)
Usualmente, los indicadores pueden agruparse en dos: por un lado, los

empleados para monitorear cada proyecto (valor ganado, densidad de
defectos, etc.), y por el otro los ms generales (porcentaje de proyectos
finalizados en fecha, desvo promedio, etc.)
Un enfoque muy interesante que puede emplearse para implementar los

indicadores del segundo grupo es el balanced scorecard propuesto por
Kaplan y Norton.
CIBERTEC
ANLISIS Y DISEO DE SISTEMAS III
7.11. Aseguramiento de la Calidad de Productos y Procesos

(PPQA)
Una vez establecidos procesos y estndares ser necesario evaluar su
aplicacin. El objetivo de esta rea es justamente ese: proveer una
evaluacin objetiva de los procesos y de los artefactos producidos.
Es importante aclarar que las prcticas de esta rea implican:
Evaluar los procesos ejecutados, los artefactos producidos y los

servicios provistos versus los estndares y descripciones de proceso
aplicables;
Identificar no conformidades, comunicarlas a los responsables, y

asegurar su resolucin;
Informar a los interesados (bsicamente, el equipo de proyecto y la

gerencia) el resultado de las actividades de aseguramiento de la
calidad.
De ninguna manera debe confundirse esta rea con la de Verificacin

(VE) incluida en el nivel 3, cuyo propsito es garantizar que se
satisfagan los requerimientos. El foco aqu est puesto en asegurar que
se apliquen los estndares y que los procesos se ejecuten de acuerdo
con lo previsto (ver el Glosario para una definicin de control y
aseguramiento de la calidad).
Un tema importante es el de la objetividad. Debe garantizarse un nivel

apropiado de independencia entre los productores y los evaluadores
(aquellos que ejecuten actividades de aseguramiento de la calidad). Un
canal de reporte con la gerencia tambin es importante para comunicar
las no conformidades y garantizar que se resuelvan.
Los objetivos y prcticas especficas del rea son lo siguientes:

74
Estas prcticas suelen implementarse mediante la creacin de un rol (no

necesariamente full-time) encargado de estas actividades y, por
supuesto, de los procesos y estndares correspondientes.
Algunas actividades de aseguramiento de la calidad podrn estar

embebidas en el proceso de produccin (por ejemplo, como una
actividad en el plan de proyecto), mientras que otras podrn ejecutarse
independientemente y tener su propio plan (ms en el estilo de una
auditora).
Es sumamente importante que el nivel de management adecuado reciba

los informes de no-conformidad y facilite su regularizacin. Por supuesto
que su postura no debe ser coercitiva.
7.12. Administracin de la Configuracin (CM)

Esta rea de proceso tiene como propsito mantener la integridad de
todos los artefactos (entregables o no ) producidos por el proyecto, lo
cual implica identificar los tems de configuracin, realizar sobre ellos
cambios de manera controlada, generar y mantener lneas base y
proveer informacin precisa acera del estado del estado de la
configuracin a todos los interesados.
Los objetivos y prcticas incluidas son los siguientes:
CARRERAS PROFESIONALES CIBERTEC

Esta rea de proceso es, probablemente, una de las ms difciles de

implementar de todas las incluidas en este nivel. Adems de tener
problemas para planificar y ejecutar sus actividades de acuerdo a esos
planes, las organizaciones de nivel 1 suelen tener serias complicaciones
para identificar y mantener las versiones correctas de sus productos y
artefactos asociados. Es bastante comn encontrarse con
organizaciones que tienen mltiples versiones activas de una misma
aplicacin, sin poder llegar a controlarlas del todo e invirtiendo ingentes
recursos en arreglar los mismos problemas una y otra vez. Estas
prcticas apuntan, justamente, a resolver este tipo de problemas.
Cmo se implementan? En general, ser necesario contar con algn

tipo de sistema (preferiblemente, total o parcialmente automatizado), que
permita realizar las actividades tpicas de administracin de la
configuracin:
Identificar tems de configuracin y mantener sus relaciones con

otros tems
Crear, extraer (checkout) e ingresar (checkin) tems de

configuracin del/al sistema de administracin de la configuracin
Generar lneas base en determinados hitos del proyecto
Auditar tems, lneas base y el sistema de administracin de la

configuracin

76
Elevar, analizar y aprobar pedidos de cambio
La introduccin de una herramienta de este tipo tendr un impacto

importantsimo en el trabajo diario de todos los miembros del proyecto (o
de la organizacin, dependiendo de su alcance), sobre todo en la de los
desarrolladores.
7.13. Administracin de Acuerdos con Proveedores (SAM)

Esta rea de proceso apunta a resolver otro de los problemas habituales
en muchas organizaciones: el de la tercerizacin.
Si bien est, originalmente, pensada para todo lo relacionado con la

adquisicin de productos que vayan a ser incorporados en la solucin a
entregar al cliente, las prcticas incluidas aqu tambin sirven para todo
aquello que sea necesario comprar, pero que no ser, finalmente,
entregado al cliente, como por ejemplo herramientas de desarrollo.
Los objetivos y prcticas del rea son los que se indican en el siguiente
cuadro:
Para poner en prctica esta rea de proceso, ser necesario definir los
mecanismos mediante, los cuales son los siguientes:

Seleccionar los potenciales proveedores (por ejemplo, mediante

un proceso que implique le creacin de RFIs y RFPs)
Elegir los proveedores que suministrarn al proyecto los

productos/servicios necesarios
Formalizar los acuerdos con los proveedores (por ejemplo,

mediante un contrato o mediante un acuerdo de nivel de servicio)
Formalizar la entrega de los requerimientos al proveedor
Formalizar la recepcin del producto/servicio solicitado al

proveedor los correspondientes criterios de aceptacin
Es importante aclarar:
Los proveedores de los que habla el rea de proceso no

necesariamente pertenecen a otra empresa u organizacin. Todo
grupo, que deba suministrar productos y servicios al proyecto
(inclusive, otros proyectos), puede ser considerado un proveedor.
Ser necesario, entonces, formalizar con ellos el acuerdo.
Si la solucin a entregar al cliente necesitar de algn tipo de

producto COTSix (por ejemplo, un motor de base de datos o
algn tipo de componente puntual), tambin ser necesario
formalizar el acuerdo con el proveedor correspondiente.

78

UNIDAD DE
APRENDIZAJE
Al trmino de la unidad, el alumno clasifica y explica las reas de

proceso de nivel 3 de CMMI.
TEMARIO
TEMA 8: REAS DE PROCESO DE NIVEL 3
8.1. Desarrollo de requerimientos (RD)

8.2. Solucin tcnica (TS)
8.3. Integracin de producto (PI)
8.4. Verificacin (VER)
8.5. Validacin (VAL)
8.6. Enfoque organizacional en el proceso (OPF)
8.7. Definicin organizacional del proceso (OPD)
8.8. Entrenamiento organizacional (OT)
8.9. Gestin de riesgos (RSKM)
8.10. Anlisis y Toma de decisiones (DAR)
8.11. Administracin Integrada de Proyecto (IPM)
8.12. Gestin Integrada de Proveedores (SS)
8.13. Ambiente Organizacional para la integracin (IPPD)
1. Desarrolle un anlisis de dos reas de proceso de nivel 3. Luego,

justifique su anlisis por cada prctica especfica.

80
Para alcanzar este nivel de madurez, deben ser formalizadas las actividades
de ingeniera del producto (diseo, desarrollo, verificacin, etc.) y ser
adoptadas prcticas de gestin de proyectos ms avanzadas (por ejemplo,
gestin de riesgos). Tambin, deben definirse procesos, procedimientos y
estndares ms detallados, que, a diferencia del nivel anterior, tendrn alcance
organizacional. Adicionalmente, tienen que ser establecidas las estructuras y
los mecanismos necesarios para instrumentar la mejora continua de procesos
(por ejemplo, el SEPG, los TWGs, etc.)
En este nivel de madurez, hay un total de catorce reas de proceso: dos de

ellas especficas para IPPD y una, puntualmente, necesaria para SS.
Desarrollo de Requerimientos (RD)
En el nivel anterior, la preocupacin radicaba en administrar los

requerimientos que por tener una manera estndar para identificarlos y
especificarlos. Justamente, es esta rea de proceso la encargada de
producir y analizar los requerimientos del cliente, del producto y de sus
componentes.
El rea incluye tres objetivos y diez prcticas especficas:

Esta rea suele implementarse mediante la adopcin de tcnicas de

relevamiento y anlisis de requerimientos, como por ejemplo prototipos,
escenarios de operacin, casos de uso, etc. Ms all de las tcnicas
elegidas es importante que se formalice:
Cmo se obtendrn los requerimientos del usuario
Cmo se refinarn dichos requerimientos hasta obtener los del

producto y los correspondientes a sus componentes
Cmo se especificarn, analizarn y validarn, los

requerimientos.
Solucin Tcnica (TS)
En el nivel 2, no importaba tanto formalizar el diseo y la construccin

del producto. Una vez que la organizacin ha arribado a este nivel se
necesitar hacerlo.
Esta rea de proceso incluye todas las actividades necesarias para
Identificar y seleccionar una solucin a los requerimientos
Desarrollar el diseo del producto
Implementar el diseo y obtener el producto.
Los objetivos y prcticas del rea son las siguientes:

82
La implementacin de las actividades aqu descriptas es bastante

compleja. En parte, los objetivos especficos quedaran satisfechos de
poner en prctica alguna tcnica o mtodo de diseo y programacin
particular (diseo orientado a objetos, patrones de diseo, etc.), que
permitan obtener el producto deseado a partir de los requerimientos y
respetando el plan de proyecto. Hay que ser muy cuidadoso para no
formalizar la prctica ms all de lo recomendable.
Tambin, ser necesario formalizar la evaluacin de las posibles

alternativas de solucin a los requerimientos (ver Anlisis y Toma de
Decisiones para un enfoque formal de toma de decisiones).
Integracin del Producto (PI)
El propsito de esta rea de proceso es ensamblar el producto a partir

de sus componentes, garantizando que su funcionamiento sea el
previsto. Tiene tres objetivos y ocho prcticas especficas:

Esta rea se puede implementar mediante la definicin de

procedimientos para mantener bajo control las interfaces internas y
externas (probablemente, uno de los problemas ms habituales en el
desarrollo de software) y para integrar peridicamente el producto (las
prcticas de daily build y smoke test propuestas por Microsoft son un
ejemplo tpico de integracin progresiva). Quizs el aspecto ms
complicado de poner en marcha sea el de disponer de un ambiente de
integracin estable; sin embargo, de contar con un buen sistema de
administracin de la configuracin que permita identificar distintos
ambientes (desarrollo, integracin, prueba, etc.), la implementacin se
facilita notablemente.
Verificacin (VER)
Esta rea de proceso tiene como objetivo garantizar que los artefactos
seleccionados cumplan con los requerimientos asignados. Similar en
ciertos aspectos a Validacin (VA) esta rea de proceso apunta a
evaluar si el producto final y los intermedios del proyecto cumplen con
los requerimientos del cliente, del producto y de los componentes del
mismo. Sus objetivos y prcticas son los siguientes:

84
Las tcnicas empleadas para realizar la verificacin pueden ser similares

a las utilizadas en la validacin (inspecciones, revisiones, pruebas, etc.);
sin embargo, el propsito de esta rea es determinar si se est
construyendo el producto correctamente.
La verificacin siempre es progresiva: a lo largo del ciclo de vida del

proyecto se tendrn varios momentos, en los cuales se revisarn los
resultados de las actividades con el propsito de comprobar si cumplen
o no con los requerimientos, que les han sido asignados (por ejemplo, si
la salida de la actividad de diseo cumple con los requerimientos
asignados a dicha actividad). De esta manera, se detectan problemas
tempranamente y se evita que lleguen al producto final.
Uno de los mecanismos para realizar verificaciones que propone el

modelo es el de revisin de pares. En este tipo, pares del productor o
autor de un artefacto lo revisan con el propsito de identificar defectos o
cambios. Una tcnica muy popular es la de inspecciones (Ver figura 8).

Figura 9 Tcnica de inspeccin
Para implementar esta rea de proceso, es necesario identificar puntos

clave en donde realizar las revisiones y las tcnicas correspondientes
para hacerlo. Tambin, ser necesario disponer de un ambiente para
ejecutar la verificacin (esto se ve muy claro cuando sta involucre algn
tipo de testing).
Aqu van algunos ejemplos:
Al final de la primer fase del proyecto, en donde se define el alcance y se

establece el plan, se inspecciona los artefactos relacionados con la
funcionalidad a desarrollar (acuerdo de proyecto, visin, especificacin
de requerimientos, etc.);
Revisar el modelo de datos y la especificacin de diseo al final

de las actividades de diseo
Inspeccionar el cdigo fuente de componentes de software clave

86
Realizar pruebas de software durante la construccin
Inspeccionar manuales de usuario y material de entrenamiento,

entre otros
Validacin (VAL)
A diferencia del rea de proceso anterior, sta est enfocada en

demostrar si el producto (o sus componentes) satisface las necesidades
de uso en el ambiente deseado.
As como Verificacin se focaliza en determinar si lo construimos bien,

se ocupa de evaluar si se construy el producto correcto.
Los objetivos y prcticas especficas del rea son los siguientes:
Verificacin y validacin suelen ocurrir simultneamente y usar el mismo

ambiente. A menudo, los usuarios estn involucrados.
Esta rea de proceso se implementa mediante la inclusin de

actividades de validacin en lugares clave del proceso productivo. Las
tcnicas y mtodos a emplear podrn ser similares a los utilizados en las
actividades de verificacin (pruebas, revisiones, inspecciones, etc.).
Son varios los aspectos importantes que deben ser contemplados antes
y durante la validacin:

Ambientes para realizar la validacin (por ejemplo, procesadores,

redes, datos, infraestructura, etc.)
Herramientas para realizar la validacin
Personal capacitado
Enfoque Organizacional en el Proceso (OPF)
Una organizacin de nivel 3 debe tener un enfoque formal y disciplinado

para continuamente mejorar sus procesos. Esta rea junto a Definicin
Organizacional del Proceso (OPD) y Entrenamiento Organizacional
(OT)- contribuye a alcanzar dicho objetivo.
El propsito de esta rea en particular es planificar e implementar las

mejoras a los procesos de la organizacin. OPD, por su lado, es la
encargada de establecer y mantener los activos de proceso (polticas,
descripciones de procesos y procedimientos, estndares, mtricas, etc.),
mientras que OT es la responsable de desarrollar los conocimientos y
habilidades del personal para que puedan desempear sus roles de
manera adecuada.
Los objetivos y prcticas especficas de esta rea son los siguientes:
Esta rea de proceso se implementa poniendo en marcha la

infraestructura bsica para la mejora de procesos, planificando las

88
actividades de mejora y formalizando la evaluacin (appraisal) de los

procesos de la organizacin.
Probablemente, ya desde el nivel 2 exista algn tipo de infraestructura

para realizar este tipo de actividades; lo que cambia es que, en este
nivel, hay un mayor grado de formalizacin y compromiso.
Este tipo de iniciativas deben manejarse como proyectos ejecutados en

el contexto de un programa de mejora continua a mediano plazo (de tres
a cinco aos), con planes tcticos de menor alcance. El modelo de
mejora propuesto por el SEI es IDEAL (Initiating, Diagnosing,
Establishing, Acting, Leveraging, las iniciales de las cinco fases del
modelo), proceso para ejecutar y guiar programas de este tipo.
Un tema crtico es la pelea por los recursos: ante la posibilidad de

ejecutar un proyecto de mejoras y otro ms relacionado con el negocio,
probablemente la balanza se inclinar a favor del ltimo. Una manera de
resolver este tipo de conflictos es tener un comit que auspicie la
iniciativa, a la vez que se encuentre en funcionamiento una PMO que
tenga a su cargo balancear la cartera de proyectos.
Por otro lado, las evaluaciones (los appraisals de los que habla el
modelo) deben realizarse siguiendo el proceso oficial, llamado SCAMPI
(Standard CMMI Appraisal Method for Process Improvement). Hay
tres tipos posibles (A, B y C), dependiendo del objetivo que se persiga
(evaluacin interna o externa, generacin de rating nivel de madurez o
capacidad-). Para demostrar que una prctica especfica de un rea de
proceso determinada se encuentra implementada, es necesario mostrar
evidencias directas (resultado directo de su ejecucin) e indirectas
(consecuencia no directa de su implementacin).
En resumen, esta rea de proceso se resuelve teniendo un proceso

definido para efectuar mejoras a los procesos de la organizacin. Ni ms
ni menos.

8.1. Definicin Organizacional del Proceso (OPD)

Esta rea de proceso, complementaria de la anterior, tiene como
propsito establecer y mantener un conjunto utilizable de activos de
proceso. En este contexto, un activo es cualquier elemento que forme
parte de los procesos de la organizacin (una poltica, la descripcin de
un proceso, un estndar, la plantilla de un documento, etc.) y que sea
empleado para describir, implementar y mejorar procesos.
El objetivo y las prcticas de esta rea son los siguientes:
Esta rea de proceso se implementa documentando los activos y

resguardndolos en algn tipo de repositorio (una intranet, un conjunto
de documentos en un directorio, una base de conocimiento, etc.), que
pueda ser fcilmente consultado por todos los interesados.
Usualmente, las organizaciones definen una arquitectura general en

donde identifican sus grandes procesos (por ejemplo, desarrollo de
software, implantacin de paquetes, administracin de cambios, etc.).
Posteriormente, cada uno de los procesos es bajado a mayor nivel de
detalle (subprocesos, actividades). Para cada actividad, podrn definirse
tcnicas (por ejemplo, cmo construir el modelo de datos) y
procedimientos detallados (cmo usar una herramienta determinada
para completar una tarea especfica). Las actividades consumirn y
producirn algn tipo de artefacto.

90
Entrenamiento Organizacional (OT)
Los esfuerzos de mejora deben ser complementados con el

entrenamiento necesario para que todos los integrantes de la
organizacin estn preparados para realizar su trabajo de manera
adecuada. El propsito de esta rea es, justamente, proveer los
conocimientos y habilidades necesarios para que el personal pueda
desempear sus roles eficaz y eficientemente, y as facilitar el
cumplimiento de los objetivos estratgicos de la organizacin y las
necesidades tcticas de los proyectos y reas de soporte.
Sus objetivos y prcticas especficas son los siguientes:
Esta rea de proceso normalmente se resuelve estableciendo un

programa de capacitacin y entrenamiento basado en los conocimientos
y habilidades necesarios para que el personal pueda desempear los
roles que les hayan sido asignados. Esto suele llevar a que la
organizacin formalice la definicin de los puestos y los planes de
carrera del personal.
El entrenamiento y la capacitacin debern incluir todos aquellos temas

relacionados con los procesos de la organizacin y, en funcin de cules
reas de conocimiento queden en manos de cada individuo y cules no,

todos aquellos considerados importantes para desempear

exitosamente el puesto asignado.
Por ejemplo, una organizacin podra definir que sus lderes de proyecto
tengan un adecuado manejo de los procesos planteados por el
PMBOKxv o que sus desarrolladores satisfagan determinadas reas de
conocimiento del SWEBOK.xvi. Otra alternativa sera obtener algn tipo
de certificacin de un ente reconocido, como por ejemplo, la certificacin
de Project Management Professional otorgada por el Project
Management Institute, o la de Certified Software Development
Professional de la IEEE Computer Society.
Gestin del riesgo (RSKM)
Esta rea es una evolucin de las prcticas bsicas de manejo de riesgo

incluidas en Planificacin del Proyecto (PP) y Monitoreo y Control del
Proyecto (PMC) pertenecientes al nivel 2. Aqu, se plantea un enfoque
sistemtico para planear, anticipar y mitigar riesgos para,
proactivamente, minimizar su impacto en el proyecto. Sus objetivos y
prcticas especficas son los siguientes:
Los objetivos de esta rea se satisfacen mediante la puesta en marcha

de mecanismos formales para manejar los riesgos. En este nivel, no
basta simplemente con identificarlos (ver la SP 2.2 de Planificacin del
Proyecto (PP)) y administrarlos en la medida que vayan ocurriendo; aqu

92
ser necesario establecer un proceso para definir y ejecutar una

estrategia para gestionarlos.
Por ejemplo, podra establecerse un esquema de clasificacin de

riesgos y posibles respuestas basado en experiencias anteriores.
Tambin, podran identificarse probabilidades de ocurrencia y
magnitudes de impacto en funcin de aspectos tcnicos y de gestin,
basados en lo ocurrido en proyectos previos.
En resumen, una organizacin de nivel 3 debe proponerse tener un

enfoque mucho ms formal para identificar riesgos y clasificarlos, y para
planear posibles acciones de mitigacin y contingencia.
Anlisis y Toma de Decisiones (DAR)
Esta rea tiene como propsito que determinadas decisiones sean

tomadas de acuerdo a un proceso formal. Por ejemplo, decidir entre
distintas alternativas de solucin o seleccionar un producto o un
proveedor. Son todas decisiones que podran tomarse mediante un
proceso formal compatible con los objetivos y prcticas de esta rea de
proceso.
Cuando se habla de un proceso de evaluacin formal, refirindose

refiere a un enfoque estructurado para evaluar alternativas y recomendar
una solucin a un problema determinado. Esto implica que se deber
cumplir lo siguiente:
Establecer criterios (qu decisiones es recomendable que pasen

por este proceso y cules no, cules son los criterios de
evaluacin, etc.)
Identificar soluciones alternativas
Determinar mtodos para evaluarlas
Evaluar las soluciones alternativas y recomendar una de ellas

El rea tiene un nico objetivo especfico y seis prcticas:
Estas prcticas se implementan mediante la definicin y uso de un

procedimiento (o de varios, segn el caso) mediante el cual
determinados tipos de decisiones sean tomadas. Por ejemplo, podra
plantearse un procedimiento que haga uso de una matriz de criterios de
seleccin para evaluar potenciales proveedores o productos. dem para
decisiones relacionadas con temas tcnicos (por ejemplo, diseos o
arquitecturas alternativas).
Lo ms interesante de esta rea de proceso, adems de proveer un

marco para un anlisis racional de alternativas, es que otorga
transparencia al proceso decisorio. Probablemente, una de las reas de
proceso ms difciles de implementar.
Administracin Integrada del Proyecto (IPM)
Junto a Gestin del Riesgo (RSKM) y Equipo Integrado (IPPD) (IT), esta
es una de las reas de gestin avanzada de proyectos incluidas en el
nivel 3. Est elaborada sobre las prcticas del nivel anterior, cuyo
propsito es administrar el proyecto y lograr el involucramiento de todos
los interesados mediante un proceso que, basado en el proceso
estndar de la organizacin, ha sido adaptado a las necesidades
particulares del proyecto.
El rea tiene cuatro objetivos, dos de ellos vlidos solamente si se est

usando la disciplina IPPD (ver la seccin Disciplinas). Los objetivos y
prcticas son los siguientes:

94
Implementar esta rea de proceso implicar:
Definir el proceso que seguir el proyecto tomando como base

los procesos y ciclos de vida estndar de la organizacin,
siguiendo las recomendaciones de adaptacin incluidos en el
repositorio de activos de proceso. En aquellos casos, en donde
no pueda realizarse la adaptacin, se solicita una excepcin a
quien corresponda (por ejemplo, el rea de calidad o la PMO). El
proceso del proyecto, as definido, deber quedar documentado
en el plan de proyecto.
Emplear los activos de proceso para estimar y planificar el

proyecto
Integrar el plan de proyecto con otros (por ejemplo, el plan de

marketing, capacitacin, etc.)

Identificar y administrar las interfaces entre el proyecto y otros

grupos de trabajo y/o individuos
Gerenciar el proyecto usando el plan del proyecto, el proceso del

proyecto y otros planes
Contribuir al repositorio de activos de la organizacin (nuevas

plantillas, mtricas, nuevos procesos definidos por el proyecto,
lecciones aprendidas, etc.)
Adicionalmente, de emplearse IPPD se deber:
Establecer la visin compartida del proyecto (todos los

participantes/interesados deben estar involucrados en su
desarrollo)
Usar la visin para gerenciar el proyecto
Establecer equipos interdisciplinarios a cargo de los distintos

aspectos del proyecto
Un comentario adicional es que, en muchos casos, adems de definir el

proceso del proyecto ser necesario establecer los procesos de soporte
y produccin (por ejemplo, si el proyecto consiste en disear un avin,
se necesitar definir, tambin, cmo se fabricarn).
Gestin Integrada de Proveedores (SS) (ISM)
Esta rea de proceso, aplicable solamente en el contexto de la disciplina

supplier sourcing o adquisicin de productos, tiene como propsito
identificar potenciales proveedores de productos y establecer con ellos
relaciones mutuamente beneficiosas.
Sus objetivos y prcticas especficas son los que se detallan a

continuacin:

96
Esta rea de proceso podra implementarse a travs de un proceso que

permita formalizar la seleccin y alianza estratgica con proveedores
que estn en condiciones de entregar productos y servicios del nivel de
calidad exigido por la organizacin. La evaluacin y seleccin debera
ser extremadamente formal una alternativa sera usar Anlisis y Toma
de Decisiones (DAR)- y el acuerdo con el proveedor podra formalizarse
con algn tipo de contrato marco en donde se establezcan las
condiciones generales de la relacin (trminos legales, niveles de
servicio, auditora de productos y procesos, revisin peridica, etc.)
Ambiente Organizacional para la Integracin (IPPD) (OEI)
Esta rea de proceso vlida solamente para la disciplina IPPD- tiene

como propsito proveer la infraestructura necesaria para que los
distintos grupos implicados en el proyecto trabajen de manera integrada.
En general, la infraestructura mencionada contendr los siguientes
elementos:
Una definicin de la visin de la organizacin, la que deber

hacer referencia a valores y prcticas importantes para esta
disciplina (trabajo en equipo, desarrollo de productos en forma
concurrente, etc.)
Un ambiente de trabajo preparado para la colaboracin e

integracin del personal y de los distintos grupos involucrados.

Personal especialmente entrenado para integrarse, colaborar y

liderar a otros.
El rea de proceso tiene dos objetivos especficos y un total de seis

prcticas especficas:
Equipo Integrado (IPPD) (IT)
sta es otra de las reas de proceso aplicable, nicamente, cuando se

emplea la disciplina IPPD. Su propsito es establecer y mantener
equipos integrados para el desarrollo de productos. En este contexto, el
grupo de trabajo puede estar integrado por representantes de distintas
reas funcionales y tcnicas-, proveedores o clientes. Cada uno de
estos representantes est autorizado por sus respectivas organizaciones
para actuar y tomar decisiones en su nombre.
El rea de proceso incluye dos objetivos y ocho prcticas especficas:

98

UNIDAD DE
APRENDIZAJE

proceso de nivel 4 de CMMI.
TEMARIO
9.1. Desempeo del proceso de la organizacin (OPP)

9.2. Administracin cuantitativa de proyectos (QPM)
1. Desarrolle un anlisis de un rea de proceso de nivel 4. Luego,

justifique su anlisis por cada prctica especfica.

100
En una organizacin de este nivel, los procesos son analizados con el

propsito de resolver las causas especiales de variacin (ver Glosario). Las
mtricas son empleadas para establecer objetivos y requerimientos de calidad
para los productos y servicios, adems de ser usadas para fijar las metas de
desempeo de los procesos.
En este nivel, los procesos son predecibles y cuantitativamente

comprendidos. Se emplean herramientas estadsticas para entender cul es la
performance real de los procesos y la calidad de los productos y servicios de
la organizacin. Las mismas herramientas se usan para predecir el futuro
desempeo de los procesos, y los niveles de calidad de los productos y
servicios.
Solamente hay dos reas de proceso en el nivel 4: Desempeo del Proceso

de la Organizacin (OPP) y Administracin Cuantitativa de Proyectos (QPM)
Desempeo del Proceso de la Organizacin (OPP)

Esta rea de proceso tiene como propsito comprender cul es la performance
de los procesos de la organizacin y emplear dicha informacin para
administrar cuantitativamente los proyectos.
En una organizacin en este nivel, las mtricas de los procesos (por ejemplo,
esfuerzo, efectividad del testing, etc.) y del producto (por ejemplo, densidad de
defectos, confiabilidad, etc.) son empleadas para modelar la performance
pasada y para predecir la futura. A su vez, estos modelos son empleados
como base para contrastar el desempeo real de los proyectos.
Con esta informacin la organizacin estar en condiciones de determinar

cules procesos son estables, cules merecen atencin, cules deberan ser
estadsticamente controlados y cmo, y cules procesos deberan ser
mejorados.
El rea tiene un solo objetivo y cinco prcticas especficas, a saber:

Estas prcticas pueden implementarse, por ejemplo, mediante un buen

programa de mtricas que contemple la generacin de modelos de
performance. Ser necesario, adems, contar con un proceso definido para
realizar estas actividades, que podran ser asignadas al departamento de
aseguramiento de la calidad (si existiere) u a otro similar.
Las herramientas y tcnicas que pueden emplearse aqu son las clsicas
popularizadas por la calidad total: diagramas de control, prueba de hiptesis,
etc.
Ms all de quin realice estas actividades es importante tener en claro que no

todos los procesos debern (o podrn) ser controlados estadsticamente. La
decisin de cules son esos procesos deber tomarse en funcin de las
necesidades del negocio y del proyecto.
Son muchos los procesos candidatos a ser controlados estadsticamente. Por

ejemplo, el proceso de testing podra ser analizado para determinar su
efectividad (defectos post-release) y as predecir su comportamiento en el
futuro. Tambin, se podran buscar determinar el nivel de confiabilidad del
proceso de estimacin, el tiempo medio entre fallas de nuestros productos, el
nivel de productividad de la organizacin, etc.

102
Administracin Cuantitativa de Proyectos (QPM)
El propsito de esta rea de proceso es administrar el proyecto de tal manera

que se cumplan con sus objetivos de calidad y desempeo. El proyecto es
gestionado cuantitativamente, lo cual implica:
Establecer y mantener los objetivos de calidad y desempeo del

proyecto
Configurar el proceso que emplear el proyecto seleccionando

aquellos subprocesos sobre la base de su estabilidad y/o
capacidad (lo que se encuentra en los modelos y lneas base
mencionados en el rea de proceso anterior)
Seleccionar los subprocesos del proceso del proyecto que sern

estadsticamente administrados, y con cules tcnicas y
herramientas
Monitorear el comportamiento del proyecto para determinar si se

cumplen o no los objetivos de calidad y desempeo
Monitorear el desempeo de los subprocesos seleccionados para

determinar si pueden cumplir sus objetivos de calidad y
desempeo, y tomar acciones correctivas de ser necesario
Alimentar el repositorio de mtricas de la organizacin con los

datos del desempeo y calidad reales
Los objetivos y prcticas especficas del rea son los siguientes:

Las herramientas que pueden usarse para implementar estas prcticas

son similares a las propuestas para el rea anterior: todas las de gestin
estadstica de procesos. La diferencia radica en que aqu se emplearn
para tener un conocimiento cabal del comportamiento de los
subprocesos del proyecto (naturaleza de las variaciones, estabilidad,
etc.).

104

UNIDAD DE
APRENDIZAJE
ARQUITECTURA DE CMMI

proceso de nivel 5 de CMMI
TEMARIO
10.1. Innovacin Organizacional y Despliegue (OID)

10.2. Anlisis y Resolucin de causas de defectos/Problemas
(CAR)
TEMA 11: EVALUACIN SCAMPI PARA CMMI
11.1. Proceso de evaluacin SCAMPI
TEMA 12: OTROS ESTNDARES Y MODELOS DE REFERENCIA
12.1. ISO 9001:2008

12.2. Cobit
12.3. ITIL
12.4. eSCM
12.5. Integracin de modelos
1. Desarrolle un anlisis deL rea de proceso OPP. Luego, justifique su

anlisis por cada prctica especfica.
2. Explique en qu consiste los diferentes tipos de evaluacin para

CMMI.

106
10. reas de Proceso de Nivel 5
Las organizaciones de este nivel trabajan en el anlisis de sus procesos con el

objetivo de identificar y eliminar las causas comunes de variacin (ver
Glosario). Para ello, hacen uso de mtricas que les permiten:
Seleccionar mejoras e innovaciones

Estimar los costos y beneficios de las mejoras e innovaciones
Medir los costos y beneficios reales de las mejoras e innovaciones
La permanente bsqueda de mejores maneras de hacer las cosas, basada en

la medicin de los procesos y sin alterar su estabilidad, est arraigada en lo
ms profundo de la cultura de la organizacin. No hay otra manera de manejar
el negocio.
La diferencia entre este nivel y el anterior radica fundamentalmente en el tipo
de causas de variacin que son atacadas: en nivel 4, se trabaja sobre las
causas especiales (aquellas que producen variaciones no al azar en los
resultados del proceso y que son atribuibles a factores externos, como por
ejemplo condiciones en el medio ambiente), mientras que, en nivel 5, el
objetivo son las causas comunes (aquellas que producen variaciones al azar
en los resultados del proceso y que tienen por origen el propio proceso).
Solamente hay dos reas de proceso en este nivel: Innovacin organizacional

y despliegue (OID), y Anlisis y resolucin de causas de defectos/problemas
(CAR).
Innovacin organizacional y despliegue (OID)
El propsito de esta rea es seleccionar e implantar cambios que, de

manera incremental, permitan mejorar en forma medible- los procesos
y las tecnologas empleadas por la organizacin, al mismo tiempo que
se alinean los objetivos de calidad y desempeo con los objetivos del
negocio. En general, las mejoras estarn relacionadas con el incremento

de la satisfaccin de los clientes o usuarios, la disminucin de los

tiempos de desarrollo o con el aumento de la productividad.
En este nivel de madurez, las organizaciones poseen una cultura y una

infraestructura que facilitan y estimulan la participacin de todos sus
integrantes en las actividades de innovacin. La identificacin de
potenciales mejoras puede ser realizada por cualquiera, sin importar su
jerarqua o posicin en la organizacin. Los cambios seleccionados son
efectivamente implementados, y sus consecuencias, medidas.
El rea tiene dos objetivos especficos y un total de siete prcticas

especficas, los que se describen a continuacin:
Estos objetivos se pueden satisfacer de contarse con un proceso para

realizar mejoras sistemticas a los procesos de la organizacin. Por
ejemplo, podra plantearse que las propuestas de mejora sean elevadas
a algn tipo de comit para su evaluacin y que las que finalmente
resulten aprobadas, sean definidas e implementadas por una iniciativa
que deber ser manejada como un proyecto ms con alcance, plan,
presupuesto, recursos asignados, etc.
Si bien mecanismos de este tipo existirn en los niveles anteriores, en

este nivel, el manejo del tema es ms sistemtico y formal.

108
Anlisis y resolucin de causas de defectos/problemas (CAR)
Poder identificar defectos tempranamente y evitar sus consecuencias es

una caracterstica fundamental de las organizaciones pertenecientes al
nivel 5. Las prcticas incluidas aqu apuntan a identificar, analizar y
eliminar las causas no slo de los defectos, sino tambin de los
problemas (por ejemplo, para mejorar atributos de calidad de productos
y servicios). Los objetivos y prcticas especficos son los siguientes:
Estos objetivos suelen ser satisfechos mediante la definicin e

implementacin de un proceso que sistemticamente realice, a escala
organizacional y por proyecto, el anlisis de los defectos y problemas
encontrados, y la definicin y ejecucin de acciones concretas que
permitan resolver sus causas de origen.
Una buena manera de implementar este anlisis, al menos a nivel

proyecto, es realizar el cierre formal de los proyectos, registrando
lecciones aprendidas y sugiriendo acciones de mejora.
Otra alternativa es que el grupo de la organizacin, a cargo de los temas

de calidad sistemticamente, examine los indicadores disponibles (por
ejemplo, densidad de defectos o cantidad de incidentes en produccin) y
que los analice con el propsito de identificar posibles causas de su
comportamiento.

Las herramientas que pueden emplearse en el anlisis son las que

clsicamente han sido usadas por la calidad total: el diagrama de
Pareto, el de causa-efecto y el de dispersin. A continuacin se muestra
un ejemplo de diagrama de Pareto.
Figura 11. Un diagrama de Pareto
Una vez realizado el anlisis deben definirse e implementarse las

mejoras, las que podrn ejecutarse dentro de este proceso o en aqul
relacionado con el rea de proceso Innovacin organizacional y
despliegue (OID).

110
11. Evaluacin SCAMPI para CMMI
Proceso de evaluacin SCAMPI
Muchas organizaciones dan valor a la medicin de su progreso

mediante la realizacin de una evaluacin y, de esta forma, ganar una
calificacin de nivel de madurez o un perfil de logro de nivel de
capacidad. Estas evaluaciones se realizan normalmente por una o ms
de las siguientes razones:
Determinar hasta qu punto los procesos de la organizacin se

equiparn con las mejores prcticas de CMMI e identificar las
reas donde realizar mejoras
Informar a los clientes y proveedores externos hasta qu punto

los procesos de la organizacin se equiparn a las mejores
prcticas de CMMI
Cumplir con los requerimientos contractuales de uno o ms

clientes
Las evaluaciones de las organizaciones que usan el modelo CMMI

deben ajustarse a los requerimientos definidos en el documento
Requerimientos de la evaluacin para CMMI Appraisal Requirements
for CMMI (ARC). Estas evaluaciones se enfocan en la identificacin de
oportunidades de mejora y en la comparacin de los procesos de la
organizacin con las mejores prcticas CMMI. Los equipos de
evaluacin usan el modelo CMMI y un mtodo conforme con ARC para
guiar su evaluacin de la organizacin, as como para informar sobre
sus conclusiones. Los resultados pueden usarse a partir de entonces
(por un grupo de proceso, por ejemplo) para planificar las mejoras para
la organizacin.
Requerimientos de la evaluacin para CMMI
El documento ARC describe los requerimientos para diferentes tipos de

evaluaciones. Una clase de evaluacin comparativa total se define como

una de Clase A. Otros mtodos menos formales se definen como

mtodos de Clase B o de Clase C. El documento ARC fue diseado
para ayudar a mejorar la consistencia entre mtodos de evaluacin y
para ayudar a los desarrolladores del mtodo de evaluacin,
patrocinadores y usuarios a comprender los pros y contras asociados
con los diferentes mtodos [SEI 2006a].
Dependiendo del propsito de la evaluacin y de la naturaleza de las

circunstancias, una clase puede ser preferible a las otras. En algunas
ocasiones, son apropiadas las auto-evaluaciones, las evaluaciones
iniciales, las vistas rpidas o mini-evaluaciones, las evaluaciones
incrementales o las evaluaciones externas, mientras que en otras lo
apropiado es una evaluacin comparativa formal.
Un mtodo de evaluacin particular se declara como mtodo de

evaluacin ARC Clase A, B o C basado en los conjuntos de
requerimientos ARC que el desarrollador trat cuando dise el mtodo.
Hay ms informacin acerca del ARC disponible en el sitio web del SEI
en www.sei.cmu.edu/cmmi/appraisals/appraisal.html
Mtodos de evaluacin SCAMPI
Los mtodos de evaluacin SCAMPI son, generalmente, los ms

aceptados, que se usan para realizar evaluaciones utilizando modelos
CMMI. El Documento de definicin del mtodo Method Definition
Document (MDD) de SCAMPI define las reglas para asegurar la
consistencia de las calificaciones de la evaluacin.
Para realizar una comparativa frente a otras organizaciones, las

evaluaciones deben de asegurar calificaciones consistentes. El logro de
un nivel de madurez especfico o la satisfaccin de un rea de proceso
debe significar lo mismo para las diferentes organizaciones evaluadas.
La familia SCAMPI de evaluaciones incluye los mtodos de evaluacin
de Clase A, B y C. SCAMPI A es el ms riguroso y el nico que puede
dar lugar a una calificacin. SCAMPI B proporciona opciones en el

112
alcance del modelo, pero la caracterizacin de las prcticas est fijada

en una escala y se realiza sobre prcticas ya implementadas. SCAMPI
C ofrece un amplio rango de opciones, incluyendo la caracterizacin de
enfoques planificados para la implementacin de procesos de acuerdo a
una escala definida por el usuario.
Hay ms informacin acerca de los mtodos SCAMPI disponible en el

sitio web del SEI en www.sei.cmu.edu/cmmi/appraisals/appraisal.html [SEI
2006b]
Consideraciones de la evaluacin
Las elecciones que afectan a una evaluacin basada en CMMI son las
siguientes:
Elegir el modelo CMMI para usar en la evaluacin (para esta

constelacin, la eleccin podra estar entre el modelo CMMI para
desarrollo y el modelo CMMI para desarrollo + IPPD).
Establecer el alcance de la evaluacin, incluyendo la unidad de la

organizacin objeto de evaluacin, las reas de proceso de CMMI a
investigar y el nivel de madurez o nivel(es) de capacidad a evaluar.
Seleccionar el mtodo de evaluacin
Seleccionar los miembros del equipo de evaluacin
Seleccionar los participantes en la evaluacin a entrevistar de las

entidades objeto de la evaluacin
Definir las salidas de la evaluacin (p.ej., calificaciones o

hallazgos especficos de la instanciacin)
Establecer las restricciones de la evaluacin (p.ej., tiempo

dedicado in situ)

El SCAMPI MDD permite la seleccin de opciones predefinidas para

usar en una evaluacin. stas se encuentran diseadas para ayudar a
las organizaciones a alinear CMMI con sus necesidades y objetivos de
negocio.
La documentacin de los planes de evaluacin CMMI y de los resultados

debe incluir siempre una descripcin de las opciones de evaluacin, del
alcance del modelo y del alcance de la organizacin seleccionada. Esta
documentacin confirma si una evaluacin cumple los requerimientos
para la comparativa.
Para organizaciones que deseen evaluar mltiples funciones o grupos,

el enfoque integrado CMMI permite cierta economa de escala en la
formacin en el modelo y en la evaluacin. Un mtodo de evaluacin
puede proporcionar resultados separados o combinados para mltiples
funciones.
Los principios de la evaluacin para el conjunto de productos de CMMI6

permanecen iguales que los utilizados para otros modelos de mejora de
procesos. Estos principios son los siguientes:
Patrocinio de la direccin
Focalizacin sobre los objetivos de negocio de la organizacin
Confidencialidad para los entrevistados
Uso de un mtodo documentado de evaluacin
Uso de un modelo de referencia de procesos (p.ej., un modelo

CMMI) como base
Un enfoque de colaboracin en equipo
Focalizacin en acciones para la mejora de procesos

114
12. Otros estndares y modelos de referencia
Adems de CMMI, existen otros modelos y estndares que pueden ser

empleados como referencia para definir e implantar procesos: ISO 9001,
CobIT, ITIL y eSCM (ver Tabla 1). A continuacin, se describirn sus
principales caractersticas y mbitos de aplicacin.
3.1. ISO 9001:2008
El ms conocido de los mencionados anteriormente es ISO 9001:2008,

un estndar internacional que puede ser aplicado a cualquier tipo de
organizacin. ste establece los requerimientos que debe cumplir un
sistema genrico de gestin de la calidad (QMS, por sus siglas en
ingls). Adems, puede ser usado para mejorar procesos internos,
obtener una certificacin o establecer relaciones contractuales. Si bien
su mbito de aplicacin es ms amplio, existen lineamientos para su uso
en organizaciones de sistemas.
Los requerimientos de la norma se agrupan en cinco captulos:
A. Sistema de gestin: contiene la siguiente informacin.
1. Requisitos generales
2. Requisitos de documentacin
B. Responsabilidades de la Direccin: contiene los requisitos que

debe cumplir la direccin de la organizacin, tales como definir la
poltica, asegurar que las responsabilidades y autoridades estn
definidas, aprobar objetivos, el compromiso de la direccin con la
calidad, etc.
2. Requisitos del cliente
3. Poltica de calidad
4. Planeacin

5. Responsabilidad, autoridad y comunicacin
6. Revisin gerencial
C. Gestin de los recursos: la Norma distingue tres tipos de recursos

sobre los cuales se debe actuar: RRHH, infraestructura y ambiente de
trabajo. Aqu, se contienen los requisitos exigidos en su gestin.
2. Recursos humanos
3. Infraestructura
4. Ambiente de trabajo
D. Realizacin del producto: aqu estn contenidos los 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 equipos de medicin, inspeccin y monitoreo
E. Medicin, anlisis y mejora: aqu se sitan los requisitos para los

procesos que recopilan informacin, la analizan y que actan en
consecuencia. El objetivo es mejorar continuamente la capacidad de la
organizacin para suministrar productos que cumplan los requisitos,
pero nadie lo toma en serio (eso es muy generalizado) El objetivo
declarado en la Norma es que la organizacin busque sin descanso la
satisfaccin del cliente a travs del cumplimiento de los requisitos.

116
2. Seguimiento y medicin
3. Control de producto no conforme
4. Anlisis de los datos para mejorar el desempeo
5. Mejora
Dentro de cada uno de ellos, se encontrarn las clusulas que describen

los requerimientos que deben satisfacerse para cumplir con el modelo.
ISO 9001:2008 y CMMI tienen varios puntos de contacto, pero algunas

diferencias (ver Tabla 1 para ms detalles). Si bien es necesario analizar
las situaciones caso por caso, se podra afirmar que una organizacin
deseosa de certificar el estndar debera cumplir con las reas de
proceso de nivel 2 y nivel 3, ms algunas de las correspondientes a los
niveles cuatro y cinco. En la Fig. 12, se ilustran las relaciones entre cada
uno de los captulos del estndar y las reas de proceso, y prcticas
genricas de CMMI.

Figura 12: Relacin entre CMMI e ISO 9001:2008
3.2 Cobit
CobIT, por otro lado, es un modelo desarrollado por el IT Governance

Institutexix, cuyo propsito es establecer una serie de objetivos de
control para las actividades de la organizacin de IT.
Se organiza en cuatro dominios, los cuales, a su vez, se descomponen

en procesos que contienen los objetivos de control.

118
Figura 13: Dominios y Procesos de Cobit
Como puede apreciarse en la Fig. 13 varios de los procesos tienen

puntos de contacto con CMMI. Por ejemplo, P09 Administrar Riesgos
est claramente relacionado con Gestin del Riesgo (RSKM) (aunque
los alcances son distintos) y Administrar Proyectos con Planificacin del
Proyecto (PP), Monitoreo y Control del Proyecto (PMC) y Administracin
Integrada del Proyecto (IPM). Sin embargo, debe recordarse que ambos
modelos tienen propsitos distintos: uno apunta a facilitar la evaluacin y
mejora de procesos, mientras que el otro est enfocado en proveer
objetivos y guas para controlar las actividades de IT. Se podra pensar,
entonces, que las prcticas descriptas en CMMI, una vez
implementadas, deberan facilitar el cumplimiento de algunos de los
objetivos de control de CobIT.
3.3. ITIL
ITIL es el acrnimo de Information Technology Infrastructure Library.8,

desarrollado en los aos ochenta por la CCTA (Central Computer &
Telecommunications Agency) del Reino Unido y administrado,

actualmente, por la OGC (Office of Government Commerce). Es un

marco para organizar las actividades de provisin de servicios de IT. No
es un estndar, sino un conjunto de best practices organizado alrededor
de diez procesos.
Figura 14: Procesos de ITIL
La principal caracterstica de ITIL es que no prescribe, sino que describe: en

cada uno de los libros correspondientes a cada proceso se proveen
lineamientos detallados de los procedimientos y actividades necesarias para
implementarlo. sta es una diferencia sustancial respecto a los distintos
frameworks incluidos en esta seccin.
A pesar de lo antes mencionado, hay dos estndares basados en ITIL:

BS15000 y el ms reciente ISO 20000.
Si bien ITIL implementa las actividades relacionadas con lo que pasa luego
de que la solucin es puesta en produccin -uno de los aspectos no
contemplados por CMMI- hay muchos puntos de contacto con dicho
modelo; por ejemplo, change, configuration y release management estn
claramente relacionados con el rea de proceso Administracin de la
Configuracin (CM). Tambin, Problem management tiene muchos puntos

120
de contacto con Anlisis y resolucin de causas de defectos/problemas

(CAR).
ITIL v3 consta de 5 libros basados en el ciclo de vida del servicio:
1. Estrategia del servicio
2. Diseo del servicio
3. Transicin del servicio
4. Operacin del servicio
5. Mejora continua del servicio
Estrategia del servicio
Se enfoca en el estudio de mercado y posibilidades mediante la bsqueda

de servicios innovadores que satisfagan al cliente, tomando en cuenta la
real factibilidad de su puesta en marcha. Asimismo, analiza posibles
mejoras para servicios ya existentes. Verifica los contratos con base en las
nuevas ofertas de proveedores antiguos y posibles nuevos, lo que incluye la
renovacin o revocacin de los contratos vigentes. Procesos:
1. Gestin Financiera
2. Gestin del Portafolio
3. Gestin de la Demanda
Diseo del servicio
Una vez identificado un posible servicio el siguiente paso consiste en

analizar su viabilidad. Para ello, se toman factores, tales como
infraestructura disponible, capacitacin del personal y se planifican aspectos
como seguridad y prevencin ante desastres. Para la puesta en marcha, se
toman en consideracin la reasignacin de cargos (contratacin, despidos,
ascensos, jubilaciones, etc.), la infraestructura y el software que se va a
implementar.

Procesos:
1. Gestin del catlogo de servicios
2. Gestin de niveles de servicio
3. Gestin de la disponibilidad
4. Gestin de la capacidad
5. Gestin de la continuidad de los servicios de TI
6. Gestin de proveedores
7. Gestin de la seguridad de informacin
Transicin del servicio
Antes de poner en marcha el servicio, se deben realizar pruebas. Para ello,

se analiza la informacin disponible acerca del nivel real de capacitacin de
los usuarios, estado de la infraestructura, recursos IT disponibles, entre
otros. Luego, se prepara un escenario para realizar pruebas; se replican las
bases de datos, se preparan planes de rollback (reversin) y se realizan las
pruebas. Posteriormente, se limpia el escenario hasta el punto de partida y
se analizan los resultados, de los cuales depender la implementacin del
servicio. En la evaluacin, se comparan las expectativas con los resultados
reales.
Procesos:
1. Gestin de la configuracin y activos
2. Gestin del cambio
3. Gestin del conocimiento
4. Planificacin y apoyo a la transicin
5. Gestin de release y despliegue

122
6. Gestin validacin y pruebas
7. Evaluacin
Operacin del Servicio
En este punto, se monitoriza activa y pasivamente el funcionamiento del

servicio, se registran eventos, incidencias, problemas, peticiones y accesos
al servicio.
Procesos:
1. Gestin de incidentes
2. Gestin de problemas
3. Cumplimiento de solicitudes
4. Gestin de eventos
5. Gestin de accesos

Mejora Continua del Servicio
Se utilizan herramientas de medicin y feedback para documentar la

informacin referente al funcionamiento del servicio, los resultados
obtenidos, problemas ocasionados, soluciones implementadas, etc. Para
ello, se debe verificar el nivel de conocimiento de los usuarios respecto al
nuevo servicio, fomentar el registro e investigacin referentes al servicio y
disponer de la informacin al resto de los clientes.

124
3.4. eSCM
Este modelo (eSourcing Capability Model) es el desarrollo ms reciente de

la Carnegie Mellon University, pero, en esta ocasin, su origen no es el
Software Engineering Institute, sino el IT Services Qualification Center
(ITsqc), dependiente del Institute for Software Research International de la
Facultad de Ciencias de la Computacin.
Este modelo de capacidades apunta a cubrir ciertos aspectos relacionados

con la provisin de servicios basados en IT que el resto de los modelos no
cubre (por ejemplo, transferencia de conocimientos al proveedor del
servicio, contratacin, gestin de relaciones, etc.). Su propsito es que los
proveedores de servicios sean ms eficaces y eficientes, que sus contratos
no sean interrumpidos por mal desempeo y que haya una mejor relacin
entre proveedores, clientes y organizaciones asociadas.
Existen dos variantes del modelo: uno destinado a los proveedores del
servicio (eSCM-SP) y otro a los clientes del servicio (an no liberado).
Claramente, el modelo es aplicable en aquellas situaciones en donde una

organizacin desee tercerizar no slo sus servicios de IT (desarrollo, help
desk, etc.), sino tambin procesos de negocio que hagan uso intensivo de la
tecnologa (call centers, facturacin, etc.). A toda esta gama de actividades
tercerizadas, es a las que eSCM llama eSourcing.

Figura 15: Fases y reas de Capacidad de eSCM
El modelo tiene muchas particularidades (ver Fig. 15). Ls prcticas pueden

agruparse por reas de capacidad (similares a las categoras de proceso de
CMMI), por fase, en funcin de la etapa en la cual se encuentre la provisin
del servicio (iniciacin antes de la formalizacin del contrato-, despliegue,
prestacin del servicio, cierre y ongoing para aquellas prcticas que se
aplican en todas las fases anteriores-), y por niveles (2, 3 y 4).
Otro de los aspectos interesantes es que no es un modelo de madurez, sino

de capacidad. Esto implica que las reas pueden ser evaluadas
individualmente (de manera similar a cuando se emplea la representacin
continua de CMMI) y reciben una clasificacin entre 2 y 5 en funcin de las
prcticas implementadas. Otra de las particularidades es que el nivel de
capacidad 5 se otorga luego de haber certificado dos veces seguidas la de
nivel 4 (existe una certificacin formal realizada por el ITsqc).

126
3.5. Integrando los modelos
Cada uno de los modelos y estndares propuestos tiene un propsito y un

alcance claros (ver Tabla 1). Sin embargo, puede ser usado
simultneamente de ser necesario.
Por ejemplo, CMMI y eSCM podran ser usados concurrentemente en

aquellas situaciones en donde se tercerice el desarrollo y mantenimiento de
software (software factory). ITIL (o ISO 20000) podra aplicarse para
resolver los temas no cubiertos por CMMI. CobIT es un framework que es
propuesto como modelo de IT Governance, de manera que hay muchos
puntos de contacto con ITIL y CMMI que deberan ser analizados, sobre
todo en organizaciones internas de sistemas.
ISO 9001:2000 y CMMI comparten filosofa (la mejora continua y la gestin

de procesos) y prcticas. Una alternativa sera usar la segunda como gua
para obtener una certificacin ISO 9001:2000. Sin embargo, debe hacerse
un anlisis detallado, ya que el mapeo entre el estndar y el modelo de
referencia, no es necesariamente lineal (ver Fig. 11).

CASOS:
1. Investigue las siguientes herramientas e identifique a qu reas de

proceso ayudan para su implementacin.
a. Project Server
b. Rational clear Case
c. Rational Clear Quest
d. Allfusion Harvest CM
e. SharePoint
f. Visual Sourse Safe
g. RequisitePro
h. Rational XDE
i. RUP
j. Test Director
k. subversion - Tortoise
l. Gforge
m. OSRMT
n. StarUML
o. Gforge
p. dotProject
q. OpenWorkbench
r. Bugzilla
s. Selenium

Comportamiento Organizacional

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Comportamiento Organizacional

Caricato da

Copyright:

Formati disponibili

Comportamiento

Unidad 1: Niveles de madurez CMMI y reas de proceso 7

Tema 1: Niveles de madurez de CMMI 8

Tema 2: reas de proceso de CMMI 13

Unidad 2: CMMI y el ciclo de vida del desarrollo del SW 23

Tema 3. Ciclo de vida del desarrollo del SW 24

Tema 4: Gestin y Calidad 27

Unidad 3: Arquitectura del Modelo CMMI 43

Tema 5: Objetivos y prcticas genricas 44

Unidad 4: reas de proceso de nivel 2 65

Unidad 5: reas de proceso de nivel 3 79

Unidad 6: reas de proceso de nivel 4 99

Unidad 7: reas de proceso de nivel 5 y evaluacin SCAMPI 105

CIBERTEC CARRERAS PROFESIONALES