CMMI For Development v1-3 Spanish

CMMI® para Desarrollo, Versión 1.
CMMI-DEV, V1.3
Equipo del Producto CMMI
Mejora de los procesos para el desarrollo de mejores productos y

servicios
Noviembre 2010
TECHNICAL REPORT
CMU/SEI-2010-TR-033
ESC-TR-2010-033
Software Engineering Process Management Program

Unlimited distribution subject to the copyright.
http://www.sei.cmu.edu
This report was prepared for the
SEI Administrative Agent
ESC/XPK
5 Eglin Street
Hanscom AFB, MA 01731-2100
The ideas and findings in this report should not be construed as an official DoD position. It is published
in the interest of scientific and technical information exchange.
This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a
federally funded research and development center sponsored by the U.S. Department of Defense.
Copyright 2010 Carnegie Mellon University.
NO WARRANTY
THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE
MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY
MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY
MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR
MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE
MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY
KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT
INFRINGEMENT.
Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark
holder.
Internal use. Permission to reproduce this document and to prepare derivative works from this document
for internal use is granted, provided the copyright and “No Warranty” statements are included with all
reproductions and derivative works.
External use. This document may be reproduced in its entirety, without modification, and freely distributed in
written or electronic form without requesting formal permission. Permission is required for any other external
and/or commercial use. Requests for permission should be directed to the Software Engineering Institute at
permission@sei.cmu.edu.
This work was created in the performance of Federal Government Contract Number FA8721-05-C-0003
with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally
funded research and development center. The Government of the United States has a royalty-free
government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any
manner, and to have or permit others to do so, for government purposes pursuant to the copyright
license under the clause at 252.227-7013.
For information about SEI publications, please visit the library on the SEI website
(www.sei.cmu.edu/library).
The following service marks and registered marks are used in this document: Capability Maturity
Model
Carnegie Mellon CERT CMM CMMI CMM Integration IDEALSM SCAMPISM
CMMI, CMM, CERT, CMM Integration, Carnegie Mellon, and Capability Maturity Model are
registered in the U.S. Patent and Trademark Office.
SCAMPI and IDEAL are service marks of Carnegie Mellon University.
El presente documento se ha extraído de CMMI® PARA DESARrollo. GUÍA PARA
LA INTEGRACIÓN de procesos y LA MEJORA de productos. Tercera edición.
Libro publicado por Editorial Universitaria Ramón Areces, en donde

encontrará los textos que faltan sobre fondo gris (sólo figura título y autor) y el
contenido del Capítulo 6 (“Ensayos y casos de estudio”).
Contenidos
prefaCio vii
Propósito vii
Agradecimientos viii
Audiencia viii
Organización de este documento ix
Cómo usar este documento x
Lectores que se inician en la mejora de procesos x
Lectores con experiencia en mejoras de procesos x
Lectores familiarizados con CMMI x
Información adicional y sugerencias del lector xii
Sobre la edición en español xiii
primera parte: aCerCa de CMMi para desarroLLo 1
1 IntrOduCCIón 3
Acerca de la mejora de procesos 4
Acerca de los modelos de madurez y de capacidad 9
Evolución del CMMI 10
Marco CMMI 14
CMMI para desarrollo 18
2 COMPOnEntES dEL árEA dE PrOCESO 19
áreas de proceso base y los modelos CMMI 19
Componentes requeridos, esperados e informativos 19
Componentes requeridos 19
Componentes esperados 20
Componentes informativos 20
Componentes asociados con la Segunda Parte 20
áreas de proceso 20
declaraciones del propósito 22
notas introductorias 22
iii
iv Contenido
áreas de proceso relacionadas 22
Metas específicas 22
Metas genéricas 23
resúmenes de metas y prácticas específicas 23
Prácticas específicas 23
Ejemplo de productos de trabajo 24
Subprácticas 24
Prácticas genéricas 24
Elaboraciones de la práctica genérica 25
Extensiones 25
Componentes informativos de soporte 25
notas 25
Ejemplos 25
referencias 26
Esquema de numeración 26
Convenciones tipográficas 27
3 unIEndO tOdO 31
Comprendiendo los niveles 31
Estructuras de las representaciones continua y por etapas 32
Comprediendo los niveles de capacidad 34
nivel de capacidad 0: Incompleto 35
nivel de capacidad 1: realizado 35
nivel de capacidad 2: Gestionado 35
nivel de capacidad 3: definido 35
Avanzando a través de los niveles de capacidad 36
Comprendiendo los niveles de madurez 41
nivel de madurez 1: Inicial 42
nivel de madurez 2: Gestionado 42
nivel de madurez 3: definido 43
nivel de madurez 4: Gestionado cuantitativamente 43
nivel de madurez 5: En optimización 44
Avanzando a través de los niveles de madurez 45
áreas de proceso 46
representación equivalente 49
Alcanzado alta madurez 52
4 rELACIOnES EntrE árEAS dE PrOCESO 59

Gestión de Procesos 60
áreas de proceso básicas de Gestión de Procesos 60
Contenido v
áreas de proceso avanzadas de Gestión de Procesos 62

Gestión de Proyectos 64
áreas de proceso básicas de Gestión de Proyectos 64
áreas de proceso avanzadas de Gestión de Proyectos 66
Ingeniería 68
recursión e iteración de los procesos de Ingeniería 74
Soporte 77
áreas de proceso básicas de Soporte 78
áreas de proceso avanzadas de Soporte 79
5 utILIzAndO LOS MOdELOS CMMI 85

Adoptando CMMI 90
Su programa de mejora de procesos 94
Selecciones que influyen en su programa 98
Modelos CMMI 99
Interpretando CMMI al utilizar enfoques ágiles 100
utilizando las evaluaciones CMMI 104
requisitos de la evaluación para CMMI 105
Métodos de evaluación SCAMPI 105
Consideraciones de la evaluación 106
Formación relacionada con CMMI 107
segunda parte: Metas GenÉriCas Y prÁCtiCas GenÉriCas,

Y Las Áreas de proCeso 163
MEtAS GEnérICAS y PráCtICAS GEnérICAS 165

Visión general 165
Institucionalización del proceso 165
Proceso realizado 166
Proceso gestionado 166
Proceso definido 166
relaciones entre procesos 168
Metas genéricas y prácticas genéricas 168
Aplicando las prácticas genéricas 226
áreas de proceso que dan soporte a las prácticas genéricas 229
AnALISIS CAuSAL y rESOLuCIón 233
GEStIón dE COnFIGurACIón 243
AnáLISIS dE dECISIOnES y rESOLuCIón 257
GEStIón IntEGrAdA dEL PrOyECtO 267
MEdICIón y AnáLISIS 287
dEFInICIón dE PrOCESOS dE LA OrGAnIzACIón 303
EnFOquE En PrOCESOS dE LA OrGAnIzACIón 317
GEStIón dEL rEndIMIEntO dE LA OrGAnIzACIón 331
rEndIMIEntO dE PrOCESOS dE LA OrGAnIzACIón 351
iv Contenido
FOrMACIón En LA OrGAnIzACIón 365
IntEGrACIón dEL PrOduCtO 377
MOnItOrIzACIón y COntrOL dEL PrOyECtO 393
PLAnIFICACIón dEL PrOyECtO 403
ASEGurAMIEntO dE LA CALIdAd dEL PrOCESO y dEL PrOduCtO 425
GEStIón CuAntItAtIVA dEL PrOyECtO 433
dESArrOLLO dE rEquISItOS 455
GEStIón dE rEquISItOS 473
GEStIón dE rIESGOS 481
GEStIón dE ACuErdOS COn PrOVEEdOrES 497
SOLuCIón téCnICA 509
VALIdACIón 531
VErIFICACIón 541
tercera parte: apÉndiCes 553
APéndICE A: rEFErEnCIAS 555

Aseguramiento de la información/Fuentes relacionadas con la
seguridad de la información 560
APéndICE B: ACrónIMOS 561
APéndICE C: PArtICIPAntES dEL PrOyECtO CMMI VErSIón 1.3 565
Comité de dirección de CMMI 565
Miembros del Comité de dirección 566
Miembros del Comité de dirección ex Officio 566
Soporte del Comité de dirección 566
Grupo Asesor de CMMI para Servicios 566
Equipo de Coordinación de CMMI V1.3 567
Comité de Control de Configuración de CMMI V1.3 567
Equipo Base del Modelo CMMI V1.3 568
Equipo de traducción de CMMI V1.3 569
Equipo de Alta Madurez de CMMI V1.3 569
Mini Equipo de Adquisición de CMMI V1.3 570
Mini Equipo de Servicios de CMMI V1.3 570
Equipo de Actualización de SCAMPI de CMMI V1.3 570
Equipos de Formación de CMMI V1.3 571
Equipo de Formación de ACq y dEV 571
Equipo de Formación de SVC 571
Equipo de Calidad de CMMI V1.3 572
APéndICE d: GLOSArIO 573
prefaCio
Los modelos CMMI® (Capability Maturity Model® Integration)

son colecciones de buenas prácticas que ayudan a las
organizaciones a mejorar sus procesos. Estos modelos son
desarrollados por equipos de producto con miembros procedentes
de la industria, del gobierno y del Software Engineering Institute
(SEI).
Este modelo, denominado CMMI para Desarrollo (CMMI-
DEV), proporciona un conjunto completo e integrado de guías
para desarrollar productos y servicios.
propósito
El modelo CMMI-DEV proporciona una orientación para aplicar
las buenas prácticas CMMI en una organización de desarrollo. Las
buenas prácticas del modelo se centran en las actividades para
desarrollar productos y servicios de calidad con el fin de
cumplir las necesidades de clientes y usuarios finales.
El modelo CMMI-DEV V1.3 es una colección de buenas
prácticas de desarrollo procedentes de la industria y del gobierno,
que se ha generado a partir de la Arquitectura y Marco1 de CMMI
V1.3. CMMI- DEV está basado en el CMMI Model Foundation
o CMF (es decir, componentes del modelo comunes a todos los
modelos y constelaciones CMMI2) e incorpora el trabajo
realizado por organizaciones de
1. El Marco CMMI es la estructura básica que organiza los componentes de CMMI y los
combina en las constelaciones y modelos CMMI.
2. Una constelación es una colección de componentes CMMI que se utilizan para
construir modelos, materiales de formación y documentos relativos a la evaluación para un
área de interés (p. ej., desarrollo, adquisición, servicios).
vii
viii Prefacio
desarrollo para adaptar CMMI para su uso en el desarrollo de

productos y servicios.
agradecimientos
Muchas personas competentes han participado en el desarrollo
del Conjunto de Productos (Product Suite) de CMMI V1.3.
Los tres principales grupos de CMMI han sido el Comité de
Dirección (Stee- ring Group), el Equipo de Producto (Product
Team), y el Comité de Control de Configuración
(Configuration Control Board, CCB). El Comité de Dirección
ha guiado y aprobado los planes del Equipo de Producto, ha
asesorado sobre cuestiones importantes del proyecto CMMI y
ha asegurado la involucración de las distintas
comunidades interesadas.
El Comité de Dirección ha supervisado el desarrollo de la
cons- telación de Desarrollo, reconociendo la importancia de
proporcionar buenas prácticas a las organizaciones de
desarrollo.
El Equipo de Producto ha escrito, revisado, modificado,
debati- do y acordado la estructura y el contenido técnico del
Conjunto de Productos de CMMI, incluyendo el marco, los
modelos y los materiales de formación y de evaluación. Las
actividades de desarrollo se basaron en múltiples fuentes. Estas
fuentes incluyeron el documento “A-Specification” y las
orientaciones específicas para cada versión proporcionadas por
el Comité de Dirección, los modelos de origen, las peticiones
de cambio recibidas de la comunidad de usuarios, y las
aportaciones recibidas de los proyectos piloto y de otras partes
interesadas.
El comité CCB es el mecanismo oficial para controlar los cam-
bios a los modelos CMMI, a los documentos de evaluación
relacionados y al curso de formación “Introduction to CMMI”.
Como tal, este grupo asegura la integridad a lo largo de la vida
del conjunto de productos, revisando todos los cambios
propuestos a la línea base y aprobando solamente aquellos que
satisfacen las cuestiones identificadas y que cumplen con los
criterios exigidos para la siguiente versión.
En el apéndice C se encuentran listados los miembros de los
grupos que estuvieron involucrados en el desarrollo de CMMI-
DEV V1.3.
audiencia
La audiencia de CMMI-DEV incluye a cualquier persona
interesada en la mejora de procesos en un entorno de desarrollo.
CMMI-DEV le será útil si está familiarizado con el concepto de
los Modelos de Ma- durez y de Capacidad o si está buscando
información para comenzar a mejorar sus procesos de desarrollo.
Este modelo también está pensado
Prefacio ix
para organizaciones que quieran usar un modelo de referencia
para una evaluación de sus procesos de desarrollo 3.
organización de este documento

Este documento está organizado en tres partes principales:
• Primera Parte: Acerca de CMMI para Desarrollo.

• Segunda Parte: Metas genéricas y prácticas genéricas, y las
áreas de proceso.
• Tercera Parte: Apéndices y glosario.
La Primera Parte, Acerca de CMMI para Desarrollo,
comprende cinco capítulos:
• Capítulo 1. Introducción, ofrece una visión amplia de CMMI
y de la constelación CMMI para Desarrollo, conceptos de
mejora de procesos y la historia de los modelos utilizados
para la mejora de procesos, así como diferentes enfoques para
la mejora de procesos.
• Capítulo 2. Componentes del área de proceso, describe todos
los componentes de las áreas de proceso de CMMI para
Desarrollo4.
• Capítulo 3. Uniendo todo, ensambla los componentes del
modelo y explica los conceptos de niveles de madurez y
niveles de capacidad.
• Capítulo 4. Relaciones entre áreas de proceso, explica el
significado e interacciones entre las áreas de proceso de
CMMI-DEV.
• Capítulo 5. Utilizando los modelos CMMI, describe formas
para adoptar y utilizar CMMI para la mejora de procesos y
para el benchmarking. de prácticas en una organización de
desarrollo.
La Segunda Parte, Metas genéricas y prácticas genéricas y las
áreas de proceso, contiene todos los componentes requeridos y
esperados del modelo CMMI. También contiene componentes
informativos relacionados, incluyendo subprácticas, notas,
ejemplos y ejemplos de productos de trabajo.
3. Una evaluación es un examen de uno o más procesos realizada por un equipo de

profesionales entrenado utilizando un modelo de referencia (p. ej., CMMI-DEV) como
base para determinar las fortalezas y las debilidades.
4. Un área de proceso es un conjunto de prácticas relacionadas en un área que, cuando se
implementan conjuntamente, satisface un conjunto de metas consideradas importantes
para lograr una mejora en ese área. Este concepto se desarrolla en detalle en el Capítulo 2.
x Prefacio
La Segunda Parte contiene 23 secciones. La primera sección

contiene las metas y prácticas genéricas. Las restantes 22
secciones corresponden a cada una de las áreas de proceso de
CMMI-DEV.
Para facilitar la búsqueda de las áreas de proceso, se han
organizado alfabéticamente por su acrónimo en inglés. Cada
sección contiene las descripciones de metas, buenas prácticas y
ejemplos.
La Tercera Parte, Apéndices y Glosario, comprende cuatro secciones:
• Apéndice A: Referencias, contiene referencias que puede
utilizar para localizar fuentes de información, tales como
informes, modelos de mejora de procesos, estándares del
sector y libros relacionados con CMMI-DEV.
• Apéndice B: Acrónimos, define los acrónimos usados en el
modelo.
• Apéndice C: Participantes en el proyecto CMMI versión 1.3,
contiene las listas de los miembros de los equipos que han
participado en el desarrollo de CMMI-DEV V1.3.
• Apéndice D: Glosario, define muchos de los términos
utilizados en CMMI-DEV.
Como usar este documento

Tanto si se está iniciando en la mejora de procesos o en CMMI
como si ya está familiarizado con CMMI, la primera parte puede
ayudarle a comprender por qué CMMI-DEV es el modelo a
utilizar para mejorar sus procesos de desarrollo.
Lectores que se inician en la mejora de procesos

Si se está iniciando en la mejora de procesos o en el concepto de
Capa- bility Maturity Model (CMM®), sugerimos que lea primero
el Capítulo
1. El Capítulo 1 contiene una visión general de la mejora de
procesos que explica qué es CMMI.
A continuación, ojee la Segunda Parte, que contiene las metas
y las prácticas genéricas, y las metas y prácticas específicas, para
hacerse una idea del alcance de las buenas prácticas contenidas
en el modelo. Preste mucha atención al propósito y a las notas
introductorias al comienzo de cada área de proceso.
En la Tercera Parte, consulte las referencias del apéndice A y
seleccione fuentes adicionales que considere útiles antes de
seguir adelante con el uso de CMMI-DEV. Lea los acrónimos y el
glosario para fami- liarizarse con la terminología de CMMI.
Finalmente vuelva y lea los detalles de la Segunda Parte.
Lectores con experiencia en mejora de procesos

Si se está iniciando en CMMI, pero tiene experiencia con otros
modelos de mejora de procesos, tales como el CMM Software o
Systems
Prefacio xi
Engineering Capability Model (EIA 731), podrá reconocer
inmediatamente numerosas similitudes en su estructura y
contenido [EIA 2002a].
Recomendamos que lea la Primera Parte para comprender las
diferencias entre CMMI y los otros modelos de mejora de
procesos. Si tiene experiencia con otros modelos, puede querer
seleccionar qué secciones leer primero. Lea la Segunda Parte
prestando atención a las buenas prácticas que pueda reconocer de
otros modelos que ya haya utilizado. Identificando el material
que le es familiar, le permitirá distinguir lo que es nuevo, lo que
ha sido eliminado y lo que le es familiar de los otros modelos que
ya conocía.
A continuación, revise el glosario para comprender las
diferencias de terminología con los modelos de mejora de
procesos que conoce. Muchos conceptos serán comunes, pero
pueden ser denominados de manera diferente.
Lectores familiarizados con CMMi

Si ha consultado o utilizado antes un modelo CMMI, reconocerá
rá- pidamente los conceptos tratados y las buenas prácticas
presentadas. Como siempre, las mejoras que el Equipo de
Producto CMMI ha realizado a CMMI para la versión 1.3
estuvieron guiadas por las aportaciones de los usuarios. Las
peticiones de cambio fueron cuidadosamente consideradas,
analizadas e implementadas.
Algunas mejoras significativas que puede encontrar en CMMI-
DEV V1.3 son:
• Las áreas de proceso de alta madurez se han mejorado de
manera significativa para reflejar las buenas prácticas del
sector, incluyendo una nueva meta específica y varias
prácticas específicas nuevas en el área de proceso de
Innovación y Despliegue en la Organización (OID) que ha
sido renombrada como Gestión del Rendimiento de la
Organización (OPM).
• Mejoras en la arquitectura del modelo que simplifican el uso
de múltiples modelos.
• Material informativo que ha sido mejorado, incluyendo una
co- rrección de las prácticas de ingeniería para reflejar las
buenas prácticas del sector y añadir orientaciones para las
organizaciones que utilicen métodos ágiles.
• Las definiciones del glosario y la terminología del modelo
han sido mejoradas para aumentar la claridad, precisión y
facilidad de uso del modelo.
• Las metas y prácticas genéricas de los niveles 4 y 5 han sido
eliminadas, así como los niveles de capacidad 4 y 5 para cen-
trar apropiadamente la alta madurez en la consecución de los
objetivos del negocio, lo cual se consigue aplicando el nivel
de capacidad 1-3 a las áreas de proceso de alta madurez
(Análisis
xii Prefacio
Causal y Resolución, Gestión Cuantitativa del Proyecto,

Gestión del Rendimiento de la Organización y Rendimiento de
Procesos de la Organización).
Para una lista más completa y detallada de las mejoras, véase
http:// www.sei.cmu.edu/cmmi/tools/cmmiv1-3/.
información adicional y sugerencias del lector

Muchas fuentes de información acerca de CMMI se encuentran lis-
tadas en el Apéndice A y están también publicadas en el sitio web
de CMMI –http://www.sei.cmu.edu/cmmi/.
Cualquier sugerencia para mejorar CMMI será bien recibida.
Para más información sobre cómo proponer sugerencias, vaya al
sitio web de CMMI en http://www.sei.cmu.edu/cmmi/tools/cr/. Si
tiene alguna pregunta acerca de CMMI, envíe un correo
electrónico a cmmi-com- ments@sei.cmu.edu.
sobre La ediCión en españoL
CoLaboradores
La Cátedra de Mejora de Procesos Software en el Espacio Ibero-

americano (MPSEI) de la Universidad Politécnica de Madrid
(UPM) patrocinada por la Fundación Everis y dirigida por José A.
Calvo- Manzano ha llevado a cabo la coordinación y traducción del
libro. El equipo ha estado formado por:
• Coordinadores:
– Gonzalo Cuevas (Cátedra MPSEI).
– José A. Calvo-Manzano (Cátedra MPSEI).
– Tomás San Feliu (Cátedra MPSEI).
– Fernando Arboledas (Cátedra MPSEI).
– José Antonio Cerrada (Cátedra MPSEI).
• Traductores:
– Fernando Arboledas (España, Cátedra MPSEI).
– Luz Sussy Bayona (Perú, Cátedra MPSEI).
– Edgar Henry Caballero (Bolivia, Cátedra MPSEI).
– José A. Calvo-Manzano (España, UPM).
– José Antonio Cerrada (España, Universidad Nacional de
Edu- cación a Distancia - UNED).
– Gonzalo Cuevas (España, UPM).
– Alleinni Féliz (República Dominicana, Cátedra MPSEI).
– Gloria Piedad Gasca (Colombia, Universidad de Medellín).
– Iván Antonio García (México, Universidad Tecnológica
de la Mixteca).
xiii
xiv SOBrE LA EdICIón En ESPAñOL
– Gerzón Eliud Gómez (México, Universidad Autónoma
de Yucatán).
– José de Jesús Jiménez (Panamá, Universidad de Panamá).
– Jezreel Mejía (México, Centro de Investigación en
Matemáticas- CIMAT).
– Santiago Matalonga (Uruguay, Universidad ORT).
– Mirna Ariadna Muñoz (México, Centro de Investigación
en Matemáticas - CIMAT).
– Tomás San Feliu (España, UPM).
– Edgar Ariel Serrano (México, Cátedra MPSEI).
– Vianca Rosa Vega (Chile, Universidad Católica del
Norte de Chile).
Accenture es una compañía global de consultoría de gestión,

servicios tecnológicos y outsourcing, que cuenta con más de
238.000 profesionales trabajando en más de 120 países.
Combinando su experiencia, sus capacidades en todos los sectores
y áreas de negocio, y su investi- gación con las compañías de más
éxito del mundo, Accenture colabora con sus clientes para ayudarles
a convertir sus organizaciones en negocios y administraciones
públicas de alto rendimiento.
Coritel, líder en gestión de soluciones tecnológicas, es la compañía
del grupo Accenture en España especializada en servicios de
desarrollo y mantenimiento de aplicaciones, desde su fundación
en 1984. Sus Centros de desarrollo han sido una referencia CMMI
a nivel nacional e internacional desde 1993, cuando fue la
primera compañía en España en obtener SW-CMM L5, nivel que
ha venido revalidando hasta obtener en julio de 2010 su
actualización al CMMI DEV v 1.3 ML5.
El grupo Accenture ha revisado y verificado la traducción del
libro. El equipo ha estado formado por:
• Coordinadores:
– Ulises Arranz (Coritel. SPAI Industrialization Lead).
– Ricardo Panero (Coritel. SDC SEPG Lead).
• Colaboradores:
– Ricardo Panero (Coritel. SDC SEPG Lead).
– Ignacio Godoy (Acenture. SI Industrialization Lead).
– Eva Muñoz (Accenture. QA Manager).
– Alicia Martínez (Coritel. Continuous Improvement).
– Esther Torrego (Accenture. Continuous Improvement).
– Alberto Jiménez (Accenture. AO Industrialization Lead).
– Lucía Sánchez (Coritel. Continuous Improvement).
– Lourdes López (Accenture. QA Manager).
Colaboradores xv
• Lead Appraiser Review:
– Giuseppe Magnani (Business Strategy. CMMI Lead Appraiser).
Para más información: www.coritel.es, www.accenture.es
Informática El Corte Inglés es uno de los principales proveedores

de consultoría tecnológica y soluciones TIC en el mercado
nacional e internacional, con sede en España y operaciones en
12 países. Con una presencia consolidada en el entorno de la
empresa privada y siendo un importante proveedor TIC de la
Administración Pública, su oferta de servicios informáticos y de
outsourcing se dirige a una economía más sostenible en el uso y
aprovechamiento de los recursos.
El esmero en el trato del cliente (característico de todo el Grupo
El Corte Inglés), la apuesta por los profesionales nacionales y
sus iniciativas por difundir la innovación TI, son señas de
identidad de la organización. La compañía también es pionera
en la implantación de buenas prácticas y modelos de calidad en
el mercado español. Informática El Corte Inglés inició el
despliegue del modelo CMMI, en 2005. Un hito en este esfuerzo
fue la consecución, en 2009, del nivel de madurez 3 en sus
Factorías Software según el modelo CMMI DEV V1.2. En la
actualidad, la organización está preparando el assessment de nivel
5 para el presente año en el ámbito de las Factorías Software
dentro de un continuo esfuerzo de mejora, recogido en su
programa de mejora de procesos ÓPTIMA.
La colaboración de Informática El Corte Inglés en la edición oficial
de CMMI DEV V1.3 en español, como patrocinador y en su
revisión, muestra de nuevo la apuesta de la organización por la
popularización de este modelo tanto en España como en
Iberoamérica, con el fin de ayudar a las empresas a conseguir sus
objetivos de negocio a través de la mejora de sus procesos.
El equipo de Informática El Corte Inglés ha participado como
patrocinador del editor y como revisores de calidad de la
traducción. El equipo de revisión ha estado formado por:
• Coordinador:
– Elena Rubio (Responsable del Grupo de Mejora de Procesos).
• Colaboradores:
– Joaquín Cervera (Grupo de Mejora de Procesos).
– Susana Escabias (Grupo de Mejora de Procesos).
– Yaser Rimawi (Grupo de Mejora de Procesos).
Para más información: www.ieci.es
xvi SOBrE LA EdICIón En ESPAñOL
Nuevamente everis participa como patrocinador en la traducción

de CMMI, en este caso para la versión 1.3, manteniendo e
impulsando su apuesta por la aplicación en sus procesos de
desarrollo y mantenimien- to de software de aquellos estándares y
buenas prácticas de referencia en esta industria. Si en la traducción
de CMMI v1.2 comentábamos que una parte de everis,
concretamente los centros de desarrollo (everis centers), llevaban
años con un ambicioso programa de certificación bajo CMMI,
ahora podemos felicitarnos de los logros obtenidos, fruto de los
cuales, se ha renovado y evolucionado el programa para la con-
secución de la certificación de nivel 5.
En nuestra apuesta por CMMI como el referente de las buenas prác-
ticas existentes en cuanto a desarrollo y mantenimiento de software,
desde el inicio de este año fiscal, estamos embarcados en el
proceso de certificación CMMI for services para todas las oficinas de
everis en LATAM (Brasil, Argentina, Chile, Perú, Colombia y México).
Finalmente, esperamos que esta nueva traducción al español de
CMMI contribuya, aún más, a incrementar la calidad de los
desarrollos de software en los países de habla hispana, como
consecuencia directa de la ayuda que la difusión en español de
la certificación pudiera aportarles.
Para más información: www.everis.es
El Instituto Nacional de Tecnologías de la Comunicación, INTECO,

sociedad estatal adscrita al Ministerio de Industria, Energía y
Turismo del Gobierno de España, a través de la Secretaría de Estado
de Telecomunica- ciones y para la Sociedad de la Información, ha
participado en la traduc- ción de este libro como entidad asesora
especializada en la promoción de la calidad de las Tecnologías de la
Información y las Comunicaciones.
El Instituto tiene los siguientes objetivos:
• Servir como instrumento para desarrollar la Sociedad de la
Informa- ción, con actividades propias en el ámbito de la
innovación y el desarrollo de proyectos asociados a las
Tecnologías de la Información y las Comunicaciones,
basándose en tres pilares fundamentales: la investigación
aplicada, la prestación de servicios y la formación.
Colaboradores xvii
• Aportar valor e innovación a los ciudadanos, a las PYMES, a
las Administraciones Públicas y al sector de las tecnologías de
la infor- mación, a través del desarrollo de proyectos que
contribuyan a reforzar la confianza en los servicios de la
Sociedad de la Información en nuestro país, promoviendo
además una línea de participación internacional.
• Promover unos servicios de la Sociedad de la Información que
cada vez sean de mayor calidad, que garanticen unos
adecuados niveles de servicio, lo cual se traduce en una mayor
robustez de aplicaciones y sistemas, un compromiso en la
disponibilidad y los tiempos de respuesta, un adecuado soporte
para los usuarios, una información precisa y clara sobre la
evolución de las funcionalidades de los servicios, y en
resumen, servicios cada vez mejores.
• Impulsar la competitividad de la industria del Software a través
de la promoción de la mejora de la calidad y la certificación de
las empresas y profesionales de la ingeniería del software.
Para más información: www.inteco.es
El Centro de Investigación en Matemáticas, A.C., que ha

participado en la traducción de este libro como patrocinador,
pertenece al Sistema de Centros Públicos de Investigación del
Consejo Nacional de Ciencia y Tecnología (CONACyT) y fue
fundado en la ciudad de Guanajuato en 1980, con el objetivo de
fomentar la investigación, el estudio, el desarrollo y la difusión
de las matemáticas, así como sus aplicaciones en las diversas
áreas del quehacer científico y tecnológico.
Su tarea fundamental consiste en generar conocimiento científico a
tra- vés de la investigación en las áreas de Matemáticas Básicas y
Aplicadas, Probabilidad y Estadística y Ciencias de la
Computación; a través de una estructura transversal que articula
las actividades de investigación, docencia y vinculación.
El CIMAT cuenta con personal científico y tecnológico del más
alto nivel, que permite ofrecer programas de excelencia en sus
áreas de especialidad a nivel licenciatura y posgrado, así como
fortalecer la vin- culación con los sectores público, privado y
social a través del desarrollo de proyectos de investigación
aplicada, de la oferta de servicios tecnológicos y de consultoría,
de la impartición de programas de capa- citación y de la difusión y
la divulgación de las matemáticas.
Para más información: www.cimat.mx

prefaCio
Después de haber llevado a cabo la traducción al español del

modelo CMMI para Desarrollo en su versión 1.2, y de haber
participado en el equipo internacional CTT (CMMI Translation
Team) de la versión 1.3 (cuyo objetivo era proponer mejoras al
texto inglés del modelo con el fin de que la traducción a los
diferentes idiomas fuera más comprensible), hemos considerado
oportuno llevar a cabo también la traduc- ción del CMMI para
Desarrollo V1.3 con el fin de aprovechar nuestras experiencias
anteriores, y poner a disposición de los lectores de habla hispana
la nueva versión en español que supone una serie cambios
importantes y fundamentales.
Esta traducción ha supuesto un trabajo más duro aún que el ante-
rior con una participación más amplia del mundo empresarial y
universitario que ha exigido un esfuerzo de coordinación y
consenso mayores. Ha predominado el consenso con el mundo
empresarial.
Para una homogeneidad en la traducción se ha consensuado
un diccionario de términos y frases en los distintos contextos por
todas las partes involucradas, que confiamos aumenten la calidad
y facilidad de comprensión de los lectores. Este diccionario ha
sido una herramienta viva que se iba actualizando con los
diferentes conflictos y resoluciones tomadas.
Asimismo con el fin de aumentar la calidad, se ha mejorado
el proceso de traducción con las lecciones aprendidas de la
traducción anterior, incrementado sensiblemente el número de
revisiones internas y externas.
Al igual que en la versión anterior, se han mantenido las siglas y
los acrónimos relativos a los componentes del modelo, es decir,
áreas de proceso y sus componentes (GG, GP, SG, SP), así como
abreviaturas tales como “COTS”. Esto, al igual que en la versión
anterior, facilitará
xix
xx SOBrE LA EdICIón En ESPAñOL
la comunicación con la comunidad internacional usuaria de la
nueva versión del CMMI, evitando equívocos innecesarios.
Asimismo, como en la versión anterior, después de acaloradas
dis- cusiones se ha llegado al consenso entre el mundo
universitario y el empresarial respecto a los nombres de las áreas
de proceso.
Como ocurre siempre, prácticamente nunca se llega a la
perfección y será necesario posteriormente refinar algunas
expresiones, aunque esperamos que las definiciones actuales no
impidan la comprensión del modelo por parte de los lectores de la
versión española.
Finalmente, agradecemos el esfuerzo desinteresado llevado a
cabo por los equipos de Accenture-CORITEL e Informática El
Corte Inglés, así como el soporte aportado por everis, Instituto
Nacional de Tec- nologías de la Comunicación (INTECO),
Centro de Investigación en Matemáticas de México (CIMAT) y la
ayuda del editor, sin todo lo cual hubiera sido prácticamente
imposible que viera la luz la versión 1.3 de CMMI para Desarrollo
en español.
Equipo Coordinador de la traducción

CMMI-DEV V1.3
próLoGo
La publicación en español de la edición revisada 1.3 de “CMMI®

para Desarrollo – Guía para la integración de procesos y la mejora
de productos” constituye un acontecimiento que marca una
época en la estrategia hacia la competitividad de la industria del
software latinoame- ricana y española. Si la segunda edición hace
ya dos años supuso un éxito, convirtiendo la traducción
castellana en una de las más deman- dadas a nivel internacional,
esta tercera edición supone una confirma- ción de la pujanza de
este sector tecnológico, que confía en la mejora permanente y la
calidad como ineludible base de partida para lograr una mayor
competitividad en los mercados.
En el caso de España, sus empresas encabezan el mayor número de
organizaciones evaluadas en Europa y ocupa la cuarta posición a
escala mundial por detrás de China, Estados Unidos e India,
según el informe del SEI publicado en septiembre de 2011,
“CMMI® for Develop- ment SCAMPISM Class A Appraisal Results
2011 Mid-Year Update”. El informe también señala que son casi
200 las organizaciones españolas actualmente en posesión del
certificado CMMI, mientras que esta cifra era de menos de 10 en
2005, y ocupan unas posiciones muy destaca- das países como
Brasil, con 125 organizaciones certificadas, México con 95 o
Argentina con 66 entidades. Podemos constatar en los años
recientes una consistente tradición que se ha alcanzado
igualmente en otras áreas de estandarización de las tecnologías de
la información y la comunicación, especialmente las referentes a
la seguridad de la infor- mación o la accesibilidad web.
En este contexto, la publicación en español de esta Guía CMMI
para Desarrollo –completa y actualizada–, supone un desarrollo
muy esperado. La nueva versión de la Guía ha tenido en cuenta
las contribuciones de expertos internacionales, tanto
pertenecientes a la
xxi
xxii SOBrE LA EdICIón En ESPAñOL
industria del software como al ámbito académico, intentando
ambas partes responder a las crecientes necesidades y expectativas
de los profesionales de la ingeniería del software.
Existe, por un lado, una creciente demanda de traducciones
de los estándares internacionales en materia de nuevas
tecnologías, ante la necesidad de agilizar la incorporación de
normas y métodos a los procesos de producción, que resulta
clave a efectos de competir con mayor calidad, reduciendo a la
vez los precios y plazos de entrega a los clientes. La
internacionalización de los mercados conlleva la necesidad de
superar las barreras lingüísticas, de modo que documentos tales
como acuerdos, contratos, manuales y todo tipo de
correspondencia comercial han de redactarse cada día en un
mayor número de lenguas. Por otro lado, la comunicación entre
profesionales de distintas organizaciones resulta vital para
asegurar la cadena de valor en la pro- ducción de software de
calidad, tanto a nivel de cooperación entre proveedores y
clientes como entre éstos y sus socios en un mundo global, donde
el desarrollo del software puede realizarse simultáneamente en
varios países. Esta Guía facilita sin duda la coordinación
mediante
métodos comprobados de innovación en los procesos.
En el apartado de felicitaciones, la labor de coordinación
efectua- da por los responsables de la cátedra de Mejora de
Procesos Software en el Espacio Iberoamericano (MPSEI) de la
Universidad Politécnica de Madrid, particularmente Gonzalo
Cuevas Agustín, José Antonio Calvo-Manzano y Tomás San
Feliu Gilabert, merece nuestro máximo reconocimiento.
Es nuestro deseo ferviente que esta edición de la Guía CMMI
pro- fundice el conocimiento de los modelos de mejora de los
procesos en el colectivo de profesionales de la programación y
desarrollo de software y estimule ampliamente su implantación
en las organizaciones que desarrollan tales productos.
Víctor M. Izquierdo LOYOLA

Director
General Instituto Nacional de Tecnologías de la
Comunicación - INTECO
primera parTe
acerca de Cmmi para

Desarrollo
CapíTulo 1
inTroDuCCión
Ahora más que nunca, las compañías desean entregar mejores

productos y servicios en menos tiempo y más baratos. Al
mismo tiempo, en los entornos de alta tecnología del siglo
veintiuno, casi todas las organizaciones se han visto abocadas a
construir productos y servicios cada vez más complejos. Hoy en
día es raro que las organizaciones desarrollen todos los
componentes que forman parte de un producto o servicio
complejo. Frecuentemente, algunos componentes se construyen
internamente y otros se adquieren; posteriormente, todos los
componentes se integran en el producto o servicio final. Las
organizaciones deben ser capaces de gestionar y controlar este
complejo proceso de desarrollo y mantenimiento.
Los problemas que estas organizaciones se encuentran hoy en día
implican soluciones que conciernen a toda la empresa y
requieren un enfoque integrado. La gestión eficaz de los activos
de la organización es crítica para el éxito de su actividad. En
esencia, estas organizaciones son desarrolladoras de productos
y servicios que necesitan una manera de gestionar sus actividades
de desarrollo como parte de la consecución de sus objetivos de
negocio.
En el mercado actual existen modelos de madurez,
estándares, metodologías y guías que pueden ayudar a una
organización a mejorar la forma de hacer su negocio. Sin
embargo, la mayoría de los enfoques de mejora existentes se
centran en una parte específica de su actividad y no tienen un
enfoque sistemático de los problemas a los que se enfrentan la
mayoría de las organizaciones. Desafortuna- damente, al
centrarse en mejorar un área de negocio, estos modelos han
hecho que persistan los nichos y las barreras existentes en el seno
de las organizaciones.
CMMI® para Desarrollo (CMMI-DEV) proporciona una opor-
tunidad para evitar o eliminar estos nichos y barreras. CMMI
para Desarrollo consta de buenas prácticas que tratan las
actividades de desarrollo aplicadas a productos y servicios.
Aborda las prácticas que cubren el ciclo de vida del producto
desde la concepción hasta la entrega y el mantenimiento.
3
4 Primera Parte acerca de cmmi Para desarrollo
El énfasis está en el trabajo necesario para construir y

mantener el producto completo.
CMMI-DEV contiene 22 áreas de proceso. De esas áreas de
proceso, 16 son áreas de proceso base, 1 es un área de proceso
compartida y 5 son áreas de proceso específicas de desarrollo1.
Todas las prácticas del modelo CMMI-DEV se centran en las
actividades de la organización desarrolladora. Cinco áreas de
proceso se centran en las prácticas específicas del desarrollo:
tratando desarrollo de requisitos, solución técnica, integración del
producto, verificación y validación.
acerca de la mejora de procesos

El Software Engineering Institute (SEI), en sus
investigaciones para ayudar a las organizaciones a desarrollar y
mantener productos y servicios de calidad, ha identificado varias
dimensiones en las que una organización puede centrarse para
mejorar su actividad. La Figura
1.1 ilustra las tres dimensiones críticas donde normalmente se
centran las organizaciones: las personas, los métodos y
procedimientos, y el equipamiento y herramientas.
¿Qué mantiene todo unido? Los procesos utilizados en su
organi- zación. Éstos le permiten alinear su modo de trabajar. Le
permiten
FiGUra 1.1
las tres dimensiones críticas
1. Un área de proceso base es un área de proceso que es común a todos los modelos
CMMI. Un área de proceso compartida está presente en al menos dos modelos CMMI,
pero no en todos.
Capítulo 1 Introducción 5
abordar la escalabilidad y proporcionan una forma para
incorporar el conocimiento de cómo hacer las cosas mejor. Los
procesos le permiten explotar mejor sus recursos y analizar las
tendencias de su actividad.
Esto no quiere decir que las personas y la tecnología no sean
importantes. Vivimos en un mundo donde la tecnología está
cambian- do a una velocidad increíble. Del mismo modo, las
personas trabajan normalmente para varias compañías a lo largo
de su vida profesional. Vivimos en un mundo dinámico. Un
enfoque en el proceso proporciona la infraestructura y la
estabilidad necesarias para hacer frente a un mundo siempre
cambiante y para maximizar la productividad de las personas y el
uso de la tecnología para ser competitivos.
La industria ha reconocido desde hace tiempo la importancia
de la eficacia y eficiencia del proceso. Hoy en día, muchas
organizaciones en los sectores de fabricación y de servicios
reconocen la importancia de procesos de calidad. El proceso
ayuda a los miembros de una organización a alcanzar los
objetivos de negocio ayudándoles a trabajar de manera más
inteligente, no con mayor esfuerzo, y de un modo más
consistente. Los procesos eficaces también proporcionan un
medio para introducir y utilizar nuevas tecnologías de manera
que permitan satisfacer mejor los objetivos de negocio de la
organización.
mirando al futuro
por WATTS Humphrey

acerca de los modelos de madurez y de capacidad

Un modelo de madurez y de capacidad (Capability Maturity
Model®, CMM®), incluyendo CMMI, es una representación
simplificada del mundo. Los CMMs contienen los elementos
esenciales de los procesos eficaces. Estos elementos se basan en
los conceptos desarrollados por Crosby, Deming, Juran y
Humphrey.
En la década de los 30, Walter Shewhart comenzó a trabajar
en la mejora de procesos con sus principios de control
estadístico de la calidad [Shewhart 1931]. Estos principios fueron
refinados por W. Ed- wards Deming [Deming 1986], Phillip
Crosby [Crosby 1979] y Joseph Juran [Juran 1988]. Watts
Humphrey, Ron Radice y otros los amplia- ron y comenzaron a
aplicarlos al software en su trabajo en IBM (In- ternational
Business Machines) y en el SEI [Humphrey 1989]. El libro de
Humphrey, MANAGING the SOFTWARe Process, describe los principios y
conceptos básicos en los que se basan muchos de los modelos de
madurez y de capacidad (Capability Maturity Models®, CMMs®).
El SEI ha tomado la premisa de la gestión de procesos, “la calidad
de un sistema o producto está muy influenciada por la calidad del
proceso empleado para desarrollarlo y mantenerlo” y ha definido
CMMs que recogen esta premisa. La adhesión a esta premisa se
encuentra en los movimientos de calidad de todo el mundo, como
lo muestra la International Organization for
Standardization/International Electro- technical Commission
(ISO/IEC) en su conjunto de estándares.
Los CMMs se centran en mejorar los procesos de una
organiza- ción. Contienen los elementos esenciales de los
procesos eficaces de una o más disciplinas y describen un camino
evolutivo de mejora desde procesos ad hoc e inmaduros a
procesos disciplinados y maduros con calidad y eficacia
mejoradas.
Al igual que otros CMMs, los modelos CMMI orientan en
el desarrollo de procesos. Los modelos CMMI no son procesos
ni descripciones de proceso. Los procesos reales utilizados en
una organización dependen de muchos factores, incluyendo
dominios de aplicación, y estructura y tamaño de la
organización. En particular, las áreas de proceso de un
modelo CMMI normalmente no se corresponden una a una
con los procesos utilizados en su organización.
El SEI creó el primer CMM concebido para organizaciones
software y lo publicó en el libro, The CApAbility MAturity Model:
Guide- lines for Improving the SoftwAre Process [SEI 1995].
Hoy en día, CMMI es una aplicación de los principios
introducidos hace casi un siglo a este ciclo interminable de
mejora de procesos. El valor de este enfoque de mejora de
procesos se ha confirma- do a lo largo del tiempo. Las
organizaciones han experimentado un crecimiento en
productividad y calidad, han mejorado la duración del ciclo de
vida y han logrado planificaciones y presupuestos más precisos y
previsibles [Gibson 2006].
evolución del Cmmi

El proyecto CMM Integration se creó para resolver el problema
de usar múltiples CMMs. La combinación de los modelos
seleccionados en un marco de mejora único pretendía que
fuera usado por organizaciones en su búsqueda de la mejora de
procesos para toda la empresa.
El desarrollo de un conjunto de modelos integrados implicó
más que una simple combinación de los materiales de los mode-
los existentes. Al usar procesos que fomentan el consenso, el
Equi- po del Producto CMMI creó un marco que da cabida a
múltiples constelaciones.
El primer modelo a desarrollar fue el CMMI para Desarrollo
(entonces denominado simplemente “CMMI”). La Figura 1.2
ilustra los modelos que condujeron a la versión 1.3 de CMMI.
Inicialmente, CMMI era un modelo que combinaba tres
modelos fuente: el CApAbility MAturity Model for SoftwAre
(SW-CMM) v2.0 draft C, el Systems Engineering CApAbility Model
(SECM) [EIA 2002a], y el IntegrAted Product Development
CApAbility MAturity Mo- del (IPD-CMM) v0.98.
Estos tres modelos fueron seleccionados debido al éxito en su
adopción o por su prometedor enfoque para mejorar los procesos
en una organización.
El primer modelo CMMI (V1.02) fue diseñado para usarse
por organizaciones de desarrollo en su búsqueda de la mejora de
procesos para toda la empresa. Fue publicado en 2000. Dos
años más tarde se publicó la versión 1.1, y cuatro años después se
publicó la versión 1.2.
CMM for Software Systems Engineering

V1.1 (1993) CMM V1.1 (1995)
INCOSE SECAM
(1996)
Software CMM
V2, draft C (1997)
Integrated Product
EIA 731 SECAM
Development CMM
(1998)
(1997)
Software Acquisition
CMM V1.03 (2002)
V1.02 (2000)
V1.1 (2002)
CMMI for Development

V1.2 (2006)
CMM for Acquisition CMMI for Services
V1.2 (2007) V1.2 (2009)
CMMI for Acquisition CMMI for Development CMMI for Services

V1.3 (2010) V1.3 (2010) V1.3 (2010)
FiGUra 1.2
la historia de los cmms2
A la vez que se publicó la versión 1.2, otros dos modelos

CMMI estaban siendo planificados. Debido a estos nuevos
modelos planificados, el nombre del primer modelo CMMI
tuvo que cambiar y pasar a ser CMMI para Desarrollo y se
creó el concepto de constelaciones.
El modelo CMMI para Adquisición se publicó en 2007.
Como fue elaborado a partir de la versión 1.2 del modelo
CMMI para Desarrollo, también se denominó versión 1.2. Dos
años más tarde se publicó el modelo CMMI para Servicios.
Como fue construido sobre los otros dos modelos, también fue
denominado versión 1.2. En 2008 se realizaron planes para
comenzar a desarrollar la ver- sión 1.3, que aseguraría la
consistencia entre los tres modelos y mejo- raría el material de
alta madurez en todos los modelos. La versión 1.3 de CMMI para
Adquisición [Gallagher 2011, SEI 2010b], CMMI para Desarrollo
[Chrissis 2011] y CMMI para Servicios [Forrester 2011,
SEI 2010a] se publicaron en noviembre de 2010.
2. EIA 731 SECM es el estándar de “Electronic Industries Alliance” o el Systems

Engineering Capability Model. INCOSE SECAM es el modelo de evaluación de
capacidad de Ingeniería de Sistemas del International Council on Systems Engineering
[EIA 2002a].
Cmmi: Continúa la integración y mejora
por Bob RASSA

marco Cmmi
El marco CMMI proporciona la estructura necesaria para crear los mo-
delos la formación y los componentes de evaluación de CMMI. Para
permitir el uso de múltiples modelos dentro del marco CMMI, los
componentes de los modelos se clasifican como comunes a todos los
modelos CMMI o aplicables a un modelo específico. El material co-
mún se denomina “CMMI Model Foundation” o “CMF.”
Los componentes del CMF son parte de todos los modelos
generados a partir del marco CMMI. Esos componentes se
combinan con el material aplicable a un área de interés (p. ej.,
adquisición, desarrollo, servicios) para crear un modelo.
Una “constelación” se define como una colección de
componentes CMMI que se usan para construir modelos,
materiales de formación y documentos relativos a la evaluación
para un área de interés (p. ej., adquisición, desarrollo, servicios).
El modelo de la constelación de desarrollo se denomina “CMMI
para Desarrollo” o “CMMI-DEV.”
la arquitectura del marco Cmmi
por Roger BATE

con un epílogo de Mike KONRAD
Cmmi para Desarrollo

CMMI para Desarrollo es un modelo de referencia que cubre las
actividades para desarrollar tanto productos como servicios. Las
organizaciones de numerosos sectores, incluyendo aeroespacial,
banca, hardware, software, defensa, automoción y
telecomunicaciones, utilizan el CMMI para Desarrollo.
CMMI para Desarrollo contiene prácticas que cubren la
gestión de proyectos, la gestión de procesos, la ingeniería de
sistemas, la ingenie- ría de hardware, la ingeniería de software y
otros procesos de soporte utilizados en el desarrollo y
mantenimiento.
Use su juicio profesional y el sentido común para interpretar
el modelo en su organización. Es decir, aunque las áreas de
proceso descritas en este modelo representen comportamientos
considerados buenas prácticas para la mayoría de los usuarios, las
áreas de proceso y las prácticas se deberían interpretar usando un
conocimiento profundo de CMMI-DEV, las restricciones de su
organización y su entorno de negocio.
Capítulo 2
Componentes del área de proCeso
En este capítulo se describen los componentes que se encuentran

en cada área de proceso y en las metas genéricas y prácticas
genéricas. La comprensión de estos componentes es crítica para
utilizar de forma eficaz la información de la Segunda Parte. Si
usted no está familiarizado con la Segunda Parte, le
recomendamos ojear la sección de “Metas Genéricas y Prácticas
Genéricas” y un par de secciones del área de proceso para hacerse
una idea general del contenido y de la estructura antes de la
lectura de este capítulo.
áreas de proceso base y los modelos CmmI

Todos los modelos CMMI se generan a partir del Marco CMMI.
Este marco contiene todas las metas y prácticas que se utilizan
para producir los modelos CMMI que pertenecen a las
constelaciones CMMI.
Todos los modelos CMMI contienen las 16 áreas de proceso
base. Estas áreas de proceso cubren los conceptos básicos que
son fundamentales para la mejora de procesos en cualquier área
de interés (es decir, adquisición, desarrollo, servicios). Una parte
del material de las áreas de proceso base es el mismo en todas las
constelaciones. Otra parte del material puede ajustarse para
orientar un área específica de interés. Por consiguiente, el
material en las áreas de proceso base puede no ser exactamente
el mismo.
Componentes requeridos, esperados e informativos

Los componentes del modelo se agrupan en tres categorías –
requeridos, esperados e informativos– que indican cómo
interpretarlos.
Componentes requeridos
Los componentes requeridos son componentes CMMI que son
esenciales para lograr la mejora de procesos en un área de
proceso dada. Este logro se debe implementar visiblemente en
los procesos de la
19
organización. Los componentes requeridos en CMMI son las

metas específicas y genéricas. La satisfacción de las metas se
utiliza en las evaluaciones como base para determinar si un área
de proceso ha sido satisfecha.
Componentes esperados
Los componentes esperados son componentes CMMI que
describen las actividades que son importantes para lograr un
componente CMMI requerido. Los componentes esperados
orientan a quienes implementan mejoras o realizan
evaluaciones. Los componentes esperados en CMMI son las
prácticas específicas y genéricas.
Antes de que las metas puedan considerarse satisfechas, sus
prác- ticas tal y como se describen, o prácticas alternativas
aceptables, deben estar presentes en los procesos planificados e
implementados de la organización.
Componentes informativos
Los componentes informativos son componentes CMMI que
ayudan a los usuarios del modelo a comprender los componentes
CMMI requeridos y esperados. Estos componentes pueden ser
ejemplos en un recuadro, explicaciones detalladas u otras
informaciones útiles. Las subprácticas, las notas, las referencias,
los títulos de metas, los títulos de prácticas, las fuentes, los
ejemplos de productos de trabajo y las elaboraciones de prácticas
genéricas son componentes informativos del modelo.
El material informativo juega un papel importante en la
compren- sión del modelo. Frecuentemente, es imposible
describir adecuadamente el comportamiento requerido o
esperado de una organización usando sólo una meta o la
declaración de una práctica. El material informativo del modelo
proporciona información necesaria para lograr la correcta
comprensión de las metas y prácticas y, por ello, no se puede
ignorar.
Componentes asociados con la segunda parte

Los componentes del modelo asociados con la Segunda Parte se
resumen en la Figura 2.1 en la que se muestran sus relaciones.
Las siguientes secciones proporcionan descripciones
detalladas de los componentes del modelo CMMI.
áreas de proceso
Un área de proceso es un grupo de prácticas relacionadas dentro
de un área que, cuando se implementan conjuntamente, satisface
un conjun- to de metas consideradas importantes para mejorar
ese área (véase la definición de “área de proceso” en el glosario).
Capítulo 2 Componentes del área de proceso 21
*** Inicio Página 21
FiGUra 2.1
componentes del modelo cmmi
Las 22 áreas de proceso se presentan a continuación por

orden alfabético de sus acrónimos en inglés:
• Análisis Causal y Resolución (CAR).
• Gestión de Configuración (CM).
• Análisis de Decisiones y Resolución (DAR).
• Gestión Integrada del Proyecto (IPM).
• Medición y Análisis (MA).
• Definición de Procesos de la Organización (OPD).
• Enfoque en Procesos de la Organización (OPF).
• Gestión del Rendimiento de la Organización (OPM).
• Rendimiento de Procesos de la Organización (OPP).
• Formación en la Organización (OT).
• Integración del Producto (PI).
• Monitorización y Control del Proyecto (PMC).
• Planificación del Proyecto (PP).

• Aseguramiento de la Calidad del Proceso y del Producto (PPQA).
• Gestión Cuantitativa del Proyecto (QPM).
• Desarrollo de Requisitos (RD).
• Gestión de Requisitos (REQM).
• Gestión de Riesgos (RSKM).
• Gestión de Acuerdos con Proveedores (SAM).
• Solución Técnica (TS).
• Validación (VAL).
• Verificación (VER).
declaraciones del propósito

Una declaración del propósito describe la finalidad del área de
proceso y es un componente informativo.
Por ejemplo, la declaración del propósito del área de
proceso Definición de Procesos de la Organización es “El
propósito de la Definición de Procesos de la Organización
(OPD) es establecer y mantener un conjunto utilizable de
activos de procesos de la orga- nización, estándares del entorno
de trabajo, y reglas y guías para los equipos”.
notas introductorias
La sección de notas introductorias del área de proceso describe
los conceptos principales cubiertos por el área de proceso y es un
componente informativo.
Un ejemplo de notas introductorias del área de proceso
Monito- rización y Control del Proyecto es “Cuando el estado
real se desvía significativamente de los valores esperados, se
llevarán a cabo acciones correctivas según proceda”.
áreas de proceso relacionadas

La sección de áreas de proceso relacionadas enumera las
referencias a áreas de proceso relacionadas y refleja las relaciones
de alto nivel entre las áreas de proceso. La sección de áreas de
proceso relacionadas es un componente informativo.
Un ejemplo de una referencia encontrada en la sección de áreas
de proceso relacionadas del área de proceso Planificación del
Proyecto es “Para más información sobre cómo identificar, analizar
y mitigar los riesgos, consúltese el área de proceso Gestión de
Riesgos”.
metas específicas
Una meta específica describe las características únicas que deben
estar presentes para satisfacer el área de proceso. Una meta
específica es un
componente requerido del modelo y se utiliza en las evaluaciones
para ayudar a determinar si se satisface un área de proceso (véase
la defini- ción de “meta específica” en el glosario).
Por ejemplo, una meta específica del área de proceso Gestión de
Configuración es “Se establece y mantiene la integridad de las líneas
base”.
Sólo la declaración de la meta específica es un componente
requerido del modelo. El título de una meta especifica
(precedido por el número de la meta) y las notas asociadas con la
meta se consideran componentes informativos del modelo.
metas genéricas
Las metas genéricas se denominan “genéricas” porque la misma de-
claración de la meta se aplica a múltiples áreas de proceso. Una
meta genérica describe las características que deben estar presentes
para institucionalizar los procesos que implementan un área de
proceso. Una meta genérica es un componente requerido del modelo
y se utiliza en las evaluaciones para determinar si se satisface un
área de proceso (para una descripción más detallada de las metas
genéricas, consúltese la sección de Metas genéricas y prácticas
genéricas en la Segunda Parte y véase la definición de “meta
genérica” en el glosario).
Un ejemplo de meta genérica es “El proceso está
institucionalizado como un proceso definido”.
Sólo la declaración de la meta genérica es un componente
requerido del modelo. El título de una meta genérica (precedido
por el núme- ro de la meta) y las notas asociadas con la meta, se
consideran componentes informativos del modelo.
resúmenes de metas y prácticas específicas

El resumen de metas y prácticas específicas proporciona un
resumen de alto nivel de las metas específicas y de las prácticas
específicas. El resumen de las metas y prácticas específicas es un
componente informativo.
prácticas específicas
Una práctica específica es la descripción de una actividad que se
considera importante para lograr la meta específica asociada.
Las prácti- cas específicas describen las actividades que se espera
que produzcan el logro de las metas específicas de un área de
proceso. Una práctica específica es un componente esperado del
modelo (véase la defini- ción de “práctica específica” en el
glosario).
Por ejemplo, una práctica específica del área de proceso
Moni- torización y Control del Proyecto es “Monitorizar los
compromisos frente a aquellos identificados en el plan de
proyecto”.
Sólo la declaración de la práctica específica es un componente

esperado del modelo. El título de una práctica específica
(precedido por el número de la práctica) y las notas asociadas con la
práctica específica se consideran componentes informativos del
modelo.
ejemplo de productos de trabajo

La sección de ejemplo de productos de trabajo enumera
resultados de muestra de una práctica específica. Un ejemplo de
producto de trabajo es un componente informativo del modelo
(véase definición de “ejemplo de producto de trabajo” en el
glosario).
Así, un ejemplo de producto de trabajo para la práctica
específica “Monitorizar los parámetros de Planificación del
Proyecto” en el área de proceso Monitorización y Control del
Proyecto es “Registros de las desviaciones significativas”.
subprácticas
Una subpráctica es una descripción detallada que proporciona
orientación para interpretar e implementar una práctica
específica o genérica. Las subprácticas pueden estar redactadas
como si fueran preceptivas, pero realmente son un
componente informativo indicado sólo para proporcionar ideas
que puedan ser útiles para la mejora de procesos (véase la
definición de “subpráctica” en el glosario).
Por ejemplo, una subpráctica para la práctica específica
“Llevar a cabo acciones correctivas” en el área de proceso
Monitorización y Control del Proyecto es “Determinar y
documentar las acciones apropiadas necesarias para tratar las
cuestiones identificadas”.
prácticas genéricas
Las prácticas genéricas se denominan “genéricas” porque la misma
práctica se aplica a múltiples áreas de proceso. Las prácticas genéri-
cas asociadas con una meta genérica describen las actividades que se
consideran importantes para lograr la meta genérica y contribuir a la
institucionalización de los procesos asociados con un área de
proceso. Una práctica genérica es un componente esperado del
modelo (véase la definición de “práctica genérica” en el glosario).
Por ejemplo, una práctica genérica para la meta genérica
“El proceso está institucionalizado como un proceso
gestionado” es “Proporcionar recursos adecuados para realizar
el proceso, desarrollar los productos de trabajo y proporcionar
los servicios del proceso”.
Sólo la declaración de la práctica genérica es un componente
esperado del modelo. El título de una práctica genérica
(precedido por el número de práctica) y las notas asociadas con
la práctica se consideran componentes informativos del modelo.
elaboraciones de la práctica genérica

Las elaboraciones de la práctica genérica aparecen después de las
prác- ticas genéricas para orientar en la forma en que pueden
aplicarse, de forma única, las prácticas genéricas a las áreas de
proceso. Una ela- boración de práctica genérica es un
componente informativo del modelo (véase la definición de
“elaboración de práctica genérica” en el glosario).
Por ejemplo, una elaboración de práctica genérica de la práctica
gené- rica “Establecer y mantener una política de la organización
para planificar y realizar el proceso” en el área de proceso
Planificación del Proyecto es “Esta política establece las expectativas
de la organización para estimar los parámetros de la
planificación, para definir compromisos internos y externos, y
para desarrollar un plan para gestionar el proyecto”.
extensiones
Las extensiones son componentes del modelo claramente visibles
que contienen información de interés para usuarios particulares.
Una ex- tensión puede ser material informativo, una práctica
específica, una meta específica, o un área de proceso completa
que amplía el alcance de un modelo o enfatiza un aspecto
particular de su uso. No hay extensiones en el modelo CMMI-
DEV.
Componentes informativos de soporte

En muchas partes del modelo, se necesita más información para
describir un concepto. Este material informativo se presenta
como uno de los siguientes componentes:
• Notas.
• Ejemplos.
• Referencias.
notas
Una nota es un texto que puede acompañar casi a cualquier otro
componente del modelo. Puede proporcionar detalles,
antecedentes o análisis razonado. Una nota es un componente
informativo del modelo.
Por ejemplo, una nota que acompaña a la práctica específica
“Im- plementar las propuestas de acción” en el área de proceso
Análisis Causal y Resolución es “ se deberían considerar los
cambios que solamente se demuestre que son de valor para su
implementación general”.
ejemplos
Un ejemplo es un componente que consta de texto y, a menudo, una
lista de elementos, por lo general en un recuadro, que puede
acompañar
a casi cualquier otro componente y proporciona uno o más

ejemplos para clarificar un concepto o una actividad descrita. Un
ejemplo es un componente informativo del modelo.
El siguiente es un ejemplo que acompaña a la subpráctica
“Docu- mentar las no conformidades cuando no puedan
resolverse en el proyecto” bajo la práctica específica “Comunicar
y asegurar la resolución de las no conformidades” en el área de
proceso Aseguramiento de la Calidad del Proceso y del Producto.
algunos ejemplos de formas para resolver las no conformidades dentro del

proyecto son:
• Corregir la no conformidad.
• Cambiar las descripciones de proceso, estándares o procedimientos que
fueron incumplidos.
• Obtener una exención para cubrir la no conformidad.
referencias
Una referencia es un enlace a información adicional o más
detallada en las áreas de proceso relacionadas y puede
acompañar a casi cualquier otro componente del modelo. Una
referencia es un componente informativo del modelo (véase la
definición de “referencia” en el glosario).
Por ejemplo, una referencia que acompaña a la práctica
específica “Componer el proceso definido” en el área de proceso
Gestión Cuan- titativa del Proyecto es “Para más información
sobre cómo establecer los activos de proceso de la organización,
consúltese el área de proceso Definición de Procesos de la
Organización”.
esquema de numeración
Las metas específicas y genéricas se numeran secuencialmente.
Cada meta específica comienza con el prefijo “SG” (p. ej., SG
1). Cada meta genérica comienza con el prefijo “GG” (p. ej., GG
2).
Las prácticas específicas y genéricas también se numeran secuen-
cialmente. Cada práctica específica comienza con el prefijo “SP”,
seguido por un número en la forma “x.y” (p. ej., SP 1.1). La x
es el mismo número que el de la meta a la que pertenece la práctica
espe- cífica. La y es el número de secuencia de la práctica
específica para la meta específica.
Un ejemplo de numeración de práctica específica se
encuentra en el área de proceso Planificación del Proyecto. La
primera práctica específica se numera SP 1.1 y la segunda SP 1.2.
Cada práctica genérica comienza con el prefijo “GP”, seguido
por un número de la forma “x.y” (p. ej., GP 1.1).
La x corresponde al número de la meta genérica. La y es el
número de secuencia de la práctica genérica para la meta
genérica. Por ejemplo, la primera práctica genérica asociada con
GG 2 se numera GP 2.1 y la segunda GP 2.2.
Convenciones tipográficas
Las convenciones tipográficas utilizadas en este modelo se han
diseña- do para permitirle identificar y seleccionar fácilmente los
componentes del modelo, presentándolos en formatos que le
permitan encon- trarlos rápidamente en la página.
Las Figuras 2.2, 2.3 y 2.4 son páginas de ejemplo traídas de
las áreas de proceso de la Segunda Parte; en ellas se muestran los
distintos componentes de las áreas de proceso, etiquetados de
forma que los pueda identificar. Obsérvese que la tipografía de
los componentes es distinta para que pueda identificar fácilmente
cada uno.
Nombre del Área de Proceso

ANÁLISIS DE DECISIONES Y RESOLUCIÓN
Un área de proceso de Soporte en el nivel de madurez 3
Categoría del Área Nivel de Madurez

Propósito de Proceso
El propósito del Análisis de Decisiones y Resolución (DAR) es
analizar las posibles decisiones utilizando un proceso de
evaluación formal que evalúa las alternativas identificadas, frente
a unos criterios establecidos.
Declaración de Propósito
Notas introductorias
El área de proceso Análisis de Decisiones y Resolución implica
establecer guías, para determinar qué cuestiones deberían estar
sujetas a un proceso de evaluación formal y aplicar los procesos de
evaluación formal a estas cuestiones.
Un proceso de evaluación formal es un enfoque estructurado
para evaluar soluciones alternativas frente a criterios establecidos
con el fin de determinar una solución recomendada. Un proceso
de evaluación formal implica las siguientes acciones:
Notas Introductorias
 Establecer los criterios para evaluar alternativas.
 Identificar soluciones alternativas.
 Seleccionar métodos para evaluar alternativas.
 Evaluar soluciones alternativas utilizando los criterios y los
méto- dos establecidos.
 Seleccionar soluciones recomendadas a partir de las
alternativas identificadas en base a los criterios de evaluación.
En este área de proceso se utiliza “soluciones alternativas” o “al-

ternativas” para referirse al concepto de “soluciones alternativas para
tratar cuestiones”.
Un proceso de evaluación formal, reduce la naturaleza
subjetiva de una toma de decisión y proporciona mayor
probabilidad de seleccionar una solución que cumpla las
múltiples demandas de las partes interesadas relevantes.
257
FiGUra 2.2
Página ejemplo de Análisis de Decisiones y Resolución (DAR)
Análisis causal y resolución 239
SG 2 T raTar laS cauSaS de loS reSulTadoS SeleccionadoS Meta Específica

Las causas raíz de los resultados seleccionados se tratan sistemáticamente.
Los proyectos que operan de acuerdo a un proceso bien definido

analizan sistemáticamente dónde son necesarias las mejoras e
implementan cambios del proceso para tratar las causas raíz de
los resultados seleccionados.
sp 2.1 implementaR las pRopuestas de acción Práctica Específica

Implementar las propuestas de acción seleccionadas que se han desarrollado
en el análisis causal.
Las propuestas de acción describen las tareas necesarias para

tratar las causas raíz de los resultados analizados con el fin de, o
bien prevenir o reducir la ocurrencia o recurrencia de resultados
negativos, o bien incorporar los éxitos obtenidos. Se desarrollan
e implementan planes de acción para las propuestas de acción
seleccionadas. Solamente se deberían considerar los cambios
que se demuestre que son de valor para su implementación
general.
Ejemplo de Producto
Ejemplos de productos de TRABAJO de Trabajo
1. Propuestas de acción seleccionadas para su
implementación.
2. Planes de acción.
SUBPRÁCTICAS Ejemplo en un Recuadro

1. Analizar las propuestas de acción y determinar sus
prioridades.
Algunos criterios para priorizar las propuestas de acción son:

• Implicaciones de no tratar el resultado.
• Coste de implementar mejoras de procesos para tratar el resultado.
• Impacto esperado sobre la calidad.
Los modelos de rendimiento de proceso se pueden utilizar para

ayudar a identificar interacciones entre múltiples propuestas de
acción. Subpráctica
2. Seleccionar las propuestas de acción a implementar.
PARA más INFORMACIÓN sobre cómo ANALIZAR posibles decisiones UTILIZAN-
do un proceso de EVALUACIÓN FORMAL que EVALÚE ALTERNATIVAS IDENTIFICADAS
frente A criterios ESTABLECIDOS, consúltese el árEA de proceso Análisis de
Decisiones y Resolución.
Referencia
3. Crear planes de acción para implementar las propuestas de
acción seleccionadas.
FiGUra 2.3
Página ejemplo de Análisis Causal y Resolución (CAR)
asociadas. Las metas genéricas están organizadas en orden

numé- rico, GG 1 a GG 3. Las prácticas genéricas también están
organizadas en orden numérico dentro de la meta genérica a la
que dan soporte.
GG 1 L oGrar Las metas específicas
Las metas específicas del área de proceso están soportadas por el proceso me-
diante la transformación de los productos de trabajo de entrada identificables
en productos de trabajo de salida identificables.
Gp 1.1 RealizaR las pRácticas específicas

Realizar las prácticas específicas del área de proceso para desarrollar produc-
tos de trabajo y proporcionar servicios para lograr las metas específicas del
área de proceso.
El propósito de esta práctica genérica es producir los productos

de trabajo y entregar los servicios que se esperan al realizar (es
decir, ejecutar) el proceso. Estas prácticas se pueden hacer de
manera informal sin seguir una descripción documentada del
proceso o un plan. El rigor con que estas prácticas se realizan
depende de las personas que gestionan y realizan el trabajo, y
puede variar considerablemente.
Meta Genérica
GG 2 i nstitucionaLizar un proceso Gestionado
El proceso está institucionalizado como un proceso gestionado.
Gp 2.1 estableceR una política de la oRganización Práctica Genérica

Establecer y mantener una política de la organización para planificar y realizar
el proceso.
El propósito de esta práctica genérica es definir las expectativas

de la organización en relación con el proceso y hacerlas visibles a
aquellos miembros de la organización que están afectados. En
general, la alta dirección es responsable de establecer y
comunicar las directrices, la orientación y las expectativas para
la organización.
No toda orientación de la alta dirección llevará la etiqueta “po-
lítica”. Lo que se espera de esta práctica genérica es la existencia de
una orientación apropiada de la organización, independientemente
de
cómo sea llamada o sea Elaboración de la
comunicada. Práctica Genérica
ELABORACIÓN de CAR
Esta política establece las expectativas de la organización para
identificar y tratar sistemáticamente el análisis causal de los
resultados seleccionados.
FiGUra 2.4
Página ejemplo de metas genéricas y prácticas genéricas
Capítulo 3
uniendo todo
Ahora que se han presentado los componentes de los modelos CMMI,

es necesario comprender cómo encajan todos juntos para satisfacer
sus necesidades de mejora de procesos. Este capítulo presenta el con-
cepto de niveles y muestra cómo se organizan y se utilizan las áreas de
proceso.
CMMI-DEV no específica que un proyecto u organización
deba seguir un flujo de proceso en particular o que sean
desarrollados un cierto número de productos por día, o que deban
alcanzarse objetivos de rendimiento específicos. El modelo
especifica que un proyecto u organización debería tener procesos
que traten prácticas relacionadas con el desarrollo. Para
determinar si estos procesos están desplegados, un proyecto u
organización busca la correspondencia entre sus procesos y las
áreas de proceso de este modelo.
La correspondencia de procesos con las áreas de proceso
permite a la organización seguir su progreso frente al modelo
CMMI-DEV a medida que actualiza o crea procesos. No espere
que todas las áreas de proceso de CMMI-DEV correspondan una
a una con los procesos de su proyecto u organización.
Comprendiendo los niveles

Los niveles se utilizan en CMMI-DEV para describir un camino
evolutivo recomendado para una organización que quiera
mejorar los procesos que utiliza para desarrollar productos o
servicios. Los niveles pueden también ser el resultado de la
actividad de calificación en las evaluaciones1. Las evaluaciones se
pueden aplicar a organizaciones en- teras o a grupos más
pequeños, tales como un grupo de proyectos o una división.
1. Para más información sobre las evaluaciones, consúltese Appraisal Requirements for
CMMI y Standard CMMI Appraisal Method for Process Improvement Method Definition
Document [SEI 2011a, SEI 2011b].
31
CMMI da soporte a dos caminos de mejora usando niveles.
Un camino permite a las organizaciones mejorar de forma
incremental los procesos que corresponden a un área de proceso
individual (o grupo de áreas de proceso) seleccionada por la
organización. El otro camino permite a las organizaciones
mejorar un conjunto de procesos relacionados tratando, de
forma incremental, conjuntos sucesivos de áreas de proceso.
Estos dos caminos de mejora están asociados con los dos tipos
de niveles: niveles de capacidad y niveles de madurez. Estos niveles
corresponden a las dos aproximaciones de mejora de procesos deno-
minadas “representaciones”. Las dos representaciones se denominan
“continua” y “por etapas.” El uso de la representación continua per-
mite alcanzar “niveles de capacidad”. El uso de la representación
por etapas permite alcanzar “niveles de madurez”.
Para alcanzar un nivel particular, una organización debe
satisfacer todas las metas del área de proceso o del conjunto de
áreas de proceso que son objeto de la mejora independientemente
de si es un nivel de capacidad o de madurez.
Ambas representaciones proporcionan caminos para mejorar
sus procesos con el fin de lograr los objetivos de negocio,
proporcionan el mismo contenido esencial y utilizan los mismos
componentes del modelo.
estructuras de las representaciones continua y por etapas

La Figura 3.1 ilustra las estructuras de las representaciones
continua y por etapas. Las diferencias entre las estructuras son
sutiles pero significativas. La representación por etapas utiliza los
niveles de madurez para caracterizar el estado global de los
procesos de la organización con respecto al modelo como un
todo, mientras que la representación continua utiliza los niveles
de capacidad para caracterizar el estado de los procesos de la
organización con respecto a un área de proceso individual.
Lo que puede sorprenderle cuando compare estas dos
representaciones es su similitud. Ambas tienen muchos
componentes iguales (p. ej., áreas de proceso, metas específicas,
prácticas específicas) y estos componentes tienen la misma
jerarquía y configuración.
Lo que no resulta tan evidente desde la visión de alto nivel de
la Figura 3.1 es que la representación continua se enfoca sobre la
capacidad del área de proceso cuando se mide por niveles de
capacidad y la representación por etapas se enfoca sobre la
madurez global cuando se mide por niveles de madurez. Esta
dimensión (la dimensión de capacidad/madurez) de CMMI se
utiliza para actividades de benchmarking y evaluación, así como
para guiar los esfuerzos de mejora de una organización.
Capítulo 3 Uniendo todo 33
Representación Continua
Áreas de Proceso
Niveles de
Capacidad
Metas Metas
Específicas Genéricas
Prácticas Prácticas
Representación por Etapas
Áreas de Proceso
Niveles de
Madurez
Metas Metas
Prácticas Prácticas
FiGUra 3.1:
estructura de las representaciones continua y por etapas
Los niveles de capacidad se refieren a la consecución de la

mejora de procesos de una organización en áreas de proceso
individuales. Es- tos niveles son un medio para mejorar de forma
incremental los procesos que corresponden a un área de proceso
dada. Los cuatro niveles de capacidad se numeran del 0 al 3.
Los niveles de madurez se refieren a la consecución de la
mejora de procesos de una organización en múltiples áreas de
proceso. Estos niveles son un medio para mejorar los procesos
correspondientes a un conjunto dado de áreas de proceso (es
decir, nivel de madurez). Los cinco niveles de madurez se
numeran del 1 al 5.
La Tabla 3.1 compara los cuatro niveles de capacidad con los
cinco niveles de madurez. Observe que los nombres de dos de los
niveles son los mismos en ambas representaciones (es decir,
Gestionado y De- finido). Las diferencias son que no existe nivel
de madurez 0, no hay niveles de capacidad 4 y 5, y en el nivel 1,
los nombres utilizados en el nivel de capacidad 1 y nivel de
madurez 1 son diferentes.
taBla 3.1. comparación de los niveles de capacidad y de madurez
Representación continua Representación por etapas

Nivel Niveles de capacidad Niveles de madurez
Nivel 0 incompleto
Nivel 1 realizado inicial
Nivel 2 Gestionado Gestionado
Nivel 3 definido definido
Nivel 4 Gestionado cuantitativamente
Nivel 5 en optimización
La representación continua se ocupa de seleccionar tanto un

área de proceso particular a mejorar como el nivel de capacidad
deseado para ese área de proceso. En este contexto, es importante
conocer si un proceso se ha realizado o está incompleto. Por lo
tanto, al pun- to de partida de la representación continua se le da
el nombre de “Incompleto”.
La representación por etapas se ocupa de seleccionar múltiples
áreas de proceso a mejorar dentro de un nivel de madurez; no es su
interés principal que los procesos individuales se realicen o estén in-
completos. Por lo tanto, al punto de partida de la representación por
etapas se le da el nombre de “Inicial”.
Tanto los niveles de capacidad como los niveles de madurez
proporcionan una forma de mejorar los procesos de una
organización y de medir como de bien las organizaciones pueden
y realmente mejoran sus procesos. Sin embargo, el enfoque
asociado a la mejora de procesos es diferente.
Comprendiendo los niveles de capacidad

Para dar soporte a aquellos que utilizan la representación
continua, todos los modelos CMMI reflejan niveles de capacidad
en su diseño y contenido.
Los cuatro niveles de capacidad, cada uno es una capa base
para la mejora de procesos en curso, se denominan por los
números del 0 al 3:
0. Incompleto.
1. Realizado.
2. Gestionado.
3. Definido.
Se alcanza un nivel de capacidad para un área de proceso
cuando se satisfacen todas las metas genéricas hasta ese nivel.
El hecho que los niveles de capacidad 2 y 3 usen los mismos
términos que
las metas genéricas 2 y 3 es intencionado porque cada una de
estas metas genéricas y prácticas genéricas refleja el significado
de los niveles de capacidad de las metas y prácticas (para más
información sobre las metas genéricas y prácticas genéricas,
véase la sección Me- tas Genéricas y Prácticas Genéricas en la
Segunda Parte). A continua- ción se presenta una breve
descripción de cada uno de los niveles de capacidad.
nivel de capacidad 0: incompleto

Un proceso incompleto es un proceso que, o bien no se realiza, o
se realiza parcialmente. Al menos una de las metas específicas del
área de proceso no se satisface y no existen metas genéricas para
este nivel, ya que no hay ninguna razón para institucionalizar un
proceso realizado parcialmente.
nivel de capacidad 1: Realizado

Un proceso de nivel de capacidad 1 se caracteriza como un proceso
rEA- LIZADO. Un proceso realizado es un proceso que lleva a cabo el
trabajo necesario para producir productos de trabajo. Se
satisfacen las metas específicas del área de proceso.
Aunque el nivel de capacidad 1 da como resultado mejoras
importantes, esas mejoras pueden perderse con el tiempo si no
se ins- titucionalizan. La aplicación de la institucionalización (las
prácticas genéricas de CMMI en los niveles de capacidad 2 y 3)
ayuda a asegurar que las mejoras se mantienen.
nivel de capacidad 2: Gestionado

Un proceso de nivel de capacidad 2 se caracteriza como un
proceso gestionAdo. Un proceso gestionado es un proceso
realizado que se planifica y ejecuta de acuerdo con la política;
emplea personal cualificado que tiene los recursos adecuados
para producir resultados controlados; involucra a las partes
interesadas relevantes; se monitoriza, controla y revisa; y se
evalúa la adherencia frente a la descrip- ción de su proceso.
La disciplina de proceso reflejada por el nivel de capacidad 2
ayuda a asegurar que las prácticas existentes se mantienen en
periodos de mayor presión.
nivel de capacidad 3: definido

Un proceso de nivel de capacidad 3 se caracteriza como un proceso
definido. Un proceso definido es un proceso gestionado que se
adapta a partir del conjunto de procesos estándar de la organización
de acuerdo a las guías de adaptación de la organización; tiene una
descripción de proceso que se mantiene y que contribuye a los
activos de proceso de la organización con experiencias relativas a
procesos.
Una diferencia crítica entre los niveles de capacidad 2 y 3 es
el alcance de los estándares, descripciones de proceso y
procedimientos. En el nivel de capacidad 2, los estándares,
descripciones de procesos y procedimientos pueden ser bastante
diferentes en cada instancia es- pecífica del proceso (p. ej., en
cada proyecto particular). En el nivel de capacidad 3, los
estándares, descripciones de procesos y procedimientos para un
proyecto se adaptan a partir del conjunto de procesos estándar de
la organización para ajustarse a un proyecto o unidad or-
ganizativa particulares y son, por tanto, más consistentes, excepto
por las diferencias permitidas por las guías de adaptación.
Otra diferencia critica es que en el nivel de capacidad 3, los proce-
sos se describen normalmente de forma más rigurosa que en el
nivel de capacidad 2. Un proceso definido establece claramente el
propósito, entradas, criterios de entrada, actividades, roles,
medidas, etapas de verificación, salidas y criterios de salida. En
el nivel de capacidad 3, los procesos se gestionan de forma más
proactiva a través de la com- prensión de las interrelaciones de
las actividades del proceso y de las medidas detalladas del
proceso y de sus productos de trabajo.
avanzando a través de los niveles de capacidad

Los niveles de capacidad de un área de proceso se logran
mediante la aplicación de las prácticas genéricas o alternativas
adecuadas a los procesos asociados con ese área de proceso.
Alcanzar el nivel de capacidad 1 para un área de proceso es
equivalente a decir que los procesos asociados con ese área de
proceso son procesos rEALIZADOS.
equivalente a decir que existe una política que indica que se
realizará el proceso. Existe un plan para realizarlo, se
proporcionan los recursos, se asignan las responsabilidades, se
proporciona la formación para realizarlo, se controlan los
productos de trabajo seleccionados relativos a la ejecución del
proceso, y así sucesivamente. En otras palabras, un proceso de
nivel de capacidad 2 puede planificarse y monitorizarse de la
misma forma que cualquier proyecto o actividad de soporte.
equivalente a decir que existe un proceso estándar de la
organización asociado con ese área de proceso, que se puede
adaptar a las necesidades del proyecto. Los procesos en la
organización se definen y aplican ahora de forma más consistente
porque se basan en los procesos estándar de la organización.
Una vez que una organización ha logrado el nivel de
capacidad 3 en las áreas de proceso que ha seleccionado para
mejorar, puede continuar su camino de mejora abordando las
áreas de proceso de alta madurez (Rendimiento de Procesos de la
Organización, Gestión Cuantitativa del Proyecto, Análisis Causal
y Resolución, y Gestión del Rendimiento de la Organización).
Las áreas de proceso de alta madurez se concentran en
mejorar el rendimiento de procesos ya implementados. Las áreas
de proceso de alta madurez describen el uso de la estadística y
de otras técnicas cuantitativas para mejorar los procesos de los
proyectos y de la or- ganización para conseguir mejor los
objetivos del negocio.
Cuando se continúa el camino de la mejora de esta forma, una
organización puede obtener mayor beneficio seleccionando, en
primer lugar, las áreas de proceso OPP y QPM, y llevando esas
áreas de proceso a los niveles de capacidad 1, 2 y 3. Haciendo
esto, los proyectos y las organizaciones alinean la selección y el
análisis de procesos de forma más próxima a sus objetivos de
negocio.
Después de alcanzar el nivel de capacidad 3 en las áreas de
proceso de OPP y de QPM, la organización puede continuar su
camino de mejora seleccionando las áreas de proceso CAR y
OPM. Haciendo esto, la organización analiza el rendimiento
del negocio utilizando la estadística y otras técnicas
cuantitativas para determinar deficiencias de rendimiento, e
identifica y despliega mejoras de procesos y de tecnologías que
contribuyan a cumplir los objetivos de rendimiento de
proceso y de calidad. Los proyectos y la organización utilizan
el análisis causal para identificar y resolver las cuestiones que
afectan al rendimiento y promover la difusión de las buenas
prácticas.
aplicando principios empíricos
Por Víctor R. BASILI, KATHLEEN C. DANGLE

y Michele A. SHAW
Comprendiendo los niveles de madurez

Para dar soporte a aquellos que utilizan la representación por
etapas, todos los modelos CMMI reflejan niveles de madurez en
su diseño y contenido. Un nivel de madurez consta de prácticas
específicas y ge- néricas relacionadas para un conjunto
predefinido de áreas de proceso que mejoran el rendimiento
global de la organización.
El nivel de madurez de una organización proporciona una
forma para caracterizar su rendimiento. La experiencia ha
mostrado que las organizaciones toman una decisión acertada
cuando centran sus esfuerzos de mejora de procesos en un
número manejable de áreas de proceso a la vez y que dichas áreas
requieren refinarse a medida que la organización mejora.
Un nivel de madurez es una plataforma evolutiva definida
para la mejora de procesos de la organización. Cada nivel de
madurez desarrolla un subconjunto importante de procesos de
la organización, preparándola para pasar al siguiente nivel de
madurez. Los niveles de madurez se miden mediante el logro de
las metas específicas y gené- ricas asociadas con cada conjunto
predefinido de áreas de procesos.
Los cinco niveles de madurez, cada uno de ellos una base
para la mejoras de proceso en curso, se denominan por los
números del 1 al 5:
1. Inicial.
2. Gestionado.
3. Definido.
4. Gestionado cuantitativamente.
5. En optimización.
Recuerde que los niveles de madurez 2 y 3 utilizan los
mismos términos que los niveles de capacidad 2 y 3. Esta
consistencia de terminología fue intencionada porque los
conceptos de niveles de madurez y niveles de capacidad son
complementarios. Los niveles de madurez se utilizan para
caracterizar la mejora de la organización relativa a un conjunto
de áreas de proceso y los niveles de capacidad caracterizan la
mejora de la organización relativa a un área de proceso
individual.
nivel de madurez 1: inicial

En el nivel de madurez 1, los procesos son generalmente ad hoc
y caóticos. La organización generalmente no proporciona un
entorno estable para dar soporte a los procesos. El éxito en estas
organizaciones depende de la competencia y la heroicidad del
personal de la orga- nización y no del uso de procesos probados.
A pesar de este caos, las organizaciones de nivel de madurez 1 a
menudo producen productos y servicios que funcionan pero, sin
embargo, exceden con frecuencia el presupuesto y los plazos
planificados.
Las organizaciones de nivel de madurez 1 se caracterizan por
una tendencia a comprometerse en exceso, a abandonar sus
procesos en momentos de crisis y a no ser capaces de repetir sus
éxitos.
nivel de madurez 2: Gestionado

En el nivel de madurez 2, se garantiza que en los proyectos los
procesos se planifican y ejecutan de acuerdo con las políticas;
los proyectos emplean personal cualificado que dispone de
recursos adecuados para producir resultados controlados; se
involucra a las partes interesadas relevantes; se monitorizan,
controlan y revisan; y se evalúan en cuanto a la adherencia a sus
descripciones de proceso. La disciplina de proceso reflejada por
el nivel de madurez 2 ayuda a asegurar que las prác- ticas
existentes se mantienen durante periodos bajo presión. Cuando
estas prácticas están desplegadas, los proyectos se realizan y
gestionan de acuerdo a sus planes documentados.
También en el nivel de madurez 2, el estado de los productos de
trabajo es visible para la dirección en puntos definidos (p. ej., en
los hitos principales y al finalizar las tareas principales). Se
establecen compromisos entre las partes interesadas relevantes y
se modifican, según sea necesario. Los productos de trabajo se
controlan de forma apropiada. Los productos de trabajo y
servicios satisfacen sus descripciones de proceso, estándares y
procedimientos especificados.
nivel de madurez 3: definido

En el nivel de madurez 3, los procesos están bien caracterizados
y comprendidos, y se describen en estándares, procedimientos,
herramientas y métodos. El conjunto de procesos estándar de la
organiza- ción, que es la base del nivel de madurez 3, se
establece y se mejora a lo largo del tiempo. Estos procesos
estándar se utilizan para establecer la integridad en toda la
organización. Los proyectos establecen sus procesos definidos
adaptando el conjunto de procesos estándar de la organización de
acuerdo a las guías de adaptación (véase la definición de
“conjunto de procesos estándar de la organización” en el
glosario).
Una diferencia crítica entre los niveles de madurez 2 y 3 es el al-
cance de los estándares, descripciones de proceso y
procedimientos. En el nivel de madurez 2, los estándares,
descripciones de proceso y procedimientos pueden ser bastante
diferentes en cada instancia es- pecífica del proceso (p. ej., en un
proyecto particular). En el nivel de madurez 3, los estándares,
descripciones de proceso y procedimientos para un proyecto se
adaptan a partir del conjunto de procesos estándar de la
organización para adecuarse a un proyecto particular o unidad
organizativa y, por tanto, son más consistentes, exceptuando las
diferencias permitidas por las guías de adaptación.
Otra diferencia crítica es que en el nivel de madurez 3, los
procesos normalmente se describen más rigurosamente que en
el nivel de madurez 2. Un proceso definido establece claramente
el propósito, entradas, criterios de entrada, actividades, roles,
medidas, etapas de verificación, salidas y criterios de salida. En
el nivel de madurez 3, los procesos se gestionan más
proactivamente a través de la com- prensión de las
interrelaciones de las actividades del proceso, de las medidas
detalladas del proceso, de sus productos de trabajo y de sus
servicios.
En el nivel de madurez 3 la organización mejora, aún más,
sus procesos relacionados con las áreas de proceso del nivel de
madurez
2. Para lograr el nivel de madurez 3, se aplican las prácticas
genéricas asociadas con la meta genérica 3 que no fueron tratadas
en el nivel de madurez 2.
nivel de madurez 4: Gestionado cuantitativamente

En el nivel de madurez 4, la organización y los proyectos
establecen objetivos cuantitativos para la calidad y el
rendimiento del proceso, y los utilizan como criterios en la
gestión de los proyectos. Los objetivos cuantitativos se basan en
las necesidades del cliente, usuarios finales, organización e
implementadores del proceso. La calidad y el rendimiento del
proceso se interpretan en términos estadísticos y se gestionan
durante la vida de los proyectos.
Para los subprocesos seleccionados, se recogen y se analizan
esta- dísticamente medidas específicas del proceso. Cuando se
seleccionan
subprocesos para su análisis, es crítico comprender las relaciones

entre diferentes subprocesos y su impacto en la consecución de
los objetivos de calidad y de rendimiento del proceso. Este
enfoque ayuda a asegurar que la monitorización de subprocesos
usando técnicas esta- dísticas y otras técnicas cuantitativas se
aplica donde tiene más valor global para el negocio. Las líneas
base y los modelos de rendimiento del proceso pueden usarse
para ayudar a establecer los objetivos de calidad y de rendimiento
del proceso que ayuden a lograr los objetivos de negocio.
Una diferencia crítica entre los niveles de madurez 3 y 4 es la
pre- dictibilidad del rendimiento del proceso. En el nivel de
madurez 4, el rendimiento de los proyectos y de los subprocesos
seleccionados se controla utilizando técnicas estadísticas y otras
técnicas cuantitativas, y las predicciones se basan, en parte, en el
análisis estadístico de los datos detallados de proceso.
nivel de madurez 5: en optimización

En el nivel de madurez 5, una organización mejora
continuamente sus procesos basándose en una comprensión
cuantitativa de sus objetivos de negocio y necesidades de
rendimiento. La organización utiliza un enfoque cuantitativo
para comprender la variación inherente en el proceso y las
causas de los resultados del proceso.
El nivel de madurez 5 se centra en mejorar continuamente el
rendimiento de los procesos mediante mejoras incrementales e
innovadoras de proceso y de tecnología. Los objetivos de
calidad y de rendimiento del proceso de la organización se
establecen, se modifican continuamente para reflejar cambios
en los objetivos del negocio y en el rendimiento de la
organización, y se utilizan como criterios para gestionar la
mejora de procesos. Los efectos de las mejoras de procesos
desplegadas se miden utilizando técnicas estadísticas y otras
técnicas cuantitativas, y se comparan con los objetivos de
calidad y de rendimiento del proceso. Los procesos definidos
del proyecto, el conjunto de procesos estándar de la or-
ganización y la tecnología de soporte, son objeto de actividades
de mejora medibles.
Una diferencia crítica entre los niveles de madurez 4 y 5 es el
enfoque de gestión y mejora del rendimiento de la
organización. En el nivel de madurez 4, la organización y los
proyectos se en- focan en interpretar y controlar el
rendimiento a nivel de subprocesos y en utilizar los resultados
para gestionar proyectos. En el nivel de madurez 5, la
organización se preocupa por el rendimiento global de la
organización usando los datos recogidos de múltiples
proyectos. El análisis de los datos identifica deficiencias o
lagunas en el rendimiento. Esas lagunas se utilizan para
orientar la mejora de procesos en la organización que genera
mejoras medibles en el rendimiento.
avanzando a través de los niveles de madurez

Las organizaciones pueden lograr mejoras progresivas en su ma-
durez consiguiendo primero el control a nivel de proyecto y
continuando hasta el nivel más avanzado –gestión de
rendimiento y mejora continua de procesos en toda la
organización– utilizando tanto datos cualitativos como
cuantitativos para la toma de decisiones.
Dado que el aumento de la madurez de la organización se
asocia con la mejora de los resultados esperados que se puede
lograr, la madurez es una forma para predecir resultados de
proyectos futuros de la organización. Por ejemplo, en el nivel
de madurez 2, la organización ha pasado de una forma de trabajo
ad hoc a una forma de trabajo disciplinada, estableciendo una
gestión de proyectos adecuada. A medida que la organización
logra las metas genéricas y específicas para el conjunto de áreas
de proceso en un nivel de madurez, aumenta su madurez
organizativa y obtiene los beneficios de la mejora de procesos.
Dado que cada nivel de madurez establece la base necesaria para
el siguiente nivel, generalmente es contrapro- ducente tratar de
saltarse niveles de madurez.
Al mismo tiempo, hay que observar que el esfuerzo de mejora
de procesos debería enfocarse en las necesidades de la organiza-
ción en el contexto de su negocio y que las áreas de proceso en
los niveles de madurez más altos puedan dirigirse a las
necesidades actuales y futuras de una organización o proyecto.
Por ejemplo, en las organizaciones que buscan avanzar
desde el nivel de madurez 1 al 2, frecuentemente se fomenta la
consti- tución de un grupo de procesos, que se trata en el área de
proceso Enfoque en Procesos de la Organización en el nivel de
madurez 3. Aunque un grupo de procesos no es una
característica necesaria de una organización de nivel 2, puede
ser útil para lograr el nivel de madurez 2.
Algunas veces esta situación se caracteriza como el
establecimiento de un grupo de procesos de nivel de madurez
1 para pasar la organización del nivel de madurez 1 al nivel de
madurez 2. Las actividades de mejora de procesos del nivel de
madurez 1 pueden depender sobre todo de la competencia de
los componentes del grupo de procesos, hasta que se establezca
una infraestructura que dé soporte a una mejora más
disciplinada y extendida.
Las organizaciones pueden establecer mejoras de proceso en
cualquier momento, incluso antes de que estén preparadas para
avanzar al nivel de madurez donde se recomiende la práctica
espe- cífica. Sin embargo, en tales situaciones, las organizaciones
debe- rían comprender que el éxito de estas mejoras está en
riesgo porque no se ha finalizado la base para su
institucionalización adecuada. Los procesos sin la base apropiada
pueden fallar en el momento en que más se necesiten –bajo
presión.
Un proceso definido que es característico de una organización

de nivel de madurez 3, puede estar en situación de riesgo si las
prácti- cas de gestión del nivel de madurez 2 son deficientes. Por
ejemplo, la gerencia podría comprometerse con un calendario mal
planificado o fracasar al controlar los cambios a los requisitos de
la línea base. De igual forma, muchas organizaciones recopilan
prematuramente los datos detallados característicos del nivel de
madurez 4 y se dan cuenta que los datos no son interpretables
debido a inconsistencias en los procesos y en las definiciones de
las mediciones.
Otro ejemplo del uso de procesos asociados con áreas de
proceso de nivel de madurez más alto, está en la construcción de
productos. Desde luego, podríamos esperar que organizaciones de
nivel de madurez 1 realicen análisis de requisitos, diseño,
integración del producto y verificación. Sin embargo, estas
actividades no están descritas hasta el nivel de madurez 3, donde
están definidas como procesos de ingenie- ría coherentes y bien
integrados. Los procesos de ingeniería del nivel de madurez 3
complementan la capacidad de gestión de proyectos desplegada,
de forma que no se malgasten las mejoras de ingeniería por el uso
de un proceso de gestión ad hoc.
Áreas de proceso
Las áreas de proceso se ven de forma diferente en las dos
representaciones. La Figura 3.2 compara los puntos de vista de
cómo se usan las áreas de proceso en la representación continua y
en la representación por etapas.
La representación continua permite a la organización elegir el
enfoque de sus esfuerzos de mejora de procesos, eligiendo
aquellas áreas de proceso, o conjuntos de áreas de proceso
interrelacionados, que más benefician a la organización y a sus
objetivos de negocio. Aunque existen algunos límites sobre lo
que una organización puede elegir debido a las dependencias
entre áreas de proceso, la organización tiene una libertad
considerable en su selección.
Para dar soporte a aquellos que utilizan la representación
continua, las áreas de procesos se organizan en cuatro
categorías: Gestión de Procesos, Gestión de Proyectos, Ingeniería
y Soporte. Estas catego- rías hacen hincapié en algunas de las
relaciones clave que existen entre las áreas de proceso.
Algunas veces, se menciona una agrupación informal de áreas
de proceso: áreas de proceso de alta madurez. Las cuatro áreas de
proceso de alta madurez son: Rendimiento de Procesos de la
Organi- zación, Gestión Cuantitativa del Proyecto, Gestión del
Rendimiento de la Organización, y Análisis Causal y Resolución.
Estas áreas de proceso se centran en mejorar el rendimiento de
los procesos implementados que están más relacionadas con los
objetivos de negocio de la organización.
Representación Continua
Perfil objetivo
Áreas de Proceso seleccionadas
Niveles de Capacidad objetivo
Representación por Etapas

Nivel de Madurez seleccionado
FiGUra 3.2
Áreas de proceso en las representaciones continua y por etapas
Una vez seleccionadas las áreas de proceso, debería

seleccionar cuánto le gustaría madurar los procesos asociados
con dichas áreas de proceso (es decir, seleccionar el nivel de
capacidad apropiado). Los niveles de capacidad, y las metas y
prácticas genéricas, dan soporte a la mejora de los procesos
asociados con las áreas de proceso individuales. Por ejemplo,
una organización puede desear alcanzar el nivel de capacidad 2
en un área de proceso y el nivel de capacidad 3 en otra. A
medida que la organización alcanza un nivel de capacidad,
establece su visión para el siguiente nivel de capacidad para
una de estas mismas áreas de proceso o decide extender su
visión y tratar un número mayor de áreas de proceso. Una vez
que alcanza el nivel de capacidad 3 en la mayoría de las áreas
de proceso, la organización puede centrar su atención en las
áreas de proceso de alta madurez y puede seguir la capacidad de
cada una a través del nivel de capacidad 3.
La selección de una combinación de áreas de proceso y
niveles de capacidad se describe normalmente mediante un “perfil
objetivo”. Un perfil objetivo define todas las áreas de proceso a
contemplar y el nivel de capacidad objetivo para cada una. Este
perfil gobierna qué metas y prácticas abordará la organización en
sus esfuerzos de mejora de procesos.
La mayoría de las organizaciones determinan nivel de
capacidad 1, como mínimo, para las áreas de proceso que
seleccionen, lo que requiere que todas las metas específicas de
esas áreas de proceso sean logradas. Sin embargo, las
organizaciones que apuntan a niveles de capacidad más altos que
el 1, se concentran en la institucionalización de los procesos
seleccionados en la organización implementando las metas y
prácticas genéricas.
La representación por etapas proporciona un camino de
mejora desde el nivel de madurez 1 al nivel de madurez 5 que
implica alcanzar las metas de las áreas de proceso en cada nivel
de madurez. Para dar soporte a quienes utilizan la representación
por etapas, las áreas de proceso se agrupan por niveles de
madurez, indicando que áreas de proceso se deben implementar
para alcanzar cada nivel de madurez.
Por ejemplo, en el nivel de madurez 2, existe un conjunto de
áreas de proceso que una organización debería utilizar para
orientar la mejora de procesos hasta conseguir todas las metas
de todas estas áreas de proceso. Una vez que se ha logrado el
nivel de madurez 2, la or- ganización centrará sus esfuerzos en
las áreas de proceso de nivel de madurez 3 y así sucesivamente.
Las metas genéricas que se aplican a cada área de proceso
también están predeterminadas. La meta genérica 2 se aplica al
nivel de madurez 2 y la meta genérica 3 se aplica a los niveles de
madurez del 3 al 5.
La Tabla 3.2 proporciona una lista de las áreas de proceso de
CM- MI-DEV y de sus categorías y niveles de madurez asociados.
taBla 3.2. Áreas de proceso, categorías y niveles de madurez
Nivel de
Área de Proceso Categoría Madurez
análisis causal y resolución (car) soporte 5
Gestión de configuración (cm) soporte 2
análisis de decisiones y resolución (dar) soporte 3
Gestión integrada del Proyecto (iPm) Gestión de proyectos 3
medición y análisis (ma) soporte 2
definición de Procesos de la organización (oPd) Gestión de procesos 3
enfoque en Procesos de la organización (oPF) Gestión de procesos 3
Gestión del rendimiento de la organización (oPm) Gestión de procesos 5
rendimiento de Procesos de la organización (oPP) Gestión de procesos 4
Formación en la organización (ot) Gestión de procesos 3
integración del Producto (Pi) ingeniería 3
monitorización y control del Proyecto (Pmc) Gestión de proyectos 2
Planificación del Proyecto (PP) Gestión de proyectos 2
aseguramiento de la calidad del Proceso y
soporte 2
del Producto (PPQa)
Gestión cuantitativa del Proyecto (QPm) Gestión de proyectos 4
desarrollo de requisitos (rd) ingeniería 3
Gestión de requisitos (reQm) Gestión de proyectos 2
Gestión de riesgos (rsKm) Gestión de proyectos 3
Gestión de acuerdos con Proveedores (sam) Gestión de proyectos 2
solución técnica (ts) ingeniería 3
Validación (Val) ingeniería 3
Verificación (Ver) ingeniería 3
Representación equivalente
La representación equivalente es una forma de comparar
resultados de la representación continua con resultados de la
representación por etapas. En esencia, si mide la mejora relativa a
las áreas de proceso seleccionadas usando niveles de capacidad en
la representación continua, ¿cómo se compara con los de niveles de
madurez?, ¿es posible la comparación?
Hasta este momento, no se han tratado las evaluaciones de
proceso con mucho detalle. El método SCAMPISM2se utiliza
para evaluar a
2. El método Standard CMMI Appraisal Method for Process Improvement (SCAMPI) se

describe en el Capítulo 5.
las organizaciones que usan CMMI y un resultado de una

evaluación es una calificación [SEI 2011a, Ahern 2005]. Si se
utiliza la represen- tación continua para una evaluación, la
calificación es “un perfil de nivel de capacidad”. Si se utiliza, la
representación por etapas para una evaluación, la calificación es una
“calificación de nivel de madurez” (p. ej., nivel de madurez 3).
Un perfil de nivel de capacidad es una lista de áreas de
proceso y el correspondiente nivel de capacidad logrado para
cada una. Este perfil permite a una organización seguir su nivel
de capacidad por área de proceso. El perfil se denomina “perfil
alcanzado” cuando representa el progreso real de la
organización en cada área de proceso. De forma alternativa, el
perfil se denomina “perfil objetivo” cuando representa los
objetivos de mejora de los procesos planificados de la
organización.
La Figura 3.3 ilustra una combinación del perfil objetivo y
del alcanzado. La zona sombreada de cada barra representa el
nivel alcanzado. La zona no sombreada representa aquello que
queda por conseguir para cumplir el perfil objetivo.
FiGUra 3.3
ejemplo combinado de perfil alcanzado y perfil objetivo
Un perfil alcanzado, cuando se compara con un perfil
objetivo, permite a una organización planificar y seguir su
progreso en cada área de proceso seleccionada. Cuando se utiliza
la representación continua, es aconsejable mantener los perfiles
de niveles de capacidad.
La representación por objetivos es una secuencia de perfiles
objetivo que describe el camino de mejora de procesos a seguir
por la orga- nización. Cuando se construyen perfiles objetivo, la
organización de- bería prestar atención a las dependencias entre
las prácticas genéricas y las áreas de proceso. Si una práctica
genérica depende de un área de proceso, bien para llevar a cabo la
práctica genérica o para proporcionar un producto de trabajo
requerido, la práctica genérica puede ser mucho menos eficaz
cuando el área de proceso no está implementada3. Aunque las
razones para utilizar la representación continua son muchas, las
calificaciones que consisten en perfiles de nivel de capacidad
están limitadas en su habilidad de proporcionar a las or-
ganizaciones un modo de compararse de forma general con
otras organizaciones. Los perfiles de nivel de capacidad pueden
utilizarse si cada organización selecciona las mismas áreas de
proceso; sin embargo, los niveles de madurez han sido
utilizados durante años para comparar organizaciones y ya
proporcionan conjuntos predefinidos
de áreas de proceso.
Debido a esta situación, se creó la representación equivalente.
La representación equivalente permite a una organización que
utiliza la representación continua, convertir un perfil de nivel de
capacidad a la calificación del nivel de madurez asociado.
La forma más eficaz de representar la representación
equivalente es proporcionar una secuencia de perfiles objetivo,
cada uno de los cuales es equivalente a una calificación de nivel
de madurez de la repre- sentación por etapas reflejada en las áreas
de proceso enumeradas en el perfil objetivo. El resultado es una
representación por objetivos que es equivalente a los niveles de
madurez de la representación por etapas.
La Figura 3.4 muestra un resumen de los perfiles objetivo que
se deben lograr cuando se utiliza la representación continua para
ser equivalentes a los niveles de madurez del 2 al 5. Cada área
sombreada en las columnas de nivel de capacidad representa un
perfil objetivo que es equivalente a un nivel de madurez.
Las reglas siguientes resumen la representación equivalente:
• Para lograr el nivel de madurez 2, todas las áreas de
proceso asignadas al nivel de madurez 2 deben lograr el
nivel de capacidad 2 o 3.
• Para lograr el nivel de madurez 3, todas las áreas de
proceso asignadas a los niveles de madurez 2 y 3 deben
lograr el nivel de capacidad 3.
3. Para más información sobre las dependencias entre las prácticas genéricas y las áreas de
proceso, véase la Tabla 6.2 en la sección de Metas Genéricas y Prácticas Genéricas de la
Segunda Parte.
Nombre Abrev. ML CL1 CL2 CL3
Gestión de Configuración CM 2
Medición y Análisis MA 2
Monitorización y Control del Proyecto PMC 2
Planificación del Proyecto PP 2 Perfil
Objetivo 2
Aseguramiento de la Calidad del Proceso y
PPQA 2
del Producto
Gestión de Requisitos REQM 2
Gestión de Acuerdos con Proveedores SAM 2
Análisis de Decisiones y Resolución DAR 3
Gestión Integrada del Proyecto IPM 3
Definición de Procesos de la Organización OPD 3
Enfoque en Procesos de la Organización OPF 3
Formación en la Organización OT 3
Perfil
Integración del Producto PI 3
Objetivo 3
Desarrollo de Requisitos RD 3
Gestión de Riesgos RSKM 3
Solución Técnica TS 3
Validación VAL 3
Verificación VER 3
Rendimiento de Procesos de la Organización OPP 4 Perfil
Gestión Cuantitativa del Proyecto QPM 4 Objetivo 4
Análisis Causal y Resolución CAR 5 Perfil

Gestión del Rendimiento de la Organización OPM 5 Objetivo 5
FiGUra 3.4
Perfiles objetivo y representación equivalente
• Para lograr el nivel de madurez 4, todas las áreas de proceso

asignadas a los niveles de madurez 2, 3 y 4 deben lograr el
nivel de capacidad 3.
• Para lograr el nivel de madurez 5, todas las áreas de proceso
deben lograr el nivel de capacidad 3.
alcanzando alta madurez

Cuando se utiliza la representación por etapas, se alcanza alta
madurez cuando se logra el nivel de madurez 4 ó 5. Lograr el nivel
de madurez 4 implica implementar todas las áreas de proceso para
los niveles de madurez 2, 3 y 4. Del mismo modo, lograr el nivel
de madurez 5, implica implementar todas las áreas de proceso
para los niveles de madurez 2, 3, 4 y 5.
Cuando se utiliza la representación continua, se alcanza alta
madurez utilizando el concepto de representación equivalente.
Alta madurez, que es equivalente a nivel de madurez 4 por
etapas utilizando la representación equivalente, se alcanza
cuando se logra el nivel de capacidad 3 para todas las áreas de
proceso excepto para Gestión del Rendimiento de la
Organización (OPM), y Análisis Causal y Resolu- ción (CAR).
La alta madurez, que es equivalente al nivel de madurez 5
utilizando la representación equivalente, se alcanza cuando se
logra el nivel de capacidad 3 en todas las áreas de proceso.
utilizando líneas base de rendimiento del proceso y modelos de

rendimiento del proceso para facilitar el éxito
por MICHAEL CAMPO, NEAL MACKERTICH y Peter KRAUS

Capítulo 4
relaCiones entre áreas de proCeso
En este capítulo, se describen las relaciones clave que hay entre

las áreas de proceso para ayudarle a comprender la mejora de
procesos desde el punto de vista de la organización y como unas
áreas de proceso dependen de la implementación de otras áreas de
proceso. Las relaciones entre múltiples áreas de proceso,
incluyendo la in- formación y los artefactos que fluyen de un área
de proceso a otra
–mostradas por las descripciones y figuras de este capítulo– le
ayuda- rán a tener una visión más amplia de la mejora e
implementación de procesos.
Las iniciativas de mejora de procesos de éxito deben estar im-
pulsadas por los objetivos de negocio de la organización. Por
ejemplo, un objetivo de negocio habitual es reducir el tiempo
necesario para lanzar un producto al mercado. El objetivo de
mejora de procesos derivado de dicho objetivo de negocio
podría ser mejorar los procesos de gestión del proyecto para
asegurar la entrega a tiempo; esas mejoras se apoyan en las
mejores prácticas dentro de las áreas de proceso Planificación del
Proyecto, y Monitorización y Control del Proyecto.
Aunque en este capítulo se agrupan ciertas áreas de proceso
para simplificar el debate de sus relaciones, a menudo las áreas
de proceso interactúan y afectan a otras independientemente de
su grupo, categoría o nivel. Por ejemplo, el área de proceso
Análisis de Decisiones y Resolución (un área de proceso de
Soporte en el nivel de madurez 3) contiene prácticas específicas
que abordan el proceso de evaluación formal usado en el área de
proceso Solución Técnica para seleccionar una solución técnica
entre varias soluciones alternativas.
Conocer las relaciones clave que existen entre las áreas de
proceso de CMMI, le ayudará a aplicar CMMI de un modo útil y
productivo. Las relaciones entre las áreas de proceso se describen
con mayor detalle en las referencias de cada área de proceso y
específicamente en la sección de Áreas de Proceso Relacionadas
de cada área de proceso en la Segunda Parte de este libro.
Consúltese el Capítulo 2 para más información sobre las
referencias.
59
Gestión de procesos
Las áreas de proceso de Gestión de Procesos contienen las
actividades transversales a los proyectos relativas a la definición,
planificación, despliegue, implementación, monitorización,
control, evaluación, me- dición y mejora de procesos.
Las cinco áreas de proceso de Gestión de Procesos de CMMI-
DEV son las siguientes:
• Definición de Procesos de la Organización (OPD).

• Enfoque en Procesos de la Organización (OPF).
• Gestión del Rendimiento de la Organización (OPM).
• Rendimiento de Procesos de la Organización (OPP).
• Formación en la Organización (OT).
áreas de proceso básicas de Gestión de procesos

Las áreas de proceso básicas de Gestión de Procesos
proporcionan a la organización la capacidad para documentar y
compartir las buenas prácticas, los activos de proceso de la
organización y el aprendizaje en toda la organización.
La Figura 4.1 proporciona una visión general de las
interacciones entre las áreas de proceso básicas de Gestión de
Procesos y con otras categorías de áreas de proceso. Como se
ilustra en la Figura 4.1, el área de proceso Enfoque en Procesos
de la Organización ayuda a la organización a planificar,
implementar y desplegar las mejoras de procesos de la
organización basadas en una comprensión de las fortalezas y
debilidades actuales de los procesos y de los activos de proceso de
la organización.
Las mejoras candidatas para los procesos de la organización
se obtienen de varias fuentes. Estas actividades incluyen
propuestas de mejora de procesos, medición de los mismos,
lecciones aprendidas de la implementación y resultados de las
actividades de evaluación del proceso y de la evaluación del
producto.
El área de proceso Definición de Procesos de la Organización
establece y mantiene el conjunto de procesos estándar de la
organización, los estándares del entorno de trabajo y otros activos
basados en las necesidades del proceso y en los objetivos de la
organización. Estos otros activos incluyen descripciones de los
modelos de ciclo de vida, guías de adaptación del proceso, y
documentación y datos relacionados con el proceso.
Los proyectos adaptan el conjunto de procesos estándar de la
or- ganización para crear sus procesos definidos. Los otros
activos dan soporte a la adaptación, así como a la implementación
de los procesos definidos.
Las experiencias y los productos de trabajo fruto de la
realiza- ción de estos procesos definidos, incluyendo los datos de
medición,
61
FiGUra 4.1
Áreas de proceso básicas de Gestión de Procesos
las descripciones de proceso, los artefactos de proceso y las

lecciones aprendidas, se incorporan según sea apropiado en el
conjunto de procesos estándar y otros activos de la organización.
El área de proceso Formación en la Organización identifica las
necesidades estratégicas de formación en la organización, así
como las necesidades tácticas de formación que son comunes a
los proyectos y a los grupos de soporte. En particular, la
formación se desarrolla u obtiene para desarrollar las
habilidades requeridas para realizar el conjunto de procesos
estándar de la organización. Los componentes principales de la
formación incluyen un programa de desarrollo de formación
gestionado, planes documentados, personal con el conocimiento
apropiado y mecanismos para la medición de la eficacia del
programa de formación.
áreas de proceso avanzadas de Gestión de procesos

Las áreas de proceso avanzadas de Gestión de Procesos
proporcionan a la organización una capacidad mejorada para
lograr sus objetivos cuantitativos de calidad y de rendimiento del
proceso.
interacciones entre las áreas de proceso avanzadas de Gestión de
Procesos y con otras categorías de áreas de proceso. Cada área de
proceso avanzada de Gestión de Procesos depende de la
capacidad para desarrollar y desplegar procesos y activos de
soporte. Las áreas de proceso básicas de Gestión de Procesos
proporcionan esta capacidad.
Como se ilustra en la Figura 4.2, el área de proceso
Rendimiento de Procesos de la Organización infiere objetivos
cuantitativos para la calidad y el rendimiento del proceso a partir
de los objetivos de negocio de la organización. La organización
proporciona a los proyectos y a los grupos de soporte medidas
comunes, líneas base de rendimien- to de procesos y modelos de
rendimiento del proceso.
Estos activos adicionales de la organización dan soporte a la
com- posición de un proceso definido que puede lograr los
objetivos de calidad y de rendimiento del proceso del proyecto, y
dan soporte a la gestión cuantitativa. La organización analiza los
datos de rendimien- to del proceso recogidos a partir de estos
procesos definidos para desarrollar una comprensión
cuantitativa de la calidad del producto, de la calidad del servicio
y del rendimiento de los procesos del conjunto de procesos
estándar de la organización.
En la Gestión del Rendimiento de la Organización, las líneas
base y los modelos de rendimiento de los procesos se analizan
para comprender la capacidad de la organización para cumplir
sus objetivos de negocio e inferir objetivos de calidad y de
rendimiento del proceso. Basada en esta comprensión, la
organización selecciona y despliega proactivamente mejoras
innovadoras e incrementales que mejoran de forma medible el
rendimiento de la organización.
63
FiGUra 4.2
Áreas de proceso avanzadas de Gestión de Procesos
La selección de las mejoras a desplegar se basa en una

compren- sión cuantitativa de los posibles beneficios y de los
costes previstos de las mejoras candidatas a desplegar. La
organización puede ajustar también los objetivos de negocio, y los
objetivos de calidad y de rendimiento del proceso según proceda.
Gestión de proyectos
Las áreas de proceso de Gestión de Proyectos cubren las
actividades de gestión del proyecto relacionadas con la
planificación, monitorización y control del proyecto.
Las siete áreas de proceso de Gestión de Proyectos de CMMI-
DEV son las siguientes:
• Gestión Integrada del Proyecto (IPM).

• Monitorización y Control del Proyecto (PMC).
• Planificación del Proyecto (PP).
• Gestión Cuantitativa del Proyecto (QPM).
• Gestión de Requisitos (REQM).
• Gestión de Riesgos (RSKM).
• Gestión de Acuerdos con Proveedores (SAM).
áreas de proceso básicas de Gestión de proyectos

Las áreas de proceso básicas de Gestión de Proyectos tratan las
actividades relacionadas con el establecimiento y
mantenimiento del plan del proyecto, el establecimiento y
mantenimiento de los compromisos, la monitorización del
progreso frente al plan, la toma de acciones correctivas y la
gestión de acuerdos con proveedores.
interacciones entre las áreas de proceso básicas de Gestión de
Proyectos y con otras categorías de áreas de proceso. Como se
ilustra en la Figura 4.3, el área de proceso Planificación del
Proyecto incluye el desarrollo del plan de proyecto, la
involucración de las partes interesadas relevantes, la obtención
del compromiso con el plan y el mantenimiento del mismo.
La planificación comienza con los requisitos que definen
el producto y el proyecto (“qué construir” en la Figura 4.3). El
plan de proyecto cubre las diferentes actividades de gestión y
desarrollo del proyecto a realizar por el proyecto. El proyecto
revisa otros planes que le afectan y que provienen de las
diversas partes interesadas, y establece los compromisos con
esas partes interesadas en cuanto a sus contribuciones al
proyecto. Por ejemplo, estos planes cubren la gestión de
configuración, la verificación, y la medición y análisis.
65
FiGUra 4.3
Áreas de proceso básicas de Gestión de Proyectos
El área de proceso Monitorización y Control del Proyecto

incluye las prácticas de monitorización y control, y de toma de
acciones correctivas. El plan de proyecto especifica la frecuencia
de las revisiones del progreso y las medidas usadas para
monitorizar el progreso. El progreso se determina
principalmente mediante la comparación del estado del proyecto
con el plan. Cuando el estado real se desvía de forma
significativa de los valores esperados, se toman acciones
correctivas según proceda. Estas acciones pueden incluir re-
planificación, que requerirá usar prácticas de la Planificación del
Proyecto.
El área de procesos Gestión de Requisitos mantiene los
requisitos. Describe las actividades para obtener y controlar los
cambios a los requisitos, y para asegurar que otros planes y datos
relevantes se mantienen actualizados. Proporciona la trazabilidad
de los requisitos desde los requisitos de cliente hasta los requisitos
de producto y de los componentes de producto.
La Gestión de Requisitos asegura que los cambios a los
requisitos se reflejan en los planes, actividades y productos de
trabajo del proyec- to. Este ciclo de cambios puede afectar a las
áreas de proceso de Inge- niería; así, la gestión de requisitos es una
secuencia de eventos dinámi- ca y a menudo recursiva. El área de
proceso Gestión de Requisitos es fundamental para un proceso de
ingeniería controlado y disciplinado. El área de proceso Gestión
de Acuerdos con Proveedores aborda la necesidad del proyecto de
adquirir aquellas partes del trabajo que son realizadas por
proveedores. Las fuentes de productos que se pueden usar para
satisfacer los requisitos del proyecto se identifican de forma
proactiva. Se selecciona al proveedor y se establece un acuerdo
con él
para su gestión.
El progreso y el rendimiento del proveedor se siguen según
está especificado en el acuerdo con el proveedor y éste se
modifica según sea necesario. Las revisiones y pruebas de
aceptación se realizan sobre el componente de producto realizado
por el proveedor.
áreas de proceso avanzadas de Gestión de proyectos

Las áreas de proceso avanzadas de Gestión de Proyectos abordan
actividades tales como establecer un proceso definido que se
adapta a partir del conjunto de procesos estándar de la
organización, establecer el entorno de trabajo del proyecto a
partir de los estándares del entorno de trabajo de la
organización, coordinar y colaborar con las partes interesadas
relevantes, crear y mantener los equipos para la dirección de los
proyectos, gestionar cuantitativamente el proyecto y gestionar los
riesgos.
interacciones entre las áreas de proceso avanzadas de Gestión de
Proyectos y con otras categorías de áreas de proceso. Cada una
de las áreas de proceso avanzadas de Gestión de Proyectos
depende de la capacidad para planificar, monitorizar y controlar
el proyecto. Las áreas de proceso básicas de Gestión de
Proyectos proporcionan esta capacidad.
67
FiGUra 4.4
Áreas de proceso avanzadas de Gestión de Proyectos
El área de proceso Gestión Integrada del Proyecto establece y

mantiene el proceso definido del proyecto que es adaptado a
partir del conjunto de procesos estándar de la organización
(Definición de Pro- cesos de la Organización). El proyecto se
gestiona usando el proceso definido del proyecto.
El proyecto usa y contribuye a los activos de proceso de la
orga- nización, se establece y mantiene el entorno de trabajo del
proyecto a partir de los estándares del entorno de trabajo de la
organización, y se establecen los equipos usando las reglas y
guías de la organización. Las partes interesadas relevantes del
proyecto coordinan sus esfuerzos de manera oportuna mediante
la identificación, negociación, y seguimiento de las
dependencias críticas y la resolución de aspectos de
coordinación.
Aunque la identificación y monitorización del riesgo se
cubren en las áreas de proceso Planificación del Proyecto, y
Monitorización y Control del Proyecto, el área de proceso Gestión
de Riesgos adopta un enfoque continuo y con visión de futuro
para gestionar los riesgos con actividades que incluyen la
identificación de los parámetros de riesgo, las evaluaciones del
riesgo y la mitigación del riesgo.
El área de proceso Gestión Cuantitativa del Proyecto establece
objetivos para la calidad y el rendimiento del proceso, redacta un
proceso definido que puede ayudar a lograr esos objetivos y
gestiona cuantitativamente el proyecto. Los objetivos de calidad
y de rendimiento del proceso del proyecto están basados en los
objetivos establecidos por la organización y el cliente.
El proceso definido del proyecto se crea usando técnicas
estadísti- cas y otras técnicas cuantitativas. Un análisis semejante
permite al proyecto predecir si conseguirá sus objetivos de
calidad y de rendimiento del proceso.
En base a la predicción, el proyecto puede ajustar el proceso
definido o puede negociar cambios a los objetivos de calidad y
de rendimiento del proceso. Conforme el proyecto progresa, el
rendimiento de los subprocesos seleccionados se monitoriza
cuidadosamente para ayudar a evaluar si el proyecto avanza según
lo previsto para alcanzar sus objetivos.
ingeniería
Las áreas de proceso de Ingeniería cubren las actividades de
desarrollo y de mantenimiento que se utilizan en todas las
disciplinas de ingenie- ría. Las áreas de proceso de Ingeniería
fueron escritas usando termino- logía general de ingeniería, de
forma que cualquier disciplina técnica implicada en el proceso de
desarrollo del producto (p. ej., ingeniería de software o ingeniería
mecánica) pueda usarlas para la mejora de procesos.
Las áreas de proceso de Ingeniería también integran los
procesos asociados con diferentes disciplinas de ingeniería en un
único proceso
Capítulo 4 Relaciones entre áreas de proceso 69
de desarrollo de producto, dando soporte a una estrategia de
mejora de procesos orientada al producto. Esta estrategia se
dirige más a los objetivos de negocio esenciales que a las
disciplinas técnicas específicas. Este enfoque a procesos, evita de
manera eficaz la tendencia hacia una mentalidad
“compartimentada” de la organización.
Las áreas de proceso de Ingeniería se aplican al desarrollo de
cualquier producto o servicio dentro del dominio de desarrollo
(p. ej., productos software, productos hardware, servicios,
procesos).
Las cinco áreas de proceso de Ingeniería de CMMI-DEV son
las siguientes:
• Integración del Producto (PI).

• Desarrollo de Requisitos (RD).
• Solución Técnica (TS).
• Validación (VAL).
• Verificación (VER).
interacciones que existen entre las cinco áreas de proceso de
Ingeniería.
El área de proceso Desarrollo de Requisitos identifica las
necesidades del cliente y las transforma en requisitos de
producto. El conjunto de requisitos de producto se analiza para
elaborar una solución conceptual de alto nivel. Posteriormente,
este conjunto de requisitos se asigna para establecer un conjunto
inicial de requisitos de componente de producto.
Se infieren otros requisitos que ayudan a definir el producto y
se asignan a componentes de producto. Este conjunto de
requisitos de producto y de componente de producto describe
claramente la presta- ción del producto, los atributos de calidad,
las características del dise- ño, los requisitos de verificación, etc.
en términos que el desarrollador pueda comprender y usar.
El área de proceso Desarrollo de Requisitos proporciona los
requisitos al área de proceso Solución Técnica, donde los
requisitos se convierten en la arquitectura del producto, los
diseños de los componentes de producto y los componentes de
producto (p. ej., mediante codificación y fabricación). Los
requisitos se proporcionan también al área de proceso Integración
del Producto, donde se combinan los componentes de producto y
se verifican las interfaces para asegurar que cumplen con los
requisitos de interfaz suministrados por el área de proceso
Desarrollo de Requisitos.
El área de proceso Solución Técnica desarrolla los paquetes
de datos técnicos relativos a los componentes de producto para
que se utilicen por el área de proceso Integración del Producto o
Gestión de Acuerdos con Proveedores. Se examinan soluciones
alternativas para seleccionar el diseño óptimo basado en criterios
establecidos. Estos criterios pueden ser significativamente
diferentes entre los
70
FiGUra 4.5
Áreas de proceso de ingeniería
distintos productos, dependiendo del tipo de producto, entorno
operativo, requisitos de prestación, requisitos de soporte y,
costes o calendarios de entrega. La tarea de seleccionar la
solución final utiliza las prácticas específicas del área de
proceso Análisis de De- cisiones y Resolución.
El área de proceso Solución Técnica se basa en las prácticas
es- pecíficas del área de proceso Verificación para realizar la
verificación del diseño y las revisiones entre pares durante el
diseño y antes de la construcción final.
El área de proceso Verificación asegura que los productos de
trabajo seleccionados cumplen los requisitos especificados. El
área de proceso Verificación selecciona los productos de trabajo y
métodos de verificación que se usarán para verificar los productos
de trabajo frente a los requisitos especificados. La verificación es
generalmente un proceso incremental, que comienza con la
verificación de componentes de producto y normalmente concluye
con la verificación de los productos totalmente ensamblados.
La verificación también trata las revisiones entre pares. Las
revisiones entre pares son un método probado para eliminar
defectos de manera temprana y proporcionar una visión de valor
sobre los productos de trabajo y los componentes de producto
que están siendo desarrollados y mantenidos.
El área de proceso Validación valida de manera incremental
los productos frente a las necesidades del cliente. La validación
puede realizarse en el entorno operacional o en un entorno
operacional simulado. La coordinación con el cliente sobre los
requisitos de validación es un elemento importante de éste área
de proceso.
El alcance del área de proceso Validación incluye la
validación de productos, de componentes de producto, de
productos de trabajo intermedios seleccionados y de procesos.
Estos elementos validados pueden requerir, con frecuencia,
volver a ser verificados y validados. Las cuestiones
descubiertas durante la validación se resuelven normalmente en
el área de proceso Desarrollo de Requi- sitos o Solución
Técnica.
El área de proceso Integración del Producto contiene las
prácticas específicas asociadas con la generación de una
estrategia de integra- ción, integrando los componentes de
producto y entregando el producto al cliente.
La Integración del Producto utiliza las prácticas específicas
tanto de Verificación como de Validación, en la implementación
del proceso de integración del producto. Las prácticas de
verificación verifican las interfaces y los requisitos de interfaz de
los componentes de producto antes de la integración del producto.
La verificación de la interfaz es esencial en el proceso de
integración. Durante la integración del producto en el entorno
operacional, se utilizan las prácticas específicas del área de
proceso Validación.
expandiendo las capacidades por las “Constelaciones”
por Mike Phillips

recursión e iteración de los procesos de ingeniería

La mayoría de los estándares de proceso coinciden en que los
procesos se pueden aplicar de dos formas. Estas dos formas se
denominan recursión e iteración.
La recursión sucede cuando un proceso se aplica a los niveles
sucesivos de elementos del sistema dentro de una estructura de
sistema. Los resultados de una aplicación en un nivel se usan
como entrada para el siguiente nivel en la estructura del sistema.
Por ejemplo, el proceso de verificación se diseña para aplicarlo
al producto ensamblado completo, a los componentes principales
del producto, e incluso a los componentes de los componentes.
La profundidad con que se puede aplicar el proceso de
verificación en el producto depende completamente del tamaño
y de la complejidad del producto final.
La iteración sucede cuando los procesos se repiten en el
mismo nivel del sistema. La nueva información se crea por la
implementación de un proceso que realimenta dicha información
a un proceso relacionado. Esta nueva información normalmente
plantea cuestiones que deben ser resueltas antes de finalizar los
procesos.
Por ejemplo, muy probablemente habrá iteración entre el de-
sarrollo de requisitos y la solución técnica. Al volver a realizar
los procesos se pueden resolver las cuestiones que hayan surgido.
La iteración puede asegurar la calidad antes de aplicarse al
siguiente proceso.
Los procesos de Ingeniería (p. ej., desarrollo de requisitos,
verifica- ción) se implementan reiteradamente sobre un producto
para asegurar que estos procesos se han realizado adecuadamente
antes de la entrega al cliente. Además, los procesos de ingeniería
se aplican a componentes de producto.
Por ejemplo, algunas cuestiones surgidas relacionadas con las
áreas de proceso Verificación y Validación se pueden resolver por
los procesos asociados con las áreas de proceso Desarrollo de
Requisitos o Integración del Producto. La recursión y la iteración
de estos procesos permiten al proyecto asegurar la calidad en
todos los componentes del producto antes de que sean entregados
al cliente.
Del mismo modo, las áreas de proceso de gestión de
proyectos pueden ser recursivas, porque en algunas ocasiones los
proyectos forman parte de otros proyectos.
las medición da sentido a la mejora
por DAVID N. CARd

soporte
Las áreas de proceso de Soporte cubren las actividades que dan
soporte al desarrollo y al mantenimiento del producto. Las áreas
de proceso de Soporte abordan los procesos que se usan en el
contexto de la realización de otros procesos. En general, las áreas
de proceso de Soporte abordan los procesos que están dirigidos
hacia el proyecto y pueden abordar los procesos que se aplican
más generalmente a la organización.
Por ejemplo, el Aseguramiento de la Calidad del Proceso y del
Pro- ducto se puede usar con todas las áreas de proceso para
proporcionar una evaluación objetiva de los procesos y de los
productos de trabajo descritos en todas las áreas de proceso.
Las cinco áreas de proceso de Soporte de CMMI-DEV son
las siguientes:
• Análisis Causal y Resolución (CAR).
• Gestión de Configuración (CM).
• Análisis de Decisiones y Resolución (DAR).
• Medición y Análisis (MA).
• Aseguramiento de la Calidad del Proceso y del Producto
(PPQA).
áreas de proceso básicas de soporte

Las áreas de proceso básicas de Soporte tratan las funciones de
soporte fundamentales que se usan por todas las áreas de
proceso. Aunque todas las áreas de proceso de Soporte usan
como entrada otras áreas de proceso, las áreas de proceso básicas
de Soporte proporcionan funciones de soporte que también
ayudan a implementar varias prácticas genéricas.
interacciones entre las áreas de proceso básicas de Soporte y con
todas las demás áreas de proceso.
El área de proceso Medición y Análisis da soporte a todas las
áreas de proceso, proporcionando prácticas específicas que guían
a los proyectos y a las organizaciones, alineando las necesidades
y objetivos de medición, con un enfoque de medición, que se usa
para dar soporte a las necesidades de información de gestión. Los
resultados se pueden usar para la toma de decisiones
fundamentadas y para la toma de las acciones correctivas
apropiadas.
FiGUra 4.6
Áreas de proceso básicas de soporte
El área de proceso Aseguramiento de la Calidad del Proceso y
del Producto da soporte a todas las áreas de proceso
proporcionando prác- ticas específicas para evaluar
objetivamente los procesos, los productos de trabajo y los
servicios realizados frente a las descripciones de proceso
estándares y procedimientos aplicables, y para asegurar que se
trata cualquier cuestión surgida de estas revisiones.
El Aseguramiento de la Calidad del Proceso y del Producto
da soporte a la entrega de productos y servicios de alta calidad,
proporcionando al personal del proyecto y a todos los niveles
de gestión la visibilidad apropiada, y una realimentación sobre
los procesos y productos de trabajo asociados, durante la vida del
proyecto.
El área de proceso Gestión de Configuración da soporte a
todas las áreas de proceso estableciendo y manteniendo la
integridad de los productos de trabajo, usando la identificación de
la configuración, el control de la configuración, los informes de
estado de la configuración y las auditorías de la configuración.
Los productos de trabajo puestos bajo gestión de configuración
incluyen los productos que se entregan al cliente, los productos
de trabajo internos seleccionados, los productos adquiridos, las
herramientas y otros elementos que se utilizan para crear y
describir estos productos de trabajo.
Algunos ejemplos de productos de trabajo que se pueden
poner bajo gestión de configuración son: los planes, las
descripciones de procesos, los requisitos, los datos de diseño, los
diagramas, las especificaciones de producto, el código, los
compiladores, los ficheros de datos del producto y las
publicaciones técnicas del producto.
áreas de proceso avanzadas de soporte

Las áreas de proceso avanzadas de Soporte proporcionan a los
proyectos y a la organización una capacidad de soporte
mejorada. Cada una de estas áreas de proceso se apoya en las
entradas o prácticas específi- cas de otras áreas de proceso.
interacciones entre las áreas de proceso avanzadas de Soporte y
con todas las demás áreas de proceso.
Mediante el uso del área de proceso Análisis Causal y
Resolu- ción, los miembros del proyecto identifican las causas de
los resultados seleccionados y toman acciones para prevenir
que se obtengan resultados negativos en el futuro o para
consolidar los resultados positivos. Aunque los objetivos
iniciales del análisis de causas raíz y de los planes de acción son
los procesos definidos del proyecto, los cambios efectivos al
proceso pueden dar como resultado propuestas de mejoras que se
trasladan al conjunto de procesos estándar de la organización.
El área de proceso Análisis de Decisiones y Resolución da
soporte a todas las áreas de proceso, determinando qué cuestiones
deberían estar sujetas a un proceso de evaluación formal, para
luego aplicarles dicho proceso.
FiGUra 4.7
Áreas de proceso avanzadas de soporte
personas, procesos, tecnología, y CMMi
por GARgi Keeni

Capítulo 5
utilizando los modelos Cmmi
La complejidad de los productos demanda hoy en día una visión

integrada del funcionamiento de las organizaciones. CMMI
puede reducir el coste de la mejora de procesos en las empresas
que dependen de múltiples funciones o grupos para lograr sus
objetivos.
Para lograr esta visión integrada, el Marco CMMI incluye una
ter- minología común, unos componentes del modelo comunes,
métodos de evaluación comunes y materiales de formación
comunes. Este ca- pítulo describe cómo las organizaciones
pueden utilizar el Conjunto de Productos de CMMI no solo para
mejorar su calidad, reducir sus costes y optimizar sus plazos, sino
también para medir cómo está funcionando su programa de
mejora de procesos.
el papel de los estándares de proceso en la definición

de procesos†
por JAMES W. Moore
†
© 2010 The MITRE Corporation. Todos los derechos reservados.
[La afiliación del autor con The MITRE Corporation se proporciona solamente con el
propósito de identificación y no conlleva ni implica que MITRE coincida con, o de
soporte a, las posiciones, opiniones o puntos de vista expresados por el autor].
85
Capítulo 5 Utilizando los modelos CMMI 87
adoptando Cmmi
La investigación ha mostrado que el paso inicial más importante
para la mejora de procesos es fomentar el apoyo de la organización
mediante un fuerte patrocinio de la alta dirección. Para obtener
este patrocinio, con frecuencia es beneficioso exponerles los
resultados de rendimiento experimentados por otras
organizaciones que han utilizado CMMI para mejorar sus
procesos [Gibson 2006].
Para más información acerca de los resultados de rendimiento
de CMMI, consúltese el sitio web del SEI en
http://www.sei.cmu.edu/ cmmi/research/results/.
El director, una vez comprometido como el patrocinador del
proceso de mejora, debe estar involucrado activamente en el
esfuerzo de mejora de procesos basado en CMMI. Las
actividades realizadas por el patrocinador de la alta dirección
incluyen, pero no se limitan a lo siguiente:
• Influir en la organización para adoptar CMMI.

• Seleccionar las mejores personas para gestionar el esfuerzo de
mejora de procesos.
• Monitorizar personalmente el esfuerzo de mejora de procesos.
• Ser un defensor y portavoz activo del esfuerzo de mejora de
procesos.
• Asegurar que están disponibles los recursos adecuados para
permitir que el esfuerzo de mejora de procesos tenga éxito.
Teniendo el suficiente patrocinio de la alta dirección, el

siguiente paso es establecer un grupo de procesos sólido y
técnicamente capacitado, que represente a las partes interesadas
relevantes para guiar los esfuerzos de mejora de procesos [Ahern
2008, Dymond 2005].
Para una organización con la misión de desarrollar sistemas
de software, el grupo de procesos podría incluir a aquellos que
representen a las diferentes disciplinas de la organización y a
otros miembros seleccionados en base a las necesidades de
negocio que conducen la mejora. Por ejemplo, un administrador
de sistemas, puede enfocarse en el soporte de tecnología de la
información, mientras que un repre- sentante de marketing puede
enfocarse en integrar las necesidades de los clientes. Ambos
miembros podrían realizar importantes contribuciones al grupo
de procesos.
Una vez que su organización decide adoptar CMMI, la
planifi- cación puede comenzar con un enfoque de mejora como
el modelo IDEALSM (Initiating, Diagnosing, Establishing, Acting,
and Learning) [McFeeley 1996]. Para más información acerca del
modelo IDEAL, consúltese el sitio web del SEI en
http://www.sei.cmu.edu/library/abstracts/reports/96hb001.cfm.
Responsabilidades ejecutivas en la mejora de procesos
por Bill Curtis

su programa de mejora de procesos

Utilice el Conjunto de Productos CMMI para ayudar a establecer
el programa de mejora de procesos de su organización. El uso del
Con- junto de Productos para este propósito, puede ser un
proceso relativamente informal que implique el entendimiento y
la aplicación de las buenas prácticas de CMMI a su organización.
Asimismo puede ser un proceso formal que implique una amplia
formación, la creación de una infraestructura de mejora de
procesos, evaluaciones, etc.
implementando la cultura de ingeniería para la mejora

de procesos de éxito
por Tomoo MATSUBARA

selecciones que influyen en su programa

Para aplicar CMMI en su organización para la mejora de procesos,
se deben seleccionar los tres elementos siguientes:
1. El alcance en la organización.
2. El modelo.
3. La representación.
La selección de los proyectos a implicar en su programa de
mejora de procesos es crucial. Si selecciona un grupo muy
grande, puede requerirse demasiado esfuerzo de mejora inicial.
La selección debería también considerar la homogeneidad en la
organización, en el produc- to y en el trabajo (es decir, si todos los
miembros del grupo son expertos en la misma disciplina, si
todos trabajan en el mismo producto o línea de negocio, etc.).
La selección de un modelo apropiado es también esencial
para el éxito de un programa de mejora de procesos. El modelo
CMMI- DEV se enfoca en las actividades para desarrollar
productos y servicios de calidad. El modelo CMMI-ACQ se
enfoca en las actividades para iniciar y gestionar la adquisición
de productos y servicios. El modelo CMMI-SVC se enfoca en
las actividades para proporcionar servicios de calidad al cliente
y a los usuarios finales. Cuando se selecciona un modelo, se
debería prestar atención al interés principal
de la organización y de los proyectos, así como a los procesos
necesarios para satisfacer los objetivos del negocio. Los
procesos del ciclo de vida (p. ej., concepción, diseño,
fabricación, despliegue, operaciones, mantenimiento, retirada) en
los cuáles se centra una organización, deberían también
considerarse al seleccionar un modelo apropiado.
Seleccione la representación (niveles de capacidad o de
madurez) que se ajuste a su idea de mejora de procesos.
Independientemente de la que elija, puede seleccionar casi
cualquier área de proceso o grupo de áreas de proceso para
orientar la mejora, aunque debería considerar las dependencias
entre áreas de proceso cuando realice dicha selección.
A medida que avanzan los planes y las actividades de mejora
de procesos, se deben seleccionar otros elementos importantes
incluyendo, si se usa una evaluación, qué método de evaluación
debería utilizarse, qué proyectos deberían evaluarse, cómo
debería asegurarse la formación para el personal y qué personal
debería ser formado.
modelos Cmmi
Los modelos CMMI describen las buenas prácticas que las
organizaciones han encontrado que son productivas y útiles para
lograr sus objetivos de negocio. Independientemente de su
organización, debe utilizar su criterio profesional a la hora de
interpretar las buenas prác- ticas CMMI a su situación,
necesidades y objetivos de negocio.
Esta utilización del criterio profesional se refuerza cuando vea
palabras tales como “adecuado”, “apropiado” o “según sea necesario”
en una meta o una práctica. Estas palabras se utilizan para las acti-
vidades que pueden no ser de igual relevancia en todas las situacio-
nes. Interprete estas metas y prácticas de forma que funcionen en su
organización.
Aunque las áreas de proceso describen las características de
una organización comprometida con la mejora de procesos, se
deben interpretar las áreas de procesos utilizando un
conocimiento en profundidad de CMMI, de su organización,
del entorno de negocio y de las circunstancias específicas
implicadas.
Cuando comience a utilizar un modelo CMMI para mejorar
los procesos de su organización, haga corresponder los procesos
de su organización con las áreas de proceso de CMMI. Esta
correspondencia le permite realizar una valoración inicial y
posteriormente hacer un seguimiento del nivel de conformidad de
su organización con el modelo CMMI que está utilizando e
identificar oportunidades de mejora.
Para interpretar las prácticas, es importante considerar el
contexto global en el cual esas prácticas se utilizan y determinar
hasta qué pun- to las prácticas satisfacen las metas de un área de
proceso en ese contexto. Los modelos CMMI no prescriben
procesos ni implican que los
procesos se ajusten exactamente a cualquier organización o
proyecto. En cambio, CMMI describe los criterios mínimos
necesarios para planificar e implementar procesos seleccionados
por la organización para la mejora basada en objetivos de negocio.
Las prácticas de CMMI de manera intencionada utilizan
frases no específicas, como “partes interesadas relevantes”, “según
proceda”, y “según sea necesario” para adecuarse a las necesidades
de diferentes organizaciones y proyectos. Las necesidades
específicas de un proyecto pueden también cambiar en
momentos diferentes a lo largo de su vida.
interpretando Cmmi al utilizar enfoques ágiles

Las prácticas de CMMI están diseñadas para proporcionar valor
en diferentes situaciones y, por lo tanto, se expresan en términos
generales. Debido a que CMMI no recomienda ningún enfoque
de desarrollo en particular, se proporciona poca información
que sea espe- cífica de un determinado enfoque. Por
consiguiente, aquellos que no tengan experiencia previa en
implementar CMMI en situaciones similares a la que tienen
ahora, pueden encontrar la interpretación poco intuitiva.
Para ayudar a quienes utilizan métodos ágiles a interpretar las
prácticas de CMMI en sus entornos, se han añadido notas en las
áreas de proceso seleccionadas. Estas notas se añaden,
generalmente en las notas introductorias, para las siguientes áreas
de proceso en CMMI- DEV: CM, PI, PMC, PP, PPQA, RD,
REQM, RSKM, TS y VER.
Todas las notas comienzan con las palabras, “En entornos ágiles”
y están en recuadros de ejemplo para ayudarle a reconocerlas fácil-
mente y recordarle que estas notas son ejemplos de cómo
interpretar las prácticas y, por lo tanto, no son ni necesarias ni
suficientes para implementar el área de proceso.
Existen múltiples enfoques ágiles. Las frases “entorno ágil” y “mé-
todo ágil” son las abreviaturas para cualquier enfoque de
desarrollo o de gestión que se adhiera al MANIFIESTO PARA el
DESARrollo Ágil [Beck 2001].
Tales enfoques se caracterizan por lo siguiente:
• Involucración directa del cliente en el desarrollo del producto.
• Utilización de múltiples iteraciones de desarrollo para aprender
y evolucionar el producto.
• Voluntad del cliente para compartir la responsabilidad en las
decisiones y riesgos.
Muchos enfoques de desarrollo y de gestión pueden compartir
una o más de estas características y aun así no son llamadas
“ágiles”. Por ejemplo, algunos equipos posiblemente sean “ágiles”
aunque no se
utilice el término ágil. Incluso si no está usando un enfoque ágil,
toda- vía podría encontrar utilidad en estas notas.
Tenga cuidado al utilizar estas notas. Su interpretación final
del área de proceso debería ajustarse a lo específico de su
situación, incluyendo el negocio, proyecto, grupo de trabajo u
objetivos de equipo de su organización, mientras cumpla
completamente las metas y prácti- cas de un área de proceso de
CMMI. Como se indicó anteriormente, las notas deberían
tomarse como ejemplos y nunca son ni necesarias ni suficientes
para implementar el área de proceso.
Algunos antecedentes generales y la motivación de las
orientaciones que figuran en los enfoques de desarrollo ágiles se
encuentran en la nota técnica del SEI CMMI or Agile: Why Not
EMBRACE Both! [Glazer 2008].
mejora de procesos en una pequeña compañía
por KHALED El EMAN

utilizando las evaluaciones Cmmi

A muchas organizaciones les proporciona valor medir su progreso
realizando una evaluación y de esta manera conseguir una
calificación de nivel de madurez o lograr un perfil de nivel de
capacidad. Estos tipos de evaluaciones se realizan normalmente,
al menos por alguna de las siguientes razones:
• Para determinar hasta qué punto los procesos de la
organización se equiparan con las buenas prácticas de CMMI e
identificar áreas donde se pueden realizar mejoras.
• Para informar a los clientes y proveedores externos cómo se
adecúan los procesos de la organización a las buenas prácticas
de CMMI.
• Para cumplir los requisitos contractuales de uno o más clientes.
Las evaluaciones de las organizaciones que utilizan el
modelo CMMI deben ajustarse a los requisitos definidos en el
documento APPRAISAL Requirement for CMMI (ARC) [SEI 2011b].
Las evaluaciones se centran en la identificación de
oportunidades de mejora y en la comparación de los procesos de
la organización con las buenas prác- ticas de CMMI.
Los equipos de evaluación utilizan el modelo CMMI y un
método de evaluación conforme con ARC para orientar la
evaluación de su organización y el informe de conclusiones. Los
resultados de la evalua- ción son utilizados (p. ej., por un grupo de
procesos) para planificar mejoras para la organización.
Requisitos de la evaluación para Cmmi

El documento APPRAISAL Requirements for CMMI (ARC) describe
los requisitos para diferentes tipos de evaluaciones. Una
evaluación completa de benchmarking se define como un
método de evaluación de Clase A. Métodos menos formales se
definen como métodos de Clase B o de Clase C. El documento
ARC fue diseñado para ayudar a mejorar la consistencia entre los
diferentes métodos de evaluación, y para ayudar a los
desarrolladores del método de evaluación, patrocinadores, y
usuarios a comprender los pros y contras asociados con los
diferentes métodos.
Dependiendo del propósito de la evaluación y de la naturaleza
de las circunstancias, se puede tener preferencia por una clase u
otra. Al- gunas veces son apropiadas autoevaluaciones,
evaluaciones iníciales, exámen superficial o mini-evaluaciones o
evaluaciones externas, en otros casos es apropiada una evaluación
de benchmarking formal.
Un método de evaluación particular se establece como
método de evaluación ARC Clase A, B o C en base a los
conjuntos de requisitos ARC que abordó el desarrollador del
método durante su diseño.
Más información acerca del ARC está disponible en el sitio web
del SEI http://www.sei.cmu.edu/cmmi/tools/appraisals/.
métodos de evaluación sCampi

El método de evaluación SCAMPI A es el método más ampliamente
aceptado y utilizado para realizar las evaluaciones ARC Clase A
utilizando los modelos CMMI. El documento Method Definition
Document (MDD) de SCAMPI A define las reglas para asegurar la
consistencia de las calificaciones de la evaluación [SEI 2011a]. Para
poder realizar un benchmarking frente a otras organizaciones, las
evaluaciones deben asegurar calificaciones consistentes. Alcanzar
un nivel de madurez es- pecífico o satisfacer un área de proceso
debe significar lo mismo para las diferentes organizaciones
evaluadas.
La familia SCAMPI de evaluaciones incluye los métodos de
eva- luación de Clase A, B y C. El método de evaluación
SCAMPI A es el método oficialmente reconocido y el más
riguroso. Es el único método que puede dar lugar a calificaciones
comparativas de calidad. Los mé- todos de evaluación SCAMPI B
y C proporcionan a las organizaciones información de mejora que
es menos formal que los resultados de una evaluación SCAMPI A,
pero que, sin embargo, ayuda a la organización a identificar
oportunidades de mejora.
Más información acerca de los métodos SCAMPI está
disponible en el sitio web del SEI
http://www.sei.cmu.edu/cmmi/tools/appraisals/.
Consideraciones de la evaluación
Para realizar una evaluación basada en CMMI hay que
seleccionar:
• Modelo CMMI.
• Alcance de la evaluación, incluyendo la unidad de la
organización a evaluar, las áreas de proceso de CMMI a
investigar y el nivel de madurez o niveles de capacidad a
evaluar.
• Método de evaluación.
• Líder del equipo de evaluación y miembros del equipo.
• Participantes de la evaluación a entrevistar seleccionados de las
entidades de la evaluación.
• Resultados de la evaluación (p. ej., calificaciones, hallazgos
especí- ficos de la instanciación).
• Restricciones de la evaluación (p. ej., tiempo dedicado in situ).
El MDD de SCAMPI permite la selección de opciones
predefinidas para utilizar en una evaluación. Estas opciones de
evaluación están diseñadas para ayudar a las organizaciones a
alinear CMMI con sus necesidades de negocio y objetivos.
Los planes y los resultados de la evaluación de CMMI
deberían siempre incluir una descripción de las opciones de
evaluación, del alcance del modelo y del alcance seleccionado
de la organización. Esta documentación confirma si una
evaluación cumple con los requisitos para el benchmarking.
Para organizaciones que deseen evaluar múltiples funciones o
grupos, el enfoque integrado de CMMI permite algunas
economías de escala en la formación en el modelo y en la
evaluación. Un método de evaluación puede proporcionar
resultados separados o combinados para múltiples funciones.
Los siguientes principios de la evaluación para CMMI son los
mismos que los utilizados en evaluaciones para otros modelos
de mejora de procesos:
• Patrocinio de la alta dirección1.
• Enfoque en los objetivos de negocio de la organización.
• Confidencialidad para los entrevistados.
• Utilización de un método documentado de evaluación.
• Utilización de un modelo de referencia de procesos (p. ej., un
modelo CMMI).
1. La experiencia ha demostrado que el factor más crítico que influye en la mejora de

procesos y evaluaciones es el patrocinio de la alta dirección.
• Enfoque de equipo colaborativo.

• Enfoque en acciones para la mejora de procesos.
Formación relacionada con Cmmi

Tanto si su organización se está iniciando en la mejora de
procesos como si ya está familiarizada con los modelos de mejora
de procesos, la formación es un elemento clave en la capacidad de
las organizaciones para adoptar CMMI. El SEI y su Red de
Socios proporcionan un conjunto inicial de cursos, pero su
organización puede desear comple- mentar estos cursos con
formación interna. Este enfoque permite a su organización
centrarse en las áreas que proporcionan el mayor valor para el
negocio.
El SEI y su Red de Socios ofrecen el curso introductorio, Intro-
duction to CMMI for Development. Asimismo, el SEI ofrece
formación avanzada a aquellos que pretendan estar más
profundamente involucrados en la adopción o evaluación de
CMMI –por ejemplo, aquellos que orientarán la mejora como parte
del grupo de procesos, aquellos que liderarán las evaluaciones
SCAMPI y aquellos que impartirán el curso Introduction to CMM
for Development.
La información actual acerca de la formación relacionada con
CMMI está disponible en el sitio web del SEI
http://www.sei.cmu.edu/ training/.
mejorando la práctica industrial
por HANS-JÜRgen Kugler

Capítulo 5 Utilizando los modelos CMMI
111
1
SEGUNDA PARTE
Metas genéricas y
prácticas genéricas,
y las áreas de proceso
GGS & GPS
METAS GENÉRICAS Y PRÁCTICAS GENÉRICAS
Visión general
Esta sección describe detalladamente todas las metas genéricas y
prác- ticas genéricas de CMMI —componentes del modelo que
tratan directamente la institucionalización del proceso. Cuando
usted aborde cada área de proceso, consulte esta sección para ver
los detalles de todas las prácticas genéricas.
La elaboración de las prácticas genéricas aparece después de
las prácticas genéricas para orientar sobre cómo puede aplicarse la
prácti- ca genérica de manera única a las áreas de proceso.
Institucionalización del proceso

La institucionAliz Ación es un concepto importante en la
mejora de procesos. Cuando se menciona en las descripciones
de las metas genéricas y de las prácticas genéricas, implica
que el proceso está arraigado en la forma en que se realiza el
trabajo y existe un compromiso y una consistencia para
realizar (es decir, ejecutar) el proceso.
Es más probable mantener un proceso institucionalizado en
periodos bajo presión. Sin embargo, cuando los requisitos y los
objetivos del proceso cambian, también puede ser necesario
cambiar la implementación del proceso para asegurar que sigue
siendo eficaz. Las prácticas genéricas describen las actividades
que tratan estos aspectos de institucionalización.
El grado de institucionalización está incorporado en las metas
ge- néricas y está expresado en los nombres de los procesos
asociados con cada una de las metas tal y como se indica Tabla
6.1.
Tabla 6.1 Metas genéricas y nombres de procesos
Meta genérica Progresión de procesos

GG 1 Proceso realizado
GG 2 Proceso gestionado
GG 3 Proceso definido
165
166 SEGUNDA PARTE LAS ÁREAS DE PROCESO
La progresión de la institucionalización del proceso se
caracteriza en las siguientes descripciones de cada proceso.
Proceso realizado
Un proceso realizado es un proceso que lleva a cabo el trabajo
necesario para satisfacer las metas específicas de un área de
proceso.
Proceso gestionado
Un proceso GESTIONADO es un proceso rEALIZADO que está planificado
y ejecutado de acuerdo a una política, emplea personas
cualificadas que tienen los recursos adecuados para producir
salidas controladas, involucra a las partes interesadas relevantes,
es monitorizado, controlado y revisado, y se evalúa para
determinar la adherencia a la descripción del proceso.
El proceso puede ser instanciado por un proyecto, por un
grupo o por una función organizativa. La gestión del proceso se
refiere a la institucionalización y a la consecución de otros
objetivos específicos establecidos para el proceso, tales como
coste, calendario, y objetivos de calidad. El control proporcionado
por un proceso gestionado ayuda a asegurar que el proceso
establecido se mantiene en periodos bajo presión.
Los requisitos y los objetivos del proceso son establecidos
por la organización. El estado de los productos de trabajo y los
servicios es visible para la gestión en puntos definidos (p. ej., en
los principales hitos y en la finalización de las principales tareas).
Los compromisos son establecidos entre aquellos que realizan el
trabajo y las partes interesadas relevantes, y son modificados
cuando es necesario. Los productos de trabajo son revisados con
las partes interesadas relevantes y son controlados. Los productos
de trabajo y los servicios satisfacen los requisitos especificados.
Una diferencia crítica entre un proceso rEALIZADO y un proceso
ges- TIONADO es el grado en que el proceso es gestionado. Un proceso
gestionado está planificado (el plan puede ser parte de un plan
más amplio) y la ejecución del proceso es gestionada frente al
plan. Se toman acciones correctivas cuando los resultados reales
y la ejecución se desvían de forma significativa del plan. Un
proceso GESTIONADO alcanza los objetivos del plan y se
institucionaliza para para ejecutarlo de una manera consistente.
Proceso definido
Un proceso definido es un proceso GESTIONADO que es adaptado a
partir del conjunto de procesos estándar de la organización de
acuerdo a las guías de adaptación de la organización; dispone de
una descripción del proceso que se mantiene; y aporta
experiencias relativas al proceso a los activos de proceso de la
organización.
Los activos de proceso de la organización son artefactos que

se refieren a la descripción, implementación y mejora de los
GGS & GPS

procesos. Estos artefactos son activos porque se desarrollan o
adquieren para cumplir los objetivos de negocio de la
organización y representan inversiones de la organización que
se espera que proporcionen valor al negocio actual y futuro.
El conjunto de procesos estándar de la organización, que
son la base del proceso definido, se establecen y mejoran en el
tiempo. Los procesos estándar describen los elementos de
proceso fundamentales que se esperan en los procesos
definidos. Los procesos estándar también describen las
relaciones (p. ej., el orden, las interfaces) entre estos
elementos de proceso. La infraestructura a nivel de
organización para dar soporte al uso actual y futuro del
conjunto de procesos estándar de la organización se establece
y se mejora con el tiempo (véase la definición de “proceso
estándar” en el glosario).
Un proceso definido del proyecto proporciona una base para la
planificación, realización y mejora de las tareas y actividades del
proyecto. Un proyecto puede tener más de un proceso definido
(p. ej., uno para desarrollar el producto y otro para probarlo).
Un proceso definido establece claramente lo siguiente:
• Propósito.
• Entradas.
• Criterios de entrada.
• Actividades.
• Roles.
• Medidas.
• Pasos de verificación.
• Salidas.
• Criterios de salida.
Una diferencia crítica entre un proceso GESTIONADO y un proceso

definido es el alcance de aplicación de las descripciones del
proceso, de los estándares y de los procedimientos. Para un
proceso GESTIONADo, las descripciones del proceso, los estándares y
los procedimientos son aplicables a un proyecto, grupo o función
de la organización concretos. Como resultado, los procesos
gestionados de dos proyectos de una organización pueden ser
diferentes.
Otra diferencia crítica es que un proceso definido está descrito
con más detalle y es realizado con más rigor que un proceso
GESTIONADO. Esta diferencia significa que la información de mejora
es más fácil de comprender, analizar y usar. Por último, la
gestión del proceso definido se basa en la visión adicional
proporcionada por la comprensión
de las interrelaciones de las actividades del proceso y de las
medidas detalladas del mismo, sus productos de trabajo y sus
servicios.
Relaciones entre procesos

Las metas genéricas evolucionan de manera que cada una de ellas
proporcione una base para la siguiente. Por lo tanto, las
conclusiones que pueden extraerse son:
 Un proceso GESTIONADO es un proceso rEALIZADO.
 Un proceso definido es un proceso GESTIONADO.
Por ello, aplicado de forma secuencial y en orden, las metas

gené- ricas describen un proceso que está cada vez más
institucionalizado, desde un proceso rEALIZADO hasta un proceso
definido.
Lograr GG 1 para un área de proceso equivale a decir que se
logran las metas específicas del área de proceso.
Lograr GG 2 para un área de proceso equivale a decir que se
gestiona la ejecución de los procesos asociados con el área de
proceso. Hay una política que indica que usted realizará el
proceso. Hay un plan para realizarlo. Se dispone de los
recursos, se asignan responsabilidades, se imparte formación
sobre cómo realizarlo, se controlan los productos de trabajo
seleccionados de la ejecución del proceso y así sucesivamente.
En otras palabras, el proceso se planifica y se monitoriza igual
que cualquier otra actividad de proyecto o de soporte.
Lograr GG 3 para un área de proceso equivale a decir que
existe un proceso estándar de la organización que puede
adaptarse para dar como resultado el proceso que será utilizado.
La adaptación podría no requerir cambios al proceso estándar. En
otras palabras, el proceso utilizado y el proceso estándar pueden
ser idénticos. Usar el proceso estándar “tal cual es” es una
adaptación porque la decisión tomada es que no se requiere
ninguna modificación.
Cada área de proceso describe múltiples actividades, algunas
de las cuales se realizan repetidamente. Se puede necesitar
adaptar la forma en que se realiza una de estas actividades para
dar cabida a nuevas capacidades o circunstancias. Por ejemplo,
se puede tener un estándar para desarrollar u obtener la
formación de la organi- zación que no considera la formación
basada en internet. Cuando se está preparando para desarrollar
u obtener un curso basado en internet, puede que sea necesario
adaptar el proceso estándar para tener en cuenta los retos y los
beneficios particulares de este tipo de formación.
Metas genéricas y prácticas genéricas

Esta sección describe todas las metas genéricas y las prácticas
genéricas, así como sus subprácticas, notas, ejemplos y
referencias
asociadas. Las metas genéricas están organizadas en orden numé-
rico, GG 1 a GG 3. Las prácticas genéricas también están organi-
GGS & GPS

zadas en orden numérico dentro de la meta genérica a la que dan
soporte.
GG 1 L oGrar Las metas específicas
Las metas específicas del área de proceso están soportadas por el proceso me-
diante la transformación de los productos de trabajo de entrada identificables
en productos de trabajo de salida identificables.
Gp 1.1 RealizaR las pRácticas específicas

Realizar las prácticas específicas del área de proceso para desarrollar produc-
tos de trabajo y proporcionar servicios para lograr las metas específicas del
área de proceso.
El propósito de esta práctica genérica es producir los productos

de trabajo y entregar los servicios que se esperan al realizar (es
decir, ejecutar) el proceso. Estas prácticas se pueden hacer de
manera informal sin seguir una descripción documentada del
proceso o un plan. El rigor con que estas prácticas se realizan
depende de las personas que gestionan y realizan el trabajo, y
puede variar considerablemente.
GG 2 i nstitucionaLizar un proceso Gestionado
El proceso está institucionalizado como un proceso gestionado.
Gp 2.1 estableceR una política de la oRganización

Establecer y mantener una política de la organización para planificar y realizar
el proceso.
El propósito de esta práctica genérica es definir las expectativas

de la organización en relación con el proceso y hacerlas visibles a
aquellos miembros de la organización que están afectados. En
general, la alta dirección es responsable de establecer y
comunicar las directrices, la orientación y las expectativas para la
organización.
No toda orientación de la alta dirección llevará la etiqueta “po-
lítica”. Lo que se espera de esta práctica genérica es la existencia de
una orientación apropiada de la organización, independientemente
de cómo sea llamada o sea comunicada.
ELABORACIÓN de CAR
identificar y tratar sistemáticamente el análisis causal de los
resultados seleccionados.
ELABORACIÓN de CM
establecer y mantener las líneas base, para seguir y controlar los
cambios a los productos de trabajo (bajo gestión de
configuración), y para establecer y mantener la integridad de las
líneas base.
ELABORACIÓN de DAR
analizar selectivamente las posibles decisiones usando un
proceso de evaluación formal que evalúa las alternativas
identificadas frente a los criterios establecidos. La política
también debería proporcionar orientación sobre qué decisiones
requieren un proceso de evaluación formal.
ELABORACIÓN de IPM
establecer y mantener el proceso definido del proyecto desde su
inicio y a lo largo de la vida del mismo, para utilizar el proceso
definido del proyecto para gestionar el proyecto, y para coordinar
y colaborar con las partes interesadas relevantes.
ELABORACIÓN de MA
alinear los objetivos y las actividades de medición con las
necesidades de in- formación identificadas y los objetivos del
proyecto, de la organiza- ción o del negocio, y para proporcionar
resultados de la medición.
ELABORACIÓN de OPD
establecer y mantener un conjunto de procesos estándar a utilizar
por la orga- nización, para poner a disposición de toda la
organización los activos de proceso de la organización, y para
establecer reglas y guías para los equipos.
ELABORACIÓN de OPF
determinar las oportunidades de mejora de procesos para los
procesos que están siendo usados y para planificar, implementar y
desplegar las mejoras de procesos en toda la organización.
ELABORACIÓN de OPM
analizar el rendimiento del negocio de la organización utilizando
técnicas esta- dísticas y otras técnicas cuantitativas para
determinar las deficiencias de rendimiento, y para identificar y
desplegar las mejoras de proceso y
de tecnología que contribuyen a cumplir los objetivos de calidad
y de rendimiento de proceso.
GGS & GPS

ELABORACIÓN de OPP
establecer y mantener las líneas base de rendimiento de proceso
y los modelos de rendimiento de proceso para el conjunto de
procesos estándar de la organización.
ELABORACIÓN de OT
identificar las necesidades estratégicas de formación en la
organización y para proporcionar esa formación.
ELABORACIÓN de PI
desarrollar las estrategias de integración de productos, los
procedimientos y un entorno de integración; para asegurar la
compatibilidad entre las interfaces de los componentes del
producto; para ensamblar los componentes del producto; y para
entregar el producto y los componentes del producto.
ELABORACIÓN de PMC
monitorizar el progreso y el rendimiento del proyecto frente al
plan de proyecto y para gestionar las acciones correctivas hasta
su cierre cuando la realidad o los resultados se desvíen
significativamente del plan.
ELABORACIÓN de PP
estimar los parámetros de la planificación, para definir
compromisos internos y externos, y para desarrollar un plan para
gestionar el proyecto.
ELABORACIÓN de PPQA
evaluar objetivamente si los procesos y los productos de trabajo
asociados se adhieren a las descripciones de proceso, estándares
y procedimientos aplicables, y para asegurar que se resuelven las
no conformidades.
Esta política también establece las expectativas de la
organización para que el aseguramiento de la calidad del proceso y
del producto esté implantado en todos los proyectos. El
aseguramiento de la calidad del proceso y del producto debe
poseer la independencia de la gestión del proyecto suficiente para
proporcionar objetividad en la identificación y la comunicación
de las no conformidades.
ELABORACIÓN de QPM
utilizar técnicas estadísticas y otras técnicas cuantitativas y datos
históricos al: establecer los objetivos de calidad y de rendimiento
de proceso, componer el proceso definido del proyecto,
seleccionar los atributos de subprocesos críticos para la
comprensión del funcionamiento del proceso, monitorizar el
subproceso y el rendimiento del proyecto, y realizar análisis de
causa raíz para tratar las deficiencias de rendimien- to de proceso.
En concreto, esta política establece las expectativas de la
organización para el uso de las medidas, líneas base y modelos
de rendimiento de proceso.
ELABORACIÓN de RD
recoger las necesidades de las partes interesadas, para formular
los requisitos del producto y de los componentes de producto, y
para analizar y validar esos requisitos.
ELABORACIÓN de REQM
gestionar los requisitos y para identificar las inconsistencias
entre los requisitos, y los planes del proyecto y los productos de
trabajo.
ELABORACIÓN de RSKM
definir una estrategia de gestión de riesgos, y para identificar,
analizar y mitigar riesgos.
ELABORACIÓN de SAM
establecer, mantener y satisfacer los acuerdos con el proveedor.
ELABORACIÓN de TS
tratar el ciclo iterativo en el cual se seleccionan las soluciones del
producto o de componentes del producto, se desarrollan y se
implementan los diseños.
ELABORACIÓN de VAL
seleccionar productos y componentes de producto para la
validación, para seleccionar los métodos de validación, y para
establecer y mantener los procedimientos, criterios y entornos de
validación que aseguren que los productos y los componentes de
producto satisfacen las necesidades del usuario final en su
entorno operacional previsto.
ELABORACIÓN de VER
GGS & GPS

establecer y mantener los métodos, procedimientos, criterios de
verificación y el entorno de verificación, así como para realizar
revisiones entre pares y verificar los productos de trabajo
seleccionados.
Gp 2.2 planificaR el pRoceso
Establecer y mantener el plan para realizar el proceso.
El propósito de esta práctica genérica es determinar lo que se

necesita para realizar el proceso y para alcanzar los objetivos
establecidos, preparar un plan para realizar el proceso, preparar
una descripción del proceso y acordar el plan con las partes
interesadas relevantes.
Las implicaciones prácticas de la aplicación de una práctica
gené- rica varían para cada área de proceso.
Por ejemplo, la planificación descrita por esta práctica genérica aplicada al

área de proceso de Monitorización y Control del Proyecto (PMC) puede ser
llevada a cabo completamente por los procesos asociados con el área de
proceso Planificación del Proyecto (PP). Sin embargo, esta práctica genérica,
cuando se aplica al área de proceso Planificación del Proyecto (PP), estable-
ce una expectativa de que se ha planificado el proceso de planificación del
proyecto en sí mismo.
Por lo tanto, esta práctica genérica puede bien reforzar las

expectativas establecidas en otras partes de CMMI o bien
establecer nuevas expectativas que deberían alcanzarse.
PARA más INFORMACIÓN sobre el ESTABLECIMIENTO y el MANTENIMIENTO de los PLANES
que definen LAS ACTIVIDADES del proyecto, consúltese el árEA de proceso PLANIFICA-
ción del Proyecto (PP).
Establecer un plan incluye documentar el plan y una
descripción del proceso. Mantener el plan incluye su
actualización para reflejar las acciones correctivas o cambios en
los requisitos o en los objetivos.
El plan para realizar el proceso normalmente incluye:

• Descripción del proceso.
• Estándares y requisitos para los productos de trabajo y los servicios del
proceso.
• Objetivos específicos para la ejecución del proceso y sus resultados (p.
ej., calidad, escala de tiempo, tiempo de ciclo, uso de recursos).
• Dependencias entre las actividades, los productos de trabajo y los
servicios del proceso.
• Recursos (p. ej., financiación, personas, herramientas) necesarios para
realizar el proceso.
Continúa
Continuación
• Asignación de responsabilidad y de autoridad.
• Formación necesaria para realizar y dar soporte al proceso.
• Productos de trabajo a controlar y el nivel de control a aplicar.
• Requisitos de medición para proporcionar una visión de la ejecución
del proceso, sus productos de trabajo y sus servicios.
• Involucración de las partes interesadas relevantes.
• Actividades de monitorización y control del proceso.
• Actividades de evaluación objetiva del proceso.
• Actividades de revisión de gestión para el proceso y para los productos
de trabajo.
SUBPRÁCTICAS
1. Definir y documentar el plan para realizar el proceso.
Este plan puede ser un documento independiente,
incorporado en un documento más completo o distribuido en
varios documentos. En el caso de que el plan esté
distribuido en varios documentos, hay que asegurarse que se
conserva una visión coherente de quién hace qué. Los
documentos pueden estar en papel o en formato electrónico.
2. Definir y documentar la descripción del proceso.
La descripción del proceso, que incluye los estándares y
procedimientos relevantes, puede incluirse como parte del
plan de reali- zación del proceso o puede referenciarse en el
plan.
3. Revisar el plan con las partes interesadas relevantes y obtener
su acuerdo.
Esta revisión del plan incluye la revisión de que el proceso
planificado satisface las políticas, los planes, los requisitos
y los es- tándares aplicables para proporcionar
aseguramiento a las partes interesadas relevantes.
4. Modificar el plan según sea necesario.
ELABORACIÓN de CAR
Este plan para realizar el proceso de análisis causal y
resolución puede estar incluido en (o referenciado por) el plan de
proyecto, que se describe en el área de proceso Planificación del
Proyecto. Este plan difiere de las acciones propuestas y de los
planes de acción asociados descritos en varias prácticas
específicas de éste área de proceso. El plan requerido en esta
práctica genérica trataría el proceso de análisis causal y
resolución global del proyecto (quizás adaptado a partir del
proceso estándar mantenido por la organización). Por el
contrario, las propuestas de acción del proceso y los elementos de
acción asociados tratan las actividades necesarias para tratar una
causa raíz específica bajo estudio.
ELABORACIÓN de CM
GGS & GPS

Este plan para realizar el proceso de gestión de configuración
puede estar incluido en (o referenciarse por) el plan de proyecto,
el cual se describe en el área de proceso Planificación del
Proyecto.
ELABORACIÓN de DAR
Este plan para realizar el proceso de análisis de decisiones y
resolución puede estar incluido en (o referenciado por) el plan de
proyecto, el cual se describe en el área de proceso Planificación
del Proyecto.
ELABORACIÓN de IPM
Este plan para el proceso de gestión integrada del proyecto
unifica la planificación de los procesos de planificación del
proyecto y de mo- nitorización y control del proyecto. La
planificación para realizar las prácticas relacionadas con la
planificación de la gestión integrada del proyecto, se aborda
dentro de la planificación del proceso de planifica- ción del
proyecto. Este plan para realizar las prácticas relacionadas con la
monitorización y control en la gestión integrada del proyecto
puede estar incluido en (o referenciado por) el plan de proyecto,
el cual se describe en el área de proceso Planificación del
Proyecto.
ELABORACIÓN de MA
Este plan para realizar el proceso de medición y análisis puede
estar incluido en (o referenciado por) el plan de proyecto, el cual se
describe en el área de proceso Planificación del Proyecto.
ELABORACIÓN de OPD
Este plan para realizar el proceso de definición de procesos de la
or- ganización, puede estar incluido en (o referenciado por) el
plan de mejora de procesos de la organización.
ELABORACIÓN de OPF
Este plan para realizar el proceso de enfoque en procesos de la
orga- nización, que se denomina a menudo “plan de mejora de
procesos”, difiere de los planes de acción de procesos descritos en
las prácticas específicas en éste área de proceso. El plan exigido
en esta práctica genérica trata la planificación completa de todas
las prácticas espe- cíficas en este área de proceso, desde el
establecimiento de las necesidades de proceso de la
organización hasta la incorporación de experiencias relacionadas
con los procesos en los activos de proceso de la organización.
ELABORACIÓN de OPM
Este plan para realizar el proceso de gestión del rendimiento de
la or- ganización difiere de los planes de despliegue descritos en
una práctica
específica en éste área de proceso. El plan requerido en esta
práctica genérica trata la planificación completa para todas las
prácticas espe- cíficas en este área de proceso, desde el
mantenimiento de los objetivos del negocio hasta la evaluación
de los efectos de la mejora. Por el contrario, los planes de
despliegue requeridos en la práctica específica tratarían la
planificación necesaria para el despliegue de las mejoras
seleccionadas.
ELABORACIÓN de OPP
Este plan para realizar los procesos del rendimiento de procesos
de la organización puede estar incluido en (o referenciado por) el
plan de mejora de procesos de la organización, el cual se describe
en el área de proceso Enfoque en los Procesos de la Organización,
o puede estar documentado en un plan separado que describe solo
el plan para el proceso de rendimiento del proceso de la
organización.
ELABORACIÓN de OT
Este plan para realizar el proceso de formación en la
organización difiere del plan táctico para la formación de la
organización descrito en una práctica específica de éste área de
proceso. El plan requerido en esta práctica genérica trata la
planificación completa para todas las prácticas específicas en éste
área de proceso, desde el establecimiento de las necesidades
estratégicas de formación hasta la evaluación de la eficacia de la
formación de la organización. Por el contrario, el plan táctico de
formación en la organización requerido en la práctica es- pecífica
de éste área de proceso trata la planificación periódica para la
entrega de ofertas de formación.
ELABORACIÓN de PI
Este plan para la realización del proceso de integración del
producto trata la planificación completa de todas las prácticas
específicas en éste área de proceso, desde la preparación de la
integración del producto hasta la entrega del producto final.
Este plan para realizar el proceso de integración del producto
puede ser parte de (o referenciado por) el plan de proyecto
como se describe en el área de proceso Planificación del
Proyecto.
ELABORACIÓN de PMC
Este plan para realizar el proceso de monitorización y control del
proyecto puede ser parte de (o referenciado por) el plan de
del Proyecto.
ELABORACIÓN de PP
PARA más INFORMACIÓN sobre LAS rELACIONES entre LA PRÁCTICA GENÉRICA 2.2
y el árEA de proceso de PLANIFICACIÓN del Proyecto, consúltese LA TABLA 6.2
en METAS GENÉRICAS y PRÁCTICAS GENÉRICAS.
GGS & GPS

Este plan para realizar el proceso de aseguramiento de la calidad
del proceso y del producto puede estar incluido en (o referenciado
por) el plan de proyecto, el cual se describe en el área de proceso
Planificación del Proyecto.
ELABORACIÓN de QPM
Este plan para realizar el proceso de gestión cuantitativa del
proyecto puede estar incluido en (o referenciado por) el plan de
del Proyecto.
ELABORACIÓN de RD
Este plan para realizar el proceso de desarrollo de requisitos puede
ser parte de (o referenciado por) el plan de proyecto, el cual se
Este plan para la ejecución del proceso de gestión de requisitos
puede ser parte de (o referenciado por) el plan de proyecto según
lo descrito en el área de proceso Planificación del Proyecto.
Este plan para realizar el proceso de gestión de riesgos puede
estar incluido en (o referenciado por) el plan de proyecto, el
cual se describe en el área de proceso Planificación del Proyecto.
El plan requerido en esta práctica genérica trata la planificación
completa para todas las prácticas específicas en éste área de
proceso. En particular, este plan proporciona la aproximación
global para la mitigación de riesgos, pero es distinto de los planes
de mitigación (incluyendo planes de contingencia) para riesgos
específicos. Por el contrario, los planes de mitiga- ción de riesgos
requeridos en las prácticas específicas de éste área de proceso
tratan elementos más detallados, tales como los niveles que
activan las actividades de tratamiento de riesgo.
ELABORACIÓN de SAM
Este plan para realizar el proceso de gestión de acuerdos con
proveedores puede ser parte de (o referenciado por) el plan de
proyecto, como se describe en el área de proceso Planificación de
Proyecto. Sin embargo, con frecuencia, algunas partes del plan
residen fuera del proyecto en grupos, tales como el de gestión de
contratos.
ELABORACIÓN de TS
Este plan para realizar el proceso de solución técnica puede ser
parte de (o referenciado por) el plan de proyecto, como se describe
en el área de proceso Planificación del Proyecto.
ELABORACIÓN de VAL
Este plan para realizar el proceso de validación puede estar
incluido en (o referenciado por) el plan de proyecto, el cual se
ELABORACIÓN de VER
Este plan para realizar el proceso de verificación puede estar
incluido en (o referenciarse por) el plan de proyecto, el cual se
Gp 2.3 pRopoRcionaR RecuRsos
Proporcionar recursos adecuados para realizar el proceso, desarrollar los pro-
ductos de trabajo y proporcionar los servicios del proceso.
El propósito de esta práctica genérica es asegurar que los recursos

necesarios para realizar el proceso tal y como se definieron en
el plan están disponibles cuando se necesiten. Los recursos
incluyen una fi- nanciación adecuada, instalaciones físicas
apropiadas, personal cualificado y herramientas apropiadas.
La interpretación del término “adecuado” depende de muchos
factores y puede cambiar con el tiempo. Si los recursos son
inadecuados, puede solventarse incrementando recursos o
eliminando requisitos, restricciones y compromisos.
ELABORACIÓN de CAR
Algunos ejemplos de recursos son:

• Sistemas de gestión de bases de datos.
• Herramientas de modelado de procesos.
• Paquetes de análisis estadístico.
ELABORACIÓN de CM

• Herramientas de gestión de configuración.
• Herramientas de gestión de datos.
• Herramientas de archivo y reproducción.
ELABORACIÓN de DAR
GGS & GPS

• Simuladores y herramientas de modelado.
• Herramientas de prototipado.
• Herramientas para realización de encuestas.
ELABORACIÓN de IPM

• Paquetes para el registro y seguimiento de problemas.
• Software colaborativo (Groupware).
• Vídeoconferencia.
• Base de datos de decisiones integradas.
• Entornos integrados de soporte del producto.
ELABORACIÓN de MA
El personal con experiencia adecuada proporciona soporte a las
actividades de análisis y medición. Puede existir un grupo de
medición con este rol.

• Paquetes estadísticos.
• Paquetes que dan soporte a la recogida de datos a través de la red.
ELABORACIÓN de OPD
El grupo de procesos normalmente gestiona las actividades de
defini- ción de procesos de la organización. Este grupo
normalmente está formado por un núcleo de profesionales cuya
principal responsabilidad es coordinar la mejora de procesos de la
organización.
Este grupo está soportado por los propietarios del proceso y por personal
con experiencia en varias disciplinas tales como:
• Gestión de proyectos.
• Las disciplinas de ingeniería apropiadas.
• Gestión de configuración.
• Aseguramiento de la calidad.

• Herramientas de construcción y navegadores de páginas web.
ELABORACIÓN de OPF

• Sistemas de gestión de base de datos.
• Herramientas de mejora de procesos.
• Herramientas de construcción y navegadores de páginas Web.
• Software colaborativo (Groupware).
• Herramientas de mejora de la calidad (p. ej., diagramas de causa-efecto,
diagramas de afinidad, diagramas de Pareto).
ELABORACIÓN de OPM

• Paquetes de simulación.
• Paquetes estadísticos.
• Modelización dinámica de sistemas.
• Subscripciones a bases de datos y publicaciones de tecnología on-line.
• Herramientas de modelización de procesos.
ELABORACIÓN de OPP
Puede ser necesario un conocimiento especial en técnicas
estadísticas y otras técnicas cuantitativas para establecer las
líneas base de rendimiento de los procesos para el conjunto de

• Sistemas de gestión de base de datos
• Modelos de la dinámica de sistemas.
• Paquetes de análisis estadísticos.
• Paquetes de seguimiento de problemas.
ELABORACIÓN de OT
GGS & GPS

Algunos ejemplos de los recursos son:
• Expertos en la materia.
• Diseñadores de planes de formación.
• Diseñadores de material de formación.
• Instructores.
• Administradores de formación.
Se pueden necesitar instalaciones especiales para la
formación. Cuando sea necesario, se desarrollan o se compran las
instalaciones necesarias para las actividades del área proceso
Formación en la Organización.

• Instrumentos para analizar las necesidades de formación.
• Puestos de trabajo para usarse para la formación.
• Herramientas de diseño de formación.
• Paquetes para desarrollar materiales de presentación.
ELABORACIÓN de PI
La coordinación de las interfaces de los componentes del
producto puede lograrse con un grupo de trabajo de control de
interfaz consistente en personas que representan las interfaces
externas e internas. Tales grupos pueden usarse para educir las
necesidades para el desarrollo de los requisitos de la interfaz.
Se puede necesitar instalaciones especiales para el ensamblaje
y la entrega del producto. Cuando sea necesario, se desarrollan o
se compran las instalaciones necesarias para las actividades del
área de proceso de Integración del producto.

• Herramientas de análisis.
• Herramientas de simulación.
• Herramientas de gestión de interfaz.
• Herramientas de ensamblaje (p. ej., compiladores, ficheros make,
herramientas de unión, patrones, dispositivos).
ELABORACIÓN de PMC

• Sistemas de seguimiento de costes.
• Sistemas de seguimiento de esfuerzo.
• Sistemas de seguimiento de elementos de acción.
• Programas de gestión del proyecto y del calendario.
ELABORACIÓN de PP
Para la planificación de proyectos pueden necesitarse experiencia,
equipamiento e instalaciones especiales.
La experiencia particular en planificación de proyectos puede incluir:

• Estimadores experimentados.
• Planificadores.
• Expertos técnicos en áreas aplicables (p. ej., dominio del producto,
tecnología).

• Programas de hojas de cálculo.
• Modelos de estimación.
• Paquetes de planificación y de calendario del proyecto.

• Herramientas de evaluación.
• Herramientas de seguimiento de no conformidades.
ELABORACIÓN de QPM
Puede ser necesaria experiencia específica en estadística y en su
uso en el análisis del rendimiento del proceso para definir las
técnicas ana- líticas usadas en la gestión cuantitativa. Puede
necesitarse también una experiencia específica en estadística para
analizar e interpretar las medidas resultantes del análisis
estadístico. Sin embargo, los equipos necesitan experiencia
suficiente para comprender el rendimiento de proceso a medida
que realizan su trabajo diario.
GGS & GPS

• Paquetes de análisis estadístico.
• Paquetes de control de calidad y de control estadístico de procesos.
• Scripts y herramientas que ayudana los equipos a analizar su propio
rendimiento de proceso con necesidad mínima de asistencia adicional de
expertos.
ELABORACIÓN de RD
Puede necesitarse una experiencia específica en el dominio de
aplica- ción, en los métodos para educir las necesidades de las
partes interesadas y en los métodos y herramientas para
especificar y analizar los requisitos de cliente, de producto y de
componente de producto.

• Herramientas de especificación de requisitos.
• Herramientas para la definición y gestión de escenarios.
• Herramientas para el seguimiento de los requisitos.

• Herramientas para el seguimiento de los requisitos.
• Herramientas de trazabilidad.

• Bases de datos de gestión de riesgos.
• Herramientas de mitigación de riesgos.
• Herramientas de modelado y simulación.
ELABORACIÓN de SAM

• Listas de proveedores preferentes.
• Herramientas de seguimiento de requisitos.
• Programas para gestión de proyectos y calendarios.
ELABORACIÓN de TS
Pueden requerirse instalaciones especiales para desarrollar,
diseñar e implementar soluciones para los requisitos. Cuando sea
necesario, se desarrollan o se compran las instalaciones
requeridas por las actividades del área de proceso Solución
Técnica.

• Herramientas de especificación del diseño.
• Herramientas de definición y gestión de escenarios.
• Herramientas de seguimiento de requisitos.
• Herramientas interactivas de documentación.
ELABORACIÓN de VAL
Pueden requerirse instalaciones especiales para validar el
producto o los componentes de producto. Cuando sea necesario,
se desarrollan o se compran las instalaciones necesarias para la
validación.

• Herramientas de gestión de pruebas.
• Generadores de casos de prueba.
• Analizadores de cobertura de las pruebas.
• Simuladores.
• Herramientas de pruebas de carga, de estrés y de rendimiento.
ELABORACIÓN de VER
Pueden requerirse instalaciones especiales para verificar los
productos de trabajo seleccionados. Cuando sea necesario, se
desarrollan o se compran las instalaciones necesarias para las
actividades del área de proceso Verificación.
Ciertos métodos de verificación pueden requerir
herramientas, equipamiento, instalaciones y formación especiales
(p. ej., las revisiones entre pares pueden requerir salas de
reuniones y moderadores formados; algunas pruebas de
verificación pueden requerir equipamiento especial de pruebas y
personal capacitado en el uso del equipamiento).

• Herramientas de gestión de pruebas.
• Generadores de casos de prueba.
• Analizadores de cobertura de prueba.
• Simuladores.
Gp 2.4 asignaR Responsabilidad
Asignar la responsabilidad y la autoridad para realizar el proceso, desarrollar
GGS & GPS

los productos de trabajo y proporcionar los servicios del proceso.
El propósito de esta práctica genérica es asegurar que existe

responsabilidad para realizar el proceso y conseguir los
resultados especificados a lo largo de la vida del proceso. Las
personas asignadas deben tener la autoridad apropiada para
realizar las responsabilidades asignadas.
La responsabilidad puede asignarse utilizando descripciones
detalladas del trabajo o en documentos operativos, tales como el
plan de realización del proceso. La asignación dinámica de
responsabilidades es otra forma legítima de implementar esta
práctica genérica, siempre y cuando la asignación y la aceptación
de la responsabilidad estén ase- guradas durante la vida del
proceso.
SUBPRÁCTICAS
1. Asignar la responsabilidad y la autoridad globalmente para
realizar el proceso.
2. Asignar la responsabilidad y la autoridad para realizar las tareas
es- pecíficas del proceso.
3. Confirmar que las personas a las que se ha asignado la
responsabilidad y la autoridad las comprenden y las aceptan.
ELABORACIÓN de OPF
Normalmente se establecen dos grupos y se les asigna la
responsabilidad para mejorar los procesos: (1) un comité de
dirección para la mejora de procesos a fin de proporcionar el
patrocinio de la alta direc- ción, y (2) un grupo de procesos para
facilitar y gestionar las actividades de mejora de procesos.
Se asigna la responsabilidad a aquellos que pueden realizar
evaluaciones de aseguramiento de la calidad del proceso y del
producto con la suficiente independencia y objetividad para
salvaguardarlo frente a la subjetividad o el prejuicio.
ELABORACIÓN de TS
El nombramiento de un líder o arquitecto jefe que supervise la
solución técnica y tenga autoridad sobre las decisiones de diseño,
ayuda a mantener la consistencia en el diseño y en la evolución
del producto.
Gp 2.5 foRmaR al peRsonal
FORMAR A LAS PERSONAS PARA rEALIZAR o DAR soporte AL proceso
según SEA NECESARIO.
El propósito de esta práctica genérica es asegurar que las

personas tengan las habilidades y la experiencia necesarias para
realizar o dar soporte al proceso.
Se imparte la formación apropiada a aquellos que vayan a
realizar el trabajo. Se proporciona formación general para orientar
a las personas que interactúan con aquellos que realizan el
trabajo.
Algunos ejemplos de métodos para proporcionar formación son el au-

toestudio; la auto formación dirigida; instrucción a su propio ritmo y pro-
gramada; formación en el puesto de trabajo; tutoría; y formación formal
en el aula.
La formación da soporte a la ejecución satisfactoria del pro-
ceso estableciendo una comprensión común del proceso e impar-
tiendo las habilidades y conocimientos necesarios para realizar el
proceso.
Para más información sobre el desarrollo de habilidades y conocimiento del
personal para que puedan realizar sus roles de forma eficaz y eficiente, consúl-
tese el área de proceso Formación en la Organización (OT).
ELABORACIÓN de CAR
Un ejemplo de tema de formación es:

• Métodos de gestión de calidad (p. ej., análisis de causas raíz).
ELABORACIÓN de CM
Algunos ejemplos de temas de formación son:

• Roles, responsabilidades y autoridad del personal de gestión de
configuración.
• Estándares, procedimientos y métodos de gestión de configuración.
• Sistema de bibliotecas de configuración.
ELABORACIÓN de DAR

• Análisis de decisión formal.
• Métodos para evaluar soluciones alternativas frente a los criterios.
ELABORACIÓN de IPM
GGS & GPS

• Adaptación del conjunto de procesos estándar de la organización para
cumplir las necesidades del proyecto.
• Gestión del proyecto en base al proceso definido del proyecto.
• Uso del repositorio de mediciones de la organización.
• Uso de los activos de proceso de la organización.
• Gestión integrada.
• Coordinación entre grupos.
• Resolución de problemas de grupo.
ELABORACIÓN de MA

• Técnicas estadísticas.
• Procesos de recogida de datos, de análisis y de elaboración de
informes.
• Desarrollo de mediciones relacionadas con objetivos (p. ej.,
GoalQuestionMetric).
ELABORACIÓN de OPD

• CMMI y otros procesos y modelos de referencia de mejora de procesos.
• Procesos de planificación, gestión y monitorización.
• Modelado y definición de procesos.
• Desarrollo de un proceso estándar adaptable.
• Desarrollo de estándares de entorno de trabajo.
• Ergonomía.
ELABORACIÓN de OPF

• CMMI y otros modelos de referencia de mejora de procesos.
• Planificación y gestión de la mejora de procesos.
• Herramientas, métodos y técnicas de análisis.
• Modelado de procesos.
• Técnicas de facilitación.
• Gestión del cambio.
ELABORACIÓN de OPM

• Análisis coste beneficio.
• Planificación, diseño y realización de pilotos.
• Transición de tecnología.
• Gestión del cambio.
ELABORACIÓN de OPP

• Modelado de procesos y de mejora de procesos.
• Métodos estadísticos y otros métodos cuantitativos (p. ej., modelos de
estimación, análisis de Pareto, diagramas de control).
ELABORACIÓN de OT

• Análisis de las necesidades de conocimiento y habilidades.
• Diseño de la formación.
• Técnicas de formación (p. ej., formación a formadores).
• Cursos de actualización sobre una materia específica.
ELABORACIÓN de PI

• Dominio de la aplicación.
• Procedimientos y criterios de integración del producto.
• Instalaciones de la organización para la integración y el ensamblaje.
• Métodos de ensamblaje.
• Estándares de empaquetado.
ELABORACIÓN de PMC

• Monitorización y control de proyectos.
• Gestión de riesgos.
• Gestión de datos.
ELABORACIÓN de PP
GGS & GPS

• Estimación.
• Elaboración de presupuestos.
• Negociación.
• Identificación y análisis de riesgos.
• Gestión de datos.
• Planificación.
• Elaboración de calendarios.

• Relaciones con el cliente.
• Descripciones de proceso, estándares, procedimientos y métodos para
el proyecto.
• Objetivos, descripciones de proceso, estándares, procedimientos,
métodos y herramientas de aseguramiento de la calidad.
ELABORACIÓN de QPM

• Análisis cuantitativo básico (incluyendo análisis estadístico) que
ayude a analizar el rendimiento del proceso, a usar datos históricos y a
identificar cuándo se justifica la acción correctiva.
• Análisis y modelado de procesos.
• Selección, definición y recogida de datos de medición del proceso.
ELABORACIÓN de RD

• Definición y análisis de requisitos.
• Educción de requisitos.
• Especificación y modelado de requisitos.
• Seguimiento de requisitos.

• Definición, análisis, revisión y gestión de requisitos.
• Herramientas de gestión de requisitos.
• Negociación y resolución de conflictos.

• Conceptos y actividades de gestión de riesgos (p. ej., identificación,
evaluación, monitorización, mitigación del riesgo).
• Selección de medidas para la mitigación del riesgo.
ELABORACIÓN de SAM

• Regulaciones y prácticas de negocio relacionadas con la negociación y
el trabajo con los proveedores.
• Planificación y preparación de la compra.
• Compra de productos COTS.
• Evaluación y selección de proveedores.
• Negociación y resolución de conflictos.
• Gestión de proveedores.
• Pruebas y transición de los productos adquiridos.
• Recepción, almacenamiento, uso y mantenimiento de los productos
adquiridos.
ELABORACIÓN de TS

• Dominio de aplicación del producto y de los componentes del
producto.
• Métodos de diseño.
• Métodos de arquitectura.
• Diseño de interfaces.
• Técnicas de pruebas unitarias.
• Estándares (p. ej., producto, seguridad, factores humanos, factores
ambientales).
ELABORACIÓN de VAL
GGS & GPS

• Principios, estándares y métodos de validación.
• Entorno de uso previsto.
ELABORACIÓN de VER

• Dominio de la aplicación o del servicio.
• Principios, estándares y métodos de verificación (p. ej., análisis,
demostración, inspección, pruebas).
• Herramientas e instalaciones de verificación.
• Preparación y procedimientos de revisiones entre pares.
• Facilitación de reuniones.
Gp 2.6 contRolaR los pRoductos de tRabajo

Poner los productos de trabajo seleccionados del proceso bajo los niveles de
control apropiados.
El propósito de esta práctica genérica es establecer y mantener la

integridad de los productos de trabajo seleccionados del proceso
(o de sus descripciones) a lo largo de su vida útil.
Los productos de trabajo seleccionados están específicamente
identificados en el plan de realización del proceso, junto con una
es- pecificación del nivel de control adecuado.
Pueden usarse distintos niveles de control para distintos
productos de trabajo y en momentos diferentes. Para algunos
productos de trabajo, puede ser suficiente mantener el control de
versiones para que la versión del producto de trabajo en uso en un
momento dado, pasado o presente, sea conocida, y los cambios
sean incorporados de una forma controlada. El control de
versiones está generalmente bajo el control exclusivo del
propietario del producto de trabajo (que puede ser un individuo,
grupo o equipo).
Algunas veces, puede ser crítico que los productos de trabajo
se pongan bajo gestión de configuración formal o de línea base.
Este tipo de control incluye la definición y el establecimiento de
líneas base en puntos predeterminados. Estas líneas base se
revisan y aprueban formalmente, y sirven como base para
desarrollos posteriores de los productos de trabajo designados.
PARA más INFORMACIÓN sobre cómo ESTABLECER y MANTENER LA INTEGRIDAD
de los productos de TRABAJO UTILIZANDO LA IDENTIFICACIÓN de LA
CONFIGURACIÓN,
el control de LA CONFIGURACIÓN, los informes de ESTADO de LA

CONFIGURACIÓN y LAS AUDITORÍAS de CONFIGURACIÓN, consúltese el árEA de
proceso Gestión de CONFIGURACIÓN (CM).
También son posibles otros niveles adicionales de control
entre el control de versiones y la gestión de configuración formal.
Un producto de trabajo identificado puede estar bajo diferentes
niveles de control en diferentes momentos.
ELABORACIÓN de CAR
Algunos ejemplos de productos de trabajo bajo control son:

• Propuestas de acción.
• Planes de acción.
• Registros de análisis causal y resolución.
ELABORACIÓN de CM

• Listas de acceso.
• Informes de estado de cambios.
• Base de datos de peticiones de cambio.
• Actas de reunión del CCB.
• Líneas base archivadas.
ELABORACIÓN de DAR

• Guías de cuándo aplicar un proceso de evaluación formal.
• Informes de evaluación que contienen soluciones recomendadas.
ELABORACIÓN de IPM

• El proceso definido del proyecto.
• Planes de proyecto.
• Otros planes que afectan al proyecto.
• Planes integrados.
• Mediciones del proceso y del producto reales recogidas del proyecto.
• Visión compartida del proyecto.
• Estructura del equipo.
• Estatutos del equipo.
ELABORACIÓN de MA
GGS & GPS

• Objetivos de medición.
• Especificaciones de medidas base y derivadas.
• Procedimientos de recogida y de almacenamiento de datos.
• Conjuntos de datos de medidas base y derivadas.
• Análisis de resultados e informes preliminares.
• Herramientas de análisis de datos.
ELABORACIÓN de OPD

• Conjunto de procesos estándar de la organización.
• Descripción de modelos de ciclo de vida.
• Guías de adaptación para el conjunto de procesos estándar de la
organización.
• Definiciones del conjunto común de medidas del producto y del
proceso.
• Datos de medidas de la organización.
• Reglas y guías para estructurar y crear equipos.
ELABORACIÓN de OPF

• Propuestas de mejora de procesos.
• Planes de acción aprobados de procesos de la organización.
• Materiales de formación utilizados para desplegar los activos de
proceso de la organización.
• Guías para desplegar el conjunto de procesos estándar de la
organización en nuevos proyectos.
• Planes para las evaluaciones de procesos de la organización.
ELABORACIÓN de OPM

• Lecciones aprendidas documentadas a partir de la validación de la
mejora.
• Planes de despliegue.
• Medidas, objetivos y prioridades de mejora modificados.
• Documentación del proceso y del material de formación actualizados.
ELABORACIÓN de OPP

• Objetivos de calidad y de rendimiento de procesos de la organización.
• Definiciones de las medidas seleccionadas de rendimiento de proceso.
• Datos de la línea base sobre el rendimiento de proceso de la
organización.
• Modelos de rendimiento de proceso.
ELABORACIÓN de OT

• Plan táctico de formación de la organización.
• Registros de formación.
• Materiales de formación y materiales de soporte.
• Formularios de evaluación del instructor.
ELABORACIÓN de PI

• Documentos de aceptación para los componentes del producto
recibidos.
• Productos y componentes de producto ensamblados evaluados.
• Estrategia de integración del producto.
• Procedimientos y criterios para la integración del producto.
• Descripciones o acuerdos de la interfaz actualizados.
ELABORACIÓN de PMC

• Calendario del proyecto actualizado.
• Datos y análisis de medición del proyecto.
• Informes de valor ganado.
ELABORACIÓN de PP

• Estructura de descomposición del trabajo.
• Plan de proyecto.
• Plan de gestión de datos.
• Plan para la involucración de las partes interesadas.
GGS & GPS

• Informes de no conformidades.
• Registros e informes de evaluación.
ELABORACIÓN de QPM

• Subprocesos a incluir en el proceso definido del proyecto.
• Definiciones operativas de las medidas, puntos de recogida en los
subprocesos y cómo se determinará la integridad de las medidas.
• Mediciones recogidas.
ELABORACIÓN de RD

• Requisitos funcionales y de atributos de calidad del cliente.
• Definición de la funcionalidad requerida y de los atributos de calidad.
• Requisitos de producto y de componentes de producto.
• Requisitos de interfaz.

• Requisitos.
• Matriz de trazabilidad de requisitos.

• Estrategia de gestión de riesgos.
• Elementos de riesgos identificados.
• Planes de mitigación de riesgos.
ELABORACIÓN de SAM

• Declaraciones del trabajo.
• Acuerdos con el proveedor.
• Memorándum del acuerdo.
• Subcontratos.
• Lista de proveedores preferentes.
ELABORACIÓN de TS

• Diseños de producto, de componente de producto y de interfaces.
• Paquetes de datos técnicos.
• Documentos de diseño de interfaces.
• Criterios para el diseño y reutilización de componentes de producto.
• Diseños implementados (p. ej., código software, componentes de
producto fabricados).
• Documentación de usuario, de instalación, de operación y de
mantenimiento.
ELABORACIÓN de VAL

• Lista de productos y de componentes de producto seleccionados para
la validación.
• Métodos, procedimientos y criterios de validación.
• Informes de validación.
ELABORACIÓN de VER

• Procedimientos y criterios de verificación.
• Material de formación de la revisión entre pares.
• Datos de la revisión entre pares.
• Informes de verificación.
Gp 2.7 identificaR e involucRaR a las paRtes inteResadas Relevantes

Identificar e involucrar a las partes interesadas relevantes del proceso, según
lo planificado.
El propósito de esta práctica genérica es establecer y mantener la
invo- lucración prevista de las partes interesadas relevantes
GGS & GPS

durante la eje- cución del proceso.
Involucre a las partes interesadas relevantes tal y como se
describe en un plan adecuado para la involucración de las partes
interesadas. Involucre a las partes interesadas de forma adecuada
en actividades tales como:
 Planificación.
 Decisiones.
 Compromisos.
 Comunicaciones.
 Coordinación.
 Revisiones.
 Evaluaciones.
 Definiciones de requisitos.
 Resolución de problemas y cuestiones.
PARA más INFORMACIÓN sobre LA PLANIFICACIÓN de LA INVOLUCRACIÓN de LAS PARTES

interESADAS, consúltese el árEA de proceso PLANIFICACIÓN del Proyecto.
El objetivo de planificar la involucración de las partes
interesadas es asegurar que se realizan las interacciones
necesarias al proceso, así como no permitir un número excesivo
de grupos e individuos afectados que impidan la ejecución del
proceso.
Algunos ejemplos de partes interesadas que podrían servir como partes

interesadas relevantes para tareas específicas son, dependiendo del
contexto, individuos, equipos, gerencia, clientes, proveedores, usuarios
finales, personal de operaciones y soporte, otros proyectos y organismos
reguladores gubernamentales
SUBPRÁCTICAS
1. Identificar a las partes interesadas relevantes a este proceso y la
invo- lucración apropiada.
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 la in- volucración en las
actividades del proceso.
2. Comunicar las partes interesadas relevantes identificadas a las
personas que planifican el proyecto y otros planes, según
proceda.
3. Involucrar a las partes interesadas relevantes según lo planificado.
ELABORACIÓN de CAR
Algunos ejemplos de actividades para la involucración de las partes inte-

resadas son:
• Llevar a cabo el análisis causal.
• Evaluar las propuestas de acción.
ELABORACIÓN de CM

resadas son:
• Establecer líneas base.
• Revisar los informes del sistema de gestión de configuración y resolver
las cuestiones.
• Evaluar el impacto de los cambios en los elementos de configuración.
• Realizar auditorías de configuración.
• Revisar los resultados de las auditorías de gestión de configuración.
ELABORACIÓN de DAR

resadas son:
• Establecer guías para determinar qué cuestiones están sujetas a un
proceso de evaluación formal.
• Definir la cuestión a tratar.
• Establecer criterios de evaluación.
• Identificar y evaluar alternativas.
• Seleccionar métodos de evaluación.
• Seleccionar soluciones.
ELABORACIÓN de IPM

resadas son:
• Resolver las cuestiones sobre la adaptación de los activos de proceso
de la organización.
• Resolver las cuestiones entre el plan de proyecto y otros planes que
afectan al proyecto.
• Revisar el rendimiento y el progreso del proyecto para alinearlo con las
necesidades, objetivos y requisitos actuales y previstos.
• Crear la visión compartida del proyecto.
• Definir la estructura del equipo para el proyecto.
• Establecer los equipos.
ELABORACIÓN de MA
GGS & GPS

resadas son:
• Establecer objetivos y procedimientos de medición.
• Evaluar los datos de la medición.
• Proporcionar realimentación significativa a aquellos que son
responsables de suministrar los datos sin procesar de los que
dependen el análisis y los resultados.
ELABORACIÓN de OPD

resadas son:
• Revisar el conjunto de procesos estándar de la organización.
• Revisar los modelos de ciclo de vida de la organización.
• Resolver las cuestiones relativas a las guías de adaptación.
• Evaluar las definiciones del conjunto común de medidas de proceso y
de producto.
• Revisar los estándares del entorno de trabajo.
• Establecer y mantener mecanismos de asignación de autoridad.
• Establecer y mantener reglas y guías de la organización para estructurar
y formar equipos.
ELABORACIÓN de OPF

resadas son:
• Coordinar y colaborar en las actividades de mejora de procesos con los
propietarios de los procesos, aquellos que están o estarán realizando
el proceso y con las organizaciones de soporte (p. ej., personal de
formación, representantes del aseguramiento de la calidad).
• Establecer las necesidades y objetivos de proceso de la organización.
• Evaluar los procesos de la organización.
• Implementar los planes de acción de procesos.
• Coordinar y colaborar en la realización de proyectos piloto para probar
las mejoras seleccionadas.
• Desplegar los activos de proceso de la organización y los cambios a los
activos de proceso de la organización.
• Comunicar los planes, el estado, las actividades y los resultados
relativos a la planificación, implementación y despliegue de las mejoras
de procesos.
ELABORACIÓN de OPM

resadas son:
• Revisar las propuestas de mejora que podrían contribuir a cumplir los
objetivos de negocio.
• Proporcionar realimentación a la organización sobre la disponibilidad,
estado y resultados de las actividades de despliegue de las mejoras.
La realimentación normalmente implica:

• Informar al personal que envía propuestas de mejora del estado de las
mismas.
• Comunicar regularmente los resultados de comparar el rendimiento del
negocio frente a los objetivos de negocio.
• Informar regularmente a las partes interesadas relevantes sobre los
planes y el estado de la selección y despliegue de las mejoras.
• Preparar y distribuir un resumen de las actividades de selección y
despliegue de la mejora.
ELABORACIÓN de OPP

resadas son:
• Establecer los objetivos de calidad y de rendimiento de proceso de la
organización y sus prioridades.
• Revisar y resolver las cuestiones sobre las líneas base de rendimiento
de los procesos de la organización.
• Revisar y resolver las cuestiones sobre los modelos de rendimiento de
ELABORACIÓN de OT

resadas son:
• Establecer un entorno de colaboración para el análisis de las
necesidades y la eficacia de la formación para asegurar que se cumplen
las necesidades de formación de la organización.
• Identificar las necesidades de formación.
• Revisar el plan táctico de formación de la organización.
• Evaluar la eficacia de la formación.
ELABORACIÓN de PI
GGS & GPS

resadas son:
• Establecer la estrategia de integración del producto.
• Revisar que las descripciones de interfaz están completas.
• Establecer los procedimientos y los criterios para la integración del producto.
• Ensamblar y entregar el producto y los componentes del producto.
• Comunicar los resultados después de la evaluación.
• Comunicar los nuevos y eficaces procesos de integración del producto para
que las personas afectadas tengan la oportunidad de mejorar su rendimiento.
ELABORACIÓN de PMC

resadas son:
• Evaluar el proyecto frente al plan.
• Revisar los compromisos y resolver las cuestiones.
• Revisar los riesgos del proyecto.
• Revisar las actividades de gestión de datos.
• Revisar el progreso del proyecto.
• Gestionar las acciones correctivas hasta su cierre.
ELABORACIÓN de PP

resadas son:
• Establecer estimaciones.
• Revisar y resolver las cuestiones sobre la completitud y exactitud de los
riesgos del proyecto.
• Revisar los planes de gestión de datos.
• Establecer los planes del proyecto.
• Revisar los planes del proyecto y resolver las cuestiones de trabajo y de
recursos.

resadas son:
• Establecer los criterios para las evaluaciones objetivas de procesos y de
productos de trabajo.
• Evaluar los procesos y los productos de trabajo.
• Resolver las no conformidades.
• Seguir las no conformidades hasta su cierre.
ELABORACIÓN de QPM

resadas son:
• Establecer los objetivos del proyecto.
• Resolver las cuestiones entre los objetivos de calidad y de rendimiento
de proceso en el proyecto.
• Seleccionar las técnicas analíticas a utilizar.
• Evaluar el rendimiento del proceso de los subprocesos seleccionados.
• Identificar y gestionar los riesgos para alcanzar los objetivos de calidad
y de rendimiento de proceso en el proyecto.
• Identificar las acciones correctivas que deberían tomarse.
ELABORACIÓN de RD

resadas son:
• Revisar la adecuación de los requisitos para cumplir las necesidades,
las expectativas, las restricciones y las interfaces.
• Establecer los conceptos operativos y los escenarios operativos, de apoyo
y de desarrollo.
• Evaluar la adecuación de los requisitos.
• Priorizar los requisitos de cliente.
• Establecer los requisitos funcionales y los atributos de calidad del
producto y de los componentes de producto.
• Evaluar el coste, el calendario y los riesgos del producto.

resadas son:
• Resolver las cuestiones sobre la comprensión de los requisitos.
• Evaluar el impacto de los cambios a los requisitos.
• Comunicar la trazabilidad bidireccional.
• Identificar las inconsistencias entre requisitos, planes del proyecto y

resadas son:
• Establecer un entorno colaborativo para el debate libre y abierto de los riesgos.
• Revisar la estrategia de gestión de riesgos y los planes de mitigación de riesgos.
• Participar en las actividades de identificación, análisis y mitigación de riesgos.
• Comunicar e informar del estado de la gestión de riesgos.
ELABORACIÓN de SAM
GGS & GPS

resadas son:
• Establecer criterios para la evaluación de proveedores potenciales.
• Revisar los proveedores potenciales.
• Establecer los acuerdos con proveedores.
• Resolver las cuestiones con proveedores.
• Revisar el rendimiento del proveedor.
ELABORACIÓN de TS

resadas son:
• Desarrollar soluciones alternativas y criterios de selección.
• Obtener la aprobación de las especificaciones de las interfaces
externas y de las descripciones de diseño.
• Desarrollar el paquete de datos técnicos.
• Evaluar las alternativas de desarrollar, comprar o reutilizar
componentes del producto.
• Implementar el diseño.
ELABORACIÓN de VAL

resadas son:
• Seleccionar los productos y los componentes de producto a validar.
• Establecer los métodos, procedimientos y criterios de validación.
• Revisar los resultados de la validación del producto y del componente
de producto y resolver las cuestiones.
• Resolver las cuestiones con los clientes o usuarios finales.
Las cuestiones con los clientes o con los usuarios finales se resuelven
particularmente cuando existen desviaciones significativas respecto
a las necesidades establecidas en la línea base. Algunos ejemplos de
resoluciones son:
• Exenciones sobre el contrato o el acuerdo (qué, cuándo y para qué
productos).
• Estudios en profundidad, ensayos, pruebas o evaluaciones adicionales.
• Posibles cambios en los contratos o acuerdos.
ELABORACIÓN de VER

resadas son:
• Seleccionar productos de trabajo y métodos de verificación.
• Establecer procedimientos y criterios de verificación.
• Llevar a cabo revisiones entre pares.
• Evaluar los resultados de la verificación e identificar las acciones
correctivas.
Gp 2.8 monitoRizaR y contRolaR el pRoceso

Monitorizar y controlar el proceso frente al plan para realizar el proceso y tomar
las acciones correctivas apropiadas.
El propósito de esta práctica genérica es realizar la monitorización

y el control directo del proceso día a día. Se mantiene una
visibilidad apropiada del proceso, de forma que se puedan tomar
las acciones correctivas apropiadas cuando sea necesario. La
monitorización y control del proceso puede implicar medir los
atributos apropiados del proceso o de los productos de trabajo
producidos por el proceso.
PARA más INFORMACIÓN sobre cómo DESARrOLLAR y MANTENER UNA CAPACIDAD de me-
dición UTILIZADA PARA DAR soporte A LAS NECESIDADES de INFORMACIÓN de LA gestión,
consúltese el árEA de proceso Medición y Análisis.
PArA más informAción sobre cómo proporcionAr unA comprensión del progre-
so del proyecto de modo que puedAn tomArse Acciones correctivAS ApropiAdAS
cuAndo el rendimiento del proyecto se desvíA SignificAtivAmente del plAn, con-
súltese el áreA de proceso MonitorizAción y Control del Proyecto.
SUBPRÁCTICAS
1. Evaluar el progreso y el rendimiento reales frente al plan de
realiza- ción del proceso.
Las evaluaciones se hacen sobre el proceso, sus productos de
trabajo y sus servicios.
2. Revisar los logros y los resultados del proceso frente al plan de
reali- zación del proceso.
3. Revisar las actividades, el estado y los resultados del proceso
con el nivel de gerencia más cercano al responsable del proceso e
identificar las cuestiones.
Estas revisiones pretenden proporcionar al nivel de gerencia más
cercano la visibilidad apropiada del proceso a través de la
monitorización y el control diario del mismo, y se complementa
con revisiones perió- dicas y puntuales con el nivel directivo
como se describe en GP 2.10.
4. Identificar y evaluar los efectos de las desviaciones significativas
del plan de realización del proceso.
GGS & GPS

5. Identificar los problemas en el plan de realización del proceso y
en la ejecución del proceso.
6. Tomar acciones correctivas cuando no se satisfacen los
requisitos y los objetivos, cuando se identifican las cuestiones o
cuando el progreso difiere significativamente del plan de
realización del proceso.
Se deberían considerar los riesgos inherentes antes de que se
tome cualquier acción correctiva.
Una acción correctiva puede ser:

• Tomar acciones para corregir los productos de trabajo o los servicios
defectuosos.
• Cambiar el plan de realización del proceso.
• Ajustar los recursos incluyendo personas, herramientas y otros
recursos.
• Negociar los cambios a los compromisos establecidos.
• Asegurar el cambio a los requisitos y a los objetivos que deben
satisfacerse.
• Interrumpir el esfuerzo.
7. Seguir las acciones correctivas hasta su cierre.
ELABORACIÓN de CAR
Algunos ejemplos de medidas y de productos de trabajo utilizados en la

monitorización y control son:
• Número de resultados analizados.
• Cambio en la calidad o en el rendimiento del proceso por cada
instancia del proceso de análisis causal y resolución.
• Calendario de actividades para implementar una propuesta de acción
seleccionada.
ELABORACIÓN de CM

• Número de cambios a los elementos de configuración.
• Número de auditorías de configuración realizadas.
• Calendario de las actividades del CCB o de auditoría.
ELABORACIÓN de DAR

• Relación coste-beneficio de los procesos de evaluación formal
utilizados.
• Calendario para la ejecución de un estudio de mercado.
ELABORACIÓN de IPM

• Número de cambios al proceso definido del proyecto.
• Calendario y esfuerzo para adaptar el conjunto de procesos estándar
• Tendencias en las cuestiones de coordinación de interfaces (p. ej.,
número de cuestiones identificadas y número de cerradas).
• Calendario de las actividades de adaptación del proyecto.
• Uso y eficacia de la visión compartida del proyecto.
• Uso y eficacia de la estructura del equipo.
• Uso y eficacia de la misión del equipo.
ELABORACIÓN de MA

• Porcentaje de proyectos que usan medidas de progreso y de
rendimiento.
• Porcentaje de objetivos de medición tratados.
• Calendario de recogida y revisión de los datos de medición.
ELABORACIÓN de OPD

• Porcentaje de proyectos que usan las arquitecturas de proceso
y elementos de proceso del conjunto de procesos estándar de la
organización.
• Densidad de defectos de cada elemento de proceso del conjunto de
• Calendario de desarrollo de un proceso o cambio de proceso.
ELABORACIÓN de OPF
GGS & GPS

• Número de propuestas de mejora de procesos remitidas, aceptadas o
implementadas.
• Nivel de madurez o nivel de capacidad de CMMI conseguido.
• Calendario de despliegue de un activo de proceso de la organización.
• Porcentaje de proyectos que usan el conjunto actual de procesos
estándar de la organización (o versión adaptada del conjunto actual).
• Tendencias de cuestiones asociadas con la implementación del
conjunto de procesos estándar de la organización (es decir, número de
cuestiones identificadas, número de cerradas).
• Progreso hacia la consecución de las necesidades y objetivos del proceso.
ELABORACIÓN de OPM

• Cambio en la calidad y en el rendimiento de proceso en relación con los
objetivos de negocio.
• Calendario para implementar y validar una mejora.
• Calendario de las actividades para desplegar una mejora seleccionada.
ELABORACIÓN de OPP

• Tendencias en el rendimiento de los procesos de la organización
respecto a los cambios en los atributos de productos de trabajo y de
tarea (p. ej. aumento de tamaño, esfuerzo, calendario, calidad).
• Calendario de recogida y revisión de las medidas que se deben utilizar
para establecer una línea base de rendimiento de proceso.
ELABORACIÓN de OT

• Número de cursos de formación impartidos (p. ej., planificado frente a real).
• Calificaciones de evaluación posteriores a la formación.
• Calificaciones de las encuestas sobre la calidad del programa de formación.
• Calendario de impartición de formación.
• Calendario del desarrollo de un curso.
ELABORACIÓN de PI

• Perfil de la integración de componentes del producto (p. ej.,
componentes del producto ensamblados planificados y realizados,
número de excepciones encontradas).
• Tendencias de informes de problemas de evaluación de la integración
(p. ej., número de informes emitidos y número de cerrados).
• Antigüedad de los informes de problemas de evaluación de la
integración (es decir, cuánto tiempo ha estado abierto cada informe de
problemas).
• Calendario para la realización de actividades de integración específicas.
ELABORACIÓN de PMC
Algunos ejemplos de medidas y productos de trabajo utilizados en la moni-

torización y control son:
• Número de acciones correctivas abiertas y cerradas.
• Calendario con el estado de la recogida mensual de los datos
financieros, análisis e informes.
• Número y tipos de revisiones realizadas.
• Calendario de revisiones (fechas planificadas frente a reales y
replanificaciones de fechas objetivo).
• Calendario de recogida y análisis de los datos de monitorización.
ELABORACIÓN de PP

• Número de revisiones al plan.
• Variación de coste, calendario y esfuerzo por cada modificación del plan.
• Calendario para el desarrollo y mantenimiento de los planes del programa.

• Diferencia entre las evaluaciones objetivas del proceso planificadas y
realizadas.
• Diferencia entre las evaluaciones objetivas de producto de trabajo
planificadas y realizadas.
• Calendario de las evaluaciones objetivas.
ELABORACIÓN de QPM
GGS & GPS

• Perfil de los atributos de los subprocesos cuyo rendimiento de proceso
proporcione una visión sobre el riesgo para, o que contribuyan
significativamente para, alcanzar los objetivos del proyecto (p. ej.,
número de atributos para monitorizar mediante técnicas estadísticas,
número de atributos que actualmente está siendo monitorizado,
número de atributos cuyo rendimiento de proceso es estable).
• Número de causas especiales de variación identificadas.
• Calendario de actividades de recogida de datos, análisis e informes
en un ciclo de medición y análisis relativo a las actividades de gestión
cuantitativa.
ELABORACIÓN de RD

• Coste, calendario y esfuerzo empleado en retrabajo.
• Densidad de defectos de las especificaciones de requisitos.
• Calendario de actividades para desarrollar un conjunto de requisitos.

• Volatilidad de los requisitos (porcentaje de requisitos modificados).
• Calendario de coordinación de los requisitos.
• Calendario para el análisis de un cambio propuesto a los requisitos.

• Número de riesgos identificados, gestionados, seguidos y controlados.
• Exposición al riesgo y sus cambios para cada riesgo evaluado, asi como
un porcentaje de la reserva de gestión.
• Cambios en los planes de mitigación de riesgos (p.ej., procesos,
calendario, financiación).
Continúa
Continuación
• Ocurrencia de riesgos no previstos.
• Volatilidad de la clasificación del riesgo.
• Comparación del esfuerzo e impacto de la mitigación de riesgos
estimados frente a los reales.
• Calendario de las actividades de análisis de riesgos.
• Calendario de acciones para mitigar un riesgo.
ELABORACIÓN de SAM

• Número de cambios realizados a los requisitos para el proveedor.
• Diferencia en coste y plazos respecto al acuerdo con el proveedor.
• Calendario para seleccionar un proveedor y establecer un acuerdo.
ELABORACIÓN de TS

• Coste, calendario y esfuerzo empleado en retrabajo.
• Porcentaje de requisitos abordados en el diseño del producto o del
• Tamaño y complejidad del producto, de los componentes de producto,
de las interfaces y de la documentación.
• Densidad de defectos de las soluciones técnicas de los productos de
trabajo.
• Calendario de las actividades de diseño.
ELABORACIÓN de VAL

• Número de actividades de validación finalizadas (planificadas frente a
reales).
• Tendencias de informes de problemas de validación (p. ej., número de
informes abiertos, número de cerrados).
• Antigüedad del informe de problemas de validación (es decir, cuánto
tiempo ha estado abierto cada informe de problema).
• Calendario de una actividad de validación específica.
ELABORACIÓN de VER
GGS & GPS

• Perfil de verificación (p. ej., número de verificaciones planificadas y
realizadas, y defectos encontrados; o defectos categorizados por el
método o tipo de verificación).
• Número de defectos detectados por categoría de defecto.
• Tendencias de informes de problemas de verificación (p. ej., número de
informes abiertos, número de cerrados).
• Estado de los informes de problemas de verificación (es decir, cuánto
tiempo ha estado abierto cada uno de los informes de problemas).
• Calendario de una actividad de verificación específica.
• Eficacia de las revisiones entre pares.
Gp 2.9 evaluaR objetivamente la adheRencia

Evaluar objetivamente la adherencia del proceso y de los productos de trabajo
seleccionados frente a la descripción del proceso, estándares y procedimien-
tos, y tratar las no conformidades.
El propósito de esta práctica genérica es proporcionar un
aseguramien- to creíble de que el proceso y los productos de
trabajo seleccionados se implementaron como estaban
planificados y se adhieren a la descrip- ción de proceso,
estándares y procedimientos (véase la definición de “evaluar
objetivamente” en el glosario).
PARA más INFORMACIÓN sobre LA EVALUACIÓN OBJETIVA de procesos y de productos de
TRABAJO, consúltese el árEA de proceso ASEGURAMIENTO de LA CALIDAD del Proceso y
del Producto.
Normalmente, las personas que no son directamente responsables
de gestionar o realizar las actividades del proceso, evalúan la
adherencia. En muchos casos, la adherencia se evalúa por personas de
la organización, pero externas al proceso o al proyecto, o por personas
externas a la organización. Como resultado, el aseguramiento creíble
de la adherencia se puede proporcionar incluso en los periodos en los
que el proceso se encuentra bajo pre- sión (p. ej., cuando está
retrasado o cuando el presupuesto se ha superado).
ELABORACIÓN de CAR
Algunos ejemplos de actividades revisadas son:

• Determinar las causas de los resultados.
• Evaluar los resultados de los planes de acción.
Algunos ejemplos de productos de trabajo revisados son:

• Propuestas de acción seleccionadas para su implementación.
• Registros del análisis causal y resolución.
ELABORACIÓN de CM

• Establecer las líneas base.
• Seguir y controlar los cambios.
• Establecer y mantener la integridad de las líneas base.

• Archivos de líneas base.
• Base de datos de peticiones de cambio.
ELABORACIÓN de DAR

• Evaluación de alternativas utilizando los criterios y métodos
establecidos.

• Guías de cuándo aplicar un proceso de evaluación formal.
• Informes de evaluación que contengan las soluciones
recomendadas.
ELABORACIÓN de IPM

• Establecer, mantener y utilizar el proceso definido del proyecto.
• Coordinar y colaborar con las partes interesadas relevantes.
• Utilizar la visión compartida del proyecto.
• Organizar los equipos.

• Proceso definido del proyecto.
• Planes del proyecto.
• Otros planes que afectan al proyecto.
• Estándares del entorno de trabajo.
• Declaraciones de la visión compartida.
• Estructura del equipo.
ELABORACIÓN de MA
GGS & GPS

• Alinear las actividades de medición y análisis.
• Proporcionar resultados de la medición.

• Especificaciones de medidas base y derivadas.
• Procedimientos de recogida y almacenamiento de datos.
• Análisis de resultados e informes preliminares.
ELABORACIÓN de OPD

• Establecer los activos de proceso de la organización.
• Determinar las reglas y guías para estructurar y formar equipos.

• Conjunto de procesos estándar de la organización.
• Descripción de los modelos de ciclo de vida.
• Guías de adaptación para el conjunto de procesos estándar de la
organización.
• Datos de medición de la organización.
• Reglas y guías de asignación de autoridad para las personas y
equipos.
• Documentación de procesos de la organización.
ELABORACIÓN de OPF

• Determinar las oportunidades de mejora de procesos.
• Planificar y coordinar las actividades de mejora de procesos.
• Desplegar el conjunto de procesos estándar de la organización al inicio
de los proyectos.

• Planes de mejora de procesos.
• Planes de acción de procesos.
• Planes de despliegue de procesos.
• Planes para las evaluaciones de proceso de la organización.
ELABORACIÓN de OPM

• Analizar los datos de rendimiento de proceso para determinar la
capacidad de la organización para cumplir los objetivos de negocio
identificados.
• Seleccionar mejoras utilizando el análisis cuantitativo.
• Desplegar las mejoras.
• Medir la eficacia de las mejoras desplegadas utilizando técnicas
estadísticas y otras técnicas cuantitativas.

• Propuestas de mejora.
• Planes de despliegue.
• Medidas, objetivos, prioridades y planes de despliegue de mejora
modificados.
• Documentación de proceso y material de formación actualizados.
ELABORACIÓN de OPP

• Establecer líneas base y modelos de rendimiento de proceso.

• Líneas base del rendimiento de procesos.
• Objetivos de calidad y de rendimiento de proceso de la organización.
• Definiciones de las medidas seleccionadas de rendimiento de
proceso.
ELABORACIÓN de OT

• Identificar las necesidades de formación y hacer que la formación esté
disponible.
• Proporcionar la formación necesaria.

• Plan táctico de formación de la organización.
• Materiales de formación y de soporte.
• Formularios de evaluación del instructor.
ELABORACIÓN de PI
GGS & GPS

• Establecer y mantener una estrategia de integración del producto.
• Asegurar la compatibilidad de las interfaces.
• Ensamblar los componentes de producto y entregar el producto.

• Estrategia de integración del producto.
• Procedimientos y criterios de integración del producto.
• Documentos de aceptación de los componentes de producto
recibidos.
• Producto y componentes de producto ensamblados.
ELABORACIÓN de PMC

• Monitorizar el progreso y el rendimiento del proyecto frente al plan de
proyecto.
• Gestionar las acciones correctivas hasta su cierre.

• Registros de progreso y de rendimiento del proyecto.
• Resultados de las revisiones del proyecto.
ELABORACIÓN de PP

• Establecer estimaciones.
• Desarrollar el plan de proyecto.
• Obtener los compromisos para el plan de proyecto.

• WBS.
• Plan de proyecto.
• Plan de gestión de datos.
• Plan de involucración de las partes interesadas.

• Evaluar objetivamente los procesos y los productos de trabajo.
• Seguir y comunicar las no conformidades.

• Informes de no conformidad.
• Registros e informes de evaluación.
ELABORACIÓN de QPM

• Gestionar el proyecto utilizando los objetivos de calidad y de rendimiento
de proceso.
• Gestionar los subprocesos seleccionados utilizando técnicas

• Composiciones del proceso definido del proyecto.
• Definiciones operativas de las medidas.
• Informes de análisis del rendimiento de proceso.
• Medidas recogidas.
ELABORACIÓN de RD

• Recoger las necesidades de las partes interesadas.
• Formular los requisitos funcionales y de atributos de calidad del
producto y de componentes de producto.
• Formular los requisitos de la arquitectura que especifiquen cómo
se organizan y diseñan los componentes de producto para lograr los
requisitos particulares del primero al último, tanto funcionales como de
atributos de calidad.
• Analizar y validar los requisitos del producto y de componentes de producto.

• Requisitos de producto.
• Requisitos de componentes de producto.
• Requisitos de interfaz.
• Definición de la funcionalidad y de los atributos de calidad requeridos.
• Requisitos de atributos de calidad significativos desde el punto de la
arquitectura.
GGS & GPS

• Gestionar los requisitos.
• Asegurar que los planes, los productos de trabajo y los requisitos del
proyecto estan alineados.

• Requisitos.

• Establecer y mantener una estrategia de gestión de riesgos.
• Identificar y analizar los riesgos.
• Mitigar los riesgos.

• Estrategia de gestión de riesgos.
• Planes de mitigación de riesgos.
ELABORACIÓN de SAM

• Establecer y mantener acuerdos con el proveedor.
• Satisfacer los acuerdos del proveedor.

• Plan para la gestión de acuerdos con proveedores.
• Acuerdos con el proveedor.
ELABORACIÓN de TS

• Seleccionar las soluciones de componente de producto.
• Desarrollar los diseños del producto y de componente de producto.
• Implementar los diseños de componente de producto.

• Paquetes de datos técnicos.
• Diseños de producto, de componentes de producto y de interfaz.
• Diseños implementados (p. ej., código software, componente de
productos fabricados).
• Documentación de usuario, de instalación, de operación y de
mantenimiento.
ELABORACIÓN de VAL

• Seleccionar los productos y los componentes de producto a validar.
• Establecer y mantener los métodos, los procedimientos y los criterios
de validación.
• Validar los productos o los componentes de producto.

• Métodos de validación.
• Procedimientos de validación.
• Criterios de validación.
ELABORACIÓN de VER

• Seleccionar los productos de trabajo para la verificación.
• Establecer y mantener procedimientos y criterios de verificación.
• Realizar las revisiones entre pares.
• Verificar los productos de trabajo seleccionados.

• Procedimientos y criterios de verificación.
• Listas de comprobación de revisiones entre partes.
• Informes de verificación.
Gp 2.10 RevisaR el estado con el nivel diRectivo

Revisar con el nivel directivo las actividades, el estado y los resultados del pro-
ceso y resolver las cuestiones.
El propósito de esta práctica genérica es proporcionar la

visibilidad apropiada del proceso al nivel directivo.
El nivel directivo incluye a aquellos niveles de gerencia en la
or- ganización situados inmediatamente por encima del nivel de
GGS & GPS

gerencia responsable del proceso. En particular, el nivel
directivo puede incluir a la alta dirección. Estas revisiones son
para los directores que proporcionan la política y la orientación
global del proceso, y no para los que realizan directamente la
monitorización y el control diario del proceso.
Diferentes directores tienen diferentes necesidades de
información sobre el proceso. Estas revisiones ayudan a asegurar
que se pueden tomar decisiones informadas sobre la planificación
y la realización del proceso. Por tanto, se espera que estas
revisiones sean tanto periódicas como puntuales.
ELABORACIÓN de OPF
Normalmente estas revisiones las presenta el grupo de procesos y
los equipos de acción de procesos como una presentación
ejecutiva al co- mité de dirección.
Algunos ejemplos de temas de la presentación son:

• Estado de las mejoras que están siendo desarrolladas por los equipos
de acción de procesos.
• Resultados de los proyectos piloto.
• Resultados de los despliegues.
• Estado del calendario para conseguir los hitos significativos (p. ej.,
disponibilidad para una evaluación, progreso para alcanzar un nivel de
madurez o un perfil de nivel de capacidad objetivo).
ELABORACIÓN de OPM
Normalmente estas revisiones las presentan los responsables de
la mejora de rendimiento como una presentación ejecutiva al
nivel directivo.
Algunos ejemplos de los temas de la presentación son:

• Áreas de mejora identificadas a partir del análisis de rendimiento
actual comparado con los objetivos de negocio.
• Resultados de las actividades de educción y de análisis de mejora de
procesos.
• Resultados a partir de las actividades de validación (p. ej., proyectos
piloto) comparados con los beneficios esperados.
• Datos de rendimiento posteriores al despliegue de las mejoras.
• Coste, calendario y riesgos del despliegue.
• Riesgos de no conseguir los objetivos de negocio.
Se revisan con el nivel directivo los cambios propuestos a los
compromisos que son externos a la organización para asegurar
que todos los compromisos se pueden cumplir.
Las revisiones del estado de los riesgos del proyecto se mantienen
pe- riódica y puntualmente, con los niveles apropiados de
gestión, para proporcionar visibilidad en la exposición al riesgo del
proyecto y en las acciones correctivas apropiadas.
Normalmente, estas revisiones incluyen un resumen de los
riesgos más críticos, los parámetros clave de riesgo (tales como
probabilidad y consecuencia de los riesgos), y el estado de los
esfuerzos de la miti- gación de los riesgos.
GG 3 i nstitucionaLizar un proceso definido

El proceso está institucionalizado como un proceso definido.
Gp 3.1 estableceR un pRoceso definido

Establecer y mantener la descripción de un proceso definido.
El propósito de esta práctica genérica es establecer y mantener

una descripción del proceso que se adapte a partir del conjunto
de procesos estándar de la organización para tratar las
necesidades de una ins- tanciación específica. La organización
debería tener procesos estándar que cubran el área de proceso, así
como guías de adaptación de estos procesos estándar para
cumplir con las necesidades de un proyecto o de una función de
la organización. Con un proceso definido, se reduce la
variabilidad en la forma que se realizan los procesos en la
organiza- ción y pueden compartirse de forma eficaz los activos
de proceso, los datos y el aprendizaje.
PARA más INFORMACIÓN sobre cómo ESTABLECER el proceso definido del proyecto,
consúltese el árEA de proceso Gestión INTEGRADA del Proyecto.
PARA más INFORMACIÓN sobre cómo ESTABLECER los procesos ESTÁNDAR y los criterios
y GUÍAS de ADAPTACIÓN, consúltese el árEA de proceso Definición de Procesos de LA
OrGANIZACIÓN.
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.
SUBPRÁCTICAS
1. Seleccionar del conjunto de procesos estándar de la
organización aquellos procesos que cubran el área de proceso y
que mejor satisfagan las necesidades del proyecto o función de
la organización.
2. Establecer el proceso definido adaptando los procesos
seleccionados de acuerdo con las guías de adaptación de la
GGS & GPS

organización.
3. Asegurar que los objetivos del proceso de la organización se
tratan de forma apropiada en el proceso definido.
4. Documentar el proceso definido y los registros de la adaptación.
5. Modificar la descripción del proceso definido según sea necesario.
Gp 3.2 R ecogeR expeRiencias Relativas al pRoceso

Recoger experiencias relativas al proceso procedentes de la planificación y rea-
lización del proceso para dar soporte al uso futuro y a la mejora de los procesos
y de los activos de proceso de la organización.
El propósito de esta práctica genérica consiste en recoger

experiencias relativas al proceso, incluyendo información y
artefactos derivados de la planificación y realización del
proceso. Algunos ejemplos de experiencias relativas al proceso
son productos de trabajo, medidas, resultados de la medición,
lecciones aprendidas y sugerencias de mejora de procesos. La
información y los artefactos se recogen para que puedan incluirse
en los activos de proceso de la organización y que se encuentren
disponibles para aquéllos que estén planificando (o vayan a estar)
y realizando procesos idénticos o similares. La in- formación y
los artefactos se almacenan en el repositorio de mediciones de
la organización y en la biblioteca de activos de proceso de la
organización.
Algunos ejemplos de información relevante son: esfuerzo empleado en

diversas actividades, defectos introducidos o eliminados en una actividad
particular y lecciones aprendidas.
PArA más informAción sobre cómo contribuir A los Activos de proceso de lA OrgA-
nizAción, consúltese el áreA de proceso Gestión IntegrAdA del Proyecto.
PArA más informAción sobre cómo estAblecer los Activos de proceso de lA
orgAnizAción, consúltese el áreA de proceso Definición de Procesos de lA
OrgAnizAción.
SUBPRÁCTICAS
1. Almacenar medidas del proceso y del producto en el repositorio
de mediciones de la organización.
Las medidas del proceso y del producto son básicamente aquellas
medidas que se definen en el conjunto común de medidas del
conjunto de procesos estándar de la organización.
2. Remitir la documentación para su inclusión en la biblioteca de
activos de proceso de la organización.
3. Documentar las lecciones aprendidas del proceso para su
inclusión en la biblioteca de activos de proceso de la
organización.
4. Proponer mejoras a los activos de proceso de la organización.
ELABORACIÓN de CAR
Algunos ejemplos de experiencias relativas al proceso son:

• Propuestas de acción.
• Número de planes de acción que están abiertos y su antigüedad.
• Informes del estado del plan de acción.
ELABORACIÓN de CM

• Tendencias del estado de los elementos de configuración.
• Resultados de las auditorías de configuración.
• Informes de antigüedad de las peticiones de cambio.
ELABORACIÓN de DAR

• Número de alternativas consideradas.
• Resultados de la evaluación.
• Soluciones recomendadas para tratar las cuestiones significativas.
ELABORACIÓN de IPM

• Proceso definido del proyecto.
• Número de opciones de adaptación utilizadas por el proyecto para
crear su proceso definido.
• Tendencias en las cuestiones de coordinación de interfaces (p.ej.,
número cuestiones identificadas, número de cerradas).
• Número de veces que el personal del proyecto accede a la biblioteca
de activos de proceso para buscar activos relacionados con la
planificación del proyecto.
• Los registros de gastos asociados a la realización de reuniones
presenciales frente a los de la realización de reuniones que utilizan
equipamiento de colaboración tales como teleconferencia y
vídeoconferencia.
• Visión compartida del proyecto.
ELABORACIÓN de MA
GGS & GPS

• Estado actual de los datos.
• Resultados de las pruebas de integridad de los datos.
• Informes de análisis de datos.
ELABORACIÓN de OPD

• Incorporación de las lecciones aprendidas a la biblioteca de activos de
• Incorporación de las medidas al repositorio de mediciones de la
organización.
• Estado de las peticiones de cambio remitidas para modificar los
• Registro de las peticiones de adaptación no estándar.
ELABORACIÓN de OPF

• Criterios utilizados para priorizar las mejoras de procesos
candidatas.
• Hallazgos de la evaluación que tratan las fortalezas y las debilidades de
los procesos de la organización.
• Estado de las actividades de mejora frente al calendario.
• Registros de la adaptación del conjunto de procesos estándar
de la organización y de su implementación en los proyectos
identificados.
ELABORACIÓN de OPM

• Lecciones aprendidas obtenidas a partir del análisis de los datos del
rendimiento de proceso frente a los objetivos de negocio.
• Medidas documentadas de los costes y beneficios resultantes de la
implementación y despliegue de las mejoras.
• Informe de una comparación de procesos de desarrollo similares para
identificar el potencial para mejorar la eficiencia.
ELABORACIÓN de OPP

• Líneas base de rendimiento de proceso.
• Porcentaje de datos de medición que se rechazan a causa de
inconsistencias con las definiciones de medición del rendimiento de
proceso.
ELABORACIÓN de OT

• Resultados de encuestas sobre la eficacia de la formación.
• Resultados de la evaluación del rendimiento del programa de formación.
• Evaluaciones del curso.
• Requisitos de formación proporcionados por un grupo asesor.
ELABORACIÓN de PI

• Registros de recepción de los componentes de producto, informes de
excepciones, confirmación del estado de la configuración y resultados
de comprobación de la disponibilidad.
• Porcentaje de esfuerzo de desarrollo total invertido en la integración del
producto (lo real hasta la fecha más la estimación hasta la finalización).
• Defectos encontrados en el producto y en el entorno de pruebas
durante la integración del producto.
• Informes de problemas resultantes de la integración del producto.
ELABORACIÓN de PMC

• Registros de desviaciones significativas.
• Criterios para determinar qué constituye una desviación.
• Resultados de acciones correctivas.
ELABORACIÓN de PP

• Estructura de la biblioteca de datos del proyecto.
• Estimaciones de los atributos del proyecto.
• Impactos de los riesgos y probabilidad de ocurrencia.
GGS & GPS

• Registros de evaluación.
• Tendencias de calidad.
• Informes de no conformidad.
• Informes de estado de acciones correctivas.
• Informes del coste de la calidad del proyecto.
ELABORACIÓN de QPM

• Registros de datos cuantitativos de gestión del proyecto, incluyendo
los resultados de la revisión periódica del rendimiento del proceso de
los subprocesos seleccionados para la gestión frente a los objetivos
intermedios establecidos del proyecto.
• Mejoras sugeridas a los modelos de rendimiento de procesos.
ELABORACIÓN de RD

• Lista de requisitos de un producto que se han identificado como
ambiguos.
• Número de requisitos introducidos en cada fase del ciclo de vida del
proyecto.
• Lecciones aprendidas del proceso de asignación de requisitos.

• Número de cambios de requisitos no financiados después de ser
puestos en la línea base.
• Lecciones aprendidas de la resolución de requisitos ambiguos.

• Parámetros de riesgo.
• Categorías de riesgo.
• Informes del estado del riesgo.
ELABORACIÓN de SAM

• Resultados de revisiones del proveedor.
• Estudios de mercado utilizados para seleccionar proveedores.
• Histórico de las modificaciones a los acuerdos con los proveedores.
• Informes de rendimiento del proveedor.
ELABORACIÓN de TS

• Resultados del análisis de si desarrollar, comprar o reutilizar.
• Densidad de defectos de diseño.
• Resultados de aplicar nuevos métodos y herramientas.
ELABORACIÓN de VAL

• Prototipo de componente de producto.
• Porcentaje de tiempo en el que está disponible el entorno de
validación.
• Número de defectos del producto encontrados por fase de desarrollo
mediante la validación.
• Informe de análisis de la validación.
ELABORACIÓN de VER

• Registros de revisiones entre pares que incluyen el tiempo de
realización y el tiempo medio de preparación.
• Número de defectos del producto encontrados por fase de desarrollo
mediante la verificación.
• Informe de verificación y análisis.
Aplicando las prácticas genéricas

Las prácticas genéricas son componentes que se pueden aplicar a
todas las áreas de proceso. Piense en las prácticas genéricas
como recorda- torios. Tienen el propósito de recordarle que haga
las cosas bien y son componentes esperados del modelo.
Por ejemplo, considere la práctica genérica “Establecer y
mantener el plan para realizar el proceso” (GP 2.2). Cuando se
GGS & GPS

aplica al área de proceso Planificación del Proyecto, esta práctica
genérica le recuerda que hay que planificar las actividades
implicadas en la creación del plan para el proyecto. Cuando se
aplica al área de proceso Formación en la Organización, esta
misma práctica genérica le recuerda que hay que planificar las
actividades implicadas en el desarrollo de las habilidades y el
conocimiento de las personas de la organización.
Áreas de proceso que dan soporte a las prácticas genéricas

Mientras que las metas genéricas y las prácticas genéricas son los
componentes del modelo que tratan directamente la
institucionalización de un proceso en toda la organización,
muchas áreas de proceso tratan asimismo la institucionalización
mediante el soporte de la implemen- tación de las prácticas
genéricas. Conocer estas relaciones le ayudará a implementar con
eficacia las prácticas genéricas.
Tales áreas de proceso contienen una o más prácticas
específicas que cuando se implementan, pueden también
implementar completamente una práctica genérica o generar un
producto de trabajo que se utiliza en la implementación de una
práctica genérica.
Un ejemplo es el área de proceso Gestión de Configuración y
GP 2.6, “Poner los productos de trabajo seleccionados del proceso
bajo los niveles de control apropiados”. Para implementar la
práctica genérica en una o más áreas de proceso, podría elegir
implementar el área de proceso de Gestión de Configuración,
total o parcialmente, para implementar la práctica genérica.
Otro ejemplo es el área de proceso Definición de Procesos de
la Organización y GP 3.1, “Establecer y mantener la descripción
de un proceso definido”. Para implementar esta práctica genérica,
en una o más áreas de proceso, primero debería implementar el
área de proceso de Definición de procesos de la organización,
total o parcialmente, para establecer los activos de proceso de la
organización que son necesarios para implementar la práctica
genérica.
La Tabla 6.2 describe (1) las áreas de proceso que dan soporte
a la implementación de las prácticas genéricas, y (2) las relaciones
recursivas entre prácticas genéricas y las áreas de proceso
estrechamente relacionadas con ellas. Es importante recordar
ambos tipos de relaciones durante la mejora de procesos para
aprovechar las sinergias naturales que existen entre las prácticas
genéricas y sus áreas de proceso relacionadas. Dadas las
dependencias que tienen las prácticas genéricas sobre estas áreas
de proceso, y dada la visión más holística que proporcionan
muchas de estas áreas de proceso, éstas se implementan a
menudo de forma temprana, total o parcialmente, antes o
concurrentemente con
la implementación de las prácticas genéricas asociadas.
Tabla 6.2 Relaciones entre práctica genérica y área de proceso
Roles de las áreas de proceso en Cómo se aplica la práctica
la implementación de la práctica genérica recursivamente a su(s)
Práctica Genérica genérica área(s) de proceso relacionada(s) 1
GP 2.2 Planificación del Proyecto: el GP 2.2 aplicada al proceso de

Planificar el proceso de planificación del proyecto planificación del proyecto puede ser
Proceso puede implementar GP 2.2 en su considerada como “planificar el plan”
totalidad para todas las áreas de y cubre la planificación de actividades
proceso relacionadas con el proyecto de planificación del proyecto.
(excepto para la propia Planificación
del proyecto).
GP 2.3 Planificación del Proyecto: la parte del

Proporcionar proceso de planificación del proyecto
Recursos que implementa PP SP 2.4 “Planificar los
recursos del proyecto” da soporte a la
GP 2.4 implementación de GP 2.3 y GP 2.4 para
Asignar todas las áreas de proceso relacionadas
Responsabilidad con el proyecto (excepto, quizás,
inicialmente para la propia Planificación
del Proyecto) identificando procesos,
roles y responsabilidades necesarias
para asegurar que están garantizados
el personal, las instalaciones, el
equipamiento y otros activos necesarios
apropiados para el proyecto.
GP 2.5 Formación en la Organización: GP 2.5 aplicado al proceso de

Formar al este proceso da soporte a la formación en la organización,
Personal implementación de GP 2.5 en tanto que cubre la formación para realizar
se aplique a todas las áreas de proceso, las actividades de formación en la
impartiendo la formación que trate las organización, las cuales tratan las
necesidades de formación de toda la habilidades requeridas para gestionar,
organización o estratégicas, disponibles crear y llevar a cabo la formación.
para aquellos que realizarán o darán
soporte al proceso.
Planificación del Proyecto: la parte
del proceso de planificación del
proyecto que implementa PP SP 2.5
“Planificar el conocimiento y las
habilidades necesarias” y el proceso
de formación de la organización, da
soporte a la implementación de GP 2.5
en su totalidad para todas las áreas de
proceso relacionadas con el proyecto.
GP 2.6 Gestión de Configuración: GP 2.6 aplicada al proceso de gestión

Controlar los el proceso de gestión de configuración de configuración, cubre el control
Productos de puede implementar GP 2.6 en su de cambios y de versiones para los
Trabajo totalidad para todas las áreas de productos de trabajo producidos
proceso relacionadas con el proyecto, por las actividades de gestión de
así como para ciertas áreas de proceso configuración.
1
Cuando la relación entre una práctica genérica y un área de proceso es menos
directa, el riesgo de confusión se reduce, por tanto en la tabla no se describen todas
las relaciones recursivas (p. ej., para las prácticas genéricas 2.3, 2.4 y 2.10).
GGS & GPS

GP 2.7 Planificación del Proyecto: la GP 2.7 aplicada al proceso de

Identificar e parte del proceso de planificación planificación del proyecto, cubre
Involucrar a las del proyecto que implementa PP la involucración de las partes
Partes Interesadas SP 2.6 “Planificar la involucración interesadas relevantes en las
Relevantes de las partes interesadas” actividades de planificación del
puede implementar la parte de proyecto.
la identificación de las partes
interesadas (primeras dos GP 2.7 aplicada al proceso de
subprácticas) de GP 2.7 en su totalidad monitorización y control del
para todas las áreas de proceso proyecto, cubre la involucración de
relacionadas con el proyecto. las partes interesadas relevantes en
las actividades de monitorización y
Monitorización y Control del Proyecto: control del proyecto.
la partedelprocesode monitorización
y controldelproyectoqueimplementa GP 2.7 aplicada al proceso de
PMC SP 1.5 “Monitorizar la involucración gestión integrada del proyecto
de las partes interesadas” puede ayudar cubre la involucración de las partes
en la implementación de la tercera interesadas relevantes en las
subpráctica de GP 2.7 para todas las áreas actividades de gestión integrada del
de proceso relacionadas con el proyecto. proyecto.
GestiónIntegradadel Proyecto:la
parte del proceso de gestión integrada
del proyecto que implementa IPM SP
2.1 “Gestionar la involucración de las
partesinteresadas”puedeayudarenla
implementación de la tercera subpráctica
de GP 2.7 para todas las áreas de proceso
relacionadas con el proyecto.
GP 2.8 Monitorización y Control GP 2.8 aplicada al proceso de

Monitorizar del Proyecto: el proceso de monitorización y control del proyecto,
y Controlar el monitorización y control del proyecto cubre la monitorización y el control
Proceso puede implementar GP 2.8 en su de las actividades de monitorizar y
totalidad para todas las áreas de controlar el proyecto.
Medición y Análisis: para todos
los procesos, no sólo los procesos
relacionados con el proyecto, el área
de proceso de “Medición y Análisis”
proporciona orientación general sobre
la medición, el análisis y el registro de
información que pueden usarse para
establecer medidas para monitorizar
el rendimiento del proceso.
GP 2.9 Evaluar Aseguramiento de la Calidad del GP 2.9 aplicada al proceso de

Objetivamente la Proceso y del Producto: el proceso aseguramiento de la calidad del
Adherencia de aseguramiento de la calidad proceso y del producto, cubre la
del proceso y del producto puede evaluación objetiva de las actividades
implementar GP 2.9 en su totalidad de aseguramiento de la calidad y de
para todas las áreas de proceso productos de trabajo seleccionados.
(excepto, quizás, para la propia de
Aseguramiento de la Calidad del
Proceso y del Producto).
Continúa

GP 2.10 Monitorización y Control del

Revisar el Estado Proyecto: la parte del proceso de
con la alta monitorización y control del proyecto
dirección que implementa PMC SP 1.6 “Realizar
revisiones del progreso” y PMC SP
1.7 “Realizar revisiones en hitos” da
soporte a la implementación de GP
2.10 para todas las áreas de proceso
relacionadas con el proyecto, quizás
en su totalidad, dependiendo de la
involucración de la alta dirección en
estas revisiones.
GP 3.1 Gestión Integrada del Proyecto: la GP 3.1 aplicada al proceso de gestión

Establecer un parte del proceso de gestión integrada integrada del proyecto, cubre el
Proceso Definido del proyecto que implementa IPM SP establecimiento de los procesos
1.1 “Establecer el proceso definido del definidos para las actividades de
proyecto” puede implementar GP 3.1 gestión integrada del proyecto.
en su totalidad para todas las áreas de
Definición de Procesos de la
Organización: para todos los
procesos, no sólo los relacionados con
el proyecto, el proceso de definición
de procesos de la organización
establece los activos del proceso de
la organización que se necesitan para
implementar GP 3.1.
GP 3.2 Gestión Integrada del Proyecto: la GP 3.2 aplicada al proceso de gestión

Recoger parte del proceso de gestión integrada integrada del proyecto, cubre la
Experiencias del proyecto que implementa IPM recogida de experiencias relativas
relativas al Proceso SP 1.7 “Contribuir a los activos de al proceso procedentes de la
proceso de la organización” puede planificación y de la realización de las
implementar GP 3.2 parcialmente o en actividades de gestión integrada del
su totalidad para todas las áreas de proyecto.
Enfoque en Procesos de la
Organización: la parte del proceso
de enfoque en procesos de la
organización que implementa OPF
SP 3.4 “Incorporar experiencias
en los activos de proceso de la
organización” puede implementar GP
3.2 parcialmente o en su totalidad para
todas las áreas de proceso.
Definición de Procesos de la
Organización: para todos los
procesos, el proceso de definición
de procesos de la organización
establece los activos de proceso
de la organización necesarios para
implementar GP 3.2.
Dadas las dependencias que tienen las prácticas genéricas
sobre estas áreas de proceso, y dada la visión más holística que
GGS & GPS

proporcionan muchas de estas áreas de proceso, éstas se
implementan a menudo de forma temprana, total o parcialmente,
antes o concurrentemente con la implementación de las prácticas
genéricas asociadas.
También hay algunas situaciones donde el resultado de aplicar
una práctica genérica a un área de proceso dada podría parecer un
dupli- cado del área de proceso completa, pero, en realidad, no es
así. Puede ser lógico pensar que la aplicación de GP 3.1 “Establecer
un proceso definido” a las áreas de proceso Planificación del
Proyecto, y Monito- rización y Control del Proyecto proporcionan el
mismo efecto que la primera meta específica Gestión Integrada del
Proyecto, “Usar el Pro- ceso Definido del Proyecto”.
Aunque es verdad que existe algún solapamiento, la
aplicación de la práctica genérica a estas dos áreas de proceso
proporciona procesos definidos que cubren las actividades de
planificación del proyecto, y de monitorización y control del
proyecto. Estos procesos definidos no cubren necesariamente
actividades de soporte (p. ej., gestión de configuración), otros
procesos de gestión de proyectos (p. ej., gestión integrada del
proyecto) u otros procesos. Por el contrario, el proceso definido
del proyecto, proporcionado por el área de proceso Gestión
Integrada del Proyecto, cubre todos los procesos apropiados.
ANÁLISIS CAUSAL Y RESOLUCIÓN
car
Propósito
El propósito de Análisis Causal y Resolución (CAR) es
identificar las causas de los resultados seleccionados y actuar
para mejorar el rendimiento de proceso.
El Análisis Causal y Resolución mejora la calidad y la
productividad mediante la prevención de la introducción de
defectos o problemas y mediante la identificación e
incorporación de forma apropiada de las causas de un mayor
rendimiento de proceso.
El área de proceso Análisis Causal y Resolución implica las
siguientes actividades:
 Identificar y analizar las causas de los resultados
seleccionados. Los resultados seleccionados pueden
representar defectos y problemas cuya ocurrencia puede
prevenirse en el futuro o éxitos que pueden implementarse
en los proyectos o en la organización.
 Tomar acciones para:
Eliminar las causas y prevenir la recurrencia de esos tipos
de defectos y problemas en el futuro.
Analizar los datos proactivamente para identificar
problemas potenciales y prevenir que ocurran.
Incorporar las causas de éxitos al proceso para mejorar el
futuro rendimiento del proceso.
No es rentable confiar que los defectos y problemas se vayan a

detectar después de que se han introducido. Es más rentable
prevenir los defectos y problemas integrando las actividades del
Análisis Causal y Resolución dentro de cada fase del proyecto.
233
Dado que pueden haberse encontrado previamente resultados
similares en otros proyectos o en fases o tareas anteriores del
proyecto en curso, las actividades del Análisis Causal y
Resolución son mecanismos para comunicar las lecciones
aprendidas entre proyectos.
Los tipos de resultados encontrados se analizan para
identificar tendencias. Basándose en una comprensión del
proceso definido y en cómo se ha implementado, se determinan
las causas raíz de estos resultados y sus implicaciones futuras.
Dado que es poco práctico realizar el análisis causal sobre
todos los resultados, se seleccionan objetivos balanceando las
inversiones estimadas frente a los retornos estimados de calidad,
de productividad y de tiempo de ciclo.
Los procesos de medición y análisis deberían estar ya
desplegados. Las medidas definidas existentes pueden utilizarse,
aunque en algunos casos para analizar los efectos de un cambio de
proceso se pueden necesitar nuevas definiciones, redefiniciones
o definiciones clarificadas de medición.
PARA más INFORMACIÓN sobre cómo ALINEAR LAS ACTIVIDADES de medición y ANÁLISIS,
y proporCIONAR rESULTADOS de medición, consúltese el árEA de proceso Medición y
Análisis.
Las actividades del Análisis Causal y Resolución
proporcionan un mecanismo a los proyectos para evaluar sus
procesos a nivel local y buscar las mejoras que puedan
implementarse.
Cuando se considera que las mejoras son eficaces, la
información se remite a nivel de la organización para un potencial
despliegue en los procesos de la organización.
Las prácticas específicas de este área de proceso se aplican a
un proceso que es seleccionado para la gestión cuantitativa. El
uso de las prácticas específicas de este área de proceso puede
añadir valor en otras situaciones, pero los resultados pueden no
proporcionar el mismo grado de impacto en los objetivos de
calidad y de rendimiento de proceso de la organización.
Áreas de proceso relacionadas

PARA más INFORMACIÓN sobre cómo ALINEAR LAS ACTIVIDADES de medición y ANÁLISIS
Análisis.
PARA más INFORMACIÓN sobre cómo SELECCIONAR e IMPLEMENTAR LAS MEJORAS A des-
PLEGAR, consúltese el árEA de proceso Gestión del Rendimiento de LA OrGANIZACIÓN.
PARA más INFORMACIÓN sobre cómo GESTIONAR CUANTITATIVAMENTE el proyecto PARA

ALCANZAR los objetivos ESTABLECIDOS de CALIDAD y de rendimiento de proceso del
proyecto, consúltese el árEA de proceso Gestión CUANTITATIVA del Proyecto.
Resumen de metas y prácticas específicas

SG 1 Determinar las causas de los resultados seleccionados.
SP 1.1 Seleccionar los resultados a analizar.
SP 1.2 Analizar las causas.
SG 2 Tratar las causas de los resultados seleccionados.
SP 2.1 Implementar las propuestas de acción.
SP 2.2 Evaluar el efecto de las acciones implementadas.
SP 2.3 Registrar datos del análisis causal.
Prácticas específicas por meta
car
sG 1 d eterminar Las causas de Los resuLtados seLeccionados
Las causas raíz de los resultados seleccionados se determinan sistemáticamente.
Una causa raíz es un elemento inicial en una cadena causal que

condu- ce a un resultado de interés.
sp 1.1 seleccionaR los Resultados a analizaR
Seleccionar los resultados a analizar.
Esta actividad podría activarse por un evento (reactiva) o podría

planificarse periódicamente, como al inicio de una nueva fase o
tarea (proactiva).
Ejemplos de productos de TRABAJO

1. Datos a utilizar en el análisis inicial.
2. Datos de los resultados del análisis inicial.
3. Resultados seleccionados para análisis posteriores.
SUBPRÁCTICAS
1. Recoger datos relevantes.
Algunos ejemplos de datos relevantes son:

• Defectos notificados por clientes o usuarios finales.
• Defectos encontrados en las revisiones entre pares o en las pruebas.
• Medidas de productividad que son mayores de lo esperado.
• Informes de problemas de gestión de proyectos que requieren acción
correctiva.
• Problemas de capacidad de proceso.
• Mediciones de valor ganado por proceso (p. ej., índice de rendimiento
de coste).
• Mediciones de rendimiento de recursos, de utilización o de tiempo de
respuesta.
• Problemas de cumplimiento o de satisfacción del servicio.
2. Determinar qué resultados analizar más a fondo.
Cuando se determina qué resultados analizar más a fondo, hay
que considerar el origen, el impacto, la frecuencia de ocurrencia,
la similitud, el coste del análisis, el tiempo y los recursos
necesarios, las consideraciones de seguridad, etc.
Algunos ejemplos de métodos para seleccionar resultados son:

• Análisis de Pareto.
• Histogramas.
• Gráficos de caja y de bigotes para atributos.
• Análisis modal de fallos y efectos (AMFE).
• Análisis de capacidad del proceso.
3. Definir formalmente el alcance del análisis, incluyendo una

defini- ción clara de la mejora necesaria o esperada, las partes
interesadas afectadas, el objetivo afectado, etc.
sp 1.2 analizaR las causas

Realizar el análisis causal de los resultados seleccionados y proponer acciones
para tratarlos.
El propósito de este análisis es definir acciones que tratarán los

resultados seleccionados mediante el análisis de los datos de
resultados relevantes y la generación de propuestas de acción a
implementar.

1. Resultados del análisis de las causas raíz.
2. Propuestas de acción.
SUBPRÁCTICAS
1. Llevar a cabo el análisis causal con los responsables de realizar
la tarea.
El análisis causal se realiza normalmente en reuniones, con
aquellos que entienden el resultado seleccionado bajo estudio.
Los responsables de realizar la tarea son, normalmente, los que
mejor entienden los resultados seleccionados. El análisis es más
eficaz cuando se aplica a datos en tiempo real, lo más cerca
posible al evento que activó el resultado.
Algunos ejemplos de cuándo realizar el análisis causal son:

• Cuando un subproceso estable no cumple sus objetivos de calidad y
de rendimiento de proceso especificados, o cuando un subproceso
necesita ser estabilizado.
• Durante la tarea, siempre y cuando los problemas justifiquen una
reunión de análisis causal.
• Cuando un producto de trabajo muestra una desviación imprevista de
sus requisitos.
• Cuando se escapan más defectos de lo previsto desde las fases
anteriores a la fase actual.
car
• Cuando el rendimiento de proceso excede las expectativas.
• Al comienzo de una nueva fase o tarea.
PARA más INFORMACIÓN sobre cómo rEALIZAR el ANÁLISIS de CAUSAS RAÍZ, consúltese
el árEA de proceso Gestión CUANTITATIVA del Proyecto.
2. Analizar los resultados seleccionados para determinar sus causas
raíz. El análisis de las líneas base y modelos de rendimiento de
proceso puede ayudar a identificar las causas raíz potenciales.
Dependiendo del tipo y número de resultados, puede ser
beneficioso examinar los resultados de varias formas para
asegurar que se investi- gan todas las causas raíz potenciales.
Considere examinar tanto resultados individuales como
resultados agrupados.
Algunos ejemplos de métodos para determinar las causas raíz son:

• Diagramas de causa efecto (fishbone - espina de pescado).
• Hojas de comprobación.
3. Agrupar los resultados seleccionados basándose en sus causas
raíz. En algunos casos, los resultados pueden estar influenciados
por múl- tiples causas raíz.
Algunos ejemplos de grupos o categorías de causas son:

• Formación y habilidades inadecuadas.
• Corte de las comunicaciones.
• No contabilizar todos los detalles de una tarea.
• Cometer errores en los procedimientos manuales (p. ej., al
mecanografiar).
• Deficiencia del proceso.
Cuando sea apropiado, busque tendencias o síntomas dentro de o

entre grupos.
4. Crear una propuesta de acción que documente las acciones a
tomar para prevenir la ocurrencia futura de resultados similares,
o para incorporar buenas prácticas en los procesos.
Los modelos de rendimiento de proceso pueden dar soporte al
aná- lisis coste beneficio de las propuestas de acción por medio
de la pre- dicción de impactos y del retorno de la inversión.
Algunos ejemplos de acciones preventivas propuestas son cambios en:

• El proceso en cuestión.
• Formación.
• Herramientas.
• Métodos.
• Productos de trabajo.
Algunos ejemplos de incorporación de buenas prácticas son:

• Crear listas de comprobación para la actividad, lo cual refuerza la
formación o las comunicaciones relativas a problemas y técnicas
comunes para su prevención.
• Cambiar un proceso de tal forma que no sucedan los pasos propensos
a errores.
• Automatizar todo o parte de un proceso.
• Reordenar las actividades del proceso.
• Añadir pasos al proceso, tales como reuniones de inicio de tarea para
revisar problemas comunes, así como acciones para su prevención.
Una propuesta de acción usualmente documenta:

• Autor de la propuesta de acción.
• Descripción del resultado a tratar.
• Descripción de la causa.
• Categoría de la causa.
• Fase identificada.
• Descripción de la acción.
• Tiempo, coste y otros recursos requeridos para implementar la
propuesta de acción.
• Beneficios esperados al implementar la propuesta de acción.
• Costes estimados de la no resolución del problema
• Categoría de la propuesta de acción.
sG 2 tratar Las causas de Los resuLtados seLeccionados

Las causas raíz de los resultados seleccionados se tratan sistemáticamente.
Los proyectos que operan de acuerdo a un proceso bien definido

analizan sistemáticamente dónde son necesarias las mejoras e
implementan cambios del proceso para tratar las causas raíz de
los resultados seleccionados.
sp 2.1 implementaR las pRopuestas de acción
Implementar las propuestas de acción seleccionadas que se han desarrollado
en el análisis causal.
Las propuestas de acción describen las tareas necesarias para

tratar las causas raíz de los resultados analizados con el fin de, o
bien prevenir o reducir la ocurrencia o recurrencia de resultados
negativos, o bien incorporar los éxitos obtenidos. Se desarrollan
e implementan planes de acción para las propuestas de acción
seleccionadas. Solamente se deberían considerar los cambios que
se demuestre que son de valor para su implementación general.
car
1. Propuestas de acción seleccionadas para su implementación.
2. Planes de acción.
SUBPRÁCTICAS
1. Analizar las propuestas de acción y determinar sus prioridades.
Algunos criterios para priorizar las propuestas de acción son:

• Implicaciones de no tratar el resultado.
• Coste de implementar mejoras de procesos para tratar el resultado.
• Impacto esperado sobre la calidad.
Los modelos de rendimiento de proceso se pueden utilizar para

ayudar a identificar interacciones entre múltiples propuestas de
acción.
2. Seleccionar las propuestas de acción a implementar.
3. Crear planes de acción para implementar las propuestas de
acción seleccionadas.
Algunos ejemplos de información proporcionada en un plan de acción son:

• Persona responsable de la implementación.
• Descripción detallada de la mejora.
• Descripción de las áreas afectadas.
• Personas a las que hay que mantener informadas del estado.
• Calendario.
• Coste empleado.
• Próxima fecha en la que será revisado el estado.
• Análisis razonado de las decisiones clave.
• Descripción de las acciones de implementación.
4. Implementar planes de acción.
Para implementar los planes de acción, se deberían realizar las
siguientes tareas:
 Hacer las asignaciones.
 Coordinar a las personas que hacen el trabajo.
 Revisar los resultados.
 Seguir los elementos de acción hasta su cierre.
Se pueden llevar a cabo experimentos para cambios
particularmente complejos.
Algunos ejemplos de experimentos son:

• Utilizar un proceso modificado temporalmente.
• Utilizar una nueva herramienta.
Las acciones pueden asignarse a los miembros del equipo de análisis
causal, a los miembros del equipo de proyecto, o a otros miembros
5. Buscar causas similares que puedan existir en otros procesos
y productos de trabajo, y actuar según proceda.
sp 2.2 evaluaR el efecto de las acciones implementadas
Evaluar los efectos de las acciones implementadas sobre el rendimiento de proceso.
PARA más INFORMACIÓN sobre cómo SELECCIONAR MEDIDAS y TÉCNICAS ANALÍTICAS, con-
súltese el árEA de proceso Gestión CUANTITATIVA del Proyecto.
Una vez que se despliega el proceso modificado en el proyecto, se
eva- lúa el efecto de los cambios para verificar que el cambio al
proceso ha mejorado el rendimiento de proceso.
1. Análisis del rendimiento de proceso y cambios en el
SUBPRÁCTICAS
1. Medir y analizar el cambio en el rendimiento de proceso de los
procesos o subprocesos afectados del proyecto.
Esta subpráctica determina si el cambio seleccionado ha influido
posi- tivamente en el rendimiento del proceso y en qué medida.
Un ejemplo de un cambio en el rendimiento de proceso del proceso de dise-

ño definido del proyecto podría ser un cambio en la capacidad prevista del
diseño para cumplir los objetivos de calidad y de rendimiento de proceso.
Otro ejemplo podría ser un cambio en la densidad de defectos de la docu-
mentación de diseño, medida estadísticamente mediante revisión entre pares
antes y después de que la mejora se haya realizado. En un gráfico de control es-
tadístico del proceso, este cambio en el rendimiento de proceso estaría repre-
sentado por una mejora en la media, una reducción en la variación, o ambas.
Las técnicas estadísticas y otras técnicas cuantitativas (p. ej.,
contraste de hipótesis) pueden utilizarse para comparar las líneas
base antes y después, y así evaluar la importancia estadística del
cambio.
2. Determinar el impacto del cambio en el logro de los objetivos de
calidad y de rendimiento de proceso del proyecto.
Esta subpráctica determina si el cambio seleccionado ha influido
positiva- mente en la capacidad del proyecto para cumplir sus
objetivos de calidad y de rendimiento de proceso, entendiendo la
forma en que los cambios en los datos de rendimiento de proceso
han afectado a los objetivos. Los modelos de rendimiento de
proceso pueden ayudar en la evaluación mediante la predicción de
car
impactos y del retorno de la inversión.
3. Determinar y documentar acciones apropiadas si las mejoras de
proceso o de subproceso no han dado como resultado los
beneficios esperados del proyecto.
sp 2.3 RegistRaR los datos del análisis causal
Registrar los datos de análisis causal y resolución para utilizarlos en los proyec-
tos y en la organización.

1. Registros del análisis causal y resolución.
2. Propuestas de mejora para la organización.
SUBPRÁCTICAS
1. Registrar los datos del análisis causal y ponerlos a disposición
para que otros proyectos puedan hacer cambios apropiados al
proceso y conseguir resultados similares.
Registrar:
 Datos sobre resultados que fueron analizados.
 Razón fundamental de las decisiones.
 Propuestas de acción de las reuniones de análisis causal.
 Planes de acción de las propuestas de acción.
 Coste de las actividades de análisis y resolución.
 Medidas de los cambios al rendimiento de proceso del
proceso definido resultado de las resoluciones.
2. Remitir las propuestas de mejora de procesos a la organización
cuando las acciones implementadas sean eficaces para el
proyecto, según proceda.
Cuando las mejoras se consideran eficaces, la información se
puede remitir a nivel de organización para su potencial inclusión
en los procesos de la organización.
PARA más INFORMACIÓN sobre cómo SELECCIONAR MEJORAS, consúltese el árEA de
proceso Gestión del Rendimiento de LA OrGANIZACIÓN.
GESTIÓN DE CONFIGURACIÓN
Propósito
El propósito de la Gestión de Configuración (CM) es establecer y
mantener la integridad de los productos de trabajo utilizando la
identifica- ción de la configuración, el control de la configuración,
el informe del estado de la configuración y las auditorías de la
configuración.
cM
El área de proceso de Gestión de Configuración implica las
siguientes actividades:
 Identificar la configuración de los productos de trabajo
seleccionados que componen las líneas base en puntos
determinados en el tiempo.
 Controlar los cambios a los elementos de configuración.
 Construir o proporcionar las especificaciones para construir
los productos de trabajo a partir del sistema de gestión de
configuración.
 Mantener la integridad de las líneas base.
 Proporcionar a los desarrolladores, usuarios finales y clientes
datos precisos del estado y de la configuración actual.
Los productos de trabajo puestos bajo gestión de

configuración incluyen los productos que se entregan al cliente,
los productos de trabajo internos seleccionados, los productos
adquiridos, las herramientas y otros elementos utilizados para
crear y describir estos productos de trabajo (véase la definición
de “gestión de configuración” en el glosario).
243
Algunos ejemplos de productos de trabajo que pueden ponerse bajo ges-

tión de configuración son:
• Hardware y equipamiento.
• Diagramas.
• Especificaciones de producto.
• Configuraciones de herramientas.
• Código y bibliotecas.
• Compiladores.
• Herramientas de pruebas y scripts de pruebas.
• Registros de instalación.
• Ficheros de datos de producto.
• Publicaciones técnicas de producto.
• Planes.
• Historias de usuario.
• Backlogs de iteración.
• Descripciones de proceso.
• Requisitos.
• Documentación de la arquitectura y datos de diseño.
• Planes de líneas de producto, procesos y activos base.
Puede ser necesario que los productos adquiridos se pongan

bajo gestión de configuración tanto por el proveedor como por el
proyecto. Para llevar a cabo la gestión de configuración, se
deberían establecer las provisiones en los acuerdos con el
proveedor. Se deberían establecer y mantener métodos para
asegurar que los datos están completos y son consistentes.
PARA más INFORMACIÓN sobre cómo ESTABLECER ACUERdos con el proveedor, consúltese
el árEA de proceso Gestión de Acuerdos con Proveedores.
La gestión de configuración de los productos de trabajo se
puede realizar en diferentes niveles de detalle. Los elementos de
configuración se pueden descomponer en componentes de confi-
guración y en unidades de configuración. El término “elemento de
configuración” sólo se utiliza en este área de proceso. Por tanto, en
estas prácticas, el “elemento de configuración” se puede interpretar
como “componente de configuración” o “unidad de configuración”
según proceda (véase la definición de “elemento de configuración”
en el glosario).
Las líneas base proporcionan una base estable para la
evolución continua de los elementos de configuración.
Un ejemplo de una línea base es una descripción aprobada de un producto

que incluye versiones de requisitos consistentes a nivel interno, de matri-
ces de trazabilidad de requisitos, de diseño, de elementos específicos de
una disciplina y de la documentación de usuario final.
Gestión de comunicación 245
Las líneas base se añaden al sistema de gestión de
configuración a medida que se desarrollan. Los cambios a las
líneas base y a las versiones de los productos de trabajo
construidos a partir del sistema de gestión de configuración, se
controlan y monitorizan siste- máticamente mediante: el control
de la configuración, la gestión de cambios y las funciones de
auditoría de configuración de gestión de configuración.
Este área de proceso se aplica no sólo a la gestión de
configura- ción en proyectos, sino también a la gestión de
configuración de los productos de trabajo de la organización,
tales como: estándares, procedimientos, bibliotecas de
reutilización y otros activos de soporte compartidos.
La gestión de configuración se centra en el control riguroso de
los aspectos de gestión y técnicos de los productos de trabajo,
incluyendo el producto o servicio entregado.
Este área de proceso cubre las prácticas para realizar la
función de gestión de configuración y es aplicable a todos los
productos de trabajo que se ponen bajo gestión de
configuración.
Para líneas de productos, la gestión de la configuración implica
cM
consideraciones adicionales debido a la compartición de activos bá-
sicos a través de los productos de la línea de productos y a través de
múltiples versiones de los activos y productos base (véase la
definición de “línea de productos” en el glosario).
En entornos ágiles, la gestión de la configuración (CM) es importante de-

bido a la necesidad de soportar cambios y ensamblados frecuentes (nor-
malmente a diario), múltiples líneas base, y múltiples espacios de trabajo
soportados por CM (p. ej., para individuos, equipos, e incluso para la pro-
gramación por pares). Los equipos ágiles pueden atascarse si la organiza-
ción no: 1) automatiza CM (p. ej., creación de scripts, informes de estado,
comprobación de integridad) y 2) implementa CM como un único conjunto
de servicios estándar. En su inicio, un equipo ágil debería identificar a la
persona que será responsable de garantizar que la CM esté correctamen-
te implementada. Al inicio de cada iteración, es necesario reconfirmar las
necesidades de soporte de CM. CM está cuidadosamente integrada en los
ritmos de cada equipo centrándose en minimizar la distracción del equi-
po para realizar el trabajo (véase “Interpretando CMMI al utilizar enfoques
ágiles”, en la Primera Parte).

Para más información sobre cómo monitorizar el proyecto frente al plan y ges-
tionar las acciones correctivas hasta el cierre, consúltese el área de proceso Mo-
nitorización y Control del Proyecto (PMC).
PARA más INFORMACIÓN sobre cómo DESARrOLLAR un PLAN de proyecto, consúltese el
árEA de proceso PLANIFICACIÓN del Proyecto (PP).
Resumen de metas específicas y prácticas específicas

SG 1 Establecer las líneas base.
SP 1.1 Identificar los elementos de configuración.
SP 1.2 Establecer un sistema de gestión de configuración.
SP 1.3 Crear o liberar las líneas base.
SG 2 Seguir y controlar los cambios.
SP 2.1 Seguir las peticiones de cambio.
SP 2.2 Controlar los elementos de configuración.
SG 3 Establecer la integridad.
SP 3.1 Establecer los registros de gestión de configuración.
SP 3.2 Realizar auditorías de configuración.
sG 1 e stabLecer Las Líneas base

Se establecen las líneas base de los productos de trabajo identificados.
Las prácticas específicas para establecer las líneas base se cubren

por esta meta específica. Las prácticas específicas bajo la meta
específica Seguir y controlar los cambios sirven para mantener
las líneas base. Las prácticas específicas de la meta específica
Establecer la integridad, documentan y auditan la integridad de las
líneas base.
sp 1.1 identificaR los elementos de configuRación
Identificar los elementos de configuración, los componentes, y los productos
de trabajo relacionados que serán puestos bajo gestión de configuración.
La identificación de la configuración consiste en la selección y

especi- ficación de:
 Productos entregados al cliente.
 Productos de trabajo internos seleccionados.
 Productos adquiridos.
 Herramientas y otros activos esenciales del entorno de trabajo
del proyecto.
 Otros elementos usados en la creación y la descripción de
estos productos de trabajo.
Los elementos de configuración pueden incluir el hardware,

el equipamiento y los activos tangibles, así como el software y la
docu- mentación. La documentación puede incluir
especificaciones de requisitos y documentos de interfaz.
También se pueden incluir otros documentos que sirven para
identificar la configuración del producto o servicio, tales como
los resultados de las pruebas.
Un “elemento de configuración” es una entidad selecciona-
da para la gestión de configuración, que puede consistir en varios
productos de trabajo relacionados que forman una línea base.
Esta agrupación lógica proporciona facilidad de identificación y
acceso controlado. La selección de los productos de trabajo para
la gestión de configuración debería basarse en criterios
establecidos durante la planificación.

1. Elementos de configuración identificados.
SUBPRÁCTICAS
1. Seleccionar los elementos de configuración y los productos de
trabajo que los componen, basándose en criterios
documentados.
Algunos ejemplos de criterios para seleccionar los elementos de configura-

ción en el nivel apropiado del producto de trabajo son:
• Productos de trabajo que se pueden utilizar por dos o más grupos.
cM
• Productos de trabajo que se espera que cambien a lo largo del tiempo
debido a errores o a cambios en los requisitos.
• Productos de trabajo que son dependientes entre sí (es decir, un
cambio en uno implica un cambio en los otros).
• Productos de trabajo críticos para el éxito del proyecto.
Algunos ejemplos de productos de trabajo que pueden ser parte de un ele-

mento de configuración son:
• Diseño.
• Planes y procedimientos de pruebas.
• Resultados de las pruebas.
• Descripciones de interfaz.
• Diagramas.
• Código fuente.
• Historias de usuario o tarjetas de historia.
• Casos de negocio, lógica de negocio o valor de negocio declarados.
• Herramientas (p. ej., compiladores).
• Descripciones de procesos.
• Requisitos.
2. Asignar identificadores únicos a los elementos de configuración.

3. Especificar las características importantes de cada elemento de
configuración.
Algunos ejemplos de características de elementos de configuración son:

autor, tipo de documento o archivo, lenguaje de programación para archi-
vos de código software, características mínimas de comercialización, y el
propósito del elemento de configuración.
4. Especificar cuándo se pone bajo gestión de configuración cada
elemento de configuración.
Algunos ejemplos de criterios para determinar cuándo poner los productos

de trabajo bajo gestión de configuración son:
• Cuando el producto de trabajo está listo para las pruebas.
• Etapa del ciclo de vida del proyecto.
• Grado de control deseado en el producto de trabajo.
• Limitaciones de costes y de calendario.
• Requisitos de las partes interesadas.
5. Identificar al propietario responsable de cada elemento de
configuración.
6. Especificar las relaciones entre los elementos de configuración.
La incorporación de los tipos de relaciones (p. ej., padre-hijo,
dependencia), que existen entre los elementos de configuración
en la estructura de gestión de configuración (p. ej., base de
datos de gestión de configuración), ayuda en la gestión de los
efectos e impactos de los cambios.
sp 1.2 estableceR un sistema de gestión de configuRación

Establecer y mantener un sistema de gestión de configuración y de gestión de
cambios para controlar los productos de trabajo.
Un sistema de gestión de configuración incluye los medios de

almacenamiento, procedimientos y herramientas para acceder al
sistema. Un sistema de gestión de configuración puede constar de
múltiples subsistemas con diferentes implementaciones que son
apropiadas para cada entorno de gestión de configuración.
Un sistema de gestión de cambios incluye los medios de
almacenamiento, los procedimientos y las herramientas para
registrar y acceder a las peticiones de cambio.

1. Sistema de gestión de configuración con productos de trabajo
controlados.
2. Procedimientos de control de acceso al sistema de gestión de
configuración.
3. Base de datos de peticiones de cambio.
SUBPRÁCTICAS
1. Establecer un mecanismo para gestionar múltiples niveles de
control. El nivel de control se selecciona normalmente en base a
los objetivos, los riesgos y los recursos del proyecto. Los niveles
de control pueden
variar en relación al ciclo de vida del proyecto, al tipo de sistema
bajo desarrollo y a los requisitos específicos del proyecto.
Algunos ejemplos de niveles de control son:

• No controlado: cualquier persona puede realizar cambios.
• Trabajo en curso: los autores controlan los cambios.
• Liberado: una autoridad designada autoriza y controla los cambios y se
notifican a las partes interesadas relevantes los cambios realizados.
Los niveles de control pueden variar desde un control informal

en el que simplemente se siguen los cambios realizados cuando
se es- tán desarrollando los elementos de configuración, hasta
un control de configuración formal utilizando las líneas base
que solamente se pueden cambiar como parte de un proceso
formal de gestión de configuración.
cM
2. Proporcionar control de acceso para asegurar el acceso
autorizado al sistema de gestión de configuración.
3. Almacenar y recuperar los elementos de configuración en un
sistema de gestión de configuración.
4. Compartir y transferir los elementos de configuración entre los
niveles de control en el sistema de gestión de configuración.
5. Almacenar y recuperar versiones archivadas de elementos de
configuración.
6. Almacenar, actualizar y recuperar los registros de gestión de
configuración.
7. Crear informes de gestión de configuración a partir del sistema
de gestión de configuración.
8. Preservar los contenidos del sistema de gestión de configuración.
Algunos ejemplos de funciones para preservar el sistema de gestión de con-

figuración son:
• Copia de seguridad y recuperación de los archivos de gestión de
configuración.
• Almacenamiento de los archivos de gestión de configuración.
• Recuperación a partir de errores de gestión de configuración.
9. Modificar la estructura de gestión de configuración según sea

necesario.
sp 1.3 cReaR o libeRaR las líneas base
Crear o liberar las líneas base para uso interno y para la entrega al cliente.
Una línea base se representa mediante la asignación de un

identificador a un elemento de configuración o una colección de
elementos de configuración y entidades asociadas en un momento
determinado en el tiempo. A medida que evoluciona un producto o
servicio, se pueden utilizar múltiples líneas base para controlar el
desarrollo y las pruebas (véase la definición de “línea base” en el
glosario).
Los productos hardware, así como el software y la
documentación, se deberían incluir también en las líneas base
para las configuraciones relativas a la infraestructura (p. ej.,
software, hardware) y en la preparación para las pruebas del
sistema que incluyen interfaces del hardware y software.
Un conjunto común de líneas base incluye los requisitos de
nivel de sistema, los requisitos de diseño a nivel de elementos del
sistema y la definición del producto al final del desarrollo/inicio de
la puesta en producción. Estas líneas base se conocen normalmente
como “lí- nea base funcional,” “línea base asignada” y “línea base del
producto”, respectivamente.
Una línea base de software puede ser un conjunto de
requisitos, de diseño, de archivos de código fuente y su código
ejecutable asociado, de archivos de construcción y de la
documentación de usuario (entidades asociadas) a los que se ha
asignado un identificador único.
1. Líneas base.
2. Descripción de las líneas base.
SUBPRÁCTICAS
1. Obtener la autorización del Comité de Control de Configura-
ción (CCB) antes de crear o liberar las líneas base de elementos
de configuración.
2. Crear o liberar líneas base sólo de los elementos de
configuración en el sistema de gestión de configuración.
3. Documentar el conjunto de elementos de configuración que
están contenidos en una línea base.
4. Poner a disposición el conjunto actual de líneas base.
sG 2 seGuir y controLar Los cambios
Se siguen y se controlan los productos de trabajo bajo gestión de configuración.
Las prácticas específicas de esta meta específica sirven para

mantener las líneas base después de que estén establecidas por
las prácticas es- pecíficas de la meta específica Establecer las
líneas base.
sp 2.1 seguiR las peticiones de cambio
Seguir las peticiones de cambio a los elementos de configuración.
Las peticiones de cambio no sólo tratan los requisitos nuevos o

modificados, sino también los fallos y los defectos en los productos
de trabajo. Las peticiones de cambio se analizan para determinar el
impacto que tendrá el cambio en el producto de trabajo, en los
productos de
trabajo relacionados, en el presupuesto y en el calendario.

1. Peticiones de cambio.
SUBPRÁCTICAS
1. Iniciar y registrar las peticiones de cambio en la base de datos
de peticiones de cambio.
2. Analizar el impacto de los cambios y de las correcciones
propuestas en las peticiones de cambio.
Los cambios se evalúan mediante actividades que aseguren que
cM
son consistentes con todos los requisitos técnicos y del proyecto.
Los cambios se evalúan por su impacto más allá de los requisitos
inmediatos del proyecto o del contrato. Los cambios a un
elemento utilizado en múltiples productos pueden resolver una
cuestión inme- diata a la vez que causar un problema en otras
aplicaciones.
Los cambios se evalúan por su impacto en los planes liberados.
3. Clasificar y priorizar las peticiones de cambio.
Las peticiones urgentes se identifican y remiten a una autoridad
com- petente para este tipo de peticiones, si es necesario.
Los cambios se asignan a las líneas base futuras.
4. Revisar las peticiones de cambio a tratar en la siguiente línea base
con las partes interesadas relevantes y llegar a un acuerdo.
Realizar la revisión de la petición de cambio con los
participantes apropiados. Registrar el orden de cada petición de
cambio y la razón fundamental de la decisión, incluyendo
criterios de éxito, un breve plan de acción si procede y las
necesidades satisfechas o no satisfechas por el cambio. Realizar
las acciones requeridas e informar de los resultados a las partes
5. Seguir el estado de las peticiones de cambio hasta su cierre.
Las peticiones de cambio llevadas al sistema se deberían
manejar de manera eficiente y oportuna. Una vez que se ha
procesado la petición de cambio, es crítico cerrarla con la acción
apropiada aprobada tan pronto como sea factible. Las acciones
que se han dejado abiertas dan como resultado listas de estado
más grandes de lo necesario, que a su vez dan como resultado
costes añadidos y confusión.
sp 2.2 contRolaR los elementos de configuRación
Controlar los cambios a los elementos de configuración.
Se mantiene el control sobre la configuración de la línea base del

producto de trabajo. Este control incluye el seguimiento de la
configuración de cada elemento de configuración, aprobando una
nueva configuración, en caso de ser necesario, y actualizando la
línea base.

1. Historial de revisiones de los elementos de configuración.
2. Archivos de líneas base.
SUBPRÁCTICAS
1. Controlar los cambios a los elementos de configuración a lo
largo de la vida del producto o servicio.
2. Obtener la autorización apropiada antes que los elementos de
confi- guración modificados sean introducidos en el sistema de
gestión de configuración.
Por ejemplo, la autorización puede venir del CCB, del jefe de proyecto, del
propietario del producto o del cliente.
3. Realizar actividades de check-in y check-out de los elementos
de configuración en el sistema de gestión de configuración para
la in- corporación de los cambios, de forma que se mantenga la
exactitud y la integridad de los elementos de configuración.
Algunos ejemplos de check-in y check-out son:

• Confirmar que las revisiones están autorizadas.
• Actualizar los elementos de configuración.
• Archivar la línea base reemplazada y recuperar la nueva línea base.
• Comentar los cambios realizados al elemento.
• Vincular los cambios a los productos de trabajo relacionados, tales
como requisitos, historias de usuario, y pruebas.
4. Realizar revisiones para asegurar que los cambios no hayan
causado efectos no deseados en las líneas base (p. ej., asegurar que
los cambios no hayan comprometido la seguridad o la
protección del sistema).
5. Registrar los cambios a los elementos de configuración y las
razones de los cambios, según sea apropiado.
Si se acepta un cambio propuesto al producto de trabajo, se
identifica un calendario para incorporar el cambio al producto de
trabajo y a otras áreas afectadas.
Los mecanismos de control de configuración se pueden adaptar
a las categorías de los cambios. Por ejemplo, las consideraciones
para la aprobación podrían ser menos rigurosas para los cambios
de componentes que no afectan a otros componentes.
Los elementos de configuración modificados se liberan después
de la revisión y de la aprobación de los cambios de
configuración. Los cambios no son oficiales hasta que se liberen.
sG 3 e stabLecer La inteGridad
Se establece y mantiene la integridad de las líneas base.
La integridad de las líneas base, establecida por los procesos

asociados con la meta específica Establecer las líneas base, y
mantenida por los procesos asociados con la meta específica
Seguir y controlar los cambios, es tratada por las prácticas
específicas de esta meta específica.
sp 3.1 estableceR los RegistRos de gestión de configuRación
Establecer y mantener los registros que describen los elementos de configuración.
cM
1. Historial de revisiones de los elementos de configuración.
2. Registro de cambios.
3. Registros de peticiones de cambio.
4. Estado de los elementos de configuración.
5. Diferencias entre líneas base.
SUBPRÁCTICAS
1. Registrar las acciones de gestión de configuración con suficiente
detalle para que se conozca el contenido y el estado de cada
elemento de configuración, y para que se puedan recuperar
versiones anteriores.
2. Asegurar que las partes interesadas relevantes tengan acceso y
conocimiento del estado de configuración de los elementos de
configuración.
Algunos ejemplos de actividades para comunicar el estado de la configura-

ción son:
• Proporcionar permisos de acceso a usuarios finales autorizados.
• Poner a disposición de los usuarios finales autorizados copias de las
líneas base.
• Generar avisos automáticamente a las partes interesadas relevantes
cuando se realizan actividades de check-in o check-out sobre los elemen-
tos, o cuando se toman decisiones respecto a las peticiones de cambio.
3. Especificar la última versión de las líneas base.
4. Identificar la versión de los elementos de configuración que
constituyen una línea base particular.
5. Describir las diferencias entre líneas base sucesivas.
6. Modificar, si procede, el estado y la historia (es decir, cambios y
otras acciones) de cada elemento de configuración.
sp 3.2 R ealizaR auditoRías de configuRación

Realizar auditorías de configuración para mantener la integridad de las líneas
base de configuración.
Las auditorías de configuración confirman que las líneas base y la

do- cumentación resultante se ajustan a un estándar o requisito
especificado. Los registros relativos a los elementos de
configuración pueden existir en múltiples bases de datos o sistemas
de gestión de configura- ción. En tales circunstancias, las auditorías
de configuración se debe- rían ampliar a las otras bases de datos,
según proceda, para asegurar la precisión, consistencia y
completitud de la información del elemento de configuración
(véase la definición de “auditoría de la configura- ción” en el
glosario).
Algunos ejemplos de tipos de auditoría son:

• Auditorías de configuración funcional (FCA): las auditorías que se llevan
a cabo para verificar que el desarrollo de un elemento de configuración
ha sido satisfactoriamente completado, que el elemento cumple con las
características funcionales y de atributos de calidad especificados en la
línea base funcional o asignada y que sus documentos operativos y de
soporte están completos y son satisfactorios.
• Auditorías de configuración física (PCA): auditorías que se llevan a
cabo para verificar que un elemento de configuración, tal como fue
construido, es conforme con la documentación técnica que lo define y
describe.
• Auditorías de gestión de la configuración: auditorías que se llevan a
cabo para confirmar que los registros de gestión de configuración y los
elementos de configuración son completos, consistentes y precisos.
Ejemplos de Productos de TRABAJO

1. Resultados de la auditoría de configuración.
2. Elementos de acción.
SUBPRÁCTICAS
1. Evaluar la integridad de las líneas base.
2. Confirmar que los registros de gestión de configuración
identifican correctamente los elementos de configuración.
3. Revisar la estructura y la integridad de los elementos en el
sistema de gestión de configuración.
4. Confirmar que los elementos en el sistema de gestión de
configura- ción son completos, correctos y consistentes.
El contenido del sistema de gestión de configuración completo,
correcto y consistente se basa en los requisitos indicados en el
plan, así como en las peticiones de cambio aprobadas.
5. Confirmar el cumplimiento con los estándares y procedimientos
aplicables de gestión de configuración.
6. Seguir los elementos de acción desde la auditoría hasta su cierre.
cM
ANÁLISIS DE DECISIONES Y RESOLUCIÓN
Propósito
El propósito del Análisis de Decisiones y Resolución (DAR) es
analizar las posibles decisiones utilizando un proceso de
evaluación formal que evalúa las alternativas identificadas,
frente a unos criterios establecidos.
El área de proceso Análisis de Decisiones y Resolución implica
establecer guías, para determinar qué cuestiones deberían estar
sujetas a un proceso de evaluación formal y aplicar los procesos
de evaluación formal a estas cuestiones.
Un proceso de evaluación formal es un enfoque estructurado
para evaluar soluciones alternativas frente a criterios establecidos
con el fin de determinar una solución recomendada. Un proceso
de evaluación formal implica las siguientes acciones:
Dar
 Establecer los criterios para evaluar alternativas.
 Identificar soluciones alternativas.
 Seleccionar métodos para evaluar alternativas.
 Evaluar soluciones alternativas utilizando los criterios y los
méto- dos establecidos.
 Seleccionar soluciones recomendadas a partir de las
alternativas identificadas en base a los criterios de evaluación.
En este área de proceso se utiliza “soluciones alternativas” o “al-

ternativas” para referirse al concepto de “soluciones alternativas
para tratar cuestiones”.
Un proceso de evaluación formal, reduce la naturaleza
subjetiva de una toma de decisión y proporciona mayor
probabilidad de seleccionar una solución que cumpla las
múltiples demandas de las partes interesadas relevantes.
257
Aunque la aplicación principal de este área de proceso es de
tipo técnico, los procesos de evaluación formal pueden aplicarse a
muchas cuestiones no técnicas, en particular durante la
planificación de un proyecto. Las cuestiones que tienen múltiples
soluciones alternativas y múltiples criterios de evaluación se
prestan a un proceso de evaluación formal.
Los estudios de mercado de equipamiento o software son ejemplos típicos

de procesos de evaluación formal.
Durante la planificación, se identifican las cuestiones que re-
quieren un proceso de evaluación formal. Algunos problemas
típicos son la selección entre distintas alternativas de diseño o de
arquitectura, la utilización de componentes reutilizables o de
componentes de productos comerciales (COTS), la selección de
proveedores, los entornos de soporte de ingeniería o de
herramientas asociadas, los entornos de prueba, las alternativas
de entrega, y la logística y producción. Un proceso de evaluación
formal también puede usarse para decidir si comprar o
desarrollar, para el desarrollo de los procesos de fabricación, y
para la selección de los lugares de distribución entre otras
decisiones.
Las guías se crean para decidir cuándo utilizar procesos de evalua-
ción formal, para tratar cuestiones no planificadas. Con
frecuencia las guías sugieren la utilización de procesos de
evaluación formal cuando las cuestiones están asociadas con
riesgos de impacto medio o alto, o cuando las cuestiones afectan
a la capacidad para conseguir los objetivos del proyecto.
Definir bien una cuestión ayuda a definir el alcance de las
alternativas a considerar. El alcance correcto (es decir, ni
demasiado amplio ni demasiado reducido) favorecerá la toma de
una decisión apropiada para resolver la cuestión definida.
Los procesos de evaluación formal pueden variar en
formalidad, tipo de criterios y métodos empleados. Las
decisiones menos formales pueden analizarse en pocas horas,
utilizan pocos criterios (p. ej., eficacia, coste de
implementación), y concluyen con un informe de una o dos
páginas. Las decisiones más formales pueden requerir planes
separados, meses de esfuerzo, reuniones para desarrollar y
aprobar criterios, simulaciones, prototipos, pilotos y
documentación extensa.
En un proceso de evaluación formal se pueden utilizar tanto
criterios numéricos como no numéricos. Los criterios
numéricos utilizan pesos para reflejar la importancia relativa de
los criterios. Los criterios no numéricos utilizan una escala de
rangos subjetiva (p. ej., alto, medio, bajo). Las decisiones más
formales pueden requerir un estudio completo de alternativas.
Un proceso de evaluación formal identifica y evalúa
soluciones alternativas. La eventual selección de una solución
puede implicar
Análisis de decisiones y resolución 259
actividades iterativas de identificación y de evaluación. Pueden
combinarse partes de las alternativas identificadas, las tecnolo-
gías emergentes pueden cambiar las alternativas, y la situación
de negocio de los proveedores puede cambiar durante el
periodo de evaluación.
Una alternativa recomendada se acompaña de la documenta-
ción de métodos, criterios y alternativas seleccionadas y el
análisis razonado de la recomendación. La documentación se
distribuye a las partes interesadas relevantes; proporciona un
registro del proceso de evaluación formal y su análisis
razonado, que serán de utilidad para otros proyectos en los que
se identifiquen cuestiones similares.
Mientras algunas de las decisiones tomadas a lo largo de la
vida del proyecto implican la utilización de un proceso de
evaluación formal, otras no. Como se mencionó anteriormente,
deberían establecerse guías para determinar qué cuestiones
deberían estar sujetas a un proceso de evaluación formal.

PARA más INFORMACIÓN sobre cómo IDENTIFICAR, ANALIZAR y MITIGAR riesgos, consúl-
tese el árEA de proceso Gestión de Riesgos.
Dar
SG 1 Evaluar las alternativas.
SP 1.1 Establecer las guías para el análisis de decisiones.
SP 1.2 Establecer los criterios de evaluación.
SP 1.3 Identificar las soluciones alternativas.
SP 1.4 Seleccionar los métodos de evaluación.
SP 1.5 Evaluar las soluciones alternativas.
SP 1.6 Seleccionar las soluciones.
sG 1 evaLuar Las aLternativas

Las decisiones se basan en una evaluación de alternativas utilizando criterios
establecidos.
Las cuestiones que requieren un proceso de evaluación formal

pueden identificarse en cualquier momento. El objetivo debería
ser identificar las cuestiones tan pronto como sea posible para
maximizar el tiempo disponible para resolverlas.
sp 1.1 estableceR las guías paRa el análisis de decisiones
Establecer y mantener guías para determinar qué cuestiones están sujetas a un
proceso de evaluación formal.
No todas las decisiones son lo suficientemente significativas para

requerir un proceso de evaluación formal. La elección entre lo
trivial y lo realmente importante no está clara sin una orientación
explícita. Si una decisión es significativa o no, depende del
proyecto y de las circunstancias, y se determina con las guías
establecidas.
Algunas guías típicas para determinar cuándo se requiere un proceso de

evaluación formal son:
• Una decisión está directamente relacionada con cuestiones cuyo riesgo
sea de impacto medio a alto.
• Una decisión está relacionada con cambios a los productos de trabajo
bajo gestión de configuración.
• Una decisión causaría retrasos en el calendario en un cierto porcentaje
o cantidad de tiempo.
• Una decisión afecta a la capacidad del proyecto para conseguir sus
objetivos.
• Los costes del proceso de evaluación formal son razonables en
comparación con el impacto de la decisión.
• Existe una obligación legal durante una licitación.
• Cuando compiten los requisitos de atributos de calidad podrían
producir alternativas de arquitectura significativamente diferentes.
PARA más INFORMACIÓN sobre cómo EVALUAR, CATEGORIZAR y PRIORIZAR riesgos, con-
súltese el árEA de proceso Gestión de Riesgos.
Algunos ejemplos de actividades donde se puede utilizar un proceso de

evaluación formal son:
• Tomar decisiones que implican la adquisición de material, cuando el
20% de las partes del material constituyan el 80% de los costes totales
del material.
• Tomar decisiones de implementación de diseño cuando un fallo técnico
en el rendimiento pueda causar un fallo catastrófico (p. ej., elemento de
seguridad de vuelo).
• Tomar decisiones con el fin de reducir significativamente riesgos de
diseño, cambios en la ingeniería, tiempo de ciclo, tiempo de respuesta y
costes de producción (p. ej., utilizar modelos de litografía para evaluar
la forma y ajustar la capacidad antes de la entrega de los diagramas de
ingeniería y de las construcciones de producción).
1. Guías de cuándo aplicar un proceso de evaluación formal.
SUBPRÁCTICAS
1. Establecer guías para determinar cuándo utilizar un proceso de
eva- luación formal.
2. Incorporar la utilización de guías en el proceso definido según
proceda.
PARA más INFORMACIÓN sobre cómo ESTABLECER el proceso definido del pro-
yecto, consúltese el árEA de proceso Gestión INTEGRADA del Proyecto.
sp 1.2 estableceR los cRiteRios de evaluación

Establecer y mantener los criterios para evaluar las alternativas y la clasifica-
ción relativa de estos criterios.
Los criterios de evaluación proporcionan las bases para evaluar

las soluciones alternativas. Los criterios se clasifican de modo
que los criterios con mayor puntuación ejercen la mayor
influencia en la evaluación.
Este área de proceso es referenciada por muchas otras áreas
de proceso en el modelo y por muchos contextos en los cuales se
puede utilizar un proceso de evaluación formal. Por lo tanto, en
algunas situaciones se puede encontrar que los criterios ya han
sido definidos como parte de otro proceso. Esta práctica
específica no sugiere que se tengan que volver a realizar un
segundo desarrollo de estos criterios.
Un enunciado bien definido de la cuestión a tratar y de la
Dar
decisión a tomar centra el análisis a realizar. Dicho enunciado
también ayuda en la definición de los criterios de evaluación que
minimizan la po- sibilidad de que las decisiones se sitúen en
segundo plano, o que las razones para la toma de decisión se
ignoren. Las decisiones basadas en criterios que están
explícitamente definidos y establecidos, eliminan las barreras
para la aceptación por las partes interesadas.
1. Criterios de evaluación documentados.
2. Clasificaciones de la importancia de los criterios.
SUBPRÁCTICAS
1. Definir los criterios para evaluar las soluciones alternativas.
Los criterios deben ser trazables a los requisitos, escenarios, su-
puestos del caso de negocio, objetivos de negocio u otras fuentes
documentadas.
Algunos tipos de criterios a considerar son:

• Limitaciones tecnológicas.
• Impacto medioambiental.
• Riesgos.
• Valor para el negocio.
• Impacto sobre las prioridades.
• Costes totales de propiedad y del ciclo de vida.
2. Definir el rango y la escala para clasificar los criterios de
evaluación. Pueden establecerse escalas de importancia relativa
para los criterios de evaluación, con valores no numéricos o con
fórmulas que relacio-
nen el parámetro de evaluación con un peso numérico.
3. Clasificar los criterios.
Los criterios se clasifican de acuerdo al rango y a la escala
definidos para reflejar las necesidades, objetivos y prioridades
de las partes interesadas relevantes.
4. Evaluar los criterios y su importancia relativa.
5. Evolucionar los criterios de evaluación para mejorar su validez.
6. Documentar el análisis razonado para la selección y el rechazo de
los criterios de evaluación.
La documentación de los criterios de selección y del análisis
razonado puede ser necesaria para justificar soluciones o para
futuras referencias y usos.
sp 1.3 identificaR las soluciones alteRnativas

Identificar soluciones alternativas para tratar las cuestiones.
Se puede obtener un abanico más amplio de alternativas al

solicitar aportaciones a tantas partes interesadas como sea
posible. Las aportaciones de las partes interesadas con diferentes
habilidades y experiencias, pueden ayudar a los equipos a
identificar y a tratar supuestos, limitaciones y predisposiciones.
Las sesiones de tormenta de ideas pueden promover alternativas
innovadoras a través de una rápida in- teracción y realimentación.
Puede ocurrir que no se aporten suficientes soluciones
candidatas para su análisis. A medida que avance el análisis,
podrían añadirse otras alternativas a la lista de soluciones
candidatas potenciales. La ge- neración y consideración de
múltiples alternativas al inicio de un proceso de análisis de
decisiones y resolución incrementa la probabilidad de que pueda
tomarse una decisión aceptable, y que las consecuencias de la
decisión sean comprendidas.
1. Alternativas identificadas.
SUBPRÁCTICAS
1. Realizar una búsqueda bibliográfica.
Una búsqueda bibliográfica puede descubrir lo que otros han
realizado, tanto dentro como fuera de la organización. Esta
búsqueda puede proporcionar un entendimiento más profundo del
problema, alternativas a considerar, barreras para la
implementación, estudios de opciones existentes, y lecciones
aprendidas de decisiones similares.
2. Identificar otras alternativas a considerar, además de las
alternativas que pueden ser proporcionadas con la cuestión.
Los criterios de evaluación son un punto de partida eficaz para
identificar alternativas. Los criterios de evaluación identifican
prioridades de las partes interesadas relevantes y la importancia
de desafíos técni- cos, logísticos u otros.
Combinar los atributos clave de alternativas existentes puede
generar alternativas adicionales o algunas veces más sólidas.
Solicitar alternativas a las partes interesadas relevantes. Las
sesiones de tormenta de ideas, entrevistas y grupos de trabajo,
pueden utilizarse eficazmente para descubrir alternativas.
3. Documentar las alternativas propuestas.
sp 1.4 s eleccionaR los métodos de evaluación

Seleccionar métodos de evaluación.
Los métodos para evaluar las soluciones alternativas frente a los

criterios establecidos pueden variar desde simulaciones hasta la
Dar
utilización de modelos probabilísticos y la teoría de la decisión.
Estos métodos deberían ser seleccionados cuidadosamente. El
nivel de detalle de un método debería estar en proporción con el
coste, el calendario, el rendimiento y los impactos del riesgo.
Aunque muchos problemas pueden requerir sólo un método de
evalua- ción, ciertos problemas pueden requerir múltiples métodos.
Por ejemplo, las simulaciones pueden ampliar un estudio de mercado
para determinar qué alternativa de diseño es la que mejor cumple un
criterio dado.
1. Métodos de evaluación seleccionados.
SUBPRÁCTICAS
1. Seleccionar métodos en base al propósito de analizar una decisión y
a la disponibilidad de la información utilizada para dar soporte al
método.
Por ejemplo, los métodos utilizados para evaluar una solución cuando los
requisitos están pobremente definidos, pueden ser diferentes de los méto-
dos utilizados cuando los requisitos están bien definidos.
Algunos métodos de evaluación típicos son:

• Pruebas.
• Modelado y simulación.
• Estudios de ingeniería.
• Estudios de fabricación.
• Estudios de costes.
• Estudios de oportunidades de negocio.
• Encuestas.
• Extrapolaciones basadas en experiencias de campo y prototipos.
• Revisiones y comentarios de usuarios finales.
• Juicios proporcionados por un experto o grupos de expertos (p. ej.,
método Delphi).
2. Seleccionar los métodos de evaluación en base a su capacidad
para centrarse en los temas en cuestión, sin estar demasiado
influenciados por cuestiones secundarias.
Los resultados de las simulaciones pueden estar distorsionados
por actividades aleatorias en la solución, que no están
directamente relacionadas con los temas en cuestión.
3. Determinar las medidas necesarias para dar soporte al método
de evaluación.
Considerar el impacto en coste, calendario, rendimiento y riesgos.
sp 1.5 evaluaR las soluciones alteRnativas

Evaluar las soluciones alternativas utilizando criterios y métodos establecidos.
Evaluar las soluciones alternativas implica análisis, debate y

revisión. Algunas veces son necesarios ciclos iterativos de
análisis. Puede necesitarse análisis de soporte, experimentación,
creación de prototipos, pilotos o simulaciones, para justificar
calificaciones y conclusiones.
Con frecuencia, la importancia relativa de los criterios es
imprecisa y el efecto total sobre una solución no es manifiesta
hasta que se realiza el análisis. En los casos donde las
calificaciones resultantes difieren en cantidades relativamente
pequeñas, la mejor selección entre las soluciones alternativas
puede no estar clara. Debería fomentarse poner en duda los
criterios y los supuestos.
1. Resultados de la evaluación.
SUBPRÁCTICAS
1. Evaluar soluciones alternativas propuestas utilizando los
criterios de evaluación establecidos y los métodos seleccionados.
2. Evaluar supuestos relacionados con los criterios de evaluación y
la evidencia que sustenta las suposiciones.
3. Evaluar si la incertidumbre en los valores de las soluciones
alternativas afecta a la evaluación, y tratar estas
incertidumbres según proceda.
Por ejemplo, si la calificación varía entre dos valores, ¿es la
diferencia lo suficientemente significativa para distinguirla en el
conjunto de la solución final?, ¿la variación en la calificación
representa un riesgo de alto impacto? Para tratar estos aspectos,
entre otras cosas, pueden realizarse simulaciones, estudios
adicionales o pueden modificarse los criterios de evaluación.
4. Realizar simulaciones, modelados, prototipos y pilotos, según sea
necesario, para ejercitar los criterios y los métodos de
evaluación y las soluciones alternativas.
Los criterios no probados, su importancia relativa y los datos o
funciones de soporte pueden causar que se cuestione la validez
de las soluciones. Los criterios y sus prioridades y escalas
relativas pueden probarse con ensayos frente a un conjunto de
alternativas. Estos ensayos de un conjunto escogido de
criterios, permiten la evaluación del impacto acumulado de los
criterios para una solución. Si los ensayos revelan problemas,
podrían considerarse diferentes criterios o alternativas para
evitar predisposiciones.
5. Considerar nuevas soluciones alternativas, criterios o métodos si
las alternativas propuestas no pasan la prueba; repetir las
evaluaciones hasta que las alternativas pasen la prueba.
6. Documentar los resultados de la evaluación.
Documentar la razón fundamental para agregar nuevas
alternativas o métodos y cambios a los criterios, así como también
los resultados de las evaluaciones intermedias.
Dar
sp 1.6 seleccionaR las soluciones
Seleccionar las soluciones a partir de alternativas en base a criterios de
evaluación.
Seleccionar soluciones implica ponderar los resultados de la

evalua- ción de las alternativas. Se deberían evaluar los riesgos
asociados con la implementación de las soluciones.

1. Soluciones recomendadas para tratar las cuestiones significativas.
SUBPRÁCTICAS
1. Evaluar los riesgos asociados con la implementación de la
solución recomendada.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR, ANALIZAR y MITIGAR riesgos,
consúltese el árEA de proceso Gestión de Riesgos.
Con frecuencia las decisiones deben realizarse con información
incompleta. Puede existir un riesgo substancial asociado con la
decisión porque se tiene información incompleta.
Cuando las decisiones deben tomarse de acuerdo a un calendario
es- pecífico, puede que no se disponga del tiempo ni los recursos
necesarios para recoger la información completa. Por
consiguiente, las decisiones arriesgadas realizadas con
información incompleta pueden requerir un nuevo análisis
posterior. Los riesgos identificados debe- rían monitorizarse.
2. Documentar y comunicar a las partes interesadas relevantes los
resultados y el análisis razonado para la solución recomendada.
Es importante registrar porqué una solución fue seleccionada y
por- qué otra solución fue rechazada.
GESTIÓN INTEGRADA DEL PROYECTO

Un área de proceso de Gestión de Proyectos en el nivel de madurez 3
Propósito
El propósito de la Gestión Integrada del Proyecto (IPM) es
establecer y gestionar el proyecto y la involucración de las partes
interesadas relevantes de acuerdo a un proceso integrado y
definido, que se adapta a partir del conjunto de procesos estándar
La Gestión Integrada del Proyecto implica las siguientes actividades:
 Establecer el proceso definido del proyecto al inicio del
mismo, mediante la adaptación del conjunto de procesos
 Gestionar el proyecto utilizando el proceso definido del proyecto.
 Establecer el entorno de trabajo para el proyecto, basándose en
los estándares del entorno de trabajo de la organización.
 Establecer los equipos que tienen la tarea de conseguir los
objetivos del proyecto.
 Utilizar y contribuir a los activos de proceso de la organización.
 Posibilitar que los intereses de las partes interesadas
relevantes se identifiquen, se consideren y, cuando sea
apropiado, se traten durante el proyecto.
 Asegurar que las partes interesadas relevantes (1) realizan
IPM
sus tareas de forma coordinada y oportuna; (2) tratan los
requisitos, los planes, los objetivos, los problemas y los
riesgos del proyecto;
(3) cumplen sus compromisos; (4) e identifican, siguen y
resuelven las cuestiones de coordinación.
El proceso definido e integrado que se adapta a partir del

conjunto de procesos estándar de la organización, se denomina el
proceso definido del proyecto (véase la definición de “proyecto”
en el glosario).
La gestión del esfuerzo, del coste, del calendario, del
personal, de los riesgos y de otros factores del proyecto, está
ligada a las tareas del proceso definido del proyecto. La
implementación y la gestión del
267
proceso definido del proyecto se describen normalmente en el
plan de proyecto. Ciertas actividades pueden cubrirse en otros
planes que afecten al proyecto, tales como el plan de
aseguramiento de la calidad, la estrategia de gestión de riesgos y el
plan de gestión de configuración. Puesto que el proceso definido
para cada proyecto se adapta a par-
tir del conjunto de procesos estándar de la organización, la
variabilidad entre los proyectos normalmente se reduce y los
proyectos pueden compartir fácilmente los activos de proceso, los
datos y las lecciones aprendidas.
Este área de proceso también trata la coordinación de todas las actividades

asociadas con el proyecto, tales como:
• Actividades de desarrollo (p. ej., desarrollo de requisitos, diseño,
verificación).
• Actividades de servicio (p. ej., entrega, help desk, operaciones, contacto
con el cliente).
• Actividades de adquisición (p. ej., licitación, monitorización del
contrato, transición a operación).
• Actividades de soporte (p. ej., gestión de configuración, documentación,
marketing, formación).
Las interfaces e interacciones de trabajo entre las partes
interesadas relevantes internas y externas al proyecto, se
planifican y gestionan para asegurar la calidad e integridad del
esfuerzo global. Las partes interesadas relevantes participan,
según proceda, en la definición del proceso definido del proyecto
y del plan de proyecto. Las revisiones y los intercambios con las
partes interesadas relevantes, se realizan periódicamente para
asegurar que las cuestiones de coordinación reciben la atención
apropiada y que cada uno de los involucrados en el proyecto es
realmente consciente del estado, de los planes y de las
actividades (véase la definición de “parte interesada relevante” en
el glosario). Durante la definición del proceso definido del
proyecto, se crean las interfaces formales según sea necesario,
para asegurar que se producen la coordinación y colaboración
apropiadas.
Este área de proceso se aplica en cualquier estructura de la orga-
nización, incluyendo los proyectos que se estructuran como
organizaciones lineales, organizaciones matriciales o equipos.
La terminología debería interpretarse apropiadamente para la
estructura de la organi- zación en vigor.

PARA más INFORMACIÓN sobre cómo rEALIZAR revisiones entre PARes, consúltese el
árEA de proceso VERIFICACIÓN.
PArA más informAción sobre cómo AlineAr lAS ActividAdes de Análisis y medición y pro-
porcionAr resultAdos de medición, consúltese el áreA de proceso Medición y Análisis.
Gestión integrada del proyecto 269
PARA más INFORMACIÓN sobre cómo ESTABLECER y MANTENER un conjunto UTILIZABLE de
ACTIVOS de proceso de LA ORGANIZACIÓN, de los ESTÁNDARes del entorno de TRABAJO, y
de GUÍAS y rEGLAS PARA los equipos de LA ORGANIZACIÓN, consúltese el árEA de proceso
Definición de Procesos de LA OrGANIZACIÓN.
PARA más INFORMACIÓN sobre cómo MONITORIZAR el proyecto frente AL PLAN, consúl-
tese el árEA de proceso MONITORIZACIÓN y Control del Proyecto.
árEA de proceso PLANIFICACIÓN del Proyecto.

SG 1 Utilizar el proceso definido del proyecto.
SP 1.1 Establecer el proceso definido del proyecto.
SP 1.2 Utilizar los activos de proceso de la organización para planificar las actividades
del proyecto.
SP 1.3 Establecer el entorno de trabajo del proyecto.
SP 1.4 Integrar los planes.
SP 1.5 Gestionar el proyecto utilizando planes integrados.
SP 1.6 Establecer los equipos.
SP 1.7 Contribuir a los activos de proceso de la organización.
SG 2 Coordinar y colaborar con las partes interesadas relevantes.
SP 2.1 Gestionar la involucración de las partes interesadas.
SP 2.2 Gestionar las dependencias.
SP 2.3 Resolver las cuestiones de coordinación.

sG 1 utiLizar eL proceso definido deL proyecto
El proyecto se lleva a cabo utilizando un proceso definido adaptado a partir del
El proceso definido del proyecto incluye aquellos procesos del

conjunto de procesos estándar de la organización que tratan todos
los procesos necesarios para adquirir, desarrollar, mantener o
entregar el producto.
Los procesos del ciclo de vida relacionados con el producto,
tales como los procesos de fabricación y de soporte, se desarrollan
simultá- neamente con el producto.
IPM
sp 1.1 estableceR el pRoceso definido del pRoyecto
Establecer y mantener el proceso definido del proyecto desde su arranque y a lo
largo de la vida del proyecto.
PARA más INFORMACIÓN sobre cómo ESTABLECER los ACTIVOS de proceso de LA ORGANI-
ZACIÓN y ESTABLECER el repositorio de medición de LA ORGANIZACIÓN, consúltese el
árEA de proceso Definición de Procesos de LA OrGANIZACIÓN.
PARA más INFORMACIÓN sobre cómo DESPLEGAR los ACTIVOS de proceso y los procesos
ESTÁNDAR de LA ORGANIZACIÓN, consúltese el árEA de proceso Enfoque en Procesos de
LA OrGANIZACIÓN.
El proceso definido del proyecto se compone de procesos
definidos que forman un ciclo de vida integrado y coherente para
el proyecto.
El proceso definido del proyecto debería satisfacer los
requisitos contractuales, las necesidades de operación, las
oportunidades y las limitaciones del proyecto. Este proceso está
diseñado para proporcionar el mejor ajuste a las necesidades del
proyecto.
Un proceso definido del proyecto se basa en los siguientes factores:
 Requisitos de las partes interesadas.

 Compromisos.
 Necesidades y objetivos del proceso de la organización.
 El conjunto de procesos estándar y guías de adaptación de la
organización.
 El entorno operacional.
 El entorno del negocio.
Establecer el proceso definido al inicio del proyecto, ayuda a

asegurar que el personal del proyecto y las partes interesadas
relevantes implementan un conjunto de actividades necesarias
para establecer eficientemente un conjunto inicial de requisitos y
planes para el proyecto. Conforme el proyecto progresa, se
elabora y modifica la des- cripción del proceso definido del
proyecto, para satisfacer mejor los requisitos del proyecto y de
las necesidades y objetivos de proceso de la organización.
También, dado que el conjunto de procesos estándar de la
organización cambia, el proceso definido del proyecto puede ne-
cesitar ser modificado.

1. El proceso definido del proyecto.
SUBPRÁCTICAS
1. Seleccionar un modelo de ciclo de vida a partir de los
disponibles en los activos de proceso de la organización.
Algunos ejemplos de características del proyecto que podrían afectar a la

selección de los modelos de ciclo de vida son:
• Tamaño o complejidad del proyecto.
• Estrategia del proyecto.
• Experiencia y familiaridad del personal con la implementación del proceso.
• Limitaciones, tales como el tiempo de ciclo y los niveles aceptables de
defectos.
• Disponibilidad de los clientes para responder preguntas y proporcionar
realimentación sobre los incrementos.
• Claridad de los requisitos.
• Expectativas del cliente.
2. Seleccionar los procesos estándar que mejor se ajusten a las
necesidades del proyecto a partir del conjunto de procesos
3. Adaptar el conjunto de procesos estándar de la organización y
otros activos de proceso de la organización, de acuerdo con las
guías de adaptación, para elaborar el proceso definido del
proyecto.
Algunas veces los modelos de ciclo de vida y los procesos
estándar disponibles son inadecuados para cumplir las
necesidades del proyecto. En estos casos, el proyecto debería
pedir la aprobación para desviarse de lo que es requerido por la
organización. Las excepciones se proporcionan para este
propósito.
El proceso definido del proyecto puede incluir adaptaciones de
las medidas comunes de la organización y especificar medidas
adicionales para cumplir las necesidades de información del
proyecto.
4. Utilizar otros artefactos de la biblioteca de activos de proceso
de la organización, según proceda.
Otros artefactos pueden ser:

• Documentos de lecciones aprendidas.
• Plantillas.
• Documentos de ejemplo.
• Modelos de estimación.
5. Documentar el proceso definido del proyecto.
El proceso definido del proyecto cubre todas las actividades del
proyecto y sus interfaces con las partes interesadas relevantes.
Algunos ejemplos de actividades del proyecto son:

• Planificación del proyecto.
• Monitorización del proyecto.
• Gestión de proveedores.
• Aseguramiento de la calidad.
• Gestión de riesgos.
• Análisis de decisiones y resolución.
IPM
• Desarrollo de requisitos.
• Gestión de requisitos.
• Desarrollo y soporte del producto.
• Revisión de código.
• Licitación.
6. Realizar revisiones entre pares del proceso definido del proyecto.

PARA más INFORMACIÓN sobre cómo rEALIZAR revisiones entre PARes, consúl-
tese el árEA de proceso VERIFICACIÓN.
7. Modificar el proceso definido del proyecto según sea necesario.
sp 1.2 utilizaR los activos de pRoceso de la oRganización paRa planificaR las

actividades del pRoyecto
Utilizar los activos de proceso de la organización y el repositorio de mediciones

para estimar y planificar las actividades del proyecto.
ZACIÓN, consúltese el árEA de proceso Definición de Procesos de LA OrGANIZACIÓN.
Cuando estén disponibles, utilice los resultados de las actividades

de planificación y de ejecución anteriores como predictores del
alcance y riesgos relativos al esfuerzo que se está estimando.

1. Estimaciones de proyecto.
2. Planes de proyecto.
SUBPRÁCTICAS
1. Utilizar las tareas y los productos de trabajo del proceso definido del
proyecto como base para estimar y planificar las actividades del
proyecto.
Una comprensión de las relaciones entre las diferentes tareas y
productos de trabajo del proceso definido del proyecto, y de los
roles desempeñados por las partes interesadas relevantes, es una
base para desarrollar un plan realista.
2. Utilizar el repositorio de mediciones de la organización para
estimar los parámetros de planificación del proyecto.
Esta estimación normalmente incluye:

• Datos históricos apropiados de este proyecto o proyectos similares.
• Semejanzas y diferencias entre el proyecto actual y aquellos proyectos
cuyos datos históricos serán utilizados.
• Datos históricos validados.
• Razonamientos, supuestos y lógica utilizados para seleccionar los datos
históricos.
• Razonamiento de una amplia base de participantes experimentados
del proyecto.
Algunos ejemplos de parámetros que se consideran para semejanzas y di-

ferencias son:
• Atributos de producto de trabajo y de tarea.
• Dominio de aplicación.
• Experiencia de las personas.
• Enfoques de diseño y de desarrollo.
• Entorno operacional.
Algunos ejemplos de datos contenidos en el repositorio de mediciones de

la organización son:
• Tamaño de los productos de trabajo u otros atributos de producto de
trabajo.
• Esfuerzo.
• Coste.
• Calendario.
• Dotación de personal.
• Tiempo de respuesta.
• Capacidad del servicio.
• Desempeño del proveedor.
• Defectos.
sp 1.3 estableceR el entoRno de tRabajo del pRoyecto

Establecer y mantener el entorno de trabajo del proyecto en base a los estánda-
res de entorno de trabajo de la organización.
Un entorno de trabajo apropiado para un proyecto comprende

una infraestructura de instalaciones, herramientas y
equipamiento, que las personas necesitan para realizar su trabajo
eficazmente en el apoyo de los objetivos de negocio y del
proyecto. El entorno de trabajo y sus componentes se mantienen
en un nivel de rendimiento y de fiabilidad del entorno de
trabajo, indicado en los estándares de entorno de trabajo de la
organización. Según sea requerido, el entorno de trabajo del
proyecto o de alguno de sus componentes puede ser desarrollado
internamente o adquirido de fuentes externas.
El entorno de trabajo del proyecto podría abarcar los entornos
para la integración, verificación y validación del producto o éstos
podrían ser entornos separados.
PArA más informAción sobre cómo estAblecer y mAntener el entorno de integrA-
ción del producto pArA el proyecto, consúltese lA prácticA específicA EstAblecer
el entorno de integrAción del producto en el áreA de proceso IntegrAción del
Producto.
IPM
PARA más INFORMACIÓN sobre cómo ESTABLECER y MANTENER el entorno de VALIDACIÓN
PARA el proyecto, consúltese LA PRÁCTICA ESPECÍFICA ESTABLECER el entorno de VALIDA-
ción en el árEA de proceso VALIDACIÓN.
PARA más INFORMACIÓN sobre cómo ESTABLECER y MANTENER el entorno de VERIFICA-
ción PARA el proyecto, consúltese LA PRÁCTICA ESPECÍFICA ESTABLECER el entorno de
VERIFICACIÓN en el árEA de proceso VERIFICACIÓN.
PARA más INFORMACIÓN sobre cómo ESTABLECER ESTÁNDARes del entorno de TRABAJO,
consúltese LA PRÁCTICA ESPECÍFICA ESTABLECER los ESTÁNDARes del entorno de TRABAJO
en el árEA de proceso Definición de Procesos de LA OrGANIZACIÓN.
Ejemplo de productos de TRABAJO
1. Equipamiento y herramientas para el proyecto.
2. Manuales de instalación, operación y mantenimiento del
entorno de trabajo del proyecto.
3. Encuestas a usuarios y resultados.
4. Registros de utilización, rendimiento y mantenimiento.
5. Servicios de soporte para el entorno de trabajo del proyecto.
SUBPRÁCTICAS
1. Planificar, diseñar e instalar un entorno de trabajo para el
proyecto. Los aspectos críticos del entorno del trabajo del
proyecto son, como en cualquier otro producto, dictados por los
requisitos. La funciona-
lidad y los atributos de calidad del entorno de trabajo, se
exploran con el mismo rigor que para cualquier otro proyecto de
desarrollo de producto.
Puede ser necesario establecer un equilibrio entre los atributos de calidad,

los costes y los riesgos. Algunos ejemplos de cada uno son:
• Las consideraciones de los atributos de calidad pueden incluir
aspectos de comunicación oportuna, seguridad, protección y capacidad
de mantenimiento.
• Los costes pueden incluir desembolsos de capital, formación, una
estructura de soporte; desmontaje y eliminación de los entornos
existentes; y la operación y mantenimiento del entorno.
• Los riesgos pueden incluir interrupciones del flujo de trabajo y del
proyecto.
Algunos ejemplos de equipamiento y herramientas son:

• Software de ofimática.
• Software de soporte a la toma de decisiones.
• Herramientas de gestión de proyectos.
• Equipamiento de pruebas y evaluación.
• Herramientas de gestión de requisitos y herramientas de diseño.
• Herramientas de gestión de configuración.
• Herramientas de evaluación.
• Herramientas de integración.
• Herramientas de pruebas automatizadas.
2. Proporcionar mantenimiento y soporte operacional continuos
para el entorno de trabajo del proyecto.
El mantenimiento y el soporte del entorno de trabajo pueden
realizarse bien con las habilidades que se encuentran dentro de
la organiza- ción o bien con las contratadas fuera de la
organización.
Algunos ejemplos de enfoques de mantenimiento y soporte son:

• Contratar personas para realizar el mantenimiento y soporte.
• Formar a personas para realizar el mantenimiento y soporte.
• Contratar el mantenimiento y soporte.
• Crear usuarios expertos en las herramientas seleccionadas.
3. Mantener la calidad de los componentes del entorno de trabajo
del proyecto.
Los componentes incluyen el software, bases de datos,
hardware, herramientas, equipamiento de pruebas y
documentación apropiada. La calificación del software incluye
las certificaciones apropiadas. La calificación del hardware y del
equipamiento de pruebas incluye los registros de calibración y de
ajuste, y la trazabilidad con los estándares de calibración.
4. Revisar periódicamente hasta qué punto el entorno de trabajo
está cumpliendo con las necesidades del proyecto y dando
soporte a la colaboración, y actuar según sea apropiado.
Algunos ejemplos de acciones que podrían realizarse son:

• Añadir nuevas herramientas.
• Adquirir redes, equipamiento, formación y soporte adicionales.
sp 1.4 integRaR los planes

Integrar el plan del proyecto y otros planes que afecten al proyecto para descri-
bir el proceso definido del proyecto.
PARA más INFORMACIÓN sobre cómo ESTABLECER los ACTIVOS de proceso de LA ORGA-
NIZACIÓN y, concrETAMENTE, ESTABLECER el repositorio de mediciones de LA ORGANI-
PARA más INFORMACIÓN sobre cómo ESTABLECER LAS NECESIDADES de procesos de LA

orGANIZACIÓN y DETERMINAR LAS OPORTUNIDADES de MEJORA de procesos, consúltese el
árEA de proceso Enfoque en Procesos de LA OrGANIZACIÓN.
IPM
Esta práctica específica amplía las prácticas específicas para el

establecimiento y mantenimiento de un plan de proyecto para
tratar las actividades adicionales de planificación, tales como
incorporar el proceso definido del proyecto, coordinar con las
partes interesadas relevantes, utilizar los activos de proceso de la
organización, incorporar planes para las revisiones entre pares y
establecer criterios objetivos de entrada y de salida para las
tareas.
El desarrollo del plan de proyecto debería tener en cuenta las
necesidades actuales y previstas, los objetivos y los requisitos de
la organi- zación, del cliente, de los proveedores y de los usuarios
finales, según proceda.

1. Planes integrados.
SUBPRÁCTICAS
1. Integrar, con el plan de proyecto, otros planes que afecten al proyecto.
Otros planes que afectan al plan de proyecto pueden ser:

• Planes de aseguramiento de la calidad.
• Estrategias de gestión de riesgos.
• Planes de verificación y validación.
• Planes de transición a operaciones y de soporte.
• Planes de gestión de configuración.
• Planes de documentación.
• Planes de formación del personal.
• Planes de instalaciones y logística.
2. Incorporar al plan de proyecto las definiciones de las medidas y

de las actividades de medición para gestionar el proyecto.
Algunos ejemplos de medidas que serían incorporadas son:

• Conjunto de medidas comunes de la organización.
• Medidas adicionales específicas del proyecto.
PARA más INFORMACIÓN sobre cómo DESARrOLLAR y SUSTENTAR UNA CAPACIDAD

de medición PARA DAR soporte A LAS NECESIDADES de INFORMACIÓN de LA ges-
tión, consúltese el árEA de proceso Medición y Análisis.
3. Identificar y analizar los riesgos de la interfaz del proyecto y del
producto.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR y ANALIZAR riesgos, consúl-
tese el árEA proceso Gestión de Riesgos.
Algunos ejemplos de riesgos de la interfaz del proyecto y del producto son:

• Descripciones incompletas de la interfaz.
• Indisponibilidad de herramientas, de proveedores o de equipamiento
de pruebas.
• Falta de disponibilidad de Productos Comerciales (COTS).
• Interfaces de equipo inadecuadas o ineficaces.
4. Planificar las tareas en una secuencia que tenga en cuenta los
factores críticos del desarrollo y los factores de la entrega, y los
Algunos ejemplos de factores considerados en la planificación son:

• Tamaño y complejidad de las tareas.
• Necesidades del cliente y de los usuarios finales.
• Disponibilidad de recursos críticos.
• Disponibilidad de personal clave.
• Cuestiones de integración y de pruebas.
5. Incorporar planes para realizar revisiones entre pares en los

productos de trabajo del proceso definido del proyecto.
PARA más INFORMACIÓN sobre cómo rEALIZAR LAS revisiones entre PARes, con-
súltese el árEA de proceso VERIFICACIÓN.
6. Incorporar la formación necesaria para realizar el proceso
definido del proyecto en los planes de formación del proyecto.
Normalmente, esta tarea incluye la negociación con el grupo de
for- mación de la organización sobre el soporte que
proporcionará.
7. Establecer criterios objetivos de entrada y de salida, para
autorizar el inicio y la terminación de las tareas descritas en la
estructura de descomposición del trabajo (WBS).
PARA más INFORMACIÓN sobre cómo ESTIMAR el ALCANCE del proyecto, consúl-
tese el árEA de proceso PLANIFICACIÓN del Proyecto.
8. Asegurar que el plan del proyecto es adecuadamente compatible
con los planes de las partes interesadas relevantes.
Normalmente, el plan y los cambios a éste, serán revisados para
demostrar su compatibilidad.
9. Identificar cómo serán resueltos los conflictos que surjan entre
las partes interesadas relevantes.
sp 1.5 gestionaR el pRoyecto utilizando planes integRados

Gestionar el proyecto utilizando el plan de proyecto, otros planes que afecten
al proyecto y el proceso definido del proyecto.
IPM
PArA más informAción sobre cómo estAblecer l AS necesidAdes del proceso de

lA Org AnizAción, desplegAr los Activos de proceso de lA OrgAniz Ación y los
procesos estándAr, consúltese el áre A de proceso Enfoque en Procesos de lA
OrgAnizAción.
PARA más INFORMACIÓN sobre cómo proporCIONAR y comprender el progreso del
proyecto, de FORMA que PUEDAN ser TOMADAS LAS ACCIONES corrECTIVAS APROPIA-
DAS, CUANDO el rendimiento del proyecto se desvíe SIGNIFICATIVAMENTE del PLAN,
consúltese el árEA de proceso MONITORIZACIÓN y Control del Proyecto.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR, ANALIZAR y MITIGAR riesgos, consúl-
tese el árEA de proceso Gestión de Riesgos.

1. Productos de trabajo creados al realizar el proceso definido del
proyecto.
2. Medidas recogidas (es decir, reales) y registros o informes de estado.
3. Requisitos, planes y compromisos modificados.
4. Planes integrados.
SUBPRÁCTICAS
1. Implementar el proceso definido del proyecto utilizando la
biblioteca de activos de proceso de la organización.
Esta tarea normalmente incluye las siguientes actividades:

• Incorporar al proyecto los artefactos de la biblioteca de activos de
proceso de la organización, según sea apropiado.
• Utilizar las lecciones aprendidas de la biblioteca de activos de proceso
de la organización, para gestionar el proyecto.
2. Monitorizar y controlar las actividades y los productos de
trabajo del proyecto, utilizando el proceso definido del
proyecto, el plan del proyecto y otros planes que afecten al
proyecto.
Esta tarea normalmente incluye las siguientes actividades:

• Usar los criterios definidos de entrada y de salida para autorizar el
inicio y determinar la terminación de las tareas.
• Monitorizar las actividades que podrían afectar significativamente a los
valores reales de los parámetros de planificación del proyecto.
• Seguir los parámetros de planificación del proyecto utilizando
umbrales medibles que inicien la investigación y las acciones
apropiadas.
• Monitorizar los riesgos de la interfaz del producto y del proyecto.
• Gestionar los compromisos externos e internos en base a los planes
para las tareas y los productos de trabajo del proceso definido del
proyecto.
Una comprensión de las relaciones entre las tareas y los

productos de trabajo del proceso definido del proyecto, así como
de los roles que desempeñan las partes interesadas relevantes,
junto con mecanismos de control bien definidos (p. ej., las
revisiones entre pares), logra mejor visibilidad del rendimiento
del proyecto y mejor control del proyecto.
3. Obtener y analizar las mediciones seleccionadas para gestionar
el proyecto y dar soporte a las necesidades de la organización.
PARA más INFORMACIÓN sobre cómo obtener DATOS de medición y ANALIZAR
DATOS de medición, consúltese el árEA de proceso Medición y Análisis.
4. Revisar y alinear periódicamente el rendimiento del proyecto
con las necesidades, objetivos y requisitos actuales y previstos
de la organi- zación, del cliente y de los usuarios finales, según
proceda.
Esta revisión incluye el alineamiento con las necesidades y los
objetivos del proceso de la organización.
Algunos ejemplos de acciones que logran el alineamiento son:

• Cambiar el calendario con ajustes apropiados a otros parámetros de
planificación y riesgos del proyecto.
• Cambiarlos requisitos o compromisos en respuesta a un cambio en las
oportunidades de mercado o necesidades del cliente y del usuario final.
• Terminar el proyecto, la iteración o la liberación.
5. Tratar las causas de cuestiones seleccionadas que puedan afectar
a los objetivos del proyecto.
Las cuestiones que requieren una acción correctiva son
determinadas y analizadas como en las prácticas específicas
Analizar las cuestiones y Llevar a cabo las acciones correctivas
del área de proceso Monitori- zación y Control del Proyecto.
Según sea apropiado, el proyecto puede revisar periódicamente
las cuestiones encontradas previamente en otros proyectos o en
fases anteriores del mismo y realizar un análisis causal de las
cuestiones seleccionadas, para determinar cómo prevenir la
recurrencia de cuestiones que puedan afectar significativamente a
los objetivos del proyecto. Los cambios del proceso del proyecto
implementados, como resultado de las actividades del análisis
causal, deberían evaluarse en cuanto a eficacia para asegurar que
el cambio del proceso ha prevenido la recurrencia y mejorado el
rendimiento.
sp 1.6 estableceR los equipos

Establecer y mantener equipos.
IPM
El proyecto se gestiona utilizando equipos que reflejen las reglas y
guías de la organización para la estructuración, formación y
operación de equipos (véase la definición de “equipo” en el
glosario).
La visión compartida del proyecto se establece antes del
establecimiento de la estructura del equipo, la cual puede
basarse en la WBS. Para pequeñas organizaciones, la
organización entera y las partes interesadas relevantes externas
pueden ser tratadas como un equipo.
PARA más INFORMACIÓN sobre cómo ESTABLECER y MANTENER LAS rEGLAS y GUÍAS de LA
orGANIZACIÓN PARA LA ESTRUCTURA, FORMACIÓN y OPERACIÓN de equipos, consúltese
LA PRÁCTICA ESPECÍFICA ESTABLECER LAS rEGLAS y GUÍAS PARA los equipos en el árEA de
proceso Definición de Procesos de LA OrGANIZACIÓN.
Una de las mejores formas de asegurar la coordinación y la
colabo- ración con las partes interesadas relevantes es incluirlas
en un equipo. En un entorno del cliente que requiera la
coordinación entre múl- tiples organizaciones de desarrollo de
servicios o de productos, es importante establecer un equipo
con representación de todas las partes que afecten al éxito
global. Tal representación ayuda a asegurar una colaboración
eficaz a través de estas organizaciones, incluyendo la re-
solución oportuna de cuestiones de coordinación.

1. Visión compartida documentada.
2. Lista de miembros asignados a cada equipo.
3. Estatutos del equipo.
4. Informes periódicos del estado del equipo.
SUBPRÁCTICAS
1. Establecer y mantener la visión compartida del proyecto.
Cuando se crea una visión compartida, es crítico comprender las
interfaces entre el proyecto y las partes interesadas externas al
proyecto. La visión debería compartirse entre las partes
interesadas relevantes para obtener su acuerdo y compromiso.
2. Establecer y mantener la estructura del equipo.
La WBS del proyecto, el coste, el calendario, los riesgos del
proyecto, los recursos, las interfaces, el proceso definido del
proyecto y las guías de la organización se evalúan para establecer
una estructura apropiada del equipo, incluyendo las
responsabilidades, las autoridades y las interrelaciones del
equipo.
3. Establecer y mantener cada equipo.
El establecimiento y mantenimiento de los equipos abarca la
elección de los líderes y miembros del equipo y el
establecimiento de los estatutos de cada equipo. También
implica proporcionar los recursos requeridos para lograr las
tareas asignadas al equipo.
4. Evaluar periódicamente la estructura y composición del equipo.
Los equipos deberían monitorizarse para detectar la no alineación
del trabajo a través de los diferentes equipos, las interfaces
gestionadas incorrectamente, y la falta de correspondencia de
las tareas a los miembros del equipo. Cuando el desempeño del
equipo o del proyecto no cubre las expectativas, es necesario
llevar a cabo acciones correctivas.
sp 1.7 contRibuiR a los activos de pRoceso de la oRganización

Contribuir con experiencias relativas al proceso a los activos de proceso de la
organización.
ZACIÓN, ESTABLECER el repositorio de mediciones de LA ORGANIZACIÓN, y ESTABLECER LA
BIBLIOTECAde ACTIVOS de proceso de LA ORGANIZACIÓN, consúltese el árEA de proceso
Definición de Procesos de LA OrGANIZACIÓN.
PARA más INFORMACIÓN sobre cómo INCORPORAR EXPERIENCIAS en los ACTIVOS de pro-
ceso de LA ORGANIZACIÓN, consúltese el árEA de proceso Enfoque en Procesos de LA
OrGANIZACIÓN.
Esta práctica específica trata la contribución de información
desde los procesos en el proceso definido del proyecto a los
activos de proceso de la organización.

1. Mejoras propuestas a los activos de proceso de la organización.
2. Medidas reales del proceso y del producto recogidas en el proyecto.
3. Documentación (p. ej., descripciones ejemplares de proceso,
planes, módulos de formación, listas de comprobación, lecciones
aprendidas).
4. Artefactos de proceso asociados a la adaptación y la
implementación del conjunto de procesos estándar de la
organización en el proyecto.
SUBPRÁCTICAS
1. Proponer mejoras a los activos de proceso de la organización.
2. Almacenar medidas del proceso y del producto en el repositorio
de mediciones de la organización.
PARA más INFORMACIÓN sobre cómo obtener DATOS de medición, consúltese
el árEA de proceso Medición y Análisis.
PARA más INFORMACIÓN sobre cómo MONITORIZAR los PARÁMETRos de LA PLA-
NIFICACIÓN del proyecto, consúltese el árEA de proceso MONITORIZACIÓN y
Control del Proyecto.
PARA más INFORMACIÓN sobre cómo PLANIFICAR LA gestión de los DATOS, con-
súltese el árEA de proceso PLANIFICACIÓN del Proyecto.
Estas medidas del proceso y del producto normalmente son:

• Datos de la planificación.
• Datos de la replanificación.
IPM
Algunos ejemplos de datos registrados por el proyecto son:
• Descripciones de tarea.
• Supuestos.
• Estimaciones.
• Estimaciones modificadas.
• Definiciones de los datos y de las medidas registradas.
• Medidas.
• Información de contexto que relaciona las medidas con las actividades
realizadas y con los productos de trabajo producidos.
• Información asociada necesaria para reconstruir las estimaciones,
evaluar si son razonables y derivar estimaciones para el trabajo nuevo.
3. Enviar la documentación para su posible inclusión en la
biblioteca de activos de proceso de la organización.
Algunos ejemplos de documentación son:

• Modelos de descripciones de proceso.
• Módulos de formación.
• Modelos de planes.
• Listas de comprobación y plantillas.
• Interfaces del repositorio del proyecto.
• Configuraciones de la herramienta.
4. Documentar las lecciones aprendidas del proyecto para su

inclusión en la biblioteca de activos de proceso de la
organización.
5. Proporcionar los artefactos de proceso asociados con la
adaptación e implementación del conjunto de procesos estándar
de la organiza- ción en apoyo de las actividades de
monitorización del proceso de la organización.
PARA más INFORMACIÓN sobre LAS ACTIVIDADES de LA ORGANIZACIÓN PARA
comprender el ALCANCE del despliegue de los procesos ESTÁNDAR sobre los
proyectos nuevos y existentes, consúltese LA PRÁCTICA ESPECÍFICA Monito-
RIZAR LA IMPLEMENTACIÓN en el árEA de proceso Enfoque en Procesos de LA
OrGANIZACIÓN.
sG 2 coordinar y coLaborar con Las partes interesadas reLevantes

La coordinación y la colaboración entre el proyecto y las partes interesadas re-
levantes se llevan a cabo.
sp 2.1 gestionaR la involucRación de las paRtes inteResadas Relevantes

Gestionar la involucración en el proyecto de las partes interesadas relevantes.
La involucración de las partes interesadas se gestiona de acuerdo

con el plan integrado y el proceso definido del proyecto.
PARA más INFORMACIÓN sobre cómo PLANIFICAR LA INVOLUCRACIÓN de LAS PARTES inte-
rESADAS y obtener el compromiso con el PLAN, consúltese el árEA de proceso PLANI-
FICACIÓN del Proyecto.

1. Agendas y calendarios para las actividades de colaboración.
2. Recomendaciones para resolver cuestiones de las partes
3. Cuestiones documentadas (p. ej., cuestiones con los requisitos
de las partes interesadas, requisitos de producto y de
componentes de producto, arquitectura del producto, diseño del
producto).
SUBPRÁCTICAS
1. Coordinar con las partes interesadas relevantes quién debería
participar en las actividades del proyecto.
Las partes interesadas relevantes ya deberían estar identificadas
en el plan del proyecto.
2. Asegurar que los productos de trabajo que se producen para
satisfacer los compromisos cumplen los requisitos de los
receptores.
PARA más INFORMACIÓN sobre cómo VERIFICAR los productos de TRABAJO selec-
CIONADOS, consúltese el árEA de proceso VERIFICACIÓN.
Los productos de trabajo producidos para satisfacer los

compromisos pueden ser servicios.
Esta tarea normalmente incluye:
Revisar, demostrar o probar, según proceda, cada
producto de trabajo producido por las partes interesadas
relevantes.
Revisar, demostrar o probar, según proceda, cada
producto del trabajo producido por el proyecto para
otros proyectos con los representantes de los proyectos
que reciben el producto de trabajo.
Resolver las cuestiones relacionadas con la aceptación de
los productos de trabajo.
3. Desarrollar recomendaciones y coordinar las acciones para
resolver los malentendidos y los problemas con los requisitos.
sp 2.2 gestionaR las dependencias
Participar con las partes interesadas relevantes para identificar, negociar y se-
guir las dependencias críticas.

1. Defectos, cuestiones y elementos de acción que resultan de las
revisiones con las partes interesadas relevantes.
2. Dependencias críticas.
3. Compromisos para tratar las dependencias críticas.
IPM
4. Estado de las dependencias críticas.
SUBPRÁCTICAS
1. Llevar a cabo revisiones con las partes interesadas relevantes.
2. Identificar cada dependencia crítica.
3. Establecer y planificar las fechas necesarias para cada
dependencia crítica en base al calendario del proyecto.
4. Revisar y acordar los compromisos para tratar cada dependencia
crí- tica con aquellos que son responsables de proporcionar o
recibir el producto de trabajo.
5. Documentar las dependencias críticas y los compromisos.
La documentación de los compromisos normalmente incluye:

• Descripción del compromiso.
• Identificación de quién hizo el compromiso.
• Identificación de quién es responsable de satisfacer el compromiso.
• Especificación de cuándo será satisfecho el compromiso.
• Especificación de los criterios para determinar si el compromiso ha sido
satisfecho.
6. Seguir las dependencias críticas y los compromisos, y realizar

acciones correctivas según proceda.
PARA más INFORMACIÓN sobre cómo MONITORIZAR los compromisos, consúl-
Normalmente, seguir las dependencias críticas incluye:

• Evaluar los efectos de la finalización temprana y tardía para posibles
impactos en futuras actividades e hitos.
• Resolver los problemas reales y potenciales con las partes
responsables siempre que sea posible.
• Escalar a las partes correspondientes los problemas reales y
potenciales que no pueden resolverse por el individuo o grupo
responsable.
sp 2.3 ResolveR las cuestiones de cooRdinación

Resolver las cuestiones con las partes interesadas relevantes.
Algunos ejemplos de cuestiones de coordinación son:

• Defectos en los requisitos del producto y de componentes de producto,
y en el diseño.
• Dependencias y compromisos críticos tardíos.
• Problemas a nivel de producto.
• Falta de disponibilidad de recursos críticos o personal.

1. Cuestiones de coordinación con las partes interesadas relevantes.
2. Estado de las cuestiones de coordinación con las partes
SUBPRÁCTICAS
1. Identificar y documentar las cuestiones.
2. Comunicar las cuestiones a las partes interesadas relevantes.
3. Resolver las cuestiones con las partes interesadas relevantes.
4. Escalar a los gestores apropiados las cuestiones que no pueden
resolverse con las partes interesadas relevantes.
5. Seguir las cuestiones hasta su cierre.
6. Comunicar a las partes interesadas relevantes el estado y la
resolu- ción de las cuestiones.
IPM
MEDICIÓN Y ANÁLISIS
Propósito
El propósito de Medición y Análisis (MA) es desarrollar y
mantener la capacidad de medición utilizada para dar soporte a
las necesidades de información de la gerencia.
El área de proceso Medición y Análisis implica las siguientes
actividades:
 Especificar los objetivos de medición y análisis para alinearlos
con las necesidades de información y con los objetivos del
proyecto, de la organización o del negocio.
 Especificar las medidas, las técnicas de análisis y los
mecanismos, para la recogida de datos, almacenamiento de
datos, difusión y realimentación.
 Implementar las técnicas de análisis y los mecanismos para
la recogida de datos, difusión de datos y realimentación.
 Proporcionar resultados objetivos que puedan utilizarse en la
toma de decisiones informadas y en la toma de acciones
correctivas apropiadas.
La integración de las actividades de medición y análisis en los

procesos del proyecto da soporte para:
 Planificar y estimar objetivamente.
 Seguir el progreso y el rendimiento reales frente a los planes
y objetivos establecidos.
 Identificar y resolver las cuestiones relativas al proceso.
 Proporcionar una base para incorporar la medición en
procesos adicionales en el futuro. Ma
287
El personal requerido para implementar una capacidad de
medición puede o no estar vinculado a un programa separado de la
organización. La capacidad de medición puede integrarse en
proyectos individuales o en otras funciones de la organización (p. ej.,
aseguramiento de la calidad). El enfoque inicial de las actividades
de medición es a nivel de proyecto. Sin embargo, una capacidad
de medición puede ser útil para tratar las necesidades de
información de la organización y de toda la empresa. Para dar
soporte a esta capacidad, las actividades de medi- ción deberían
dar soporte a las necesidades de información a varios niveles,
incluyendo el negocio, la unidad organizativa y el proyecto, con el
fin de minimizar el re-trabajo a medida que madura la
organización. Los proyectos pueden almacenar datos y resultados
específicos del proyecto, en un repositorio específico del
proyecto, pero cuando los datos se van a utilizar ampliamente o
se van a analizar como base para la determinación de tendencias o
para comparativas, los datos pueden
residir en el repositorio de mediciones de la organización.
La medición y el análisis de componentes del producto
proporcionados por los proveedores son fundamentales para la
gestión eficaz de la calidad y de los costes del proyecto. Con una
gestión cuidadosa de los acuerdos con el proveedor, es posible
proporcionar la visión de los datos que dan soporte al análisis del
rendimiento del proveedor.
Los objetivos de medición se derivan de las necesidades de
infor- mación que provienen de los objetivos del proyecto, de la
organización o del negocio. En éste área de proceso, cuando se
utiliza el término “objetivos” sin el calificador de “medición”, indica
objetivos del proyecto, de la organización o del negocio.

PARA más INFORMACIÓN sobre cómo educir, ANALIZAR y ESTABLECER los requisitos del
cliente, del producto y del componente del producto, consúltese el árEA de proceso
DESARrollo de Requisitos.
PARA más INFORMACIÓN sobre cómo ESTABLECER y MANTENER LA INTEGRIDAD de los
productos de TRABAJO UTILIZANDO LA IDENTIFICACIÓN de CONFIGURACIÓN, el control de
CONFIGURACIÓN, el informe del ESTADO de CONFIGURACIÓN y LAS AUDITORÍAS de configu-
RACIÓN, consúltese el árEA de proceso Gestión de CONFIGURACIÓN.
PARA más INFORMACIÓN sobre cómo ESTABLECER el repositorio de medición de LA ORGA-

NIZACIÓN, consúltese el árEA de proceso Definición de Procesos de LA OrGANIZACIÓN.
PARA más INFORMACIÓN sobre cómo MONITORIZAR los PARÁMETRos de PLANIFICACIÓN

del proyecto, consúltese el árEA de proceso MONITORIZACIÓN y Control del Proyecto.
PARA más INFORMACIÓN sobre cómo ESTABLECER ESTIMACIONES, consúltese el árEA de
proceso PLANIFICACIÓN del Proyecto.
PARA más INFORMACIÓN sobre cómo GESTIONAR CUANTITATIVAMENTE el proyecto, con-
súltese el árEA de proceso Gestión CUANTITATIVA del Proyecto.
Medición y análisis 289
PARA más INFORMACIÓN sobre cómo MANTENER LA TRAZABILIDAD bidirECCIONAL de los
requisitos, consúltese el árEA de proceso Gestión de Requisitos.

SG 1 Alinear las actividades de medición y análisis.
SP 1.1 Establecer los objetivos de medición.
SP 1.2 Especificar las medidas.
SP 1.3 Especificar los procedimientos de recogida y de almacenamiento de datos.
SP 1.4 Especificar los procedimientos de análisis.
SG 2 Proporcionar los resultados de la medición.
SP 2.1 Obtener los datos de la medición.
SP 2.2 Analizar los datos de la medición.
SP 2.3 Almacenar los datos y los resultados.
SP 2.4 Comunicar los resultados.
sG 1 a Linear Las actividades de medición y anáLisis

Los objetivos y las actividades de medición están alineados con las necesida-
des de información y los objetivos identificados.
Las prácticas específicas bajo esta meta específica pueden

tratarse si- multáneamente o en cualquier orden.
 Cuando se establecen los objetivos de medición, a menudo
los expertos prevén los criterios necesarios para especificar
las medidas y los procedimientos de análisis. También
consideran simul- táneamente las restricciones impuestas por
los procedimientos de recogida y de almacenamiento de
datos.
 Con frecuencia es importante especificar los análisis esen-
ciales a llevar a cabo antes de ocuparse de los detalles de la
especificación de la medición, de la recogida de datos o del
almacenamiento.
sp 1.1 estableceR los objetivos de medición

Establecer y mantener los objetivos de medición derivados de las necesidades
de información y de los objetivos identificados.
Los objetivos de medición documentan los fines para los que se

hace la medición y el análisis, y especifican los tipos de acciones
que se pueden tomar basándose en los resultados del análisis de
datos. Los objetivos de medición también pueden identificar el
Ma
cambio en el comportamiento deseado, como resultado de la

implementación de una actividad de medición y análisis.
Los objetivos de medición pueden estar limitados por los
procesos existentes, los recursos disponibles u otras
consideraciones de medi- ción. Se puede necesitar hacer juicios
sobre si el valor del resultado es proporcional a los recursos
dedicados para hacer el trabajo.
Las modificaciones a las necesidades de información y a los
objetivos identificados pueden, a su vez, estar indicadas como
una consecuencia del proceso y de los resultados de la medición
y el análisis.
Algunas fuentes de las necesidades de información y de los objetivos son:

• Planes de proyecto.
• Monitorización del rendimiento del proyecto.
• Entrevistas con gestores y otros que tengan necesidades de
información.
• Objetivos de gestión establecidos.
• Planes estratégicos.
• Planes de negocio.
• Requisitos formales u obligaciones contractuales.
• Problemas recurrentes o de gestión o técnicos.
• Experiencias de otros proyectos o entidades de la organización.
• Comparativas con empresas del sector.
• Planes de mejora de procesos.
Algunos ejemplos de objetivos de medición son:

• Proporcionar una visión de las fluctuaciones del calendario y del
progreso.
• Proporcionar una visión del tamaño real comparado con el planificado.
• Identificar incrementos no planificados.
• Evaluar la eficacia de la detección de defectos durante el ciclo de vida
de desarrollo del producto.
• Determinar el coste de la corrección de defectos.
• Proporcionar una visión de los costes reales comparados con los
planificados.
• Evaluar el progreso del proveedor frente al plan.
• Evaluar la eficacia de mitigar las vulnerabilidades del sistema de
información.
cliente, del producto, y de los componentes de producto, consúltese el árEA de pro-
ceso DESARrollo de Requisitos.
PARA más INFORMACIÓN sobre cómo MONITORIZAR los PARÁMETRos de PLANIFICACIÓN
del proyecto, consúltese el árEA de proceso MONITORIZACIÓN y Control del Proyecto.
PARA más INFORMACIÓN sobre cómo ESTABLECER ESTIMACIONES, consúltese el árEA de
proceso PLANIFICACIÓN del Proyecto.
1. Objetivos de medición.
SUBPRÁCTICAS
1. Documentar las necesidades de información y los objetivos.
2. Priorizar las necesidades de información y los objetivos.
Puede que no sea ni posible ni deseable someter todas las
necesidades de información identificadas inicialmente a la
medición y el análisis. También puede ser necesario que se
establezcan prioridades teniendo en cuenta la limitación de
recursos disponibles.
3. Documentar, revisar y actualizar los objetivos de medición.
Considere cuidadosamente los propósitos y usos previstos de la
me- dición y el análisis.
Los objetivos de medición se documentan, se revisan por la
gerencia y por otras partes interesadas relevantes, y se
actualizan según sea necesario. Todo esto, permite la trazabilidad
a las actividades de medición y análisis subsiguientes, y ayuda a
asegurar que los análisis abordarán adecuadamente las
necesidades de información y los objetivos identificados.
Es importante que los usuarios de los resultados de la medición y el
análi- sis estén involucrados en el establecimiento de los objetivos de la
medición y en la decisión sobre los planes de acción. También puede
ser apropiado involucrar a aquellos que proporcionan los datos de la
medición.
4. Proporcionar realimentación para refinar y clarificar las
necesidades de información y los objetivos cuando sea
necesario.
Las necesidades de información y los objetivos identificados
pueden refinarse y clarificarse como resultado de establecer
objetivos de me- dición. Las descripciones iniciales de
necesidades de información pueden ser ambiguas. Pueden surgir
conflictos entre las necesidades y los objetivos existentes. Los
objetivos precisos sobre una medida ya existente pueden no ser
realistas.
5. Mantener la trazabilidad de los objetivos de medición con las
necesidades de información y los objetivos identificados.
Siempre debería haber una buena contestación a la pregunta,
“¿por qué estamos midiendo esto?”
Evidentemente, los objetivos de medición pueden también cambiar
para reflejar la evolución de las necesidades de información y de los
objetivos.
sp 1.2 e specificaR las medidas

Especificar las medidas para tratar los objetivos de medición.
Ma
Los objetivos de medición se refinan en medidas precisas y

cuantificables. La medición del trabajo del proyecto y de la
organización normalmente se puede asignar a una o más
categorías de medición. Estas
categorías son: calendario y progreso, esfuerzo y coste, tamaño y
estabilidad, y calidad.
Las medidas pueden ser base o derivadas. Los datos para las
medidas base se obtienen por medición directa. Los datos para
las medidas derivadas provienen de otros datos, normalmente por
combinación de dos o más medidas base.
Algunos ejemplos de medidas base de uso común son:

• Medidas estimadas y reales del tamaño del producto de trabajo (p. ej.,
número de páginas).
• Medidas estimadas y reales de esfuerzo y de coste (p. ej., número de
horas persona).
• Medidas de calidad (p.ej., número de defectos por grado de severidad).
• Medidas de seguridad de la información (p. ej., número de
vulnerabilidades identificadas en el sistema).
• Calificaciones de las encuestas de satisfacción del cliente.
Algunos ejemplos de medidas derivadas de uso común son:

• Valor ganado.
• Índice de rendimiento de plazos.
• Densidad de defectos.
• Cobertura de revisiones entre pares.
• Cobertura de pruebas o de verificación.
• Medidas de fiabilidad (p. ej., tiempo medio entre fallos).
• Medidas de calidad (p. ej., número de defectos por grado de severidad/
número total de defectos).
• Medidas de seguridad de la información (p. ej., porcentaje de las
vulnerabilidades del sistema mitigadas).
• Tendencias en la satisfacción del cliente.
Las medidas derivadas se expresan normalmente como ratios,

ín- dices compuestos u otras medidas resumen agregadas. A
menudo, son cuantitativamente más fiables y se interpretan de
modo más significativo que las medidas base utilizadas para
generarlas.
Hay relaciones directas entre las necesidades de información,
los objetivos de medición, las categorías de medición, las medidas
base y las medidas derivadas. Esta relación directa se representa
en la Tabla MA. 1 usando algunos ejemplos de uso común.

1. Especificaciones de medidas base y derivadas.
SUBPRÁCTICAS
1. Identificar las medidas candidatas en base a los objetivos de
medición documentados.
Tabla MA.1: Ejemplo de las relaciones de medición
Ejemplo de
Objetivos del
Proyecto, de la
Organización o del Necesidad de Objetivo de Categorías de Ejemplo de Medidas Ejemplo de Medidas
Negocio Información Medición Medición Base Derivadas
Reducir el tiempo ¿Cuál es el tiempo Proporcionar visión Calendario y Fechas estimadas y reales Grado de consecución
para la entrega de entrega de las fluctuaciones progreso de inicio y fin por tarea de hitos
Ser el primero en estimado? del calendario y del Porcentaje de proyecto
comercializar el progreso realizado en tiempo
producto Precisión en la
estimación del
calendario
Aumentar la ¿Cómo de exactos Proporcionar una Tamaño y Esfuerzo y tamaño Productividad

cuota de mercado son el tamaño y el visión del tamaño esfuerzo estimado y real
reduciendo los coste estimados? y costes reales
costes de productos comparados con el
y servicios plan Esfuerzo y Coste estimado y real Rendimiento de coste
coste Variación de coste
Entregar la ¿Se ha ampliado Proporcionar una Tamaño y Número de requisitos Volatilidad de los
funcionalidad el alcance o visión del tamaño estabilidad requisitos
especificada el tamaño del real comparado Precisión en la
proyecto? con el plan, estimación del tamaño
para identificar
incrementos no Número de puntos de Puntos función
planificados función estimados vs. reales
Número de líneas de Cantidad de código

código nuevo, modificado y
reutilizado
Reducir los defectos
en los productos ¿Dónde se Evaluar la eficacia Calidad Número de defectos Defectos no detectados
entregados al cliente inyectan y se de la detección de inyectados y detectados por cada fase del ciclo
en un 10% sin afectar detectan los defectos en todo por cada fase del ciclo de de vida
a los costes defectos antes de el ciclo de vida del vida Densidad de defectos
la entrega? producto Tamaño del producto
¿Cuál es el coste Determinar el coste Coste Número de defectos Costes de retrabajo

del retrabajo? de corrección de inyectados y detectados
defectos por cada fase del ciclo de
vida
Horas de esfuerzo para
corregir defectos
Costes por hora
Reducir las ¿Cuál es la Evaluar la eficacia de Aseguramiento Número de Porcentaje de

vulnerabilidades magnitud de las la mitigación de las de la vulnerabilidades del vulnerabilidades del
del sistema de vulnerabilidades vulnerabilidades del Información sistema identificadas sistema mitigadas
Ma
información del sistema sistema y número de

abiertas? vulnerabilidades del
sistema mitigadas
Los objetivos de medición se refinan en medidas. Las medidas
candidatas identificadas se clasifican y se especifican por nombre y
unidad de medida.
2. Mantener la trazabilidad de las medidas con los objetivos de
medición. Las interdependencias entre las medidas candidatas
se identifican para permitir la validación posterior de los datos y
los análisis candi-
datos, en apoyo de los objetivos de medición.
3. Identificar las medidas existentes que ya tratan los objetivos de
medición. Las especificaciones para las medidas pueden ya
existir, quizás establecidas para otros propósitos anteriores o en
cualquier otra parte de
la organización.
4. Especificar las definiciones operativas para las medidas.
Las definiciones operativas se establecen en términos precisos y
no ambiguos. Tratan dos criterios importantes:
Comunicación: ¿qué ha sido medido?, ¿cómo fue medido?,
¿cuáles son las unidades de medida? y ¿qué ha sido incluido o
excluido?
Repetición: ¿se puede obtener el mismo resultado repitiendo la
me- dición a partir de la misma definición?
5. Priorizar, revisar y actualizar las medidas.
Las especificaciones propuestas de las medidas se revisan con
usuarios finales potenciales y con otras partes interesadas
relevantes para determinar si son adecuadas. Las prioridades se
establecen o se cambian, y las especificaciones de las medidas se
actualizan según sea necesario.
sp 1.3 especificaR los pRocedimientos de Recogida y de almacenamiento de datos

Especificar cómo se obtienen y almacenan los datos de la medición.
La especificación explícita de los métodos de recogida ayuda a
asegurar que los datos correctos se recogen apropiadamente. Esta
especifica- ción puede también ayudar posteriormente a clarificar
las necesidades de información y los objetivos de la medición.
Una adecuada atención a los procedimientos de
almacenamiento y de recuperación ayuda a asegurar que los
datos están disponibles y accesibles para uso futuro.
1. Procedimientos de recogida y de almacenamiento de datos.
2. Herramientas de recogida de datos.
SUBPRÁCTICAS
1. Identificar las fuentes de datos existentes que se generan a partir
de los productos de trabajo, los procesos o las transacciones
actuales.
Las fuentes de datos existentes pueden identificarse cuando se
especifican las medidas. Pueden existir mecanismos de recogida
apropiados con independencia de que se hayan recogido o no los
datos pertinentes.
2. Identificar las medidas para las que se necesitan datos que no se
encuentren disponibles en la actualidad.
3. Especificar cómo recoger y almacenar los datos para cada
medida requerida.
Se hacen especificaciones explícitas de qué, cómo, dónde y
cuándo serán recogidos y almacenados los datos, para asegurar
su validez y para dar soporte a su uso posterior para propósitos
de análisis y de documentación.
Algunas preguntas a considerar normalmente son:

• ¿Se ha determinado la frecuencia de recogida y los puntos en el
proceso en los que se harán las mediciones?
• ¿Se ha establecido el cronograma que se requiere para trasladar los
resultados de la medición desde los puntos de recogida hasta los
repositorios, otras bases de datos o usuarios finales?
• ¿Quién es el responsable de obtener los datos?
• ¿Quién es el responsable del almacenamiento, recuperación y
seguridad de los datos?
• ¿Se han desarrollado o adquirido las herramientas de soporte
necesarias?
4. Crear mecanismos de recogida de datos y orientaciones del

proceso. Los mecanismos de recogida y de almacenamiento de
datos están bien integrados con otros procesos de trabajo normales.
Los mecanismos de
recogida de datos pueden incluir formularios y plantillas
manuales o automatizadas. Aquellos responsables de realizar el
trabajo, disponen de una orientación clara y concisa sobre los
procedimientos correctos. Se proporciona formación, según sea
necesario, para clarificar los procesos requeridos para la recogida
completa y precisa de datos, y para minimizar la carga de aquellos
que proporcionan y registran los datos.
5. Dar soporte a la recogida automática de los datos según proceda y
sea factible.
Algunos ejemplos de dichos soportes automatizados son:

• Registros de actividad con indicación de fecha y hora.
• Análisis estático y dinámico de artefactos.
6. Priorizar, revisar y actualizar los procedimientos de recogida y

de almacenamiento de datos.
Se revisan los procedimientos propuestos para ver si son
apropiados y factibles, con aquellas personas responsables de
proporcionar, recoger y almacenar los datos. Estas personas
también pueden tener perspectivas útiles sobre cómo mejorar
Ma
los procesos existentes o pueden ser capaces de sugerir otras

medidas o análisis útiles.
7. Actualizar las medidas y los objetivos de medición según sea necesario.
sp 1.4 especificaR los pRocedimientos de análisis
Especificar cómo se analizan y comunican los datos de medición.
Especificando previamente los procedimientos de análisis se

asegura que los análisis apropiados se llevarán a cabo y se
difundirán para tratar los objetivos de medición documentados (y
por tanto, las necesidades de información y los objetivos sobre los
cuales se basan). Esta aproxi- mación también proporciona una
verificación de que, efectivamente, los datos necesarios pueden ser
recogidos. Los procedimientos de análisis deberían tener en cuenta
la calidad (p. ej., vigencia, fiabilidad) de todos los datos que entran
en un análisis (ya sea desde el proyecto, el repositorio de
mediciones de la organización u otra fuente). La calidad de los
datos se debería tener en cuenta para ayudar a seleccionar el
procedimiento de análisis apropiado y evaluar los resultados del
análisis.
1. Especificaciones y procedimientos de análisis.
2. Herramientas de análisis de datos.
SUBPRÁCTICAS
1. Especificar y priorizar los análisis a realizar y los informes a
preparar. Preste atención desde el principio a los análisis a
realizar y a la manera en que se informará de los resultados. Estos
análisis e informes debe-
rían cumplir los siguientes criterios:
Los análisis tratan de manera explícita los objetivos de
medi- ción documentados.
La presentación de los resultados es claramente
entendible por las audiencias a las que se dirigen los
resultados.
Pueden tener que establecerse prioridades en base a los recursos
disponibles.
2. Seleccionar los métodos y las herramientas apropiados de
análisis de datos.
Algunas cuestiones a considerar normalmente son:

• Elección de técnicas de presentación visual y otras técnicas de
presentación (p. ej., diagramas de tarta, de barras, histogramas,
diagramas de radar, gráficos de líneas, diagramas de dispersión, tablas).
• Elección de estadísticos descriptivos apropiados (p. ej., media
aritmética, mediana, moda).
• Decisiones sobre los criterios de muestreo estadístico cuando es
imposible o innecesario examinar cada elemento de datos.
• Decisiones sobre cómo manejar el análisis en caso de ausencia de
elementos de datos.
• Selección de herramientas de análisis adecuadas.
Los estadísticos descriptivos normalmente se usan en el análisis de datos

para hacer lo siguiente:
• Examinar las distribuciones de las medidas especificadas (p. ej.,
tendencia central, cuantía de la variación, puntos de datos que
muestran una variación inusual).
• Examinar las interrelaciones entre las medidas especificadas (p. ej.,
comparaciones de defectos por fase del ciclo de vida del producto,
comparaciones de defectos por componente de producto).
• Mostrar los cambios a lo largo del tiempo.
PARA más INFORMACIÓN sobre el uso ADECUADO de TÉCNICAS ESTADÍSTICAS y LA

comprensión de LA VARIACIÓN, consúltese LA PRÁCTICA ESPECÍFICA SELECCIONAR
LAS MEDIDAS y LAS TÉCNICAS ANALÍTICAS en el árEA de proceso Gestión CUAN-
TITATIVA del Proyecto.
3. Especificar los procedimientos administrativos para el análisis
de los datos y comunicar los resultados.
Normalmente, las cuestiones que hay que tener en cuenta son:

• Identificación de las personas y de los grupos responsables de analizar
los datos y de presentar los resultados.
• Determinación del plazo de tiempo para analizar los datos y presentar
los resultados.
• Determinación de las formas de comunicación de los resultados (p. ej.,
informes de progreso, notas emitidas, informes escritos, reuniones con
el personal).
4. Revisar y actualizar el contenido y el formato propuesto de los
análi- sis e informes especificados.
Todo el contenido y el formato propuestos están sujetos a
revisión y corrección, incluyendo métodos y herramientas
analíticas, procedimientos administrativos y prioridades. Las
partes interesadas relevantes consultadas deberían incluir a
usuarios finales, patrocinadores, analistas de datos y
suministradores de datos.
5. Actualizar las medidas y los objetivos de medición según sea
necesario. Al igual que las necesidades de medición guían el
análisis de los datos, la clarificación de los criterios de análisis
puede afectar a la medición.
Las especificaciones para algunas medidas pueden refinarse a
poste- riori, en base a las especificaciones establecidas para los
procedimientos de análisis de datos. Puede que otras medidas
sean innecesarias o que se necesiten medidas adicionales.
Especificar cómo serán analizadas e informadas las medidas puede
también sugerir la necesidad de refinar los objetivos de la medición en
sí mismos.
Ma
6. Especificar los criterios para evaluar la utilidad de los resultados

de análisis y para evaluar el comportamiento de las actividades
de medi- ción y análisis.
Los criterios para evaluar la utilidad del análisis podrían tratar el grado de
aplicación de:
• Los resultados son proporcionados a tiempo, son comprensibles, y son
utilizados para la toma de decisiones.
• El coste del trabajo a realizar está justificado por los beneficios que
produce.
Los criterios para evaluar el comportamiento de la medición y del análisis

podrían tratar el grado de aplicación de:
• La cantidad de datos desaparecidos o el número de inconsistencias
marcadas está por encima de los umbrales especificados.
• Hay predisposición en la selección de la muestra (p. ej., sólo se encuesta
a usuarios finales satisfechos para evaluar la satisfacción del usuario
final, sólo se evalúan los proyectos sin éxito para determinar la
productividad global).
• Los datos de medición son repetibles (p. ej., estadísticamente fiables).
• Los supuestos estadísticos se han satisfecho (p. ej., sobre la distribución
de los datos, sobre las escalas de medición apropiadas).
sG 2 p roporcionar Los resuLtados de La medición

Se proporcionan los resultados de la medición que tratan las necesidades de
información y los objetivos identificados.
La razón principal para llevar a cabo la medición y análisis es tratar

las necesidades de información identificadas, derivadas de los
objetivos del proyecto, de la organización y del negocio. Los
resultados de la me- dición basados en la evidencia objetiva
pueden ayudar a monitorizar el progreso y el rendimiento,
satisfacer las obligaciones documentadas en el acuerdo con el
proveedor, tomar decisiones informadas técnicas y de gestión, y
permitir la toma de acciones correctivas.
sp 2.1 obteneR los datos de la medición
Obtener los datos de la medición especificados.
Se obtienen los datos necesarios para el análisis y se comprueba

su completitud e integridad.

1. Conjuntos de datos de medición base y derivados.
2. Resultados de las pruebas de integridad de datos.
SUBPRÁCTICAS
1. Obtener los datos para las medidas base.
Los datos se recogen, según sea necesario, para las medidas base
utilizadas previamente y las especificadas nuevamente. Los datos
existentes se recogen de los registros del proyecto o de cualquier
parte de la organización.
2. Generar los datos para las medidas derivadas.
Los valores se calculan de nuevo para todas las medidas derivadas.
3. Realizar las comprobaciones de integridad de datos lo más cerca
posible a la fuente de los mismos.
Todas las mediciones están sujetas a error en la especificación o
en el registro de datos. Siempre es mejor identificar esos errores y
las fuentes de los datos desaparecidos lo antes posible en el ciclo
de medición y análisis.
Las comprobaciones pueden incluir exploraciones de datos
desaparecidos, valores de datos fuera de límites, y patrones y
correlaciones inusuales en todas las medidas. Es particularmente
importante hacer lo siguiente:
Probar y corregir inconsistencias de clasificaciones hechas por el
juicio humano (es decir, determinar con qué frecuencia la gente
toma decisiones de clasificación distintas en base a la misma
infor- mación, (también conocida como “fiabilidad entre-
codificadores”).
Examinar empíricamente las relaciones entre las medidas que
se utilizan para calcular medidas derivadas adicionales.
Haciéndolo así, se puede asegurar que no se pasan por alto
distinciones importantes y que las medidas derivadas
transmiten sus significados deseados (también conocido como
“validez de criterio”).
sp 2.2 analizaR los datos de la medición

Analizar e interpretar los datos de la medición.
Los datos de la medición se analizan conforme a la planificación,

se realizan análisis adicionales según sea necesario, se revisan los
resultados con las partes interesadas relevantes y se anotan las
revisiones necesarias para análisis futuros.
1. Resultados del análisis e informes preliminares.
SUBPRÁCTICAS
1. Llevar a cabo los análisis iniciales, interpretar los resultados y
perfilar las conclusiones preliminares.
Los resultados de los análisis de datos rara vez son evidentes. Se
Ma
debe- rían establecer explícitamente los criterios para interpretar

los resultados y perfilar las conclusiones.
2. Llevar a cabo mediciones y análisis adicionales según sea
necesario y preparar los resultados para su presentación.
Los resultados de los análisis planificados pueden sugerir (o
requerir) análisis adicionales imprevistos. Además, estos análisis
pueden identificar necesidades para refinar las medidas
existentes, para calcular las medidas derivadas adicionales o
incluso para recoger datos para medidas base adicionales que
completen apropiadamente el análisis planificado.
Análogamente, la preparación de los resultados iniciales para su
presentación puede identificar la necesidad de análisis adicio-
nales no previstos.
3. Revisar los resultados iniciales con las partes interesadas
relevantes. Puede ser apropiado revisar las interpretaciones
iniciales de los resultados y la forma en la que estos resultados
son presentados antes de
diseminarlos y comunicarlos ampliamente.
La revisión de los resultados iniciales antes de su publicación,
puede prevenir malas interpretaciones innecesarias y llevar a
mejoras en el análisis y presentación de los datos.
Las partes interesadas relevantes con quienes se puede llevar a
cabo la revisión, incluyen los usuarios finales previstos, los
patrocinadores, los analistas de datos y los suministradores de
datos.
4. Refinar los criterios para análisis futuros.
Las lecciones que pueden mejorar los esfuerzos futuros se
aprenden frecuentemente realizando análisis de datos y
preparando resultados. Análogamente, la manera de mejorar las
especificaciones de medición y los procedimientos de recogida de
datos pueden llegar a ser evidentes, como lo pueden ser ideas
para refinar las necesidades de informa- ción y los objetivos
identificados.
sp 2.3 a lmacenaR los datos y los Resultados

Gestionar y almacenar los datos de la medición, las especificaciones de la me-
dición y los resultados del análisis.
Almacenar la información relacionada con la medición permite un

uso eficaz en tiempo y coste de los datos y resultados históricos.
También es necesaria la información para proporcionar un
contexto adecuado para la interpretación de los datos, criterios de
medición y resultados del análisis.
La información almacenada normalmente es:

• Planes de medición.
• Especificaciones de medidas.
• Conjuntos de datos recogidos.
• Informes de análisis y presentaciones.
• Periodo de conservación para los datos almacenados.
La información almacenada contiene o hace referencia a otra
in- formación necesaria para comprender e interpretar las
medidas y evaluarlas en cuanto a que sean razonables y
aplicables (p. ej., especificaciones de medición utilizadas en
diferentes proyectos, cuando se compara entre proyectos).
Normalmente, los conjuntos de datos para medidas derivadas
pueden ser recalculados y no necesitan almacenarse. Sin
embargo, puede ser apropiado almacenar resúmenes basados en
medidas derivadas (p. ej., diagramas, tablas de resultado,
informes escritos).
Los resultados de análisis intermedios no necesitan ser
almacenados por separado si se pueden reconstruir
eficientemente.
Los proyectos pueden elegir almacenar datos y resultados
especí- ficos del proyecto en un repositorio específico del
proyecto. Cuando los datos se comparten entre proyectos, los
datos pueden residir en el repositorio de mediciones de la
organización.
PARA más INFORMACIÓN sobre cómo ESTABLECER un SISTEMA de gestión de LA configu-
RACIÓN, consúltese el árEA de proceso Gestión de CONFIGURACIÓN.
PARA más INFORMACIÓN sobre cómo ESTABLECER el repositorio de medición de LA

orGANIZACIÓN, consúltese LA PRÁCTICA ESPECÍFICA ·ESTABLECER el repositorio de me-
diciones de LA ORGANIZACIÓN en el árEA de proceso Definición de Procesos de LA
OrGANIZACIÓN.
Ejemplo de Productos de TRABAJO

1. Inventario de datos almacenados.
SUBPRÁCTICAS
1. Revisar los datos para asegurar que sean completos, íntegros,
precisos y actuales.
2. Almacenar los datos conforme a los procedimientos de
almacenamiento de datos.
3. Dejar disponibles los contenidos almacenados para uso
exclusivo de grupos y miembros del personal apropiados.
4. Prevenirquelainformaciónalmacenadaseautilizadainapropiadamente.
Algunos ejemplos de formas para prevenir la utilización inapropiada de los

datos y de la información relacionada son: controlar el acceso a los datos y
educar a las personas en la utilización apropiada de los datos.
Algunos ejemplos de uso inapropiado de los datos son:

• Revelar información proporcionada de manera confidencial.
• Malinterpretar en base a información incompleta, fuera de contexto o
engañosa.
• Utilizar medidas para evaluar indebidamente el rendimiento de las
personas o para clasificar los proyectos.
Ma
• Cuestionar la integridad de las personas.

sp 2.4 comunicaR los Resultados
Comunicar los resultados de las actividades de medición y análisis a todas las
partes interesadas relevantes.
Los resultados del proceso de medición y análisis se comunican a las
partes interesadas relevantes a tiempo y de forma utilizable para dar
soporte a la toma de decisiones y para ayudar en la toma de acciones
correctivas. Las partes interesadas relevantes previstas incluyen a
los usuarios finales, a los patrocinadores, a los analistas de datos y
a los proveedo-
res de datos.
1. Informes entregados y resultados de los análisis relacionados.
2. Información contextual u orientación para ayudar a interpretar
los resultados del análisis.
SUBPRÁCTICAS
1. Mantener informadas oportunamente a las partes interesadas
relevantes de los resultados de la medición.
En la medida de lo posible y como parte de la forma en que ellos
llevan a cabo su negocio, los usuarios de los resultados de la
medición se mantienen personalmente involucrados en el
establecimiento de los objetivos y en la decisión de los planes de
acción para la medición y el análisis. Los usuarios se mantienen
informados regularmente del progreso y de los resultados
intermedios.
PARA más INFORMACIÓN sobre cómo LLEVAR A CABO revisiones de progreso,
2. Ayudar a las partes interesadas relevantes a entender los
resultados. Los resultados se comunican de forma clara y
concisa, adecuada a las partes interesadas relevantes. Los
resultados son comprensibles,
fácilmente interpretables y claramente ligados a las necesidades
de información y objetivos identificados.
Con frecuencia, los datos analizados no son evidentes para los
profesionales que no son expertos en medición. La
comunicación de los resultados debería ser clara en:
Cómo y por qué fueron especificadas las medidas base y
derivadas. Cómo fueron obtenidos los datos.
Cómo interpretar los resultados en base a los métodos de
análisis de datos utilizados.
Cómo los resultados cubren las necesidades de información.
Algunos ejemplos de acciones para ayudar en la comprensión de los resul-
tados son:
• Examinar los resultados con las partes interesadas relevantes.
• Proporcionar antecedentes y explicaciones en un documento.
• Informar a los usuarios sobre los resultados.
• Proporcionar formación sobre el uso apropiado y la comprensión de los
resultados de la medición.
OPD
DEFINICIÓN DE PROCESOS DE LA ORGANIZACIÓN
Un área de proceso de Gestión de Procesos en el nivel de madurez 3
Propósito
El propósito de la Definición de Procesos de la Organización
(OPD) es establecer y mantener un conjunto utilizable de activos
de proceso de la organización, estándares del entorno de trabajo,
y reglas y guías para los equipos.
Notas Introductorias
Los activos de proceso de la organización permiten una ejecución
consistente de los procesos en toda la organización y
proporcionan una base para obtener beneficios acumulados a
largo plazo para la organi- zación (véase la definición de “activos
de proceso de la organización” en el glosario).
La biblioteca de activos de proceso de la organización da
soporte al aprendizaje y a la mejora de procesos, al permitir
compartir las buenas prácticas y las lecciones aprendidas en toda
la organización (véase la definición de “activos de proceso de la
organización” en el glosario).
El conjunto de procesos estándar de la organización también
describe las interacciones estándar con los proveedores. Las
interacciones del proveedor se caracterizan por los siguientes
elementos típicos: entregables esperados de los proveedores,
criterios de aceptación aplicables a estos entregables, estándares
(p. ej., estándares de arquitectura y de tecnología), e hitos estándar
y revisiones de progreso.
El “conjunto de procesos estándar” de la organización se
adapta por los proyectos para crear sus procesos definidos. Se
utilizan otros activos de proceso de la organización para dar
soporte a la adaptación y a la implementación de los procesos
definidos. Los estándares del entorno de trabajo se utilizan para
guiar la creación de los entornos de trabajo del proyecto. Las
reglas y guías para los equipos se utilizan para ayudar a su
estructuración, formación y operación.
Un “proceso estándar” se compone de otros procesos (es
decir, subprocesos) o elementos de proceso. Un “elemento de
proceso” es la unidad fundamental (es decir, atómica) de la
definición del proceso que describe las actividades y las tareas
para realizar el trabajo de manera consistente. La arquitectura
del proceso proporciona reglas para
303
conectar los elementos de proceso de un proceso estándar. El
conjunto de procesos estándar de la organización puede incluir
múltiples arquitecturas de proceso.
(Véanse las definiciones de “proceso estándar”, “arquitectura de
proceso”, “subproceso” y “elemento del proceso” en el glosario).
Los activos de proceso de la organización pueden estar organizados de mu-

chas maneras, dependiendo de la implementación del área de proceso de
Definición de Procesos de la Organización. Algunos ejemplos son:
• Las descripciones de los modelos de ciclo de vida pueden ser parte
del conjunto de procesos estándar de la organización o pueden
documentarse por separado.
• El conjunto de procesos estándar de la organización puede estar
almacenado en la biblioteca de activos de proceso de la organización o
puede estar almacenado de manera separada.
• Un único repositorio puede contener tanto las mediciones como la
documentación relacionada con el proceso o pueden almacenarse por
separado.

PArA más informAción sobre cómo desplegAr los Activos de proceso de lA OrgAni-
zAción, consúltese el áre A de proceso Enfoque en Procesos de lA OrgAniz Ación.

SG 1 Establecer los activos de proceso de la organización.
SP 1.1 Establecer los procesos estándar.
SP 1.2 Establecer las descripciones de los modelos de ciclo de vida.
SP 1.3 Establecer los criterios y las guías de adaptación.
SP 1.4 Establecer el repositorio de mediciones de la organización.
SP 1.5 Establecer la biblioteca de activos de proceso de la organización.
SP 1.6 Establecer los estándares del entorno de trabajo.
SP 1.7 Establecer las reglas y guías para los equipos.
sG 1 e stabLecer Los activos de proceso de La orGanización

Se establece y mantiene un conjunto de activos de proceso de la organización.
sp 1.1 estableceR los pRocesos estándaR

Establecer y mantener el conjunto de procesos estándar de la organización.
Los procesos estándar se pueden definir en diferentes niveles

dentro de una empresa y se pueden relacionar de forma jerárquica.
Por ejemplo,
Definición de procesos de la organización 305
una empresa puede tener un conjunto de procesos estándar que
se adapta por organizaciones individuales de la empresa (p. ej.,
una divi- sión, una ubicación) para establecer su conjunto de
OPD
procesos estándar. El conjunto de procesos estándar puede
también estar adaptado para cada una de las áreas de negocio,
líneas de producto o servicios están- dar de la organización. De
esta manera, el conjunto de procesos ESTÁNDAR de LA ORGANIZACIÓN puede
referirse a los procesos estándar establecidos a nivel de la
organización y a los procesos estándar que pueden estar
establecidos en niveles inferiores, aunque algunas organizaciones
pueden tener solo un nivel de procesos estándar (véanse las
definiciones de “proceso estándar” y “conjunto de procesos estándar
de la organi- zación” en el glosario).
Se pueden necesitar múltiples procesos estándar para tratar las ne-
cesidades de los diferentes dominios de aplicación, modelos de
ciclo de vida, metodologías y herramientas. El conjunto de
procesos están- dar de la organización contiene elementos de
proceso (p. ej. un elemento de estimación de tamaño del
producto de trabajo) que pueden interconectarse de acuerdo a una
o más arquitecturas de proceso, que describen las relaciones entre
los elementos de proceso.
El conjunto de procesos estándar de la organización incluye,
normalmente, procesos técnicos, de gestión, administrativos, de
soporte y organizativos.
El conjunto de procesos estándar de la organización debería
cubrir, de forma conjunta, todos los procesos necesarios para la
organi- zación y para los proyectos, incluyendo aquellos procesos
tratados por las áreas de proceso en el nivel de madurez 2.
1. Conjunto de procesos estándar de la organización.
SUBPRÁCTICAS
1. Descomponer cada proceso estándar en los elementos de proceso
que lo constituyen hasta el detalle necesario para comprender y
describir el proceso.
Cada elemento de proceso cubre un conjunto de actividades
estrechamente relacionadas. Las descripciones de los elementos de
proceso pueden ser plantillas para cumplimentar, partes para
completar, abstracciones para refinar o descripciones completas para
que se puedan adaptar o para utilizar sin modificaciones. Estos
elementos se describen con tal detalle que, el proceso, cuando se
defina completamente, se pueda realizar, de forma consistente, por
personas con la formación y las habilidades apropiadas.
Algunos ejemplos de elementos de proceso son:

• Plantilla para generar estimaciones de tamaño del producto de trabajo.
• Descripción de la metodología de diseño del producto de trabajo.
Continúa
Continuación
• Metodología adaptable para la revisión entre pares.
• Plantilla para llevar a cabo revisiones de gestión.
• Plantillas o flujos de tareas embebidos en herramientas de flujos de
trabajo.
• Descripción de métodos para precalificar a proveedores como
preferentes.
2. Especificar los atributos críticos de cada elemento de proceso.
Algunos ejemplos de atributos críticos son:

• Roles del proceso.
• Estándares aplicables.
• Procedimientos, métodos, herramientas y recursos aplicables.
• Objetivos de rendimiento de proceso.
• Criterios de entrada.
• Entradas.
• Puntos de verificación (p. ej. revisión entre pares).
• Salidas.
• Interfaces.
• Criterios de Salida.
• Medidas del producto y del proceso.
3. Especificar las relaciones entre elementos de proceso.
Algunos ejemplos de relaciones son:

• Orden de los elementos de proceso.
• Interfaces entre elementos de proceso.
• Interfaces con procesos externos.
• Interdependencias entre elementos de proceso.
Las reglas que describen las relaciones entre elementos del

proceso se denominan “arquitectura de proceso”. La arquitectura
de proceso cubre los requisitos y las guías principales. Las
especificaciones detalladas de estas relaciones se contemplan
en las descripciones de los procesos definidos que se adaptan a
partir del conjunto de procesos estándar de la organización.
4. Asegurar que el conjunto de procesos estándar de la
organización se adhiere a las políticas, estándares y modelos
aplicables.
La adherencia a los estándares y modelos de proceso aplicables
se demuestra, normalmente, estableciendo la correspondencia
entre el conjunto de procesos estándar de la organización, y los
estándares y los modelos de proceso relevantes. Esta
correspondencia es una infor- mación útil para futuras
evaluaciones.
5. Asegurar que el conjunto de procesos estándar de la organización
satisface las necesidades del proceso y los objetivos de la
organización.
OPD
PARA más INFORMACIÓN sobre cómo ESTABLECER LAS NECESIDADES del proceso
de LA ORGANIZACIÓN, consúltese el árEA de proceso Enfoque en Procesos de
LA OrGANIZACIÓN.
6. Asegurar que existe una integración apropiada entre los procesos
que se incluyen en el conjunto de procesos estándar de la
organización.
7. Documentar el conjunto de procesos estándar de la organización.
8. Llevar a cabo revisiones entre pares sobre el conjunto de
PARA más INFORMACIÓN sobre cómo LLEVAR A CABO revisiones entre PARes,
consúltese el árEA de proceso VERIFICACIÓN.
9. Modificar el conjunto de procesos estándar de la organización
según sea necesario.
Algunos ejemplos sobre cuándo puede ser necesario modificar los proce-
sos estándar de la organización son:
• Cuando se identifican mejoras a los procesos.
• Cuando los datos del análisis causal y resolución indican que se
necesita un cambio en el proceso.
• Cuando se seleccionan propuestas de mejora de procesos para su
despliegue en la organización.
• Cuando se actualizan las necesidades de procesos y los objetivos de la
organización.
sp 1.2 estableceR las descRipciones de los modelos de ciclo de vida

Establecer y mantener las descripciones de los modelos de ciclo de vida apro-
bados para su uso en la organización.
Los modelos de ciclo de vida se pueden desarrollar para

diferentes clientes o diferentes situaciones, ya que un modelo de
ciclo de vida puede no ser adecuado para todas las situaciones.
Los modelos de ciclo de vida se utilizan frecuentemente para
definir las fases del proyec- to. La organización también puede
definir modelos de ciclo de vida diferentes para cada tipo de
producto y servicio que entrega.

1. Descripciones de los modelos de ciclo de vida.
SUBPRÁCTICAS
1. Seleccionar los modelos de ciclo de vida basándose en las
necesidades de los proyectos y de la organización.
Algunos ejemplos de modelos de ciclo de vida del proyecto son:

• Cascada o en serie.
• Espiral.
• Evolutivo.
• Incremental.
• Iterativo.
2. Documentar las descripciones de los modelos de ciclo de vida.
Los modelos de ciclo de vida pueden documentarse como parte
de las descripciones del proceso estándar de la organización o
pueden documentarse por separado.
3. Llevar a cabo revisiones entre pares de los modelos de ciclo de vida.
4. Modificar las descripciones de modelos de ciclo de vida según
sea necesario.
sp 1.3 estableceR los cRiteRios y las guías de adaptación

Establecer y mantener los criterios y las guías de adaptación para el conjunto de
Los criterios y las guías de adaptación describen:

 Cómo utilizar el conjunto de procesos estándar de la
organización y los activos de proceso para crear los procesos
definidos.
 Los requisitos que se deben satisfacer por los procesos
definidos (p. ej., el subconjunto de los activos de proceso de la
organización que son esenciales para cualquier proceso
definido).
 Las opciones que se pueden ejercer y los criterios para su selección.
 Los procedimientos que deben seguirse para realizar y
documentar la adaptación del proceso.
Algunos ejemplos de razones para realizar la adaptación son:

• Adaptar el proceso a una nueva línea de producto o entorno de trabajo.
• Elaborar la descripción del proceso de forma que pueda realizarse el
proceso definido resultante.
• Personalizar el proceso para una aplicación o para una clase de
aplicaciones similares.
La flexibilidad en la adaptación y en la definición de los
procesos se equilibra asegurando una consistencia apropiada de
los procesos en toda la organización. La flexibilidad se necesita
para tratar variables contextuales, tales como el dominio; la
naturaleza del cliente; el compromiso de coste, calendario y
calidad; la dificultad técnica del
trabajo; y la experiencia del personal que implementa el proceso.
La consistencia en toda la organización es necesaria para que los
estánda- res, los objetivos y las estrategias de la organización se
OPD
traten de forma apropiada, y se puedan compartir los datos del
proceso y las lecciones aprendidas.
La adaptación es una actividad crítica que permite cambios
controlados a los procesos debido a necesidades específicas de
un proyecto o de una parte de la organización. Los procesos y
elementos de proceso que están directamente relacionados con
los objetivos críticos del negocio se deberían definir
generalmente como obligatorios, pero los procesos y elementos
de proceso que son menos críticos o que sólo afectan
indirectamente a los objetivos del negocio pueden permitir una
mayor adaptación.
El grado de adaptación podría depender también del modelo
de ciclo de vida del proyecto, de la utilización de proveedores y
de otros factores.
Los criterios y guías de adaptación pueden permitir utilizar un
proceso estándar “como está”, sin ninguna adaptación.

1. Guías de adaptación para el conjunto de procesos estándar de
la organización.
SUBPRÁCTICAS
1. Especificar los criterios de selección y los procedimientos para
adaptar el conjunto de procesos estándar de la organización.
Algunos ejemplos de criterios y procedimientos son:

• Criterios para seleccionar los modelos de ciclo de vida entre los
aprobados por la organización.
• Criterios para seleccionar los elementos de proceso a partir del
• Procedimientos para adaptar los modelos de ciclo de vida y los
elementos de proceso seleccionados con objeto de adecuar las
características y necesidades del proceso.
• Procedimientos para adaptar las medidas comunes de la organización
para tratar las necesidades de información.
Algunos ejemplos de adaptación son:

• Modificar un modelo de ciclo de vida.
• Combinar elementos de modelos de ciclo de vida diferentes.
• Modificar elementos de proceso.
• Reemplazar elementos de proceso.
• Reordenar elementos de proceso.
2. Especificar los estándares utilizados para documentar los procesos definidos.
3. Especificar los procedimientos utilizados para proponer y
obtener la aprobación de exenciones a partir del conjunto de
4. Documentar las guías de adaptación para el conjunto de
5. Llevar a cabo revisiones entre pares sobre las guías de adaptación.
6. Modificar las guías de adaptación según sea necesario.
sp 1.4 estableceR el RepositoRio de mediciones de la oRganización

Establecer y mantener el repositorio de mediciones de la organización.
PARA más INFORMACIÓN sobre el uso del repositorio de mediciones de LA ORGANI-
ZACIÓN en LA PLANIFICACIÓN de LAS ACTIVIDADES del proyecto, consúltese LA PRÁCTICA
ESPECÍFICA UTILIZAR los ACTIVOS de proceso de LA ORGANIZACIÓN PARA PLANIFICAR LAS
ACTIVIDADES del proyecto, en el árEA de proceso Gestión INTEGRADA del Proyecto.
El repositorio contiene medidas tanto de producto como de proceso

que están relacionadas con el conjunto de procesos estándar de la
organi- zación. También contiene o se refiere a la información
necesaria para comprender e interpretar las medidas, y evaluarlas en
cuanto a que sean razonables y aplicables. Por ejemplo, se utilizan
las definiciones de las medidas para comparar medidas similares
de diferentes procesos.
1. La definición del conjunto común de medidas de producto y de
proceso para el conjunto de procesos estándar de la
organización.
2. El diseño del repositorio de mediciones de la organización.
3. El repositorio de mediciones de la organización (es decir, la
estructura del repositorio, el entorno de soporte).
4. Los datos de mediciones de la organización.
SUBPRÁCTICAS
1. Determinar las necesidades de la organización para almacenar,
recuperar y analizar las mediciones.
2. Definir un conjunto común de medidas de proceso y de
producto para el conjunto de procesos estándar de la
organización.
Las medidas en el conjunto común se seleccionan por su capacidad
para proporcionar visibilidad en los procesos críticos en cuanto a
la conse- cución de los objetivos de negocio y para enfocarse sobre
los elementos de proceso que impactan de forma significativa en
el coste, calendario y rendimiento dentro de un proyecto y en toda
la organización. El conjunto común de medidas puede variar para
diferentes procesos estándar.
Las medidas definidas incluyen aquellas relativas a la gestión de
acuerdos, algunas de las cuales podrían ser recogidas de los
proveedores.
Las definiciones operativas de las medidas especifican los
procedimientos para recoger los datos válidos y en qué punto
del proceso se recogerán los datos.
OPD
Algunos ejemplos de medidas utilizadas frecuentemente son:
• Estimaciones de tamaño del producto de trabajo (p. ej., páginas).
• Estimaciones de esfuerzo y coste (p. ej., horas/persona).
• Medidas reales de tamaño, esfuerzo y coste.
• Cobertura de las pruebas.
• Medidas de fiabilidad (p. ej., tiempo medio entre fallos).
• Medidas de calidad (p. ej., número de defectos encontrados, gravedad
de los defectos).
• Cobertura de las revisiones entre pares.
3. Diseñar e implementar el repositorio de mediciones.
Algunas funciones del repositorio de mediciones son:
Dar soporte para la comparación eficaz y para la
interpreta- ción de los datos de medición entre los
proyectos.
Proporcionar un entorno adecuado para permitir que un
nuevo proyecto identifique y acceda rápidamente a los
datos de proyectos similares en el repositorio.
Posibilitar que los proyectos mejoren la precisión de sus
estimaciones utilizando sus propios datos y datos
históricos de otros proyectos.
Ayudar en la comprensión del rendimiento de proceso.
Dar soporte a la gestión estadística de procesos o
subprocesos, según sea necesario.
4. Especificar los procedimientos para almacenar, actualizar y
recuperar las medidas.
PARA más INFORMACIÓN sobre cómo ESPECIFICAR LA rECOGIDA de DATOS y los
procedimientos de ALMACENAMIENTO, consúltese el árEA de proceso Medi-
ción y Análisis.
5. Llevar a cabo revisiones entre pares sobre las definiciones del
conjunto común de medidas y procedimientos para
almacenarlas, actua- lizarlas y recuperarlas.
6. Introducir las medidas especificadas en el repositorio.
PARA más INFORMACIÓN sobre cómo ESPECIFICAR MEDIDAS, consúltese el árEA
de proceso Medición y Análisis.
7. Poner los contenidos del repositorio de mediciones a
disposición de la organización y de los proyectos para su uso,
según proceda.
8. Modificar el repositorio de mediciones, el conjunto común de
medidas y los procedimientos, a medida que cambien las
necesidades de la organización.
Algunos ejemplos sobre cuándo puede ser necesario modificar el conjunto

común de medidas son:
• Al añadir nuevos procesos.
• Al modificar los procesos y necesitarse nuevas medidas.
• Al requerir una mayor granularidad de los datos.
• Al requerir una mayor visibilidad en el proceso.
• Al eliminar medidas.
sp 1.5 estableceR la biblioteca de activos de pRoceso de la oRganización

Establecer y mantener la biblioteca de activos de proceso de la organización.
Algunos ejemplos de elementos a almacenar en la biblioteca de activos de

proceso de la organización son:
• Políticas de la organización.
• Descripciones de proceso.
• Procedimientos (p. ej., procedimiento de estimación).
• Planes de desarrollo.
• Planes de adquisición.
• Planes de aseguramiento de la calidad.
• Materiales de formación.
• Ayudas al proceso (p. ej., listas de comprobación).
• Informes de lecciones aprendidas.

1. Diseño de la biblioteca de activos de proceso de la organización.
2. La biblioteca de activos de proceso de la organización.
3. Elementos seleccionados para incluirse en la biblioteca de
4. El catálogo de elementos de la biblioteca de activos de proceso
SUBPRÁCTICAS
1. Diseñar e implementar la biblioteca de activos de proceso de la
or- ganización, incluyendo la estructura de la biblioteca y el
entorno de soporte.
2. Especificar los criterios para incluir elementos en la biblioteca.
Los elementos se seleccionan basándose principalmente en su
rela- ción con el conjunto de procesos estándar de la
organización.
3. Especificar los procedimientos para almacenar, actualizar y
recuperar elementos.
4. Incorporar los elementos seleccionados en la biblioteca y
clasificarlos para facilitar su consulta y recuperación.
5. Poner los elementos a disposición de los proyectos para su uso.
6. Revisar periódicamente el uso de cada elemento.
7. Modificar la biblioteca de activos de proceso de la organización
OPD
Algunos ejemplos sobre cuándo puede ser necesario modificar la biblio-

teca son:
• Al añadir nuevos elementos.
• Al eliminar elementos.
• Al cambiar las versiones actuales de los elementos.
sp 1.6 e stableceR los estándaRes del entoRno de tRabajo

Establecer y mantener los estándares del entorno de trabajo.
Los estándares del entorno de trabajo permiten a la organización

y a los proyectos beneficiarse de las herramientas, formación y
mantenimiento comunes, así como un ahorro de costes por
volumen de compras. Los estándares del entorno de trabajo tratan
las necesidades de todas las partes interesadas y consideran los
factores de productividad, coste, disponibilidad, seguridad, y
salud, protección y ergonomía en el puesto de trabajo. Los
estándares del entorno de trabajo pueden incluir guías para la
adaptación y el uso de exenciones que permitan la adaptación
del entorno de trabajo del proyecto para cumplir las necesidades.
Algunos ejemplos de estándares del entorno de trabajo son:

• Procedimientos para la operación, protección y seguridad del entorno
de trabajo.
• Hardware y software de puesto de trabajo estándar.
• Software de aplicación estándar y guías para su adaptación.
• Equipos de producción y de calibración estándar.
• Proceso para solicitar y aprobar las adaptaciones o las exenciones.

1. Estándares del entorno de trabajo.
SUBPRÁCTICAS
1. Evaluar los estándares del entorno de trabajo comercialmente
disponibles apropiados para la organización.
2. Adoptar los estándares existentes del entorno de trabajo y
desarrollar nuevos estándares para cubrir las carencias,
basándose en las necesidades y en los objetivos de proceso de
la organización.
sp 1.7 estableceR las Reglas y guías paRa los equipos
Establecer y mantener las reglas y guías de la organización para la estructura,
constitución y funcionamiento de los equipos.
Las reglas y guías operativas para los equipos definen y controlan

cómo se crean y cómo interactúan para lograr los objetivos. Los
miembros del equipo deberían entender los estándares para
trabajar y participar de acuerdo a dichos estándares.
Cuando se establecen las reglas y guías para los equipos, se
debe asegurar que éstas cumplen las normativas o leyes, locales y
nacionales, que pueden afectar a su utilización por los equipos.
La estructuración de los equipos implica definir el número de
equipos, el tipo de cada equipo y cómo se relaciona cada equipo
con los demás en la estructura. La constitución de equipos
implica definir los estatutos de cada equipo, asignar los
miembros y los líderes, y proporcionar los recursos para que cada
equipo pueda cumplir con su trabajo.
1. Reglas y guías para estructurar y constituir equipos.
2. Reglas de funcionamiento para los equipos.
SUBPRÁCTICAS
1. Establecer y mantener los mecanismos para proporcionar
autoridad que permitan la toma de decisiones a tiempo.
En un entorno de éxito para el equipo, se establecen canales
claros de responsabilidad y autoridad mediante la documentación
y despliegue de guías de la organización que definan claramente
la autoridad de los equipos.
2. Establecer y mantener las reglas y guías para estructurar y
constituir equipos.
Los activos de procesos de la organización pueden ayudar al proyecto a

estructurar y constituir equipos. Algunos activos son:
• Guías para estructurar equipos.
• Guías para la constitución de equipos.
• Guías sobre autoridad y responsabilidad de equipos.
• Guías para establecer líneas de comunicación, autoridad y escalado.
• Criterios para la selección del líder de los equipos.
3. Definir las expectativas, reglas y guías que orienten sobre cómo
trabajan conjuntamente los equipos.
Estas reglas y guías establecen prácticas de la organización sobre la cohe-

rencia entre los equipos y pueden ser:
OPD
• Cómo se establecen y mantienen las interfaces entre los equipos.
• Cómo se aceptan y transfieren las asignaciones.
• Cómo se accede a los recursos y a las entradas.
• Cómo se realiza el trabajo.
• Quién comprueba, revisa y aprueba el trabajo.
• Cómo se aprueba el trabajo.
• Cómo se entrega y comunica el trabajo.
• Quién informa a quien.
• Cuáles son los requisitos de informes (p. ej., coste, calendario, estado
del rendimiento), las medidas y los métodos.
• Qué medidas y métodos se utilizan para el informe de progreso.
ENFOqUE EN PROCESOS DE LA ORGANIZACIÓN
OPF
Propósito
El propósito de Enfoque en Procesos de la Organización (OPF) es
planificar, implementar y desplegar las mejoras de proceso de
la orga- nización, basadas en una comprensión completa de las
fortalezas y debilidades actuales de los procesos y de los activos
de proceso de la organización.
Los procesos de la organización incluyen todos los procesos
utilizados por la organización y sus proyectos. Las mejoras
candidatas a los procesos y a los activos de proceso de la
organización se obtienen de diferentes fuentes, incluyendo la
medición de procesos, las lecciones aprendidas en la
implementación de procesos, los resultados de las evaluaciones
de proceso, los resultados de las actividades de evalua- ción de
productos y servicios, los resultados de las evaluaciones de
satisfacción del cliente, los resultados de benchmarking frente a
procesos de otras organizaciones, y las recomendaciones de otras
iniciativas de mejora en la organización.
La mejora de procesos tiene lugar en el contexto de las necesidades
de la organización y se utiliza para abordar los objetivos de la
organi- zación. La organización promueve la participación en
actividades de mejora de procesos de aquellos que realizan el
proceso. La responsabilidad de facilitar y gestionar las
actividades de mejora de procesos de la organización, incluyendo
la coordinación de la participación de otros, se asigna
normalmente a un grupo de procesos. La organización
proporciona el compromiso a largo plazo y los recursos
requeridos para patrocinar este grupo y asegurar el despliegue
eficaz y oportuno de las mejoras.
Se requiere una planificación cuidadosa para asegurar que los
esfuerzos de mejora de procesos en toda la organización se
gestionan e implementan adecuadamente. Los resultados de la
planificación de la mejora de procesos de la organización se
documentan en un plan de mejora de procesos.
317
El “plan de mejora de procesos de la organización” trata la
pla- nificación de la evaluación, la planificación de acción del
proceso, la planificación del piloto y la planificación del
despliegue. Los planes de evaluación describen la cronología y el
calendario de la evaluación, el alcance de la evaluación, los
recursos requeridos para realizar la evaluación, el modelo de
referencia frente al cual será realizada la eva- luación y la logística
para la evaluación.
Los planes de acción de proceso generalmente resultan de las
evaluaciones y documentan cómo se implementarán las mejoras
dirigidas a las debilidades descubiertas por una evaluación. A
veces, la mejora descrita en el plan de acción del proceso se
debería probar en un pe- queño grupo antes de que se despliegue
en toda la organización. En estos casos, se genera un plan para los
pilotos.
Cuando la mejora va a ser desplegada, se crea un plan de
despliegue. Este plan describe cuándo y cómo se desplegará la
mejora en toda la organización.
Los activos de proceso de la organización se utilizan para
describir, implementar y mejorar los procesos de la
organización (véase la definición de “activos de proceso de la
organización” en el glosario).


SG 1 Determinar las oportunidades de mejora de procesos.
SP 1.1 Establecer las necesidades de proceso de la organización.
SP 1.2 Evaluar los procesos de la organización.
SP 1.3 Identificar las mejoras de procesos de la organización.
SG 2 Planificar e implementar las acciones de proceso.
SP 2.1 Establecer los planes de acción de proceso.
SP 2.2 Implementar los planes de acción de proceso.
SG 3 Desplegar los activos de proceso de la organización e incorporar las experiencias.
SP 3.1 Desplegar los activos de proceso de la organización.
SP 3.2 Desplegar los procesos estándar.
SP 3.3 Monitorizar la implementación.
SP 3.4 Incorporar las experiencias en los activos de proceso de la organización.
sG 1 d eterminar Las oportunidades de mejora de procesos

Las fortalezas, las debilidades y las oportunidades de mejora para los procesos
de la organización se identifican periódicamente y según sea necesario.
Enfoque en procesos de la organización 319
Las fortalezas, las debilidades y las oportunidades de mejora
pueden determinarse en relación a un estándar o modelo de
proceso, tales como el modelo CMMI o el estándar ISO. Se
deberían seleccionar las mejoras de proceso para tratar las
necesidades de la organización.
Las oportunidades de mejora de procesos pueden surgir como
resultado de modificar los objetivos del negocio, los requisitos
legales y reguladores, y como resultado de estudios de
benchmarking.
sp 1.1 estableceR las necesidades de pRoceso de la oRganización
Establecer y mantener la descripción de las necesidades y de los objetivos de
proceso para la organización.
OPF
Los procesos de la organización funcionan en un contexto de
negocio que debería comprenderse. Los objetivos de negocio, las
necesidades y las limitaciones de la organización determinan
las necesidades y los objetivos para los procesos de la
organización. Normalmente, cuestiones relacionadas con la
satisfacción del cliente, las finanzas, la tecnología, la calidad, los
recursos humanos y el marketing son consideraciones
importantes de los procesos.
Las necesidades y los objetivos de proceso de la organización cubren as-

pectos que incluyen:
• Las características de los procesos.
• Los objetivos de rendimiento de proceso, tales como plazo de
comercialización (time-to-market) y calidad entregada.
• La eficacia del proceso.

1. Las necesidades y los objetivos de proceso de la organización.
SUBPRÁCTICAS
1. Identificar políticas, estándares y objetivos de negocio que sean
aplicables a los procesos de la organización.
Algunos ejemplos de estándares son:

• ISO/IEC 12207:2008 Systems and Software Engineering – Software Life
Cycle Processes [ISO 2008a].
• ISO/IEC 15288:2008 Systems and Software Engineering – System Life
Cycle Processes [ISO 2008b].
• ISO/IEC 27001:2005 Information Technology – Security Techniques –
Information Security Management Systems – Requirements [ISO/IEC
2005].
• ISO/IEC 14764: 2006 Software Engineering – Software Life Cycle
Processes – Maintenance [ISO 2006b].
Continúa
Continuación
• ISO/IEC 20000 Information Technology – Service Management [ISO 2005b].
• Assurance Focus for CMMI [DHS 2009].
• NDIA Engineering for System Assurance Guidebook [NDIA 2008].
• Resilience Management Model [SEI 2010c].
2. Examinar estándares y modelos de proceso relevantes de buenas
prácticas.
3. Determinar los objetivos de rendimiento de proceso de la
organización.
Los objetivos de rendimiento de proceso se pueden expresar en
térmi- nos cuantitativos o cualitativos.
PARA más INFORMACIÓN sobre cómo ESTABLECER los objetivos de medición,
PARA más INFORMACIÓN sobre cómo ESTABLECER los objetivos de CALIDAD y
de rendimiento de proceso, consúltese el árEA de proceso Rendimiento de
Procesos de LA OrGANIZACIÓN.
Algunos ejemplos de objetivos de rendimiento de procesos son:

• Conseguir una calificación de satisfacción del cliente de un
determinado valor.
• Asegurar que la fiabilidad del producto sea, como mínimo, un
porcentaje determinado.
• Reducir la tasa de inserción de defectos en un porcentaje determinado.
• Lograr un tiempo de ciclo determinado para una determinada actividad.
• Mejorar la productividad en un porcentaje determinado.
• Simplificar el flujo de trabajo de la aprobación de los requisitos.
• Mejorar la calidad de los productos entregados al cliente.
4. Definir características principales de los procesos de la
organización. Las características principales de los procesos de
la organización se determinan en base a:
Procesos que están siendo utilizados actualmente en la
organización. Estándares impuestos por la organización.
Estándares impuestos habitualmente por los clientes de la
organización.
Algunos ejemplos de características de procesos son:

• Nivel de detalle.
• Notación de proceso.
• Granularidad.
5. Documentar las necesidades y los objetivos de proceso de la

organización.
6. Modificar las necesidades y los objetivos de proceso de la
organiza- ción según sea necesario.
sp 1.2 evaluaR los pRocesos de la oRganización
Evaluar los procesos de la organización periódicamente y según sea necesario,
para mantener una comprensión de sus fortalezas y debilidades.
Las evaluaciones de proceso se pueden realizar por los siguientes motivos:

• Para identificar los procesos a mejorar.
• Para confirmar el progreso y dar visibilidad a los beneficios de la
mejora de procesos.
• Para satisfacer las necesidades de una relación cliente-proveedor.
OPF
• Para motivar y facilitar la involucración.
La involucración existente durante una evaluación de
procesos puede verse mermada significativamente si no es
seguida por un plan de acción basado en la evaluación.
1. Planes para las evaluaciones de proceso de la organización.
2. Hallazgos de la evaluación que tratan las fortalezas y las
debilidades de los procesos de la organización.
3. Recomendaciones de mejora para los procesos de la organización.
SUBPRÁCTICAS
1. Obtener el patrocinio de la alta dirección para la evaluación de
proceso. El patrocinio de la alta dirección incluye el compromiso
para hacer que los gerentes y el personal de la organización
participen en la eva-
luación de proceso, y para proporcionar los recursos y la
financiación con objeto de analizar y comunicar los hallazgos de
la evaluación.
2. Definir el alcance de la evaluación de proceso.
Las evaluaciones de proceso se pueden realizar en toda la
organiza- ción o en una parte más pequeña de la organización,
tal como un proyecto o un área de negocio.
El alcance de la evaluación de proceso trata:
La definición de la organización (p. ej., ubicaciones, áreas de
negocio) que se cubrirá en la evaluación.
La identificación del proyecto y de las funciones de soporte
que representarán a la organización en la evaluación.
Los procesos a evaluar.
3. Determinar el método y los criterios que se utilizarán para la
evalua- ción de proceso.
Las evaluaciones de proceso se pueden realizar de diferentes
formas. Éstas deberían tratar las necesidades y los objetivos de
la organiza- ción, que pueden cambiar con el tiempo.
Por ejemplo, la evaluación se puede basar en un modelo de
procesos, tal como el modelo CMMI, o en un estándar nacional o
internacional, tal como ISO 9001 [ISO 2008c]. Las evaluaciones
también se pueden basar en realizar un benchmarking con otras
organizaciones en las que se identifican las prácticas que pueden
contribuir a mejorar el rendimiento de la organización. Las
características del método de evaluación pueden variar
incluyendo el tiempo y el esfuerzo, la composición del equipo de
evaluación, y el método y la profundidad de la investigación.
4. Planificar, programar y preparar la evaluación de proceso.
5. Llevar a cabo la evaluación de proceso.
6. Documentar y entregar las actividades y los hallazgos de la evaluación.
sp 1.3 i dentificaR las mejoRas de pRoceso de la oRganización

Identificar las mejoras a los procesos y a los activos de proceso de la
organización.

1. Análisis de las mejoras de proceso candidatas.
2. Identificación de las mejoras para los procesos de la organización.
SUBPRÁCTICAS
1. Determinar las mejoras de proceso candidatas.
Las mejoras de proceso candidatas se determinan normalmente realizando

lo siguiente:
• Midiendo los procesos y analizando los resultados de la medición.
• Revisando los procesos en cuanto a su eficacia y adecuación.
• Evaluando la satisfacción del cliente.
• Revisando las lecciones aprendidas de la adaptación del conjunto de
• Revisando las lecciones aprendidas a partir de la implementación de
los procesos.
• Revisando las propuestas de mejora de procesos remitidas por los
gerentes, el personal y otras partes interesadas relevantes de la
organización.
• Solicitando información sobre mejoras de proceso a la alta dirección y a
otros líderes de la organización.
• Examinando los resultados de las evaluaciones de proceso y de otras
revisiones relativas a procesos.
• Revisando los resultados de otras iniciativas de mejora de la
organización.
2. Priorizar las mejoras de procesos candidatas.
Los criterios para la priorización son:
Considerar el coste y el esfuerzo estimados para implementar
las mejoras de proceso.
Evaluar la mejora esperada frente a los objetivos y a las
prioridades de mejora de la organización.
Determinar las barreras potenciales a las mejoras de proceso y
desarrollar las estrategias para superarlas.
Algunos ejemplos de técnicas para ayudar a determinar y a priorizar las po-

sibles mejoras a implementar son:
• Un análisis coste-beneficio, que compare el coste y esfuerzo estimados
para implementar las mejoras de proceso y los beneficios asociados.
• Un análisis de carencias, que compare las condiciones actuales en la
organización con las condiciones óptimas.
OPF
• Análisis de teoría del campo (Force-field analysis) de las mejoras
potenciales, para identificar barreras potenciales y estrategias para
superarlas.
• Análisis causa-efecto, para proporcionar información sobre los
efectos potenciales de las diversas mejoras que se pueden comparar
posteriormente.
3. Identificar y documentar las mejoras de proceso que se implementarán.

4. Modificar la lista de mejoras de procesos planificadas para
mantener- la actualizada.
sG 2 p Lanificar e impLementar Las acciones de proceso

Se planifican e implementan las acciones de proceso que tratan las mejoras a
los procesos y a los activos de proceso de la organización.
Para que la implementación de mejoras tenga éxito, se requiere que

los propietarios del proceso, los que realizan el proceso, y las
organizaciones de soporte participen en la planificación e
implementación de las acciones de proceso.
sp 2.1 estableceR los planes de acción de pRoceso
Establecer y mantener los planes de acción de proceso para tratar las mejoras a
los procesos y a los activos de proceso de la organización.
El establecimiento y mantenimiento de los planes de acción de proceso

normalmente involucra a los siguientes roles:
• Comités de dirección que establecen estrategias y supervisan las
actividades de mejora de procesos.
• Grupos de proceso que facilitan y gestionan las actividades de mejora
de proceso.
• Equipos de acción de proceso que definen e implementan las acciones
de proceso.
• Propietarios del proceso que gestionan el despliegue.
• Profesionales que llevan a cabo el proceso.
La involucración de las partes interesadas ayuda a obtener el
compromiso en las mejoras de procesos e incrementa la
probabilidad de un despliegue eficaz.
Los planes de acción de proceso son planes de implementación
detallados. Estos planes difieren del plan de mejora de procesos de
la organi- zación, en que apuntan a las mejoras que han sido definidas
para tratar las debilidades y que generalmente fueron descubiertas
por las evaluaciones.
1. Planes de acción de proceso de la organización aprobados.
SUBPRÁCTICAS
1. Identificar las estrategias, las aproximaciones y las acciones para
tratar las mejoras de procesos identificadas.
Las novedades, los cambios no probados y los cambios
importantes son sometidos a un pilotaje antes de incorporarlos a
un uso normal.
2. Establecer los equipos de acción de proceso para implementar
las acciones.
Se denominan “equipos de acción de proceso” a los equipos y al
personal que realiza las acciones de mejora de procesos. Los
equipos de acción de proceso incluyen, normalmente, a los
propietarios del proceso y a aquellos que llevan a cabo el
proceso.
3. Documentar los planes de acción de proceso.
Los planes de acción de proceso normalmente cubren:

• La infraestructura de la mejora de procesos.
• Los objetivos de la mejora de procesos.
• Las mejoras de procesos a tratar.
• Los procedimientos para la planificación y el seguimiento de las
acciones de proceso.
• Las estrategias para llevar a cabo pilotos e implementar las acciones de
proceso.
• La responsabilidad y la autoridad para implementar las acciones de proceso.
• Los recursos, los calendarios y las asignaciones para la implementación
de las acciones de proceso.
• Los métodos para determinar la eficacia de las acciones de proceso.
• Los riesgos asociados con los planes de acción de proceso.
4. Revisar y negociar los planes de acción de proceso con las partes
interesadas relevantes.
5. Modificar los planes de acción de proceso según sea necesario.
sp 2.2 implementaR los planes de acción de pRoceso
Implementar los planes de acción de proceso.

1. Compromisos entre los equipos de acción de proceso.
2. Estado y resultados de la implementación de los planes de
acción de proceso.
3. Planes de los proyectos piloto.
SUBPRÁCTICAS
1. Poner los planes de acción de proceso a disposición de las
partes interesadas relevantes.
2. Negociar y documentar los compromisos entre los equipos de
acción de proceso y modificar sus planes de acción de proceso, según
sea necesario.
3. Seguir el progreso y los compromisos frente a los planes de
acción de proceso.
OPF
4. Llevar a cabo revisiones conjuntas con los equipos de acción de
proceso y con las partes interesadas relevantes para
monitorizar el progreso y los resultados de las acciones de
proceso.
5. Planificar los proyectos piloto necesarios para probar las
mejoras de procesos seleccionadas.
6. Revisar las actividades y los productos de trabajo de los equipos
de acción de proceso.
7. Identificar, documentar y seguir hasta su cierre las cuestiones
encontradas cuando se implementan los planes de acción de
proceso.
8. Asegurar que los resultados de la implementación de los planes
de acción de proceso satisfacen los objetivos de mejora de
procesos de la organización.
sG 3 despLeGar Los activos de proceso de La orGanización e incorporar Las experiencias
Los activos de proceso de la organización se despliegan en toda la organización
y las experiencias relativas a procesos se incorporan a los activos de proceso de
la organización.
Las prácticas específicas bajo esta meta específica describen las
actividades en curso. Durante la vida del proyecto, pueden
surgir nuevas oportunidades para obtener beneficios de los
activos de proceso de la organización y de sus cambios. Se debe
proporcionar un soporte continuado en la organización al
despliegue de los procesos estándar y de otros activos de proceso
de la organización, particularmente en el arranque de los nuevos
proyectos.
sp 3.1 desplegaR los activos de pRoceso de la oRganización
Desplegar los activos de proceso de la organización en toda la organización.
El despliegue de los activos de proceso de la organización, o los
cambios a estos activos, se debería realizar de una manera
ordenada. Algu- nos activos de proceso de la organización o
cambios a éstos pueden no ser apropiados para su utilización en
algunas áreas de la organización (p. ej., debido a requisitos de las
partes interesadas o a la fase actual del ciclo de vida que se está
implementando). Por lo tanto, es importante que aquellos que
están o estarán ejecutando el proceso, así como otras
funciones de la organización (p. ej., formación, aseguramiento de
la calidad), estén involucrados en el despliegue según sea
necesario.
PARA más INFORMACIÓN sobre cómo ESTABLECER ACTIVOS de proceso de LA ORGANIZA-
ción, consúltese el árEA de proceso Definición de Procesos de LA OrGANIZACIÓN.

1. Planes para el despliegue de los activos de proceso de la
organización y los cambios a estos activos en toda la
organización.
2. Materiales de formación para el despliegue de los activos de
proceso de la organización y los cambios a estos activos.
3. Documentación de los cambios a los activos de proceso de la
organización.
4. Materiales de soporte para el despliegue de los activos de
proceso de la organización y los cambios a estos activos.
SUBPRÁCTICAS
1. Desplegar los activos de proceso de la organización en toda la
organización.
Algunas actividades típicas realizadas como parte del despliegue de los ac-
tivos de proceso son:
• Identificar los activos de proceso de la organización que se deberían
adoptar por aquellos que llevan a cabo el proceso.
• Determinar cómo se ponen a disposición los activos de proceso de la
organización (p. ej., mediante sitio web).
• Identificar cómo se comunican los cambios a los activos de proceso de
la organización.
• Identificar los recursos (p. ej., métodos, herramientas) necesarios para
dar soporte a la utilización de los activos de proceso de la organización.
• Planificar el despliegue.
• Ayudar a aquellos que usan los activos de proceso de la organización.
• Asegurar que la formación está disponible para aquellos que usan los
PARA más INFORMACIÓN sobre cómo ESTABLECER UNA CAPACIDAD de FORMA-
ción de LA ORGANIZACIÓN, consúltese el árEA de proceso FORMACIÓN en LA
OrGANIZACIÓN.
2. Documentar los cambios en los activos de proceso de la
organización. Documentar los cambios en los activos de proceso
de la organización sirve para dos propósitos principales:
Permitir la comunicación de los cambios.
Comprender la relación entre los cambios en los activos de
proceso de la organización y los cambios en el rendimiento de
proceso y en los resultados.
3. Desplegar los cambios realizados a los activos de proceso de la
orga- nización en toda la organización.
Algunas actividades típicas realizadas como parte del despliegue de cam-

bios son:
• Determinar qué cambios son apropiados para los que llevan a cabo el
proceso.
• Planificar el despliegue.
• Organizar el soporte necesario para que la transición de los cambios
tenga éxito.
4. Proporcionar orientación y consultoría sobre la utilización de los
activos de proceso de la organización.
OPF
sp 3.2 d esplegaR los pRocesos estándaR
Desplegar el conjunto de procesos estándar de la organización para los proyec-
tos en su arranque y desplegar los cambios de estos procesos estándar según
proceda durante la vida de cada proyecto.
Es importante que los nuevos proyectos utilicen procesos proba-

dos y eficaces para realizar las actividades críticas iniciales (p.
ej., planificación del proyecto, recepción de requisitos, obtención
de recursos).
Los proyectos deberían también actualizar periódicamente sus
procesos definidos, para incorporar los últimos cambios
realizados al conjunto de procesos estándar de la organización
cuando esto les sea beneficioso. Esta actualización periódica
ayuda a asegurar que todas las actividades del proyecto obtienen
todo el beneficio de lo aprendido en otros proyectos.
PARA más INFORMACIÓN sobre cómo ESTABLECER procesos ESTÁNDAR y ESTA-
blecer criterios y GUÍAS de ADAPTACIÓN, consúltese el árEA de proceso Defi-
nición de Procesos de LA OrGANIZACIÓN.

1. Lista de proyectos de la organización y el estado del despliegue
del proceso en cada proyecto (es decir, proyectos existentes y
planificados).
2. Guías para el despliegue del conjunto de procesos estándar de la
or- ganización en nuevos proyectos.
3. Registros de la adaptación e implementación del conjunto de
procesos estándar de la organización.
SUBPRÁCTICAS
1. Identificar los proyectos que están comenzando en la organización.
2. Identificar los proyectos activos que se beneficiarían de la im-
plementación del conjunto actual de procesos estándar de la
organización.
3. Establecer los planes para implementar el conjunto actual de
procesos estándar de la organización en los proyectos
identificados.
4. Ayudar a los proyectos en la adaptación del conjunto de
procesos estándar de la organización para cumplir sus
necesidades.
PARA más INFORMACIÓN sobre cómo ESTABLECER el proceso definido del pro-
yecto, consúltese el árEA de proceso Gestión INTEGRADA del Proyecto.
5. Mantener los registros de adaptación e implementación de los
procesos en los proyectos identificados.
6. Asegurar que los procesos definidos que resultan de la adaptación
del proceso se incorporan a los planes para las auditorías de
conformidad del proceso.
Las auditorías de conformidad del proceso son evaluaciones
objetivas de las actividades del proyecto frente al proceso definido
del proyecto.
7. A medida que se actualiza el conjunto de procesos estándar de la
orga- nización identifique qué proyectos deberían implementar los
cambios.
sp 3.3 m onitoRizaR la implementación

Monitorizar la implementación del conjunto de procesos estándar de la organi-
zación y la utilización de los activos de proceso en todos los proyectos.
Con la monitorización de la implementación, la organización se

asegura que el conjunto de procesos estándar de la organización
y otros activos de proceso están apropiadamente desplegados en
todos los proyectos. La monitorización de la implementación
también ayuda a la organización a desarrollar una comprensión de
los activos de proceso que se están utilizando y dónde se utilizan
en la organización. La mo- nitorización también ayuda a
establecer un contexto más amplio para interpretar y utilizar las
medidas de proceso y de producto, las lecciones aprendidas y la
información de mejora obtenida de los proyectos.

1. Resultados de monitorizar la implementación de procesos en los proyectos.
2. Estado y resultados de las auditorias de conformidad de proceso.
3. Resultados de la revisión de los artefactos de proceso
seleccionados creados como parte de la adaptación e
implementación de procesos.
SUBPRÁCTICAS
1. Monitorizar el uso de los activos de proceso de la organización
en el proyecto y los cambios a estos activos.
2. Revisar los artefactos de proceso seleccionados creados durante
la vida de cada proyecto.
La revisión de los artefactos de proceso seleccionados, creados
durante la vida de un proyecto, asegura que todos los proyectos
están haciendo un uso apropiado del conjunto de procesos estándar
3. Revisar los resultados de las auditorías de conformidad del
proceso para determinar cómo se ha desplegado el conjunto de
procesos es- tándar de la organización.
PARA más INFORMACIÓN sobre cómo EVALUAR OBJETIVAMENTE los procesos,
consúltese el árEA de proceso ASEGURAMIENTO de LA CALIDAD del Proceso y
del Producto.
4. Identificar, documentar y seguir hasta su cierre las cuestiones
relativas a la implementación del conjunto de procesos
sp 3.4 incoRpoRaR las expeRiencias en los activos de pRoceso de la oRganización

Incorporar las experiencias relativas al proceso derivadas de la planificación y
realización del proceso en los activos de proceso de la organización.
OPF
1. Propuestas de mejora de procesos.
2. Lecciones aprendidas de proceso.
3. Mediciones de los activos de proceso de la organización.
4. Recomendaciones de mejora para los activos de proceso de la
organización.
5. Registros de las actividades de mejora de procesos de la organización.
6. Información sobre los activos de proceso de la organización y
sus mejoras.
SUBPRÁCTICAS
1. Llevar a cabo revisiones periódicas de la eficacia y de la adecuación
del conjunto de procesos estándar y de los activos de proceso
relativos a la organización relacionados con las necesidades del
proceso y los objetivos derivados a partir de los objetivos de
negocio de la organización.
2. Obtener realimentación sobre el uso de los activos de proceso
3. Obtener las lecciones aprendidas a partir de la definición, la
realiza- ción de pilotos, la implementación y el despliegue de
los activos de proceso de la organización.
4. Poner las lecciones aprendidas a disposición del personal de la
orga- nización según proceda.
Puede ser necesario tomar acciones para asegurar que las
lecciones aprendidas se usan adecuadamente.
Algunos ejemplos del uso inadecuado de lecciones aprendidas son:

• Evaluación del desempeño del personal.
• Juicio del rendimiento o del proceso o de los resultados.
Algunos ejemplos de formas para prevenir el uso inadecuado de las leccio-

nes aprendidas son:
• Controlar el acceso a las lecciones aprendidas.
• Educar al personal sobre el uso adecuado de las lecciones aprendidas.
5. Analizar los datos de medición obtenidos a partir de la utilización
del conjunto común de medidas de la organización.
PARA más INFORMACIÓN sobre cómo ANALIZAR los DATOS de LAS mediciones,
PARA más INFORMACIÓN sobre cómo ESTABLECER el repositorio de mediciones
de LA ORGANIZACIÓN, consúltese el árEA de proceso Definición de Procesos
de LA OrGANIZACIÓN.
6. Evaluar los procesos, los métodos y las herramientas que se
utilicen en la organización y desarrollar recomendaciones para
mejorar los activos de proceso de la organización.
Esta evaluación incluye normalmente:

• Determinar qué procesos, métodos y herramientas son de uso potencial
para otras áreas de la organización.
• Evaluar la calidad y la eficacia de los activos de proceso de la
organización.
• Identificar las mejoras candidatas a los activos de proceso de la
organización.
• Determinar la conformidad con el conjunto de procesos estándar de la
organización y con sus guías de adaptación.
7. Poner los mejores procesos, métodos y herramientas de la
organiza- ción a disposición, de las personas de la organización,
según proceda.
8. Gestionar las propuestas de mejora de procesos.
Las propuestas de mejora de procesos pueden tratar tanto las
mejoras de procesos como las mejoras de tecnología.
Las actividades para gestionar las propuestas de mejora de procesos inclu-

yen normalmente:
• Solicitar las propuestas de mejora de procesos.
• Recoger las propuestas de mejora de procesos.
• Revisar las propuestas de mejora de procesos.
• Seleccionar las propuestas de mejora de procesos a implementar.
• Seguir la implementación de las propuestas de mejora de procesos.
Las propuestas de mejora de procesos se documentan como

peticiones de cambio de procesos o como informes de problemas,
según proceda.
Algunas propuestas de mejora de procesos se pueden incorporar
en los planes de acción de proceso de la organización.
9. Establecer y mantener los registros de las actividades de mejora
de procesos de la organización.
gestión del rendimiento de la organización

Propósito
El propósito de la Gestión del Rendimiento de la Organización
(OPM) es gestionar proactivamente el rendimiento de la
organización para satisfacer sus objetivos de negocio.
El área de proceso Gestión del Rendimiento de la Organización
OPM
permite gestionar el rendimiento de la organización analizando
iterativamente los datos agregados de proyectos, identificando
carencias en el rendimiento frente a los objetivos de negocio, y
seleccionando y desplegando mejoras para subsanar las
carencias.
En este área de proceso, el término “mejora” incluye todas
las mejoras de proceso y de tecnología tanto incrementales como
innovadoras, incluyendo aquellas mejoras realizadas sobre los
entornos de trabajo del proyecto. La “mejora” se refiere a
cualquier idea que podría cambiar los procesos, las tecnologías y
el rendimiento de la organización para satisfacer mejor los
objetivos de negocio de la or- ganización y los objetivos
asociados de calidad y de rendimiento del proceso.
Los objetivos de negocio que este área de proceso podría
tratar son:
• Mejora de la calidad del producto (p. ej., funcionalidad,
atributos de calidad).
• Aumento de la productividad.
• Aumento de la eficiencia y eficacia del proceso.
• Aumento de la regularidad en el cumplimiento del
presupuesto y del calendario.
• Reducción del tiempo de ciclo.
• Mayor satisfacción del cliente y del usuario final.
• Reducción del tiempo de desarrollo o de producción para
cambiar la funcionalidad, añadir nuevas características o
adaptarse a las nuevas tecnologías.
331
332 segunda parte Las Áreas de prOCesO
• Mejora del rendimiento de una cadena de suministro que
involucre a múltiples proveedores.
• Mejora del uso de los recursos en toda la organización.
La organización analiza los datos de rendimiento del

producto y de proceso de los proyectos para determinar si es
capaz de cumplir los objetivos de calidad y de rendimiento de
proceso. Como parte del análisis, se usan las líneas base de
rendimiento de proceso y los modelos de rendimiento de
proceso, desarrollados utilizando los procesos de rendimiento
del proceso de la organización. Los procesos de análisis causal
y resolución pueden utilizarse también para identificar áreas
potenciales de mejora o propuestas de mejora específicas.
La organización identifica y solicita proactivamente mejoras
incrementales e innovadoras internamente y desde fuentes
externas, tales como, el mundo académico, la inteligencia
competitiva y las mejoras implementadas con éxito en otros
lugares.
La ejecución de las mejoras y sus efectos sobre los objetivos
de calidad y de rendimiento de proceso dependen de la capacidad
para identificar, evaluar, implementar y desplegar con eficacia
mejoras sobre los procesos y las tecnologías de la organización.
La ejecución de las mejoras y los efectos beneficiosos también
dependen del compromiso del personal para identificar y
evaluar las posibles mejoras y para mantener el foco en la
planificación a largo plazo que incluya la identificación de
innovaciones.
Las propuestas de mejora se evalúan y se validan para
determinar su eficacia en el entorno objetivo. En base a esta
evaluación, se priorizan y se seleccionan las mejoras para el
despliegue en nuevos proyectos y en proyectos en curso. El
despliegue se gestiona de acuerdo al plan de despliegue y se
analizan los datos de rendimiento utilizando técnicas estadísticas
y otras técnicas cuantitativas, para determinar los efectos de la
mejora sobre los objetivos de calidad y de rendimiento de proceso.
Este ciclo de mejora optimiza continuamente los procesos de
la or- ganización en base a los objetivos de calidad y de
rendimiento del proceso. Los objetivos de negocio se revisan
periódicamente para asegurar que están actualizados, y que los
objetivos de calidad y de rendimiento del proceso se actualizan,
según proceda.
El área de proceso Enfoque en Procesos de la Organización
no incluye ni supuestos sobre la base cuantitativa para identificar
mejoras, ni sus resultados esperados. Este área de proceso
amplía las prácticas de Enfoque en Procesos de la Organización,
enfocándose en la mejora de procesos en base a un entendimiento
cuantitativo del conjunto de procesos y tecnologías estándar de la
organización, y el rendimiento esperado de calidad y de proceso.
Gestión del rendimiento de la organización 333
Las prácticas específicas de este área de proceso se aplican a
organizaciones cuyos proyectos se gestionan cuantitativamente.
El uso de las prácticas específicas de este área de proceso puede
añadir valor en otras situaciones, pero los resultados pueden no
proporcionar el mismo grado de impacto en los objetivos de
calidad y de rendimiento del proceso de la organización.

PARA más INFORMACIÓN sobre cómo IDENTIFICAR LAS CAUSAS de los rESULTADOS selec-
CIONADOS y TOMAR ACCIONES PARA MEJORAR el rendimiento de proceso, consúltese el
árEA de proceso Análisis CAUSAL y Resolución.
PARA más INFORMACIÓN sobre cómo ANALIZAR posibles decisiones UTILIZANDO un
proceso de EVALUACIÓN FORMAL que EVALÚE LAS ALTERNATIVAS IDENTIFICADAS frente A
los criterios ESTABLECIDOS, consúltese el árEA de proceso Análisis de Decisiones y
Resolución.
PARA más INFORMACIÓN sobre cómo ALINEAR LAS ACTIVIDADES de medición y ANÁLISIS,
OPM
Análisis.
PARA más INFORMACIÓN sobre cómo PLANIFICAR, IMPLEMENTAR y DESPLEGAR MEJORAS de
proceso en LA ORGANIZACIÓN en BASE A un conocimiento profundo de LAS FORTALEZAS y
DEBILIDADES ACTUALES de los procesos y de los ACTIVOS de proceso de LA ORGANIZACIÓN,
consúltese el árEA de proceso Enfoque en Procesos de LA OrGANIZACIÓN.
PARA más INFORMACIÓN sobre cómo ESTABLECER los objetivos de CALIDAD y de ren-
dimiento del proceso, y cómo ESTABLECER LAS LÍNEAS BASE y los modelos de rendi-
miento de proceso, consúltese el árEA de proceso Rendimiento de Procesos de LA
OrGANIZACIÓN.
PARA más INFORMACIÓN sobre cómo proporCIONAR FORMACIÓN, consúltese el árEA de
proceso FORMACIÓN en LA OrGANIZACIÓN.
resumen de metas y prácticas específicas

sg 1 gestionar el rendimiento de negocio.
sp 1.1 Mantener los objetivos de negocio.
sp 1.2 analizar los datos de rendimiento de proceso.
sp 1.3 Identificar las áreas potenciales para la mejora.
sg 2 seleccionar las mejoras.
sp 2.1 educir las sugerencias de mejora.
sp 2.2 analizar las sugerencias de mejora.
sp 2.3 Validar las mejoras.
sp 2.4 seleccionar e implementar las mejoras para el despliegue.
sg 3 desplegar las mejoras.
sp 3.1 planificar el despliegue.
sp 3.2 gestionar el despliegue.
sp 3.3 evaluar los efectos de la mejora.
SG 1 G eStionar el rendimiento de neGocio

El rendimiento del negocio de la organización se gestiona utilizando técnicas
estadísticas y otras técnicas cuantitativas para comprender carencias de rendi-
miento de proceso, y para identificar áreas para la mejora de procesos.
La gestión del rendimiento de negocio requiere:
• Mantener los objetivos de negocio de la organización.
• Comprender la capacidad de la organización para satisfacer
los objetivos de negocio.
• Mejorar continuamente los procesos relacionados para
conseguir los objetivos de negocio.
La organización utiliza las líneas base de rendimiento del
proceso definido, para determinar si se están cumpliendo los
objetivos de negocio de la organización actuales y previstos.
Las carencias en el rendimiento del proceso se identifican y se
analizan para determinar áreas potenciales para la mejora de
procesos.
PARA más INFORMACIÓN sobre cómo ESTABLECER LAS LÍNEAS BASE y los modelos de
rendimiento de proceso, consúltese el árEA de proceso Rendimiento de Procesos de
LA OrGANIZACIÓN.
A medida que la organización mejora su rendimiento de
proceso o a medida que cambian las estrategias de negocio, se
identifican nuevos objetivos de negocio y se obtienen objetivos
asociados de calidad y de rendimiento de proceso.
La meta específica 2 se dirige a la educción y el análisis de las
sugerencias de mejoras que traten las carencias para alcanzar los
objetivos de calidad y de rendimiento de proceso.
SP 1.1 Mantener los objetivos de negocio
Mantener los objetivos de negocio en base a un entendimiento de las estrate-
gias de negocio y de los resultados reales del rendimiento.
Los datos de rendimiento de la organización, caracterizados por

las líneas base de rendimiento de proceso, se utilizan para
evaluar si los objetivos de negocio son realistas y están alineados
con las estrategias de negocio. Una vez que se hayan modificado
y priorizado los objetivos de negocio por la alta dirección, puede
ser necesario crear o mantener y volver a comunicar los

1. Objetivos de negocio modificados.
2. Objetivos de calidad y de rendimiento de proceso modificados.

3. Aprobación por la alta dirección de los objetivos de negocio y
de los objetivos de calidad y de rendimiento de proceso
modificados.
4. Comunicación de todos los objetivos modificados.
5. Medidas de rendimiento de proceso actualizadas.
SUBPRÁCTICAS
1. Evaluar los objetivos de negocio periódicamente para asegurar
que están alineados con las estrategias de negocio.
La alta dirección es responsable de conocer el mercado, de
establecer las estrategias de negocio y de establecer los objetivos de
negocio.
Los objetivos de negocio deberían revisarse periódicamente, dado
que las estrategias de negocio y el rendimiento de la organización
evolucionan, para determinar si deberían actualizarse. Por
ejemplo, un objetivo de negocio podría ser eliminado cuando los
datos de rendimiento de proceso muestran que el objetivo de
negocio se está cumpliendo con regularidad a lo largo del tiempo o
cuando cambia la estrategia de negocio asociada.
2. Comparar los objetivos de negocio con los resultados reales de
OPM
rendimiento de proceso para asegurar que son realistas.
Los objetivos de negocio pueden poner el listón demasiado alto
para motivar la mejora real. La utilización de las líneas base de
rendimiento de proceso ayuda a equilibrar los deseos con la
realidad.
Si no se dispone de líneas base de rendimiento del proceso se
pueden utilizar técnicas de muestreo para desarrollar una base
cuantitativa para la comparación en un periodo corto de tiempo.
3. Priorizar los objetivos de negocio en base a criterios
documentados, tales como la capacidad de conseguir nuevos
negocios, retener a los clientes existentes o llevar a cabo otras
estrategias clave de negocio.
4. Mantener los objetivos de calidad y de rendimiento del proceso
para tratar los cambios en los objetivos de negocio.
Los objetivos de negocio y los objetivos de calidad y de
rendimiento de proceso normalmente evolucionarán con el tiempo.
A medida que se alcanzan los objetivos existentes, éstos se
monitorizarán para asegurar que se sigan cumpliendo, mientras que
se identificarán y se gestionarán los nuevos objetivos de negocio y
los objetivos asociados de calidad y de rendimiento del proceso.
PARA más INFORMACIÓN sobre cómo ESTABLECER los objetivos de CALIDAD y de
rendimiento de proceso, consúltese el árEA de proceso Rendimiento de Pro-
cesos de LA OrGANIZACIÓN.
5. Modificar las medidas de rendimiento de proceso para
alinearlas con los objetivos de calidad y de rendimiento de
proceso.
PARA más INFORMACIÓN sobre cómo ESTABLECER MEDIDAS de rendimiento
de proceso, consúltese el árEA de proceso Rendimiento de Procesos de LA
OrGANIZACIÓN.
SP 1.2 analizar los datos de rendiMiento de proceso
Analizar los datos de rendimiento de proceso para determinar la capacidad de
la organización para satisfacer los objetivos de negocio identificados.
Los datos que resultan de aplicar las medidas de rendimiento de

proceso, que se definen utilizando los procesos de rendimiento
de procesos de la organización, se analizan para crear las líneas
base de rendimien- to de proceso que ayuden a comprender la
capacidad actual de la orga- nización. La comparación de las
líneas base de rendimiento de proceso con los objetivos de calidad
y de rendimiento de proceso, ayuda a la organización a
determinar su capacidad para cumplir los objetivos de negocio.
Estos datos normalmente se recogen de los datos de rendi-
miento de proceso a nivel de proyecto para posibilitar el análisis

1. Análisis de la capacidad actual frente a los objetivos de negocio.
2. Carencias del rendimiento de proceso.
3. Riesgos asociados con el cumplimiento de los objetivos de negocio.
SUBPRÁCTICAS
1. Comparar periódicamente los objetivos de calidad y de
rendimiento de proceso con las líneas base actuales de
rendimiento de proceso para evaluar la capacidad de la
organización para satisfacer sus objetivos de negocio.
Por ejemplo, si el tiempo de ciclo es una necesidad critica de
negocio, se pueden recoger diferentes medidas de tiempo de ciclo
por la organi- zación. Los datos globales de rendimiento del tiempo
de ciclo deberían compararse con los objetivos de negocio para
comprender si el rendimiento esperado satisfará los objetivos de
negocio.
2. Identificar las carencias en las que el rendimiento del proceso
actual no satisface los objetivos de negocio.
3. Identificar y analizar los riesgos asociados con el
incumplimiento de los objetivos de negocio.
4. Comunicar a la dirección de la organización los resultados del
rendimiento de proceso y del análisis de riesgos.
SP 1.3 identificar las áreas potenciales para la Mejora

Identificar las áreas potenciales para la mejora que podrían contribuir a cum-
plir con los objetivos de negocio.
Las áreas potenciales para la mejora se identifican a través de un

análi- sis proactivo para determinar las áreas que podrían tratar las
carencias
de rendimiento del proceso. Los procesos de análisis causal y
resolu- ción se pueden utilizar para diagnosticar y resolver las
causas raíz.
El resultado de esta actividad se utiliza para evaluar y
priorizar las mejoras potenciales, y puede proporcionar
sugerencias de mejora incrementales o innovadoras tal y como se
describe en la meta espe- cífica 2.

1. Áreas potenciales para la mejora.
SUBPRÁCTICAS
1. Identificar áreas potenciales para la mejora en base al análisis
de las carencias de rendimiento de proceso.
Las carencias de rendimiento incluyen el incumplimiento de los
objetivos de productividad, de tiempo de ciclo o de satisfacción
del cliente. Algunos ejemplos de áreas a considerar para mejorar
son la tecnología de producto, la tecnología de procesos, el
reclutamiento y el desarrollo de personal, las estructuras de equipos,
la selección y gestión de proveedores, y otras infraestructuras de
OPM
la organización.
2. Documentar el análisis razonado de la selección de áreas
potenciales de mejora, incluyendo referencias a objetivos de
negocio aplicables y a datos de rendimiento de proceso.
3. Documentar los costes y beneficios previstos asociados con el
tratamiento de las áreas potenciales de mejora.
4. Comunicar el conjunto de áreas potenciales de mejora para su
posterior evaluación, priorización y utilización.
SG 2 S eleccionar laS mejoraS

Las mejoras se identifican proactivamente, se evalúan usando técnicas esta-
dísticas y otras técnicas cuantitativas, y se seleccionan para su despliegue en
base a su contribución para el cumplimento de los objetivos de calidad y de
Las mejoras a desplegar en toda la organización se seleccionan de

entre las sugerencias de mejora que se han evaluado en cuanto a
su eficacia en el entorno de despliegue destino. Estas sugerencias
de mejora se educen y se remiten a toda la organización para tratar
las áreas de mejora identificadas en la meta específica 1.
Las evaluaciones de sugerencias de mejoras se basan en:
• Una comprensión cuantitativa de la calidad y del rendimiento
del proceso actuales de la organización.
• La satisfacción de los objetivos de calidad y de rendimiento
del proceso de la organización.
• Los costes e impactos estimados del desarrollo y despliegue
de las mejoras, de los recursos, y de la financiación
disponible para el despliegue.
• Los beneficios estimados en la calidad y en el rendimiento de
proceso resultante del despliegue de las mejoras.
SP 2.1 educir las sugerencias de Mejora
Educir y categorizar las sugerencias de mejora.
Esta práctica se centra en educir las sugerencias de mejora e in-

cluye la categorización dichas mejoras como incrementales o
innovadoras.
Las mejoras incrementales generalmente se originan por
quienes hacen el trabajo (es decir, usuarios de proceso o de
tecnología). Las mejoras incrementales pueden ser sencillas y
baratas de implementar y desplegar. Las sugerencias de mejora
incrementales se analizan, pero, si se seleccionan, puede que no
sea necesario realizar una validación rigurosa o un piloto. Las
mejoras innovadoras, tales como procesos nuevos o rediseñados,
son mejoras de transformación más que mejoras incrementales.
Las mejoras innovadoras con frecuencia surgen de una
búsqueda sistemática de soluciones a cuestiones de rendimiento
particulares o de oportunidades para mejorar el rendimiento.
Estas mejoras se identifican por quienes tienen formación y
experiencia en la madurez de determinadas tecnologías o por
aquellos cuyo trabajo es seguir o contribuir directamente a
aumentar el rendimiento.
Las innovaciones pueden encontrarse externamente monitori-
zando activamente innovaciones utilizadas en otras
organizaciones o documentadas en la literatura de investigación.
Las innovaciones tam- bién pueden provenir de fuentes internas
(p. ej., examinando las lecciones aprendidas de los proyectos).
Las innovaciones están motivadas por la necesidad de alcanzar los
objetivos de calidad y de rendimiento de proceso, por la necesidad
de mejorar las líneas base de rendimiento, o por el entorno externo
del negocio.
algunos ejemplos de mejoras incrementales son:

 añadir un elemento a una lista de comprobación de revisión entre
pares.
 aunar la revisión técnica y la revisión de gestión para proveedores en
una sola revisión.
 Incorporar una solución temporal a una incidencia.
 sustituir un nuevo componente.
 Llevar a cabo actualizaciones menores a una herramienta.
algunos ejemplos de mejoras innovadoras normalmente son ampliaciones

o actualizaciones importantes sobre:
 Ordenadores y productos relacionados con el hardware.
 Herramientas de soporte transformacional.
 Flujos de trabajo nuevos o rediseñados.
 procesos o modelos de ciclo de vida.
 estándares de interfaz.
 Componentes reutilizables.
 técnicas y metodologías de gestión.
 técnicas y metodologías de mejora de la calidad.
 técnicas y metodologías de desarrollo.
Algunas sugerencias de mejora pueden recibirse en forma de

una propuesta (es decir, una propuesta de mejora de la
organización surgida de una actividad de análisis causal y
resolución). Estas sugerencias de mejora se analizarán y
documentarán antes de la entrada a los procesos de gestión del
OPM
rendimiento de la organización. Cuando se reciban las
sugerencias de mejora como propuestas, las propuestas se revisan
en cuanto a su completitud y se evalúan como parte del proceso
de selección para su implementación.
La búsqueda de mejoras puede implicar buscar fuera de la or-
ganización, obtener innovaciones de proyectos que están utilizan-
do los procesos de análisis causal y resolución, utilizar
inteligencia de negocios competitiva, o analizar el rendimiento
existente de la organización.

1. Sugerencias de mejora incrementales.
2. Sugerencias de mejora innovadoras.
SUBPRÁCTICAS
1. Educir las mejoras sugeridas.
Estas sugerencias documentan mejoras potenciales a los procesos
y a las tecnologías. Los gerentes y el personal en la organización,
así como los clientes, los usuarios finales y los proveedores,
pueden enviar sugerencias. La organización también puede
buscar sugerencias de mejora en las comunidades académica y
tecnológica. Algunas sugerencias de mejora se pueden haber
implementado a nivel de proyecto antes de pro- ponerse a la
organización.
algunos ejemplos de fuentes para las mejoras son:

 Hallazgos y recomendaciones de las evaluaciones de proceso.
 Los objetivos de calidad y de rendimiento de proceso de la
organización.
 análisis de datos sobre problemas del cliente y del usuario final, así
como su satisfacción.
 resultados de actividades de benchmarking de proceso y de producto.
 eficacia medida de las actividades de proceso.
 eficacia medida de los entornos de trabajo del proyecto.
 ejemplos de mejoras que fueron adoptadas con éxito en otro lugar.
 realimentación sobre mejoras previas.
 Ideas sugeridas por los gerentes y por el personal.
 propuestas de mejora de los procesos de análisis causal y resolución
que resultan de las acciones implementadas que han demostrado su
eficacia.
 análisis de medidas de rendimiento técnico.
 análisis de datos sobre las causas de los defectos.
 análisis de rendimiento del proyecto y de la organización comparado
con los objetivos de calidad y de productividad.
PARA más INFORMACIÓN sobre cómo DESPLEGAR los ACTIVOS de proceso de LA OR-
GANIZACIÓN e INCORPORAR EXPERIENCIAS, consúltese el árEA de proceso Enfoque
en Procesos de LA OrGANIZACIÓN.
2. Identificar las sugerencias de mejora como incrementales o

innovadoras.
3. Investigar mejoras innovadoras que pueden mejorar los
procesos y las tecnologías de la organización.
Investigar mejoras innovadoras normalmente implica:

 estar al corriente del trabajo técnico relevante y de las tendencias en la
tecnología.
 Buscar mejoras innovadoras disponibles en el mercado.
 recopilar propuestas de mejoras innovadoras de los proyectos y de la
organización.
 revisar los procesos y las tecnologías utilizadas externamente
y compararlos con los procesos y tecnologías usadas en la
organización.
 Identificar las áreas donde se han utilizado con éxito las mejoras
innovadoras y revisar los datos y la documentación sobre la
experiencia en la utilización de estas mejoras.
 Identificar las mejoras que integren nuevas tecnologías en los
productos y en los entornos de trabajo del proyecto.
SP 2.2 analizar las sugerencias de Mejora
Analizar las sugerencias de mejora por su posible impacto en la consecución
de los objetivos de calidad y de rendimiento del proceso de la organización.
Las sugerencias de mejora son mejoras incrementales e

innovadoras que se analizan y, posiblemente, se seleccionan para
su validación, im- plementación y despliegue en toda la
organización.

1. Propuestas de sugerencias de mejora.
2. Mejoras seleccionadas para su validación.
SUBPRÁCTICAS
1. Analizar los costes y los beneficios de las sugerencias de
mejora. Los modelos de rendimiento de proceso proporcionan
información sobre el efecto de los cambios al proceso en la
capacidad y el rendimiento de proceso.
PARA más INFORMACIÓN sobre cómo ESTABLECER los modelos de rendimiento
OPM
del proceso, consúltese el árEA de proceso Rendimiento del Proceso de LA
OrGANIZACIÓN.
Las sugerencias de mejora que tengan una relación coste/beneficio
eleva- da o que no mejoren los procesos de la organización pueden
rechazarse.
algunos criterios para evaluar los costes y los beneficios son:

 Contribución al cumplimiento de los objetivos de calidad y de
rendimiento del proceso de la organización.
 efecto sobre la mitigación de los riesgos identificados en el proyecto y
en la organización.
 Capacidad para responder con rapidez a los cambios en los requisitos
del proyecto, a las situaciones de mercado y al entorno de negocio.
 efecto sobre los procesos relacionados y los activos asociados.
 Coste de la definición y recopilación de datos que dan soporte a la
medición y al análisis de las mejoras de procesos y de tecnología.
 tiempo de vida esperado de la mejora.
2. Identificar las barreras y riesgos potenciales del despliegue de

cada sugerencia de mejora.
algunos ejemplos de barreras al desplegar las mejoras son:

 protección del territorio propio y perspectivas locales.
 Motivaciones confusas o débiles del negocio.
 Falta de beneficios a corto plazo y de éxitos visibles.
Continúa
Continuación
 situación poco clara de qué se espera de cada persona.

 demasiados cambios realizados al mismo tiempo.
 Falta de involucración y de soporte de las partes interesadas relevantes.
algunos ejemplos de factores de riesgo que afectan al despliegue de las

mejoras son:
 Compatibilidad de la mejora con los procesos existentes, con los
valores y con las habilidades de los usuarios finales posibles.
 Complejidad de la mejora.
 dificultad para implementar la mejora.
 Capacidad para demostrar el valor de la mejora antes de realizar su
despliegue.
 Justificación de inversiones grandes y por adelantado en áreas, tales
como herramientas y formación.
 Incapacidad para superar la “resistencia a la tecnología” cuando la
implementación actual se está utilizando con éxito por una base de
usuarios finales amplia y madura.
3. Estimar el coste, el esfuerzo y el calendario requerido para

implementar, verificar y desplegar cada sugerencia de
mejora.
4. Seleccionar las sugerencias de mejora para su validación y su
posible implementación y despliegue en base a las
evaluaciones.
PARA más INFORMACIÓN sobre cómo ANALIZAR posibles decisiones UTILIZANDO
un proceso de EVALUACIÓN FORMAL que EVALÚE LAS ALTERNATIVAS IDENTIFICADAS
frente A los criterios ESTABLECIDOS, consúltese el árEA de proceso Análisis de
5. Documentar los resultados de la evaluación de cada
sugerencia de mejora seleccionada en una propuesta de
mejora.
La propuesta debería incluir una descripción del problema, un plan
(incluyendo el coste y el calendario, el tratamiento de los riesgos,
el méto- do para evaluar la eficacia en el entorno destino) para
implementar la mejora, y los criterios de éxito cuantitativos para la
evaluación de los resultados reales del despliegue.
6. Determinar el detalle de los cambios necesarios para
implementar la mejora y documentarlos en la propuesta de
mejora.
7. Determinar el método de validación que se utilizará antes del
despliegue a gran escala del cambio y documentarlo en la
propuesta de mejora.
• Determinar el método de validación incluye definir los criterios
de éxito cuantitativos que se utilizarán para evaluar los
resultados de la evaluación.
• La mayoría de las mejoras innovadoras serán pilotadas dado que las
innovaciones, por definición, representan un cambio importante de
alto impacto. Se pueden usar otros métodos de validación,
incluyendo el modelado y la simulación, según proceda.
8. Documentar los resultados del proceso de selección.
Los resultados del proceso de selección normalmente incluyen:

 La disposición de cada sugerencia de mejora.
 La razón fundamental de la disposición de cada sugerencia
de mejora.
SP 2.3 validar las Mejoras

Validar las mejoras seleccionadas.
Las mejoras seleccionadas se validan conforme a sus propuestas

de mejora.
algunos ejemplos de métodos de validación son:
OPM
 debates con las partes interesadas, por ejemplo en el contexto de una
revisión formal.
 demostraciones de prototipos.
 pilotos de sugerencias de mejora.
 Modelado y simulación.
Los pilotos se pueden llevar a cabo para evaluar los cambios

significativos que implican mejoras no probadas, de alto riesgo
o innovadoras antes de que se desplieguen ampliamente. No
todas las mejoras necesitan el rigor de un piloto. Se definen y se
utilizan los criterios para seleccionar las mejoras para realizar los
pilotos. Factores tales como el riesgo, la naturaleza de
transformación del cambio, o el núme- ro de áreas funcionales
afectadas, determinarán la necesidad de llevar a cabo un piloto de
la mejora.
La documentación del proceso en borrador o previa puede
ponerse a disposición de los pilotos.

1. Planes de validación.
2. Informes de evaluación de la validación.
3. Lecciones aprendidas documentadas de la validación.
SUBPRÁCTICAS
1. Planificar la validación.
Cuando se planifica la validación, pueden ser útiles los criterios de
éxito cuantitativos documentados en la propuesta de mejora.
Los planes de validación para las mejoras seleccionadas que se van
a pilotar deberían incluir los proyectos objetivo, las
características de cada proyecto, un calendario para informar de los
resultados y las actividades de medición.
2. Revisar y conseguir el acuerdo sobre los planes de validación
con las partes interesadas relevantes.
3. Consultar y ayudar a los que realizan la validación.
4. Crear una implementación de prueba para las mejoras
seleccionadas a pilotar conforme al plan de validación.
5. Realizar cada validación en un entorno que sea similar al
entorno en el que se realizará el despliegue global.
6. Seguir la validación frente a los planes de validación.
7. Revisar y documentar los resultados de la validación.
Los resultados de validación se evalúan utilizando los criterios
cuantitativos definidos en la propuesta de mejora.
revisar y documentar los resultados de los pilotos normalmente implica

las siguientes actividades:
 revisar los resultados del piloto con las partes interesadas.
 decidir si finalizar el piloto, implementar de nuevo la mejora,
replanificar y continuar con el piloto, o proceder con el despliegue.
 actualizar la disposición de las propuestas de mejora asociadas con el
piloto.
 Identificar y documentar las nuevas propuestas de mejora según
proceda.
 Identificar y documentar las lecciones aprendidas y los problemas
encontrados durante el piloto, incluyendo la realimentación al equipo
de mejora y los cambios a la mejora.
SP 2.4 seleccionar e iMpleMentar las Mejoras para el despliegue

Seleccionar e implementar las mejoras para el despliegue en la organización
en base a una evaluación de costes, beneficios y otros factores.
La selección de las sugerencias de mejora para su despliegue está

basada en la relación coste/beneficio respecto a los objetivos de
calidad y de rendimiento de proceso, los recursos disponibles, y
los resultados de la evaluación de la propuesta de mejora y de las
actividades de validación.
PARA más INFORMACIÓN sobre cómo ANALIZAR posibles decisiones USANDO un proceso
de EVALUACIÓN FORMAL que EVALÚE LAS ALTERNATIVAS IDENTIFICADAS frente A los criterios
ESTABLECIDOS, consúltese el árEA de proceso Análisis de Decisiones y Resolución.

1. Mejoras seleccionadas para el despliegue.
2. Documentación y formación de proceso actualizados.
SUBPRÁCTICAS
1. Priorizar las mejoras para su despliegue.
La prioridad de una mejora está basada en una evaluación de su
rela- ción coste/beneficio estimado respecto a la comparación de
los objetivos de calidad y de rendimiento del proceso con las
líneas base de rendimiento. El retorno de inversión se puede usar
como una base de comparación.
2. Seleccionar las mejoras a desplegar.
La selección de mejoras a desplegar se basa en las prioridades, los
recursos disponibles, y los resultados de las actividades de
evaluación y validación de la propuesta de mejora.
3. Determinar cómo desplegar cada mejora.
algunos ejemplos donde se pueden desplegar las mejoras son:

 entornos de trabajo de uso común o específicos del proyecto.
 Familias de productos.
 proyectos de la organización.
OPM
 grupos de la organización.
4. Documentar los resultados del proceso de selección.
Los resultados del proceso de selección normalmente son:

 Los criterios de selección para las sugerencias de mejora.
 Las características de los proyectos objetivo.
 La disposición de cada propuesta de mejora.
 La razón fundamental para la disposición de cada propuesta de mejora.
5. Revisar cualquier cambio que sea necesario para implementar

las mejoras.
algunos ejemplos de cambios que son necesarios para desplegar una

mejora son:
 descripciones de proceso, estándares y procedimientos.
 entornos de trabajo.
 educación y formación.
 Habilidades.
 Compromisos existentes.
 actividades existentes.
 soporte continuo a los usuarios finales.
 Cultura y características de la organización.
6. Actualizar los activos de proceso de la organización.
La actualización de los activos de proceso de la organización

normalmente incluye su revisión, su aprobación y su difusión.
PARA más INFORMACIÓN sobre cómo ESTABLECER los ACTIVOS de proceso de LA

orGANIZACIÓN, consúltese el árEA de proceso Definición de los Procesos de LA
OrGANIZACIÓN.
SG 3 d eSPleGar laS mejoraS

Las mejoras medibles a los procesos y a las tecnologías de la organización
se despliegan y se evalúan utilizando técnicas estadísticas y otras técnicas
cuantitativas.
Una vez que se han seleccionado las mejoras para el despliegue, se

crea y se ejecuta un plan de despliegue. Se gestiona el despliegue
de mejoras y se miden y se evalúan los efectos de las mejoras
para determinar hasta qué punto contribuyen a satisfacer los
objetivos de calidad y de rendimiento del proceso.
SP 3.1 planificar el despliegue

Establecer y mantener los planes para desplegar las mejoras seleccionadas.
Los planes para desplegar las mejoras seleccionadas se pueden in-

cluir en el plan para la gestión del rendimiento de la organización,
en propuestas de mejora, o en documentos separados de
despliegue. Esta práctica específica complementa la práctica
específica Des- plegar los activos de proceso de la organización,
del área de proceso Enfoque en Procesos de la Organización e
incorpora el uso de datos cuantitativos para guiar el despliegue y
para determinar el valor de las
mejoras.
PARA más INFORMACIÓN sobre cómo DESPLEGAR los ACTIVOS de proceso de LA ORGANIZA-
ción e INCORPORAR EXPERIENCIAS, consúltese el árEA de proceso Enfoque en Procesos

1. Planes de despliegue para las mejoras seleccionadas.
SUBPRÁCTICAS
1. Determinar cómo se debería ajustar cada mejora para su
despliegue. Las mejoras identificadas en un contexto limitado
(p.ej., para una propuesta de mejora sencilla) podrían necesitar
modificarse para una parte seleccionada de la organización.
2. Identificar las estrategias que abordan las barreras potenciales
para desplegar cada mejora que fueron definidas en las
propuestas de mejora.
3. Identificar la población de proyectos objetivo para el
No todos los proyectos son buenos candidatos para todas las mejoras.
Por ejemplo, las mejoras pueden estar dirigidas sólo a proyectos
software, a proyectos de integración COTS, o proyectos de
operaciones y de soporte.
4. Establecer las medidas y los objetivos para determinar el valor
de cada mejora con respecto a los objetivos de calidad y de
rendimien- to del proceso de la organización.
Las medidas pueden estar basadas en criterios de éxito
cuantitativos documentados en la propuesta de mejora o derivadas
de los objetivos de la organización.
algunos ejemplos de medidas para determinar el valor de una mejora

son:
 Mejora medida del rendimiento de proceso o de proyectos de la
organización.
OPM
 tiempo para recuperar el coste de la mejora.
 número y tipos de riesgos mitigados por la mejora del proceso o de la
tecnología, tanto a nivel del proyecto como de la organización.
 tiempo medio requerido para dar respuesta a los cambios en los
requisitos del proyecto, en situaciones de mercado y en el entorno de
negocio.
PARA más INFORMACIÓN sobre cómo ALINEAR LAS ACTIVIDADES de medición y

ANÁLISIS, y proporCIONAR rESULTADOS de medición, consúltese el árEA de proce-
so Medición y Análisis.
5. Documentar los planes para desplegar las mejoras

seleccionadas. Los planes de despliegue deberían incluir las
partes interesadas relevantes, las estrategias de riesgos, los
proyectos objetivo, las medidas de éxito, y el calendario.
6. Revisar y conseguir el acuerdo con las partes interesadas
relevantes sobre los planes para desplegar las mejoras
seleccionadas.
Las partes interesadas relevantes incluyen al patrocinador de la
mejora, los proyectos objetivo, las organizaciones de soporte, etc.
7. Modificar los planes para desplegar las mejoras seleccionadas,
se- gún sea necesario.
SP 3.2 gestionar el despliegue

Gestionar el despliegue de las mejoras seleccionadas.
Esta práctica específica se puede solapar con la práctica

específica Implementar las propuestas de acción en el área de
proceso Análisis
Causal y Resolución (p. ej., cuando el análisis causal y resolución
es utilizado en toda la organización o en múltiples proyectos).

1. Materiales de formación actualizados (para reflejar las
mejoras desplegadas).
2. Resultados documentados de las actividades de despliegue de
mejoras.
3. Medidas de mejoras, objetivos, prioridades y planes de
despliegue modificados.
SUBPRÁCTICAS
1. Monitorizar el despliegue de las mejoras utilizando los planes
de despliegue.
2. Coordinar el despliegue de las mejoras en la organización.
La coordinación del despliegue incluye las siguientes actividades:

 Coordinar las actividades de los proyectos, de los grupos de soporte, y
de los grupos de la organización para cada mejora.
 Coordinar las actividades para el despliegue de mejoras relacionadas.
3. Desplegar las mejoras de manera controlada y disciplinada.
algunos ejemplos de métodos para desplegar mejoras son:

 desplegar mejoras incrementalmente, en lugar de en un único
despliegue.
 proporcionar consultoría completa a los primeros que adoptan la
mejora, en vez de una formación formal modificada.
4. Coordinar el despliegue de las mejoras en los procesos

definidos del proyecto, según proceda.
PARA más INFORMACIÓN sobre cómo DESPLEGAR los ACTIVOS de proceso de LA OR-
GANIZACIÓN e INCORPORAR EXPERIENCIAS, consúltese el árEA de proceso Enfoque
en Procesos de LA OrGANIZACIÓN.
5. Proporcionar consultoría, según proceda, para dar soporte al
despliegue de las mejoras.
6. Proporcionar materiales de formación actualizados o
desarrollar paquetes de comunicación para reflejar las mejoras
a los activos de proceso de la organización.
PARA más INFORMACIÓN sobre cómo proporCIONAR FORMACIÓN, consúltese el
árEA de proceso FORMACIÓN en LA OrGANIZACIÓN.
7. Confirmar que el despliegue de todas las mejoras se ha
completado de acuerdo al plan de despliegue.
8. Documentar y revisar los resultados del despliegue de la mejora.
La documentación y la revisión de resultados incluye:

 Identificar y documentar las lecciones aprendidas.
 Modificar las medidas, los objetivos, las prioridades, y los planes de
SP 3.3 evaluar los efectos de la Mejora

Evaluar los efectos de las mejoras desplegadas sobre la calidad y el rendimien-
to de proceso utilizando técnicas estadísticas y otras técnicas cuantitativas.
PARA más INFORMACIÓN sobre cómo ALINEAR LAS ACTIVIDADES de medición y ANÁLISIS
Análisis.
Esta práctica específica se puede solapar con la práctica específica
OPM
Eva- luar el efecto de las acciones implementadas en el área de
proceso Aná- lisis Causal y Resolución (p. ej., cuando el análisis
causal y resolución se aplica a nivel de organización o en
múltiples proyectos).

1. Medidas documentadas de los efectos resultantes de las
mejoras desplegadas.
SUBPRÁCTICAS
1. Medir los resultados de cada mejora una vez implementadas en
los proyectos objetivo, utilizando las medidas definidas en los
planes de despliegue.
2. Medir y analizar el progreso hacia la consecución de los
objetivos de calidad y de rendimiento de proceso de la
organización, utilizando técnicas estadísticas y otras técnicas
cuantitativas, y tomar las acciones correctivas según sea
necesario.
PARA más INFORMACIÓN sobre cómo ESTABLECER los objetivos de CALIDAD y de
rendimiento de proceso y, ESTABLECER LAS LÍNEAS BASE y los modelos de rendi-
miento del proceso, consúltese el árEA de proceso Rendimiento de Procesos
rendimiento de Procesos de la organización

Propósito
El propósito del Rendimiento de Procesos de la Organización
(OPP) es establecer y mantener una comprensión cuantitativa del
rendimiento de los procesos seleccionados del conjunto de
procesos estándar de la organización para dar soporte a la
consecución de los objetivos de calidad y de rendimiento de
proceso, y para proporcionar datos, líneas base y modelos de
rendimiento de proceso con los que gestionar cuantitativamente
los proyectos de la organización.
El área de proceso de Rendimiento de Procesos de la
Organización implica las siguientes actividades:
• Establecer los objetivos cuantitativos de calidad y de
rendimiento de proceso de la organización a partir de los
OPP
objetivos de negocio (véase la definición de “objetivos de
calidad y de rendimiento de proceso” en el glosario).
• Seleccionar los procesos o subprocesos para el análisis de
• Establecer definiciones de las medidas a utilizar en el análisis
de rendimiento de proceso (véase la definición de
“rendimiento de proceso” en el glosario).
• Establecer las líneas base de rendimiento de proceso y
modelos de rendimiento de proceso (véase las definiciones de
“líneas base de rendimiento de proceso” y “modelos de
rendimiento de proceso” en el glosario).
La recogida y el análisis de los datos y la creación de las líneas

base y los modelos de rendimiento de proceso se pueden llevar a
cabo a distintos niveles de la organización, incluyendo proyectos
individuales o grupos de proyectos relacionados, según
proceda, en base a las necesidades de los proyectos y de la
organización.
351
Las medidas comunes para la organización constan de medidas
del proceso y del producto que se pueden utilizar para caracterizar
el rendimiento real de los procesos en proyectos individuales de la
organización. Mediante el análisis de las mediciones resultantes, se
puede establecer una distribución o un rango de resultados que
caracterice el rendimien- to esperado del proceso cuando se utiliza
en un proyecto individual.
La medición de la calidad y del rendimiento de proceso puede
implicar la combinación de medidas existentes para obtener
medidas derivadas adicionales para proporcionar una visión más
clara de la eficiencia y eficacia global a nivel de proyecto o a
nivel de la organi- zación. El análisis a nivel de la organización
puede ser utilizado para estudiar la productividad, para mejorar la
eficiencia y para incrementar el rendimiento a través de los
proyectos de la organización.
El rendimiento de proceso esperado se puede utilizar para
establecer los objetivos de calidad y de rendimiento de proceso
del proyecto, y como una línea base frente a la que comparar el
rendimiento real del proyecto. Esta información se utiliza para
gestionar cuantitativamente el proyecto. Cada proyecto
gestionado cuantitativamente, a su vez, proporciona resultados
reales de rendimiento que pasarán a formar parte de los activos
de proceso de la organización que se pondrán a disposición de
todos los proyectos.
Los modelos de rendimiento de proceso se utilizan para
representar el rendimiento pasado y actual del proceso, y para
predecir los resultados futuros del proceso. Por ejemplo, los
defectos latentes en el producto entregado pueden predecirse
utilizando mediciones de atributos de producto de trabajo, tal
como la complejidad, y mediciones de atributos de proceso, tal
como el tiempo de preparación de las revisiones entre pares.
Cuando la organización tiene suficientes medidas, datos y
técnicas analíticas relativas a las características críticas del
proceso, del produc- to y del servicio, es capaz de hacer lo
siguiente:
• Determinar si los procesos se comportan consistentemente o
tienen tendencias estables (es decir, si son predecibles).
• Identificar los procesos en los que el rendimiento está dentro
de los límites naturales que son consistentes a través de los
proyectos y que potencialmente podrían agregarse.
• Identificar los procesos que muestran un comportamiento
inusual (p.ej., esporádico, impredecible).
• Identificar aspectos de los procesos que puedan mejorarse en
el conjunto de procesos estándar de la organización.
• Identificar la implementación del proceso que funciona mejor.
Este área de proceso se interrelaciona y da soporte a la

implementa- ción de otras áreas de proceso de alta madurez. Los
activos establecidos y mantenidos como parte de la
implementación de este área de proceso
Rendimiento de procesos de la organización 353
(p. ej., las medidas a utilizar para caracterizar el comportamiento
del subproceso, las líneas base de rendimiento de proceso y los
modelos de rendimiento de proceso) son entradas a los procesos de
gestión cuantitativa del proyecto, análisis causal y resolución, y
gestión del rendimien- to de la organización para dar soporte a los
análisis descritos en dichas áreas de proceso. Los procesos de
gestión cuantitativa del proyecto proporcionan los datos de
calidad y de rendimiento de proceso necesarios para mantener los
activos descritos en este área de proceso.

PARA más INFORMACIÓN sobre cómo ESPECIFICAR MEDIDAS, obtener DATOS de medición
y ANALIZAR DATOS de medición, consúltese el árEA de proceso Medición y Análisis.
PARA más INFORMACIÓN sobre cómo GESTIONAR prOACTIVAMENTE el rendimiento de LA
orGANIZACIÓN PARA cumplir sus objetivos de negocio, consúltese el árEA de proceso
Gestión del Rendimiento de LA OrGANIZACIÓN.
LOGRAR los objetivos de CALIDAD y de rendimiento de proceso ESTABLECIDOS en el pro-
yecto, consúltese el árEA de proceso Gestión CUANTITATIVA del Proyecto.

sg 1 establecer las líneas base y los modelos de rendimiento.
sp 1.1 establecer los objetivos de calidad y de rendimiento de proceso.
sp 1.2 seleccionar los proceso.
sp 1.3 establecer las medidas de rendimiento de proceso.
sp 1.4 analizar el rendimiento de proceso y establecer las líneas base de rendimiento de
OPP
proceso.
sp 1.5 establecer los modelos de rendimiento de proceso.
SG 1 e Stablecer laS líneaS baSe y loS modeloS de rendimiento

Se establecen y se mantienen las líneas base y los modelos que caracterizan
el rendimiento de proceso esperado del conjunto de procesos estándar de la
organización.
Antes de establecer las líneas base y los modelos de

rendimiento de proceso, es necesario determinar los objetivos de
calidad y de rendimiento de proceso para esos procesos (práctica
específica Establecer objetivos de calidad y de rendimiento de
proceso), qué procesos son adecuados para que sean medidos
(práctica específica Seleccionar los procesos), y qué medidas son
útiles para determinar el rendimiento de proceso (práctica
específica Establecer las medidas de rendimiento de proceso).
Las tres primeras prácticas de esta meta están
interrelacionadas y, con frecuencia, necesitan ejecutarse de forma
simultánea e iterativa para seleccionar los objetivos de calidad y
de rendimiento de proceso, los procesos y las medidas. Con
frecuencia, la selección de un objetivo de calidad y de
rendimiento de proceso, proceso o medida limitará la selección
de los demás. Por ejemplo, la selección de un objetivo de calidad
y de rendimiento de proceso relacionado con los defectos
entregados al cliente, es casi seguro, que requerirá la selección de
los procesos de verificación y de medidas relacionadas con los
defectos.
El propósito de esta meta es proporcionar a los proyectos los
modelos y las líneas base de rendimiento de proceso que
necesiten llevar a cabo la su gestión cuantitativa. Muchas veces,
estas líneas base y modelos son recopilados o creados por la
organización, pero hay circunstancias en las que un proyecto
puede necesitar crear sus propias líneas base y sus propios
modelos. Estas circunstancias incluyen proyectos que no están
cubiertos por las líneas base ni por los modelos de la organización.
Para estos casos, el proyecto sigue las prácticas de esta meta para
crear sus líneas base y modelos.
SP 1.1 establecer los objetivos de calidad y de rendiMiento de proceso
Establecer y mantener los objetivos cuantitativos de la organización en cuanto a la
calidad y al rendimiento de proceso, que son trazables con los objetivos de negocio.
Los objetivos de calidad y de rendimiento de proceso de la
organi- zación se pueden establecer a distintos niveles en la
estructura de la organización (p. ej., área de negocio, línea de
producto, función, proyecto), así como en los diferentes niveles
en la jerarquía de los procesos. Cuando se establezcan los
objetivos de calidad y de rendimiento de proceso considere lo
siguiente:
• La trazabilidad a los objetivos de negocio de la organización.
• El rendimiento histórico de los procesos o de los subprocesos
seleccionados en el contexto (p. ej., en proyectos).
• Los múltiples atributos de rendimiento de proceso (p. ej.,
calidad del producto, productividad, tiempo de ciclo, tiempo
de respuesta).
• La variabilidad inherente o los límites naturales de los
procesos o subprocesos seleccionados.
Los objetivos de calidad y de rendimiento de proceso de la
organi- zación proporcionan un enfoque y una orientación a las
actividades de análisis de rendimiento de proceso y de gestión
cuantitativa del proyecto. Sin embargo, cabe señalar que la
proceso que son significativamente diferentes de la capacidad
del proceso actual, requiere el uso de técnicas que se encuentran
en el Análisis Causal y Resolución y en la Gestión del
Rendimiento de la Organización.
1. Objetivos de calidad y de rendimiento de proceso de la organización.
SUBPRÁCTICAS
1. Revisar los objetivos de negocio de la organización
relacionados con la calidad y el rendimiento de proceso.
algunos ejemplos de objetivos de negocio son:

 entregar los productos dentro del presupuesto y en plazo.
 Mejorar la calidad del producto en un porcentaje especificado en un
periodo de tiempo especificado.
 Mejorar la productividad en un porcentaje especificado en un periodo
de tiempo especificado.
 Mantener las tasas de satisfacción del cliente.
 Mejorar el plazo de puesta en el mercado de nuevos productos o
servicios en un porcentaje especificado en un periodo de tiempo
especificado.
 reducir la funcionalidad diferida del producto en un porcentaje
especificado en un periodo de tiempo especificado.
 reducir la tasa de devoluciones de productos en un porcentaje
especificado en un período de tiempo especificado.
 reducir el coste total de propiedad del cliente en un porcentaje
especificado en un periodo de tiempo especificado.
 disminuir el coste de mantenimiento de productos heredados en un
porcentaje especificado en un periodo de tiempo especificado.
OPP
2. Definir los objetivos cuantitativos de calidad y de rendimiento
Los objetivos de calidad y de rendimiento de proceso se pueden
establecer para mediciones del proceso o subproceso (p. ej., esfuerzo,
tiempo del ciclo, eficacia en la eliminación de defectos), así como
para las mediciones del producto (p. ej., fiabilidad, densidad de
defectos) y para las mediciones de servicios (p. ej., capacidad,
tiempos de respuesta) según proceda.
algunos ejemplos de objetivos de calidad y de rendimiento de proceso son:

 Lograr un objetivo especificado de tasa de defectos no eliminados, de
productividad, de duración, de capacidad o de coste.
 Mejorar el rendimiento de la tasa de defectos no eliminados, de la
productividad, de la duración, de la capacidad, o del coste en un
porcentaje especificado de la línea base de rendimiento del proceso en
un periodo de tiempo especificado.
 Mejorar el rendimiento del acuerdo del nivel de servicio en un
porcentaje especificado de la línea base de rendimiento del proceso en
un período de tiempo especificado.
3. Definir las prioridades de los objetivos de calidad y de
rendimiento de proceso de la organización.
4. Revisar, negociar y obtener el compromiso con las partes
interesadas relevantes de los objetivos de calidad y de
rendimiento de proceso de la organización, y sus prioridades.
5. Modificar los objetivos cuantitativos de calidad y de
rendimiento de proceso de la organización según sea necesario.
algunos ejemplos sobre cuándo se deberían modificar los objetivos

cuantitativos de calidad y de rendimiento de proceso de la organización son:
 Cuando cambian los objetivos de negocio de la organización.
 Cuando cambia el conjunto de procesos estándar de la organización.
 Cuando la calidad y el rendimiento de proceso reales difieren
significativamente de los objetivos.
SP 1.2 seleccionar los procesos

Seleccionar los procesos o los subprocesos del conjunto de procesos estándar
de la organización que se incluirán en los análisis de rendimiento de proceso
de la organización y mantener la trazabilidad a los objetivos de negocio.
PArA más informAción sobre cómo estAblecer los Activos de proceso de lA
orgAnizAción, consúltese el áreA de proceso Definición de Procesos de lA
OrgAnizAción.
El conjunto de procesos estándar de la organización consta de un

conjunto de procesos estándar que, a su vez, están compuestos de
subprocesos.
Normalmente, no es ni posible, ni útil ni está justificado
económi- camente aplicar técnicas de gestión estadística a todos
los procesos o subprocesos del conjunto de procesos estándar de
la organización. La selección de los procesos o subprocesos se
basa en los objetivos de calidad y de rendimiento de proceso de
la organización, que se obtienen de los objetivos de negocio,
según se describe en la práctica específica anterior.

1. Lista de procesos o subprocesos identificados para el análisis
de rendimiento de proceso con la razón fundamental de su
selección incluyendo la trazabilidad a los objetivos de
negocio.
SUBPRÁCTICAS
1. Establecer los criterios a utilizar para la selección de los subprocesos.
algunos ejemplos de criterios que se pueden utilizar para la selección de

un proceso o subproceso para el análisis de rendimiento de proceso de la
organización son:
 el proceso o subproceso está fuertemente relacionado con los objetivos
clave de negocio.
 el proceso o subproceso ha demostrado estabilidad en el pasado.
 Los datos históricos válidos que son relevantes para el proceso o
subproceso están actualmente disponibles.
 el proceso o subproceso generará los datos con la frecuencia suficiente
como para permitir la gestión estadística.
 el proceso o subproceso es elemento que contribuye de manera
importante a la calidad y al rendimiento de proceso.
 el proceso o subproceso es un indicador importante de la calidad y del
 el proceso o subproceso es un factor importante para entender los
riesgos asociados con la consecución de los objetivos de calidad y de
 La calidad de las medidas y de las mediciones asociadas con el proceso
o subproceso (p. ej., error del sistema de medición) es adecuada.
 Múltiples atributos medibles que caracterizan el comportamiento del
proceso o subproceso están disponibles.
2. Seleccionar los subprocesos y documentar el análisis razonado

de su selección.
algunos ejemplos de enfoques para identificar y evaluar alternativas de

subprocesos como parte de una selección son:
 análisis causal.
OPP
 análisis de sensibilidad.
PArA más informAción sobre cómo AnAlizAr decisiones posibles utilizAndo un
proceso de evAluAción formAl que evAlúe AlternAtivAS identificAdAS frente A los
criterios estAblecidos, consúltese el áreA de proceso Análisis CAusAl y Resolución.
3. Establecer y mantener la trazabilidad entre los subprocesos
seleccionados, los objetivos de calidad y de rendimiento de
proceso y los objetivos de negocio.
algunos ejemplos de cómo se puede expresar la trazabilidad son:

 Correspondencia de los subprocesos con los objetivos de calidad y de
 Correspondencia de los subprocesos con los objetivos de negocio.
 Objetivo flow-down (p. ej., Big Y a Vital X, planificación Hoshin).
 Cuadro de mando integral.
 despliegue de la función calidad (QFd).
 goal Question Metric (gQM).
 documentación de un modelo de rendimiento de proceso.
4. Modificar la selección según sea necesario.

Puede ser necesario modificar la selección cuando:
• Las predicciones realizadas por los modelos de rendimiento
de procesos tienen demasiada variación para que sean útiles.
• Cambian los objetivos de calidad y de rendimiento de proceso.
• Cambia el conjunto de procesos estándar de la organización.
• Cambia la calidad y rendimiento de procesos subyacentes.
SP 1.3 establecer las Medidas de rendiMiento de proceso

Establecer y mantener definiciones de medidas que se incluirán en los análisis
de rendimiento de proceso de la organización.
PARA más INFORMACIÓN sobre cómo ESPECIFICAR MEDIDAS, consúltese el árEA de pro-
ceso Medición y Análisis.

1. Definiciones de medidas de rendimiento de proceso
seleccionadas con el análisis razonado para su selección
incluyendo la trazabilidad a los procesos o subprocesos
seleccionados.
SUBPRÁCTICAS
1. Seleccionar las medidas que reflejen atributos apropiados de
los procesos o subprocesos seleccionados para proporcionar
una visión sobre la calidad y el rendimiento de proceso de la
organización.
A menudo es útil definir múltiples medidas de un proceso o
subproceso para comprender el impacto de los cambios en el
proceso y evitar la sub-optimización. Además, a menudo es útil
establecer medidas tanto para los atributos de proceso como del
producto para los procesos y los subprocesos seleccionados, así
como para sus entradas, salidas y recursos consumidos
(incluyendo el personal y sus habilidades).
El paradigma Goal Question Metric (GQM) es una aproximación
que se puede utilizar para seleccionar medidas que proporcionen
visión en los objetivos de calidad y de rendimiento de proceso de
la orga- nización. A menudo es útil analizar cómo estos objetivos
de calidad y de rendimiento de proceso se pueden lograr a través
de la com- prensión del rendimiento de proceso proporcionado por
las medidas seleccionadas.
algunos ejemplos de criterios utilizados para seleccionar las medidas son:

 relación de las medidas con los objetivos de calidad y de rendimiento
 Cobertura que proporcionan las medidas a lo largo de la vida del
producto o servicio.
 Visibilidad que proporcionan las medidas de rendimiento de proceso.
Continúa
Continuación
 disponibilidad de las medidas.

 Frecuencia con la que pueden recogerse las observaciones de las
medidas.
 grado en el que las medidas son controlables por cambios al proceso o
subproceso.
 grado en el que las medidas representan la visión de los usuarios
finales del rendimiento eficaz del proceso.
2. Establecer definiciones operativas para las medidas seleccionadas.

PARA más INFORMACIÓN sobre cómo ESPECIFICAR MEDIDAS, consúltese el árEA de
proceso Medición y Análisis.
3. Incorporar las medidas seleccionadas en el conjunto de
medidas comunes de la organización.
PARA más INFORMACIÓN sobre cómo ESTABLECER los ACTIVOS de proceso de LA
orGANIZACIÓN, consúltese el árEA de proceso Definición de Procesos de LA
OrGANIZACIÓN.
4. Modificar el conjunto de medidas según sea necesario.
Las medidas se evalúan periódicamente en cuanto a su utilidad
continua y capacidad para indicar la eficacia del proceso.
SP 1.4 a nalizar el rendiMiento de proceso y establecer las líneas base de rendiMiento

de proceso
Analizar el rendimiento de los procesos seleccionados y establecer y mantener

las líneas base de rendimiento de proceso.
OPP
Las medidas seleccionadas se analizan para caracterizar el
rendimiento de los procesos o subprocesos seleccionados alcanzado
en los proyectos. Esta caracterización se utiliza para establecer y
mantener las líneas base de rendimiento de proceso (véase la
definición de “línea base de rendimiento de proceso” en el glosario).
Estas líneas base se usan para determinar los resultados esperados
del proceso o subproceso cuando se utilizan en un proyecto bajo
un conjunto dado de circunstancias.
Las líneas base de rendimiento de proceso se comparan con
los objetivos de calidad y de rendimiento de proceso de la
organización para determinar si se están consiguiendo los
Las líneas base de rendimiento de proceso son una medición
de rendimiento para el conjunto de procesos estándar de la
organización a varios niveles de detalle. Los procesos que pueden
abordar las líneas base de rendimiento de proceso son:
• Secuencia de procesos conectados.
• Procesos que cubren la vida completa del proyecto.
• Procesos para desarrollar productos de trabajo individuales.
Puede haber varias líneas base de rendimiento de proceso para
caracterizar el rendimiento de subgrupos de la organización.
algunos ejemplos de criterios utilizados para categorizar los subgrupos son:

 Línea de producto.
 Línea de negocio.
 dominio de la aplicación.
 Complejidad.
 tamaño del equipo.
 tamaño del producto de trabajo.
 elementos de proceso del conjunto de procesos estándar de la
organización.
La adaptación del conjunto de procesos estándar de la

organización puede afectar significativamente a la capacidad de
comparar datos para su incorporación en las líneas base de
rendimiento de proceso. Se de- berían considerar los efectos de la
adaptación en el establecimiento de las líneas base. Dependiendo
de la adaptación permitida, pueden existir líneas base de
rendimiento diferentes para cada tipo de adaptación.
PArA más informAción sobre cómo gestionAr cuAntitAtivAmente el proyecto
pArA logrAr los objetivos estAblecidos de cAlidAd y de rendimiento de proceso
del proyecto, consúltese el áreA de proceso Gestión CuAntitAtivA del Proyecto.

1. Análisis de datos de rendimiento de proceso.
2. Datos de la línea base de rendimiento de proceso de la organización.
SUBPRÁCTICAS
1. Recopilar las mediciones seleccionadas de los procesos y
subprocesos seleccionados.
Se registra el proceso o subproceso en uso cuando fue tomada la
medi- ción para permitir su utilización posterior.
PARA más INFORMACIÓN sobre cómo ESPECIFICAR procedimientos de rECOGIDA
de DATOS de medición y de ALMACENAMIENTO, consúltese el árEA de proceso
Medición y Análisis.
2. Analizar las medidas recogidas cuando se usan en un
proyecto, para establecer una distribución o un rango de
resultados que caracterizan el rendimiento esperado de los
Este análisis debería incluir la estabilidad del proceso o
subproceso relacionado y los impactos de los factores y el
contexto asociados. Los factores relacionados incluyen entradas al
proceso y a otros atributos que pueden afectar a los resultados
obtenidos. El contexto incluye el contexto de negocio (p. ej., el
dominio) y la adaptación significativa del conjunto de procesos
Se deberían utilizar, siempre que sea posible, mediciones de
subprocesos estables en los proyectos; otros datos pueden no ser
fiables.
3. Establecer y mantener las líneas base de rendimiento de
proceso a partir de las mediciones recogidas y el análisis.
ANÁLISIS y proporCIONAR rESULTADOS de medición, consúltese el árEA de proceso
Las líneas base de rendimiento se obtienen del análisis de las
medidas recogidas cuando se utilizan en un proyecto en la
organización, para establecer una distribución o rango de
resultados que caractericen el rendimiento esperado de los
4. Revisar y obtener el acuerdo con las partes interesadas
relevantes sobre las líneas base de rendimiento de proceso.
5. Poner a disposición de toda la organización la información de
rendimiento de proceso en el repositorio de mediciones de la
organización.
Las líneas base de rendimiento de proceso de la organización se
utilizan por los proyectos para estimar los límites naturales de
6. Comparar las líneas base de rendimiento de proceso con sus
objetivos asociados de calidad y de rendimiento de proceso
para determinar si se están alcanzando dichos objetivos.
Para estas comparaciones se deberían utilizar técnicas estadísticas,
más allá que una simple comparación de la media para determinar
el grado de satisfacción del objetivo de calidad y de rendimiento
de proceso. Si los objetivos de calidad y de rendimiento de proceso
OPP
no se están alcanzando, se debería considerar tomar acciones
correctivas.
PARA más INFORMACIÓN sobre cómo DETERMINAR LAS CAUSAS de los rESULTADOS
SELECCIONADOS, consúltese el árEA de proceso Análisis CAUSAL y Resolución.
PARA más INFORMACIÓN sobre cómo PLANIFICAR e IMPLEMENTAR ACCIONES de pro-

ceso, consúltese el árEA de proceso Enfoque en Procesos de LA OrGANIZACIÓN.
PARA más INFORMACIÓN sobre cómo ANALIZAR los DATOS de rendimiento de pro-
ceso e IDENTIFICAR árEAS POTENCIALES de MEJORA, consúltese el árEA de proceso
de Gestión del Rendimiento de LA OrGANIZACIÓN.
7. Modificar las líneas base de rendimiento de proceso según sea
necesario.
algunos ejemplos sobre cuándo puede ser necesario modificar las líneas
base de rendimiento de proceso de la organización son:
 Cuando cambian los procesos.
 Cuando cambian los resultados de la organización.
 Cuando cambian las necesidades de la organización.
 Cuando cambian los procesos de los proveedores.
 Cuando cambian los proveedores.
SP 1.5 e Stablecer loS modeloS de rendimiento de ProceSo
Establecer y mantener los modelos de rendimiento de proceso para el conjun-
to de procesos estándar de la organización.
Las organizaciones de alta madurez generalmente establecen y

mantienen un conjunto de modelos de rendimiento de proceso
en varios niveles de detalle que cubren un rango de actividades
que son comunes en toda la organización y se dirigen a los
organización (véase la definición de “modelo de rendimiento de
proceso” en el glosario). Bajo determinadas circunstancias
puede ser necesario que los proyectos creen sus propios modelos
de rendimiento de proceso.
Los modelos de rendimiento de proceso se usan para estimar
o predecir el valor de una medida de rendimiento de proceso a
partir de los valores de otras mediciones de proceso, de producto
y de servicio. Estos modelos de rendimiento de proceso
normalmente utilizan mediciones de proceso y de producto
recogidas durante la vida del proyec- to, para estimar el progreso
hacia la consecución de los objetivos de calidad y de rendimiento
de proceso que no pueden medirse hasta más adelante en la vida
del proyecto.
Los modelos de rendimiento de proceso se utilizan del siguiente modo:
• La organización los utiliza para estimar, analizar y
predecir el rendimiento de proceso asociado con los procesos
y con los cambios al conjunto de procesos estándar de la
organización.
• La organización los utiliza para evaluar el retorno (potencial)
de la inversión de las actividades de mejora de proceso.
• Los proyectos los utilizan para estimar, analizar y predecir el
rendimiento de proceso de sus procesos definidos.
• Los proyectos los utilizan para seleccionar procesos o
subprocesos a usar.
• Los proyectos los utilizan para estimar el progreso sobre la
proceso del proyecto.
Estas medidas y modelos se definen para proporcionar visión
y para proporcionar la capacidad para predecir características de
proceso y del producto críticas que son relevantes para los
organización.
algunos ejemplos de modelos de rendimiento de proceso son:

 Modelos dinámicos de sistema.
 Modelos de regresión.
 Modelos de complejidad.
 Modelos de simulación de eventos discretos.
 Modelos de simulación Monte Carlo.
ALCANZAR los objetivos de CALIDAD y de rendimiento de proceso ESTABLECIDOS del
proyecto, consúltese el árEA de proceso Gestión CUANTITATIVA del Proyecto.

1. Modelos de rendimiento de proceso.
SUBPRÁCTICAS
1. Establecer los modelos de rendimiento de proceso en base al
conjunto de procesos estándar de la organización y a las
líneas base de rendimiento de proceso de la organización.
2. Calibrar los modelos de rendimiento de proceso en base a los
resultados pasados y a las necesidades actuales.
3. Revisar los modelos de rendimiento de proceso y obtener el
acuerdo con las partes interesadas relevantes.
4. Dar soporte en la utilización de los modelos de rendimiento de
proceso a los proyectos.
5. Modificar los modelos de rendimiento de proceso según sea
necesario.
algunos ejemplos sobre cuándo puede ser necesario modificar los

modelos de rendimiento de proceso son:
 Cuando cambian los procesos.
 Cuando cambian los resultados de la organización.
 Cuando cambian los objetivos de calidad y de rendimiento de proceso
OPP
Formación en la organización
Propósito
El propósito de la Formación en la Organización (OT) es
desarrollar las habilidades y los conocimientos de las personas
para que puedan desempeñar sus roles eficaz y eficientemente.
La Formación de la organización trata la formación
proporcionada para dar soporte a los objetivos estratégicos del
negocio de la organi- zación y para cumplir las necesidades
tácticas de formación que son comunes a los proyectos y grupos
de soporte. Las necesidades de for- mación para cumplir las
necesidades especificas, identificadas por los proyectos
individuales y grupos de soporte, se tratan a nivel de proyec- to y
de grupo de soporte, y están fuera del alcance del área de proceso
Formación de la Organización.
PARA más INFORMACIÓN sobre cómo PLANIFICAR los conocimientos y HABILIDADES ne-
CESARIOS, consúltese el árEA de proceso PLANIFICACIÓN del Proyecto.
El programa de formación de la organización implica las
siguientes actividades:
• Identificar las necesidades de formación de la organización.

• Obtener y proporcionar formación para tratar esas necesidades.
• Establecer y mantener la capacidad de formación.
OT
• Establecer y mantener registros de formación.
• Evaluar la eficacia de la formación.
La formación eficaz requiere la evaluación de las

necesidades, la planificación, el diseño educativo y los medios de
formación adecuados (p. ej., libros de trabajo, software), así
como un repositorio de datos del proceso de formación. Como
cualquier proceso de la orga- nización, los componentes
principales de la formación incluyen un programa gestionado de
desarrollo de la formación, planes documentados, personal con
un dominio apropiado de las disciplinas y de otras
365
áreas de conocimiento, y mecanismos para medir la eficacia del
programa de formación.
La identificación de las necesidades de formación de
procesos se basa principalmente en las habilidades requeridas
para llevar a cabo el conjunto de procesos estándar de la
organización.
PARA más INFORMACIÓN sobre cómo ESTABLECER procesos ESTÁNDAR, consúltese el árEA
de proceso Definición de Procesos de LA OrGANIZACIÓN.
Ciertas habilidades se pueden impartir con eficacia y eficiencia
a través de otros medios distintos a las experiencias de formación
en aula (p.ej., tutoría informal). Otras habilidades requieren medios
de forma- ción más formalizados, como en un aula, formación
basada en web, a través de auto-estudio guiado, o mediante un
programa formalizado de formación en el trabajo. Los medios de
formación formales o informales empleados para cada situación
deberían basarse en una evaluación de la necesidad de formación y
en las carencias de desempeño a tratar. El término “formación”
usado durante este área de proceso se utiliza ampliamente para
incluir todas estas opciones de aprendizaje.
El éxito de la formación se demuestra por la disponibilidad de
oportunidades para adquirir las habilidades y los conocimientos
necesarios para realizar actividades nuevas y en curso de la
empresa.
Las habilidades y el conocimiento pueden ser técnicos, de la
orga- nización o de contexto. Las habilidades técnicas se refieren
a la capacidad de utilizar equipos, herramientas, materiales,
datos y procesos requeridos por un proyecto o proceso. Las
habilidades de la organiza- ción están relacionadas con el
comportamiento interno y de acuerdo con la estructura de la
organización de los miembros del personal, con los roles y
responsabilidades, y con los principios y los métodos generales
de funcionamiento. Las habilidades de contexto son la auto-
gestión, la comunicación y las habilidades interpersonales
necesarias para realizar con éxito el trabajo en el contexto de la
organización y social del proyecto y de los grupos de soporte.
Áreas de procesos relacionadas

PARA más INFORMACIÓN sobre cómo ANALIZAR LAS posibles decisiones USANDO un pro-
ceso de EVALUACIÓN FORMAL que EVALÚE ALTERNATIVAS IDENTIFICADAS frente A criterios

sg 1 establecer una capacidad de formación de la organización.
sp 1.1 establecer las necesidades estratégicas de formación.
sp 1.2 determinar qué necesidades de formación son responsabilidad de la organización.
Formación de la organización 367
sp 1.3 establecer un plan táctico de formación en la organización.
sp 1.4 establecer una capacidad de formación.
sg 2 proporcionar formación.
sp 2.1 Impartir la formación.
sp 2.2 establecer los registros de formación.
sp 2.3 evaluar la eficacia de la formación.

SG 1 e Stablecer una caPacidad de formación de la orGanización
Se establece y se mantiene una capacidad de formación, que de soporte a los
roles en la organización.
La organización identifica la formación requerida para

desarrollar las habilidades y el conocimiento necesarios para
realizar las actividades de la empresa. Una vez que se identifican
las necesidades, se desarrolla un programa de formación que las
trate.
SP 1.1 establecer las necesidades estratégicas de forMación
Establecer y mantener las necesidades estratégicas de formación de la
organización.
Las necesidades estratégicas de formación tratan los objetivos a

largo plazo para construir una capacidad cubriendo las carencias
significativas de conocimiento, introduciendo nuevas
tecnologías o implementando cambios importantes en el
OT
comportamiento. La planificación estratégica se considera,
normalmente, de dos a cinco años vista.
algunos ejemplos de fuentes de necesidades estratégicas de formación son:

 Los procesos estándar de la organización.
 el plan estratégico de negocios de la organización.
 el plan de mejora de procesos de la organización.
 Iniciativas a nivel de empresa.
 evaluaciones de las habilidades.
 análisis de riesgos.
 gestión de adquisiciones y de proveedores.
1. Necesidades de formación.
2. Análisis de evaluación.
SUBPRÁCTICAS
1. Analizar los objetivos estratégicos del negocio de la
organización y el plan de mejora de proceso para identificar las
necesidades potenciales de formación.
2. Documentar las necesidades estratégicas de formación de la
organización.
algunos ejemplos de categorías de necesidades de formación son:

 análisis y documentación del proceso.
 Ingeniería (p. ej., análisis de requisitos, diseño, pruebas, gestión de
configuración, aseguramiento de la calidad).
 selección y gestión de proveedores.
 Creación de equipo.
 gestión (p. ej., estimación, seguimiento, gestión de riesgos).
 Liderazgo.
 recuperación de desastres y continuidad de las operaciones.
 Habilidades de comunicación y de negociación.
3. Determinar los roles y las habilidades necesarias para realizar

el conjunto de procesos estándar de la organización.
4. Documentar la formación necesaria para desempeñar los roles
en el conjunto de procesos estándar de la organización.
5. Documentar las necesidades de formación para mantener la
seguridad, la protección y el funcionamiento continuado del
negocio.
6. Modificar las necesidades estratégicas y la formación
requerida de la organización según sea necesario.
SP 1.2 deterMinar qué necesidades de forMación son responsabilidad de la organización

Determinar qué necesidades de formación son responsabilidad de la organi-
zación y cuáles son responsabilidad de los proyectos individuales o grupos de
soporte.
Además de las necesidades estratégicas de formación, la

formación de la organización trata los requisitos de formación
que son comunes a todos los proyectos y grupos de soporte. Los
proyectos y grupos de soporte tienen la responsabilidad principal
de identificar y tratar sus necesidades de formación. El personal
de formación de la orga- nización es responsable de tratar sólo
las necesidades de formación comunes de todos los proyectos y
grupos de soporte (p. ej., forma- ción en los entornos de trabajo
comunes a múltiples proyectos). En algunos casos, sin embargo,
el personal de formación de la organiza- ción puede tratar
necesidades de formación adicionales de proyectos y grupos de
soporte, según se negocie con ellos, en el contexto de los recursos
de formación disponibles y las prioridades de formación de la
organización.
1. Necesidades de formación comunes a proyectos y a grupos de
soporte.
2. Compromisos de formación.
SUBPRÁCTICAS
1. Analizar las necesidades de formación identificadas en los
proyectos y grupos de soporte.
El análisis de las necesidades de los proyectos y grupos de soporte
pretende identificar necesidades de formación comunes, que
puedan ser tratadas más eficientemente a nivel de la organización.
Estas actividades de análisis de las necesidades se utilizan para
anticipar las necesidades futuras de formación, que son visibles
primero a nivel de proyecto y de grupo de soporte.
2. Negociar con los proyectos y grupos de soporte cómo se
satisfarán sus necesidades de formación.
El soporte proporcionado por el personal de formación de la
organiza- ción depende de los recursos disponibles de formación y
de las prioridades de formación de la organización.
algunos ejemplos de formación realizados adecuadamente por el

proyecto o grupo de soporte son:
 Formación en el dominio de la aplicación o servicio del proyecto.
 Formación en las herramientas y en los métodos únicos utilizados por
el proyecto o grupo de soporte.
 Formación en seguridad, protección y factores humanos.
3. Documentar los compromisos para proporcionar soporte de

forma- ción a proyectos y grupos de soporte.
SP 1.3 establecer un plan táctico de forMación en la organización

Establecer y mantener un plan táctico de formación en la organización.
OT
El plan táctico de formación de la organización es el plan para
impartir la formación que es responsabilidad de la organización y
es necesario para que las personas realicen sus roles con eficacia.
Este plan se ocupa de la ejecución a corto plazo de la formación y
se ajusta periódicamen- te como respuesta a los cambios (p. ej.,
en las necesidades, en recursos) y a las evaluaciones de eficacia.

1. Plan táctico de formación de la organización.
SUBPRÁCTICAS
1. Establecer el contenido del plan.
el plan táctico de formación de la organización normalmente contiene:

 necesidades de formación.
 temas de formación.
 Calendarios basados en actividades de formación y sus dependencias.
 Métodos utilizados para la formación.
 requisitos y estándares de calidad para los materiales de formación.
 tareas de formación, roles y responsabilidades.
 recursos necesarios incluyendo herramientas, instalaciones, entornos,
dotación de personal, habilidades y conocimientos.
2. Establecer compromisos con el plan.

Los compromisos documentados por aquellos que son
responsables de implementar y dar soporte al plan son esenciales
para que el plan sea eficaz.
3. Modificar el plan y los compromisos según sea necesario.
SP 1.4 establecer una capacidad de forMación

Establecer y mantener una capacidad de formación para abordar las necesida-
des de formación de la organización.
PARA más INFORMACIÓN sobre cómo ANALIZAR LAS posibles decisiones UTILIZANDO un
Resolución.

1. Materiales de formación y artefactos de soporte.
SUBPRÁCTICAS
1. Seleccionar las aproximaciones adecuadas para satisfacer las
necesidades de formación de la organización.
Muchos factores pueden afectar a la selección de las
aproximaciones de formación, incluyendo el conocimiento
específico de la audiencia, costes, calendario y entorno de trabajo.
La selección de una aproxima- ción requiere la consideración de
los medios para proporcionar las habilidades y el conocimiento
de la manera más eficaz posible, dadas las limitaciones.
algunos ejemplos de aproximaciones de formación son:

 aula de formación.
 enseñanza asistida por ordenador.
 auto-estudio guiado.
 aprendizaje formal y programas con mentores.
 Vídeos.
 Charlas con soporte de pizarra.
 seminarios informales durante el almuerzo.
 Formación estructurada en el trabajo.
2. Determinar si los materiales de formación se desarrollan

internamente o se adquieren externamente.
Determinar los costes y beneficios del desarrollo interno de la
forma- ción y de la adquisición de la formación externa.
algunos ejemplos de criterios que pueden usarse para determinar el

modo más eficaz de adquisición de habilidades o conocimientos son:
 aplicabilidad sobre objetivos de rendimiento del trabajo o de proceso.
 disponibilidad de tiempo para preparar la ejecución del proyecto.
 aplicabilidad sobre objetivos del negocio.
 disponibilidad de experiencia interna.
 disponibilidad de formación desde fuentes externas.
algunos ejemplos de fuentes externas de formación son:

 Formación proporcionada por el cliente.
 Cursos de formación disponibles comercialmente.
 programas académicos.
 Conferencias profesionales.
 seminarios.
3. Desarrollar u obtener los materiales de formación.
OT
La formación puede ser proporcionada por el proyecto, grupos de
soporte, la organización o una organización externa. El personal
de for- mación de la organización coordina la adquisición e
impartición de la formación, independientemente de su origen.
algunos ejemplos de materiales de formación son:

 Cursos.
 enseñanza asistida por ordenador.
 Vídeos
4. Desarrollar u obtener instructores cualificados, diseñadores de
la formación o mentores.
Para asegurar que aquellos que desarrollan e imparten la
formación interna tienen el conocimiento y habilidades necesarios
de formación, se pueden definir criterios para identificar,
desarrollar y cualificar a los instructores. El desarrollo de la
formación, incluyendo el auto-estudio y la formación en línea,
debería involucrar a aquellos que tienen experiencia en el diseño
de la formación. En el caso de la formación externa, el personal de
formación de la organización puede investigar cómo el proveedor
de formación determina qué instructores imparti- rán la formación.
Esta selección de instructores cualificados también puede ser un
factor para seleccionar o continuar con un proveedor de formación.
5. Describir la formación del catálogo de formación de la organización.
algunos ejemplos de información proporcionada en las descripciones de

cada curso del catálogo son:
 temas cubiertos en la formación.
 a quién va dirigida.
 prerrequisitos y preparación para la participación.
 Objetivos de la formación.
 duración de la formación.
 planes de las lecciones.
 Criterios de finalización del curso.
 Criterios para la concesión de exenciones de formación.
6. Modificar los materiales de formación y artefactos de soporte

algunos ejemplos de situaciones en las cuales los materiales de formación

y artefactos de soporte pueden necesitar modificarse son:
 Cambio en las necesidades de formación (p. ej., cuando está disponible
una nueva tecnología asociada con el tema de formación).
 una evaluación de la formación identifica la necesidad de cambio
(p.ej., evaluaciones de las encuestas de la eficacia de la formación,
evaluaciones de rendimiento del programa de formación, formularios
de evaluación del instructor).
SG 2 ProPorcionar formación
Se proporciona la formación para que las personas desempeñen sus roles con
eficacia.
Al seleccionar las personas a formar, se debería considerar:

• Conocimientos previos de los receptores de la formación.
• Prerrequisitos previos para recibir la formación.
• Habilidades y capacidades necesarias de las personas para
desem- peñar sus roles.
• Necesidad de formación interdisciplinaria para todas las
disciplinas, incluyendo la gestión de proyectos.
• Necesidad de que los gerentes tengan la formación en los
procesos adecuados de la organización.
• Necesidad de formación en principios básicos de todas las
disciplinas o servicios apropiados al personal de soporte en
gestión de la calidad, gestión de configuración y otras funciones
de soporte relacionadas.
• Necesidad de proporcionar el desarrollo de competencias
para las áreas funcionales críticas.
• Necesidad de mantener competencias y cualificaciones del
personal para operar y mantener entornos de trabajo comunes a
varios proyectos.
SP 2.1 iMpartir la forMación

Impartir la formación siguiendo el plan táctico de formación de la organización.

1. Curso de formación impartido.
SUBPRÁCTICAS
1. Seleccionar a aquellos que recibirán la formación necesaria
para desempeñar sus roles con eficacia.
La formación pretende impartir el conocimiento y las habilidades a
personas que desempeñan diferentes roles en la organización.
Algunas personas ya poseen el conocimiento y las habilidades
requeridas para desempeñar bien sus roles designados. La formación
puede no aplicarse a estas personas, pero se debe tener cuidado de no
abusar de las exenciones a la formación.
2. Calendario de formación, incluyendo cualquier recurso, según
sea necesario (p. ej., instalaciones, instructores).
La formación debería estar planificada y programada. Se
proporciona la formación que tenga una relación directa sobre las
expectativas de desempeño en el trabajo. Por lo tanto, la formación
será óptima, cuando se imparte en el momento oportuno en
relación a las expectativas de desempeño del trabajo.
OT
estas expectativas de desempeño incluyen a menudo:
 Formación en el uso de herramientas especializadas.
 Formación en los procedimientos nuevos para las personas que los
ejecutarán.
3. Impartir la formación.
Si la formación es impartida por personas, entonces se debería im-
partir por profesionales de formación apropiados (p. ej.,
instructores
experimentados, mentores). Cuando sea posible, la formación se
rea- lizará en lugares que se asemejen mucho al entorno de trabajo
real, e incluye actividades para simular situaciones reales de
trabajo. Esta aproximación incluye integración de herramientas,
métodos y procedimientos para el desarrollo de competencias. La
formación está vincu- lada a las responsabilidades de trabajo, de
modo que las actividades en el trabajo u otras experiencias
externas, reforzarán la formación en un plazo razonable después de
que haya sido impartida.
4. Seguir la impartición de formación frente al plan.
SP 2.2 establecer los registros de forMación
Establecer y mantener los registros de formación de la organización.
Esta práctica se aplica a la formación realizada a nivel de la

organiza- ción. El establecimiento y mantenimiento de los
registros de forma- ción para la formación patrocinada por
proyectos o grupos de soporte es responsabilidad de cada
proyecto individual o grupo de soporte.

1. Registros de formación.
2. Actualizaciones de la formación en el repositorio de la organización.
SUBPRÁCTICAS
1. Mantener registros de todos los estudiantes que completen con
éxi- to cada curso de formación u otras actividades de
formación autorizadas, así como de aquellos que han
fracasado.
2. Mantener registros de todo el personal que ha sido eximido de
la formación.
La razón fundamental para la concesión de una exención se debería
documentar y tanto el gerente responsable y el gerente de la
persona que ha solicitado la excepción deberían aprobar dicha
exención.
3. Mantener los registros de todos los estudiantes que completen
con éxito su formación requerida.
4. Poner los registros de formación a disposición del personal
apropiado para su consideración en las asignaciones.
Los registros de formación pueden ser parte de una matriz de
habilidades desarrollada por la organización de formación para
ofrecer un resumen de la experiencia y la educación de las
personas, así como la formación patrocinada por la organización.
SP 2.3 evaluar la eficacia de la forMación

Evaluar la eficacia del programa de formación de la organización.
Debería existir un proceso para determinar la eficacia de la

formación (es decir, lo bien que la formación está cumpliendo las
necesidades de la organización).
algunos ejemplos de métodos utilizados para evaluar la eficacia de la

formación son:
 pruebas en el contexto de formación.
 encuestas posteriores a la formación de los participantes.
 encuestas de satisfacción de los gerentes con efectos posteriores a la
formación.
 Mecanismos de evaluación incluidos en los cursos.
Se pueden tomar medidas para evaluar los beneficios de la

for- mación tanto frente a los objetivos del proyecto como frente
a los objetivos de la organización. Se debería prestar especial
atención a la necesidad de diferentes métodos de formación, tales
tanto equipos de formación como unidades de trabajo integral. Si
se usan, los objetivos de rendimiento de proceso o de trabajo
deberían ser no ambiguos, ob- servables, verificables y
compartidos con los participantes del curso. Los resultados de la
evaluación de la eficacia de la formación se debe- rían utilizar
para modificar los materiales de formación según se describe en
la práctica específica Establecer una capacidad de formación.

1. Encuestas de la eficacia de la formación.
2. Evaluaciones del rendimiento del programa de formación.
3. Formularios de evaluación del instructor.
4. Exámenes de formación.
SUBPRÁCTICAS
1. Evaluar los proyectos terminados o en curso para determinar
si el conocimiento del personal es adecuado para realizar las
tareas del proyecto.
2. Proporcionar un mecanismo para evaluar la eficacia de cada
curso de formación, con respecto a los objetivos de aprendizaje
establecidos (o rendimiento) individual, del proyecto o de la
organización.
3. Obtener evaluaciones de los estudiantes sobre cómo las
actividades de formación han satisfecho sus necesidades.
OT
integración del producto

un área de proceso de ingeniería en el nivel de madurez 3
propósito
El propósito de la Integración del Producto (PI) es ensamblar el
producto a partir de sus componentes, asegurar que el producto,
una vez integrado, se comporta correctamente (es decir, posee la
funcionalidad y los atributos de calidad requeridos) y entregar el
producto.
Este área de proceso trata la integración de componentes de
producto dentro de componentes de producto más complejos o
dentro de productos completos.
El alcance de este área de proceso es lograr la integración del
producto completo a través de un ensamblaje progresivo de los
componentes de producto, en una etapa o en etapas
incrementales, de acuerdo a una estrategia y procedimientos de
integración definidos. En todas las áreas de procesos donde se
utilizan los términos “produc- to” y “componente de producto”, sus
significados pretenden también englobar servicios, sistemas de
servicios y sus componentes.
Un aspecto crítico de la integración del producto es la gestión de
las interfaces, internas y externas, de los productos y de los
componentes de producto para asegurar la compatibilidad entre
las interfaces. Estas interfaces no se restringen a las interfaces de
usuario, sino que también se aplican a las interfaces entre
componentes del producto, incluyendo fuentes de datos internas y
externas, middleware y otros componentes que pueden o no estar
dentro del control de la organización de desarrollo, pero de las
que depende el producto. Debería prestarse atención a la gestión
de la interfaz a lo largo del proyecto.
La integración del producto es algo más que un ensamblaje
único de los componentes de producto a la finalización del diseño
y la fa- bricación. La integración del producto puede llevarse a
cabo de forma incremental, utilizando un proceso iterativo de
ensamblaje de componentes de producto, evaluándolos, y
después ensamblando más componentes de producto. Puede
llevarse a cabo utilizando construcciones altamente automatizadas
PI
e integración continua de productos probados completamente

de forma unitaria. Este proceso puede comenzar
377
con análisis y simulaciones (p. ej., hilos de ejecución, prototipos
rá- pidos, prototipos virtuales, prototipos físicos) y progresar
firmemen- te mediante incrementos cada vez más realistas hasta
que se logre el producto final. En cada construcción, se
construyen los prototipos (virtuales, rápidos o físicos), se evalúan,
se mejoran y se reconstruyen sucesivamente en base al
conocimiento adquirido en el proceso de evaluación. La
proporción necesaria de prototipo virtual frente al prototipo
físico, depende de la funcionalidad de las herramientas de dise-
ño, de la complejidad del producto y de sus riesgos asociados.
Existe una alta probabilidad de que el producto integrado de esta
manera, pa- sará la verificación y la validación. Para algunos
productos y servicios, la última fase de integración se producirá
cuando se desplieguen en el lugar operacional previsto.
Para líneas de productos, los productos son ensamblados de acuer-
do al plan de producción de la línea de producto. El plan de
produc- ción de la línea de producto específica el proceso de
ensamblado, incluyendo los activos fundamentales a utilizar y
cómo se resuelve la variación de la línea de producto dentro de
esos activos base.
En entornos ágiles, la integración del producto es una actividad frecuen-

te, a menudo diaria. Por ejemplo, para el software, el código elaborado se
añade continuamente al código base en un proceso llamado “integración
continua”. Además de tratar la integración continua, la estrategia de integra-
ción del producto puede abordar cómo se incorporarán los componentes
suministrados por el proveedor, cómo se construirá la funcionalidad (en
capas frente a “piezas verticales”), y cuándo “refactorizar”. La estrategia
debería establecerse en etapas tempranas del proyecto y modificarse para
reflejar la evolución y la aparición de las interfaces de los componentes,
las fuentes externas, el intercambio de datos y las interfaces de los progra-
mas de las aplicaciones (véase “Interpretando CMMI al utilizar Ágiles “en la
Primera Parte”).

PARA más INFORMACIÓN sobre cómo IDENTIFICAR los requisitos de interFAZ, consúltese
el árEA de proceso DESARrollo de Requisitos.
PARA más INFORMACIÓN sobre cómo DISEÑAR LAS interFACES UTILIZANDO criterios, con-
súltese el árEA de proceso Solución TÉCNICA.
PARA más INFORMACIÓN sobre cómo rEALIZAR LA VALIDACIÓN, consúltese el árEA de
proceso VALIDACIÓN.
PARA más INFORMACIÓN sobre cómo rEALIZAR LA VERIFICACIÓN, consúltese el árEA de
proceso VERIFICACIÓN.
PARA más INFORMACIÓN sobre cómo seguir y contrOLAR los CAMBIOS, consúltese AL
árEA de proceso Gestión de CONFIGURACIÓN.
Integración del producto 379
PArA más informAción sobre cómo An AlizAr posibles decisiones usAndo un
proceso formAl de evAluAción, que evAlúe AlternAtivAS identificAdAS frente A
criterios estAblecidos, consúltese el áreA de proceso Análisis de Decisiones y
Resolución.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR y MITIGAR riesgos, consúltese el árEA
de proceso Gestión de Riesgos.
PARA más INFORMACIÓN sobre cómo GESTIONAR LA ADQUISICIÓN de productos y ser-
vicios de proveedores, consúltese el árEA de proceso Gestión de Acuerdos con
Proveedores.

SG 1 Prepararse para la integración del producto.
SP 1.1 Establecer una estrategia de integración.
SP 1.2 Establecer el entorno de integración del producto.
SP 1.3 Establecer los procedimientos y los criterios de integración del producto.
SG 2 Asegurar la compatibilidad de las interfaces.
SP 2.1 Revisar la completitud de las descripciones de las interfaces.
SP 2.2 Gestionar las interfaces.
SG 3 Ensamblar los componentes de producto y entregar el producto.
SP 3.1 Confirmar la disponibilidad de los componentes de producto para la integración.
SP 3.2 Ensamblar los componentes de producto.
SP 3.3 Evaluar los componentes de producto ensamblados.
SP 3.4 Empaquetar y entregar el producto o componente de producto.
prácticas específicas por metas
SG 1 P rePararSe Para la inteGración del Producto

Se lleva a cabo la preparación para la integración del producto.
La preparación para la integración de los componentes de

producto implica establecer una estrategia de integración,
establecer el entorno para realizar la integración, y establecer los
procedimientos y criterios de integración. La preparación para la
integración comienza en las etapas tempranas del proyecto.
SP 1.1 EstablEcEr una EstratEgia dE intEgración
Establecer y mantener una estrategia de integración del producto.
La estrategia de integración del producto describe la

aproximación para recibir, ensamblar y evaluar los componentes
de producto que componen el producto.
PI
Una estrategia para la integración del producto aborda
elementos tales como:
 Poner a disposición los componentes de producto para la
inte- gración (p. ej., en qué secuencia).
 Ensamblar y evaluar si es una única construcción o una
progre- sión de construcciones incrementales.
 Incluir y probar las características en cada iteración
cuando se utiliza desarrollo iterativo.
 Gestionar las interfaces.
 Utilizar modelos, prototipos y simulaciones para ayudar
en la evaluación de un ensamblaje, incluyendo sus
interfaces.
 Establecer el entorno de integración del producto.
 Definir los procedimientos y criterios.
 Poner a disposición las herramientas y el equipamiento de
pruebas apropiados.
 Gestionar la jerarquía, arquitectura y complejidad del producto.
 Registrar los resultados de las evaluaciones.
 Manejar las excepciones.
La estrategia de integración debería estar también alineada con la
aproximación técnica descrita en el área de proceso Planificación del
Pro- yecto y armonizada con la selección de soluciones y el diseño del
produc- to y de componentes de producto en el área de proceso
Solución Técnica.
PArA más informAción sobre cómo seleccionAr lAS SOluciones de los componentes de
producto e implementAr el diseño, consúltese el áreA de proceso Solución TécnicA.
PArA más informAción sobre cómo AnAlizAr posibles decisiones utilizAndo un proce-
so de evAluAción formAl que evAlúe lAS AlternAtivAS identificAdAS frente A los crite-
rios estAblecidos, consúltese el áreA de proceso Análisis de Decisiones y Resolución.
PARA más INFORMACIÓN sobre cómo ESTABLECER y MANTENER PLANES que definen LAS
ACTIVIDADES del proyecto, consúltese el árEA de proceso PLANIFICACIÓN del Proyecto.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR y MITIGAR riesgos, consúltese el árEA
de proceso Gestión de Riesgos.
PArA más informAción sobre cómo gestionAr lA Adquisición de productos y servicios
de proveedores, consúltese el áreA de proceso Gestión de Acuerdos con Proveedores.
Los resultados de desarrollar una estrategia de integración del
producto son documentados normalmente en un plan de
integración del producto, que se revisa con las partes interesadas
para promover el compromiso y la comprensión. Algunos de los
elementos tratados en una estrategia de integración del producto
se cubren con más detalle en las otras prácticas específicas y
genéricas de este área de proceso (p. ej., entorno, procedimientos y
criterios, formación, roles y responsabilidades, e involucración
de las partes interesadas).
1. Estrategia de integración del producto.
2. La razón fundamental de la selección o rechazo de las
estrategias alternativas de integración del producto.
SUBPRACTICAS
1. Identificar los componentes de producto a integrar.
2. Identificar las verificaciones a realizar durante la integración de
los componentes de producto.
Esta identificación incluye las verificaciones a realizar en las interfaces.
3. Identificar estrategias alternativas de integración de los
componentes de producto.
El desarrollo de una estrategia de integración puede implicar la
espe- cificación y evaluación de varias estrategias o secuencias
alternativas de integración.
4. Seleccionar la mejor estrategia de integración.
Será necesario alinear y armonizar la estrategia de integración
con la disponibilidad de: los componentes de producto; el
entorno de inte- gración; las herramientas y el equipamiento de
pruebas; los procedimientos y criterios; las partes interesadas
relevantes; y el personal que posee las habilidades apropiadas.
5. Revisar periódicamente la estrategia de integración del producto
y modificar, según sea necesario.
Evaluar la estrategia de integración del producto para asegurar
que las variaciones en los calendarios de producción y de entrega
no han tenido un impacto adverso sobre la secuencia de
integración, o han comprometido los factores sobre los cuales se
tomaron las decisiones anteriores.
6. Registrar la razón fundamental de las decisiones tomadas y diferidas.
SP 1.2 EstablEcEr El Entorno dE intEgración dEl producto

Establecer y mantener el entorno necesario para dar soporte a la integración de
El entorno para la integración del producto puede o bien

adquirirse o bien desarrollarse. Para establecer un entorno, será
necesario desarrollar los requisitos para la compra o desarrollo
de equipamien- to, software u otros recursos. Estos requisitos se
recogen cuando se implementan los procesos asociados con el
área de proceso Desa- rrollo de Requisitos. El entorno de
integración del producto puede incluir la reutilización de los
recursos existentes de la organización. La decisión para adquirir
o desarrollar el entorno de integración del producto se trata en los
PI
procesos asociados con el área de proceso de Solución Técnica.

PARA más INFORMACIÓN sobre cómo LLEVAR A CABO los ANÁLISIS de rEALIZAR, COMPRAR
o rEUTILIZAR, consúltese el árEA de proceso Solución TÉCNICA.
En cada paso del proceso de integración del producto, el
entorno requerido puede incluir el equipamiento de pruebas,
simuladores (sustituyendo los componentes del producto que no
estén disponibles) piezas del equipamiento real, y dispositivos
de grabación.

1. Entorno verificado para la integración del producto.
2. Documentación de soporte para el entorno de integración del
producto.
SUBPRÁCTICAS
1. Identificar los requisitos para el entorno de integración del producto.
2. Identificar los procedimientos y criterios de verificación para el
entorno de integración del producto.
3. Decidir si desarrollar o comprar el entorno necesario de
integración del producto.
PARA más INFORMACIÓN sobre cómo GESTIONAR LA ADQUISICIÓN de productos y ser-
vicios de proveedores, consúltese el árEA de proceso Gestión de Acuerdos con
Proveedores.
4. Desarrollar el entorno de integración si no puede adquirirse un
entorno adecuado.
Para proyectos complejos, sin precedentes, el entorno de integra-
ción del producto puede ser un desarrollo importante. Como tal,
implicaría la planificación del proyecto, el desarrollo de
requisitos, las soluciones técnicas, la verificación, la validación
y la gestión de riesgos.
5. Mantener el entorno de integración del producto durante todo el
proyecto.
6. Desechar aquellas partes del entorno que ya no son útiles.
SP 1.3 EstablEcEr los procEdimiEntos y los critErios dE intEgración dEl producto

Establecer y mantener los procedimientos y los criterios para la integración de
Los procedimientos para la integración de los componentes de

produc- to pueden incluir aspectos como el número de iteraciones
incrementales a realizar y detalles de las pruebas y otras
evaluaciones previstas que se llevarán a cabo en cada etapa.
Los criterios pueden indicar la disponibilidad de un
componente de producto para la integración o su aceptación.
Los procedimientos y criterios para la integración del
producto abordan:
 El nivel de prueba para construir componentes.
 La verificación de las interfaces.
 Los umbrales de desviación de rendimiento.
 Los requisitos obtenidos para el ensamblaje y sus
interfaces externas.
 Las sustituciones de componentes permitidas.
 Los parámetros del entorno de prueba.
 Los limites en el coste de las pruebas.
 Un equilibrio de calidad/coste para las operaciones
de integración.
 La probabilidad de funcionamiento apropiado.
 La tasa de entrega y su variación.
 El tiempo transcurrido desde el pedido hasta la entrega.
 La disponibilidad de personal.
 La disponibilidad de las
instalaciones/línea/entorno de integración.
Se pueden definir los criterios sobre cómo han de verificarse

los componentes de producto y los comportamientos
(funcionalidad y atributos de calidad) que se espera que tengan.
Se pueden definir los criterios sobre cómo los componentes de
producto ensamblado y el producto final integrado serán
validados y entregados.
Los criterios también pueden limitar el grado de simulación
per- mitido para que un componente de producto pase una
prueba, o pueden limitar el entorno a utilizar para la prueba de
integración.
Las partes pertinentes del calendario y de los criterios para el
ensamblaje deberían compartirse con los proveedores de los pro-
ductos de trabajo para reducir la aparición de retrasos y de fallo
de componentes.
PARA más INFORMACIÓN sobre cómo EJECUTAR el ACUERdo con el proveedor, consúltese
el árEA de proceso Gestión de Acuerdos con Proveedores.

1. Procedimientos de integración del producto.
2. Criterios de integración del producto.
SUBPRÁCTICAS
1. Establecer y mantener los procedimientos de integración del
produc- to para los componentes de producto.
2. Establecer y mantener los criterios para la integración y
evaluación de los componentes de producto.
PI
3. Establecer y mantener los criterios para la validación y entrega

del producto integrado.
SG 2 a SeGurar la comPatibilidad de laS interfaceS
Las interfaces de los componentes de producto, tanto internas como externas,
son compatibles.
Muchos problemas en la integración del producto surgen de

aspectos desconocidos o incontrolados, tanto de las interfaces
internas como de las externas. La gestión eficaz de los requisitos,
especificaciones y diseños de las interfaces de los componentes
de producto, ayuda a asegurar que las interfaces implementadas
sean completas y compatibles.
SP 2.1 rEvisar la complEtitud dE las dEscripcionEs dE las intErfacEs
Revisar la cobertura y la completitud de las descripciones de las interfaces.
Las interfaces deberían incluir, además de las interfaces de los

componentes de producto, todas las interfaces con el entorno de
integración del producto.

1. Categorías de interfaces.
2. Lista de interfaces por categoría.
3. Correspondencia de las interfaces con los componentes de
producto y el entorno de integración del producto.
SUBPRÁCTICAS
1. Revisar la completitud de los datos de interfaces y asegurar la
cobertura completa de todas las interfaces.
Considerar todos los componentes de producto y preparar una
tabla de relaciones. Las interfaces se clasifican generalmente en
tres clases principales: ambientales, físicas y funcionales. Las
categorías típicas para estas clases son: mecánica, fluido, sonido,
eléctrica, climática, electromagnética, térmica, mensaje y
hombre-máquina o interfaz humana.
Algunos ejemplos de interfaz (p. ej. para componentes mecánicos o electró-

nicos) que pueden clasificarse dentro de estas tres clases son:
• Interfaces mecánicas (p. ej., peso y tamaño, centro de gravedad, espacio
de elementos en operación, espacio requerido para mantenimiento,
enlaces fijos, enlaces móviles, impactos y vibraciones recibidas de la
estructura de soporte).
• Interfaces de ruido (p. ej., ruido trasmitido por la estructura, ruido
trasmitido en el aire y acústica).
• Interfaces climáticas (p. ej., temperatura, humedad, presión y salinidad).
Continúa
Continuación
• Interfaces térmicas (p. ej., disipación de calor, transmisión de calor a la
estructura de soporte y características del aire acondicionado).
• Interfaces de fluidos (p. ej., toma/salida de agua dulce, toma/salida de agua de
mar para productos navales/costeros, aire acondicionado, aire comprimido,
nitrógeno, combustible, aceite lubricante y tobera de salida de gas).
• Interfaces eléctricas (p. ej., consumo de energía suministrada por la
red con valores pico y transitorios, señales de control no sensibles
al suministro de energía y comunicaciones, señales sensibles [p. ej.,
enlaces analógicos]; señales perturbadoras [p. ej., microondas]; tomas
de tierra para cumplir con el estándar TEMPEST).
• Interfaces electromagnéticas (p. ej., campo magnético, enlaces de radio
y radar, enlace de banda óptica, guías de onda, coaxial y fibras ópticas).
• Interfaz hombre-máquina (p. ej., síntesis de audio o voz,
reconocimiento de audio o voz, pantalla [marcación analógica, pantalla
de cristal líquido, paneles indicadores led] controles manuales [pedal,
joystick, trackball, teclado, pulsadores, pantalla táctil).
• Interfaces de mensaje (p. ej., origen, destino, estímulo, protocolos,
características de datos).
2. Asegurar que los componentes de producto y las interfaces se
eti- quetan para asegurar una conexión fácil y correcta para la
unión del componente de producto.
3. Revisar periódicamente que las descripciones de las interfaces
son adecuadas.
Una vez establecidas las descripciones de las interfaces, deberían
revisarse periódicamente para asegurar que no existe desviación
entre las descripciones existentes y los productos que se están
desarrollando, procesando, produciendo o comprando.
Las descripciones de las interfaces para los componentes de
produc- to deberían revisarse con las partes interesadas
relevantes para evitar malas interpretaciones, reducir los retrasos
y prevenir el desarrollo de interfaces que no funcionen
adecuadamente.
SP 2.2 gEstionar las intErfacEs

Gestionar las definiciones, diseños y cambios de las interfaces internas y exter-
nas, para los productos y componentes de producto.
Los requisitos de interfaz guían el desarrollo de las interfaces

necesarias para integrar los componentes de producto. La
gestión de las interfaces del producto y de los componentes de
producto comienza en las etapas tempranas del desarrollo del
producto. Las definiciones y diseños para las interfaces no sólo
PI
afectan a los componentes de producto y a los sistemas externos,

sino que también pueden afectar a los entornos de verificación y
validación.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR los requisitos de interFAZ, consúltese
el árEA de proceso DESARrollo de Requisitos.
PARA más INFORMACIÓN sobre cómo DISEÑAR LAS interFACES UTILIZANDO criterios, con-
súltese el árEA de proceso Solución TÉCNICA.
PARA más INFORMACIÓN sobre cómo ESTABLECER y MANTENER LA INTEGRIDAD de los
productos de TRABAJO MEDIANTE LA IDENTIFICACIÓN de CONFIGURACIÓN, el control de
CONFIGURACIÓN, el informe de ESTADO de LA CONFIGURACIÓN y LAS AUDITORÍAS de confi-
GURACIÓN, consúltese el árEA de proceso Gestión de CONFIGURACIÓN.
PARA más INFORMACIÓN sobre cómo los CAMBIOS A los requisitos de interFAZ, con-
súltese LA PRÁCTICA ESPECÍFICA GESTIONAR los CAMBIOS de requisitos en el árEA de
proceso Gestión de Requisitos.
La gestión de las interfaces incluye el mantenimiento de la
consistencia de las interfaces durante toda la vida del producto,
el cumplimiento con las decisiones y limitaciones de la
arquitectura, y la resolución de conflictos, las no conformidades
y cuestiones de cambio. La gestión de las interfaces entre los
productos adquiridos a proveedores y otros productos o
componentes de productos es crítica para el éxito del proyecto.
PARA más INFORMACIÓN sobre cómo GESTIONAR LA ADQUISICIÓN de productos y servicios
A proveedores, consúltese el árEA de proceso Gestión de Acuerdos con Proveedores.
Las interfaces deberían incluir, además de las interfaces de
los componentes de producto, todas las interfaces con el entorno,
así como con otros entornos para la verificación, validación,
operaciones y soporte.
Los cambios de las interfaces se documentan, se mantienen y
son de fácil acceso.

1. Tabla de relaciones entre los componentes de producto y el
entorno externo (p. ej., fuente de alimentación principal,
producto de suje- ción, sistema de bus del ordenador).
2. Tabla de relaciones entre los diferentes componentes de producto.
3. Lista de interfaces acordadas que se definen para cada par de
componentes de producto, cuando sea aplicable.
4. Informes de las reuniones del grupo de trabajo de control de
interfaces.
5. Elementos de acción para la actualización de las interfaces.
6. Interfaz de programación de aplicaciones (API).
7. Descripción o acuerdo de interfaces actualizados.
SUBPRÁCTICAS
1. Asegurar la compatibilidad de las interfaces durante toda la vida
del producto.
2. Resolver los conflictos, no conformidades y cuestiones de cambios.
3. Mantener un repositorio para los datos de interfaz accesible a
los participantes del proyecto.
Un repositorio común accesible para los datos de interfaz
proporciona un mecanismo para asegurar que todo el mundo
conoce dónde residen los datos actuales de interfaz y puede
acceder a ellos para su uso.
SG 3 e nSamblar loS comPonenteS de Producto y entreGar el Producto

Se ensamblan los componentes de producto verificados y se entrega el produc-
to integrado, verificado y validado.
En la integración de los componentes de producto se procede de

acuerdo a la estrategia y procedimientos de integración del
producto. Antes de la integración, debería confirmarse que cada
componente de producto está conforme con sus requisitos de
interfaz. Los componentes de producto se ensamblan dentro de
componentes de producto más grandes y más complejos. Estos
componentes de producto ensamblados se comprueban para una
correcta interoperabilidad. Este proceso continúa hasta que se
completa la integración del producto. Si durante este proceso se
identifican problemas, el problema debería documentarse e
iniciarse un proceso de acción correctiva. La recepción oportuna
de los componentes de producto necesarios y la involucración de
las personas adecuadas contribuyen al éxito de la integración de
los componentes de producto que componen el producto.
SP 3.1 confirmar la disponibilidad dE los componEntEs dE producto para la intEgración
Confirmar, antes de ensamblar, que cada componente de producto requerido
para ensamblar el producto haya sido identificado adecuadamente, se com-
porta de acuerdo a su descripción y que las interfaces del componente de pro-
ducto cumplen con las descripciones de las interfaces.
PARA más INFORMACIÓN sobre cómo rEALIZAR LA VERIFICACIÓN, consúltese con el árEA
de proceso VERIFICACIÓN.
El propósito de esta práctica específica es asegurar que el compo-

nente de producto identificado apropiadamente que cumple con
su descripción, puede realmente ensamblarse de acuerdo a la
estrategia y procedimientos de integración del producto. Los
componentes de producto se comprueban en cuanto a cantidad,
daños evidentes y consistencia entre el componente de producto
y las descripciones de interfaces.
Aquellos que llevan a cabo la integración del producto son
finalmente los responsables de la comprobación para asegurar
que todo está conforme respecto a los componentes de producto
PI
antes del ensamblaje.

1. Documentos de aceptación de los componentes de producto recibidos.
2. Justificantes de entrega.
3. Listas de paquetes comprobados.
4. Informes de excepción.
5. Exenciones.
SUBPRÁCTICAS
1. Seguir el estado de todos los componentes de producto tan
pronto como estén disponibles para la integración.
2. Asegurar que los componentes de producto se incluyen en el
entorno de integración del producto, de acuerdo con la estrategia
y los procedimientos de integración del producto.
3. Confirmar la recepción de cada componente de producto
identificado adecuadamente.
4. Asegurar que cada componente de producto recibido cumple
con su descripción.
5. Comprobar el estado de la configuración frente a la
configuración esperada.
6. Realizar una pre-comprobación (p.ej., mediante una inspección
visual, utilizando medidas base) de todas las interfaces físicas
antes de conectar los componentes de producto.
SP 3.2 Ensamblar los componEntEs dE producto
Ensamblar los componentes de producto de acuerdo a la estrategia y procedi-
mientos de integración del producto.
Las actividades de ensamblaje de esta práctica específica y las

actividades de evaluación de la siguiente práctica específica se
llevan a cabo iterativamente, desde los componentes de producto
inicial, mediante ensamblajes intermedios de los componentes
de producto, hasta el producto como un todo.
Ejemplos de productos de TRABAJOS

1. Producto o componentes de producto ensamblados.
SUBPRÁCTICAS
1. Asegurar la disponibilidad del entorno de integración del producto.
2. Llevar a cabo la integración de acuerdo con la estrategia,
procedimientos y criterios de integración del producto.
Registrar toda la información apropiada (p. ej., estado de la
configura- ción, números de serie de los componentes de
producto, tipos, fecha de calibración de los medidores).
3. Modificar la estrategia, los procedimientos y los criterios de
integra- ción del producto, según sea apropiado.
SP 3.3 Evaluar los componEntEs dE producto Ensamblados
Evaluar los componentes de producto ensamblados para la compatibilidad de
las interfaces.
PARA más INFORMACIÓN sobre cómo rEALIZAR LA VERIFICACIÓN, consúltese AL árEA de
Esta evaluación implica examinar y probar el rendimiento, la
adecua- ción, la disponibilidad o la preparación de los
componentes de producto ensamblados usando los
procedimientos, criterios y entorno de integración del producto.
Esto se lleva a cabo según sea apropiado para las diferentes
etapas de ensamblaje de los componentes de producto, tal como
se identificó en la estrategia y en los procedimientos de
integración del producto. La estrategia y procedimientos de
integra- ción del producto pueden definir una integración más
refinada y una secuencia de evaluación que podría ser solo
visualizada examinando la jerarquía o la arquitectura del producto.
Por ejemplo, si un ensamblaje de componentes de producto se
compone de cuatro componentes de producto menos complejos,
la estrategia de integración no requerirá necesariamente la
integración y evaluación simultáneas de las cuatro unidades
como una sola. Más bien, las cuatro unidades menos com- plejas
pueden integrarse progresivamente, de una en una, con una
evaluación después de cada operación de ensamblaje, previa a la
reali- zación del componente de producto más complejo, que
corresponde a la especificación en la arquitectura del producto. De
forma alternativa, la estrategia y procedimientos de integración
del producto podrían haber determinado que realizar sólo una
evaluación final fuera lo mejor.
1. Informes de excepción.
2. Informes de evaluación de las interfaces.
3. Informes resumen de integración del producto.
SUBPRÁCTICAS
1. Llevar a cabo la evaluación de los componentes de producto
ensamblados siguiendo la estrategia, procedimientos y criterios
de integra- ción del producto.
2. Registrar los resultados de la evaluación.
Algunos ejemplos de resultados son:

• Cualquier adaptación requerida para el procedimiento o criterios de
integración.
PI
• Cualquier cambio a la configuración del producto (piezas de repuesto,

nueva versión).
• Evaluación de las desviaciones de los procedimientos o criterios.
SP 3.4 EmpaquEtar y EntrEgar El producto o componEntE dE producto
Empaquetar el producto o componente de producto ensamblado y entregarlo
al cliente.
PARA más INFORMACIÓN sobre cómo rEALIZAR LA VERIFICACIÓN, consúltese el árEA de
Los requisitos de empaquetado para algunos productos pueden

tratarse en sus especificaciones y criterios de verificación. Este
tratamiento de requisitos es especialmente importante cuando los
elementos se almacenan y transportan por el cliente. En estos
casos, puede existir un espectro de condiciones ambientales y de
estrés especificadas para el paquete. En otras circunstancias,
factores como los siguientes pueden llegar a ser importantes:
 Ahorro y facilidad de transporte (p. ej., contenedores).
 Responsabilidad (p. ej., embalaje).
 Facilidad y protección del desembalaje (p. ej., bordes
afilados, resistencia de los métodos de fijación, protección
a menores, consideraciones ecológicas del material de
empaquetado, peso).
El ajuste requerido para encajar los componentes de producto

en la fábrica podría ser diferente al requerido para encajar los
componentes del producto, cuando se instalan en el sitio de
operación. En ese caso, la documentación del producto para el
cliente debe utilizarse para registrar dichos parámetros
específicos.

1. Producto o componentes de producto empaquetados.
2. Documentación de entrega.
SUBPRÁCTICAS
1. Revisar los requisitos, diseño, producto, resultados de la
verificación y documentación para asegurar que las cuestiones
que afectan al empaquetado y a la entrega del producto están
identificados y resueltos.
2. Utilizar métodos eficaces para empaquetar y entregar el
producto ensamblado.
Algunos ejemplos de empaquetado de software y de métodos de entrega

son:
• Cinta magnética.
• Disquetes.
Continúa
Continuación
• Copias impresas de documentos.
• Discos compactos.
• Otra distribución electrónica como Internet.
3. Satisfacer los requisitos y estándares aplicables para el
empaquetado y la entrega del producto.
Algunos ejemplos de requisitos y estándares son los de protección, entor-

no, seguridad, facilidad de transporte y retirada.
Algunos ejemplos de requisitos y estándares para el empaquetado y la en-

trega del software son:
• Tipo de almacenamiento y medios de entrega.
• Conservación de las copias maestras y de respaldo.
• Documentación requerida.
• Derechos de autor.
• Contrato de licencia.
• Seguridad del software.
4. Preparar el sitio de operación para la instalación del producto.
Preparar el sitio de operación puede ser responsabilidad del
cliente o de los usuarios finales.
5. Entregar el producto y la documentación relacionada, y
confirmar la recepción.
6. Instalar el producto en el sitio de operación y confirmar el
funcionamiento correcto.
Instalar el producto puede ser responsabilidad del cliente o de los
usuarios finales. En algunas circunstancias, puede que se necesite
hacer poco para confirmar la correcta operación. En otras
circunstancias, la verificación final del producto integrado se
produce en el sitio de operación.
PI
Monitorización y control del proyecto 393
PMC
MonitoriZación Y control del proYecto
un área de proceso de gestión de proyectos en el nivel de madurez 2
propósito
El propósito de la Monitorización y Control del Proyecto (PMC)
es proporcionar una comprensión del progreso del proyecto para
que se puedan tomar las acciones correctivas apropiadas, cuando
el rendimiento del proyecto se desvíe significativamente del
plan.
Un plan de proyecto documentado es la base para la
monitorización de las actividades, la comunicación del estado y
la toma de acciones correctivas. El progreso se determina
principalmente comparando los atributos de los productos de
trabajo y de las tareas, el esfuerzo, el coste y el calendario reales,
con el plan en los hitos o niveles de control establecidos en el
calendario del proyecto o en la estructura de descomposición del
trabajo (WBS). Una visibilidad adecuada del progreso permite
llevar a cabo las acciones correctivas de manera oportuna
cuando el rendimiento se desvíe significativamente del plan. Una
desviación es significativa si, cuando se deja sin resolver, impide
al proyecto cumplir con sus objetivos.
El término “plan de proyecto”, se utiliza a lo largo de este área de
proceso para referirse al plan global para controlar el proyecto.
Cuando el estado real se desvíe significativamente de los
valores esperados, se llevarán a cabo acciones correctivas según
proceda. Es- tas acciones pueden requerir una replanificación,
que puede incluir la modificación del plan original, el
establecimiento de nuevos acuerdos o la inclusión de
actividades adicionales de mitigación en el plan actual.

PARA más INFORMACIÓN sobre cómo proporCIONAR rESULTADOS de medición, consúlte-
se el árEA de proceso Medición y Análisis.
PARA más INFORMACIÓN sobre cómo ESTABLECER y MANTENER PLANES
que definen LAS ACTIVIDADES del proyecto, consúltese el árEA de proceso
PLANIFI- CACIÓN del Proyecto.

SG 1 Monitorizar el proyecto frente al plan.
SP 1.1 Monitorizar los parámetros de planificación del proyecto.
SP 1.2 Monitorizar los compromisos.
SP 1.3 Monitorizar los riesgos del proyecto.
SP 1.4 Monitorizar la gestión de los datos.
SP 1.5 Monitorizar la involucración de las partes interesadas.
SP 1.6 Llevar a cabo las revisiones del progreso.
SP 1.7 Llevar a cado las revisiones de hitos.
SG 2 Gestionar las acciones correctivas hasta su cierre.
SP 2.1 Analizar las cuestiones.
SP 2.2 Llevar a cabo las acciones correctivas.
SP 2.3 Gestionar las acciones correctivas.
prácticas específicas por meta
SG 1 m onitorizar el Proyecto frente al Plan

El progreso y el rendimiento reales del proyecto se monitorizan frente al plan
de proyecto.
SP 1.1 monitorizar los parámEtros dE planificación dEl proyEcto

Monitorizar los valores reales de los parámetros de planificación del proyecto
frente al plan de proyecto.
Los parámetros de planificación del proyecto constituyen los

indicadores típicos del progreso y del rendimiento del proyecto,
e incluyen atributos de los productos de trabajo y de las tareas, el
coste, el esfuerzo y el calendario. Los atributos de los productos
de trabajo y de las tareas incluyen el tamaño, la complejidad, el
nivel de servicio, la disponibilidad, el peso, la forma, el ajuste y la
función. Debería considerarse la frecuencia de monitorización
de los parámetros.
La monitorización normalmente implica medir los valores
reales de los parámetros de la planificación del proyecto,
comparar los valores reales con los estimados en el plan e
identificar las desviaciones significativas. El registro de los
valores reales de los parámetros de planificación del proyecto
incluye registrar la información contextual asociada para ayudar a
comprender las medidas. El análisis de impacto de las
desviaciones significativas para determinar qué acciones correc-
tivas hay que realizar, se trata en la meta específica 2 y sus
prácticas específicas de este área de proceso.
1. Registros del rendimiento del proyecto.
PMC
2. Registros de las desviaciones significativas.
3. Informes de rendimiento de costes.
SUBPRÁCTICAS
1. Monitorizar el progreso frente al calendario.
La monitorización del progreso normalmente incluye:

• Medir periódicamente el grado de avance real de las actividades e
hitos.
• Comparar el grado de avance real de las actividades e hitos frente al
calendario del plan de proyecto.
• Identificar las desviaciones significativas de las estimaciones del
calendario del plan de proyecto.
2. Monitorizar los costes y el esfuerzo empleado en el proyecto.
La monitorización del coste y del esfuerzo normalmente incluye:

• Medir periódicamente el esfuerzo y los costes reales incurridos y el
personal asignado.
• Comparar el esfuerzo, los costes, el personal y la formación reales con
las estimaciones y el presupuesto del plan de proyecto.
• Identificar las desviaciones significativas del presupuesto y las
estimaciones del plan de proyecto.
3. Monitorizar los atributos de los productos de trabajo y de las tareas.
PARA más INFORMACIÓN sobre cómo DESARrOLLAR y MANTENER UNA CAPACIDAD
de medición UTILIZADA PARA DAR soporte A LAS NECESIDADES de INFORMACIÓN
de gestión, consúltese el árEA de proceso Medición y Análisis.
PARA más INFORMACIÓN sobre cómo ESTABLECER ESTIMACIONES de los ATRIBUTOS
de los productos de TRABAJO y de LAS TAREAS, consúltese el árEA de proceso
PLANIFICACIÓN del Proyecto.
La monitorización de los atributos de los productos de trabajo y de las ta-

reas normalmente incluye:
• Medir periódicamente los atributos reales de los productos de trabajo
y de las tareas (y los cambios a estos atributos), tales como el tamaño, la
complejidad o los niveles de servicio.
• Comparar los atributos reales de los productos de trabajo y de las
tareas (y los cambios a estos atributos) con las estimaciones del plan de
proyecto.
• Identificar las desviaciones significativas de las estimaciones del plan
de proyecto.
4. Monitorizar los recursos proporcionados y los recursos utilizados.
PARA más INFORMACIÓN sobre cómo PLANIFICAR los recursos del proyecto,
consúltese el árEA de proceso PLANIFICACIÓN del Proyecto.

• Instalaciones físicas.
• Ordenadores, periféricos y software.
• Redes.
• Entornos de seguridad.
• Personal del proyecto.
• Procesos.
5. Monitorizar el conocimiento y las habilidades del personal del
proyecto.
PArA más informAción sobre cómo plAnificAr el conocimiento y lAS hA-
bilidAdes necesAriAS, consúltese el áreA de proceso PlAnificAción del
Proyecto.
La monitorización del conocimiento y de las habilidades del personal del

proyecto normalmente incluye:
• Medir periódicamente la adquisición de conocimiento y de las
habilidades por el personal del proyecto.
• Comparar la formación real obtenida con la documentada en el plan de
proyecto.
• Identificar las desviaciones significativas de las estimaciones del plan
de proyecto.
6. Documentar las desviaciones significativas en los parámetros de
pla- nificación del proyecto.
SP 1.2 monitorizar los compromisos

Monitorizar los compromisos frente a aquellos identificados en el plan de
proyecto.

1. Registros de las revisiones de los compromisos.
SUBPRÁCTICAS
1. Revisar los compromisos (tanto externos como internos) con
regularidad.
2. Identificar los compromisos que no se han cumplido o que están
en riesgo significativo de no cumplirse.
3. Documentar los resultados de las revisiones de los compromisos.
SP 1.3 monitorizar los riEsgos dEl proyEcto
Monitorizar los riesgos frente a aquellos identificados en el plan de proyecto.
PMC
PARA más INFORMACIÓN sobre cómo IDENTIFICAR los riesgos del proyecto, consúltese
el árEA de proceso PLANIFICACIÓN del Proyecto.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR los prOBLEMAS POTENCIALES ANTES de
que ocurRAN, de TAL MANERA que LAS ACTIVIDADES PARA el TRATAMIENTO de los riesgos
se PUEDAN PLANIFICAR e INVOCAR según SEA NECESARIO, DURANTE LA VIDA del proyecto
o producto, PARA MITIGAR IMPACTOS ADVERSOS en LA consecución de los objetivos,
consúltese el árEA de proceso Gestión de Riesgos.

1. Registros de la monitorización de los riesgos del proyecto.
SUBPRÁCTICAS
1. Revisar periódicamente la documentación de riesgos en el
contexto del estado y de las circunstancias actuales del proyecto.
2. Modificar la documentación de riesgos, a medida que se va
dispo- niendo de información adicional.
A medida que avanzan los proyectos (especialmente los
proyectos de larga duración u operación continua), surgen
nuevos riesgos. Es importante la identificación y el análisis de
estos nuevos riesgos. Por ejemplo, el software, el equipamiento
y las herramientas en uso pueden llegar a quedar obsoletas; o el
personal clave puede perder gra- dualmente las habilidades en
áreas de particular importancia a largo plazo para el proyecto y la
organización.
3. Comunicar el estado de los riesgos a las partes interesadas relevantes.
Algunos ejemplos de estados del riesgo son:

• Un cambio en la probabilidad de que suceda el riesgo.
• Un cambio en la prioridad del riesgo.
SP 1.4 monitorizar la gEstión dE los datos

Monitorizar la gestión de los datos del proyecto frente al plan de proyecto.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR los tipos de DATOS A GESTIONAR y cómo
PLANIFICAR su gestión, consúltese LA PRÁCTICA ESPECÍFICA PLANIFICAR LA gestión de los
DATOS del árEA de proceso PLANIFICACIÓN del Proyecto.
Las actividades de gestión de los datos deberían monitorizarse

para asegurar que se están cumpliendo los requisitos de dicha
gestión. De- pendiendo de los resultados de la monitorización y
de los cambios en los requisitos, situación o estado del proyecto,
puede ser necesario replanificar las actividades de gestión de los
datos del proyecto.
1. Registros de la gestión de los datos.
SUBPRÁCTICAS
1. Revisar periódicamente las actividades de gestión de los datos
frente a su descripción en el plan de proyecto.
2. Identificar y documentar las cuestiones significativas y sus impactos.
Un ejemplo de una cuestión significativa es cuando las partes interesadas

no tienen el acceso a los datos del proyecto que necesitan para cumplir sus
roles como partes interesadas relevantes.
3. Documentar los resultados de las revisiones de las actividades de
ges- tión de los datos.
SP 1.5 monitorizar la involucración dE las partEs intErEsadas

Monitorizar la involucración de las partes interesadas frente al plan de proyecto.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR A LAS PARTES interESADAS rELEVANTES y
PLANIFICAR UNA INVOLUCRACIÓN ADECUADA con ELLAS, consúltese LA PRÁCTICA ESPECÍFICA
PLANIFICAR LA INVOLUCRACIÓN de LAS PARTES interESADAS en el árEA de proceso PLANI-
FICACIÓN del Proyecto.
La involucración de las partes interesadas debería monitorizarse

para asegurar que se producen las interacciones apropiadas.
Dependiendo de los resultados de la monitorización y de los
cambios en los requisitos, de la situación o del estado del
proyecto, puede ser necesario replanificar la involucración de las
partes interesadas.
En entornos ágiles, la involucración continua del cliente y de los usuarios

finales potenciales en las actividades del proyecto de desarrollo del pro-
ducto puede ser crucial para el éxito del proyecto; por lo tanto, se debería
monitorizar la involucración del cliente y del usuario final en las activida-
des del proyecto (véase “Interpretando CMMI al utilizar enfoques ágiles”
en la Primera Parte).

1. Registros de la involucración de las partes interesadas.
SUBPRÁCTICAS
1. Revisar periódicamente el estado de la involucración de las
partes interesadas.
3. Documentar los resultados de las revisiones del estado de la
involu- cración de las partes interesadas.
SP 1.6 llEvar a cabo las rEvisionEs dEl progrEso
Revisar periódicamente el progreso, el rendimiento y las cuestiones del proyecto.
PMC
El “progreso del proyecto” es el estado del proyecto en un
momento concreto en el que las actividades del proyecto realizadas
hasta ese momento y sus resultados e impactos se revisan con las
partes interesadas relevantes (especialmente los representantes
del proyecto y la direc- ción del proyecto), para determinar si
existen cuestiones significativas o carencias en el rendimiento que
se deban tratar.
Las revisiones del progreso son revisiones del proyecto para
mantener informadas a las partes interesadas relevantes. Estas
revisiones del proyecto pueden ser informales y pueden no estar
especificadas explícitamente en los planes del proyecto.
1. Resultados documentados de la revisión del proyecto.
SUBPRÁCTICAS
1. Comunicar con regularidad a las partes interesadas relevantes el
estado de las actividades y los productos de trabajo asignados.
Los gerentes, el personal, los clientes, los usuarios finales, los
proveedores y otras partes interesadas relevantes se incluyen en
las revisiones según proceda.
2. Revisar los resultados de la recogida y del análisis de las medidas
para controlar el proyecto.
Las mediciones revisadas pueden incluir medidas de la
satisfacción del cliente.
ANÁLISIS, y proporCIONAR los rESULTADOS de LA medición, consúltese el árEA
de proceso Medición y Análisis.
3. Identificar y documentar las cuestiones y las desviaciones
significativas frente al plan.
4. Documentar las peticiones de cambio y los problemas
identificados en los productos de trabajo y en los procesos.
PARA más INFORMACIÓN sobre cómo seguir y contrOLAR los CAMBIOS, consúl-
tese el árEA de proceso Gestión de CONFIGURACIÓN.
5. Documentar los resultados de las revisiones.
6. Seguir las peticiones de cambio y los informes de problemas
hasta su cierre.
SP 1.7 llEvar a cabo las rEvisionEs dE hitos
Revisar los logros y los resultados delproyectoenloshitosseleccionadosdelproyecto.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR los hitos PRINCIPALES, consúltese LA
PRÁCTICA ESPECÍFICA ESTABLECER el presupuesto y el CALENDARIO en el árEA de proceso
PLANIFICACIÓN del Proyecto.
Los hitos son eventos o momentos preplanificados en los cuáles se
lleva a cabo una revisión minuciosa del estado para comprender
cómo se están cumpliendo los requisitos de las partes interesadas
(si el proyec- to incluye un hito en el desarrollo, entonces se lleva a
cabo la revisión para asegurar que se están cumpliendo los
supuestos y los requisitos asociados con ese hito). Los hitos
pueden estar asociados con el proyecto global o con un tipo o
caso de servicio particular. Los hitos, por lo tanto, pueden estar
basados en eventos o basados en el calendario.
Las revisiones de los hitos se planifican durante la planificación
del proyecto y normalmente son revisiones formales.
No es necesario que las revisiones de progreso y las
revisiones de hitos se realicen por separado. El propósito de
ambas revisiones se puede abordar en una única revisión. Por
ejemplo, una única revisión de replanificación puede evaluar el
progreso, las cuestiones y el rendimiento a lo largo de un
periodo de tiempo planificado (o hito) frente a las expectativas
del plan.
Dependiendo del proyecto, “el arranque del proyecto” y “el cierre
del proyecto” podrían ser fases cubiertas por revisiones de hitos.
1. Resultados documentados de las revisiones de hitos.
SUBPRÁCTICAS
1. Llevar a cabo las revisiones de hitos con las partes interesadas
relevantes en puntos significativos del calendario del proyecto,
como por ejemplo, a la finalización de las fases seleccionadas.
Los gerentes, el PERSONAL, los clientes, los USUARIOS FINALES, los proveedores
y OTRAS PARTES interESADAS rELEVANTES se incluyen en LAS revisiones de hitos
según prOCEDA.
2. Revisar los compromisos, el plan, el estado y los riesgos del proyecto.
4. Documentar los resultados de la revisión, los elementos de
acción y las decisiones.
5. Seguir los elementos de acción hasta su cierre.
SG 2 G eStionar laS accioneS correctivaS haSta Su cierre

Las acciones correctivas se gestionan hasta su cierre cuando el rendimiento o
los resultados del proyecto se desvían significativamente del plan.
SP 2.1 analizar las cuEstionEs

Recopilar y analizar las cuestiones y determinar acciones correctivas para su
tratamiento.

1. Lista de cuestiones que requieren acciones correctivas.
SUBPRÁCTICAS
1. Recopilar las cuestiones para su análisis.
PMC
Se rECOPILAN LAS cuestiones de LAS revisiones y de LA ejecución de otros
procesos.
Algunos ejemplos de cuestiones a recopilar son:

• Cuestiones descubiertas cuando se realizan las revisiones técnicas, la
verificación y la validación.
• Desviaciones significativas en los parámetros de planificación del
proyecto respecto a las estimaciones en el plan del proyecto.
• Compromisos (tanto internos como externos) que no se han cumplido.
• Cambios significativos en el estado de los riesgos.
• Cuestiones de acceso, recogida, privacidad o seguridad de los datos.
• Cuestiones de representación e involucración de las partes interesadas.
• Supuestos en la transición del entorno, de la herramienta o del
producto (u otros compromisos del cliente o del proveedor) que no se
han dado.
2. Analizar las cuestiones para determinar la necesidad de acciones
correctivas.
PARA más INFORMACIÓN sobre los criterios de LAS ACCIONES corrECTIVAS, con-
súltese LA PRÁCTICA ESPECÍFICA ESTABLECER el presupuesto y el CALENDARIO del
Se requieren acciones correctivas cuando la cuestión, si se deja
sin resolver, puede impedir al proyecto satisfacer sus objetivos.
SP 2.2 llEvar a cabo las accionEs corrEctivas

Llevar a cabo la acción correctiva sobre las cuestiones identificadas.

1. Planes de acciones correctivas.
SUBPRÁCTICAS
1. Determinar y documentar las acciones apropiadas necesarias
para tratar las cuestiones identificadas.
PARA más INFORMACIÓN sobre cómo DESARrOLLAR un PLAN de proyecto, con-
súltese el árEA de proceso PLANIFICACIÓN del Proyecto.
Algunos ejemplos de acciones potenciales son:

• Modificar la declaración del trabajo.
• Modificar los requisitos.
Continúa
Continuación
• Modificar las estimaciones y los planes.
• Renegociar los compromisos.
• Añadir recursos.
• Cambiar los procesos.
• Modificar los riesgos del proyecto.
2. Revisar y obtener acuerdos con las partes interesadas relevantes
sobre las acciones a tomar.
3. Negociar los cambios a los compromisos internos y externos.
SP 2.3 gEstionar las accionEs corrEctivas

Gestionar las acciones correctivas hasta su cierre.

1. Resultados de las acciones correctivas.
SUBPRÁCTICAS
1. Monitorizar las acciones correctivas hasta su finalización.
2. Analizar los resultados de las acciones correctivas para
determinar su eficacia.
3. Determinar y documentar las acciones apropiadas para corregir
las desviaciones producidas en los resultados planificados
debido a las acciones correctivas realizadas.
Las lecciones aprendidas como resultado de tomar acciones
correctivas pueden ser entradas a los procesos de planificación
y de gestión de riesgos.
planiFicación del proYecto

propósito
PP
El propósito de la Planificación del Proyecto (PP) es establecer y
mantener planes que definan las actividades del proyecto.
Una de las claves para gestionar eficazmente un proyecto es la
plani- ficación del proyecto. El área de proceso Planificación del
Proyecto implica las siguientes actividades:
 Desarrollar el plan de proyecto.
 Interactuar de forma apropiada con las partes
 Obtener el compromiso con el plan.
 Mantener el plan.
La planificación incluye la estimación de los atributos de los

productos de trabajo y de las tareas, la determinación de los
recursos necesarios, la negociación de los compromisos, la
elaboración de un calendario, y la identificación y el análisis de
los riesgos del proyecto. Para establecer el plan de proyecto,
puede ser necesario realizar iteraciones de estas actividades. El
plan de proyecto proporciona la base para realizar y controlar las
actividades del proyecto que abordan los compromisos con el
cliente del proyecto (véase la definición de “proyecto” en el
glosario).
El plan de proyecto se modifica generalmente a medida que el
proyecto progresa, para abordar los cambios en los requisitos
y en los compromisos, las estimaciones inexactas, las acciones
correctivas y los cambios a los procesos. Este área de proceso
contiene las prácticas es- pecíficas que describen tanto la
planificación como la replanificación. El término “plan de
proyecto” se usa a lo largo de este área de proceso para referirse al
plan global para controlar el proyecto. El plan de proyecto puede
ser un documento independiente o puede estar distribuido en
múltiples documentos. En cualquier caso, debería incluirse una
imagen coherente de quién hace qué. Igualmente, la monitorización
403
y el control pueden ser centralizados o distribuidos, siempre y
cuando a nivel de proyecto sea posible mantener una imagen
coherente del estado del proyecto.
Para líneas de producto, existen múltiples conjuntos de actividades de tra-

bajo que se beneficiarían de las prácticas de este área de proceso. Estas
actividades de trabajo incluyen la creación y el mantenimiento de los acti-
vos base, el desarrollo de productos que se construirán usando los activos
base, y la orquestación del esfuerzo total de la línea de producto para dar
soporte y coordinar las operaciones de los grupos de trabajo interrelacio-
nados y sus actividades.
En entornos ágiles, llevar a cabo un desarrollo incremental implica la pla-

nificación, la monitorización, el control y la replanificación más frecuen-
temente que en entornos más tradicionales de desarrollo. Mientras que
normalmente se establece un plan de alto nivel para el proyecto global o el
esfuerzo de trabajo los equipos estimarán, planificarán y llevarán a cabo el
trabajo real de un incremento o iteración a la vez. Los equipos normalmen-
te no pronostican más allá de lo que saben sobre el proyecto o iteración,
excepto para anticipar riesgos, eventos importantes, e influencias y limita-
ciones de gran escala. Las estimaciones reflejan los factores específicos de
la iteración y del equipo que influyen en el plazo, el esfuerzo, los recursos
y los riesgos para realizar la iteración. Los equipos planifican, monitorizan
y ajustan los planes en cada iteración tan a menudo como sea posible (p.
ej., diariamente). Los compromisos con los planes se manifiestan cuando
se asignan y aceptan las tareas durante la planificación de la iteración, se
elaboran o estiman las historias de usuario y se publican las iteraciones con
tareas de un backlog de trabajo (véase “Interpretando CMMI al utilizar en-
foques ágiles” en la Primera Parte).

cliente, del producto y de los componentes de producto, consúltese el árEA de pro-
ceso DESARrollo de Requisitos.
PARA más INFORMACIÓN sobre cómo SELECCIONAR, DISEÑAR e IMPLEMENTAR soluciones
A los requisitos, consúltese el árEA de proceso Solución TÉCNICA.
PARA más INFORMACIÓN sobre cómo ESPECIFICAR MEDIDAS, consúltese el árEA de pro-
ceso Medición y Análisis.
PARA más INFORMACIÓN sobre cómo GESTIONAR los requisitos, consúltese el árEA de
PARA más INFORMACIÓN sobre cómo IDENTIFICAR, ANALIZAR y MITIGAR los riesgos, con-
Planificación del proyecto 405

SG 1 Establecer las estimaciones.
SP 1.1 Estimar el alcance del proyecto.
SP 1.2 Establecer las estimaciones de los atributos de los productos de trabajo y de las
tareas.
SP 1.3 Definir las fases del ciclo de vida del proyecto.
SP 1.4 Estimar el esfuerzo y el coste.
SG 2 Desarrollar un plan de proyecto.
SP 2.1 Establecer el presupuesto y el calendario.
SP 2.2 Identificar los riesgos del proyecto.
SP 2.3 Planificar la gestión de los datos.
PP
SP 2.4 Planificar los recursos del proyecto.
SP 2.5 Planificar el conocimiento y las habilidades necesarias.
SP 2.6 Planificar la involucración de las partes interesadas.
SP 2.7 Establecer el plan de proyecto.
SG 3 Obtener el compromiso con el plan.
SP 3.1 Revisar los planes que afectan al proyecto.
SP 3.2 Conciliar los niveles de trabajo y de recursos.
SP 3.3 Obtener el compromiso con el plan.
SG 1 e Stablecer laS eStimacioneS

Se establecen y mantienen las estimaciones de los parámetros de planificación
del proyecto.
Los parámetros de la planificación del proyecto incluyen toda la

in- formación necesaria del proyecto para realizar la
planificación, la or- ganización, la asignación de personal, la
dirección, la coordinación, la comunicación y la preparación de
presupuestos necesarias.
Las estimaciones de los parámetros de planificación deberían
tener una base sólida para infundir la confianza en que los planes
basados en estas estimaciones son capaces de dar soporte a los
objetivos del proyecto.
Algunos factores a considerar cuando se estiman estos
parámetros son los requisitos del proyecto, incluyendo los
requisitos del producto, los requisitos impuestos por la
organización, los requisitos impuestos por el cliente y otros
requisitos que afectan al proyecto.
La documentación del análisis razonado de la estimación y de
los datos de soporte es necesaria para la revisión y el
compromiso con el plan de las partes interesadas, y para el
mantenimiento del plan a medida que el proyecto progresa.
SP 1.1 E stimar El alcancE dEl proyEcto
Establecer una estructura de descomposición del trabajo (WBS) de alto nivel
para estimar el alcance del proyecto.
La WBS evoluciona con el proyecto. Una WBS de alto nivel

puede servir para estructurar la estimación inicial. El desarrollo de
una WBS divide el proyecto global en un conjunto
interconectado de componentes manejables.
Normalmente, la WBS es un producto, producto de trabajo o
estructura orientada a tareas que proporciona un esquema para
identificar y organizar las unidades lógicas de trabajo a ser
gestionadas, las cuales se llaman “paquetes de trabajo”. La WBS
proporciona un mecanismo de referencia y de organización para
asignar el esfuerzo, el calendario y la responsabilidad, y se usa
como el marco básico para planificar, organizar y controlar el
trabajo realizado en el proyecto.
Algunos proyectos usan el término “WBS contractual” para
referirse a la parte de la WBS cubierta por el contrato
(posiblemente la WBS completa). No todos los proyectos tienen
una WBS contractual (p. ej., desarrollo financiado internamente).
1. Descripciones de las tareas.
2. Descripciones de los paquetes de trabajo.
3. WBS.
SUBPRÁCTICAS
1. Desarrollar una WBS.
La WBS proporciona un esquema para organizar el trabajo del
proyecto. La WBS debería permitir la identificación de los
siguientes elementos:
 Riesgos y sus tareas de mitigación.
 Tareas para los entregables y las actividades de soporte.
 Tareas para la adquisición de habilidades y conocimiento.
 Tareas para el desarrollo de planes de soporte necesarios, tales
como los planes de gestión de configuración, de
aseguramiento de la calidad y de verificación.
 Tareas para la integración y la gestión de elementos que no
son de desarrollo.
2. Definir los paquetes de trabajo con el detalle suficiente para que
se puedan especificar las estimaciones de las tareas, las
responsabilidades y el calendario del proyecto.
La WBS de alto nivel pretende ayudar a calibrar el esfuerzo de
trabajo del proyecto para las tareas y los roles y las
responsabilidades de la organización. El nivel de detalle en la
WBS en este nivel ayuda en el desarrollo de calendarios realistas,
con lo que se minimiza la necesidad de una reserva de gestión.
3. Identificar los productos y los componentes del producto a
adquirir externamente.
PARA más INFORMACIÓN sobre cómo GESTIONAR LA ADQUISICIÓN de productos
y de servicios de proveedores, consúltese el árEA de proceso Gestión de
Acuerdos con Proveedores.
4. Identificar los productos de trabajo a reutilizar.
SP 1.2 EstablEcEr las EstimacionEs dE los atributos dE los productos dE trabajo y dE las tarEas
Establecer y mantener las estimaciones de los atributos de los productos de tra-
bajo y de las tareas.
PP
El tamaño es la entrada principal para muchos modelos utilizados
para estimar el esfuerzo, el coste y el calendario. Los modelos
también pueden estar basados en otros atributos, tales como el
nivel de servicio, la conectividad, la complejidad, la
disponibilidad y la estructura.
Algunos ejemplos de atributos para estimar son:

• Número y complejidad de los requisitos.
• Número y complejidad de las interfaces.
• Volumen de los datos.
• Número de funciones.
• Puntos función.
• Líneas de código fuente.
• Número de clases y de objetos.
• Velocidad y complejidad del equipo.
• Número de páginas.
• Número de entradas y salidas.
• Número de elementos de riesgo técnico.
• Número de tablas en la base de datos.
• Número de campos en las tablas de datos.
• Elementos de la arquitectura.
• Experiencia de los participantes en el proyecto.
• Cantidad de código a reutilizar con respecto al código a crear.
• Número de puertas lógicas para circuitos integrados.
• Número de piezas (p. ej., circuitos impresos, componentes, piezas
mecánicas).
• Restricciones físicas (p. ej., peso, volumen).
• Distribución geográfica de los miembros del proyecto.
• Proximidad de clientes, de usuarios finales y de proveedores.
• Cómo de agradable o difícil es el cliente.
• Calidad y “limpieza” del código base existente.
Las estimaciones deberían ser consistentes con los requisitos
del proyecto para determinar el esfuerzo, el coste y el calendario
del proyecto. Para cada atributo de tamaño debería asignarse un
nivel relativo de dificultad o complejidad.

1. Tamaño y complejidad de las tareas y de los productos de trabajo.
2. Modelos de estimación.
3. Estimaciones de los atributos.
4. Aproximación técnica.
SUBPRÁCTICAS
1. Determinar la aproximación técnica para el proyecto.
La aproximación técnica define una estrategia de alto nivel para el
desarrollo del producto. Incluye las decisiones sobre las
características de la arquitectura, tales como estructura
distribuida o cliente/servi- dor; estado del arte o tecnologías
existentes para aplicarse, tales como robótica, materiales
compuestos o inteligencia artificial; y atributos de funcionalidad
y de calidad esperados en los productos finales, tales como
seguridad, protección y ergonomía.
2. Usar métodos apropiados para determinar los atributos de los
productos de trabajo y de las tareas a utilizar para estimar los
requisitos de recursos.
Los métodos para determinar el tamaño y la complejidad
deberían basarse en modelos validados o datos históricos.
Los métodos para determinar los atributos evolucionan a medida
que se incrementa la comprensión acerca de la relación entre las
caracte- rísticas del producto y los atributos.
3. Estimar los atributos de los productos de trabajo y de las tareas.
Algunos ejemplos de productos de trabajo para los cuales se calculan esti-

maciones de tamaño son:
• Productos de trabajo entregables y no entregables.
• Documentos y ficheros.
• Hardware, firmware y software operacional y de soporte.
SP 1.3 dEfinir las fasEs dEl ciclo dE vida dEl proyEcto

Definir las fases del ciclo de vida del proyecto sobre las que encuadrar el es-
fuerzo a planificar.
La determinación de las fases del ciclo de vida del proyecto

proporciona periodos planificados de evaluación y de toma de
decisiones. Estos periodos normalmente se definen para dar soporte
a los puntos lógicos de deci- sión, en los cuales se determina la
conveniencia de la confianza continua sobre el plan y la estrategia
del proyecto, y se realizan los compromisos
significativos en relación a los recursos. Dichos puntos proporcionan
eventos planificados en los que se pueden realizar correcciones
sobre el curso del proyecto y determinaciones de futuros alcances y
costes.
Comprender el ciclo de vida del proyecto es crucial para
determinar el alcance del esfuerzo de planificación y el
calendario de la pla- nificación inicial, así como el calendario y
los criterios (hitos críticos) para la replanificación.
Las fases del ciclo de vida del proyecto necesitan definirse
dependiendo del alcance de los requisitos, de las estimaciones
de recursos del proyecto y de la naturaleza del proyecto. Los
proyectos más grandes pueden contener múltiples fases, tales
como exploración del concepto, desarrollo, producción,
PP
operación y retirada. Dentro de estas fases, pueden ser necesarias
subfases. Una fase de desarrollo puede incluir subfases tales
como el análisis de los requisitos, el diseño, la fabricación, la
integración y la verificación. La determinación de las fases del
proyecto normalmente incluye la selección y el refinamiento de
uno o más modelos de desarrollo, para abordar las
interdependencias y la secuenciación apropiada de las actividades
en las fases.
Dependiendo de la estrategia para el desarrollo, pueden existir fa-
ses intermedias para la creación de prototipos, incrementos de capa-
cidad o ciclos de modelo en espiral. Además, pueden incluirse fases
explícitas para el ‘arranque del proyecto’ y el ‘cierre del proyecto’.

1. Fases del ciclo de vida del proyecto.
SP 1.4 Estimar El EsfuErzo y El costE
Estimar el esfuerzo y el coste del proyecto para los productos de trabajo y para
las tareas, basándose en el análisis razonado de la estimación.
Las estimaciones de esfuerzo y de coste generalmente están

basadas en los resultados del análisis usando modelos o datos
históricos aplicados al tamaño, actividades y otros parámetros de
la planificación. La confianza en estas estimaciones está basada
en el análisis razonado sobre el modelo seleccionado y la
naturaleza de los datos. Pueden existir ocasiones donde los datos
históricos disponibles no se puedan aplicar, tales como cuando los
esfuerzos no tengan precedentes o cuando el tipo de tarea no se
ajuste a los modelos disponibles. Por ejemplo, puede
considerarse que un esfuerzo no tiene precedente si la
organización no tiene experiencia con dicho producto o tarea.
Los esfuerzos que no tienen precedentes tienen mayor riesgo, re-
quieren más investigación para desarrollar bases razonables de
estima- ción, y requieren más reservas de gestión. La singularidad
del proyecto debería documentarse cuando se usen estos modelos
para asegurar una comprensión común de cualquier suposición
hecha en las fases iniciales de la planificación.
1. Análisis razonado de la estimación.
2. Estimaciones del esfuerzo del proyecto.
3. Estimaciones del coste del proyecto.
SUBPRÁCTICAS
1. Recopilar los modelos o los datos históricos a utilizar para
transformar los atributos de los productos de trabajo y de las
tareas en estimaciones de horas de trabajo y de coste.
Se han desarrollado muchos modelos paramétricos para ayudar a
estimar el coste y el calendario. No se recomienda el uso de
estos modelos como fuente única de estimación, porque están
basados en datos históricos de proyectos que pueden o no ser
pertinentes al proyecto. Pueden utilizarse múltiples modelos y
métodos para asegurar un alto nivel de confianza en la
estimación.
Los datos históricos deberían incluir los datos de coste, de
esfuerzo y de calendario de proyectos ejecutados previamente
y datos apropiados del escalado para explicar diferencias en
tamaños y complejidad.
2. Incluir las necesidades de la infraestructura de soporte al
estimar el esfuerzo y el coste.
La infraestructura de soporte incluye los recursos necesarios
desde una perspectiva de desarrollo y de mantenimiento del
producto.
Cuando estime el esfuerzo y el coste, considere las necesidades
de recursos de infraestructura en el entorno de desarrollo, en el
entorno de prueba, en el entorno de producción, en el entorno
operativo, o en cualquier combinación apropiada de estos
entornos.
Algunos ejemplos de recursos de infraestructura son:

• Recursos críticos del ordenador (p. ej., memoria, capacidad en disco y
de red, periféricos, canales de comunicación, las capacidades de estos
recursos).
• Entornos y herramientas de ingeniería (p. ej., herramientas para
prototipado, pruebas, integración, ensamblaje, diseño asistido por
ordenador [CAD], simulación).
• Instalaciones, maquinaria y equipamiento (p. ej., bancos de pruebas,
dispositivos de grabación).
3. Estimar el esfuerzo y el coste usando modelos, datos históricos, o

una combinación de ambos.
Algunos ejemplos de información de entrada de esfuerzo y de coste usada

normalmente para estimar son:
• Estimaciones proporcionadas por un experto o grupo de expertos (p. ej.,
método Delphi, el juego de planificación de la Programación Extrema).
• Riesgos, incluyendo hasta qué punto el esfuerzo no tiene precedentes.
• Competencias y roles críticos necesarios para realizar el trabajo.
• Viajes.
• WBS.
• Modelo de ciclo de vida del proyecto y procesos seleccionados.
• Estimaciones de coste del ciclo de vida.
PP
• Niveles de habilidad de los gerentes y del personal necesario para
realizar el trabajo.
• Necesidades de conocimiento, de habilidades y de formación.
• Mano de obra directa y gastos indirectos.
• Acuerdos de servicio para centros de atención al cliente y garantía.
• Nivel de seguridad requerido para las tareas, productos de trabajo,
hardware, software, personal y entorno de trabajo.
• Instalaciones necesarias (p. ej., oficinas y espacios de reunión y
estaciones de trabajo).
• Requisitos del producto y de los componentes de producto.
• Estimaciones de tamaño de los productos de trabajo, de las tareas y de
los cambios anticipados.
• Coste de los productos adquiridos externamente.
• Capacidad de los procesos de fabricación.
• Instalaciones de ingeniería necesarias.
• Capacidad de las herramientas proporcionadas en el entorno de
ingeniería.
• Aproximación técnica.
SG 2 d eSarrollar un Plan de Proyecto

Se establece y mantiene un plan de proyecto como base para gestionar el
proyecto.
Un plan de proyecto es un documento formal y aprobado,

utilizado para gestionar y controlar la ejecución del proyecto. Está
basado en los requisitos del proyecto y en las estimaciones
establecidas.
El plan de proyecto debería considerar todas las fases del
ciclo de vida del proyecto. La planificación del proyecto debería
asegurar que todos los planes que afectan al proyecto sean
consistentes con el plan global del proyecto.
SP 2.1 EstablEcEr El prEsupuEsto y El calEndario
Establecer y mantener el presupuesto y el calendario del proyecto.
El presupuesto y el calendario del proyecto están basados en las
estimaciones desarrolladas y aseguran que se abordan
adecuadamente la asignación del presupuesto, la complejidad de
las tareas y las dependencias entre las mismas.
Los calendarios orientados a eventos y con limitación de
recursos han demostrado ser eficaces para gestionar el riesgo
del proyecto. La identificación de los resultados a demostrar antes
del inicio de un evento proporciona flexibilidad en los plazos del
evento, una com- prensión común de lo que se espera, una mejor
visión del estado del proyecto y un estado más preciso de las
tareas del proyecto.
1. Calendarios del proyecto.
2. Dependencias del calendario.
3. Presupuesto del proyecto.
SUBPRÁCTICAS
1. Identificar los principales hitos.
Los hitos son eventos o momentos pre-planificados en los cuales
se realiza una revisión cuidadosa del estado para comprender el
grado de cumplimiento de los requisitos de las partes interesadas
(si el proyecto incluye un hito de desarrollo, entonces la revisión se
realiza para asegurar que se cumplen los supuestos y los
requisitos asociados con ese hito). Los hitos pueden estar
asociados al proyecto global o a un tipo o instancia de servicio
particular. Así, los hitos pueden estar basados en eventos o en el
calendario. Si están basados en el calendario, una vez que han sido
acordados, a menudo es difícil cambiar las fechas de los hitos.
2. Identificar los supuestos del calendario.
Cuando se desarrollan inicialmente los calendarios, es común
hacer supuestos sobre la duración de ciertas actividades. Estos
supuestos se hacen frecuentemente sobre elementos para los
cuales hay pocos datos de estimación disponibles. La
identificación de estos supuestos proporciona una visión sobre el
nivel de confianza (es decir, incertidumbres) en el calendario
global.
3. Identificar las restricciones.
Los factores que limitan la flexibilidad de las opciones de gestión
de- berían identificarse tan pronto como sea posible. El examen
de los atributos de los productos de trabajo y de las tareas a
menudo hace aflorar estas cuestiones a la superficie. Estos
atributos pueden incluir la duración de la tarea, los recursos, las
entradas y las salidas.
4. Identificar las dependencias entre las tareas.
Con frecuencia, las tareas de un proyecto o servicio pueden
ejecutarse en una secuencia ordenada que minimiza la duración.
Esta secuencia-
ción implica la identificación de las tareas predecesoras y
sucesoras para determinar la ordenación óptima.
Algunos ejemplos de herramientas y entradas que pueden ayudar a deter-

minar el orden óptimo de tareas son:
• Método del camino crítico (CPM).
• Técnica de evaluación y revisión de programa (PERT).
• Calendario limitado por recursos.
• Prioridades del cliente.
• Características de mercado.
PP
• Valor para el usuario final.
5. Establecer y mantener el presupuesto y el calendario.
El establecimiento y mantenimiento del presupuesto y del calendario del

proyecto normalmente incluye:
• Definir la disponibilidad comprometida o esperada de recursos e
instalaciones.
• Determinar la distribución temporal de las actividades.
• Determinar una descomposición de calendarios subordinados.
• Definir dependencias entre las actividades (relaciones predecesoras o
sucesoras).
• Definir las actividades y los hitos del calendario para dar soporte a la
monitorización y control del proyecto.
• Identificar los hitos, las entregas o los incrementos para la entrega de
los productos al cliente.
• Definir la duración apropiada de las actividades.
• Definir hitos con una separación apropiada de tiempo.
• Definir una reserva de gestión basada en el nivel de confianza de
cumplimiento del calendario y del presupuesto.
• Usar los datos históricos apropiados para verificar el calendario.
• Definir los requisitos incrementales de financiación.
• Documentar los supuestos del proyecto y su análisis razonado.
6. Establecer los criterios de las acciones correctivas.

Se establecen los criterios para determinar qué constituye una
desvia- ción significativa del plan de proyecto. Es necesaria una
base para calibrar las cuestiones y los problemas y así
determinar cuándo debería llevarse a cabo una acción correctiva.
Las acciones correctivas pueden conducir a la replanificación, la
cual puede incluir la corrección del plan original, el
establecimiento de nuevos acuerdos o la inclusión de actividades
de mitigación en el plan actual. El plan de proyecto define
cuándo (p. ej., bajo qué circunstancias, con qué frecuencia) y por
quién serán aplicados los criterios.
SP 2.2 idEntificar los riEsgos dEl proyEcto
Identificar y analizar los riesgos del proyecto.
PARA más INFORMACIÓN sobre LAS ACTIVIDADES de MONITORIZACIÓN de riesgos, con-
súltese LA PRÁCTICA ESPECÍFICA MONITORIZAR los riesgos del proyecto en el árEA de
proceso MONITORIZACIÓN y Control del Proyecto.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR prOBLEMAS POTENCIALES ANTES de que
ocurRAN, de MANERA que se PUEDAN PLANIFICAR e INVOCAR, según SEA NECESARIO, LAS
ACTIVIDADES PARA MANEJAR los riesgos A TRAVÉS de LA VIDA del producto o proyecto
PARA MITIGAR IMPACTOS ADVERSOS en el logro de los objetivos, consúltese el árEA de
proceso Gestión de Riesgos.
Los riesgos se identifican o descubren y se analizan para dar

soporte a la planificación del proyecto. Esta práctica específica
debería ampliar- se a todos los planes que afecten al proyecto
para asegurar que todas las partes interesadas relevantes están
interactuando adecuadamente sobre los riesgos identificados.
La identificación y el análisis de riesgos en la planificación del proyecto

normalmente incluyen:
• La identificación de los riesgos.
• El análisis de riesgos para determinar el impacto, la probabilidad de
ocurrencia y el marco temporal en el cual es probable que ocurran los
problemas.
• La priorización de los riesgos.

1. Riesgos identificados.
2. Impactos y probabilidad de ocurrencia de los riesgos.
3. Prioridades de los riesgos.
SUBPRÁCTICAS
1. Identificar los riesgos.
La identificación de los riesgos implica la identificación de
cuestiones potenciales, de peligros, de amenazas, de
vulnerabilidades, etc. que podrían afectar negativamente a los
esfuerzos y a los planes del trabajo. Los riesgos deberían
identificarse y describirse de forma comprensible antes de que
puedan analizarse y gestionarse apropiadamente. Cuando se
identifican los riesgos, una buena idea es usar un método
estándar para definirlos. Se pueden usar herramientas de
identificación y de análisis de riesgos para ayudar a identificar
posibles problemas.
Algunos ejemplos de herramientas de identificación y de análisis de ries-

gos son:
• Taxonomías de riesgos.
• Evaluaciones de riesgos.
• Listas de comprobación.
• Entrevistas estructuradas.
• Tormenta de ideas.
• Modelos de rendimiento del producto, del proyecto y del proceso.
• Modelos de coste.
• Análisis de red.
PP
• Análisis del factor de calidad.
2. Documentar riesgos.
3. Revisar y obtener el acuerdo con las partes interesadas relevantes
sobre la completitud y exactitud de los riesgos documentados.
4. Modificar los riesgos según sea apropiado.
Algunos ejemplos de cuándo los riesgos identificados pueden necesitar ser

modificados son:
• Cuando se identifican nuevos riesgos.
• Cuando los riesgos se convierten en problemas.
• Cuando desaparecen los riesgos.
• Cuando cambian las circunstancias del proyecto significativamente.
SP 2.3 planificar la gEstión dE los datos

Planificar la gestión de los datos del proyecto.
Los datos son formas de documentación requeridas para dar

soporte a un proyecto en todas sus áreas (p. ej., administración,
ingenie- ría, gestión de configuración, finanzas, logística,
calidad, protección, fabricación, adquisición). Los datos pueden
tomar cualquier forma (p.ej., informes, manuales, libretas,
gráficas, dibujos, especificaciones, ficheros, correspondencia).
Los datos pueden existir en cualquier medio (p.ej., impreso o
elaborado sobre diferentes materiales, fotografías, electrónico,
multimedia).
Los datos pueden ser entregables (p. ej., elementos
identificados por los requisitos de datos contractuales de un
proyecto) o no entregables (p. ej., datos informales, estudios de
mercado, análisis, actas de reuniones internas, documentación de
la revisión interna de diseños, lecciones aprendidas, elementos de
acción). La distribución puede tomar muchas formas,
incluyendo la transmisión electrónica.
Los requisitos de datos para el proyecto deberían establecerse
tan- to para elementos de datos a crear como para su contenido y
forma, basándose en un conjunto común o estándar de requisitos
de datos. Los requisitos de contenido y de formato uniformes
para los elementos de datos, facilitan la comprensión de su
contenido y ayudan a una gestión consistente de los recursos de
los datos.
La razón para recoger cada documento debería estar clara.
Esta tarea incluye el análisis y la verificación de los entregables y
no entregables del proyecto, los requisitos de datos y los datos
suministrados por el cliente. A menudo, los datos se recogen sin
una comprensión clara de cómo se usarán. Los datos son costosos
y deberían recogerse únicamente cuando se necesiten.
1. Plan para la gestión de datos.
2. Lista maestra de datos gestionados.
3. Contenido de datos y descripción del formato.
4. Listas de requisitos de datos para los compradores y los proveedores.
5. Requisitos de privacidad.
6. Requisitos de seguridad.
7. Procedimientos de seguridad.
8. Mecanismo para la recuperación, reproducción y distribución de
los datos.
9. Calendario para la recogida de datos del proyecto.
10. Listado de datos del proyecto a recoger.
SUBPRÁCTICAS
1. Establecer los requisitos y los procedimientos para asegurar la
privacidad y la seguridad de los datos.
No todo el mundo tendrá la necesidad o acreditación necesaria
para acceder a los datos del proyecto. Los procedimientos
deberían establecerse para identificar quién tiene acceso a qué
datos, así como cuándo tienen acceso a qué datos.
2. Establecer un mecanismo para almacenar los datos y acceder a
los datos almacenados.
La información a la que se accede debería estar en una forma
comprensible (p. ej., una salida electrónica o lógica desde una
base de datos) o representada como fue originalmente generada.
3. Determinar los datos del proyecto que serán identificados,
recogidos y distribuidos.
4. Determinar los requisitos para proporcionar el acceso a los datos
y su distribución a las partes interesadas relevantes.
Una revisión de otros elementos del plan de proyecto puede
ayudar a determinar quién requiere acceso a los datos del
proyecto o a su recepción, así como qué datos están implicados.
5. Decidir qué datos y planes del proyecto requieren control de
versión u otros niveles de control de configuración y establecer
mecanismos para asegurar que los datos del proyecto se
controlan.
SP 2.4 planificar los rEcursos dEl proyEcto

Planificar los recursos para realizar el proyecto.
La definición de los recursos del proyecto (p. ej., trabajo,

equipamien- to, materiales, métodos) y las cantidades necesarias
para realizar las actividades del proyecto se basan en las
estimaciones iniciales y proporciona información adicional que
PP
puede aplicarse para extender la WBS usada para gestionar el
proyecto.
La WBS de alto nivel, desarrollada en etapas tempranas como
un mecanismo de estimación, normalmente se expande
descomponiendo estos niveles más altos en paquetes de trabajo,
que representan unidades de trabajo únicas que se pueden
asignar, realizar y seguir separa- damente. Esta subdivisión se
hace para distribuir la responsabilidad de gestión y proporcionar
un mejor control de gestión.
Cada paquete de trabajo en la WBS debería tener asignado un
identificador único (p. ej., un número) para permitir su
seguimiento. Una WBS puede basarse en requisitos, actividades,
productos de trabajo, servicios o una combinación de estos
elementos. Un diccionario que describa el trabajo para cada
paquete de trabajo en la WBS debería acompañar a la WBS.
1. Paquetes de trabajo.
2. Diccionario de tareas de la WBS.
3. Requisitos de personal basados en el tamaño y en el alcance del
proyecto.
4. Lista de instalaciones y equipamiento críticos.
5. Definiciones y diagramas del proceso y del flujo de trabajo.
6. Lista de requisitos de administración del proyecto.
7. Informes de estado.
SUBPRÁCTICAS
1. Determinar los requisitos del proceso.
Los procesos usados para gestionar un proyecto se identifican,
definen y coordinan con todas las partes interesadas relevantes
para asegurar operaciones eficientes durante la ejecución del
proyecto.
2. Determinar los requisitos de comunicación.
Estos requisitos abordan los tipos de mecanismos a utilizar para
la comunicación con los clientes, los usuarios finales, el personal
del proyecto y otras partes interesadas relevantes.
3. Determinar los requisitos de personal.
El personal de un proyecto depende de la descomposición de los
requisitos del proyecto en tareas, roles y responsabilidades para
cumplir los requisitos del proyecto según lo dispuesto en los paquetes
de trabajo de la WBS.
Los requisitos de personal deberían considerar el conocimiento y las
habilidades requeridas para cada puesto identificado, según lo
definido en la práctica específica Planificar el conocimiento y las
habilidades necesarias.
4. Determinar los requisitos de instalaciones, equipamiento y
componentes. La mayoría de proyectos de alguna forma son
únicos y requieren un conjunto de activos únicos para lograr los
objetivos del proyecto. La
determinación y la adquisición oportuna de estos activos son
cruciales para el éxito del proyecto.
Es mejor identificar lo antes posible los elementos con plazo de
entrega para determinar cómo serán tratados. Incluso cuando
los activos requeridos no son únicos, la recopilación de una lista
de todas las instalaciones, equipamiento y piezas (p. ej., número
de ordenadores para el personal que trabaja en el proyecto,
aplicaciones software, espacio de oficina) proporciona una visión
más profunda sobre aspectos del alcance de un esfuerzo que a
menudo se pasan por alto.
5. Determinar otros requisitos de recursos continuos.
Más allá de determinar los procesos, las plantillas de los
informes, el personal, las instalaciones y el equipamiento, puede
existir una necesidad continua de otros tipos de recursos para
llevar a cabo las actividades del proyecto de manera eficaz,
incluyendo:
 Consumibles (p. ej., electricidad, material de oficina).
 Acceso a la propiedad intelectual.
 Acceso al transporte (para personas y equipamiento).
Los requisitos para dichos recursos se derivan de los requisitos
establecidos en (existentes y futuros) los acuerdos (p. ej.,
acuerdos con el cliente, acuerdos de servicio, acuerdos con el
proveedor), la aproxi- mación estratégica del proyecto, y la
necesidad de gestionar y mantener las operaciones del proyecto
por un período de tiempo.
SP 2.5 planificar El conocimiEnto y las habilidadEs nEcEsarias

Planificar las necesidades de conocimiento y de habilidades para realizar el proyecto.
PARA más INFORMACIÓN sobre cómo DESARrOLLAR el conocimiento y LAS HABILIDADES
de LAS PERSONAS PARA que PUEDAN DESEMPEÑAR sus roles de FORMA EFICAZ y eficiente,
consúltese el árEA de proceso FORMACIÓN de LA OrGANIZACIÓN.
La entrega de conocimiento a los proyectos implica formación del

personal del proyecto y adquisición de conocimiento desde
fuentes externas.
Los requisitos de personal dependen del conocimiento y de las
habilidades disponibles para dar soporte a la ejecución del
proyecto.
1. Inventario de habilidades necesarias.
2. Planes de personal y de nuevas contrataciones.
3. Bases de datos (p. ej., habilidades, formación).
4. Planes de formación.
SUBPRÁCTICAS
1. Identificar el conocimiento y las habilidades necesarios para
realizar el proyecto.
2. Evaluar el conocimiento y las habilidades disponibles.
3. Seleccionar los mecanismos para proporcionar el conocimiento
PP
y las habilidades necesarias.
Algunos ejemplos de mecanismos son:

• Formación interna (tanto de la organización como del proyecto).
• Formación externa.
• Personal y nuevas contrataciones.
• Adquisición externa de habilidades.
La opción de formación interna o formación subcontratada para

el conocimiento y las habilidades necesarias se determina por la
disponibilidad de experiencia en formación, el calendario del
proyecto y los objetivos de negocio.
4. Incorporar los mecanismos seleccionados en el plan de proyecto.
SP 2.6 planificar la involucración dE las partEs intErEsadas
Planificar la involucración de las partes interesadas identificadas.
Las partes interesadas se identifican en todas las fases del ciclo de

vida del proyecto mediante la identificación de personas y
funciones que deberían estar representadas en el proyecto y
mediante la descripción de su importancia y del grado de
interacción con las actividades del proyecto. Un formato
conveniente para lograr esta identificación, es una matriz
bidimensional con las partes interesadas en un eje y las
actividades del proyecto en el otro. La relevancia de la parte
interesada con la actividad en una fase particular del proyecto y
la cantidad de interacción esperada deberían mostrarse en la
intersección del eje de la actividad de la fase del proyecto y el eje
de la parte interesada.
Para que sea útil la información de entrada de las partes interesa-
das, es necesario seleccionarlas cuidadosamente. Para cada
actividad principal, identifique a las partes interesadas que están
afectadas por ésta y a aquellos quienes tienen la experiencia
necesaria para llevar- la a cabo. Esta lista de partes interesadas
relevantes probablemente cambiará a medida que el proyecto
avance durante las fases del ciclo de vida del proyecto. Sin
embargo, es importante asegurar que en las
últimas fases del ciclo de vida las partes interesadas relevantes
tengan información de entrada lo antes posible acerca de los
requisitos y de las decisiones de diseño que les afecten.
Algunos ejemplos del tipo de contenido que se debería incluir en un plan

para la interacción con las partes interesadas son:
• Lista de todas las partes interesadas relevantes.
• La razón fundamental para la involucración de las partes interesadas.
• Relaciones entre las partes interesadas.
• Recursos (p. ej., formación, materiales, tiempo, financiación) necesarios
para asegurar la interacción de las partes interesadas.
• Calendario para dividir por fases la interacción de las partes
interesadas.
• Roles y responsabilidades de las partes interesadas relevantes con
respecto al proyecto, por fase del ciclo de vida del proyecto.
• Importancia relativa de las partes interesadas para el éxito del
proyecto, por fase del ciclo de vida del proyecto.
La implementación de esta práctica específica se basa en
compartir o intercambiar información con la práctica específica
previa de Plani- ficar el conocimiento y las habilidades
necesarias.

1. Plan para la involucración de las partes interesadas.
SP 2.7 EstablEcEr El plan dE proyEcto
Establecer y mantener el plan global del proyecto.
Para alcanzar la comprensión y el compromiso mutuos de los

individuos, grupos y organizaciones que ejecutan o dan soporte a
los planes, es necesario un plan documentado que aborde todos
los elementos relevantes de planificación.
El plan generado para el proyecto define todos los aspectos
de esfuerzo, uniendo lo siguiente de manera lógica:
 Consideraciones sobre el ciclo de vida del proyecto.
 Tareas del proyecto.
 Presupuestos y calendarios.
 Hitos.
 Gestión de datos.
 Identificación de riesgos.
 Requisitos de recursos y de habilidades.
 Identificación e interacción de las partes interesadas.
 Consideraciones de infraestructura.
Las consideraciones de infraestructura incluyen relaciones de
responsabilidad y de autoridad para el personal del proyecto, la
gerencia y las organizaciones de soporte.
Las consideraciones sobre el ciclo de vida pueden incluir la
cobertura de fases posteriores de la vida del producto o del
servicio (que podría estar más allá de la vida del proyecto),
especialmente la transi- ción a otra fase o parte (p. ej., transición a
fabricación, a formación, a operaciones, a un proveedor de
servicio).
Para el software, el documento de planificación a menudo se refiere como:
PP
• Plan de desarrollo del software.
• Plan de proyecto del software.
• Plan del software.
Para el hardware, el documento de planificación a menudo se refiere como

el plan de desarrollo del hardware. Las actividades de desarrollo en la pre-
paración para la producción se pueden incluir en el plan de desarrollo del
hardware o pueden definirse en un plan de producción separado.
Algunos ejemplos de planes que han sido usados por la comunidad del De-
partamento de la Defensa de los Estados Unidos de Norteamérica son:
• Plan Maestro Integrado: un plan dirigido por eventos que documenta
los logros significativos con criterios de aprobación/fallo tanto para los
elementos del negocio como para los elementos técnicos del proyecto,
y que relaciona cada logro con un evento clave del proyecto.
• Calendario Maestro Integrado: un calendario multi-capa integrado y en
red de tareas del proyecto requeridas para completar el esfuerzo del
trabajo documentado en un Plan Maestro Integrado relacionado.
• Plan de Gestión de Ingeniería de Sistemas: un plan que detalla el
esfuerzo técnico integrado durante el proyecto.
• Calendario Maestro de Ingeniería en Sistemas: un calendario basado
en eventos que contiene una recopilación de los logros técnicos clave,
cada uno con criterios medibles, que requieren la finalización con éxito
para aprobar los eventos identificados.
• Calendario Detallado de Ingeniería de Sistemas: un calendario
detallado, que depende del tiempo y está orientado a tareas, que asocia
fechas e hitos con el Calendario Maestro de Ingeniería de Sistemas.

1. Plan global del proyecto.
SG 3 o btener el comPromiSo con el Plan
Se establecen y mantienen los compromisos con el plan de proyecto.
Para ser eficaces, los planes requieren el compromiso de aquellos
que son responsables de implementar y dar soporte al plan.
SP 3.1 rEvisar los planEs quE afEctan al proyEcto
Revisar todos los planes que afectan al proyecto para comprender los compro-
misos del proyecto.
Los planes desarrollados en otras áreas de proceso normalmente

contienen información similar a la referenciada en el plan
global del proyecto. Estos planes pueden proporcionar una
orientación detallada adicional y deberían ser compatibles y dar
soporte al plan global del proyecto, para indicar quién tiene la
autoridad, la responsabilidad, la contabilidad y el control. Todos
los planes que afectan al proyecto de- berían revisarse para
asegurar que contienen una comprensión común del alcance,
objetivos, roles y relaciones que son requeridas para que el
proyecto tenga éxito. Muchos de estos planes se describen en la
práctica genérica Planificar el proceso.

1. Registro de las revisiones de los planes que afectan al proyecto.
SP 3.2 conciliar los nivElEs dE trabajo y dE rEcursos
Ajustar el plan de proyecto para conciliar los recursos disponibles y los
estimados.
Para establecer un proyecto que sea factible, obtenga el

compromiso de las partes interesadas relevantes y concilie las
diferencias entre los recursos estimados y los disponibles. La
conciliación normalmente se logra modificando o aplazando los
requisitos, negociando más recursos, encontrando formas de
incrementar la productividad, subcontratando, ajustando la
mezcla de las habilidades del personal, o modificando todos los
planes que afectan al proyecto o a sus calendarios.

1. Métodos y parámetros de estimación correspondientes
modificados (p. ej., mejores herramientas, uso de productos
comerciales).
2. Presupuestos renegociados.
3. Calendarios modificados.
4. Lista de requisitos modificada.
5. Acuerdos renegociados con las partes interesadas.
SP 3.3 obtEnEr El compromiso con El plan
Obtener el compromiso de las partes interesadas relevantes responsables de
realizar y de dar soporte a la ejecución del plan.
Obtener el compromiso implica la interacción entre todas las par-

tes interesadas relevantes, tanto internas como externas al
proyecto. El individuo o grupo que adquiere un compromiso
debería tener la confianza de que el trabajo puede realizarse
dentro de las restricciones de coste, de calendario y de
rendimiento. A menudo, resulta adecuado adquirir un
compromiso de forma provisional para empe- zar a trabajar y
posteriormente investigar con objeto de aumentar la confianza
PP
hasta el nivel adecuado necesario para obtener un compromiso
definitivo.

1. Peticiones de compromisos documentadas.
2. Compromisos documentados.
SUBPRÁCTICAS
1. Identificar el soporte necesario y negociar los compromisos con
La WBS puede usarse como una lista de comprobación para
asegurar que se obtienen los compromisos para todas las tareas.
El plan para la interacción con las partes interesadas debería
identificar todas las partes de las que se debería obtener el
compromiso.
2. Documentar todos los compromisos de la organización, tanto
de- finitivos como provisionales, asegurando el nivel apropiado
de firmantes.
Los compromisos deberían documentarse para asegurar una
com- prensión mutua consistente y para el seguimiento y
mantenimiento del proyecto. Los compromisos provisionales
deberían acompañarse de una descripción de los riesgos
asociados.
3. Revisar los compromisos internos con la alta dirección según
sea apropiado.
4. Revisar los compromisos externos con la alta dirección según
sea apropiado.
La dirección puede tener la visión y la autoridad necesarias para
reducir los riesgos asociados a los compromisos externos.
5. Identificar los compromisos relacionados con las interfaces entre
los elementos del proyecto y otros proyectos y unidades de la
organiza- ción, de tal forma que estos compromisos puedan ser
monitorizados.
Las especificaciones de interfaces bien definidas forman la base
para los compromisos.
aSeguraMiento de la calidad del proceSo Y del

producto
un área de proceso de Soporte en el nivel de madurez 2
propósito
El propósito del Aseguramiento de la Calidad del Proceso y del
Pro- ducto (PPQA) es proporcionar al personal y a la gerencia
una visión objetiva de los procesos y de los productos de trabajo
asociados.
PPQA
El área de proceso de Aseguramiento de la Calidad del Proceso y
del Producto implica las siguientes actividades:
 Evaluar objetivamente los procesos realizados y los
productos de trabajo frente a las descripciones de proceso, los
estándares y los procedimientos aplicables.
 Identificar y documentar las no conformidades.
 Proporcionar realimentación al personal del proyecto y a los
gerentes sobre los resultados de las actividades de
aseguramiento de la calidad.
 Asegurar que se tratan las no conformidades.
El área de proceso de Aseguramiento de la Calidad del
Proceso y del Producto da soporte a la entrega de productos de
alta calidad, proporcionando al personal del proyecto y a los
gerentes, en todos los niveles, la visibilidad apropiada y la
realimentación sobre los procesos y los productos de trabajo
asociados, durante toda la vida del proyecto.
Las prácticas en el área de proceso de Aseguramiento de la
Calidad del Proceso y del Producto aseguran que los procesos
planificados se implementan, mientras que las prácticas en el área
de proceso de Veri- ficación aseguran que se satisfacen los
requisitos especificados. Estas dos áreas de proceso pueden en
ocasiones tratar los mismos productos de trabajo, pero desde
diferentes perspectivas. Los proyectos deberían aprovechar este
solapamiento para minimizar la duplicación de esfuerzos,
aunque cuidándose de mantener perspectivas separadas.
La objetividad en las evaluaciones de aseguramiento de la
calidad del proceso y del producto es crítica para el éxito del
proyecto (véase la definición de “evaluar objetivamente” en el
glosario). La objetividad
425
se logra tanto por la independencia como por la utilización de
criterios. Frecuentemente, se usa una combinación de métodos
que proporcionan evaluaciones frente a criterios de quienes no
producen el producto de trabajo. Se pueden utilizar métodos
menos formales para proporcionar una amplia cobertura del día a
día. Se pueden utilizan métodos más formales periódicamente
para asegurar la objetividad.
Algunos ejemplos de formas para realizar evaluaciones objetivas son:

• Auditorías formales realizadas por organizaciones de aseguramiento
de la calidad separadas desde el punto de vista organizativo.
• Revisiones entre pares que pueden realizarse con varios niveles de
formalidad.
• Revisión en profundidad del trabajo en el lugar donde se realiza (es
decir, auditorías “de escritorio”).
• Revisiones y comentarios distribuidos de productos de trabajo.
• Comprobaciones de proceso integradas en los procesos, tales como a
prueba de fallos, cuando se hacen incorrectamente (p. ej., Poka-Yoke).
Tradicionalmente, un grupo de aseguramiento de la calidad
que es independiente del proyecto proporciona objetividad. Sin
embargo, otro enfoque podría ser apropiado en algunas
organizaciones para implementar el rol de aseguramiento de la
calidad del proceso y del producto sin ese tipo de
independencia.
Por ejemplo, en una organización con una cultura abierta, orientada a la

calidad, el rol de aseguramiento de la calidad del proceso y del producto
puede realizarse, parcial o completamente, entre pares; y la función de ase-
guramiento de la calidad puede embeberse en el proceso. Para organizacio-
nes pequeñas, esta aproximación podría ser la más viable.
Si el aseguramiento de la calidad está embebido en el
proceso, se deberían tratar varias cuestiones para garantizar la
objetividad. Todos los que realicen actividades de aseguramiento
de la calidad deberían estar formados en aseguramiento de la
calidad. Aquellos que realicen actividades de aseguramiento de la
calidad para un producto de trabajo deberían estar separados de
los que están directamente involucrados en el desarrollo o
mantenimiento del producto de trabajo. Se debería disponer de
un canal independiente para informar, al nivel apropiado de
gerencia de la organización, de tal manera que se puedan escalar
las no conformidades según sea necesario.
Por ejemplo, cuando se implementan revisiones entre pares como un mé-

todo objetivo de evaluación, se deberían tratar las siguientes cuestiones:
• Los miembros están formados y se asignan roles a las personas que
realizan la revisión entre pares.
• Un miembro de la revisión entre pares que no haya generado este producto
de trabajo se asigna para realizar el rol de aseguramiento de la calidad.
Continúa
Aseguramiento de la calidad del proceso y del producto 427
Continuación
• Las listas de comprobación basadas en descripciones de proceso,
estándares y procedimientos están disponibles, para dar soporte a la
actividad de aseguramiento de la calidad.
• Las no conformidades se registran como parte del informe de la
revisión entre pares, y se siguen y escalan fuera del proyecto cuando
sea necesario.
El aseguramiento de la calidad debería comenzar en las fases
tempranas de un proyecto para establecer los planes, los procesos,
los estándares y los procedimientos que aportarán valor al proyecto
y satisfarán sus requisitos y las políticas de la organización.
Aquellos que realizan las actividades de aseguramiento de la
calidad participan en el establecimiento de los planes, procesos,
estándares y procedimientos, para asegurar que éstos se ajustan a las
necesidades del proyecto y que serán utilizables para realizar las
evaluaciones de aseguramiento de la calidad. Adicionalmente, se
designan los procesos y los productos de trabajo asociados que
serán evaluados durante el proyecto. Esta designación puede basarse
en mues- treos o en criterios objetivos que sean consistentes con las
políticas de la organización, los requisitos y las necesidades del
PPQA
proyecto.
Cuando se identifican no conformidades, se tratan primero en el
proyecto y se resuelven en él si es posible. Las no conformidades
que no puedan resolverse en el proyecto se escalan al nivel de
gerencia apropiado para su resolución.
Este área de proceso se aplica a las evaluaciones de las actividades
del proyecto y de los productos de trabajo, y a las actividades y
productos de trabajo de la organización (p. ej., grupo de proceso,
formación de la organización). Para estas actividades y productos
de trabajo de la orga- nización, el término “proyecto” debería
interpretarse apropiadamente.
En entornos ágiles, los equipos tienden a enfocarse en las necesidades in-

mediatas de la iteración más que en las necesidades generales y a más lar-
go plazo de la organización. Para asegurar que las evaluaciones objetivas
sean percibidas como valiosas y eficientes, trate en etapas tempranas lo
siguiente: (1) cómo se van a realizar evaluaciones objetivas; (2) qué pro-
cesos y productos de trabajo serán evaluados; (3) cómo serán integrados
los resultados de las evaluaciones en la dinámica de trabajo del equipo (p.
ej., como parte de las reuniones diarias, listas de comprobación, revisiones
entre pares, herramientas, integración continua, retrospectivas) (véase “In-
terpretando CMMI al utilizar enfoques ágiles” en la Primera Parte).

PARA más INFORMACIÓN sobre cómo ASEGURAR que los productos de TRABAJO selec-
CIONADOS SATISFACEN sus requisitos ESPECIFICADOS, consúltese el árEA de proceso
VERIFICACIÓN.

SG 1 Evaluar objetivamente los procesos y los productos de trabajo.
SP 1.1 Evaluar objetivamente los procesos.
SP 1.2 Evaluar objetivamente los productos de trabajo.
SG 2 Proporcionar una visión objetiva.
SP 2.1 Comunicar y resolver las no conformidades.
SP 2.2 Establecer los registros.
SG 1 evaluar objetivamente loS ProceSoS y loS ProductoS de trabajo

Se evalúa objetivamente la adherencia de los procesos realizados y de los pro-
ductos de trabajo asociados a las descripciones de proceso, estándares y pro-
cedimientos aplicables.
SP 1.1 Evaluar objEtivamEntE los procEsos

Evaluar objetivamente los procesos realizados seleccionados frente a las des-
cripciones de proceso, estándares y procedimientos aplicables.
La objetividad en las evaluaciones de aseguramiento de la
calidad es crítica para el éxito del proyecto. Debería definirse una
descripción de la cadena informativa de aseguramiento de la
calidad y cómo ello asegura la objetividad.
1. Informes de evaluación.
2. Informes de no conformidad.
3. Acciones correctivas.
SUBPRÁCTICAS
1. Promover un entorno (creado como parte de la gestión del
proyecto) que incentive la participación del personal en la
identificación y co- municación de las cuestiones de calidad.
2. Establecer y mantener criterios claramente indicados para las
evaluaciones.
La intención de esta subpráctica es proporcionar criterios, en base
a las necesidades del negocio, tales como:
 Qué será evaluado.
 Cuándo o con qué frecuencia será evaluado un proceso.
 Cómo se llevará a cabo la evaluación.
 Quién debe estar involucrado en la evaluación.
3. Utilizar los criterios indicados para evaluar la adherencia de los
procesos realizados y seleccionados frente a las descripciones
de proceso, estándares y procedimientos.
4. Identificar cada no conformidad encontrada durante la evaluación.

5. Identificar las lecciones aprendidas que podrían mejorar los procesos.
SP 1.2 Evaluar objEtivamEntE los productos dE trabajo

Evaluar objetivamente los productos de trabajo seleccionados frente a las des-
cripciones de proceso, estándares y procedimientos aplicables.

2. Informes de no conformidad.
SUBPRÁCTICAS
1. Seleccionar los productos de trabajo a evaluar, en base a
criterios de muestreo documentados en caso de usar muestreo.
Los productos de trabajo pueden incluir servicios producidos por
un proceso, ya sea el destinatario de este servicio interno o
externo al proyecto u organización.
PPQA
2. Establecer y mantener criterios claramente establecidos para la
eva- luación de los productos de trabajo seleccionados.
La intención de esta subpráctica es proporcionar criterios, en
base a las necesidades del negocio, tales como:
 Qué será evaluado durante la evaluación de un producto
de trabajo.
 Cuándo o con qué frecuencia será evaluado un producto
de trabajo.
 Cómo se llevará a cabo la evaluación.
 Quién debe estar involucrado en la evaluación.
3. Utilizar los criterios indicados durante las evaluaciones de los
productos de trabajo seleccionados.
4. Evaluar los productos de trabajo seleccionados en los momentos
escogidos.
Algunos ejemplos de cuándo los productos de trabajo pueden ser evaluados

frente a las descripciones de proceso, estándares o procedimientos son:
• Antes de la entrega al cliente.
• Durante la entrega al cliente.
• Incrementalmente, cuando sea apropiado.
• Durante las pruebas unitarias.
• Durante la integración.
• Cuando se demuestra un incremento.
5. Identificar cada caso de no conformidad encontrado durante las
evaluaciones.
6. Identificar las lecciones aprendidas que podrían mejorar los procesos.
SG 2 P roPorcionar una viSión objetiva
Las no conformidades se siguen y comunican de forma objetiva, y se asegura
su resolución.
SP 2.1 comunicar y rEsolvEr las no conformidadEs

Comunicar las cuestiones de calidad y asegurar la resolución de las no confor-
midades con el personal y con los gerentes.
Las no conformidades son problemas identificados en las

evaluaciones que reflejan una falta de adherencia a los estándares,
descripciones de proceso o procedimientos aplicables. El estado
de las no conformidades indica las tendencias de calidad. Las
cuestiones de calidad incluyen no conformidades y resultados
del análisis de tendencia.
Cuando las no conformidades no pueden resolverse en el
proyec- to, use los mecanismos de escalado establecidos para
asegurar que el nivel apropiado de gerencia puede resolver la no
conformidad. Siga las no conformidades hasta su resolución.

1. Informes de acciones correctivas.
3. Tendencias de calidad.
SUBPRÁCTICAS
1. Resolver cada no conformidad con los miembros apropiados del
personal si es posible.
2. Documentar las no conformidades cuando no puedan resolverse
en el proyecto.
Algunos ejemplos de formas de resolver las no conformidades dentro del

proyecto son:
• Corregir la no conformidad.
• Cambiar las descripciones de proceso, estándares o procedimientos
que fueron incumplidos.
• Obtener una exención para cubrir la no conformidad.
3. Escalar las no conformidades que no puedan resolverse en el
proyecto al nivel de gerencia apropiado designado para recibir
las no conformidades y actuar sobre ellas.
4. Analizar las no conformidades para ver si existen tendencias de
calidad que pueden identificarse y tratarse.
5. Asegurar que las partes interesadas relevantes están al corriente
de los resultados de las evaluaciones y de las tendencias de
calidad de manera oportuna.
6. Revisar periódicamente las no conformidades abiertas y las
tendencias con el gerente designado para recibir las no
conformidades y actuar sobre ellas.
7. Seguir las no conformidades hasta su resolución.
SP 2.2 EstablEcEr los rEgistros
Establecer y mantener los registros de las actividades de aseguramiento de la
calidad.

1. Registros de evaluación.
2. Informes de aseguramiento de la calidad.
3. Informes del estado de las acciones correctivas.
PPQA
4. Informes de las tendencias de calidad.
SUBPRÁCTICAS
1. Registrar las actividades de aseguramiento de la calidad del
proceso y del producto con suficiente detalle, de forma que sean
conocidos el estado y los resultados.
2. Modificar el estado y la historia de las actividades de
aseguramiento de la calidad, según sea necesario.
geStión cuantitatiVa del proYecto
propósito
El propósito de la Gestión Cuantitativa del Proyecto (QPM) es
gestionar cuantitativamente el proyecto para alcanzar los
objetivos establecidos de calidad y de rendimiento de proceso en
el proyecto.
El área de proceso Gestión Cuantitativa del Proyecto implica las
siguientes actividades:
 Establecer y mantener los objetivos de calidad y de
rendimiento de proceso del proyecto.
 Componer un proceso definido para el proyecto que ayude a
alcanzar los objetivos de calidad y de rendimiento de
 Seleccionar los subprocesos y los atributos críticos para
QPM
comprender el rendimiento y que ayuden a alcanzar los
objetivos de calidad y rendimiento de proceso del proyecto.
 Seleccionar las medidas y las técnicas analíticas que van a
utilizarse en la gestión cuantitativa.
 Monitorizar el rendimiento de los subprocesos seleccionados
utilizando técnicas estadísticas y otras técnicas cuantitativas.
 Gestionar el proyecto utilizando técnicas estadísticas y otras
téc- nicas cuantitativas para determinar si se están alcanzando
los objetivos del proyecto de calidad y de rendimiento de
proceso.
 Realizar un análisis de causa raíz de las cuestiones
seleccionadas para tratar las deficiencias en la consecución
de los objetivos de calidad y de rendimiento de proceso del
proyecto.
Los activos de proceso de la organización utilizados para

lograr la alta madurez, incluyendo los objetivos de calidad y de
rendimiento de proceso, los procesos seleccionados, las medidas,
las líneas base y los modelos, se establecen utilizando procesos de
rendimiento de procesos de la organización y se utilizan en los
procesos de gestión cuantitativa
433
del proyecto. El proyecto puede utilizar los procesos de
rendimiento de procesos de la organización para definir los
objetivos, las medidas, las líneas base y los modelos adicionales,
según sea necesario para analizar y gestionar eficazmente el
rendimiento. Las medidas, las mediciones y otros datos que
resulten de los procesos de gestión cuantitativa del proyecto se
incorporan a los activos de proceso de la organización. De esta
forma, la organización y sus proyectos se benefician de los
activos mejorados a través de su utilización.
El proceso definido del proyecto es un conjunto de
subprocesos interrelacionados que forman un proceso integrado y
coherente para el proyecto. Las prácticas de la Gestión Integrada
del Proyecto describen el establecimiento del proceso definido
del proyecto mediante la selección y la adaptación de los
procesos a partir del conjunto de procesos estándar de la
organización (véase la definición de “proceso definido” en el
glosario).
Las prácticas de la Gestión Cuantitativa del Proyecto, a
diferencia de las prácticas de Gestión Integrada del Proyecto, le
ayudan a comprender cuantitativamente el rendimiento
esperado de los procesos o subprocesos. Esta comprensión se
utiliza como base para el establecer el proceso definido del
proyecto mediante la evaluación de procesos o subprocesos
alternativos para el proyecto y para seleccionar aquellos procesos
que permitirán alcanzar mejor los objetivos de calidad y de
Asimismo, es importante establecer relaciones eficaces con
los proveedores para implementar con éxito éste área de proceso.
El establecimiento de relaciones eficaces puede implicar
establecer los objetivos de calidad y de rendimiento de proceso
para los proveedores, determinar las medidas y técnicas analíticas
a utilizar para obtener una visión del progreso y del rendimiento
del proveedor, y monitorizar el progreso hacia la consecución de
esos objetivos.
Un elemento fundamental de la gestión cuantitativa es tener
confianza en las predicciones (p. ej., la capacidad para predecir
con pre- cisión hasta qué punto el proyecto puede cumplir sus
objetivos de calidad y de rendimiento de proceso). Los
subprocesos que se gestio- narán mediante el uso de técnicas
estadísticas y otras técnicas cuantitativas, se eligen en base a la
necesidad de disponer un rendimiento predecible del proceso.
Otro elemento fundamental de la gestión cuantitativa es com-
prender la naturaleza y el grado de la variación experimentada en
el rendimiento de proceso y reconocer cuándo el rendimiento real
del proyecto puede no ser adecuado para alcanzar los objetivos de
calidad y de rendimiento de proceso del proyecto.
Por lo tanto, la gestión cuantitativa incluye el pensamiento
estadís- tico y el uso correcto de una variedad de técnicas
estadísticas (véase la definición de “gestión cuantitativa” en el
glosario).
Gestión cuantitativa del proyecto 435
Las técnicas estadísticas y otras técnicas cuantitativas se
utilizan para comprender el rendimiento real o para predecir el
rendimiento de los procesos. Dichas técnicas se pueden aplicar a
múltiples niveles, desde un enfoque sobre subprocesos
individuales hasta análisis que abarcan las fases del ciclo de vida,
los proyectos y las funciones de soporte. Las técnicas no
estadísticas proporcionan un conjunto de enfoques menos
riguroso pero útil que, junto con las técnicas estadísticas, ayudan
al proyecto a comprender si se están alcanzando los objetivos de
calidad y de rendimiento de proceso, y a identificar cualquier ac-
ción correctiva que sea necesaria.
Éste área de proceso se aplica a la gestión de un proyecto. La apli-
cación de estos conceptos a la gestión de otros grupos y
funciones puede ayudar a vincular los diferentes aspectos del
rendimiento en la organización para proporcionar una base para
equilibrar y reconciliar las prioridades que compiten para tratar
un conjunto más amplio de objetivos de negocio.
Algunos ejemplos de otros grupos y funciones que podrían beneficiarse

del uso de éste área de proceso son:
• Funciones de aseguramiento de la calidad o de control de la calidad.
• Definición y mejora del proceso.
• Funciones internas de Investigación y desarrollo.
• Funciones de Identificación y gestión de riesgos.
• Funciones de exploración de tecnologías.
• Investigación de mercado.
• Evaluación de la satisfacción del cliente.
• Seguimiento e informe de problemas.
QPM
CIONADOS y TOMAR ACCIONES PARA MEJORAR el rendimiento del proceso, consúltese el
árEA de proceso Análisis CAUSAL y Resolución.
PARA más INFORMACIÓN sobre cómo ALINEAR LAS ACTIVIDADES de medición y de ANÁLI-
sis, y proporCIONAR los rESULTADOS de LAS mediciones, consúltese el árEA de proceso
PARA más INFORMACIÓN sobre cómo ESTABLECER los ACTIVOS del proceso de LA ORGANI-
PARA más INFORMACIÓN sobre cómo GESTIONAR prOACTIVAMENTE el rendimiento de LA

orGANIZACIÓN PARA LOGRAR sus objetivos de negocio, consúltese el árEA de proceso
Gestión del Rendimiento de LA OrGANIZACIÓN.
PArA más informAción sobre cómo estAblecer y mAntener unA comprensión
cuAntitAtivA del rendimiento de los procesos seleccionAdos del conjunto de pro-
cesos estándAr de lA OrgAnizAción como soporte pAr A AlcAnzAr los objetivos de
cAlidAd y de rendimiento de proceso, y proporcionAr los dAtos de rendimiento del
proceso, líneAS bASe y modelos pArA gestionAr cuAntitAtivAmente los proyectos
de lA OrgAnizAción, consúltese el áreA de proceso Rendimiento de Procesos de lA
OrgAnizAción.
PARA más INFORMACIÓN sobre cómo proporCIONAR y comprender el progreso del
proyecto de TAL MANERA que PUEDAN TOMARSE LAS ACCIONES corrECTIVAS APROPIADAS
CUANDO el rendimiento del proyecto se desvíe SIGNIFICATIVAMENTE del PLAN, consúl-
PARA más INFORMACIÓN sobre cómo GESTIONAR LA ADQUISICIÓN de productos y servi-
cios de los proveedores, consúltese el árEA de proceso de Gestión de Acuerdos con
Proveedores.

SG 1 Preparar la gestión cuantitativa.
SP 1.1 Establecer los objetivos del proyecto.
SP 1.2 Componer el proceso definido.
SP 1.3 Seleccionar los subprocesos y los atributos.
SP 1.4 Seleccionar las medidas y las técnicas analíticas.
SG 2 Gestionar el proyecto cuantitativamente.
SP 2.1 Monitorizar el rendimiento de los subprocesos seleccionados.
SP 2.2 Gestionar el rendimiento del proyecto.
SP 2.3 Realizar el análisis de las causas raíz.
SG 1 P reParar la GeStión cuantitativa

Se lleva a cabo la preparación para la gestión cuantitativa.
Las actividades de preparación incluyen establecer los objetivos

cuantitativos para el proyecto, componer un proceso definido
para el proyecto que pueda ayudar a alcanzar esos objetivos,
seleccionar los subprocesos y los atributos críticos para
comprender el rendimiento y la consecución de los objetivos, y
seleccionar las medidas y técnicas analíticas que den soporte a la
gestión cuantitativa.
Puede ser necesario repetir estas actividades cuando cambien
las necesidades y las prioridades, cuando exista una mejor
comprensión del rendimiento de proceso o como parte de la
mitigación de riesgos o de acciones correctivas.
SP 1.1 EstablEcEr los objEtivos dEl proyEcto
Establecer y mantener los objetivos de calidad y de rendimiento de proceso del
proyecto.
Cuando se establecen los objetivos de calidad y de rendimiento de

proceso del proyecto, piense acerca de los procesos que serán
incluidos en el proceso definido del proyecto, y acerca de lo que
indican los datos históricos respecto al rendimiento de sus
procesos. Estas consideraciones, junto con otras como la
capacidad técnica, ayudarán a establecer objetivos realistas para
el proyecto.
Los objetivos de calidad y de rendimiento de proceso del
proyecto son establecidos y negociados a un nivel de detalle
adecuado (p.ej., para los componentes individuales del producto,
los subprocesos, los equipos del proyecto) para permitir una
evaluación global de los objetivos y los riesgos a nivel del
proyecto. A medida que progresa el proyecto, se pueden
actualizar los objetivos del proyecto según se vaya conociendo y
siendo más predecible el rendimiento real del proyecto, y cuando
se produzcan cambios en las necesidades y prioridades de las
1. Los objetivos de calidad y de rendimiento de proceso del proyecto.
2. La evaluación del riesgo de no alcanzar los objetivos del proyecto.
SUBPRÁCTICAS
1. Revisar los objetivos de calidad y de rendimiento de proceso de
la organización.
QPM
Esta revisión asegura que los miembros del proyecto
comprendan la amplitud del contexto del negocio en el que
opera el proyecto. Los objetivos del proyecto para la calidad y el
rendimiento del proceso se desarrollan en el contexto de estos
objetivos generales de la organización.
PARA más INFORMACIÓN sobre cómo ESTABLECER los objetivos de CALIDAD y
de rendimiento de proceso, consúltese el árEA de proceso Rendimiento de
Procesos de LA OrGANIZACIÓN.
2. Identificar las necesidades y prioridades de calidad y de
rendimiento de proceso del cliente, de los proveedores, de los
usuarios finales y de otras partes interesadas relevantes.
Normalmente, la identificación de las necesidades de las partes
interesadas relevantes comenzará de forma temprana (p. ej.,
durante el desarrollo de la declaración del trabajo).
Posteriormente, durante el desarrollo de los requisitos, las
necesidades se educen, analizan, refinan, priorizan y balancean.
Algunos ejemplos de atributos de calidad y de rendimiento de proceso

para los que se podrían identificar necesidades y prioridades son:
• Duración.
• Predecibilidad.
• Fiabilidad.
• Facilidad de mantenimiento.
• Usabilidad.
• Puntualidad.
• Funcionalidad.
• Exactitud.
3. Definir y documentar objetivos medibles de calidad y de

Definir y documentar los objetivos para el proyecto implica:
 Incorporar adecuadamente los objetivos de calidad y de
rendimiento de proceso de la organización.
 Documentar los objetivos que reflejen las necesidades y las
prioridades de calidad y de rendimiento de proceso del
cliente, de los usuarios finales y de otras partes interesadas
relevantes.
 Determinar cómo se alcanzará cada objetivo.
 Revisar los objetivos para asegurar que son suficientemente
es- pecíficos, medibles, alcanzables, relevantes y que tienen
un plazo determinado.
Algunos ejemplos de atributos de calidad medibles son:

• Tiempo medio entre fallos.
• Número y gravedad de los defectos en el producto liberado.
• Uso de recursos críticos.
• Número y gravedad de las reclamaciones del cliente respecto al servicio
proporcionado.
Algunos ejemplos de atributos medibles para el rendimiento del proceso

son:
• Tiempo de ciclo.
• Porcentaje de tiempo de retrabajo.
• Porcentaje de defectos eliminados por las actividades de verificación
del producto (por ejemplo, por el tipo de verificación, tales como las
revisiones entre pares y las pruebas).
• Tasa de defectos no detectados.
• Número y gravedad de defectos encontrados (o incidencias
comunicadas) en el año siguiente a la entrega del producto (o al inicio
del servicio).
Algunos ejemplos de objetivos de calidad y de rendimiento de proceso del

proyecto son:
• Mantener el tamaño de la lista de peticiones de cambio por debajo de
un valor objetivo.
• Mejorar la velocidad en un entorno ágil en un valor objetivo para una
fecha objetivo.
• Reducir el tiempo no productivo en un x% para una fecha objetivo.
• Mantener la desviación del calendario por debajo de un porcentaje
especificado.
• Reducir el coste total del ciclo de vida en un porcentaje especificado
para una fecha objetivo.
• Reducir los defectos en los productos entregados al cliente en un 10%
sin afectar al coste.
4. Obtener objetivos intermedios para monitorizar el progreso de
la consecución de los objetivos del proyecto.
Los objetivos intermedios se pueden establecer para los atributos
de las fases del ciclo de vida, de los hitos, de los productos de
trabajo y de los subprocesos seleccionados.
Dado que los modelos de rendimiento del proceso caracterizan
las relaciones entre los atributos del producto y del proceso, estos
modelos pueden utilizarse para ayudar a obtener objetivos
intermedios que guían al proyecto a conseguir sus objetivos.
5. Determinar el riesgo de no alcanzar los objetivos de calidad y de
rendimiento de proceso del proyecto.
El riesgo es una función de los objetivos establecidos, de la
arquitectura del producto, del proceso definido del proyecto, de
la disponibilidad de conocimiento y habilidades necesarias, etc.
Las líneas base y los modelos de rendimiento del proceso pueden
QPM
utilizarse para evaluar la probabilidad de alcanzar un conjunto
de objetivos y proporcionar orientación en la negociación de los
objetivos y los compromisos. La evaluación del riesgo puede
involucrar a varias partes interesadas del proyecto y se puede
realizar como parte de la resolución de conflictos tal y como se
describe en la siguiente subpráctica.
6. Resolver los conflictos entre los objetivos de calidad y de
rendimien- to de proceso del proyecto (p. ej., si un objetivo no
puede alcanzarse sin comprometer a otro).
Los modelos de rendimiento del proceso pueden ayudar a
identificar conflictos y a asegurar que la resolución de los
conflictos no introduz- ca nuevos conflictos o riesgos.
Resolver los conflictos implica las siguientes actividades:
 Establecer prioridades relativas para los objetivos.
 Considerar objetivos alternativos teniendo en cuenta tanto
estrategias de negocio a largo plazo, como necesidades a
corto plazo.
 Involucrar a los clientes, usuarios finales, alta dirección, jefes
de proyecto y otras partes interesadas relevantes en tomar
decisiones basadas en acuerdos de compromiso.
 Modificar los objetivos según sea necesario para reflejar los
resultados de la resolución de conflictos.
7. Establecer la trazabilidad de los objetivos de calidad y de
rendimiento de proceso del proyecto desde sus fuentes.
Algunos ejemplos de fuentes de objetivos son:

• Requisitos.
• Objetivos de calidad y de rendimiento de proceso de la organización.
• Objetivos de calidad y de rendimiento de proceso del cliente.
• Objetivos de negocio.
• Conversaciones con clientes y clientes potenciales.
• Estudios de mercado.
• Arquitectura del producto.
Un ejemplo de un método para identificar y trazar estas necesidades y

prioridades es el Despliegue de la Función Calidad (QFD, Quality Function
Deployment).
8. Definir y negociar los objetivos de calidad y de rendimiento de

proceso para los proveedores.
9. Modificar los objetivos de calidad y de rendimiento de proceso
en el proyecto según sea necesario.
SP 1.2 componEr El procEso dEfinido
Componer un proceso definido que permita al proyecto alcanzar sus objetivos
de calidad y de rendimiento del proceso utilizando técnicas estadísticas y otras
técnicas cuantitativas.
PArA más informAción sobre cómo estAblecer los Activos del proceso de
lA OrgAnizAción, consúltese el áreA de proceso Definición de Procesos de lA
OrgAnizAción.
PArA más informAción sobre cómo estAblecer lAS líneAS bASe y los modelos
de rendimiento, consúltese el áreA de proceso Rendimiento de Procesos de lA
OrgAnizAción.
La composición del proceso definido del proyecto va más allá de

la selección y adaptación descrita en el área de proceso Gestión
Inte- grada del Proyecto. Esto implica la identificación de
alternativas para uno o más procesos o subprocesos, realizar un
análisis cuantitativo del rendimiento y seleccionar las alternativas
que están en mejores condiciones para ayudar al proyecto a
alcanzar sus objetivos de calidad y de rendimiento de proceso.
1. Criterios utilizados para evaluar las alternativas para el proyecto.
2. Subprocesos alternativos.
3. Subprocesos a incluir en el proceso definido del proyecto.
4. Evaluación de los riesgos de no alcanzar los objetivos del proyecto.
SUBPRÁCTICAS
1. Establecer los criterios a utilizar en la evaluación de las
alternativas de proceso para el proyecto.
Los criterios se pueden basar en:

• Objetivos de calidad y de rendimiento de proceso.
• Disponibilidad de datos de rendimiento de proceso y la relevancia de
los datos para evaluar una alternativa.
• Experiencia con una alternativa o con alternativas similares en la
composición.
• Existencia de modelos de rendimiento de proceso que se puedan usar
en la evaluación de una alternativa.
• Estándares de líneas de producto.
• Modelos de ciclo de vida del proyecto.
• Requisitos de las partes interesadas.
• Leyes y normativas.
2. Identificar los procesos y subprocesos alternativos para el proyecto.
La identificación de alternativas puede incluir lo siguiente:
 Analizar las líneas base de rendimiento de proceso de la
QPM
organiza- ción para identificar subprocesos candidatos que
podrían ayudar a alcanzar los objetivos de calidad y de
 Identificar los subprocesos del conjunto de procesos estándar
de la organización, así como los procesos adaptados de la
biblioteca de activos de proceso que puedan ayudar a alcanzar
los objetivos.
 Identificar los procesos de fuentes externas (p.ej., tales
como otras organizaciones, conferencias profesionales,
investigación académica).
 Ajustar el nivel o la profundidad con la que se aplica un
subproceso (tal y como se describe con más detalle en la
subpráctica siguiente).
Ajustar el nivel o la profundidad con la que se aplican los
subprocesos, puede implicar las siguientes opciones:
 Número y tipo de revisiones entre pares a realizar y
cuándo se deben realizar.
 Cantidad de esfuerzo o tiempo dedicado a tareas particulares.
 Número y selección de personal involucrado.
 Requisitos del nivel de habilidad para la realización de
tareas específicas.
 Aplicación selectiva de técnicas especializadas de
construcción o de verificación.
 Decisiones de reutilización y estrategias asociadas de
mitigación de riesgos.
 Atributos del proceso y del producto a medir.
 Frecuencia de muestreo para los datos de gestión.
PARA más INFORMACIÓN sobre cómo USAR los ACTIVOS de proceso de LA ORGA-
NIZACIÓN PARA PLANIFICAR LAS ACTIVIDADES del proyecto, consúltese el árEA de
proceso Gestión INTEGRADA del Proyecto.
3. Analizar la interacción de los subprocesos alternativos para
comprender las relaciones entre los subprocesos, incluyendo
sus atributos.
Un análisis de la interacción proporcionará una visión sobre las
fortalezas y debilidades relativas de alternativas particulares. Este
análisis se puede soportar por una calibración de los modelos de
rendimiento de proceso de la organización con datos del
rendimiento de proceso (p. ej., según se determinaron en las líneas
base de rendimiento de proceso).
Puede ser necesario un modelado adicional si los modelos de
rendimiento de proceso existentes no pueden tratar relaciones
importantes entre los subprocesos alternativos bajo consideración
y existe un riesgo alto de no alcanzar los objetivos.
4. Evaluar subprocesos alternativos frente a los criterios.
Utilizar datos históricos, líneas base de rendimiento de proceso y
modelos de rendimiento de proceso según proceda para ayudar a
evaluar las alternativas frente a los criterios. Estas evaluaciones
pueden incluir el uso de un análisis de sensibilidad
particularmente en situaciones de alto riesgo.
PARA más INFORMACIÓN sobre cómo EVALUAR ALTERNATIVAS, consúltese el árEA
de proceso de Análisis de Decisiones y Resolución.
5. Seleccionar los subprocesos alternativos que mejor cumplan los
criterios.
Puede ser necesario que las actividades descritas en las
subprácticas previas se realicen iterativamente antes de alcanzar
la confianza de que se han identificado las mejores alternativas
disponibles.
6. Evaluar el riesgo de no alcanzar los objetivos de calidad y de
rendimiento de proceso del proyecto.
Un análisis de los riesgos asociados con el proceso definido
alternativo seleccionado puede llevar a identificar nuevas
alternativas a evaluar, así como a identificar áreas que
requieren una mayor atención de gestión.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR y ANALIZAR los riesgos, con-
SP 1.3 sElEccionar los subprocEsos y los atributos
Seleccionar los subprocesos y los atributos críticos para evaluar el rendimiento
y que ayuden a alcanzar los objetivos de calidad y de rendimiento de proceso
del proyecto.
Algunos subprocesos son críticos porque su rendimiento

influye o contribuye significativamente la consecución de los
objetivos del proyecto. Estos subprocesos pueden ser buenos
candidatos para monitorizar y controlar utilizando técnicas
estadísticas u otras técnicas cuantitativas como se describió en la
primera práctica específica de la segunda meta específica.
Además, algunos atributos de estos subprocesos pueden
servir como indicadores destacados de rendimiento de proceso a
esperar de los subprocesos posteriores, y que se pueden utilizar
para evaluar el riesgo de no alcanzar los objetivos del proyecto (p.
ej., mediante el uso de modelos de rendimiento de proceso).
Los subprocesos y los atributos que juegan tales roles críticos
pueden haber sido ya identificados como parte del análisis
descrito en la práctica específica previa.
Para proyectos pequeños y otras circunstancias en las que los
datos de los subprocesos no se puedan generar con la frecuencia
suficiente en el proyecto para dar soporte a una inferencia
estadística suficientemente sensible, todavía puede ser posible
comprender el rendimiento examinando el rendimiento de proceso
a través de iteraciones, equipos o proyectos similares.
QPM
1. Criterios utilizados para seleccionar los subprocesos que son
factores clave para alcanzar los objetivos del proyecto.
2. Subprocesos seleccionados.
3. Atributos de los subprocesos seleccionados que ayudan a
predecir el rendimiento del proyecto.
SUBPRÁCTICAS
1. Analizar cómo los subprocesos, sus atributos, otros factores y
los resultados de rendimiento del proyecto se relacionan entre
sí.
Un análisis de causas raíz, un análisis de sensibilidad o un
modelo de rendimiento de proceso pueden ayudar a identificar
los subprocesos y los atributos que más contribuyen para
alcanzar resultados particulares de rendimiento (y variación en
los resultados de rendimiento) o que son indicadores útiles de la
consecución de los resultados futuros de rendimiento.
PARA más INFORMACIÓN sobre cómo DETERMINAR LAS CAUSAS de los rESULTADOS
SELECCIONADOS, consúltese el árEA de proceso Análisis CAUSAL y Resolución.
2. Identificar los criterios a utilizar en la selección de los
subprocesos que son contribuidores clave para alcanzar los
objetivos de calidad y de rendimiento de proceso del proyecto.
Algunos ejemplos de criterios utilizados para seleccionar subprocesos son:

• Existe una fuerte correlación con los resultados de rendimiento que se
tratan en los objetivos del proyecto.
• El rendimiento estable de los subprocesos es importante.
• El rendimiento pobre del subproceso está asociado con los principales
• Uno o más atributos del subproceso sirven como entradas clave para
los modelos de rendimiento de proceso utilizados en el proyecto.
• El subproceso se ejecutará con la frecuencia suficiente para
proporcionar datos suficientes para el análisis.
3. Seleccionar subprocesos utilizando los criterios identificados.
Los datos históricos, los modelos de rendimiento de proceso y
las lí- neas base de rendimiento de proceso pueden ayudar en la
evaluación de subprocesos candidatos frente a los criterios de
selección.
PARA más INFORMACIÓN sobre cómo EVALUAR LAS ALTERNATIVAS, consúltese el
árEA de proceso Análisis de Decisiones y Resolución.
4. Identificar los atributos del producto y del proceso que se deben
monitorizar.
Estos atributos pueden haber sido identificados como parte de la
rea- lización de las subprácticas previas.
Los atributos que proporcionan una visión del rendimiento actual o
futuro del subproceso son candidatos para monitorizar, estén o no
los subprocesos asociados bajo el control del proyecto. Además,
alguno de estos mismos atributos puede servir a otros roles, (p. ej.,
ayudar en la monitorización del progreso y rendimiento del
proyecto según se descri- bió en el área de proceso Monitorización y
Control del Proyecto [PMC]).
Algunos ejemplos de atributos del producto y del proceso son:

• Esfuerzo empleado para realizar el subproceso.
• Velocidad a la que se lleva a cabo el subproceso.
• Tiempo de ciclo de los elementos del proceso que componen el subproceso.
• Recursos o materiales empleados como entrada al subproceso.
• Nivel de habilidad de los miembros del personal para llevar a cabo el
subproceso.
• Calidad del entorno de trabajo utilizado para realizar el subproceso.
• Volumen de salidas del subproceso (p. ej., productos de trabajo
intermedios).
• Atributos de calidad de las salidas del subproceso (p. ej., fiabilidad,
facilidad de prueba).
SP 1.4 sElEccionar las mEdidas y las técnicas analíticas
Seleccionar las medidas y técnicas analíticas a utilizar en la gestión cuantitativa.
PArA más informAción sobre cómo AlineAr lAS ActividAdes de medición y Análisis y pro-
porcionAr resultAdos de medición, consúltese el áreA de proceso Medición y Análisis.

1. Definiciones de medidas y técnicas analíticas a utilizar en la
gestión cuantitativa.
2. Trazabilidad de medidas hacia los objetivos de calidad y de
rendimiento de proceso del proyecto.
3. Objetivos de calidad y de rendimiento de proceso para los
subprocesos seleccionados y sus atributos.
4. Líneas base y modelos de rendimiento del proceso a utilizar por
el proyecto.
SUBPRÁCTICAS
1. Identificar las medidas comunes de los activos de proceso de la
orga- nización que dan soporte a la gestión cuantitativa.
PArA más informAción sobre cómo estAblecer los Activos de proceso de lA OrgAni-
zAción, consúltese el áreA de proceso Definición de Procesos de lA OrgAnizAción.
PARA más INFORMACIÓN sobre cómo ESTABLECER LÍNEAS BASE y modelos de
rendimiento, consúltese el árEA de proceso Rendimiento de Procesos de LA
OrGANIZACIÓN.
Las líneas de producto u otros criterios de estratificación pueden
caracterizar las medidas comunes.
QPM
2. Identificar medidas adicionales que pueden ser necesarias para
cubrir atributos críticos del producto y del proceso de los
subprocesos seleccionados.
En algunos casos, las medidas pueden estar orientadas a la
investiga- ción. Tales medidas se deberían identificar
explícitamente.
3. Identificar las medidas a utilizar en la gestión de los
subprocesos. Cuando se seleccionan las medidas, hay que tener
en cuenta las siguientes consideraciones:
 Medidas que agregan datos de múltiples fuentes (p. ej.,
diferentes procesos, fuentes de entrada, entornos) o a lo largo
del tiempo (p. ej., a un nivel de fase) pueden ocultar
problemas subyacentes, haciendo difícil la identificación y
resolución de problemas.
 Para proyectos a corto plazo, puede ser necesario agregar
datos a través de instancias similares de un proceso para
permitir el análi- sis de su rendimiento del proceso mientras
se continúan utilizando datos desagregados como soporte a
proyectos individuales.
 La selección no debería estar limitada sólo a las medidas de
progreso o de rendimiento. Las “medidas de análisis” (p. ej.,
velocidades
de preparación de inspección, niveles de habilidad de los
miembros del personal, cobertura de caminos en las pruebas)
pueden proporcionar una mejor visión sobre el rendimiento de
proceso.
4. Especificar las definiciones operativas de las medidas, sus
puntos de recogida en los subprocesos y cómo se determinará la
integridad de las medidas.
5. Analizar las relaciones de las medidas identificadas con los
objetivos de calidad y de rendimiento de proceso del proyecto y
obtener los objetivos de calidad y de rendimiento del proceso del
subproceso que establezcan objetivos (p. ej., umbrales, rangos)
a cumplir para cada atributo medido de cada subproceso
seleccionado.
Algunos ejemplos de objetivos de calidad y de rendimiento de proceso del

subproceso son:
• Mantener la velocidad de revisión de código entre 75 y 100 líneas de
código por hora.
• Mantener sesiones de captura de requisitos por debajo de tres horas.
• Mantener la velocidad de prueba sobre un número específico de casos
de prueba por día.
• Mantener los niveles de retrabajo por debajo de un porcentaje
especificado.
• Mantener la productividad en la generación de casos de uso por día.
• Mantener la complejidad del diseño (tasa de fan-out) por debajo del
umbral especificado.
6. Identificar las técnicas estadísticas y otras técnicas cuantitativas a

utilizar en la gestión cuantitativa.
En la gestión cuantitativa, el rendimiento de proceso de los
subprocesos seleccionados se analiza utilizando técnicas
estadísticas y otras técnicas cuantitativas que ayudan a
caracterizar la variación del subproceso, identificar cuándo
ocurre un comportamiento estadístico inesperado, reconocer
cuándo es excesiva una variación, e investigar el porqué.
Algunos ejemplos de técnicas estadísticas que se pueden utilizar
en el análisis del rendimiento de proceso son los gráficos de
control, el análisis de regresión, el análisis de la varianza y el
análisis de series temporales.
El proyecto se puede beneficiar del análisis de rendimiento de
los subprocesos no seleccionados por su impacto en el
rendimiento del proyecto. Se pueden identificar también técnicas
estadísticas y otras técnicas cuantitativas para tratar estos
subprocesos.
Las técnicas estadísticas y otras técnicas cuantitativas algunas
veces implican el uso de presentaciones gráficas que ayudan a
visualizar las asociaciones entre los datos y los resultados de los
análisis. Tales presentaciones pueden ayudar a visualizar el
rendimiento de proceso y su variación en el tiempo (es decir,
tendencias), a identificar problemas u oportunidades, y a evaluar
los efectos de factores concretos.
Algunos ejemplos de presentaciones gráficas son:

• Gráficos de dispersión.
• Histogramas.
• Gráficos de cajas y bigotes.
• Gráficos de ejecución (run charts).
• Diagramas de Ishikawa.
Algunos ejemplos de otras técnicas utilizadas para analizar el rendimiento

de los procesos son:
• Hojas de conteo.
• Esquemas de clasificación (p. ej., Clasificación ortogonal de defectos).
7. Determinar qué líneas base y qué modelos de rendimiento de
proceso pueden ser necesarios para dar soporte a los análisis
identificados.
En algunas situaciones, el conjunto de líneas base y modelos
proporcionado tal y como se describió en el área de proceso
Rendimiento de los Procesos de la Organización puede ser
inadecuado para dar soporte a la gestión cuantitativa del
proyecto. Esta situación puede suceder cuando los objetivos, los
procesos, las partes interesadas, los niveles de habilidad o el
entorno del proyecto son diferentes de otros proyectos para los
que fueron establecidos las líneas base y los modelos. A medida
que el proyecto progresa, los datos del proyecto pueden servir
como un conjunto de datos más representativo para establecer un
conjunto de líneas base o modelos de rendimiento del proceso no
disponibles o específicos para un proyecto.
El contraste de hipótesis, comparando los datos del proyecto con
los datos históricos anteriores, puede confirmar la necesidad de
QPM
establecer líneas base y modelos adicionales específicos para el
proyecto.
8. Instrumentar el entorno de soporte de la organización o del
proyecto para dar soporte en la recopilación, obtención y análisis
de medidas.
Esta instrumentación está basada en:
 La descripción del conjunto de procesos estándar
 La descripción del proceso definido del proyecto.
 Las capacidades del entorno de soporte de la organización o
del proyecto.
9. Modificar las medidas y las técnicas de análisis estadístico según
sea necesario.
SG 2 G eStionar el Proyecto cuantitativamente

El proyecto se gestiona cuantitativamente.
Gestionar el proyecto cuantitativamente implica la utilización de
téc- nicas estadísticas y otras técnicas cuantitativas para:
 Monitorizar los subprocesos seleccionados utilizando
técnicas estadísticas y otras técnicas cuantitativas.
 Determinar si se están cumpliendo los objetivos de calidad
y de rendimiento de proceso del proyecto.
 Llevar a cabo el análisis de causa raíz de las cuestiones
seleccionadas para tratar las deficiencias.
SP 2.1 monitorizar El rEndimiEnto dE los subprocEsos sElEccionados
Monitorizar el rendimiento de los subprocesos seleccionados usando técnicas
El propósito de esta práctica específica es utilizar técnicas
estadísticas y otras técnicas cuantitativas para analizar la variación
en el rendimiento del subproceso y determinar las acciones
necesarias para alcanzar los objetivos de calidad y de rendimiento
de proceso de cada subproceso.
Ejemplos de los productos de TRABAJO
1. Límites naturales de rendimiento de proceso para cada atributo
seleccionado del subproceso.
2. Las acciones necesarias para tratar las deficiencias en la
estabilidad o en la capacidad del proceso de cada subproceso
seleccionado.
SUBPRÁCTICAS
1. Recopilar los datos de los subprocesos a medida que se ejecuten,
se- gún se ha definido por las medidas seleccionadas.
2. Monitorizar la variación y la estabilidad de los subprocesos
seleccionados y tratar las deficiencias.
Este análisis implica la evaluación de las mediciones en relación a los
lími- tes naturales calculados para cada medida seleccionada y la
identificación de valores anormales u otras señales de
comportamiento potencial no alea- torio, la determinación de sus
causas y la prevención o mitigación de los efectos de su recurrencia
(p.ej., tratar las causas especiales de variación). Durante este
análisis, tenga en cuenta que debería disponer de una cantidad
suficiente de datos, así como los cambios en el rendimiento de
proceso que puedan afectar a la capacidad para alcanzar o
mantener la estabilidad del proceso.
Las técnicas analíticas para identificar valores anormales o
señales incluyen los gráficos de control estadístico del proceso,
los intervalos de predicción y el análisis de varianza. Algunas de
estas técnicas implican presentaciones gráficas.
Otras deficiencias en el rendimiento del proceso a considerar,
incluyen situaciones cuando la variación es demasiado amplia
para tener la confianza de que el subproceso es estable, o
demasiado importante para evaluar su capacidad (subpráctica
siguiente) para alcanzar los objetivos establecidos para cada
atributo seleccionado.
3. Monitorizar la capacidad y el rendimiento de los subprocesos
seleccionados y tratar las deficiencias.
El propósito de esta subpráctica es identificar qué acciones
tomar para ayudar al subproceso a alcanzar sus objetivos de
calidad y de
rendimiento de proceso. Asegúrese que el rendimiento del
subproceso es estable en relación a las medidas seleccionadas
(subpráctica previa) antes de comparar su capacidad con sus
Algunos ejemplos de acciones que se pueden tomar cuando el rendimiento

de un subproceso seleccionado no consigue satisfacer sus objetivos son:
• Mejorar la implementación del subproceso existente para reducir su variación
o mejorar su rendimiento (p. ej., tratar las causas comunes de variación).
• Identificar e implementar un subproceso alternativo a través de
la identificación y la adopción de nuevos elementos del proceso,
subprocesos y tecnologías que puedan ayudar a hacer una mejor
alineación con susobjetivos.
• Identificar riesgos y estrategias de mitigación de riesgos para cada
deficiencia en la capacidad del subproceso.
• Renegociar o volver a obtener objetivos para cada atributo seleccionado
de un subproceso de forma que se puedan cumplir por el subproceso.
ALGUNAS ACCIONES pueden IMPLICAR el uso de ANÁLISIS de CAUSAS RAÍZ, que se

describe más ADELANTE en LA SP 2.3.
PArA más informAción sobre cómo gestionAr Acciones correctivAS hAStA Su
cierre, consúltese el áreA de proceso MonitorizAción y Control del Proyecto.
SP 2.2 gEstionar El rEndimiEnto dEl proyEcto

Gestionar el proyecto utilizando técnicas estadísticas y otras técnicas cuantita-
tivas para determinar si se cumplirán los objetivos de calidad y de rendimiento
QPM
de proceso del proyecto.
PARA más INFORMACIÓN sobre cómo ALINEAR LAS MEDIDAS y ACTIVIDADES de ANÁLI-
sis y proporCIONAR rESULTADOS medición, consúltese el árEA de proceso Medición y
Análisis.
PARA más INFORMACIÓN sobre cómo GESTIONAR el rendimiento del negocio, consúlte-
se el árEA de proceso Gestión del Rendimiento de LA OrGANIZACIÓN.
Esta práctica específica está enfocada al proyecto y utiliza

múltiples entradas para predecir si se cumplirán los objetivos de
calidad y de rendimiento de proceso del proyecto. En base a esta
predicción, se identifican y se gestionan los riesgos asociados a no
alcanzar los objetivos de calidad y de rendimiento de proceso del
proyecto, y se definen las acciones para tratar las deficiencias,
según proceda.
Las entradas clave para este análisis incluyen los datos de
estabilidad y de capacidad de subprocesos individuales
obtenidos de la práctica específica previa, así como los datos de
rendimiento obtenidos de la monitorización del progreso de
otros subprocesos, riesgos y proveedores.
1. Predicciones de los resultados a lograr en relación con los
objetivos de calidad y de rendimiento de proceso del proyecto.
2. Presentaciones gráficas y tabulaciones de datos para otros
subprocesos, que den soporte a la gestión cuantitativa.
3. Evaluación de los riesgos de no alcanzar los objetivos de calidad
y de rendimiento de proceso del proyecto.
4. Acciones necesarias para tratar las deficiencias en la
consecución de los objetivos del proyecto.
SUBPRÁCTICAS
1. Revisar periódicamente el rendimiento de los subprocesos.
Los datos de estabilidad y de capacidad obtenidos de la
monitorización de los subprocesos seleccionados, según se
describió en la SP 2.1, son una entrada clave en la comprensión de
la capacidad global del proyec- to para cumplir los objetivos de
calidad y de rendimiento de proceso.
Además, los subprocesos no seleccionados por su impacto en los
objetivos del proyecto pueden crear todavía problemas o riesgos
para el proyecto y por lo tanto puede ser deseable algún nivel de
monitori- zación para estos subprocesos. Las técnicas analíticas
que implican el uso de presentaciones gráficas se pueden mostrar
también útiles para comprender el rendimiento del subproceso.
2. Monitorizar y analizar el progreso de los proveedores hacia la
conse- cución de sus objetivos de calidad y de rendimiento de
proceso.
3. Revisar y analizar periódicamente los resultados reales
conseguidos frente a los objetivos intermedios establecidos.
4. Utilizar los modelos de rendimiento de proceso calibrados con
los datos del proyecto para evaluar el progreso hacia el logro de
los objetivos de calidad y de rendimiento de proceso del
proyecto.
Los modelos de rendimiento de proceso se usan para evaluar el
progreso en la consecución de los objetivos que no se pueden
medir hasta una fase futura en el ciclo de vida del proyecto. Los
objetivos pueden ser tanto objetivos intermedios como objetivos
generales.
Un ejemplo es la utilización de los modelos de rendimiento de proceso

para predecir los defectos latentes en los productos de trabajo en fases fu-
turas o en el producto entregado.
La calibración de los modelos de rendimiento de proceso se basa

en los resultados obtenidos al realizar las actividades descritas
en las subprácticas y prácticas específicas previas.
5. Identificar y gestionar los riesgos asociados con la consecución
de los objetivos de calidad y de rendimiento de proceso del
proyecto.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR, ANALIZAR y MITIGAR los ries-
gos, consúltese el árEA de proceso Gestión de Riesgos.
Algunos ejemplos de fuentes de riesgos son:

• Subprocesos que tienen un rendimiento o capacidad inadecuados.
• Proveedores que no alcanzan sus objetivos de calidad y de rendimiento
de proceso.
• Falta de visibilidad en la capacidad del proveedor.
• Inexactitudes en los modelos de rendimiento de proceso utilizados para
predecir el rendimiento.
• Deficiencias en el rendimiento predecible de proceso (progreso estimado).
• Otros riesgos identificados asociados con las deficiencias identificadas.
6. Determinar e implementar las acciones necesarias para tratar las
deficiencias para alcanzar los objetivos de calidad y de
El propósito de esta subpráctica es identificar e implementar el
conjunto correcto de acciones, de recursos y de calendario para
devolver al proyecto a la senda hacia la consecución de sus
objetivos.
Algunos ejemplos de acciones que se pueden tomar para tratar las defi-
ciencias para lograr los objetivos del proyecto son:
• Cambiar los objetivos de calidad y de rendimiento de proceso para que
estén dentro del rango esperado del proceso definido del proyecto.
• Mejorar la implementación del proceso definido del proyecto.
• Adoptar los nuevos subprocesos y tecnologías que tengan el potencial
para satisfacer los objetivos y gestionar los riesgos asociados.
• Identificar el riesgo y las estrategias de mitigación del riesgo para las
deficiencias.
• Finalizar el proyecto.
QPM
Algunas acciones pueden implicar el uso del análisis de causas
raíz, que se trata en la siguiente práctica específica.
PArA más informAción sobre cómo gestionAr Acciones correctivAS hAStA Su
Cuando las acciones correctivas dan lugar a cambios a los
atributos
o las medidas relacionadas con factores ajustables en un modelo de
rendimiento de proceso, el modelo se puede utilizar para
predecir los efectos de las acciones. Al llevar a cabo acciones
correctivas críticas en situaciones de alto riesgo, se puede crear
un modelo de rendimiento de proceso para predecir los efectos
del cambio.
SP 2.3 rEalizar El análisis dE las causas raíz

Realizar el análisis de causas raíz de las cuestiones seleccionadas para tratar las
deficiencias en la consecución de los objetivos de calidad y de rendimiento de
Las cuestiones a tratar incluyen las deficiencias en la estabilidad
y en la capacidad del subproceso, y las deficiencias en el
rendimiento del proyecto en relación con sus objetivos.
El análisis de causas raíz de las cuestiones seleccionadas es
mejor realizarlo inmediatamente después de que el problema haya
sido identificado por primera vez, cuando el evento es aún lo
suficientemente reciente para ser cuidadosamente investigado.
La formalidad y el esfuerzo requerido para un análisis de
causas raíz pueden variar ampliamente y se pueden determinar
por factores tales como las partes interesadas que están
involucradas; el riesgo o la oportunidad que está presente; la
complejidad de la situación; la frecuencia con que la situación se
puede repetir; la disponibilidad de los datos, las líneas base y los
modelos que se puedan utilizar para el análisis; y cuánto tiempo
ha pasado desde que los eventos desencade- naron la deficiencia.
En el caso de un subproceso que presenta demasiada
variación, se realiza en raras ocasiones, e involucre a diferentes
partes interesadas, podría llevar varias semanas o meses
identificar las causas raíz.
Del mismo modo, las acciones a llevar a cabo pueden variar
significativamente en términos de esfuerzo y de tiempo
necesarios para determinarlas, planificarlas e implementarlas.
Con frecuencia es difícil saber cuánto tiempo se necesita a
menos que se lleve a cabo un análisis inicial de las deficiencias.
CIONADOS y LLEVAR A CABO ACCIONES corrECTIVAS PARA MEJORAR el rendimiento del
proceso, consúltese el árEA de proceso Análisis CAUSAL y Resolución.
PARA más INFORMACIÓN sobre cómo ALINEAR LAS ACTIVIDADES de medición y de ANÁLI-
sis y proporCIONAR rESULTADOS de medición, consúltese el árEA de proceso Medición
y Análisis.

1. Mediciones y análisis del rendimiento de subprocesos y del
proyecto (incluyendo análisis estadísticos) registrados en el
repositorio de mediciones de la organización.
2. Presentación gráfica de los datos utilizados para comprender el
rendimiento de proyecto y de subproceso y las tendencias del
rendimiento.
3. Identificar las causas raíz y las acciones potenciales a llevar a cabo.
SUBPRÁCTICAS
1. Realizar el análisis de causas raíz, según proceda, para
diagnosticar deficiencias en el rendimiento del proceso.
Las líneas base y los modelos de rendimiento del proceso se
utilizan para diagnosticar deficiencias; identificar posibles
soluciones; predecir el rendimiento futuro del proyecto y del
proceso; y evaluar acciones potenciales según proceda.
El uso de modelos de rendimiento del proceso en la predicción
del rendimiento futuro del proyecto y del proceso, se describe en
una subpráctica de la práctica específica previa.
2. Identificar y analizar las acciones potenciales.

3. Implementar las acciones seleccionadas.
4. Evaluar el impacto de las acciones sobre el rendimiento del
subproceso.
Esta evaluación del impacto puede incluir una evaluación de la
signi- ficancia estadística de los impactos resultantes de las
acciones llevadas a cabo para mejorar el rendimiento del proceso.
QPM
DESARROLLO DE REQUISITOS
Un área de proceso de Ingeniería en el nivel de madurez 3
Propósito
El propósito del Desarrollo de Requisitos (RD) es educir,
analizar y establecer los requisitos de cliente, de producto y de
Éste área de proceso describe tres tipos de requisitos: de cliente,
de producto y de componente de producto. Tomados en conjunto,
estos requisitos tratan las necesidades de las partes interesadas
relevantes, incluyendo las necesidades pertinentes a las diferentes
fases del ciclo de vida del producto (p. ej., criterios de pruebas de
aceptación) y a los atributos del producto (p. ej., capacidad de
respuesta, protección, fiabilidad, capacidad de mantenimiento).
Los requisitos también tratan las restricciones causadas por la
selección de soluciones de diseño (p. ej., integración de productos
disponibles comercialmente (COTS), o uso de un patrón
particular de arquitectura).
Todos los proyectos de desarrollo tienen requisitos. Los requisitos
son la base para el diseño. El desarrollo de los requisitos incluye
las siguientes actividades:
• Educción, análisis, validación y comunicación de las
necesidades, las expectativas y las restricciones del cliente
para obtener los requisitos priorizados de cliente que
constituyen una comprensión de lo que satisfará a las partes
interesadas.
RD
• Recopilación y coordinación de las necesidades de las partes
interesadas.
• Desarrollo de los requisitos del ciclo de vida del producto.
• Establecimiento de los requisitos funcionales de cliente y de
los requisitos de los atributos de calidad.
• Establecimiento de los requisitos iniciales de producto y de
componente de producto consistentes con los requisitos de
cliente.
455
Este área de proceso trata todos los requisitos de cliente, y no

sólo los requisitos a nivel de producto, ya que el cliente puede
también proporcionar requisitos específicos de diseño.
Los requisitos de cliente se refinan más tarde en requisitos de
producto y de componentes de producto. Además de los
requisitos de cliente, los requisitos de producto y de componente
de producto se derivan de las soluciones de diseño seleccionadas.
En todas las áreas de proceso donde se utilizan los términos
“producto” y “componente de producto”, su significado pretende
también abarcar los servicios, los sistemas de servicio y sus
componentes.
Los requisitos se identifican y se refinan a través de todas las
fases del ciclo de vida del producto. Las decisiones de diseño, las
acciones correctivas subsiguientes y la realimentación durante
cada fase del ciclo de vida del producto se analizan para
determinar el impacto sobre los requisitos derivados y asignados.
El área de proceso Desarrollo de Requisitos incluye tres metas
es- pecíficas. La meta específica Desarrollar los requisitos de
cliente trata la definición de un conjunto de requisitos de cliente
para utilizarse en el desarrollo de los requisitos de producto. La
meta específica Desarro- llar los requisitos de producto trata la
definición de un conjunto de requisitos de producto o de
componente de producto para utilizarse en el diseño de productos
y de componentes de producto. La meta espe- cífica Analizar y
validar los requisitos trata el análisis de los requisitos de cliente,
de producto y de componente de producto para definir, inferir y
comprender los requisitos. Las prácticas específicas de la tercera
meta específica están pensadas para ayudar a las prácticas
específicas de las dos primeras metas específicas. Los procesos
asociados al área de proceso Desarrollo de Requisitos y los
procesos asociados con el área de proceso Solución Técnica
pueden interactuar recursivamente unos con otros.
Los análisis se utilizan para comprender, definir y seleccionar
los
requisitos a todos los niveles a partir de alternativas competitivas.
Es- tos análisis incluyen:
• Análisis de necesidades y de requisitos para cada fase del
ciclo de vida de producto, incluyendo las necesidades de las
partes interesadas relevantes, el entorno de operación y los
factores que reflejan las expectativas y la satisfacción
globales del cliente y del usuario final, tales como
protección, seguridad y asequibilidad.
• Desarrollo de un concepto operacional.
• Definición de funcionalidad requerida y atributos de calidad.
Esta definición de funcionalidad requerida y de atributos de

calidad describe qué tiene que hacer el producto (véase en el
glosario la definición de “definición de funcionalidad requerida y
de atributos de
Desarrollo de requisitos 457
calidad”). Esta definición puede incluir descripciones,
descomposicio- nes y una división de las funciones (o en el análisis
orientado a objetos lo que se ha referenciado como “servicios” o
“métodos”) del producto. Además, la definición especifica las
consideraciones o restricciones de diseño sobre cómo la
funcionalidad requerida será realizada en el producto. Los
atributos de calidad tratan cosas tales como: disponibilidad del
producto; capacidad de mantenimiento; adaptabilidad; oportunidad,
tasa de transferencia y capacidad de respuesta; fiabilidad;
seguridad; y escalabilidad. Algunos atributos de calidad surgirán
como significativos de la arquitectura y conducirán así el
desarrollo de la
arquitectura del producto.
Estos análisis ocurren recursivamente en capas sucesivas que
contienen un mayor detalle de la arquitectura del producto hasta
que se disponga del suficiente detalle para permitir realizar el
diseño detallado, la adquisición y las pruebas del producto.
Como resultado del análisis de requisitos y del concepto
operacional (incluyendo funcionalidad, soporte, mantenimiento
y retirada), la fabricación o el concepto de producción produce
más requisitos derivados, incluyendo consideraciones como las
siguientes:
• Restricciones de varios tipos.

• Coste y parámetros de coste.
• Restricciones de tiempo y parámetros de calendario.
• Riesgos.
• Consideraciones de cuestiones implícitas, pero no declaradas
explícitamente por el cliente o por el usuario final.
• Factores introducidos por consideraciones de negocio
propias del desarrollador, por normativas y por leyes.
Una jerarquía de entidades lógicas (p. ej., funciones y

subfunciones, clases y subclases de objetos; procesos; otras
entidades arquitectó- nicas) se establece a través de la iteración con
la evolución del concepto operacional. Los requisitos se refinan,
se infieren y se asignan a estas entidades lógicas. Los requisitos y
RD
las entidades lógicas se asignan a los productos, a los
componentes de producto, a las personas o a los procesos
asociados. En el caso de desarrollo iterativo o incremental, los
requisitos también se asignan a las iteraciones o incrementos.
La involucración de las partes interesadas relevantes, tanto
en el desarrollo como en el análisis de los requisitos, les
proporciona visibilidad en la evolución de los requisitos. Esta
actividad les asegura continuamente que los requisitos están
siendo definidos apropiadamente.
Para las líneas de producto, los procesos de ingeniería
(incluyendo el desarrollo de los requisitos) pueden aplicarse por
lo menos a dos niveles en la organización. En un nivel de
organización o de línea de
producto, un “análisis de lo común y de la variación” se realiza
para ayudar a educir, analizar y establecer activos base para su
uso por los proyectos dentro de la línea de producto. En el nivel
del proyecto, estos activos base son luego usados según el plan
de producción de la línea de producto como parte de las
actividades de ingeniería del proyecto.
en entornos Ágiles, las necesidades y las ideas del cliente son

iterativamente educidas, elaboradas, analizadas y validadas. Los
requisitos se documentan en formularios tales como: historias de usuario,
escenarios, casos de uso, backlog del producto y los resultados de
iteraciones (código en elaboración en el caso del software). Qué requisitos
serán tratados en una iteración dada se determinan por una evaluación
del riesgo y por las prioridades asociadas con los requisitos que se dejan
en la backlog del producto. Qué detalles de los requisitos (y de otros
artefactos) a documentar se determinan por la necesidad de coordinación
(entre los miembros del equipo, los equipos y las iteraciones posteriores)
y el riesgo de perder lo que se ha aprendido. Cuando el cliente está en el
equipo, puede todavía existir una necesidad de separar la documentación
de cliente y de producto para permitir que sean exploradas múltiples
soluciones. Mientras que la solución surge, las responsabilidades de
los requisitos derivados se asignan a los equipos apropiados (véase
“Interpretando CMMI al utilizar enfoques ágiles” en la primera parte).

PARA más INFORMACIÓN sobre cómo ASEGURAR LA COMPATIBILIDAD de interFACES, con-
súltese el árEA de proceso INTEGRACIÓN del Producto.
PARA más INFORMACIÓN sobre cómo SELECCIONAR LAS SOLUCIONES del componente de
producto y DESARrOLLAR el diseño, consúltese el árEA de proceso Solución TÉCNICA.
PARA más INFORMACIÓN sobre cómo VALIDAR el producto o componentes de producto,
consúltese el árEA de proceso VALIDACIÓN.
PARA más INFORMACIÓN sobre cómo VERIFICAR los productos de TRABAJO SELECCIONA-
dos, consúltese el árEA de proceso VERIFICACIÓN.
PARA más INFORMACIÓN sobre cómo seguir y contrOLAR los CAMBIOS, consúltese el
PARA más INFORMACIÓN sobre cómo IDENTIFICAR y ANALIZAR los riesgos, consúltese el
árEA de proceso Gestión de Riesgos.

sg 1 desarrollar los requisitos de cliente.
sp 1.1 educir las necesidades.
sp 1.2 trasformar las necesidades de las partes interesadas en requisitos de
cliente.
sg 2 desarrollar los requisitos de producto.
sp 2.1 establecer los requisitos de producto y de componente de producto.
sp 2.2 asignar los requisitos de componente de producto.
sp 2.3 Identificar los requisitos de interfaz.
sg 3 analizar y validar los requisitos.
sp 3.1 establecer los conceptos y los escenarios de operación.
sp 3.2 establecer una definición de la funcionalidad y de los atributos de
calidad requeridos.
sp 3.3 analizar los requisitos.
sp 3.4 analizar los requisitos para conseguir un equilibrio.
sp 3.5 Validar los requisitos.
SG 1 DeSarrollar loS requiSitoS De cliente

Las necesidades, expectativas, restricciones e interfaces de las partes interesa-
das se recopilan y traducen en requisitos de cliente.
Las necesidades de las partes interesadas (p. ej., clientes,

usuarios finales, proveedores, desarrolladores, personal de
pruebas, fabri- cantes, personal de soporte logístico) son la base
para determinar los requisitos de cliente. Las necesidades, las
expectativas, las restricciones, las interfaces, los conceptos
operacionales y los conceptos de producto de las partes
interesadas se analizan, ajustan, refinan y elaboran para
traducirlos en un conjunto de requisitos de cliente.
Con frecuencia, las necesidades, las expectativas, las
restricciones y las interfaces de las partes interesadas están
pobremente identificadas o en conflicto. Puesto que las
necesidades, las expectativas, las restricciones y las limitaciones
de las partes interesadas deberían identificarse y comprenderse
RD
claramente, se utiliza un proceso iterativo durante toda la vida
del proyecto para cumplir este objetivo. Para facilitar la
interacción requerida, frecuentemente se involucra a un sustituto
del usuario final o cliente para representar sus necesidades y
ayudar a resolver conflictos. Las relaciones del cliente o el área
de marketing de la organización, así como los miembros del
equipo de desarrollo de disciplinas como ingeniería o soporte
humano, pueden utilizarse como sustitutos. Las restricciones
medioambientales, legales y otras deberían considerarse al crear y
resolver el conjunto de requisitos de cliente.
SP 1.1 Educir las nEcEsidadEs
Educir las necesidades, las expectativas, las restricciones y las interfaces de las
partes interesadas para todas las fases del ciclo de vida del producto.
Educir va más allá de la recopilación de requisitos mediante la

identifica- ción proactiva de requisitos adicionales no explícitamente
proporcionados por los clientes. Los requisitos adicionales deberían
tratar las distintas actividades del ciclo de vida del producto y sus
impactos en el producto.
algunos ejemplos de técnicas para educir las necesidades son:

 demostraciones de tecnología.
 grupos de trabajo de control de la interfaz.
 grupos de trabajo de control técnico.
 revisiones intermedias del proyecto.
 Cuestionarios, entrevistas y escenarios (operacional, soporte y
desarrollo) obtenidos de los usuarios finales.
 Walthroughs de soporte, desarrollo y de operación, y análisis de tareas
de usuario final.
 Workshops con las partes interesadas para la educción de los atributos
de calidad.
 prototipos y modelos.
 tormenta de ideas.
 despliegue de la función de calidad.
 estudios de mercado.
 pruebas beta.
 extracción de fuentes como documentos, estándares o
especificaciones.
 Observación de productos, entornos y patrones de flujo de trabajo
existentes.
 Casos de uso.
 Historias de usuario.
 pequeñas entregas incrementales “por rodajas” de la funcionalidad del
producto.
 análisis de casos de negocio.
 Ingeniería inversa (para productos heredados).
 encuestas de satisfacción del cliente.
algunos ejemplos de fuentes de requisitos que pueden no ser
identificadas por el cliente son:
 políticas de negocio.
 estándares.
 decisiones y principios de diseño de arquitectura previos.
 requisitos de entorno de negocio (p. ej., laboratorios, pruebas y otras
instalaciones, infraestructura de tecnología de información).
Continúa
Continuación
 tecnología.
 productos o componentes de producto heredados (reutilización de
componentes de producto).
 estatutos reguladores

1. Resultados de las actividades de educción de requisitos.
SUBPRÁCTICAS
1. Comprometer a las partes interesadas relevantes usando
métodos para educir las necesidades, las expectativas, las
restricciones y las interfaces externas.
SP 1.2 T ransformar las nEcEsidadEs dE las parTEs inTErEsadas En rEquisiTos dE cliEnTE
Transformar las necesidades, las expectativas, las restricciones y las interfaces
de las partes interesadas en requisitos de cliente priorizados.
Se deberían consolidar las distintas entradas provenientes de las

partes interesadas relevantes, se debería recuperar la información
que falta y se deberían resolver los conflictos a medida que se
desarrollan y priorizan los requisitos de cliente. Los requisitos de
cliente pueden incluir las necesidades, las expectativas y las
restricciones con respecto a la verificación y a la validación.
En algunas situaciones, el cliente proporciona un conjunto de
requisitos al proyecto, o los requisitos existen como una salida
de las actividades de un proyecto anterior. En estas situaciones,
los requisitos de cliente podrían entrar en conflicto con las
necesidades, expectativas, restricciones e interfaces de las partes
interesadas relevantes y necesitarán transformarse en un conjunto
reconocido de requisitos de cliente después de una resolución de
conflictos apropiada.
Las partes interesadas relevantes que representan a todas las
fases del ciclo de vida del producto deberían incluir tanto
funciones del negocio, como funciones técnicas. De esta manera,
RD
los conceptos para todos los procesos del ciclo de vida relativo al
producto se consideran concurrentemente con los conceptos para
los productos. Los requisitos de cliente resultan tanto de
decisiones informadas sobre el negocio, como de los efectos
técnicos de sus requisitos.
1. Requisitos de cliente priorizados.
2. Restricciones de cliente para llevar a cabo la verificación.
3. Restricciones de cliente para llevar a cabo la validación.
SUBPRÁCTICAS
1. Traducir las necesidades, las expectativas, las restricciones y
las interfaces de las partes interesadas en requisitos
documentados del cliente.
2. Establecer y mantener una priorización de los requisitos
funcionales de cliente y de los atributos de calidad.
Tener priorizados los requisitos de cliente ayuda a determinar el
alcance del proyecto, de la iteración o del incremento. Esta
priorización asegura que los requisitos funcionales y de los
atributos de calidad crí- ticos para el cliente y otras partes
interesadas se tratan rápidamente.
3. Definir las restricciones para la verificación y la validación.
SG 2 DeSarrollar loS requiSitoS De ProDucto

Los requisitos de cliente se refinan y elaboran para desarrollar los requisitos de
producto y de componente de producto.
Los requisitos de cliente se analizan conjuntamente con el

desarrollo del concepto de operación para inferir conjuntos de
requisitos más detallados y precisos llamados “requisitos de
producto y de componente de producto”. Los requisitos de
producto y de componente de produc- to tratan las necesidades
asociadas con cada fase del ciclo de vida del producto. Los
requisitos derivados surgen de restricciones; consideraciones de
las cuestiones implícitas pero no declaradas explícitamente en la
línea base de los requisitos de cliente; factores introducidos por
la arquitectura seleccionada, ciclo de vida del producto y diseño; y
por las consideraciones propias del negocio del desarrollador. Los
requisitos se reexaminan con cada conjunto de requisitos
sucesivo y de nivel más bajo y con la arquitectura, y se refina el
concepto de producto preferido.
Los requisitos se asignan a las funciones del producto y a los com-
ponentes de producto, incluyendo objetos, personas y procesos.
En el caso de desarrollo iterativo o incremental, los requisitos
también se asignan a las iteraciones o a los incrementos en base a
las prioridades del cliente, cuestiones de tecnología y objetivos
del proyecto. Se documenta la trazabilidad de los requisitos a las
funciones, objetos, pruebas, cuestiones u otras entidades. Los
requisitos asignados y las funciones (u otras entidades lógicas)
son la base para la síntesis de la solución técnica; sin embargo,
mientras se define la arquitectura, sirve como base última para
dirigir la asignación de requisitos a la solución. A medida que se
desarrollan los componentes internos, se definen interfaces
adicionales y se establecen los requisitos de la interfaz.
SP 2.1 eStablecer loS requiSitoS De ProDucto y De comPonente De ProDucto
Establecer y mantener los requisitos de producto y de componente de produc-
to, basados en los requisitos de cliente.
Los requisitos funcionales y los atributos de calidad del cliente

pueden expresarse en términos del cliente y pueden ser
descripciones no téc- nicas. Los requisitos de producto son la
expresión de estos requisitos en términos técnicos que pueden
utilizarse para las decisiones de di- seño. Un ejemplo de esta
traducción se encuentra en la primera House of Quality Function
Deployment, que traduce los deseos del cliente en parámetros
técnicos. Por ejemplo, “puerta sólida de resonancia” po- dría
corresponder a tamaño, peso, ajuste, amortiguación y frecuencias
de resonancia.
Los requisitos de producto y de componente de producto
tratan la satisfacción del cliente, el negocio, y los objetivos del
proyecto y sus atributos asociados, tales como eficacia y
asequibilidad.
Los requisitos derivados también tratan las necesidades de
otras fases del ciclo de vida (p. ej., producción, operaciones,
retirada) en la medida que son compatibles con los objetivos de
negocio.
La modificación de los requisitos debida a cambios de requisitos
aprobados se cubre por el aspecto “mantener” de esta práctica
específi- ca; mientras que la gestión de los cambios a los requisitos
se cubre por el área de proceso Gestión de Requisitos.

1. Requisitos derivados.
2. Requisitos de producto.
3. Requisitos de componente de producto.
4. Requisitos de arquitectura, que especifican o restringen las
relaciones entre componentes de producto.
SUBPRÁCTICAS
RD
1. Desarrollar los requisitos en los términos técnicos necesarios
para el diseño del producto y de los componentes de producto.
2. Inferir los requisitos resultantes de las decisiones de diseño.
PARA más INFORMACIÓN sobre cómo SELECCIONAR LAS SOLUCIONES de los com-
ponentes de producto y cómo DESARrOLLAR el diseño, consúltese el árEA de
proceso Solución TÉCNICA.
La selección de una tecnología trae consigo requisitos adicionales.
Por ejemplo, el uso de electrónica requiere requisitos tecnológicos
especí- ficos adicionales, tales como límites de interferencia
electromagnética.
Las decisiones de arquitectura, tales como la selección de
patrones de la arquitectura, introducen requisitos inferidos
adicionales para los componentes de producto. Por ejemplo, el
patrón de capas restringirá dependencias entre ciertos
3. Desarrollar los requisitos de arquitectura capturando los
atributos críticos de calidad y las medidas de atributos de
calidad necesarios para establecer la arquitectura y el diseño
del producto.
algunos ejemplos de medidas de los atributos de calidad son:

 respuesta dentro de 1 segundo.
 disponibilidad del sistema en un 99% del tiempo.
 Implementar un cambio con no más de una semana de esfuerzo del
personal.
4. Establecer y mantener las relaciones entre los requisitos para

su consideración durante la gestión del cambio y la asignación
de los requisitos.
PARA más INFORMACIÓN sobre cómo MANTENER LA TRAZABILIDAD bidirECCIONAL
de los requisitos, consúltese el árEA de proceso Gestión de Requisitos.
Las relaciones entre los requisitos pueden ayudar en la evaluación
del impacto de los cambios.
SP 2.2 aSiGnar loS requiSitoS De comPonente De ProDucto

Asignar los requisitos para cada componente de producto.
PARA más INFORMACIÓN sobre cómo SELECCIONAR LAS SOLUCIONES del componente de
producto, consúltese el árEA de proceso Solución TÉCNICA.
La arquitectura del producto proporciona la base para asignar los

requisitos de producto a los componentes de producto. Los
requisitos para los componentes de producto de la solución
definida incluyen la asignación de la prestación del producto; las
restricciones de diseño; y el ajuste, la forma y la función para
cumplir los requisitos y facilitar la producción. En los casos
donde un requisito de nivel más alto especifique un atributo de
calidad que sea responsabilidad de más de un componente de
producto, el atributo de calidad puede a veces dividirse para la
asignación única a cada componente de producto como un
requisito inferido, sin embargo, otras veces el requisito comparti-
do debería, en su lugar, estar asignado directamente a la
arquitectura. Por ejemplo, la asignación de requisitos
compartidos a la arquitectura podría describir cómo se
presupuesta un requisito de rendimiento (p. ej, en capacidad de
respuesta) entre los componentes, de forma que se contabilice de
inicio a fin la forma de realizar el requisito. Este concepto de
requisitos compartidos puede extenderse a otros atributos de
calidad de arquitectura significativos (p. ej, seguridad, fiabilidad).
1. Hojas de asignación de requisitos.
2, Asignaciones provisionales de requisitos.
3. Restricciones de diseño.
4. Requisitos inferidos.
5. Relaciones entre requisitos inferidos.
SUBPRÁCTICAS
1. Asignar los requisitos a las funciones.
2. Asignar los requisitos a los componentes de producto y a la
arquitectura.
3. Asignar las restricciones de diseño a componentes de producto
y a la arquitectura.
4. Asignar requisitos a las entregas incrementales.
5. Documentar las relaciones entre requisitos asignados.
Las relaciones incluyen las dependencias en que un cambio en
un requisito puede afectar a otros requisitos.
SP 2.3 idEnTificar los rEquisiTos dE inTErfaz

Identificar los requisitos de interfaz.
Se identifican las interfaces entre las funciones (o entre objetos u

otras entidades lógicas). Las interfaces pueden conducir el
desarrollo de soluciones alternativas descritas en el área de
proceso Solución Técnica.
PARA más INFORMACIÓN sobre cómo ASEGURAR LA COMPATIBILIDAD de interFACES, con-
Se definen los requisitos de interfaz entre los productos o
componentes de producto identificados en la arquitectura del
producto. Es- tos requisitos se controlan como parte de la
integración del producto y del componente de producto y son una
parte integral de la definición de la arquitectura.
RD
1. Requisitos de interfaz.
SUBPRÁCTICAS
1. Identificar las interfaces tanto externas como internas al
producto (p. ej., entre las particiones funcionales u objetos).
A medida que progresa el diseño, la arquitectura del producto
será alterada por los procesos de la solución técnica, creando
nuevas interfaces entre los componentes de producto y los
componentes externos al producto.
Deberían identificarse también las interfaces con los procesos del
ciclo de vida relativos al producto.
algunos ejemplos de estas interfaces son las interfaces con el equipo de

pruebas, con los sistemas de transporte, con los sistemas de soporte y con
las instalaciones de fabricación.
2. Desarrollar los requisitos para las interfaces identificadas.

PARA más INFORMACIÓN sobre cómo DISEÑAR LAS interFACES USANDO criterios,
consúltese el árEA de proceso Solución TÉCNICA.
Los requisitos para las interfaces se definen en términos tales
como el origen, el destino, el estímulo, las características de los
datos para el software, y las características eléctricas y mecánicas
para el hardware.
SG 3 analizar y valiDar requiSitoS

Los requisitos se analizan y validan.
Las prácticas específicas de la meta específica Analizar y validar

requisitos dan soporte al desarrollo de los requisitos, tanto en la
meta específica Desarrollar los requisitos de cliente como en la
meta específica Desarrollar los requisitos de producto. Las
prácti- cas específicas asociadas a esta meta específica cubren el
análisis y la validación de los requisitos con respecto al entorno
previsto del usuario final.
Los análisis se realizan para determinar qué impacto tendrá el
entorno de operación previsto sobre la capacidad para satisfacer
las necesidades, las expectativas, las restricciones y las interfaces
de las partes interesadas. Deberían tenerse en cuenta
consideraciones como la viabilidad, las necesidades de la misión,
las restricciones de coste, el tamaño del mercado potencial y la
estrategia de la adquisición, dependiendo del contexto del
producto. Los atributos de calidad de la arquitectura
significativos se identifican en base a la misión y a los factores del
negocio. También se establece una definición de la funcionalidad
requerida y de los atributos de calidad. Se consideran todos los
modos de uso especificados para el producto.
Los objetivos de los análisis son determinar los requisitos candi-
datos para los conceptos del producto que satisfarán las
necesidades, las expectativas y las restricciones de las partes
interesadas, y entonces traducir estos conceptos en requisitos.
Paralelamente a esta actividad, los parámetros que se utilizarán
para evaluar la eficacia del producto se determinan en base a las
entradas del cliente y al concepto preliminar del producto.
Los requisitos se validan para incrementar la probabilidad de
que el producto resultante funcione según lo previsto en el
entorno de uso.
SP 3.1 E sTablEcEr los concEpTos y los EscEnarios dE opEración
Establecer y mantener los conceptos y los escenarios de operación asociados.
Un escenario es normalmente una secuencia de eventos que

podrían ocurrir en el desarrollo, uso o soporte del producto, el cual
se usa para hacer explícitas algunas de las necesidades funcionales o
de los atributos de calidad de las partes interesadas. Por el contrario,
un concepto operacional para un producto depende generalmente
tanto de la solución de diseño como del escenario. Por ejemplo, el
concepto operacional para un producto de comunicaciones basado
en satélites es completamente diferente de uno basado en
comunicaciones por tierra. Puesto que las soluciones alternativas
generalmente no han sido definidas cuando se preparan los
conceptos de operación iniciales, las soluciones conceptua- les se
desarrollan para su uso cuando se analizan los requisitos. Los con-
ceptos operacionales se refinan a medida que se toman las
decisiones de la solución y se desarrollan los requisitos detallados
de más bajo nivel.
Al igual que una decisión de diseño para un producto puede llegar
a ser un requisito para un componente de producto, el concepto
de operación puede llegar a ser los escenarios (requisitos) para
los componentes de producto. Los conceptos y los escenarios de
operación evolucionan para facilitar la selección de soluciones
del componente de producto que, cuando se implementan,
satisfarán el uso previsto del producto o facilitarán su desarrollo
y soporte. Los conceptos y los escenarios de operación
documentan la interacción de los componentes de producto con
el entorno, con los usuarios finales y con otros componentes de
producto, independientemente de la disciplina de ingeniería.
Estos conceptos se deberían documentar para todos los modos y
los estados dentro de las operaciones, del desarrollo del pro-
ducto, del despliegue, de la entrega, del soporte (incluyendo el
mantenimiento y soporte), de la formación y de la retirada.
Los escenarios pueden desarrollarse para tratar secuencias de ope-
ración, de soporte, de desarrollo o de otros eventos.
1. Concepto operacional.
RD
2. Desarrollo, instalación, operación, mantenimiento y conceptos
de soporte del producto o componente de producto.
3. Conceptos de retirada.
4. Casos de uso.
5. Escenarios de cronología.
6. Nuevos requisitos.
SUBPRÁCTICAS
1. Desarrollar los conceptos y los escenarios de operación que
inclu- yan operaciones, instalación, desarrollo,
mantenimiento, soporte y retirada según sea apropiado.
Identifique y desarrolle los escenarios, consistentes con el nivel
de detalle de las necesidades, las expectativas y las restricciones
de las partes interesadas en las cuales se espera que funcione el
producto o componente de producto propuesto.
Aumente los escenarios con las consideraciones de los atributos de
calidad para las funciones (u otras entidades lógicas) descritas en los
escenarios.
2. Definir el entorno en el que funcionará el producto o
componente de producto, incluyendo los límites y las
restricciones.
3. Revisar los conceptos y los escenarios de operación para
refinar y descubrir requisitos.
El concepto y el desarrollo del escenario de operación es un
proceso iterativo. Para asegurar que éstos están de acuerdo con
los requisitos, deberían mantenerse revisiones periódicamente. La
revisión puede ser un walkthrough.
4. Desarrollar un concepto de operación detallado, a medida que
se seleccionan los productos y los componentes de producto,
que define la interacción del producto, del usuario final y
del entorno, y que satisfaga las necesidades operativas, de
mantenimiento, de soporte y de retirada.
SP 3.2 EsTablEcEr una dEfinición dE la funcionalidad y dE los aTribuTos dE calidad rEquEridos

Establecer y mantener una definición de funcionalidad y de los atributos de
calidad requeridos.
Una aproximación para definir la funcionalidad y los atributos de

calidad requeridos es analizar escenarios utilizando lo que
llamamos “análisis funcional” para describir lo que se pretende que
haga el producto. Esta descripción funcional puede incluir
acciones, secuencia, entradas, salidas u otra información que
comunique la forma en la que se utilizará el producto. La
descripción resultante de las funciones, agrupaciones lógicas de
funciones y su asociación con los requisitos se denomina como
arquitectura funcional (véanse las definiciones de “análisis
funcional” y “arquitectura funcional” en el glosario).
Estas aproximaciones han evolucionado en años recientes a
través de la introducción de lenguajes, métodos y herramientas
de descrip- ción de la arquitectura para tratar y caracterizar de
forma más completa los atributos de calidad, permitiendo una
especificación más rica de las restricciones sobre cómo la
funcionalidad definida se realizará en el producto (p.ej.,
multidimensional), y facilitando análisis adicionales de los
requisitos y las soluciones técnicas. Algunos atributos de calidad
que surgirán serán significativos para la arquitectura y así
conducirán el desarrollo de la arquitectura del producto. Estos
atributos de calidad reflejan a menudo temas transversales que no
se pudieron asignar a los elementos del nivel más bajo de una
solución. Una comprensión clara de los atributos de calidad y de
su importancia en base a la misión o necesidades del negocio es
una entrada esencial al proceso de diseño.
1. Definición de funcionalidad y de atributos de calidad requeridos.
2. Arquitectura funcional.
3. Diagramas de actividad y casos de uso.
4. Análisis orientado a objetos con servicios o métodos identificados.
5. Requisitos de los atributos de calidad significativos para la arquitectura.
SUBPRÁCTICAS
1. Determinar la misión clave y los factores de negocio.
2. Identificar la funcionalidad y los atributos de calidad deseados.
La funcionalidad y los atributos de calidad pueden ser
identificados y definidos con las partes interesadas relevantes a
través de un análisis de diversos escenarios según lo descrito en la
práctica específica anterior.
3. Determinar los atributos de calidad significativos para la
arquitectura en base a la misión clave y los factores del
negocio.
4. Analizar y cuantificar la funcionalidad requerida por los
usuarios finales.
Este análisis puede implicar considerar la secuencia de funciones
crí- ticas de tiempo.
5. Analizar los requisitos para identificar las particiones lógicas o
funcionales (p. ej., subfunciones).
6. Dividir los requisitos en grupos, en base a los criterios
establecidos (p. ej., funcionalidad similar, requisitos similares de
atributos de calidad, acoplamiento) para facilitar y enfocar el
análisis de requisitos.
7. Asignar los requisitos de cliente a las particiones funcionales,
objetos, personal o elementos de soporte para dar apoyo a la
síntesis de las soluciones.
8. Asignar los requisitos a las funciones y a las subfunciones (u
otras entidades lógicas).
SP 3.3 a nalizar los rEquisiTos
Analizar los requisitos para asegurarse que son necesarios y suficientes.
RD
Teniendo en cuenta el concepto y los escenarios de operación, los
requisitos para el nivel uno de la jerarquía del producto se
analizan para determinar si son necesarios y suficientes para cumplir
con los objetivos de niveles más altos de la jerarquía del producto.
Los requisitos analizados, posteriormente, proporcionan la base
para requisitos más detallados y precisos en los niveles más bajos
de la jerarquía del producto.
A medida que se definen los requisitos, debería comprenderse
su relación con los requisitos de nivel más alto y la definición de
más alto nivel de la funcionalidad y los atributos de calidad
requeridos. Tam- bién, se determinan los requisitos clave que se
utilizarán para realizar
el seguimiento del progreso. Por ejemplo, el peso de un producto
o el tamaño de un producto software pueden monitorizarse
durante el desarrollo en base al riesgo o la criticidad que tienen
para el cliente.
PARA más INFORMACIÓN sobre cómo ESTABLECER los procedimientos y criterios de
VERIFICACIÓN, consúltese el árEA de proceso VERIFICACIÓN.

1. Informes de defectos de los requisitos.
2. Cambios propuestos a los requisitos para resolver defectos.
3. Requisitos clave.
4. Medidas de rendimiento técnico.
SUBPRÁCTICAS
1. Analizar las necesidades, las expectativas, las restricciones y
las interfaces externas de las partes interesadas para
organizarlas en temas relacionados y eliminar conflictos.
2. Analizar los requisitos para determinar si satisfacen los
objetivos de los requisitos de nivel más alto.
3. Analizar los requisitos para asegurarse que son completos,
factibles, realizables y verificables.
Mientras que el diseño determina la viabilidad de una solución
particular, esta subpráctica trata de conocer qué requisitos
afectan a la viabilidad.
4. Identificar los requisitos clave que tienen una fuerte influencia
en el coste, el calendario, el rendimiento o el riesgo.
5. Identificar las medidas técnicas de rendimiento que serán
seguidas durante el esfuerzo de desarrollo.
PArA más informAción sobre cómo desArrollAr y sostener unA cApAcidAd de
medición utilizAdA pArA dAr soporte A lAS necesidAdes de informAción de lA
gerenciA, consúltese el áreA de proceso Medición y Análisis.
6. Analizar los conceptos y los escenarios de operación para
refinar las necesidades, las restricciones y las interfaces del
cliente, y para Inferir nuevos requisitos.
Este análisis puede dar lugar a conceptos y a escenarios de
operación más detallados, así como al soporte de la inferencia de
nuevos requisitos.
SP 3.4 a nalizar los rEquisiTos para consEguir un Equilibrio

Analizar los requisitos para equilibrar las necesidades y las restricciones de las
partes interesadas.
Las necesidades y las restricciones de las partes interesadas

pueden tratar temas como coste, calendario, rendimiento del
proyecto o producto, funcionalidad, prioridades, componentes
reutilizables, facilidad de mantenimiento o riesgo.
Ejemplo de productos de TRABAJO típicos
1. Evaluación de los riesgos relativos a los requisitos.
SUBPRÁCTICAS
1. Usar modelos, simulaciones y prototipos probados para
analizar el equilibrio entre las necesidades y las restricciones
de las partes interesadas.
Los resultados de los análisis pueden usarse para reducir el coste
del producto y el riesgo del desarrollo del producto.
2. Realizar una evaluación de riesgos sobre los requisitos y la
defini- ción de funcionalidad y atributos de calidad requeridos.
3. Examinar los conceptos del ciclo de vida del producto en
cuanto a los impactos de los requisitos en los riesgos.
4. Evaluar el impacto de los requisitos de los atributos de calidad
significativos para la arquitectura en el producto y en los
costes y riesgos del desarrollo del producto.
Cuando el impacto de los requisitos en costes y riesgos parece
superar el beneficio percibido, debería consultarse a las partes
interesadas relevantes para determinar qué cambios pueden ser
necesarios.
Como ejemplo, un requisito tiempo-respuesta realmente ajustado
o un requisito de alta-disponibilidad, podría demostrar un coste
alto de implementación. Quizás el requisito podría relajarse una
vez que se entienden los impactos (p. ej., en coste).
SP 3.5 V alidar los rEquisiTos

Validar los requisitos para asegurar que el producto resultante funcione según
lo previsto en el entorno del usuario final.
La validación de los requisitos se ejecuta en etapas tempranas del

desarrollo con los usuarios finales para ganar confianza en que
los requisitos sean capaces de guiar un desarrollo que dé como
resultado una validación final de éxito. Esta actividad debería
RD
integrarse con las actividades de gestión de riesgos. Las
organizaciones maduras normalmente realizarán la validación
de los requisitos de una manera más sofisticada, usando múltiples
técnicas y ampliarán la base de la validación para incluir otras
necesidades y expectativas de las partes interesadas.
algunos ejemplos de técnicas usadas para la validación de los requisitos

son:
 análisis.
 simulaciones.
 prototipos.
 demostraciones.

1. Registro de los métodos y resultados del análisis.
SUBPRÁCTICAS
1. Analizar los requisitos para determinar el riesgo de que el
produc- to resultante no funcione apropiadamente en el
entorno de uso previsto.
2. Explorar la adecuación y la completitud de los requisitos desa-
rrollando representaciones del producto (p. ej., prototipos, si-
mulaciones, modelos, escenarios, guiones gráficos) y
obteniendo realimentación sobre ellos de las partes interesadas
relevantes.
PARA más INFORMACIÓN sobre cómo prEPARAR LA VALIDACIÓN y VALIDAR los
productos y los componentes de producto, consúltese el árEA de proceso
VALIDACIÓN.
3. Evaluar el diseño a medida que madure en el contexto del
entorno de validación de los requisitos para identificar las
cuestiones de validación, y para exponer necesidades y
requisitos de cliente sin especificar.
GESTIÓN DE REQUISITOS
Propósito
El propósito de la Gestión de Requisitos (REQM) es gestionar
los requisitos de los productos y los componentes de producto
del proyecto, y asegurar la alineación entre esos requisitos, y los
planes y los productos de trabajo del proyecto.
Los procesos de gestión de requisitos gestionan todos los
requisitos recibidos o generados por el proyecto, incluyendo
tanto los requisitos técnicos como los no técnicos, así como los
requisitos impuestos al proyecto por la organización.
En particular, si se implementa el área de proceso Desarrollo
de Requisitos, sus procesos generarán requisitos de producto y de
componente de producto que también serán gestionados por los
procesos de gestión de requisitos.
En todas las áreas de proceso, cuando se utilizan los términos
“producto” y “componente de producto”, sus significados previstos
tam- bién incluyen los servicios, los sistemas de servicio y sus
componentes. Cuando las áreas de proceso Gestión de
Requisitos, Desarrollo de Requisitos y Solución Técnica están
implementadas, sus procesos asociados pueden estar
estrechamente relacionados y realizarse de mane-
ra concurrente.
El proyecto realiza los pasos apropiados para asegurar que el
conjunto de requisitos aprobados se gestiona para dar soporte a
las necesidades de planificación y de ejecución del proyecto.
Cuando un proyecto recibe requisitos de un proveedor de
requisitos aprobado, éstos se revisan con dicho proveedor para
resolver las cuestiones y para prevenir malentendidos antes de
que los requisitos se incorporen en los planes del proyecto. Una
vez que el proveedor y el receptor de los requisitos alcanzan un
acuerdo, se obtiene un compromiso sobre los requisitos por parte
de los participantes en el proyecto. El proyec- to gestiona los
cambios a los requisitos a medida que evolucionan e identifica
inconsistencias que ocurren entre los planes, los productos de
REQM
trabajo y los requisitos.
473
Una parte de la gestión de requisitos es documentar los
cambios a los requisitos y su análisis razonado, y mantener la
trazabilidad bidireccional entre los requisitos fuente, todos los
requisitos de producto y de componente de producto, y otros
productos de trabajo especificados (véase la definición de
“trazabilidad bidireccional” en el glosario).
Todos los proyectos tienen requisitos. En el caso de
actividades de mantenimiento, los cambios se basan en los
cambios a los requisitos, al diseño o a la implementación
existentes. En proyectos que entregan incrementos de la
capacidad del producto, los cambios también se pueden deber a la
evolución de las necesidades del cliente, a la madurez u
obsolescencia de la tecnología y a la evolución de los estándares.
En ambos casos, los cambios a los requisitos, si existen, podrían
documentarse en peticiones de cambio del cliente o de los
usuarios finales, o podrían tomar la forma de nuevos requisitos
recibidos del proceso de desarrollo de requisitos.
Independientemente de su fuente o forma, las actividades que son
dirigidas por cambios a los requisitos se gestionan
consecuentemente.
en entornos ágiles, los requisitos se comunican y se siguen a través

de mecanismos, tales como, backlog de producto, tarjetas de historia
y maquetas de pantallas. Los compromisos a los requisitos se hacen
bien colectivamente por el equipo o por un líder de equipo autorizado.
Las asignaciones del trabajo se ajustan regularmente (p.ej., diaria,
semanalmente) en base al progreso obtenido y por una mejor
comprensión de los requisitos y de la solución. La trazabilidad y la
consistencia entre los requisitos y los productos de trabajo se tratan
a través de los mecanismos ya mencionados, así como durante las
actividades de comienzo de iteración o de fin de iteración, tales como,
“reuniones de retrospectiva” y “días demo” (véase “Interpretando CMMI
al utilizar enfoques Ágiles” en la primera parte).

cliente, de producto y de componente de producto, consúltese el árEA de proceso
A requisitos, consúltese el árEA de proceso Solución TÉCNICA.
PARA más INFORMACIÓN sobre cómo ESTABLECER LAS LÍNEAS BASE y contrOLAR y seguir
los CAMBIOS, consúltese el árEA de proceso Gestión de CONFIGURACIÓN.
Gestión de requisitos 475
PARA más INFORMACIÓN sobre cómo MONITORIZAR el proyecto frente AL PLAN y gestio-
NAR LA TOMA de ACCIONES corrECTIVAS HASTA SU cierre, consúltese el árEA de proceso
MONITORIZACIÓN y Control del Proyecto.
PARA más INFORMACIÓN sobre cómo ESTABLECER y MANTENER los PLANES que definen LAS
ACTIVIDADES del proyecto, consúltese el árEA de proceso PLANIFICACIÓN del Proyecto.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR y ANALIZAR los riesgos, consúltese el
árEA de proceso Gestión de Riesgos.

sg 1 gestionar los requisitos.
sp 1.1 Comprender los requisitos.
sp 1.2 Obtener el compromiso sobre los requisitos.
sp 1.3 gestionar los cambios a los requisitos.
sp 1.4 Mantener la trazabilidad bidireccional de los requisitos.
sp 1.5 asegurar el alineamiento entre el trabajo del proyecto y los
requisitos.
SG 1 GeStionar loS requiSitoS

Los requisitos se gestionan y las inconsistencias con los planes y productos de
trabajo del proyecto se identifican.
El proyecto mantiene un conjunto actual y aprobado de requisitos

durante la vida del proyecto haciendo lo siguiente:
• Gestionando todos los cambios a los requisitos.
• Manteniendo las relaciones entre los requisitos, los planes del
proyecto y los productos de trabajo.
• Asegurando la alineación entre los requisitos, los planes del
proyecto y los productos de trabajo.
• Tomando acciones correctivas.
PARA más INFORMACIÓN sobre cómo ANALIZAR y VALIDAR los requisitos, consúltese el
árEA de proceso DESARrollo de Requisitos.
PARA más INFORMACIÓN sobre cómo DETERMINAR LA VIABILIDAD de los requisitos, con-
súltese LA PRÁCTICA ESPECÍFICA DESARrollo de soluciones ALTERNATIVAS y criterios de
selección del árEA de proceso Solución TÉCNICA.
PARA más INFORMACIÓN sobre cómo GESTIONAR ACCIONES corrECTIVAS HASTA SU cierre,
REQM

SP 1.1 comprEndEr los rEquisiTos
Desarrollar una comprensión del significado de los requisitos con los provee-
dores de los requisitos.
A medida que madura el proyecto y se derivan los requisitos,

todas las actividades o disciplinas recibirán requisitos. Para evitar
el flujo continuo de requisitos, se establecen criterios para
designar los canales apropiados o las fuentes oficiales desde las
que se reciben los requisitos. Aquellos que reciben los requisitos,
los analizan con el proveedor para asegurar que se alcanza una
comprensión compatible y compartida del significado de los
requisitos. El resultado de estos análisis y diálogos es un
conjunto de requisitos aprobados.

1. Listas de criterios para distinguir a los proveedores apropiados
de requisitos.
2. Criterios para la evaluación y la aceptación de los requisitos.
3. Resultados del análisis frente a los criterios.
4. Un conjunto de requisitos aprobados.
SUBPRÁCTICAS
1. Establecer criterios para distinguir a los proveedores
apropiados de requisitos.
2. Establecer criterios objetivos para la evaluación y aceptación de
los requisitos.
La falta de criterios de evaluación y de aceptación da lugar a
menudo a una verificación inadecuada, un retrabajo costoso o el
rechazo del cliente.
algunos ejemplos de criterios de evaluación y de aceptación son:

 Claramente y correctamente establecidos.
 Completos.
 Consistentes unos conotros.
 Identificados de forma única.
 Consistentes con el enfoque de la arquitectura y con las prioridades de
los atributos de calidad.
 apropiados para implementar.
 Verificables (es decir, que se pueden probar).
 trazables.
 alcanzables.
 Vinculados al valor de negocio.
 Identificados como una prioridad para el cliente.
3. Analizar los requisitos para asegurar que se cumplen los
criterios establecidos.
4. Alcanzar una comprensión de los requisitos con los
proveedores de requisitos para que los participantes del
proyecto puedan comprometerse con ellos.
SP 1.2 o bTEnEr El compromiso sobrE los rEquisiTos
Obtener el compromiso de los participantes del proyecto sobre los requisitos.
PARA más INFORMACIÓN sobre cómo MONITORIZAR los compromisos, consúltese el
árEA de proceso MONITORIZACIÓN y Control del Proyecto.
La práctica específica anterior se ocupó de alcanzar una comprensión

con los proveedores de los requisitos. Esta práctica específica se
ocupa de los acuerdos y compromisos entre aquellos que llevan a
cabo las actividades necesarias para implementar los requisitos. Los
requisitos evolucionan a lo largo del proyecto. A medida que los
requisitos evolucionan, esta prác- tica específica asegura que los
participantes del proyecto se comprometen con los requisitos
actuales y aprobados, y con los cambios resultantes en los planes,
actividades y productos de trabajo del proyecto.

1. Evaluaciones del impacto de los requisitos.
2. Compromisos documentados de los requisitos y de sus cambios.
SUBPRÁCTICAS
1. Evaluar el impacto de los requisitos sobre los compromisos
existentes. El impacto sobre los participantes del proyecto se
debería evaluar cuando cambian los requisitos o al principio de
un nuevo requisito.
2. Negociar y registrar los compromisos.
Los cambios a los compromisos existentes se deberían negociar
antes de que los participantes del proyecto se comprometan con
un nuevo requisito o un cambio a un requisito.
SP 1.3 gEsTionar los cambios a los rEquisiTos

Gestionar los cambios a los requisitos a medida que evolucionan durante el
proyecto.
PARA más INFORMACIÓN sobre cómo seguir y contrOLAR los CAMBIOS, consúltese el
Los requisitos cambian por diversas razones. A medida que

cambian las necesidades y avanza el trabajo, es posible que se
tengan que hacer cambios a los requisitos existentes. Es esencial
REQM
gestionar estas adiciones y cambios, eficiente y eficazmente. Para

analizar con eficacia el impacto de los cambios, es necesario que
se conozca la fuente de
cada requisito y que esté documentado el análisis razonado de
cualquier cambio. El proyecto puede querer seguir medidas
apropiadas de volatilidad de los requisitos para juzgar si es
necesario un enfoque nuevo o modificado para el control de
cambios.

1. Petición de cambio de requisitos.
2. Informes de impacto del cambio de requisitos.
3. Estado de los requisitos.
4. Base de datos de requisitos.
SUBPRÁCTICAS
1. Documentar todos los requisitos y los cambios a los requisitos
que se reciben o generan por el proyecto.
2. Mantener una historia de cambios de los requisitos,
incluyendo el análisis razonado de los cambios.
Mantener la historia de cambios ayuda a seguir la volatilidad de
los requisitos.
3. Evaluar el impacto de los cambios de requisitos desde el
punto de vista de las partes interesadas relevantes.
Los cambios a los requisitos que afectan a la arquitectura del
producto pueden afectar a muchas partes interesadas.
4. Poner a disposición del proyecto los requisitos y los datos de
los cambios.
SP 1.4 m anTEnEr la Trazabilidad bidirEccional dE los rEquisiTos
Mantener la trazabilidad bidireccional entre los requisitos y los productos de
trabajo.
La intención de esta práctica específica es mantener la

trazabilidad bidireccional de los requisitos (véase la definición de
“trazabilidad bidireccional” en el glosario). Cuando se gestionan
bien los requisitos, se puede establecer la trazabilidad desde un
requisito fuente hasta sus requisitos de más bajo nivel y desde
estos requisitos de más bajo nivel de vuelta hasta sus requisitos
fuente. Esta trazabilidad bidireccional ayuda a determinar si
todos los requisitos fuente se han tratado totalmente y si todos
los requisitos de nivel más bajo pueden trazarse hacia una fuente
válida.
La trazabilidad de los requisitos también cubre las relaciones
a otras entidades, tales como productos de trabajo intermedios y
finales, cambios en la documentación de diseño y planes de
pruebas. La trazabilidad puede cubrir relaciones horizontales,
tales como relaciones entre interfaces, así como relaciones
verticales. La trazabilidad es particularmente necesaria al
evaluar el impacto de los cambios de los requisitos sobre las
actividades del proyecto y los productos de trabajo.
algunos ejemplos de aspectos de trazabilidad a considerar son:

 alcance de la trazabilidad: los límites dentro de los cuales es necesaria
la trazabilidad.
 definición de trazabilidad: los elementos que necesitan relaciones lógicas.
 tipos de trazabilidad: cuándo es necesaria la trazabilidad horizontal y
la vertical.
La trazabilidad bidireccional no siempre está automatizada.

Ésta se puede hacer manualmente utilizando hojas de cálculo,
bases de datos u otras herramientas comunes.
1. Matriz de trazabilidad de los requisitos.
2. Sistema de seguimiento de los requisitos.
SUBPRÁCTICAS
1. Mantener la trazabilidad de los requisitos para asegurar que la
fuente de los requisitos de nivel más bajo (es decir, inferidos)
está documentada.
2. Mantener la trazabilidad de los requisitos desde un requisito a
sus requisitos inferidos y a la asignación a los productos de
trabajo.
Los productos de trabajo para los cuales la trazabilidad se puede
mantener incluyen la arquitectura, los componentes de
producto, las iteraciones de desarrollo (o incrementos), las
funciones, las interfaces, los objetos, las personas, los procesos y
otros productos de trabajo.
3. Generar una matriz de trazabilidad de requisitos.
SP 1.5 a sEgurar El alinEamiEnTo EnTrE El Trabajo dEl proyEcTo y los rEquisiTos
Asegurar que los planes del proyecto y los productos de trabajo permanecen
alineados con los requisitos.
Esta práctica específica encuentra las inconsistencias entre los

requisitos, los planes del proyecto y los productos de trabajo, e
inicia acciones correctivas para resolverlas.
1. Documentación de inconsistencias entre los requisitos y los planes
del proyecto y los productos de trabajo, incluyendo fuentes y
condiciones.
SUBPRÁCTICAS
1. Revisar los planes del proyecto, las actividades y los
REQM
productos de trabajo en cuanto a la consistencia con los

requisitos y los cambios realizados sobre ellos.
2. Identificar la fuente de la inconsistencia (si existe).
3. Identificar cualquier cambio que se debería realizar a los planes
y a los productos de trabajo resultantes de los cambios a la
línea base de requisitos.
4. Iniciar cualquier acción correctiva necesaria.
RSKM
GESTIÓN DE RIESGOS
Propósito
El propósito de la Gestión de Riesgos (RSKM) es identificar
problemas potenciales antes de que ocurran, para que las
actividades de tratamiento de riesgos puedan planificarse e
invocarse según sea necesario a lo largo de la vida del producto o
del proyecto para mitigar los impactos adversos sobre la
consecución de objetivos.
La gestión de riesgos es un proceso continuo, orientado hacia el
futuro que es una parte importante de la gestión de proyectos. La
gestión de riesgos debería tratar las cuestiones que podrían poner
en peligro el logro de los objetivos críticos. Una aproximación de
gestión de riesgos continua anticipa y mitiga eficazmente los
riesgos que puedan tener un impacto crítico sobre un proyecto.
Una gestión de riesgos eficaz incluye la identificación
temprana y dinámica de los riesgos a través de la colaboración e
involucración de las partes interesadas relevantes, tal y como se
describió en el plan de involucración de las partes interesadas
tratado en el área de proceso Planificación del Proyecto. Se
necesita un fuerte liderazgo entre todas las partes interesadas
relevantes para establecer un entorno para la libre y abierta
divulgación y discusión de los riesgos.
La gestión de riesgos debería considerar fuentes tanto internas
como externas, así como técnicas y no técnicas, de coste, de
calendario y de rendimiento y de otros riesgos. La detección
temprana y dinámica de riesgos es importante porque normalmente
es más fácil, menos costosa y menos perjudicial hacer los cambios y
corregir los esfuerzos de trabajo durante las fases iniciales del
proyecto, en lugar de hacerlo en fases posteriores.
Por ejemplo, las decisiones relacionadas con la arquitectura del
producto a menudo se toman de forma temprana antes de
comprender totalmente el impacto que puedan tener y, por lo
tanto, las implicaciones de los riesgos de esas opciones deberían
considerarse cuidadosamente. Los estándares de la industria
pueden ayudar en el momento de determinar cómo prevenir o
mitigar riesgos específicos comúnmente encontrados en una
industria particular. Ciertos riesgos pueden ser gestionados o
mitigados proactivamente mediante la revisión de bue-
nas prácticas y las lecciones aprendidas de la industria.
481
La gestión de riesgos se puede dividir en las siguientes partes:
• Definir una estrategia de gestión de riesgos.

• Identificar y analizar los riesgos.
• Tratar los riegos identificados, incluyendo la implementación
de planes de mitigación de riesgos, según sea necesario.
Como se representó en las áreas de proceso Planificación del

Pro- yecto, y Monitorización y Control del Proyecto, las
organizaciones inicialmente pueden enfocarse en la
identificación del riesgo para tomar conciencia, y reaccionar
ante la materialización de estos Riesgos a medida que ocurren. El
área de proceso Gestión de riesgos describe una evolución de
estas prácticas específicas para planificar, prevenir y mitigar los
riesgos sistemáticamente a fin de minimizar proactivamente su
impacto sobre el proyecto.
Aunque el énfasis principal del área de proceso Gestión de
Riesgos se realiza sobre el proyecto, estos conceptos también
pueden aplicarse para gestionar los riesgos de la organización.
en entornos Ágiles, algunas actividades de gestión de riesgos están

embebidas en el método ágil utilizado. por ejemplo, algunos riesgos técnicos
pueden tratarse fomentando la experimentación (primeros “fracasos”) o por la
ejecución de un “spike” fuera de la iteración de rutina. sin embargo, el área de
proceso gestión de riesgos fomenta una aproximación más sistemática para
gestionar riesgos, tanto técnicos como no técnicos. esta aproximación puede
ser integrada en una típica iteración ágil y en los ritmos de las reuniones;
más específicamente, durante la planificación, la estimación de la tarea y la
aceptación de las tareas de la iteración (consúltese “Interpretando CMMI al
utilizar enfoques Ágiles” en la primera parte).

PARA más INFORMACIÓN sobre cómo ANALIZAR posibles decisiones UTILIZANDO un pro-
ceso FORMAL de EVALUACIÓN que EVALÚE ALTERNATIVAS IDENTIFICADAS frente A criterios
PARA más INFORMACIÓN sobre cómo MONITORIZAR los riesgos del proyecto, consúltese
el árEA de proceso MONITORIZACIÓN y Control del Proyecto.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR riesgos del proyecto y PLANIFICAR LA
INVOLUCRACIÓN de LAS PARTES interESADAS, consúltese el árEA de proceso PLANIFICA-
ción del Proyecto.

sg 1. preparar la gestión de riesgos.
sp 1.1 determinar las fuentes y las categorías de riesgos.
sp 1.2 definir los parámetros de riesgos.
sp 1.3 establecer una estrategia de gestión de riesgos.
Gestión de riesgos 483
sg 2 Identificar y analizar los riesgos.
sp 2.1 Identificar los riesgos.
RSKM
sp 2.2 evaluar, clasificar y priorizar los riesgos.
sg 3 Mitigar los riesgos.
sp 3.1 desarrollar los planes de mitigación de riesgos.
sp 3.2 Implementar los planes de mitigación de riesgos.
SG 1 P reParar la GeStión De rieSGoS

La preparación de la gestión de riesgos se lleva a cabo.
Prepárese para la gestión de riesgos estableciendo y manteniendo una

estrategia para identificar, analizar y mitigar los riesgos.
Normalmente, esta estrategia se documenta en un plan de gestión de
riesgos. La estrategia de gestión de riesgos trata las acciones
específicas y el enfoque de gestión usado para aplicar y controlar el
programa de gestión de riesgos. La estrategia normalmente incluye
la identificación de las fuentes de riesgos, el esquema utilizado para
clasificar los riesgos y los parámetros usados para evaluar, limitar y
controlar los riesgos para su tratamiento eficaz.
SP 1.1 dETErminar las fuEnTEs y las caTEgorías dE riEsgos
Determinar las fuentes y las categorías de los riesgos.
Identificar las fuentes de riesgo proporciona una base para

examinar de forma sistemática las situaciones que cambian en el
tiempo para descubrir circunstancias que afectan a la capacidad
del proyecto para cumplir sus objetivos. Las fuentes de riesgo
son tanto internas como externas al proyecto. A medida que el
proyecto avanza, pueden identificarse fuentes de riesgo
adicionales. Establecer categorías para los riesgos proporciona un
mecanismo para recopilarlos y organizarlos, además de asegurar
el análisis apropiado y la atención que le dedica la gerencia a los
riesgos que puedan tener consecuencias serias para el
cumplimiento de los objetivos del proyecto.

1. Listas de fuentes de riesgos (externas e internas).
2. Lista de categorías de riesgos.
SUBPRÁCTICAS
1. Determinar las fuentes de riesgos.
Las fuentes de riesgos son parámetros fundamentales que causan
riesgos en un proyecto u organización. Hay muchas fuentes de
riesgos, tanto internas como externas a un proyecto. Las fuentes
de riesgo identifican dónde pueden originarse los riesgos.
algunas fuentes típicas de riesgo internas y externas son:

 requisitos inciertos.
 esfuerzos sin precedentes (p. ej., estimaciones no disponibles).
 diseño inviable.
 requisitos de atributos de calidad en competencia que afectan a la
selección de la solución y al diseño.
 tecnología no disponible.
 estimaciones o asignación de calendarios no realistas.
 recursos de personal y habilidades inadecuadas.
 Cuestiones de coste o financiación.
 Capacidad del subcontratista incierta o inadecuada.
 Capacidad del proveedor incierta o inadecuada.
 Comunicación inadecuada con los clientes actuales o potenciales o con
sus representantes.
 Interrupciones en la continuidad de las operaciones.
 restricciones reglamentarias (p. ej., seguridad, protección, entorno).
Muchas de estas fuentes de riesgo son aceptadas sin su

adecuada planificación. La identificación temprana de
fuentes de riesgo tanto internas como externas, puede llevar
a la identificación temprana de riesgos. Los planes de
mitigación de riesgos pueden implementarse, posteriormente,
en etapas tempranas del proyecto para prevenir la ocurrencia
de riesgos o reducir las consecuencias de su ocurrencia.
2. Determinar las categorías de riesgos.
Las categorías de riesgos son “agrupaciones” utilizadas para
recopilar y organizar los riesgos. Identificar las categorías de
riesgos ayuda a la futura consolidación de las actividades en los
planes de mitigación de riesgos.
Los siguientes factores pueden considerarse cuando se determinan las

categorías de riesgos:
 Fases del modelo del ciclo de vida del proyecto (p. ej., requisitos,
diseño, fabricación, prueba y evaluación, entrega, retirada).
 tipos de procesos utilizados.
 tipos de productos utilizados.
 riesgos de gestión de proyectos (p. ej., riesgos del contrato, riesgos del
presupuesto, riesgos de calendario, riesgos de recursos).
 riesgos técnicos de rendimiento (p. ej., riesgos relativos a los atributos
de calidad, riesgos de soporte).
Se puede utilizar una taxonomía de riesgos para proporcionar

un marco de trabajo para determinar las fuentes y las categorías de
riesgos.
SP 1.2 dEfinir los parámETros dE riEsgos
Definir los parámetros usados para analizar y clasificar los riesgos y para con-
RSKM
trolar el esfuerzo de la gestión de riesgos.
Algunos parámetros para evaluar, clasificar y priorizar los riesgos son:
• Probabilidad del riesgo (es decir, probabilidad de ocurrencia del riesgo).

• Consecuencia del riesgo (es decir, impacto y gravedad de la
ocurrencia del riesgo).
• Umbrales para desencadenar las actividades de gestión.
Los parámetros del riesgo se usan para proporcionar criterios

comunes y consistentes a fin de comparar los riesgos a
gestionar. Sin estos parámetros, es difícil medir la gravedad de un
cambio no deseado causado por un riesgo y priorizar las acciones
requeridas para planificar la mitigación del riesgo.
Los proyectos deberían documentar los parámetros utilizados
para analizar y categorizar los riesgos a fin de que estén
disponibles como referencia a lo largo de toda la vida del
proyecto, porque las circunstancias cambian con el tiempo.
Utilizando estos parámetros, los riesgos pueden fácilmente ser
re-clasificados y analizados cuando se producen los cambios.
El proyecto puede usar técnicas como análisis de modo de
fallo y de efectos (FMEA) para examinar los riesgos de fallos
potenciales en el producto o en los procesos seleccionados de
desarrollo del producto. Estas técnicas pueden ayudar a
proporcionar una disciplina de trabajo con los parámetros del
riesgo.
1. Criterios de evaluación, clasificación, y priorización de riesgos.
2. Requisitos de la gestión de riesgos (p. ej., niveles de control y
de aprobación, intervalos de reevaluación).
SUBPRÁCTICAS
1. Definir criterios consistentes para evaluar y cuantificar la
probabilidad del riesgo y los niveles de gravedad.
Los criterios utilizados de forma consistente (p. ej., límites de
probabilidad, niveles de gravedad) generalmente permiten que los
impactos de los diferentes riesgos sean comprendidos, para recibir
el nivel apropiado de análisis, y para garantizar la atención de la
dirección. En la gestión de riesgos distintos (p.ej., la protección de
los empleados frente a la conta- minación ambiental), es importante
asegurar la consistencia del resultado final (por ejemplo, un alto
impacto del riesgo de contaminación ambiental es tan importante
como un alto impacto del riesgo de protec- ción de los empleados).
Una forma de proporcionar una base común para comparar
diferentes riesgos es asignar valores económicos a los riesgos (p.ej.,
mediante un proceso de monetización del riesgo).
2. Definir los umbrales para cada categoría de riesgo.
Para cada categoría de riesgo, se pueden establecer umbrales que
de- terminen la aceptación o no aceptación, la priorización o la
activación de las acciones para gestionar los riesgos.
algunos ejemplos de umbrales son:

 Los umbrales a escala de proyecto podrían establecerse para involucrar
a la alta dirección cuando los costes del producto excedan el 10 por
ciento del coste objetivo o cuando los indicadores de rendimiento de
coste (CpIs) caigan por debajo del 0,95.
 Los umbrales de calendario podrían establecerse para involucrar a la alta
dirección cuando los indicadores de rendimiento de calendario (spIs)
caigan por debajo del 0,95.
 Los umbrales de rendimiento podrían establecerse para involucrar a
la alta dirección cuando los elementos clave especificados (p. ej., la
utilización del procesador, los tiempos medios de respuesta) superan
el 125 por ciento del diseño previsto.
3. Definir los límites de la extensión a la cual se aplican los

umbrales frente a una categoría o dentro de ella.
Existen pocos límites para los que los riesgos puedan evaluarse
de un modo cuantitativo o cualitativo. La definición de límites (o
condiciones del límite) puede usarse para ayudar a definir la
extensión del esfuerzo de gestión de riesgos y evitar excesivos
gastos de recursos. Los límites pueden llevar a la exclusión de
una fuente de riesgo en una categoría. Estos límites también
pueden excluir condiciones que ocurren por debajo de una
determinada frecuencia.
SP 1.3 E sTablEcEr una EsTraTEgia dE gEsTión dE riEsgos

Establecer y mantener la estrategia que se usará para la gestión de riesgos.
Una estrategia de gestión de riesgos exhaustiva trata elementos como:
• El alcance del esfuerzo de gestión de riesgos.

• Los métodos y las herramientas que se usarán para la
identificación de riesgos, su análisis, mitigación,
monitorización y comunicación.
• Las fuentes específicas de riesgos del proyecto.
• La forma en que los riesgos se organizarán, clasificarán,
compararán y consolidarán.
• Los parámetros usados para tomar acciones sobre los riesgos
identificados, incluyendo la probabilidad, la consecuencia y los
umbrales.
• Las técnicas de mitigación de riesgos que serán utilizadas, como
prototipos, pilotos, simulación, diseños alternativos o desarrollo
evolutivo.
• La definición de medidas de riesgos utilizadas para
monitorizar el estado de los riesgos.
• Los intervalos de tiempo para la monitorización o
reevaluación de los riesgos.
La estrategia de gestión de riesgos debería guiarse por una
visión común del éxito que describa los futuros resultados
deseados del proyecto, en términos del producto entregado, su
RSKM
coste y su ajuste a la tarea. La estrategia de gestión de riesgos a
menudo se documenta en un plan de gestión de riesgos para la
organización o el proyecto. Esta estrategia se revisa con las partes
interesadas relevantes para promover su compromiso y su
comprensión.
Una estrategia de gestión de riesgos debería desarrollarse en
etapas tempranas del proyecto, con el fin de que los riesgos
relevantes sean identificados y gestionados proactivamente. La
temprana identi- ficación y evaluación de riesgos críticos permite
al proyecto formular aproximaciones de tratamiento de riesgo y
ajustar la definición del proyecto y la asignación de recursos
basados en los riesgos críticos.
1. Estrategia de gestión de riesgos del proyecto.
SG 2 iDentificar y analizar loS rieSGoS

Los riesgos se identifican y analizan para determinar su importancia relativa.
El grado de riesgo afecta a los recursos asignados para manejar el

riesgo y al momento en el que se requiere la atención apropiada de la
gerencia. El análisis de riesgos implica la identificación de los
riesgos de las fuentes internas y externas identificadas, y la
evaluación de cada riesgo identificado para determinar su
probabilidad y consecuencias. La clasifi- cación de los riesgos,
basada en una evaluación frente a las categorías de riesgo
establecidas y los criterios desarrollados para la estrategia de ges-
tión de riesgos, proporciona información necesaria para su
tratamiento.
Los riesgos relacionados pueden agruparse para permitir el
tratamiento eficiente y el uso eficaz de los recursos de la gestión
de riesgos.
SP 2.1 idEnTificar los riEsgos
Identificar y documentar los riesgos.
La identificación de cuestiones potenciales, peligros, amenazas y

vulnerabilidades que podrían afectar negativamente a los esfuerzos
de trabajo o a los planes es la base para una gestión de riesgos sólida
y exitosa. Los riesgos deberían identificarse y describirse de forma
comprensible antes de que puedan analizarse y gestionarse
apropiadamente. Los riesgos se documentan en una declaración
concisa que incluye el contexto, las condiciones y las
consecuencias de la ocurrencia del riesgo.
La identificación de riesgos debería ser una aproximación
exhaustiva y organizada para buscar riesgos probables o reales en
la consecución de los objetivos. Para ser eficaz, la identificación de
riesgos no debería intentar tratar cada posible evento. El uso de las
categorías y los paráme- tros desarrollados en la estrategia de
gestión de riesgos y las fuentes de
riesgo identificadas pueden proporcionar la disciplina y la
coordinación apropiada para la identificación del riesgo. Los riesgos
identificados forman una línea base para el inicio de las actividades
de gestión de riesgos. Los riesgos deberían revisarse periódicamente
para reexaminar posibles fuentes de riesgos, y condiciones
cambiantes para descubrir fuentes y riesgos que se omitieron o no
existían previamente cuando fue actualizada la estrategia de
gestión de riesgos por última vez.
La identificación de riesgos no se enfoca en la asignación de
culpas sino en la propia identificación de los riesgos. Los
resultados de las actividades de identificación de riesgos nunca
deberían ser utilizados por la gerencia para evaluar el rendimiento
de los individuos.
se utilizan muchos métodos para identificar los riesgos. algunos métodos

típicos de identificación son:
 examinar cada elemento de la estructura de descomposición del
trabajo del proyecto.
 Llevar a cabo una evaluación de riesgos usando una taxonomía de
riesgos.
 entrevistar a expertos en la materia en cuestión.
 revisar los esfuerzos de gestión de riesgos de productos similares.
 examinar los documentos o bases de datos de lecciones aprendidas.
 examinar las especificaciones de diseño y los requisitos del acuerdo.

1. Lista de riesgos identificados, incluyendo el contexto, las
condiciones y las consecuencias de la ocurrencia del riesgo.
SUBPRÁCTICAS
1. Identificar los riesgos asociados con el coste, el calendario y
el rendimiento.
Los riesgos asociados con el coste, el calendario, el rendimiento
y otros objetivos de negocio deberían examinarse para
comprender su efecto sobre los objetivos del proyecto. Puede
descubrirse que los riesgos candidatos estén fuera del alcance de
los objetivos del proyecto pero que son vitales para los intereses
del cliente. Por ejemplo, los riesgos en costes de desarrollo,
costes de adquisición del producto, coste de repuestos (o
sustitución) de los productos y costes de retirada del producto
(o retirada) tienen implicaciones en el diseño.
El cliente puede no haber considerado el coste total de dar
soporte a un producto operativo o de usar un servicio entregado.
El cliente debería estar informado de este tipo de riesgos, aunque
puede que no sea necesario gestionarlos de forma activa. Los
mecanismos para tomar estas decisiones deberían examinarse a
nivel de proyecto y de organización, y ponerlos en práctica si se
considera apropiado, especialmente en los riesgos que afecten a
la capacidad del proyecto para verificar y validar el producto.
Además de los riesgos de coste identificados antes, pueden
incluirse otros riesgos de coste asociados a los niveles de
financiación, estimaciones de financiación y presupuestos
RSKM
distribuidos.
Los riesgos de calendario pueden incluir riesgos asociados con
las actividades planificadas, los eventos clave y los hitos.
Los riesgos de rendimiento pueden incluir riesgos asociados con:

 requisitos.
 análisis y diseño.
 aplicación de tecnología nueva.
 tamaño físico.
 Forma.
 peso.
 Manufacturación y fabricación.
 Comportamiento y funcionamiento del producto con respecto a la
funcionalidad o atributos de calidad.
 Verificación.
 Validación.
 atributos de mantenimiento del rendimiento.
Los atributos de mantenimiento del rendimiento son aquellas

caracte- rísticas que permiten al producto o al servicio en uso
proporcionar el rendimiento requerido, como mantener el
rendimiento de protección y de seguridad.
Hay riesgos que no encajan en las categorías de coste, de
calendario o de rendimiento, pero pueden asociarse con otros
aspectos de la operativa de la organización.
algunos ejemplos de estos otros riesgos son los relacionados con:

 Huelgas.
 disminución de las fuentes de suministro.
 tiempo de ciclo tecnológico.
 Competencia.
2. Revisar los elementos del entorno que pueden afectar al

proyecto. Los riesgos que se olvidan frecuentemente en los
proyectos son los riesgos que supuestamente están fuera del
alcance del proyecto
(es decir, el proyecto no controla si ocurren, pero puede mitigar
su impacto). Estos riesgos pueden tener que ver con la
climatolo- gía o los desastres naturales, los cambios políticos y
los fallos de telecomunicaciones.
3. Revisar todos los elementos de la estructura de descomposición
del trabajo como parte de la identificación de riesgos para
ayudar a asegurar que se consideran todos los aspectos del
esfuerzo del trabajo.
4. Revisar todos los elementos del plan del proyecto como parte
de la identificación de riesgos para ayudar a asegurar que se
consideran todos aspectos del proyecto.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR los riesgos del proyecto,
consúltese el árEA de proceso PLANIFICACIÓN del Proyecto.
5. Documentar el contexto, las condiciones y las consecuencias
potenciales de cada riesgo.
Las declaraciones de riesgo normalmente se documentan en un
formato estándar que contiene el contexto, las condiciones y las
consecuencias de la ocurrencia del riesgo. El contexto del riesgo
proporciona informa- ción adicional acerca del riesgo como el
marco de tiempo relativo del riesgo, las circunstancias o las
condiciones que rodean al riesgo que han provocado la
preocupación y cualquier duda o incertidumbre.
6. Identificar a las partes interesadas relevantes asociadas con
cada riesgo.
SP 2.2 E Valuar , clasificar y priorizar los riEsgos
Evaluar y clasificar cada riesgo identificado usando las categorías y los paráme-
tros definidos para el riesgo, y determinar su prioridad relativa.
La evaluación de los riesgos es necesaria para asignar una

importancia relativa a cada riesgo identificado y se usa para
determinar cuándo se requiere la atención apropiada de la
gerencia. A menudo, es útil agregar riesgos basados en sus
interrelaciones y desarrollar opciones en un nivel agregado.
Cuando se crea un riesgo agregado mediante un conjunto de
riesgos de nivel más bajo, se debería tener cuidado para asegurar
que los riesgos importantes de nivel más bajo no son ignorados.
Colectivamente, las actividades de evaluación, clasificación y prio-
rización de riesgos son denominadas algunas veces “evaluación
de
riesgos” o “análisis de riesgos”.

1. Lista de riesgos y su prioridad asignada.
SUBPRÁCTICAS
1. Evaluar los riesgos identificados usando parámetros definidos
del riesgo.
Cada riesgo se evalúa y recibe valores de acuerdo a los parámetros
del riesgo definidos, que pueden incluir la probabilidad, la
consecuencia (p.ej., gravedad, impacto) y umbrales. Los valores
de los parámetros asignados del riesgo pueden integrarse para
producir medidas adicionales, tales como la exposición del
riesgo (p. ej. la combinación de probabilidad y consecuencia),
que puede usarse para priorizar los riesgos en su tratamiento.
A menudo, se usa una escala con tres a cinco valores para
evaluar tanto la probabilidad como la consecuencia.
La probabilidad, por ejemplo, puede clasificarse como remota,

algunos ejemplos
improbable, de categorías
probable, altamentede consecuencia
probable son:
o casi certeza.
RSKM
 Baja.
 Media.
 alta.
 despreciable.
 Marginal.
 significativa.
 Crítica.
 Catastrófica.
Los valores de probabilidad se usan frecuentemente para

cuantificar la probabilidad de ocurrencia. Las consecuencias
generalmente están relacionadas con coste, calendario, impacto
del entorno medioambiental, o medidas humanas (p. ej., horas
laborales perdidas, gravedad del daño).
La evaluación de riesgos es a menudo una tarea difícil y que
lleva tiempo. Puede ser necesaria una experiencia específica o
técnicas de grupo para evaluar riesgos y adquirir confianza en la
priorización. Además, las prioridades pueden requerir una
reevaluación a medida que avanza el tiempo. Para proporcionar
una base para comparar el impacto de la realización de los
riesgos identificados, las consecuencias de los riesgos pueden
traducirse en dinero.
2. Clasificar y agrupar los riesgos de acuerdo a las categorías de
riesgo definidas.
Los riesgos se clasifican en categorías de riesgo definidas,
proporcionando un medio para revisarlos de acuerdo con su
fuente, taxonomía o componente de proyecto. Los riesgos
relacionados o equivalentes pueden agruparse para un
tratamiento eficiente. Se documentan las relaciones causa efecto
entre riesgos relacionados.
3. Priorizar los riesgos para la mitigación.
Se determina una prioridad relativa para cada riesgo basada en
pa- rámetros asignados de riesgo. Se deberían usar criterios
claros para determinar la prioridad del riesgo. La priorización del
riesgo ayuda a determinar las áreas más eficaces a las que
pueden aplicarse los recursos para que la mitigación de los
riesgos tenga un mayor impacto positivo sobre el proyecto.
SG 3 mitiGar loS rieSGoS

Los riesgos son tratados y mitigados de manera apropiada para reducir los im-
pactos adversos sobre la obtención de los objetivos.
Las etapas en el tratamiento de los riesgos incluyen desarrollar

opciones de tratamiento de riesgos, monitorizar los riesgos y
realizar
las actividades de tratamiento de riesgos cuandose sobrepasan los
umbrales definidos. Los planes de mitigación de riesgo se
desarrollan e implementan para los riesgos seleccionados a fin
de reducir de forma proactiva el impacto potencial de la
ocurrencia del riesgo. La planificación de la mitigación de
riesgos también puede incluir planes de contingencia para tratar
con el impacto de los riesgos seleccionados que puedan ocurrir a
pesar de los intentos para miti- garlos. Los parámetros de riesgo
usados para desencadenar las actividades de tratamiento del
riesgo están definidos por la estrategia de gestión de riesgos.
SP 3.1 d Esarrollar los planEs dE miTigación dE riEsgos
Desarrollar un plan de mitigación de riesgos en concordancia con la estrategia
de gestión de riesgos.
Un componente crítico de la planificación de la mitigación de ries-

gos es el desarrollo de líneas de acción alternativas, soluciones
temporales y en última instancia y una línea de acción
recomendada para cada riesgo crítico. El plan de mitigación de
riesgos para un riesgo dado incluye técnicas y métodos usados
para evitar, reducir y controlar la probabilidad de ocurrencia del
riesgo; la extensión del daño incurrido en caso de que el riesgo
ocurriera (a veces llamado “plan de contingencia”); o ambos.
Los riesgos se monitorizan y, cuando sobrepasan los umbrales
establecidos, los planes de miti- gación de riesgo se despliegan
para devolver el esfuerzo afectado a un nivel de riesgo aceptable.
Si el riesgo no puede mitigarse, puede invocarse un plan de
contingencia. Tanto los planes de mitigación como los de
contingencia del riesgo se generan con frecuencia solamente para
los riesgos seleccionados para los que las consecuencias de los
riesgos sean altas o inaceptables. Otros riesgos pueden acep- tarse
y simplemente monitorizarse.
algunas de las opciones para tratar los riesgos normalmente son:

 evitar el riesgo: cambiar o reducir los requisitos mientras se sigan
cumpliendo las necesidades del usuario final.
 Controlar el riesgo: llevar a cabo actividades para minimizar los riesgos.
 transferir el riesgo: reasignar requisitos para reducir riesgos.
 Monitorizar el riesgo: vigilar y reevaluar periódicamente el riesgo en
función de los cambios en los parámetros del riesgo asignados.
 aceptar el riesgo: reconocer el riesgo pero no tomar ninguna acción.
A menudo, especialmente para riesgos de alto impacto, se

debería generar más de una aproximación para tratar un riesgo.
por ejemplo, en el caso de un evento que interrumpe la continuidad de
RSKM
las operaciones, algunos enfoques para la gestión de riesgos que podrían
establecerse son:
 reservas de recursos para responder a los eventos perjudiciales.
 Listas de equipamiento de respaldo disponible.
 respaldo para el personal clave.
 planes para probar los sistemas de respuesta a emergencias.
 procedimientos de emergencias comunicados.
 Listas distribuidas de los contactos clave y de información de recursos
para emergencias.
En muchos casos, los riesgos son aceptados o vigilados.

General- mente el riesgo se acepta cuando se juzga demasiado
bajo para una mitigación formal, o cuando parece que no existe
ninguna manera viable de reducir el riesgo. Si un riesgo se
acepta, debería documentarse el análisis razonado para ello. Los
riesgos son vigilados cuando hay un umbral objetivamente
definido, verificable y documentado (p. ej., para coste, calendario,
rendimiento, exposición del riesgo) que activará el plan de
mitigación de riesgos o invocará un plan de contingencia.
PARA más INFORMACIÓN ACERCA de cómo EVALUAR ALTERNATIVAS y SELECCIONAR solucio-
nes, consúltese el árEA de proceso Análisis de Decisiones y Resolución.
Se debería dar de forma temprana una consideración
adecuada a las demostraciones de tecnología, los modelos, las
simulaciones, los pilotos y los prototipos como parte del plan de
mitigación de riesgos.

1. Opciones documentadas de tratamiento para cada riesgo identificado.
2. Planes de mitigación de riesgos.
3. Planes de contingencia.
4. Lista de aquellos que son responsables de seguir y tratar cada riesgo.
SUBPRÁCTICAS
1. Determinar los niveles y los umbrales que definen cuándo un
riesgo pasa a ser inaceptable y activa la ejecución de un plan
de mitiga- ción de riesgos o un plan de contingencia.
El nivel de riesgo (obtenido usando un modelo de riesgo) es una
medida que combina la incertidumbre de alcanzar un objetivo
con las consecuencias de fallar en el logro del mismo.
Los niveles y los umbrales de riesgo que limitan el coste, el
calendario o el rendimiento planificado o aceptable deberían
comprenderse y definirse claramente para proporcionar un
medio con el cual pueda comprenderse el riesgo. Una
clasificación adecuada del riesgo es esencial para asegurar una
prioridad adecuada basada en la gravedad y en la respuesta de la
gerencia asociada. Pueden emplearse múltiples umbrales para
iniciar diferentes niveles de respuesta de la gerencia.
Normalmente, los umbrales para la ejecución de los planes de
mitiga- ción de riesgo se establecen para utilizarse antes de la
ejecución de los planes de contingencia.
2. Identificar a la persona o al grupo responsable de tratar cada riesgo.
3. Determinar los costes y los beneficios de la implementación
del plan de mitigación de riesgos para cada riesgo.
Las actividades de mitigación de riesgo deberían examinarse en
cuan- to a los beneficios que proporcionan frente a los recursos
que se de- dican. Al igual que en cualquier otra actividad de
diseño, puede ser necesario desarrollar planes alternativos, y los
costes y beneficios de cada una de las alternativas evaluadas. Se
selecciona el plan más adecuado para su implementación.
4. Desarrollar un plan general de mitigación de riesgos para el
proyec- to a fin de organizar la implementación de los planes
individuales de mitigación y de contingencia de los riesgos.
El conjunto completo de planes de mitigación de riesgos pueden
no ser asequibles. Debería realizarse un análisis de pros y
contras para priorizar los planes de mitigación de riesgos a
implementar.
5. Desarrollar planes de contingencia para los riesgos críticos
seleccionados en caso de que tengan lugar sus impactos.
Los planes de mitigación de riesgos se desarrollan y se implementan
se- gún sea necesario para reducir de forma proactiva los riesgos antes
de que se conviertan en problemas. A pesar de los esfuerzos
realizados, algunos riesgos serán inevitables y se convertirán en
problemas que afectan al proyecto. Pueden desarrollarse planes de
contingencia para los riesgos críticos a fin de describir las acciones
que un proyecto puede adoptar para tratar la ocurrencia de este
impacto. La intención es definir un plan proactivo para manejar el
riesgo. Bien sea que el riesgo se reduzca (mitigación) o sea tratado
(contingencia). En cualquier caso el riesgo se tiene que gestionar.
Alguna literatura de gestión de riesgos puede considerar los
planes de contingencia como un sinónimo o subconjunto de
planes de mitiga- ción de riesgos. Estos planes también pueden
tratarse colectivamente como planes de tratamiento o de acción
de riesgos.
SP 3.2 i mplEmEnTar los planEs dE miTigación dE riEsgos

Monitorizar el estado de cada riesgo periódicamente e implementar el plan de
mitigación de riesgos según sea apropiado.
Para controlar y gestionar eficazmente los riesgos durante el

trabajo, siga un programa proactivo para monitorizar
regularmente los riesgos, y el estado y los resultados de las
acciones de tratamiento de riesgos. La estrategia de gestión de
riesgos define los intervalos en los que debería volver a revisarse
el estado del riesgo. Esta actividad puede dar como resultado el
descubrimiento de nuevos riesgos o de nuevas opciones de
tratamiento del riesgo que pueden requerir replanificación y
reeva- luación. En cualquier caso, los umbrales de aceptabilidad
asociados al
riesgo deberían compararse con el estado del riesgo para
determinar la necesidad de implementar un plan de mitigación de
riesgos.
RSKM
1. Listas actualizadas del estado del riesgo.
2. Evaluaciones actualizadas de la probabilidad, consecuencia y
umbrales de los riesgos.
3. Listas actualizadas de las opciones de tratamiento de riesgos.
4. Listas actualizadas de las acciones tomadas para tratar los riesgos.
5. Planes de mitigación de riesgos para las opciones de
tratamiento del riesgo.
SUBPRÁCTICAS
1. Monitorizar el estado del riesgo.
Una vez iniciado un plan de mitigación de riesgos, el riesgo
continúa monitorizándose. Los umbrales se evalúan para
comprobar la ejecu- ción potencial de un plan de contingencia.
Debería emplearse un mecanismo de monitorización.
2. Proporcionar un método de seguimiento de los elementos de
ac- ción de tratamiento de riesgos abiertos hasta su cierre.
PArA más informAción sobre cómo gestionAr lA Acción correctivA hAStA el
3. Invocar las opciones seleccionadas de tratamiento del riesgo
cuando los riesgos monitorizados excedan los umbrales
definidos.
A menudo, el tratamiento del riesgo solamente se realiza para el
riesgo considerado como ALTO y medio. La estrategia de
tratamiento del riesgo para un riesgo dado puede incluir
técnicas y métodos para evitar, reducir y controlar la
probabilidad del riesgo o la extensión del daño incurrido en caso
de que ocurriera, o ambos. En este contexto, el tratamiento de
riesgos incluye tanto los planes de mitigación como los planes
de contingencia de riesgos.
Las técnicas de tratamiento del riesgo se desarrollan para evitar,
reducir y controlar el impacto adverso sobre los objetivos del
proyecto y para lograr resultados aceptables en función de los
probables impactos. Las acciones generadas para el tratamiento de
un riesgo requieren una carga de recursos y de calendario apropiados
en los planes y en la línea base del calendario. Esta replanificación
debería considerar de cerca los efectos sobre las actividades o
iniciativas de trabajo adyacentes o dependientes.
4. Establecer un calendario o un período de realización para cada
actividad de tratamiento de riesgos que incluya una fecha de
inicio y una fecha prevista de finalización.
5. Proporcionar un compromiso continuo de los recursos para
cada plan, para que la ejecución de las actividades de
tratamiento de riesgos tengan éxito.
6. Recoger medidas de rendimiento sobre las actividades de
tratamiento de riesgos.
GESTION DE AcUERDOS cON PROvEEDORES
Propósito
SAM
El propósito de la Gestión de Acuerdos con Proveedores (SAM) es
gestionar la adquisición de productos y servicios de
proveedores.
El alcance de este área de proceso aborda la adquisición de
productos, servicios y componentes de producto y de servicio que
pueden ser entregados al cliente del proyecto o incluidos en un
producto o sistema de servicios. Estas prácticas del área de
proceso también pueden ser utilizadas para otros propósitos que
beneficien al proyecto (p.ej., compra de consumibles).
Este área de proceso no se aplica en todos los contextos en los
que se adquieren los componentes comerciales (COTS), sino que
se aplica en los casos donde hay modificaciones a los
componentes (COTS), en componentes comerciales de gobierno,
o en software libre, que son un valor importante para el proyecto
o que representan un riesgo importante para el proyecto.
En las áreas de proceso, donde se utilizan los términos
“producto” y “componente de producto”, sus significados también
abarcan servicios, sistemas de servicio y sus componentes.
El área de proceso Gestión de Acuerdos con proveedores
implica las siguientes actividades:
• Determinar el tipo de adquisición.

• Seleccionar los proveedores.
• Establecer y mantener acuerdos con los proveedores.
• Ejecutar los acuerdos del proveedor.
• Aceptar la entrega de los productos adquiridos.
• Asegurar una transición satisfactoria de los productos adquiridos.
Este área de proceso trata principalmente la adquisición de

productos y de componentes de producto que se entregan al
cliente del proyecto.
497
algunos ejemplos de productos y de componentes de producto que se

pueden adquirir por el proyecto son:
 subsistemas (p. ej., sistema de navegación de un avión).
 software.
 Hardware.
 documentación (p. ej., manuales de instalación, de operador y de usuario).
 piezas y materiales (p. ej., calibradores, interruptores, ruedas, acero y
materias primas).
Para minimizar los riesgos del proyecto, este área de proceso

puede tratar también la adquisición de productos y de
componentes de producto importantes no entregados al cliente
del proyecto, pero usados para desarrollar y mantener el
producto o servicio (por ejemplo, herramientas de desarrollo y
entornos de prueba).
Normalmente, los productos que se adquieren por el
proyecto, se determinan durante las etapas iniciales de
planificación y desarrollo.
El área de proceso Solución Técnica proporciona prácticas
para determinar los productos y los componentes de producto
que pueden adquirirse de los proveedores.
Este área de proceso no trata directamente los acuerdos en los
cuales el proveedor esté integrado en el equipo del proyecto y
en los que use los mismos procesos e informes para la gerencia
que los miembros del equipo del proyecto (p. ej., equipos
integrados). Normalmente, estas situaciones se manejan por otros
procesos o funciones (p. ej., procesos de gestión de proyectos,
procesos o funciones externas al proyecto), aunque algunas de las
prácticas específicas de este área de proceso pueden ser útiles en
la gestión del acuerdo con el proveedor.
Normalmente este área de proceso no se implementa para
abordar los acuerdos en los cuales el cliente del proyecto es
también un proveedor. Estas situaciones son normalmente
manejadas bien por acuerdos informales con el cliente o por la
especificación de los elementos proporcionados al cliente
recogida en el acuerdo global del proyecto establecido con el
cliente. En el último caso, algunas de las practicas específicas de
este área de proceso pueden ser útiles en la gestión del acuerdo,
aunque otras no, debido fundamentalmente a la diferencia que
existe entre la relación con un cliente y la relación con un pro-
veedor habitual. Para más información sobre otros tipos de
acuerdos, consúltese el modelo CMMI-ACQ.
Los proveedores pueden ser de muchos tipos dependiendo de las ne-
cesidades de negocio, incluyendo proveedores internos (es decir,
proveedores que están en la misma organización pero son externos
al proyecto), departamentos de fabricación, proveedores de librerías de
reutilización y proveedores comerciales (véase la definición de
“proveedor” en el glosario). Se establece un acuerdo con el proveedor
para gestionar la relación entre la organización y el proveedor.
Un acuerdo con el proveedor
Gestión de acuerdos con proveedores 499
es cualquier acuerdo escrito entre la organización (representando
al proyecto) y el proveedor. Este acuerdo puede ser un contrato,
licencia, acuerdo de nivel de servicio o memorando de acuerdo.
El producto adquirido se entrega al proyecto por el proveedor
conforme al acuerdo con el proveedor (véase la definición de
“acuerdo con el proveedor” en el glosario).

PARA más INFORMACIÓN sobre cómo rEALIZAR el ANÁLISIS de HACER, COMPRAR o reutili-
ZAR, consúltese el árEA proceso Solución TÉCNICA.
SAM
PARA más INFORMACIÓN sobre cómo educir, ANALIZAR y ESTABLECER los requisitos de
cliente, de producto o de componente de producto, consúltese el árEA de proceso
PARA más INFORMACIÓN sobre cómo MONITORIZAR el proyecto frente AL PLAN y gestio-
NAR LAS ACCIONES corrECTIVAS HASTA el cierre, consúltese el árEA de proceso Monito-
RIZACIÓN y Control del Proyecto.


sg 1 establecer acuerdos con proveedores.
sp 1.1 determinar el tipo de adquisición.
sp 1.2 seleccionar a los proveedores.
sp 1.3 establecer acuerdos con proveedores.
sg 2 satisfacer los acuerdos con los proveedores.
sp 2.1 ejecutar el acuerdo con el proveedor.
sp 2.2 aceptar el producto adquirido.
sp 2.3 asegurar la transición de los productos.
SG 1 e Stablecer acuerDoS con ProveeDoreS

Los acuerdos con los proveedores se establecen y mantienen.
SP 1.1 d ETErminar El Tipo dE adquisición

Determinar el tipo de adquisición para cada producto o componente de pro-
ducto a adquirir.
PARA más INFORMACIÓN sobre cómo rEALIZAR los ANÁLISIS de HACER, COMPRAR o reuti-
LIZAR, consúltese el árEA de proceso Solución TÉCNICA.
Para adquirir productos y componentes de producto que
puedan usarse en el proyecto, se pueden utilizar muchos tipos
diferentes de adquisición.
algunos ejemplos de tipos de adquisición son:

 Compra de productos COts modificados de gran valor para el proyecto.
 Obtención de productos mediante un acuerdo con el proveedor.
 Obtención de productos de un proveedor interno.
 Obtención de productos del cliente.
 Obtención de productos de un proveedor preferente.
 Combinación de algún tipo de los anteriores (p. ej., contratar una
modificación a un producto COts, tener otra parte de la empresa
desarrollando productos con un proveedor externo).
Si se adquieren productos COTS modificados de gran valor

para el proyecto o que representan un riesgo importante para el
proyecto, el cuidado en la evaluación y la selección de estos
productos y del proveedor pueden ser críticos para el proyecto.
Los aspectos a considerar en la decisión de la selección incluyen
cuestiones de propiedad y de disponibilidad de los productos.

1. Lista de tipos de adquisición que serán usados para todos los
productos y componentes de producto a adquirir.
SP 1.2 Seleccionar a loS ProveeDoreS
Seleccionar a los proveedores en base a una evaluación de su capacidad para
cumplir los requisitos especificados y los criterios establecidos.
PARA más INFORMACIÓN sobre cómo ANALIZAR posibles decisiones USANDO un proceso
de EVALUACIÓN FORMAL que EVALÚE ALTERNATIVAS IDENTIFICADAS frente A criterios ESTA-
blecidos, consúltese el árEA de proceso Análisis de Decisiones y Resolución.
PARA más INFORMACIÓN sobre cómo obtener compromisos con los requisitos, con-
súltese el árEA de proceso Gestión de Requisitos.
Deberían establecerse criterios para tratar factores que son

importantes para el proyecto.
algunos ejemplos de factores que pueden ser importantes para el

proyecto son:
 Localización geográfica del proveedor.
 registros de desempeño del proveedor en trabajos similares.
Continúa
Continuación
 Capacidades de ingeniería.
 personal e instalaciones disponibles para realizar el trabajo.
 experiencia anterior en situaciones similares.
 satisfacción del cliente con productos similares entregados por el
proveedor.

1. Estudios de mercado.
SAM
2. Lista de proveedores candidatos.
3. Lista de proveedores preferentes.
4. Estudio de opciones (glosario) u otro registro de criterios de
eva- luación, ventajas y desventajas de los proveedores
candidatos y análisis razonado para la selección de
proveedores.
5. Materiales y requisitos de solicitud.
SUBPRÁCTICAS
1. Establecer y documentar los criterios para la evaluación de
proveedores potenciales.
2. Identificar proveedores potenciales y enviarles el material y
los requisitos de solicitud.
Una manera proactiva de realizar esta actividad es llevar a cabo
investigaciones de mercado para identificar fuentes potenciales
de productos candidatos a adquirir, incluyendo proveedores de
productos a medida y de productos COTS.
3. Evaluar propuestas conforme a los criterios de evaluación.
4. Evaluar los riesgos asociados con cada proveedor propuesto.
5. Evaluar las capacidades de los proveedores propuestos para
realizar el trabajo.
algunos ejemplos de métodos usados para evaluar las capacidades del

proveedor propuesto para realizar el trabajo son:
 evaluación de la experiencia anterior en aplicaciones similares.
 evaluación de la satisfacción del cliente con productos similares
proporcionados.
 evaluación de desempeño anterior en trabajos similares.
 evaluación de las capacidades de gestión.
 evaluaciones de capacidad.
Continúa
Continuación
 evaluación del personal disponible para realizar el trabajo.
 evaluación de las instalaciones y de los recursos disponibles.
 evaluación de la capacidad del proyecto para trabajar con el proveedor
propuesto.
 evaluación del impacto de los productos COts candidatos en el plan y
en los compromisos del proyecto.
Cuando los productos COts modificados están siendo evaluados, considere:

 Coste de los productos COts modificados.
 Coste y esfuerzo para incorporar los productos COts modificados en el
proyecto.
 requisitos de seguridad.
 Beneficios e impactos que pueden resultar de entregas futuras de productos.
Las futuras versiones de los productos COTS modificados

pueden proporcionar características adicionales que den soporte a
las mejoras planificadas o previstas para el proyecto, pero
pueden dar lugar a la suspensión del soporte por parte del
proveedor de la versión actual.
6. Seleccionar el proveedor.
SP 1.3 E sTablEcEr acuErdos con proVEEdorEs
Establecer y mantener los acuerdos con proveedores.
Un acuerdo con el proveedor es cualquier acuerdo escrito entre la
or- ganización (representando al proyecto) y el proveedor. Este
acuerdo puede ser un contrato, licencia, acuerdo de nivel de
servicio, o memorando de acuerdo.
El contenido del acuerdo con el proveedor debería especificar
el acuerdo para la selección de los procesos y productos de
trabajo del proveedor a monitorizar, analizar y evaluar, si el
acuerdo es apropiado para la adquisición o para el producto que se
adquiere. El acuerdo con el proveedor también debería especificar
las revisiones, la monitoriza- ción, las evaluaciones y las pruebas
de aceptación a realizar.
Los procesos del proveedor que sean críticos para el éxito del
proyecto (p. ej., debido a su complejidad, debido a su
importancia) se deberían monitorizar.
Normalmente los acuerdos de proveedor entre personas
jurídicas independientes se revisan por asesores jurídicos o
asesores del contra- to antes de su aprobación.
1. Declaración del trabajo.
2. Contratos.
3. Memorandos de acuerdo.
4. Acuerdo de licencia.
SUBPRÁCTICAS
1. Modificar los requisitos (p. ej., requisitos de producto,
requisitos de nivel de servicio) a realizar por el proveedor cuando
sea necesario para reflejar las negociaciones con el proveedor.
PARA más INFORMACIÓN sobre cómo DESARrOLLAR los requisitos de producto,
consúltese el árEA de proceso DESARrollo de Requisitos.
PARA más INFORMACIÓN sobre cómo GESTIONAR los requisitos de los produc-
tos y de los componentes de producto del proyecto y cómo ASEGURAR LA
ALINEACIÓN entre esos requisitos, y los PLANES y productos de TRABAJO del
proyecto, consúltese el árEA de proceso Gestión de Requisitos.
SAM
2. Documentar lo que el proyecto proporcionará al proveedor.
Incluye:
• Instalaciones del proyecto equipadas.
• Documentación.
• Servicios.
3. Documentar el acuerdo con el proveedor.
El acuerdo con el proveedor debería incluir una declaración del
trabajo, una especificación, los términos y condiciones, una
lista de entregables, un calendario, un presupuesto y un proceso
definido de aceptación.
esta subpráctica normalmente incluye las siguientes tareas:

 Identificar el tipo y la profundidad de supervisión del proyecto del
proveedor, los procedimientos y los criterios de evaluación que
serán utilizados en la monitorización del desempeño del proveedor,
incluyendo la selección de los procesos a monitorizar y los productos
de trabajo a evaluar.
 establecer la declaración del trabajo, la especificación, los términos y
condiciones, la lista de entregables, el calendario, el presupuesto y el
proceso de aceptación.
 Identificar a los responsables y autorizados del proyecto y del
proveedor para hacer cambios en el acuerdo con el proveedor.
 Identificar cómo se determinarán, comunicarán y tratarán los cambios
a los requisitos y los cambios al acuerdo con el proveedor.
 Identificar los estándares y procedimientos que se seguirán.
 Identificar las dependencias críticas entre el proyecto y el proveedor.
 Identificar los tipos de revisiones que se llevarán cabo con el
proveedor.
 Identificar las responsabilidades del proveedor para el mantenimiento
y soporte continuo de los productos adquiridos.
 Identificar la garantía, la propiedad y los derechos de uso de los
productos adquiridos.
 Identificar los criterios de aceptación.
en algunos casos, la selección de productos COts modificados puede

requerir un acuerdo con el proveedor, además de los acuerdos en las
licencias del producto. algunos ejemplos de lo que podría cubrirse en un
acuerdo con un proveedor COts son:
 descuentos para grandes cantidades de compras.
 Cobertura de las partes interesadas relevantes bajo el acuerdo de
licencia, incluyendo los proveedores del proyecto, los miembros del
equipo y los clientes del proyecto.
 planes para futuras mejoras.
 soporte in situ, tales como respuestas a las consultas e informes de
problemas.
 Capacidades adicionales que no están en el producto.
 soporte de mantenimiento, incluyendo el soporte después de que el
producto sea retirado.
4. Revisar periódicamente el acuerdo con el proveedor para

asegurar que refleja exactamente la relación del proyecto con el
proveedor, y los riesgos y las condiciones de mercado actuales.
5. Asegurar que todas las partes del el acuerdo con el proveedor
comprenden y aceptan todos los requisitos antes de
implementar el acuerdo o cualquier cambio.
6. Modificar el acuerdo con el proveedor, según sea necesario, para
reflejar los cambios a los procesos o productos de trabajo del
proveedor.
7. Modificar los planes y compromisos del proyecto, incluyendo
los cambios a los procesos o a los productos de trabajo del
proyecto según sea necesario, para reflejar el acuerdo con el
proveedor.
PARA más INFORMACIÓN sobre cómo MONITORIZAR los compromisos, consúl-
SG 2 S atiSfacer loS acuerDoS con loS ProveeDoreS

Los acuerdos con los proveedores se satisfacen tanto por el proyecto como por
el proveedor.
SP 2.1 E jEcuTar El acuErdo con El proVEEdor

Realizar las actividades con el proveedor tal y como se especifica en el acuerdo
con el proveedor.
PARA más INFORMACIÓN sobre cómo proporCIONAR UNA comprensión del progreso del
proyecto PARA que LAS ACCIONES corrECTIVAS APROPIADAS PUEDAN ser TOMADAS CUANDO
el rendimiento del proyecto se DESVÍA SIGNIFICATIVAMENTE del PLAN, consúltese el
árEA de proceso MONITORIZACIÓN y Control del Proyecto.

1. Informes del progreso del proveedor y medidas de desempeño.
2. Materiales e informes de revisión del proveedor.
3. Elementos de acción seguidos hasta su cierre.
4. Entregas de producto y de documentación.
SUBPRÁCTICAS
1. Monitorizar el progreso y el desempeño del proveedor (p. ej.,
calendario, esfuerzo, coste, rendimiento técnico), según se
define en el acuerdo con el proveedor.
2. Seleccionar, monitorizar y analizar los procesos usados por el
proveedor según se define en el acuerdo con el proveedor.
Los procesos del proveedor que son críticos para el éxito del
SAM
proyecto (p. ej., debido a su complejidad, a su importancia)
deberían monitorizarse. La selección de los procesos a
monitorizar debería considerar el impacto de la selección sobre el
proveedor.
3. Seleccionar y evaluar los productos de trabajo del proveedor
según se define en el acuerdo con el proveedor.
Los productos de trabajo seleccionados para su evaluación
deberían incluir los productos críticos, componentes de
producto y productos de trabajo que proporcionen visibilidad de
las cuestiones de calidad tan pronto como sea posible. En
situaciones de riesgo bajo, puede no ser necesaria la selección de
ningún producto de trabajo para su evaluación.
4. Llevar a cabo revisiones con el proveedor según se especifica
en el acuerdo con el proveedor.
PARA más INFORMACIÓN sobre cómo LLEVAR ACABO revisiones de hitos y revi-
siones de progreso, consúltese el árEA de proceso MONITORIZACIÓN y Control
del Proyecto.
Las revisiones cubren tanto revisiones formales como
informales, e incluyen los siguientes pasos:
• Preparar la revisión.
• Asegurar la participación de las partes interesadas relevantes.
• Llevar a cabo la revisión.
• Identificar, documentar y seguir todos los elementos de acción
hasta su cierre.
• Preparar y distribuir un informe resumen de la revisión a las
5. Llevar a cabo revisiones técnicas con el proveedor según se
defina en el acuerdo con el proveedor.
normalmente las revisiones técnicas incluyen:

 proporcionar al proveedor visibilidad de las necesidades y de los deseos
de los clientes y de los usuarios finales del proyecto, según proceda.
 revisar las actividades técnicas del proveedor y verificar que la
interpretación y la implementación de los requisitos del proveedor son
consistentes con la interpretación del proyecto.
Continúa
Continuación
 asegurar que los compromisos técnicos se cumplen y que las
cuestiones técnicas se comunican y resuelven de forma apropiada.
 Obtener información técnica sobre los productos del proveedor.
 proporcionar información técnica y soporte apropiados al proveedor.
6. Llevar a cabo revisiones de gestión con el proveedor, según se

defina en el acuerdo con el proveedor.
normalmente, las revisiones de gestión del proyecto incluyen:

 revisar dependencias críticas.
 revisar los riesgos del proyecto que involucran al proveedor.
 revisar el calendario y el presupuesto.
 revisar la conformidad del proveedor con los requisitos legales y
normativos.
Las revisiones técnicas y las de gestión pueden coordinarse y

realizarse conjuntamente.
7. Usar los resultados de las revisiones para mejorar el desempeño
del proveedor, y para establecer y fomentar las relaciones a
largo plazo con los proveedores preferentes.
8. Monitorizar los riesgos que involucran al proveedor y tomar
las acciones correctivas según sea necesario.
PARA más INFORMACIÓN sobre cómo MONITORIZAR los riesgos del proyecto,
SP 2.2 a cEpTar El producTo adquirido

Asegurar que el acuerdo con el proveedor se cumple antes de aceptar el pro-
ducto adquirido.
Se deberían completar las revisiones de aceptación, las pruebas y

las auditorias de configuración antes de aceptar el producto
según se defina en el acuerdo con el proveedor.
Ejemplos de Productos de TRABAJO

1. Procedimientos de aceptación.
2. Resultados de las revisiones o de las pruebas de aceptación.
3. Informes de discrepancia o planes de acción correctiva.
SUBPRÁCTICAS
1. Definir los procedimientos de aceptación.
2. Revisar y obtener el acuerdo con las partes interesadas
relevantes sobre los procedimientos de aceptación antes de la
revisión o prueba de aceptación.
3. Verificar que los productos adquiridos satisfacen sus requisitos.
4. Confirmar que se satisfacen los compromisos no técnicos
asociados con el producto de trabajo adquirido.
SAM
Esta confirmación puede incluir la confirmación de que la
licencia apropiada, la garantía, la propiedad, el uso y los acuerdos
de soporte o de mantenimiento están en vigor y que todos los
materiales de soporte se reciben.
5. Documentar los resultados de la revisión o prueba de aceptación.
6. Establecer un plan de acción y obtener el acuerdo con el
proveedor para tomar acciones con el objeto de corregir los
productos de trabajo adquiridos que no pasen su revisión o
pruebas de aceptación.
7. Identificar, documentar y seguir los elementos de acción hasta el cierre.
PARA más INFORMACIÓN sobre cómo GESTIONAR LA ACCIÓN corrECTIVA HAS-
TA el cierre, consúltese el árEA de proceso MONITORIZACIÓN y Control del
Proyecto.
SP 2.3 asEgurar la Transición dE los producTos

Asegurar la transición de los productos adquiridos del proveedor.
Antes que el producto adquirido sea transferido al proyecto, al

cliente o al usuario final, se debería realizar la preparación y
evaluación adecuadas para asegurar una transición fluida.
PARA más INFORMACIÓN sobre cómo ENSAMBLAR los componentes de producto, con-

1. Planes de transición.
2. Informes de formación.
3. Informes de soporte y de mantenimiento.
SUBPRÁCTICAS
1. Asegurar que hay instalaciones para recibir, almacenar,
integrar y mantener los productos adquiridos según sea
apropiado.
2. Asegurar que se proporciona la formación apropiada a
aquellos involucrados en la recepción, almacenamiento,
integración y mantenimiento de los productos adquiridos.
3. Asegurar que se almacenan, distribuyen e integran los
productos adquiridos de acuerdo a los términos y condiciones
especificados en el acuerdo o licencia con el proveedor.
SOLUcIÓN TécNIcA
Un área de proceso de Ingeniería en el nivel de madurez 3
Propósito
El propósito de la Solución Técnica (TS) es seleccionar, diseñar e
implementar soluciones para los requisitos. Las soluciones, los
diseños y las implementaciones engloban productos,
componentes de producto y procesos del ciclo de vida relativos al
producto, bien individualmen- te o en conjunto, según proceda.
TS
El área de proceso Solución Técnica es aplicable en cualquier nivel
de la arquitectura de producto y a cada producto, componente de
produc- to y proceso del ciclo de vida relativo al producto. En todas
las áreas de proceso, cuando se usan los términos “producto” y
“componente de producto”, su significado engloba también a los
servicios, sistemas de servicios y sus componentes.
Este área de proceso se enfoca en lo siguiente:
• Evaluar y seleccionar soluciones (referidas a veces como
“aproximaciones de diseño”, “conceptos de diseño” o “diseños
preliminares”) que potencialmente satisfacen un conjunto
de requisitos funcionales apropiado y de atributos de calidad
asignados.
• Desarrollar diseños detallados para las soluciones
seleccionadas (detallados en el contexto de contener toda la
información necesaria para fabricar, codificar o, de otra
manera implementar el diseño como un producto o
componente de producto).
• Implementar los diseños como un producto o componente de
producto.
Normalmente, estas actividades se dan soporte interactivamente

entre sí. Para seleccionar soluciones puede ser necesario algún nivel
de dise- ño, a veces bastante detallado. Los prototipos o los pilotos
pueden usarse como un medio para obtener el conocimiento
suficiente para desarrollar un paquete de datos técnicos o un
conjunto completo de requisitos. Los modelos de atributos de
calidad, las simulaciones, los prototipos o los pilotos pueden usarse
para proporcionar información adicional sobre las
509
propiedades de las soluciones potenciales de diseño para ayudar en la
se- lección de soluciones. Las simulaciones pueden ser
particularmente útiles para proyectos de desarrollo de sistemas de
sistemas.
Las prácticas específicas de la Solución Técnica no se aplican
sólo al producto y a los componentes de producto, sino también a
los procesos del ciclo de vida relativos al producto. Los procesos
del ciclo de vida relativos al producto se desarrollan de manera
conjunta con el producto o componente de producto. Este
desarrollo puede incluir la selección y la adaptación de los procesos
existentes (incluyendo los procesos están- dar) para su uso, así
como para el desarrollo de nuevos procesos.
Los procesos asociados al área de proceso Solución Técnica
reciben los requisitos de producto y de componentes de
producto de los procesos de gestión de requisitos. Los procesos
de gestión de requisitos sitúan los requisitos, que se originan en
los procesos de desarrollo de requisitos, bajo la gestión de
configuración apropiada y mantienen su trazabilidad con los
requisitos previos.
Para un proyecto de mantenimiento o de soporte, los requisitos
necesarios para las acciones de mantenimiento o de rediseño se
pueden guiar por las necesidades de los usuarios, la madurez y
obsolescencia de la tecnología, o los defectos latentes en los
componentes de producto. Pueden surgir nuevos requisitos de los
cambios en el entorno operativo. Dichos requisitos pueden
descubrirse durante la verificación del producto(s), donde se puede
comparar su rendimiento real frente a su rendimiento especificado y
se puede identificar una degradación inaceptable. Los procesos
asociados con el área de proceso Solución Técnica deberían usarse
para realizar los esfuerzos de diseño de mantenimiento o de
soporte.
Para las líneas de producto, estas prácticas se aplican tanto para
el desarrollo de activos base (p. ej., construcción para
reutilización) como para el desarrollo del producto (p. ej.,
construcción con reuti- lización). Además, el desarrollo de
activos base requiere de la gestión de la variación de las líneas de
producto (la selección y la implemen- tación de mecanismos de
variación de las líneas de producto) y de la planificación de la
producción de las líneas de producto (el desarrollo de procesos y
otros productos de trabajo que definen cómo se cons- truirán los
productos para hacer un uso mejor de estos activos base).
en entornos Ágiles, el enfoque está en la exploración temprana de las

soluciones. Haciendo la selección y las decisiones de compromisos más
explícitas, el área de proceso solución técnica ayuda a mejorar la calidad
de esas decisiones, tanto para las decisiones individuales como para las
decisiones en el tiempo. Las soluciones se pueden definir en términos
de funciones, conjuntos de características, versiones o cualquier otro
componente que facilite el desarrollo del producto. Cuando alguien
que no pertenece al equipo va a trabajar en el producto en el futuro, la
información de versiones, registros de mantenimiento, u otros
Continúa
Solución técnica 511
Continuación
datos se incluyen normalmente con el producto instalado. para dar

soporte a futuras actualizaciones del producto, se recoge el análisis
razonado (para compromisos, interfaces y partes compradas) para que
se pueda comprender mejor porqué existe el producto. siexiste riesgo
de nivel bajo en la solución seleccionada, se reduce significativamente
la necesidad de capturar decisiones formalmente (véase “Interpretando
CMMI al utilizar enfoques Ágiles” en la primera parte).

PARA más INFORMACIÓN sobre cómo ASIGNAR requisitos de componente de producto,
ESTABLECER conceptos y ESCENARIOS de OPERACIÓN, e IDENTIFICAR los requisitos de in-
terFAZ, consúltese el árEA de proceso DESARrollo de Requisitos.
PARA más INFORMACIÓN sobre cómo rEALIZAR LA revisión entre PARes y VERIFICAR los
productos de TRABAJO SELECCIONADOS, consúltese el árEA de proceso VERIFICACIÓN.
TS
PARA más INFORMACIÓN sobre cómo ANALIZAR posibles decisiones UTILIZANDO un
Resolución.
PARA más INFORMACIÓN sobre cómo SELECCIONAR y DESPLEGAR LAS MEJORAS, consúltese
el árEA de proceso Gestión del Rendimiento de LA OrGANIZACIÓN.
PARA más INFORMACIÓN sobre cómo GESTIONAR los requisitos de los productos y los
componentes de producto del proyecto, y ASEGURAR LA ALINEACIÓN entre esos requi-
sitos, y los PLANES del proyecto y los productos de TRABAJO, consúltese el árEA de

sg 1 seleccionar soluciones de componentes de producto.
sp 1.1 desarrollar soluciones alternativas y los criterios de selección.
sp 1.2 seleccionar las soluciones de componentes de producto.
sg 2 desarrollar el diseño.
sp 2.1 diseñar el producto o los componentes de producto.
sp 2.2 establecer un paquete de datos técnicos.
sp 2.3 diseñar las interfaces usando criterios.
sp 2.4 realizar los análisis sobre si hacer, comprar o reutilizar.
sg 3 Implementar el diseño del producto.
sp 3.1 Implementar el diseño.
sp 3.2 desarrollar la documentación de soporte del producto.
SG 1 S eleccionar SolucioneS De comPonenteS De ProDucto

Las soluciones del producto o de componentes de producto se seleccionan a
partir de soluciones alternativas.
Antes de seleccionar una solución, se consideran las soluciones

alternativas y sus ventajas relativas. Los requisitos clave, las
cuestiones de diseño y las limitaciones se establecen para utilizarse
en el análisis de soluciones alternativas. Se consideran las
elecciones y patrones de arquitectura que dan soporte a la
consecución de los requisitos de los atributos de calidad. También,
el uso de componentes de productos comerciales (COTS) se
considera en relación al coste, al calendario, al rendimiento y al
riesgo. Las alternativas COTS pueden usarse con o sin
modificación. Algunas veces, estos elementos pueden requerir
modificaciones en aspectos tales como las interfaces o una
adaptación de alguna de las características para corregir un
desajuste con los requisitos de los atributos de calidad y
funcionales o con los diseños de arquitectura. Un indicador de un
buen proceso de diseño es que el diseño fuera elegido después de
compararlo y de evaluarlo frente a las soluciones alternativas. En
general, entre las selecciones de diseño que se tratan están las
decisiones sobre arquitectura, el desarrollo a medida frente a
productos comerciales y la modulación de componentes de producto.
Algunas de estas decisiones pueden requerir el uso de un proceso de
evaluación formal.
so de evAluAción formAl que evAlúe AlternAtivAS identificAdAS frente A los criterios
estAblecidos, consúltese el áreA de proceso Análisis de Decisiones y Resolución.
A veces, en la búsqueda de soluciones se examinan instancias
alternativas de los mismos requisitos sin las asignaciones
necesarias para los componentes de producto de nivel inferior.
Este es el caso del nivel más bajo de la arquitectura del producto.
También hay casos donde una o más de las soluciones están
fijadas (p. ej., se investiga para su uso una solución específica
dirigida o la disponibilidad de componentes de producto, como
COTS).
Generalmente, las soluciones se definen como un conjunto, es
decir, cuando se define la siguiente capa de componentes de
producto, la solución se establece en su conjunto para cada uno
de los componentes de producto. Las soluciones alternativas no
son sólo formas diferentes de tratar los mismos requisitos, sino
que también reflejan una asignación diferente de requisitos entre
los componentes de producto, que abarca el conjunto de la
solución. El objetivo es optimizar el conjunto como un todo y no
sólo las piezas individuales. Habrá una interacción significativa
con los procesos asociados con el área de proceso Desarrollo de
Requisitos, para dar soporte a las asignaciones provisionales de
los componentes de producto, hasta que se seleccione la solución
en su conjunto y se establezcan las asignaciones finales.
Los procesos del ciclo de vida relativos al producto están entre
las soluciones de componentes de producto que se seleccionan
desde las soluciones alternativas.
Ejemplos de estos procesos del ciclo de vida relativos al
producto son los procesos de fabricación, de entrega y de soporte.
SP 1.1 d Esarrollar solucionEs alTErnaTiVas y los criTErios dE sElEcción
Desarrollar soluciones alternativas y los criterios de selección.
PARA más INFORMACIÓN sobre cómo obtener ASIGNACIONES de requisitos A LAS SO-
luciones ALTERNATIVAS PARA los componentes de producto, consúltese LA PRÁCTICA
ESPECÍFICA ASIGNAR los requisitos de componentes de producto en el árEA de proceso
PARA más INFORMACIÓN sobre cómo ESTABLECER criterios de EVALUACIÓN, consúltese el
árEA de proceso Análisis de Decisiones y Resolución.
Deberían identificarse y analizarse soluciones alternativas, para

permitir la selección de una solución equilibrada a lo largo de la vida
del producto en términos de coste, de calendario, de rendimiento y
de riesgo. Estas soluciones se basan en las arquitecturas propuestas
TS
de producto que tratan los requisitos críticos de los atributos de
calidad del producto y abarcan un espacio de diseño de soluciones
factibles. Las prácticas específicas asociadas con la meta específica
Desarrollar el diseño proporcionan más información sobre el
desarrollo de arquitecturas potenciales del producto que pueden
incorporarse en soluciones alternativas del mismo.
Las soluciones alternativas engloban frecuentemente
asignaciones alternativas de requisitos para diferentes
componentes de producto. Estas soluciones alternativas también
pueden incluir el uso de soluciones COTS en la arquitectura del
producto. Los procesos asociados con el área de proceso
Desarrollo de Requisitos podrían entonces emplearse para
proporcionar una asignación provisional más completa y robusta
de los requisitos para las soluciones alternativas.
Las soluciones alternativas abarcan un rango aceptable de
coste, de calendario y de rendimiento. Los requisitos de los
componentes de producto se reciben y se utilizan junto con las
cuestiones de diseño, las restricciones y los criterios de diseño
para desarrollar soluciones alternativas. Los criterios de
selección normalmente podrían tratar costes (p. ej., tiempo,
personal, dinero), beneficios (p. ej., prestación del producto,
capacidad, eficacia) y riesgos (p. ej., técnicos, de coste, de
calendario). Algunas consideraciones para las soluciones
alternativas y los criterios de selección son:
• Coste de desarrollo, fabricación, aprovisionamiento,
mantenimiento y soporte.
• Logro de los requisitos clave de los atributos de calidad,
como la oportunidad, la protección, la fiabilidad y la
facilidad de mantenimiento del producto.
• Complejidad de los procesos relativos al ciclo de vida de los
componentes de producto y del producto.
• Robustez en el funcionamiento del producto y en las
condiciones de uso, modos de operación, entornos y
variaciones en los procesos del ciclo de vida relativos al
producto.
• Expansión y crecimiento del producto.
• Sensibilidad a los métodos y materiales de construcción.
• Riesgo.
• Evolución de los requisitos y de la tecnología.
• Retirada.
• Capacidades y limitaciones de los usuarios finales y de los
operadores.
• Características de los productos COTS.
Las consideraciones anteriores forman un conjunto base; las

organizaciones deberían desarrollar criterios de filtrado para
reducir la lista de alternativas que son consistentes con sus
objetivos del negocio. El coste del ciclo de vida del producto,
aunque sea un parámetro deseable a minimizar, puede estar
fuera del control de las organizaciones de desarrollo. Un cliente
puede no desear pagar por características que cuesten más a corto
plazo, aunque en definitiva el coste disminuya a lo largo de la
vida del producto. En estos casos, los clientes deberían por lo
menos estar informados de cualquier reducción potencial de los
costes del ciclo de vida. Los criterios usados para seleccionar las
soluciones finales deberían proporcionar un enfoque equilibrado
de costes, beneficios y riesgos.
1. Criterios de filtrado de la solución alternativa.
2. Informes de evaluación de nuevas tecnologías.
3. Soluciones alternativas.
4. Criterios de selección para la selección final.
5. Informes de evaluación de los productos COTS.
SUBPRÁCTICAS
1. Identificar los criterios de filtrado para seleccionar un
conjunto de soluciones alternativas a considerar.
2. Identificar las tecnologías actualmente en uso y las nuevas
tecnolo- gías de producto en cuanto a ventajas competitivas.
PARA más INFORMACIÓN sobre cómo SELECCIONAR y DESPLEGAR MEJORAS, con-
súltese el árEA de proceso Gestión del Rendimiento de LA OrGANIZACIÓN.
El proyecto debería identificar las tecnologías aplicadas a los
productos y procesos actuales y monitorizar durante toda la
vida del proyecto el progreso de las tecnologías usadas
actualmente. El proyecto debería identificar, seleccionar, evaluar
e invertir en nuevas tecnolo- gías para conseguir ventajas
competitivas. Las soluciones alternativas podrían incluir
tecnologías desarrolladas recientemente, pero tam- bién podrían
incluir la aplicación de tecnologías maduras en diversas
aplicaciones o para mantener los métodos actuales.
3. Identificar los productos COTS candidatos que satisfagan los requisitos.
PARA más INFORMACIÓN sobre cómo SELECCIONAR proveedores, consúltese el
árEA de proceso Gestión de Acuerdos con Proveedores.
El proveedor de los productos COTS necesitará cumplir ciertos
requisitos que incluyen:
• Funcionalidad del producto y atributos de calidad.
• Términos y condiciones de garantía de los productos.
• Expectativas (p. ej., para actividades de revisión), restricciones, o
puntos de control que ayuden a reducir las responsabilidades de los
proveedores en cuanto al mantenimiento y soporte continuo de los
productos.
4. Identificar los componentes de solución reutilizables o los
TS
patrones de arquitectura aplicables.
Para líneas de producto, los activos base de la organización
pueden ser usados como base para una solución.
5. Generar soluciones alternativas.
6. Obtener una asignación completa de requisitos para cada alternativa.
7. Desarrollar los criterios para seleccionar la mejor solución
alternativa. Se deberían incluir los criterios que tratan las
cuestiones de diseño durante la vida del producto, tales como
las provisiones para intro-
ducir más fácilmente nuevas tecnologías o la capacidad para
mejorar la explotación de los productos comerciales. Los
ejemplos incluyen criterios relacionados con el diseño abierto o
con los conceptos de arquitectura abierta para las alternativas que
están siendo evaluadas.
SP 1.2 s ElEccionar las solucionEs dE componEnTEs dE producTo

Seleccionar las soluciones de componentes de producto en base a los criterios
de selección.
PARA más INFORMACIÓN sobre cómo ESTABLECER los requisitos ASIGNADOS PARA los
componentes de producto y los requisitos de LA interFAZ entre los componentes de
producto, consúltense LAS PRÁCTICAS ESPECÍFICAS ASIGNAR los requisitos de compo-
nentes de producto e IDENTIFICAR los requisitos de interFAZ en el árEA de proceso
La selección de los componentes de producto que mejor

satisfagan los criterios establece las asignaciones de requisitos a
los componentes de producto. Los requisitos de nivel inferior se
generan a partir de la alternativa seleccionada y se usan para
desarrollar diseños de
componentes de producto. Las interfaces se describen entre los
componentes de producto. Las descripciones de interfaz física se
incluyen en la documentación de las interfaces para los
elementos y las actividades externas al producto.
Se documentan la descripción de las soluciones y el análisis
razonado de la selección. La documentación evoluciona a través
del desarrollo a la vez que se desarrollan soluciones y diseños
detallados y se implementan esos diseños. Mantener un registro
del análisis razonado es crítico para la toma de decisiones
posterior. Estos registros impiden posteriormente a las partes
interesadas rehacer el trabajo y proporcionan ideas para aplicar
la tecnología a medida que esté disponible en circunstancias
aplicables.
1. Decisiones y análisis razonado de la selección de
2. Relaciones documentadas entre los requisitos y los
3. Soluciones, evaluaciones y análisis razonado documentadas.
SUBPRÁCTICAS
1. Evaluar cada solución/conjunto alternativo de soluciones
frente a los criterios de selección establecidos en el contexto de
los conceptos y escenarios operacionales.
Desarrollar la secuencia de los escenarios para la operación del
producto y la interacción del usuario para cada solución
alternativa.
2. En base a la evaluación de alternativas, evaluar la adecuación
de los criterios de selección y actualizar estos criterios según
sea necesario.
3. Identificar y resolver las cuestiones con las soluciones
alternativas y los requisitos.
4. Seleccionar el mejor conjunto de soluciones alternativas que
satisfagan los criterios de selección establecidos.
5. Establecer los requisitos funcionales y de atributos de calidad
asociados con el conjunto seleccionado de alternativas, así
como con el conjunto de requisitos asignados a esos
6. Identificar las soluciones de componentes de producto que
serán reutilizadas o adquiridas.
PARA más INFORMACIÓN sobre cómo GESTIONAR LA ADQUISICIÓN de productos
y de servicios de proveedores, consúltese el árEA de proceso Gestión de
Acuerdos con Proveedores.
7. Establecer y mantener la documentación de las soluciones, las
evaluaciones y el análisis razonado.
SG 2 D eSarrollar el DiSeño
Los diseños del producto o de los componentes de producto se desarrollan.
Los diseños del producto o de los componentes de producto

deberían proporcionar el contenido apropiado no sólo para la
implementación, sino también para otras fases del ciclo de vida de
producto, tales como la modificación, el reaprovisionamiento, el
mantenimiento, el soporte y la instalación. La documentación del
diseño proporciona una referencia para dar soporte a la comprensión
mutua del diseño por las partes interesadas relevantes, y da soporte
a los futuros cambios del diseño tanto en el desarrollo como en las
fases sucesivas del ciclo de vida del producto. Una descripción de
diseño completa se documenta en un paquete de datos técnicos que
incluye una gama completa de características y de paráme- tros,
como la forma, el ajuste, la función, la interfaz, las características del
proceso de fabricación y otros parámetros. Los estándares de diseño
del proyecto o de la organización establecidos (p. ej., listas de
comprobación, plantillas, frameworks de objetos) forman la base
para lograr un alto grado de definición y completitud en la
documentación del diseño.
SP 2.1 d isEñar El producTo o los componEnTEs dE producTo
TS
Desarrollar un diseño para el producto o el componente de producto.
El diseño del producto consiste en dos grandes fases que pueden

sola- parse en ejecución: diseño preliminar y detallado. El diseño
preliminar establece las capacidades del producto y la
arquitectura del producto, incluyendo estilos y patrones de
arquitectura, particiones del produc- to, identificaciones de los
componentes de producto, estados y modos del sistema,
interfaces principales entre componentes, e interfaces externas del
producto. El diseño detallado define completamente la estructura
y capacidades de los componentes de producto.
PARA más INFORMACIÓN sobre cómo DESARrOLLAR los requisitos de ARQUITECTURA, con-
súltese LA PRÁCTICA ESPECÍFICA ESTABLECER UNA definición de LA FUNCIONALIDAD y de
los ATRIBUTOS de CALIDAD requeridos en el árEA de proceso DESARrollo de Requisitos.
La definición de la arquitectura se guía por un conjunto de
requisitos de arquitectura desarrollados durante los procesos de
desarrollo de requisitos. Estos requisitos identifican los atributos de
calidad que son críticos para el éxito del producto. La arquitectura
define los elementos estructurales y los mecanismos de
coordinación que o bien satisfacen directamente los requisitos o
bien dan soporte al logro de los requisitos cuando se establecen los
detalles de diseño del producto. Las arquitecturas pueden incluir
estándares y reglas de diseño que gobiernan el desarrollo de los
componentes de producto y de sus interfaces, así como
orientaciones para ayudar a los desarrolladores del producto. Las
prác- ticas específicas de la meta especifica Seleccionar las
soluciones de componentes de producto contienen más
información sobre el uso de las arquitecturas del producto como
base para las soluciones alternativas.
Los arquitectos proponen y desarrollan un modelo de producto,
haciendo juicios sobre la asignación de los requisitos funcionales y
de atributos de calidad a los componentes de producto,
incluyendo hardware y software. Para determinar las ventajas y
desventajas en el contexto de los requisitos de la arquitectura, se
pueden desarrollar y analizar múlti- ples arquitecturas, dando
soporte a soluciones alternativas.
Los conceptos operacionales y los escenarios operacionales, de
soporte y de desarrollo se usan para generar casos de usos y
atributos de calidad relativos a los escenarios que se utilizan para
refinar la calidad de la arquitectura. También se usan como un
medio para evaluar la adecuación de la arquitectura para su
propósito previsto durante las evaluaciones de la arquitectura, las
cuales se llevan a cabo periódica- mente a lo largo del diseño del
producto.
PARA más INFORMACIÓN sobre cómo DESARrOLLAR los conceptos y los ESCENARIOS ope-
RACIONALES USADOS en LA EVALUACIÓN de LA ARQUITECTURA, consúltese LA PRÁCTICA espe-
CIFICA ESTABLECER los conceptos y los ESCENARIOS de OPERACIÓN en el árEA de proceso
algunos ejemplos de tareas de definición de la arquitectura son:

 establecer las relaciones estructurales de particiones y de reglas, con
respecto a las interfaces entre los elementos dentro de las particiones,
y entre las particiones.
 seleccionar los patrones de arquitectura que den soporte a los
requisitos funcionales y a los atributos de calidad, e instanciar o
elaborar los patrones para crear la arquitectura del producto.
 Identificar las principales interfaces internas y todas las interfaces externas.
 Identificar los componentes del producto y las interfaces entre ellos.
 definir formalmente el comportamiento e interacción de los
componentes usando un lenguaje de descripción de la arquitectura.
 definir mecanismos de coordinación (p. ej., para software, hardware).
 establecer capacidades y servicios de la infraestructura.
 desarrollar plantillas, o clases y marcos de trabajo de componentes de
producto.
 establecer reglas de diseño y la autoridad para la toma de decisiones.
 definir un modelo de proceso/hilos de ejecución.
 definir el despliegue físico del software al hardware.
 Identificar las principales aproximaciones y fuentes de reutilización.
Durante el diseño detallado, se finalizan los detalles de la

arquitectura del producto, se definen completamente los
componentes de producto y se caracterizan totalmente las interfaces.
Los diseños de los componentes de producto pueden optimizarse
para determinados atributos de calidad. Los diseñadores pueden
evaluar el uso de productos heredados o de COTS para los
componentes de producto. A medida que madura el diseño, los
requisitos asignados a los componentes de producto de nivel inferior
se siguen para asegurar que se satisfacen esos requisitos.
PARA más INFORMACIÓN sobre cómo ASEGURAR LA ALINEACIÓN entre los requisitos y el
TRABAJO del proyecto, consúltese el árEA de proceso Gestión de Requisitos.
Para la ingeniería de software, el diseño detallado se enfoca
en el desarrollo software de componentes de producto. Se define
la estructura interna de los componentes de producto, se generan
los esquemas de datos, se desarrollan los algoritmos y se
establecen las heurísticas para proporcionar las capacidades de
los componentes de producto que satisfagan los requisitos
asignados.
Para la ingeniería del hardware, el diseño detallado se enfoca
en el desarrollo de productos electrónicos, mecánicos,
electroópticos y otros productos de hardware y sus componentes.
Se desarrollan los esquemas eléctricos y diagramas de
interconexión, se generan los modelos mecánicos y ópticos de
ensamblaje, y se desarrollan los procesos de fabricación y de
ensamblaje.

1. Arquitectura del producto.
2. Diseño del componente de producto.
TS
SUBPRÁCTICAS
1. Establecer y mantener los criterios frente a los cuales puede
evaluarse el diseño.
algunos ejemplos de atributos de calidad, además de prestación esperada

del producto, para los cuales pueden establecerse criterios de diseño, son:
 Modular.
 Claro.
 simple.
 Fácil de mantener.
 Verificable.
 portátil.
 Fiable.
 exacto.
 seguro.
 escalable.
 utilizable.
2. Identificar, desarrollar o adquirir los métodos de diseño

apropiados para el producto.
Los métodos de diseño eficaces pueden incorporar un amplio
rango de actividades, herramientas y técnicas descriptivas. Que
un determinado método sea eficaz o no, depende de la situación.
Dos compañías pueden tener métodos de diseño eficaces para los
productos en los cuales se especializan, pero estos métodos
pueden no ser eficaces en proyectos de cooperación. Los
métodos excesivamente sofisticados
no son necesariamente eficaces en manos de diseñadores que no
se han formado en el uso de los métodos.
Que un método sea eficaz también depende de cuanta ayuda propor-
cione al diseñador y de la eficacia del coste de esa ayuda. Por ejemplo,
un esfuerzo en la creación de un prototipo plurianual puede no ser
apropiado para un simple componente de producto, pero podría
ser lo correcto para un desarrollo de producto sin precedentes,
costoso y complejo. Sin embargo, las técnicas de prototipado
rápido, pueden ser altamente eficaces para muchos componentes de
producto. Los métodos que usan herramientas para asegurar que un
diseño abar- cará todos los atributos necesarios para implementar el
diseño de los componentes de producto pueden ser eficaces. Por
ejemplo, una herramienta de diseño que “conoce” las capacidades de
los procesos de fabricación, puede permitir que la variabilidad del
proceso de fabrica- ción sea considerada en las tolerancias del diseño.
algunos ejemplos de técnicas y métodos que facilitan un diseño eficaz son:

 prototipos.
 Modelos estructurales.
 diseño orientado a objetos.
 análisis esencial de sistemas.
 Modelos de entidad-relación.
 reutilización del diseño.
 patrones de diseño.
3. Asegurar que el diseño se adhiere a los estándares y a los

criterios de diseño aplicables.
algunos ejemplos de estándares de diseño son (algunos o todos

estos estándares pueden ser criterios de diseño, particularmente en
circunstancias donde los estándares no se han establecido):
 estándares de interfaz del operador.
 escenarios de prueba.
 estándares de protección.
 restricciones de diseño (p. ej., compatibilidad electromagnética,
integridad de la señal, ambiental).
 restricciones de producción.
 tolerancias del diseño.
 estándares de piezas (p. ej., desechos, residuos de la producción).
4. Asegurar que el diseño se adhiere a los requisitos asignados.
Deberían tenerse en cuenta los componentes del producto COTS
identificados. Por ejemplo, introducir componentes de producto
exis-
tentes en la arquitectura del producto podría modificar los
requisitos y la asignación de requisitos.
5. Documentar el diseño.
SP 2.2 E sTablEcEr un paquETE dE daTos Técnicos
Establecer y mantener un paquete de datos técnicos.
Un paquete de datos técnicos proporciona al desarrollador una

des- cripción completa del producto o del componente de
producto a medida que se desarrolla. Este paquete también
proporciona flexibilidad en la adquisición bajo diversas
circunstancias, tales como la contratación basada en el
rendimiento o según el diseño del cliente (build-to-print) (véase la
definición de “paquete de datos técnicos” en el glosario).
El diseño se registra en un paquete de datos técnicos que se crea
durante el diseño preliminar para documentar la definición de la
arquitectura. Este paquete de datos técnicos se mantiene durante
TS
toda la vida del producto para registrar los detalles esenciales del
diseño del producto. El paquete de datos técnicos proporciona la
descripción de un producto o componente de producto (incluyendo
los procesos del ciclo de vida relativos al producto si no se
manejan como componentes de producto separados), que da
soporte a una estrategia de adquisición, o a las fases de
implementación, producción, ingeniería y soporte logístico del
ciclo de vida del producto. La descripción incluye la definición de
la confi- guración y de los procedimientos de diseño requeridos
para asegurar la adecuación del rendimiento del producto o del
componente de produc- to. Incluye todos los datos técnicos
aplicables, tales como esquemas, listas asociadas, especificaciones,
descripciones de diseño, base de datos del diseño, estándares,
requisitos de los atributos de calidad, disposiciones para asegurar
la calidad y detalles de empaquetado. El paquete de datos técnicos
incluye una descripción de la solución alternativa seleccionada
que fue elegida para la implementación.
Debido a que las descripciones de diseño pueden implicar una
gran cantidad de datos y que pueden ser cruciales para el éxito
del desarrollo del componente de producto, es aconsejable
establecer los criterios para organizar los datos y para seleccionar
el contenido de los datos. Es particularmente útil usar la
arquitectura del producto como un medio para organizar estos
datos, y para abstraer vistas que son claras y relevantes para una
cuestión o una característica de interés. Estas vistas incluyen:
• Clientes.
• Requisitos.
• El entorno.
• Funcional.
• Lógica.
• Seguridad.
• Datos.
• Estados/modos.
• Construcción.
• Gestión.
Estas vistas se documentan en el paquete de datos técnicos.

Ejemplo de producto de TRABAJO
1. Paquete de datos técnicos.
SUBPRÁCTICAS
1. Determinar el número de niveles de diseño y el nivel
apropiado de documentación para cada nivel de diseño.
Determinar el número de niveles de componentes de producto (p.
ej., subsistema, elemento de configuración del hardware, tarjeta
de circuitos, elemento de configuración de software de
ordenador [CSCI], componente de producto software de
ordenador, unidad software de ordenador) que requieren
documentación y trazabilidad de requisitos, es importante para
gestionar los costes de la documentación y dar soporte a los
planes de integración y verificación.
2. Determinar las vistas que se utilizaran para documentar la
arquitectura. Se seleccionan las vistas para documentar las
estructuras inherentes al producto y para tratar las
preocupaciones particulares de las partes
interesadas.
3. Basar las descripciones de diseño detallado en los requisitos
asignados a los componentes de producto, a la arquitectura y a
los diseños de más alto nivel.
4. Documentar el diseño en el paquete de datos técnicos.
5. Documentar las decisiones claves (es decir, efecto significativo
sobre coste, calendario o rendimiento técnico) tomadas o
definidas, incluyendo su análisis razonado.
6. Modificar el paquete de datos técnicos según sea necesario.
SP 2.3 disEñar las inTErfacEs usando criTErios
Diseñar las interfaces de componentes usando los criterios establecidos.
Algunos diseños de interfaz son:
• Origen.
• Destino.
• Características de datos y de estímulo para software,
incluyendo restricciones de secuenciación o de protocolos.
• Recursos consumidos procesando un estímulo particular.
• Comportamiento del tratamiento de excepciones o de errores
para estímulos que son erróneos o están fuera de los límites
especificados.
• Características eléctricas, mecánicas y funcionales para el hardware.
• Líneas de servicio de comunicación.
Los criterios para las interfaces reflejan con frecuencia los

paráme- tros críticos que deberían definirse, o al menos
investigarse, para comprobar su aplicabilidad. Estos parámetros
son a menudo particulares para un tipo dado de producto (p. ej.,
software, mecánico, eléctrico, servicio) y, a menudo, se asocian
con características de protección, seguridad, durabilidad y misión
crítica.
PARA más INFORMACIÓN sobre cómo IDENTIFICAR requisitos de LA interFAZ de producto
y de componente de producto, consúltese LA PRÁCTICA ESPECÍFICA IDENTIFICAR los re-
quisitos de interFAZ en el árEA de proceso DESARrollo de Requisitos.

1. Especificaciones del diseño de la interfaz.
TS
2. Documentos de control de la interfaz.
3. Criterios de especificación de la interfaz.
4. Análisis razonado del diseño seleccionado de la interfaz.
SUBPRÁCTICAS
1. Definir los criterios de la interfaz.
Estos criterios pueden formar parte de los activos de proceso de
la organización.
PArA más informAción sobre cómo estAblecer y mAntener un conjunto utilizA-
ble de Activos de proceso de lA OrgAnizAción y los estándAres de entorno de trA-
bAjo, consúltese el áreA de proceso Definición de Procesos de lA OrgAnizAción.
2. Identificar las interfaces asociadas con otros componentes de producto.
3. Identificar las interfaces asociadas con elementos externos.
4. Identificar las interfaces entre los componentes de producto y
los procesos de ciclo de vida relativos al producto.
Por ejemplo, tales interfaces podrían incluir aquellas entre un
componente de producto a fabricarse, y las plantillas y los
accesorios utilizados para permitir la construcción durante el
proceso de fabricación.
5. Aplicar los criterios para las alternativas de diseño de la
interfaz. Para más información sobre cómo analizar posibles
decisiones utilizando un proceso de evaluación formal que
evalúe las alternativas
identificadas frente a los criterios establecidos, consúltese el área
de proceso Análisis de Decisiones y Resolución.
6. Documentar los diseños de la interfaz seleccionados y el
análisis razonado de la selección.
SP 2.4 r Ealizar los análisis sobrE si hacEr , comprar o rEuTilizar
Evaluar si los componentes de producto se deberían desarrollar, comprar o
reutilizar en base a criterios establecidos.
La determinación de qué productos o componentes de producto

se- rán adquiridos, se denomina con frecuencia “análisis sobre si
hacer- o-comprar”. Se basa en un análisis de las necesidades del
proyecto. Este análisis sobre si hacer-o-comprar comienza en
fases tempranas del proyecto durante la primera iteración del
diseño; continúa durante el proceso de diseño; y se termina con la
decisión de desarrollar, adquirir o reutilizar el producto.
PARA más INFORMACIÓN sobre cómo educir, ANALIZAR y ESTABLECER requisitos de clien-
te, de producto y de componente de producto, consúltese el árEA de proceso DESA-
rrollo de Requisitos.
PARA más INFORMACIÓN sobre cómo GESTIONAR requisitos, consúltese el árEA de pro-
ceso Gestión de Requisitos.
Algunos factores que afectan a la decisión de hacer o comprar son:
• Funciones que los productos proporcionarán y cómo estas
funciones se ajustarán al proyecto.
• Recursos y habilidades disponibles del proyecto.
• Costes de adquisición frente a costes de desarrollo interno.
• Fechas críticas de integración y de entrega.
• Alianzas de negocio estratégicas, incluyendo requisitos de
negocio de alto nivel.
• Investigación de mercado de productos disponibles,
incluyendo productos COTS.
• Funcionalidad y calidad de los productos disponibles.
• Habilidades y capacidades de los proveedores potenciales.
• Impacto en las competencias básicas.
• Licencias, garantías, responsabilidades y limitaciones
asociadas con los productos que están siendo adquiridos.
• Disponibilidad del producto.
• Cuestiones de propiedad.
• Reducción del riesgo.
• Correspondencia entre las necesidades y los activos básicos
de la línea de producto.
La decisión de hacer o comprar puede ser llevada a cabo

usando un aproximación formal de evaluación.
so de evAluAción formAl que evAlúe lAS AlternAtivAS identificAdAS frente A los crite-
rios estAblecidos, consúltese el áreA de proceso Análisis de Decisiones y Resolución.
A medida que la tecnología evoluciona, también lo hace el
análisis razonado para elegir desarrollar o comprar un
componente de produc- to. Mientras los esfuerzos de desarrollo
complejos pueden favorecer la compra de un componente de
producto comercial, los avances en productividad y
herramientas pueden proporcionar un análisis razonado de
oposición. Los productos comerciales pueden tener
documentación incompleta o inexacta, y pueden o no tener
soporte en el futuro.
Una vez que se toma la decisión de comprar un componente
de producto comercial, cómo implementar esa decisión depende
del tipo de elemento que está siendo adquirido. Hay veces que el
“producto COTS” se refiere a un elemento existente que no está
disponible, debido a que antes debe ser adaptado para cumplir
con los requisitos particulares especificados por el comprador
respecto a prestaciones y otras características del producto como
parte de su adquisición (p. ej., motores de aeronaves). Para
gestionar estas adquisiciones, se establece un acuerdo con el
proveedor que incluya estos requisitos y los criterios de aceptación
que se deben cumplir. En otros casos, el producto COTS se
adquiere tal cual (por ejemplo, los procesadores de texto), y no es
necesario gestionar ningún acuerdo con el proveedor.
PARA más INFORMACIÓN sobre MANEJAR los ACUERdos con el proveedor PARA produc-
tos MODIFICADOS COTS, consúltese LA PRÁCTICA ESPECÍFICA ESTABLECER ACUERdos con
TS
proveedores en el árEA de proceso Gestión de Acuerdos con Proveedores.

1. Criterios para la reutilización del diseño y del componente de
producto.
2. Análisis sobre hacer o comprar.
3. Guías para elegir componentes de producto COTS.
SUBPRÁCTICAS
1. Desarrollar los criterios para la reutilización de los diseños de
2. Analizar los diseños para determinar si deberían desarrollarse,
reutilizarse o comprarse los componentes de producto.
3. Analizar las implicaciones para el mantenimiento cuando se
considera comprar o no desarrollar algunos elementos (p. ej.,
COTS, productos comerciales gubernamentales, de
reutilización).
algunos ejemplos de implicaciones para el mantenimiento son:

 Compatibilidad con futuras versiones de productos COts.
 gestión de la configuración de cambios del proveedor.
 defectos en el elemento no desarrollado y su resolución.
 Obsolescencia imprevista.
SG 3 i mPlementar el DiSeño Del ProDucto
Los componentes de producto y la documentación de soporte asociada son im-
plementados a partir de sus diseños.
Los componentes de producto se implementan a partir de los

dise- ños establecidos por las prácticas específicas en la meta
específica Desarrollar el diseño. Generalmente la
implementación incluye las pruebas unitarias de los componentes
de producto antes de enviarlos a la integración del producto y del
desarrollo de la documentación del usuario final.
SP 3.1 i mplEmEnTar El disEño
Implementar los diseños de los componentes de producto.
Una vez que el diseño se ha terminado, se implementa como un

componente de producto. Las características de esa
implementación dependen del tipo de componente de producto.
La implementación del diseño en el nivel superior de la je-
rarquía de producto implica la especificación de cada uno de los
componentes de producto en el siguiente nivel de la jerarquía
del producto. Esta actividad incluye la asignación, el
refinamiento y la verificación de cada componente de
producto. También implica la coordinación entre los esfuerzos
de desarrollo de los diferentes componentes de producto.
PARA más INFORMACIÓN sobre cómo GESTIONAR LAS interFACES y ENSAMBLAR los compo-
nentes de producto, consúltese el árEA de proceso INTEGRACIÓN del Producto.
PARA más INFORMACIÓN sobre cómo ASIGNAR requisitos de componente de producto y
ANALIZAR requisitos, consúltese el árEA de proceso DESARrollo de Requisitos.
algunos ejemplos de características de esta implementación son:

 se codifica el software.
 se documentan los datos.
 se documentan los servicios.
 se fabrican las piezas eléctricas y mecánicas.
 se hacen operativos los procesos de fabricación de productos únicos.
 se documentan los procesos.
 se construyen las instalaciones.
 se producen los materiales (p. ej., un material de producto único podría
ser el petróleo, el aceite, un lubricante, una nueva aleación).
Ejemplo de producto de TRABAJO
1. El diseño implementado.
SUBPRÁCTICAS
1. Usar métodos eficaces para implementar los componentes de
producto.
algunos ejemplos de métodos de codificación del software son:

 programación estructurada.
 programación orientada a objetos.
 programación orientada a aspectos.
 generación automática de código.
 reutilización de código software.
 uso de patrones aplicables al diseño.
algunos ejemplos de métodos de implementación de hardware son:

 síntesis a nivel de puerta lógica.
TS
 diseño de la placa de circuito impreso (posición y conexiones).
 diseño gráfico asistido por ordenador.
 simulación posterior al diseño.
 Métodos de fabricación.
2. Adherirse a los estándares y a los criterios aplicables.
algunos ejemplos de los estándares de implementación son:

 estándares de lenguaje (p. ej., estándares para lenguajes de
programación de software, lenguajes de descripción de hardware).
 requisitos de diagramación.
 Listas de piezas estándar.
 piezas fabricadas.
 estructura y jerarquía de los componentes de producto software.
 estándares de procesos y de calidad.
algunos ejemplos de criterios son:

 Modularidad.
 Claridad.
 simplicidad.
 Fiabilidad.
 protección.
 Mantenibilidad.
3. Llevar a cabo revisiones entre pares de los componentes de
produc- to seleccionados.
4. Realizar pruebas unitarias del componente de producto según
sea apropiado.
Nótese que las pruebas unitarias no están limitadas al software.
Las pruebas unitarias implican la prueba de unidades
individuales de hardware o de software o de grupos de
elementos relacionados antes de la integración de esos
elementos.
algunos ejemplos de métodos de pruebas unitarias (manuales o

automáticas) son:
 pruebas de cobertura de sentencias.
 pruebas de cobertura de decisiones.
 pruebas de cobertura de predicados.
 pruebas de cobertura de caminos.
 pruebas de valores límites.
 pruebas de valores especiales.
algunos ejemplos de métodos de pruebas unitarias son:

 prueba funcional.
 prueba de inspección de radiación.
 prueba medioambiental.
5. Modificar el componente de producto según sea necesario.
un ejemplo de cuando el componente de producto puede necesitar

modificarse es cuando surgen problemas durante la implementación que
no pudieron preverse durante el diseño.
SP 3.2 d Esarrollar la documEnTación dE soporTE dEl pro ducTo

Desarrollar y mantener la documentación de uso final.
Esta práctica específica desarrolla y mantiene la documentación

que será usada para instalar, operar y mantener el producto.

1. Materiales de formación del usuario final.
2. Manual de usuario.
3. Manual del operador.
4. Manual de mantenimiento.
5. Ayuda en línea.
SUBPRÁCTICAS
1. Revisar los requisitos, el diseño, el producto y los resultados
de pruebas para asegurar que se identifican y resuelven las
cuestiones que afectan a la documentación de instalación, de
operación y de mantenimiento.
2. Utilizar métodos eficaces para desarrollar la documentación de
ins- talación, de operación y de mantenimiento.
3. Adherirse a los estándares aplicables de documentación.
algunos ejemplos de estándares de documentación son:

 Compatibilidad con los procesadores de textos designados.
 Fuentes aceptables.
 numeración de páginas, secciones y párrafos.
TS
 Consistencia con un manual de estilo designado.
 uso de abreviaturas.
 Marcas de clasificación de seguridad.
 requisitos de internacionalización.
4. Desarrollar las versiones preliminares de la documentación de

instala- ción, de operación y de mantenimiento en fases iniciales
del ciclo de vida del proyecto para su revisión por las partes
5. Llevar a cabo revisiones entre pares de la documentación de
insta- lación, de operación y de mantenimiento.
6. Modificar la documentación de instalación, de operación y de
mantenimiento según sea necesario.
algunos ejemplos de cuándo puede ser necesario modificar la

documentación son cuando:
 se realizan cambios de requisitos.
 se realizan cambios de diseño.
 se realizan cambios de producto.
 se identifican errores de documentación.
 se identifican correcciones mediante soluciones temporales.
vALIDAcIÓN
Un área de proceso de Ingeniería en el nivel de madurez 3.
Propósito
El propósito de la Validación (VAL) es demostrar que un
producto o componente de producto cumple con su uso previsto
cuando se ubica en el entorno previsto.
Las actividades de validación se pueden aplicar a todos los
aspectos del producto en cualquiera de sus entornos previstos,
tales como ope- ración, formación, fabricación, mantenimiento y
servicios de soporte. Los métodos empleados para lograr la
validación se pueden aplicar a productos de trabajo, así como al
producto y los componentes de producto (en la totalidad de las
áreas de proceso, cuando se utilizan los términos “producto” y
“componente de producto”, los significados también abarcan los
servicios, sistemas de servicios y sus componentes). Los
productos de trabajo (p. ej., requisitos, diseños, prototipos) se
deberían seleccionar sobre la base de cuáles son los que mejor
predicen cómo el producto y el componente de producto
VAL
satisfarán las necesidades del usuario final, y de esta manera la
validación se realiza de forma temprana (fases de
concepto/exploración) e incremental a lo largo del ciclo de vida
del producto (incluyendo la transición a operaciones y soporte).
El entorno de validación debería representar el entorno previsto
para el producto y los componentes de producto, así como el
entorno previsto adecuado para las actividades de validación con
los productos de trabajo.
La validación demuestra que el producto, tal cual se propor-
ciona, cumplirá con su uso previsto; mientras que, la verificación
contempla si el producto de trabajo refleja adecuadamente los requi-
sitos especificados. En otras palabras, la verificación asegura que
“lo construyó correctamente”; mientras que la validación
asegura que “construyó lo correcto”. Las actividades de
validación utilizan enfoques similares a la verificación (p. ej.,
pruebas, análisis, inspección, demostración, simulación).
Frecuentemente, los usuarios finales y otras partes interesadas
relevantes están involucrados en las actividades de validación.
Tanto las actividades de validación como las de
531
verificación, se suelen ejecutar concurrentemente y pueden
utilizar partes del mismo entorno.
PARA más INFORMACIÓN sobre cómo ASEGURAR que los productos de TRABAJO se-
LECCIONADOS cumplen sus requisitos ESPECIFICADOS, consúltese el árEA de proceso
VERIFICACIÓN.
Siempre que sea posible, se debería realizar la validación
utilizando el producto o componente de producto operando en
su entorno previsto. Se puede utilizar el entorno completo o sólo
una parte de él. Sin embargo, las cuestiones de validación se
pueden descubrir de forma temprana en la vida del proyecto
utilizando productos de trabajo mediante la involucración de las
partes interesadas relevantes. Las actividades de validación para
servicios se pueden aplicar a productos de trabajo, tales como
propuestas, catálogos de servicio, declaración del trabajo y
registros de servicios.
Para resolver las cuestiones detectadas en la validación, éstas se
remiten a los procesos asociados con las áreas de proceso
Desarrollo de Requisitos, Solución Técnica, o Monitorización y
Control del Proyecto.
Las prácticas específicas de este área de proceso se
complementan unas con otras de la siguiente forma:
• La práctica específica Seleccionar los productos para la
validación permite la identificación del producto o del
componente de producto a validar y los métodos a usar para
realizar la validación.
• La práctica específica Establecer el entorno de validación
permite la determinación del entorno a utilizar para llevar a
cabo la validación.
• La práctica específica Establecer los procedimientos y los
criterios de validación permite el desarrollo de los
procedimientos y criterios de validación que están alineados
con las características de los productos seleccionados, las
restricciones del cliente sobre la validación, los métodos y el
entorno de validación.
• La práctica específica Realizar la validación permite la
realización de la validación de acuerdo a los métodos, los
procedimientos y los criterios.

PARA los requisitos, consúltese el árEA de proceso Solución TÉCNICA.
PARA más INFORMACIÓN sobre cómo ASEGURAR que los productos de TRABAJO selec-
CIONADOS SATISFACEN sus requisitos ESPECIFICADOS, consúltese el árEA de proceso
VERIFICACIÓN.
Validación 533

sg1 preparar la validación.
sp 1.1 seleccionar los productos para la validación.
sp 1.2 establecer el entorno de validación.
sp 1.3 establecer los procedimientos y los criterios de validación.
sg 2 Validar el producto o los componentes de producto.
sp 2.1 realizar la validación.
sp 2.2 analizar los resultados de la validación.
Prácticas específicas por metas
SG1 P reParar la valiDación

Se prepara la validación.
Las actividades de preparación incluyen la selección de los

productos y componentes de producto para la validación, y el
establecimiento y mantenimiento del entorno, de los
procedimientos y de los criterios de validación. Los elementos
seleccionados para la validación pueden incluir solo el producto o
pueden incluir niveles adecuados de componentes de producto
utilizados para construir el producto. Cualquier producto o
componente de producto puede estar sujeto a validación,
incluyendo productos de repuesto, de mantenimiento y de
formación, por nombrar algunos.
Se prepara el entorno requerido para validar el producto o
componente de producto. El entorno se puede comprar o se puede
especificar, diseñar y construir. Los entornos utilizados para la
integración y verifica- ción del producto se pueden considerar en
VAL
colaboración con el entorno de validación para reducir costes y
mejorar la eficiencia o la productividad.
SP 1.1 s ElEccionar los producTos para la Validación
Seleccionar los productos y los componentes de producto a validar y los méto-
dos de validación a utilizar.
Se seleccionan los productos y los componentes de producto para

la validación teniendo en cuenta su relación con las necesidades
del usuario final. Para cada componente de producto, se debería
determinar el alcance de la validación (p. ej., comportamiento
operativo, mantenimiento, formación e interfaz de usuario).
algunos ejemplos de productos y componentes de producto que se

pueden validar son:
 requisitos y diseños de producto y de componente de producto.
 producto y componentes de producto (p. ej., sistema, unidades de
hardware, software y documentación de servicios).
Continúa
Continuación
 Interfaces de usuario.
 Manuales de usuario.
 Materiales de formación.
 documentación del proceso.
 protocolos de acceso.
 Formatos de informes de intercambio de datos.
Se recogen los requisitos y las restricciones para realizar la

valida- ción. Posteriormente, se seleccionan los métodos de
validación en base a su capacidad para demostrar que se satisfacen
las necesidades del usuario final. Los métodos de validación no sólo
definen el enfoque para la validación del producto, sino que
también dirigen las necesidades de las instalaciones, equipamiento
y entornos. El enfoque y las necesidades de validación pueden
generar requisitos de componente de producto de más bajo nivel
que son tratados por los procesos de desarrollo de requisitos. Se
pueden generar requisitos derivados, tales como requisitos de
interfaz para conjuntos de prueba y equipamiento de prueba. Estos
requisitos también pueden pasar a los procesos de desarrollo de
requisitos para asegurar que el producto o los componentes de
producto se pueden validar en un entorno que da soporte a los
métodos.
Los métodos de validación se deberían seleccionar pronto en la
vida del proyecto para que sean claramente comprendidos y
aceptados por las partes interesadas relevantes.
Los métodos de validación contemplan el desarrollo,
mantenimiento, soporte y formación para el producto o
componente de producto, según sea apropiado.
algunos ejemplos de métodos de validación son:

 debates con los usuarios finales, tal vez en el contexto de una revisión
formal.
 demostraciones de prototipos.
 demostraciones funcionales (p. ej., sistema, unidades de hardware,
software, documentación de servicios, interfaces de usuario).
 pilotos de materiales de formación.
 pruebas de productos y de componentes de producto por los usuarios
finales y otras partes interesadas relevantes.
 entrega incremental del trabajo y del producto potencialmente aceptable.
 análisis de producto y de componentes de producto (p. ej.,
simulaciones, modelado, análisis de usuario).
Las actividades de validación de hardware incluyen el modelado
para validar la forma, el ajuste y la función de los diseños mecánicos;
el modelado térmico; el análisis de mantenibilidad y fiabilidad;
demostraciones en el tiempo; y simulaciones de diseño eléctrico de
componentes de producto electrónicos o mecánicos.
Validación 535
1. Listas de productos y de componentes de producto
seleccionados para la validación.
2. Métodos de validación para cada producto o componente de
producto.
3. Requisitos para realizar la validación para cada producto o
componente de producto.
4. Restricciones de la validación para cada producto o
SUBPRÁCTICAS
1. Identificar los principios, características y fases clave para la
valida- ción del producto o componente de producto a lo largo
de la vida del proyecto.
2. Determinar qué categorías de las necesidades del usuario final
(operativa, mantenimiento, formación o soporte) se validarán.
El producto o componente de producto debería ser fácil de
mantener y soportar en su entorno operacional previsto. Esta
práctica específica también contempla los servicios de
mantenimiento, de formación y de soporte reales, que se pueden
entregar con el producto.
un ejemplo de evaluación de conceptos de mantenimiento en el

entorno operacional es una demostración de que las herramientas de
mantenimiento están operando con el producto real.
3. Seleccionar el producto y los componentes de producto a validar.
VAL
4. Seleccionar los métodos de evaluación para la validación del
producto o del componente de producto.
5. Revisar la selección, las restricciones y los métodos de
validación con las partes interesadas relevantes.
SP 1.2 E sTablEcEr El EnTorno dE Validación
Establecer y mantener el entorno necesario para dar soporte a la validación.
Los requisitos para el entorno de validación se deben al producto

o los componentes de producto seleccionados, al tipo de
productos de trabajo (p. ej., diseño, prototipo, versión final), y a
los métodos de validación. Estas selecciones pueden producir
requisitos para la compra o el desarrollo de equipamiento,
software u otros recursos. Estos requisitos se proporcionan a los
procesos de desarrollo de requisitos para su desarrollo. El
entorno de validación puede incluir la reutiliza- ción de recursos
existentes. En este caso, se deberían llegar a acuerdos para la
utilización de estos recursos.
algunos tipos de elementos en un entorno de validación son:

 Herramientas de prueba relacionadas con el producto que se está
validando (p. ej., alcance, dispositivos electrónicos y sensores).
 software de prueba embebido temporalmente.
 Herramientas de grabación para descarga o posterior análisis y
repetición.
 subsistemas o componentes simulados (p. ej., software, electrónicos,
mecánicos).
 sistemas de interfaz simulados (p. ej., un barco de guerra simulado para
probar un radar naval).
 sistemas de interfaz reales (p. ej., un avión para probar un radar con
instalaciones de seguimiento de trayectoria).
 Instalaciones y productos proporcionados por el cliente.
 personal cualificado para operar o utilizar todos los elementos
precedentes.
 entorno de pruebas de cálculo o de red dedicado (p. ej., banco de pruebas
de una red de telecomunicación pseudo-operacional o instalaciónde
pruebas con líneas troncales, interruptores y sistemas reales establecidos
para la integración y ensayos realistas de validación).
Para asegurar que el entorno de validación esté disponible

cuando se necesite, se requiere la selección temprana de los
productos o componentes de producto a validar, los productos
de trabajo a utilizar en la validación y los métodos de validación.
El entorno de validación se debería controlar cuidadosamente
para contemplar la replicación, el análisis de resultados y la
revalidación de las áreas problemáticas.

1. Entorno de validación.
SUBPRÁCTICAS
1. Identificar los requisitos para el entorno de validación.
2. Identificar los productos suministrados por el cliente.
3. Identificar el equipamiento y las herramientas de prueba.
4. Identificar los recursos de validación que están disponibles
para su reutilización y modificación.
5. Planificar en detalle la disponibilidad de los recursos.
Validación 537
SP 1.3 E sTablEcEr los procEdimiEnTos y los criTErios dE Validación
Establecer y mantener los procedimientos y los criterios de validación.
Los procedimientos y los criterios de validación se definen para

asegurar que el producto o componente de producto cumplirá su
uso previs- to cuando se ubica en su entorno previsto. Los casos y
procedimientos para la prueba de aceptación se pueden utilizar
para los procedimientos de validación.
Los procedimientos y los criterios de validación incluyen las
pruebas y evaluación de los servicios de mantenimiento, de
formación y de soporte.
algunos ejemplos de fuentes de criterios de validación son:

 requisitos de producto o componente de producto.
 estándares.
 Criterios de aceptación del cliente.
 rendimiento del entorno.
 umbrales de desviación del rendimiento.

1. Procedimientos de validación.
2. Criterios de validación.
3. Procedimientos de prueba y de evaluación para
mantenimiento, formación y soporte.
VAL
SUBPRÁCTICAS
1. Revisar los requisitos de producto para asegurar que se
identifican y resuelven las cuestiones que afectan a la
validación del producto o del componente de producto.
2. Documentar el entorno, escenario operativo, procedimientos,
entradas, salidas y criterios para la validación del producto o
del componente de producto seleccionado.
3. Evaluar el diseño a medida que madura en el contexto del
entorno de validación para identificar cuestiones de validación.
SG 2 v aliDar el ProDucto o loS comPonenteS De ProDucto
El producto o los componentes de producto se validan para asegurar que son
adecuados para su utilización en su entorno operativo previsto.
Se utilizan los métodos, los procedimientos y los criterios de

valida- ción para validar los productos y componentes de
producto seleccionados y cualquier servicio asociado de
mantenimiento, formación y
soporte utilizando el entorno de validación adecuado. Las
actividades de validación se realizan durante todo el ciclo de vida
del producto.
SP 2.1 r Ealizar la Validación
Realizar la validación sobre los productos y los componentes de producto
seleccionados.
Para que las partes interesadas acepten un producto o un

componente de producto, debería funcionar como se espera en su
entorno operativo previsto.
Se realizan las actividades de validación y se recogen los da-
tos resultantes de acuerdo a los métodos, procedimientos y
criterios establecidos.
Se deberían documentar los procedimientos de validación tal
y como se ejecutaron y se deberían anotar las desviaciones que
ocurren durante la ejecución, según proceda.

1. Informes de la validación.
2. Resultados de la validación.
3. Matriz de referencias cruzadas de la validación.
4. Registro de ejecución de los procedimientos.
5. Demostraciones de operación.
SP 2.2 a nalizar los rEsulTados dE la Validación
Analizar los resultados de las actividades de la validación.
Los datos resultantes de las pruebas, inspecciones, demostraciones

o evaluaciones de validación, se analizan frente a los criterios de
valida- ción definidos. Los informes de análisis indican si se
cumplieron las necesidades. En el caso de que existan deficiencias,
estos informes documentan el grado de éxito o fallo, y clasifican las
posibles causas de fallo. Los resultados recogidos de las pruebas,
inspecciones o revisiones se comparan con los criterios de
evaluación establecidos para determinar si se continúa o si se
tratan las cuestiones de requisitos o de diseño en los procesos de
desarrollo de requisitos o de solución técnica.
Los informes de análisis o documentación de ejecución de la
vali- dación también pueden indicar que unos malos resultados de
las pruebas se deben a un problema del procedimiento de
validación o a un problema del entorno de validación.

1. Informes de deficiencias de la validación.
2. Cuestiones de validación.
3. Petición de cambio del procedimiento.
Validación 539
SUBPRÁCTICAS
1. Comparar los resultados reales con los resultados esperados.
2. Identificar los productos y los componentes de producto que
no funcionan adecuadamente en el entorno de operación
previsto, o identificar los problemas con los métodos, criterios
o el entorno, en base a los criterios de validación establecidos.
3. Analizar los datos de validación para encontrar defectos.
4. Registrar los resultados del análisis e identificar cuestiones.
5. Utilizar los resultados de la validación para comparar las
mediciones y el rendimiento reales con el uso previsto o las
necesidades operativas previstas.
6. Proporcionar información sobre cómo pueden resolverse los
defectos (incluyendo métodos de validación, criterios y
entorno de validación) e iniciar acciones correctivas.
PARA más INFORMACIÓN sobre cómo GESTIONAR ACCIONES corrECTIVAS, consúl-
VAL
vERIfIcAcIÓN
Un área de proceso de Ingeniería en el nivel de madurez 3.
Propósito
El propósito de la Verificación (VER) es asegurar que los
productos de trabajo seleccionados cumplen los requisitos
especificados.
El área de proceso Verificación implica lo siguiente: preparación
de la verificación, realización de la verificación e identificación de
acciones correctivas.
La verificación incluye la verificación del producto y de los
productos de trabajo intermedios frente a todos los requisitos se-
leccionados, incluyendo requisitos de cliente, de producto y de
componente de producto. Para líneas de producto, también se
debería verificar los activos base y sus mecanismos asociados de
variación de la línea de producto. A lo largo de las áreas de
proceso, donde se utilizan los términos “producto” y
“componente de producto”, los significados también abarcan los
servicios, los sistemas de servicio y sus componentes.
La verificación es, intrínsecamente, un proceso incremental
debido a que se realiza durante el desarrollo del producto y de
los productos de trabajo, comenzando con la verificación de los
requisitos, continuando con la verificación de los productos de
trabajo que se van desarrollando, y culminando con la
verificación del producto terminado.
Las prácticas específicas de este área de proceso se
VER
complementan unas con otras de la siguiente forma:
• La práctica específica Seleccionar los productos de trabajo
para la verificación permite la identificación de los productos
de trabajo a verificar, los métodos a utilizar para realizar la
verificación, y los requisitos que se deben satisfacer por cada
producto de trabajo seleccionado.
• La práctica específica Establecer el entorno de verificación
permite determinar el entorno que se utilizará para llevar a
cabo la verificación.
541
• La práctica específica Establecer los procedimientos y los
criterios de verificación permite el desarrollo de los
procedimientos y los criterios de verificación que están
alineados con los productos de trabajo seleccionados,
requisitos, métodos y características del entorno de
verificación.
• La práctica específica Realizar la verificación lleva a cabo la
verificación de acuerdo a los métodos, procedimientos y criterios
disponibles.
La verificación de los productos de trabajo incrementa

substan- cialmente la probabilidad que el producto satisfaga los
requisitos de cliente, de producto y de componente de producto.
Las áreas de proceso Verificación y Validación son similares, pero
abordan diferentes cuestiones. La validación demuestra que el
producto, tal y como se proporciona (o tal y como se proporcionará),
cumplirá su uso previsto, mientras que la verificación contempla si el
producto de trabajo refleja adecuadamente los requisitos especificados.
En otras palabras, la verificación asegura que “lo construyó
correctamente”; mientras que, la validación asegura que “construyó
lo correcto”.
Las revisiones entre pares son una parte importante de la
verifica- ción y son un mecanismo probado para eliminar defectos
eficazmente. Un corolario importante es comprender mejor los
productos de trabajo y los procesos que los producen, de tal forma
que se puedan prevenir los defectos y se puedan identificar
oportunidades de mejora de procesos.
Las revisiones entre pares implican una revisión metódica de
los productos de trabajo por compañeros del mismo nivel que los
autores para identificar defectos y otros cambios que son
necesarios.
algunos ejemplos de métodos de revisión entre pares son:

 Inspecciones.
 Walkthroughs.
 refactorización intencionada.
 programación por parejas.
en entornos Ágiles, dada la involucración del cliente y las frecuentes

versiones, la verificación y la validación se apoyan entre sí. por ejemplo,
un defecto puede provocar que falle un prototipo o una versión temprana
durante la validación de forma prematura. a la inversa, la validación
temprana y continua ayuda a asegurar que la verificación se aplica al
producto correcto. Las áreas de proceso Verificación y Validación ayudan a
asegurar un enfoque sistemático para seleccionar los productos de trabajo
a revisar y probar, los métodos y entornos a utilizar y las interfaces a
gestionar, lo cual ayuda a asegurar que los defectos se identifican y se tratan
de forma temprana. Cuanto más complejo sea el producto, más necesario es
un enfoque sistemático para asegurar la compatibilidad entre los requisitos
y las soluciones, y asegurar la consistencia en cómo se utilizará producto
(véase “Interpretando CMMI al utilizar enfoques Ágiles” en la primera parte).
Verificación 543

PARA más INFORMACIÓN sobre cómo DEMOSTRAR que un producto o componente de
producto cumple con el uso previsto CUANDO es puesto en el entorno previsto, con-
súltese el árEA de proceso VALIDACIÓN.
PARA más INFORMACIÓN sobre cómo ASEGURAR el ALINEAMIENTO entre el TRABAJO del
proyecto y los requisitos, consúltese el árEA de proceso Gestión de Requisitos.

sg 1 preparar la verificación.
sp 1.1 seleccionar los productos de trabajo para la verificación.
sp 1.2 establecer el entorno de verificación.
sp 1.3 establecer los procedimientos y los criterios de verificación.
sg 2 realizar las revisiones entre pares.
sp 2.1 preparar las revisiones entre pares.
sp 2.2 realizar las revisiones entre pares.
sp 2.3 analizar los datos de las revisiones entre pares.
sg 3 Verificar los productos de trabajo seleccionados.
sp 3.1 realizar la verificación.
sp 3.2 analizar los resultados de la verificación.
SG 1 P reParar la verificación
Se prepara la verificación.
Una preparación previa es necesaria para asegurar que las

disposiciones de verificación están integradas en los requisitos
de producto y de componente de producto, en los diseños, en los
planes de desarrollo y en los calendarios. La verificación incluye
la selección, inspección, prueba, análisis y demostración de los
VER
Los métodos de verificación incluyen, pero no están limitados
a, inspecciones, revisiones entre pares, auditorías, walkthroughs,
análi- sis, evaluaciones de arquitectura, simulaciones, pruebas y
demostraciones. Las prácticas relacionadas con las revisiones
entre pares como método específico de verificación, se incluyen
en la meta específica 2. La preparación también implica la
definición de herramientas de soporte, equipamiento y software
de prueba, simulaciones, prototipos
e instalaciones.
SP 1.1 s ElEccionar los producTos dE Trabajo para la VErificación
Seleccionar los productosde trabajo averificar y losmétodosdeverificación autilizar.
Los productos de trabajo se seleccionan en base a su contribución

para conseguir los objetivos y los requisitos del proyecto, y para
tratar los riesgos del proyecto.
Los productos de trabajo a verificar pueden incluir aquellos
asociados con servicios de mantenimiento, de formación y de
soporte. Los requisitos de los productos de trabajo para la
verificación se incluyen con los métodos de verificación. Los
métodos de verificación tratan el enfoque para la verificación de
los productos de trabajo y los enfoques específicos que se
utilizarán para verificar que los productos de trabajo específicos
cumplen sus requisito
algunos ejemplos de métodos de verificación son:

 evaluación de la arquitectura de software y evaluación de la
conformidad de la implementación.
 pruebas de cobertura de caminos.
 pruebas de carga, de estrés y de rendimiento.
 pruebas basadas en tablas de decisión.
 pruebas basadas en descomposición funcional.
 reutilización de casos de prueba.
 pruebas de aceptación.
 Integración continua (es decir, enfoque Ágil que identifica cuestiones
de integración en las etapas iniciales).
La verificación para ingeniería de sistemas normalmente incluye

prototipado, modelado y simulación para verificar la idoneidad del diseño
del sistema (y asignación).
La verificación para ingeniería de hardware normalmente requiere un

enfoque paramétrico que considere diversas condiciones de entorno
(p.ej., presión, temperatura, vibración, humedad), diversos rangos de
entrada (p.ej., la potencia de entrada podría valorarse de 20V a 32V para
un nominal planificado de 28V), las variaciones inducidas de parte a parte
por cuestiones de tolerancia, y muchas otras variables. La verificación de
hardware normalmente prueba la mayoría de las variables por separado
excepto cuando se sospecha que existen interacciones problemáticas.
La selección de los métodos de verificación normalmente
comienza con la definición de los requisitos de producto y de
componente de producto asegurando que los requisitos son
verificables. La re-verifica- ción debería tratarse por los métodos
de verificación para asegurar que el re-trabajo realizado sobre los
productos de trabajo no cause defectos involuntarios. Los
proveedores deberían estar involucrados en esta selección para
asegurar que los métodos del proyecto son adecuados para el
entorno del proveedor.
Verificación 545
1. Lista de productos de trabajo seleccionados para la verificación.
2. Métodos de verificación para cada producto de trabajo seleccionado.
SUBPRÁCTICAS
1. Identificar los productos de trabajo para la verificación.
2. Identificar los requisitos a satisfacer por cada producto de
trabajo seleccionado.
PARA más INFORMACIÓN sobre cómo TRAZAR los requisitos A los productos
de TRABAJO, consúltese LA PRÁCTICA ESPECÍFICA MANTENER LA TRAZABILIDAD bi-
dirECCIONAL de los requisitos en el árEA de proceso Gestión de Requisitos.
3. Identificar los métodos de verificación disponibles.
4. Definir los métodos de verificación a utilizar para cada
producto de trabajo seleccionado.
5. Proponer la identificación de productos de trabajo a verificar,
los requisitos a satisfacer y los métodos a utilizar, para la
integración con el plan de proyecto.
PARA más INFORMACIÓN sobre cómo DESARrOLLAR el PLAN de proyecto, consúl-
tese el árEA de proceso PLANIFICACIÓN del Proyecto.
SP 1.2 E sTablEcEr El EnTorno dE VErificación

Establecer y mantener el entorno necesario para dar soporte a la verificación.
Se debería establecer un entorno para permitir que tenga lugar la

verificación. El entorno de verificación puede ser adquirido,
desarrollado, reutilizado, modificado o se puede obtener
utilizando una combinación de estas actividades, dependiendo de
las necesidades del proyecto.
El tipo de entorno necesario depende de los productos de
trabajo seleccionados para la verificación y de los métodos de
verificación utilizados. Una revisión entre pares puede requerir
poco más que un conjunto de materiales, revisores y una sala.
Una prueba de producto puede requerir simuladores, emuladores,
generadores de escenarios, herramientas de reducción de datos,
VER
controles medioambientales e interfaces con otros sistemas.
1. Entorno de verificación.
SUBPRÁCTICAS
1. Identificar los requisitos del entorno de verificación.
2. Identificar los recursos de verificación que están disponibles
para su reutilización o modificación.
3. Identificar el equipamiento y herramientas de verificación.
4. Adquirir equipamiento de soporte y un entorno de verificación
(p.ej. equipamiento de prueba, software).
SP 1.3 E sTablEcEr los procEdimiEnTos y los criTErios dE VErificación
Establecer y mantener los procedimientos y los criterios de verificación para los
productos de trabajo seleccionados.
Los criterios de verificación se definen para asegurar que los

productos de trabajo cumplen sus requisitos.
algunos ejemplos de fuentes de los criterios de verificación son:

 requisitos de producto y de componente de producto.
 estándares.
 políticas de la organización.
 tipos de prueba.
 parámetros de la pruebas.
 parámetros para establecer el equilibrio entre la calidad y el coste de
las pruebas.
 tipos de productos de trabajo.
 proveedores.
 propuestas y acuerdos.
 revisiones de clientes en colaboración con los desarrolladores.

1. Procedimientos de verificación.
2. Criterios de verificación.
SUBPRÁCTICAS
1. Generar un conjunto completo e integrado de procedimientos
de verificación para productos de trabajo y productos COTS,
2. Desarrollar y refinar criterios de verificación según sea necesario.
3. Identificar los resultados esperados, las tolerancias permitidas
y otros criterios que satisfagan los requisitos.
4. Identificar el equipamiento y los componentes del entorno
necesarios para dar soporte a la verificación.
Verificación 547
SG 2 realizar laS reviSioneS entre PareS
Serealizanlasrevisionesentreparessobrelosproductosdetrabajoseleccionados.
Las revisiones entre pares implican un examen metódico de los

productos de trabajo por los compañeros del mismo nivel que
los autores con el fin de identificar defectos para su eliminación y
de recomendar otros cambios que sean necesarios.
La revisión entre pares es un método de verificación
importante y eficaz implementado mediante inspecciones,
walkthroughs, o un nú- mero de otros métodos de revisión
colegiados.
Las revisiones entre pares se aplican principalmente a
productos de trabajo desarrollados en los proyectos, pero también
se pueden aplicar a otros productos de trabajo, tales como
documentación, y productos de trabajo de formación que
normalmente se desarrollan por grupos de soporte.
SP 2.1 prEparar las rEVisionEs EnTrE parEs
Preparar las revisiones entre pares de los productos de trabajo seleccionados.
Las actividades de preparación para la revisión entre pares

normalmente incluye identificar al personal al que se invitará a
participar en la revisión entre pares de cada producto de trabajo;
identificar a los revisores clave que deberían participar en la
revisión entre pares; preparar y actualizar cualquier material a
utilizar durante las revisiones entre pares, tales como las listas de
comprobación y criterios de revi- sión, y el calendario de la
revisión entre pares.

1. Calendario de la revisión entre pares.
2. Lista de comprobación de la revisión entre pares.
3. Criterios de entrada y salida para los productos de trabajo.
4. Criterios para solicitar otra revisión entre pares.
5. Material de formación de la revisión entre pares.
6. Productos de trabajo seleccionados para revisar.
VER
SUBPRÁCTICAS
1. Determinar el tipo de revisión entre pares a realizar.
algunos ejemplos de tipos de revisión entre pares son:

 Inspecciones.
 Walkthroughs.
 revisiones activas.
 evaluación de conformidad de la implementación de la arquitectura.
2. Definir los requisitos para recoger los datos durante la revisión
entre pares.
3. Establecer y mantener los criterios de entrada y salida para la
revi- sión entre pares.
4. Establecer y mantener criterios para solicitar otra revisión
entre pares.
5. Establecer y mantener listas de comprobación para asegurar
que los productos de trabajo se revisan consistentemente.
algunos ejemplos de elementos que se tratan en las listas de

comprobación son:
 reglas de construcción.
 guías de diseño.
 Completitud.
 grado de corrección.
 Mantenibilidad.
 tipos de defectos comunes.
Las listas de comprobación se modifican según sea necesario

para tratar el tipo específico de producto de trabajo y de revisión
entre pares. Los compañeros del mismo nivel que los autores de
las listas de comprobación y los potenciales usuarios finales
revisan las listas de comprobación.
6. Desarrollar un calendario detallado de la revisión entre pares,
incluyendo las fechas para la formación de la revisión entre
pares y cuándo estarán disponibles los materiales para la
revisión entre pares.
7. Asegurar que el producto de trabajo satisface los criterios de
entrada de la revisión entre pares antes de su distribución.
8. Distribuir a los participantes el producto de trabajo a revisar y
su información relacionada con suficiente antelación de forma
que les permita prepararse adecuadamente para la revisión
entre pares.
9. Asignar roles para la revisión entre pares según proceda.
algunos ejemplos de roles son:

 Líder.
 Lector.
 escritor.
 autor.
10. Prepararse para la revisión entre pares mediante la revisión del

producto de trabajo antes de llevar a cabo la revisión entre
pares.
Verificación 549
SP 2.2 r Ealizar las rEVisionEs EnTrE parEs
Realizar las revisiones entre pares de los productos de trabajo seleccionados e
identificar las cuestiones resultantes de estas revisiones.
Uno de los propósitos de llevar a cabo una revisión entre pares es

encontrar y eliminar defectos en fases tempranas. Las revisiones
entre pares se realizan de forma incremental mientras se
desarrollan los productos de trabajo. Estas revisiones son
estructuradas y no son revisiones de gestión.
Las revisiones entre pares se pueden realizar sobre productos
de trabajo clave de actividades de especificación, diseño, pruebas e
imple- mentación y sobre productos de trabajo específicos de
planificación.
El enfoque de la revisión entre pares debería ser sobre el
producto de trabajo que se revisa, no sobre la persona que lo
realizó.
Cuando surgen cuestiones durante la revisión entre pares, se
debe- rían comunicar al desarrollador principal del producto de
trabajo para su corrección.
PARA más INFORMACIÓN sobre cómo MONITORIZAR el proyecto frente AL PLAN, consúl-
Las revisiones entre pares deberían seguir las siguientes pautas:
de- berían estar suficientemente preparadas, se debería gestionar y
controlar la realización, se deberían registrar datos consistentes y
suficientes (un ejemplo es realizar una inspección formal), y se
deberían registrar los elementos de acción.

1. Resultados de la revisión entre pares.
2. Cuestiones de la revisión entre pares.
3. Datos de la revisión entre pares.
SUBPRÁCTICAS
1. Desempeñar los roles asignados en la revisión entre pares.
2. Identificar y documentar defectos y otras cuestiones sobre el
producto de trabajo.
VER
3. Registrar los resultados de la revisión entre pares, incluyendo
los elementos de acción.
4. Recoger los datos de la revisión entre pares.
5. Identificar elementos de acción y comunicar las cuestiones a
6. Realizar una revisión entre pares adicional si es necesario.
7. Asegurar que se satisfacen los criterios de salida de la revisión
entre pares.
SP 2.3 a nalizar los daTos dE las rEVisionEs EnTrE parEs
Analizar los datos sobre la preparación, realización y resultados de las revisio-
nes entre pares.
PARA más INFORMACIÓN sobre cómo obtener DATOS de medición y ANALIZAR los DATOS
de LA medición, consúltese el árEA de proceso Medición y Análisis.

1. Datos de la revisión entre pares.
2. Elementos de acción de la revisión entre pares.
SUBPRÁCTICAS
1. Registrar los datos relativos a la preparación, realización y
resultados de la revisión entre pares.
Los datos típicos son el nombre del producto, el tamaño del
producto, la composición del equipo de la revisión entre pares, el
tipo de revi- sión entre pares, el tiempo de preparación por
revisor, el tiempo de la reunión de revisión, el número de
defectos encontrados, el tipo y origen del defecto, etc. Se puede
recoger información adicional sobre el producto de trabajo que se
está revisando, tal como el tamaño, la etapa de desarrollo, los
modos de operación examinados, y los requisitos que se están
evaluando.
2. Almacenar los datos para futuras consultas y análisis.
3. Proteger los datos para asegurar que los datos de la revisión
entre pares no se utilizan de forma inapropiada.
algunos ejemplos de uso inapropiado de los datos de revisión entre pares

son utilizar los datos para evaluar el desempeño de las personas y utilizar
datos para atribución.
4. Analizar los datos de la revisión entre pares.
algunos ejemplos de datos de revisión entre pares que pueden ser

analizados son:
 Fase en la que se inyectó el defecto.
 tiempo o tasa de preparación frente al tiempo o tasa esperado.
 número de defectos frente al número esperado.
 tipos de defectos detectados.
 Causas de los defectos.
 Impacto de la resolución de los defectos.
 Historias de usuario o casos de estudio asociados con un defecto.
 Los usuarios finales y clientes que están asociados con los defectos.
Verificación 551
SG3 v erificar loS ProDuctoS De trabajo SeleccionaDoS
Los productos de trabajo seleccionados se verifican frente a los requisitos
especificados.
Los métodos, procedimientos y criterios de verificación se

utilizan para verificar los productos de trabajo seleccionados y
los servicios asociados de mantenimiento, de formación y de
soporte utilizando el entorno de verificación adecuado. Se
deberían realizar las actividades de verificación durante todo el
ciclo de vida del producto. Las prácti- cas relacionadas con las
revisiones entre pares se incluyen en la meta específica 2 como
un método de verificación específico.
SG3.1 r Ealizar la VErificación
Realizar la verificación sobre los productos de trabajo seleccionados.
Verificar los productos y productos de trabajo incrementalmente

promueve la detección temprana de problemas y puede dar como
resultado la eliminación temprana de defectos. Los resultados de
la verificación ahorran un coste considerable de aislamiento de
fallos y re-trabajo asociados con la resolución de problemas.

1. Resultados de la verificación.
2. Informes de la verificación.
3. Demostraciones.
4. Registro de ejecución de los procedimientos.
SUBPRÁCTICAS
1. Realizar la verificación de los productos de trabajo
seleccionados frente a los requisitos.
2. Registrar los resultados de las actividades de verificación.
3. Identificar los elementos de acción resultantes de la
verificación de los productos de trabajo.
4. Documentar el método de verificación “tal y como se ejecuta” y
VER
las desviaciones de los métodos y los procedimientos disponibles
descubiertos durante su realización.
SG 3.2 a nalizar los rEsulTados dE la VErificación
Analizar los resultados de todas las actividades de verificación.
Se deberían comparar los resultados reales con los criterios de

verifica- ción establecidos para determinar su aceptación.
Los resultados del análisis se registran como evidencia de que
se ha llevado a cabo la verificación.
Para cada producto de trabajo, se analizan incrementalmente
todos los resultados de verificación disponibles para asegurar que
se han cumplido los requisitos. Dado que una revisión entre pares
es uno de los métodos de verificación, los datos de la revisión
entre pares se deberían incluir en esta actividad de análisis para
asegurar que se analizan adecuadamente los resultados de la
verificación.
Los informes de análisis o la documentación de los métodos
de “como se ejecuta” pueden también indicar que los resultados de
una mala verificación se deben a problemas del método,
problemas de los criterios, o a problemas del entorno de
verificación.
1. Informe de análisis (p. ej., estadísticas de rendimiento, análisis
causal de no conformidades, comparación del
comportamiento entre el producto real y los modelos,
tendencias).
2. Informes de problemas.
3. Peticiones de cambio de los métodos, de los criterios y del
entorno de verificación.
SUBPRÁCTICAS
1. Comparar los resultados reales con los resultados esperados.
2. En base a los criterios de verificación establecidos, identificar
productos que no han cumplido sus requisitos o identificar
problemas con los métodos, los procedimientos, los criterios y
el entorno de verificación.
3. Analizar los datos de defectos.
4. Registrar todos los resultados del análisis en un informe.
5. Utilizar los resultados de la verificación para comparar
mediciones y rendimiento reales con parámetros de
rendimiento técnico.
6. Proporcionar información sobre cómo se pueden resolver los
defectos (incluyendo los métodos, los criterios y el entorno
de verifica- ción) e iniciar acciones correctivas.
PARA más INFORMACIÓN sobre cómo TOMAR ACCIONES corrECTIVAS, consúltese
el árEA de proceso MONITORIZACIÓN y Control del Proyecto.
Verificación 553
tercera Parte
apéndices
aPéndice a
referencias
Ahern 2005 Ahern, Dennis M.; Armstrong, Jim; Clouse, Aaron;

Ferguson, Jack R.; Hayes, Will; & Nidiffer, Kenneth E. CMMI
SCAMPI Distilled: ApprAisAls for Process Improvement. Boston,
MA: Addison-Wesley, 2005.
Ahern 2008 Ahern, Dennis M.; Clouse, Aaron; & Turner, Richard.
CMMI Distilled: A PrActiCAl Introduction to IntegrAted Process
Improvement, Third Edition. Boston: Addison-Wesley, 2008.
Beck 2001 Beck, Kent et. al. Manifesto for Agile
Software Development. 2001.
http://agilemanifesto.org/.
Chrissis 2011 Chrissis, Mary Beth; Konrad, Mike; & Shrum,
Sandy. CMMI: Guidelines for Process IntegrAtion And Product
Improvement, Third Edition. Boston: Addison-Wesley, 2011.
Crosby 1979 Crosby, Philip B. QuAlity Is Free: The Art of
MAking QuAlity CertAin. New York: McGraw-Hill, 1979.
Curtis 2009 Curtis, Bill; Hefley, William E.; & Miller, Sally
A. The People CMM: A FrAmework for HumAn CApitAl
MAnAgement, SecondSecond Edition. Boston.: Addison-Wesley,
2009.
Deming 1986 Deming, W. Edwards. Out of the Crisis.
Cambridge, MA: MIT Center for Advanced Engineering, 1986.
DoD 1996 Department of Defense. DoD Guide to IntegrAted
Product And Process Development (Version 1.0). Washington, DC:
Office
of the Under Secretary of Defense (Acquisition and
Technology), February 5, 1996.
https://www.acquisition.gov/sevensteps/library/dod-guide-to-
integrated.pdf.
555
556 segunda parte apéndices
Dymond 2005 Dymond, Kenneth M. A Guide to the CMMI:
Interpreting the CApAbility MAturity Model IntegrAtion, Second
Edition. Annapolis, MD: Process Transition International
Inc., 2005.
EIA 2002a Electronic Industries Alliance. Systems
Engineering CApAbility Model (EIA/IS-731.1). Washington,
DC, 2002.
EIA 2002b Government Electronics and Information
Technology Alliance. EArned VAlue MAnAgement Systems
(ANSI/EIA-748). New York, NY, 2002.
http://webstore.ansi.org/RecordDet
ail. aspx?sku=ANSI%2FEIA-748-
B.
EIA 2003 Electronic Industries Alliance. EIA Interim
StAndArd: Systems Engineering (EIA/IS-632). Washington,
DC, 2003.
Forrester 2011 Forrester, Eileen; Buteau, Brandon; & Shrum,
Sandy. CMMI for Services: Guidelines for Superior Service,
Second Edition. Boston: Addison-Wesley, 2011.
Gallagher 2011 Gallagher, Brian; Phillips, Mike; Richter, Karen;
& Shrum, Sandy. CMMI-ACQ: Guidelines for Improving the
Acquisition of Products And Services, Second Edition. Boston:
Addison-Wesley, 2011.
GEIA 2004 Government Electronic Industries Alliance.
DAtA MAnAgement (GEIA-859). Washington, DC, 2004.
http://webstore.ansi.org/RecordDetail.
aspx?sku=ANSI%2FGEIA+859-2009.
Gibson 2006 Gibson, Diane L.; Goldenson, Dennis R. & Kost,
Keith. PerformAnce Results of CMMI-BASed Process Improvement.
(CMU/SEI-2006-TR-004, ESC-TR-2006-004). Pittsburgh.:
Software
Engineering Institute, Carnegie Mellon® University, August 2006.
http://www.sei.cmu.edu/library/abstracts/reports/06tr004.cfm.
Glazer 2008 Glazer, Hillel; Dalton, Jeff; Anderson, David;
Konrad, Mike; & Shrum, Sandy. CMMI or Agile: Why Not
EmbrAce Both! (CMU/SEI-2008-TN-003). Pittsburgh: Software
Engineering Institute, Carnegie Mellon University, November
2008.
http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cf
m.
Humphrey 1989 Humphrey, Watts S. MAnAging the SoftwAre Process.
Reading, MA: Addison-Wesley, 1989.
IEEE 1991 Institute of Electrical and Electronics Engineers.
IEEE StAndArd Computer DictionAry: A CompilAtion of IEEE
StAndArd Computer GlossAries. New York: IEEE, 1991.
Apéndice A Referencias 557
ISO 2005a International Organization for Standardization.
ISO 9000: InternAtionAl StAndArd. 2005.
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalog
ue_ detail.htm?csnumber=42180.
ISO 2005b International Organization for Standardization and
International Electrotechnical Commission. ISO/IEC 20000-1
InformAtion Technology – Service MAnAgement, PArt 1: SpecifiCAtion;
ISO/IEC 20000-2 InformAtion Technology – Service MAnAgement,
PArt 2: Code of PrActice, 2005.
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_t
c_ browse.htm?commid=45086.
ISO 2006a International Organization for Standardization and
International Electrotechnical Commission. ISO/IEC 15504
InformAtion Technology—Process Assessment PArt 1: Concepts And
VoCAbulAry, PArt 2: Performing An Assessment, PArt 3: GuidAnce
on Performing An Assessment, PArt 4: Guid Ance on Use for Process
Improvement And Process CApAbility DeterminAtion, PArt 5: An
ExemplAr Process Assessment Model, 2003-2006.
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc_
browse.htm?commid=45086.
ISO 2006b International Organization for Standardization and
SoftwAre Engineering – SoftwAre Life Cycle Processes – MAintenAnce,
2006.
ISO 2007 International Organization for Standardization and
Systems And SoftwAre Engineering—MeASurement Process, 2007.
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue
_tc_ browse.htm?commid=45086.
ISO 2008a International Organization for Standardization
and International Electrotechnical Commission. ISO/IEC
12207 Systems And SoftwAre Engineering—SoftwAre Life Cycle
Processes, 2008.
ISO 2008b International Organization for Standardization
15288 Systems And SoftwAre Engineering—System Life Cycle
Processes, 2008.
ISO 2008c International Organization for Standardization. ISO
9001, QuAlity MAnAgement Systems—Requirements, 2008.
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue
_tc_ browse.htm?commid=53896.
IT Governance 2005 IT Governance Institute. CobiT 4.0.
Rolling Meadows, IL: IT Governance Institute, 2005.
http://www.isaca.org/Content/NavigationMenu/Members_and
_ Leaders/COBIT6/Obtain_COBIT/Obtain_COBIT.htm.
Juran 1988 Juran, Joseph M. JurAn on PlAnning for QuAlity.
New York: Macmillan, 1988.
McFeeley 1996 McFeeley, Robert. IDEAL: A User’s Guide for
SoftwAre Process Improvement (CMU/SEI-96-HB-001,
ADA305472). Pittsburgh: Software Engineering Institute,
Carnegie Mellon University, February 1996.
http://www.sei.cmu.edu/library/abstracts/reports/96hb001.cfm
.
McGarry 2001 McGarry, John; Card, David; Jones, Cheryl;
Layman, Beth; Clark, Elizabeth; Dean, Joseph; & Hall, Fred.
PrActiCAl SoftwAre MeASurement: Objective InformAtion for Decision
MAkers. Boston: Addison-Wesley, 2001.
Office of Government Commerce 2007a Office of Government
Commerce. ITIL: ContinuAl Service Improvement. London: Office
of Government Commerce, 2007.
Office of Government Commerce 2007b Office of Government
Commerce. ITIL: Service Design. London: Office of
Government Commerce, 2007.
Office of Government Commerce 2007c Office of Government
Commerce. ITIL: Service OperAtion. London: Office of
Office of Government Commerce 2007d Office of Government
Commerce. ITIL: Service StrAtegy. London: Office of
Office of Government Commerce 2007e Office of Government
Commerce. ITIL: Service TrAnsition. London: Office of
SEI 1995 Software Engineering Institute. The CApAbility MAturity
Model: Guidelines for Improving the SoftwAre Process. Reading,
MA: Addison-Wesley, 1995.
Apéndice A Referencias 559
SEI 2002 Software Engineering Institute. SoftwAre Acquisition
CApAbility MAturity Model (SA-CMM) Version 1.03 (CMU/SEI-
2002- TR-010, ESC-TR-2002-010). Pittsburgh: Software
Engineering Institute, Carnegie Mellon University, March
2002. http://www.sei.cmu.edu/publications/documents/02.
reports/02tr010.html.
SEI 2006 CMMI Product Team. CMMI for Development, Version
1.2 (CMU/SEI-2006-TR-008, ADA455858). Pittsburgh:
Software Engineering Institute, Carnegie Mellon University,
August 2006.
http://www.sei.cmu.edu/library/abstracts/reports/06tr008.cfm
.
SEI 2010a CMMI Product Team. CMMI for Services, Version
1.3 (CMU/SEI-2010-TR-034). Pittsburgh: Software
Engineering Institute, Carnegie Mellon University,
November 2010.
http://www.sei.cmu.edu/library/abstracts/reports/10tr034.cfm
.
SEI 2010b CMMI Product Team. CMMI for Acquisition, Version
November 2010.
http://www.sei.cmu.edu/library/abstracts/reports/10tr032.c
fm.
SEI 2010c CMMI Product Team. CMMI for Development, Version
November 2010.
fm.
SEI 2010d Caralli, Richard; Allen, Julia; Curtis, Pamela;
White, David; and Young, Lisa. CERT® Resilience
MAnAgement Model, Version 1.0 (CMU/SEI-2010-TR-012).
Pittsburgh: Software Engineering Institute, Carnegie
Mellon University, May 2010.
fm.
SEI 2011a SCAMPI Upgrade Team. Standard CMMI
Appraisal Method for Process Improvement (SCAMPI)
A, Version 1.3: Method Definition Document (CMU/SEI-
2011-HB-001).
Pittsburgh: Software Engineering Institute, Carnegie Mellon
University, expected January 2011.
http://www.sei.cmu.edu/library/abstracts/reports/11hb001.cfm.
SEI 2011b SCAMPI Upgrade Team. Appraisal
Requirements for CMMI, Version 1.2 (ARC, V1.3)
(CMU/SEI-2011-TR-001).
Pittsburgh: Software Engineering Institute, Carnegie Mellon
University, expected January 2011.
http://www.sei.cmu.edu/library/abstracts/reports/11tr0101.cfm.
Shewhart 1931 Shewhart, Walter A. Economic Control of QuAlity
of MAnufActured Product. New York: Van Nostrand, 1931.
aseguramiento de la información/fuentes relacionadas con

la seguridad de la información
DHS 2009 Department of Homeland Security. AssurAnce Focus
for CMMI (SummAry of AssurAnce for CMMI Efforts), 2009.
https://buildsecurityin.us-cert.gov/swa/proself_assm.html.
DoD and DHS 2008 Department of Defense and Department
of Homeland Security. SoftwAre AssurAnce in Acquisition:
MitigAting Risks to the Enterprise, 2008.
https://buildsecurityin.us-cert.gov/swa/downloads/SwA_in_
Acquisition_102208.pdf.
ISO/IEC 2005 International Organization for Standardization
27001
InformAtion Technology – Security Techniques – InformAtion Security
MAnAgement Systems – Requirements, 2005.
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_
detail.htm?csnumber= 42103.
NDIA 2008 NDIA System Assurance Committee. Engineering
for System AssurAnce. Arlington, VA: NDIA, 2008.
http://www.ndia.org/Divisions/Divisions/SystemsEngineeri
ng/ Documents/Studies/SA-Guidebook-v1-Oct2008-
REV.pdf.
aPéndice B
acrónimos
ANSI American National Standards Institute (Instituto de

Estándares Nacionales Americano)
API Application Program Interface (Interfaz de programación de
aplicaciones)
ARC Appraisal Requirements for CMMI
CAD Compute-aided design (Diseño asistido por ordenador)
CAR Causal Analysis and Resolution (Análisis Causal y
Resolución, área de proceso)
CCB Configuration Control Board (Comité de control de
configuración)
CL Capability Level (Nivel de capacidad)
CM Configuration Management (Gestión de Configuración, área
de proceso)
CMU Carnegie Mellon University
CMF CMMI Model Foundation
CMM Capability Maturity Model (Modelo de madurez y de capacidad)
CMMI Capability Maturity Model Integration (Modelo de
madurez y de capacidad Integrado)
CMMI-ACQ CMMI for Adquisition (CMMI para
Adquisición) CMMI-DEV CMMI for Development (CMMI
para Desarrollo) CMMI-SVC CMMI for Services (CMMI
para Servicios)
CobiT Control Objectives for Information and related
Technology (Objetivos de control para la información y
tecnologías relacionadas)
COTS Comercial off-the-shelf (Producto comercial )
CPI Cost Performance Index (Índice de rendimiento de coste, IRC)
CPM Critical Path Method (Método del camino crítico)
CSCI Comuter Software Configuration Item (Elemento de
configu- ración de software)
DAR Decision Analysis and Resolution (Análisis de decisiones
y re- solución, área de proceso)
DHS Department of Homeland Security
DoD Deparment of Defense
EIA Electronic Industries Alliance
EIA/IS Electronic Industries Alliance/Interim Standard
561
FCA Functional Configuration Audit (Auditoría de configuración
funcional)
FMEA Failure Model and Effects Analysis (Análisis modal de fallos
y efectos, AMFE)
GG Generic Goal (Meta genérica)
GP Generic Practice (Práctica genérica)
IBM International Business Machines
IDEAL Initiating, Diagnosing, Establishing, Acting,
Learning IEEE Institute of Electrical and Electronics
Engineers INCOSE International Council on
Systems Engineering
IPD-CMM Integrated Product Development Capability Maturity
Mo- del (Modelo de madurez y de capacidad de desarrollo
integrado de producto)
IPM Integrated Project Management (Gestión Integrada del
Proyec- to, área de proceso)
ISO International Organization for Standardization
ISO/IEC International Organization for Standardization and
Interna- tional Electrotechnical Commission
ITIL Information Technology Infrastructure Library
MA Measurement and Analysis (Medición y Análisis, área de proceso)
MDD Method Definition Document
ML Maturity Level (Nivel de madurez)
NDIA National Defense Industrial Association
OID Organizational Innovation and Deployment (Innovación y
Des- pliegue en la Organización (área de proceso antigua)
OPD Organizational Process Definition (Definición de Procesos
de la Organización, área de proceso)
OPF Organizational Process Focus (Enfoque en Procesos de la
Orga- nización, área de proceso)
OPM Organizational Performance Management (Gestión del
Rendi- miento de la Organización, área de proceso)
OPP Organizational Process Performance (Rendimiento de
Procesos de la Organización, área de proceso)
OT Organizational Training (Formación en la Organización,
área de proceso)
P-CMM People Capability Maturity Model
PCA Physical Configuration Audit (Auditoría de configuración
física)
PERT Program Evaluation and Review Technique (Técnica de
Eva- luación y Revisión de Programas)
PI Product Integration (Integración del Producto,área de proceso)
PMC Process Monitoring and Control (Monitorización y Control
del Proyecto, área de proceso)
PP Project Planning (Planificación del proyecto, área de proceso)
PPQA Process and Product Quality Assurance (Aseguramiento
de la Calidad del Proceso y del Producto, área de proceso)
Apéndice B Acrónimos 563
QFD Quality Function Deployment (Despliegue de la Función

de Calidad)
QPM Quantitative Project Management (Gestión Cuantitativa
del Proyecto, área de proceso)
RD Requirements Development (Desarrollo de Requisitos, área
de proceso)
REQM Requirements Management (Gestión de Requisitos, área
de proceso)
RSKM Risk Management (Gestión de Riesgos, área de proceso)
SA-CMM Software Adquisition Capability Maturity Model
(Modelo de madurez y de capacidad para adquisición de
software)
SAM Supplier Agreement Management (Gestión de Acuerdos
con Proveedores, área de proceso)
SCAMPI Standard CMMI Appraisal Method for Process
Improve- ment (Método de evaluación estándar de CMMI para
la mejora de procesos)
SECAM Systems Engineering Capability Assestment Model
(Modelo de evaluación de la capacidad de ingeniería de
sistemas)
SECM Systems Engineering Capability Model (Modelo de
capacidad de ingeniería de sistemas)
SEI Software Engineering Institute
SG Specific Goal (Meta específica)
SP Specific Practice (Práctica específica)
SPI Schedule Performance Index (Índice de rendimiento de
plazo, IRP)
SSD Service System Development (Desarrollo del Sistema de
Servi- cio, área de proceso de CMMI-SVC)
SSE-CMM Systems Security Engineering Capability Maturity
Model (Modelo de madurez y de capacidad para ingeniería de
seguridad de sistemas)
SW-CMM Capability Maturity Model for Software or Software
Ca- pability Maturity Model (Modelo de madurez y de
capacidad para software)
TS Technical Solution (Solución Técnica, área de proceso)
VAL Validation (Validación, área de proceso)
VER Verification (Verificación área de proceso)
WBS Work Breakdown Structure (Estructura de descomposición
del trabajo).
aPéndice c
ParticiPantes en el Proyecto cmmi

Versión 1.3
Muchas personas con talento han formado parte del equipo de

producto que ha desarrollado los modelos de la versión 1.3 de
CMMI. Se enumeran a continuación aquellos que participaron en
uno o más de los siguientes equipos durante el desarrollo de la
versión 1.3 de CMMI. Las organizaciones que se indican al lado
del nombre de cada uno de los miembros son aquellas a las que
dichos miembros repre- sentaban en el momento en el que
formaban parte del equipo. Los siguientes son los grupos
principales involucrados en el desarrollo de este modelo:
• Comité de Dirección de CMMI.

• Grupo Asesor de CMMI para Servicios.
• Equipo de Coordinación de CMMI V1.3.
• Comité de Control de Configuración de CMMI V1.3.
• Equipo Base del Modelo CMMI V1.3.
• Equipo de Traducción de CMMI V1.3.
• Equipo de Alta Madurez de CMMI V1.3.
• Mini Equipo de Adquisición de CMMI V1.3.
• Mini Equipo de Servicios de CMMI V1.3.
• Equipo de Actualización de SCAMPI de CMMI V1.3.
• Equipos de Formación de CMMI V1.3.
• Equipo de Calidad de CMMI V1.3.
comité de dirección de cmmi

El Comité de Dirección de CMMI guía y aprueba los planes del
Equipo de Producto de CMMI, asesora sobre cuestiones
importantes del proyecto CMMI, asegura la involucración de
las diferentes comunidades interesadas y aprueba la versión final
del modelo.
565
miembros del comité de dirección

Alan Bemish, US Air Force.
Anita Carleton, Software Engineering Institute.
Clyde Chittister, Software Engineering
Institute. James Gill, Boeing Integrated
Defense Systems. John C. Kelly, NASA.
Kathryn Lundeen, Defense Contract Management
Agency. Larry McCarthy, Motorola.
Lawrence Osiecki, US Army.
Robert Rassa, Raytheon Space and Airborne Systems
(responsable). Karen Richter, Institute for Defense Analyses.
Joan Weszka, Lockheed Martin Corporation.
Harold Wilson, Northrop Grumman
Corporation. Brenda Zettervall, US Navy.
miembros del comité de dirección ex officio

Mike Konrad, Software Engineering
Institute. Susan LaFortune, National
Security Agency.
David (Mike) Phillips, Software Engineering Institute.
soporte del comité de dirección

Mary Beth Chrissis, Software Engineering Institute
(CCB). Eric Hayes, Software Engineering Institute
(secretario).
Rawdon Young, Software Engineering Institute (Appraisal program).
Grupo asesor de cmmi para servicios

El Grupo Asesor para Servicios aconseja al equipo de desarrollo
del producto sobre las industrias de servicios.
Brandon Buteau, Northrop Grumman Corporation.
Christian Carmody, University of Pittsburgh Medical
Center.
Sandra Cepeda, Cepeda Systems & Software Analysis/RDECOM SED.
Annie Combelles, DNV IT Global Services.
Jeff Dutton, Jacobs Technology, Inc.
Eileen Forrester, Software Engineering Institute.
Craig Hollenbach, Northrop Grumman Corporation
(responsable). Bradley Nelson, Department of Defense.
Lawrence Osiecki, US Army ARDEC.
Apéndice C CMMI versión 1.3. participantes en el proyecto 567
David (Mike) Phillips, Software Engineering
Institute. Timothy Salerno, Lockheed Martin
Corporation.
Sandy Shrum, Software Engineering
Institute. Nidhi Srivastava, Tata
Consultancy Services. Elizabeth Sumpter,
NSA.
David Swidorsky, Bank of America.
equipo de coordinación de cmmi V1.3

El equipo de coordinación reúne a los miembros de otros equipos
de desarrollo del producto para asegurar la coordinación del
proyecto.
Rhonda Brown, Software Engineering Institute.
Mary Beth Chrissis, Software Engineering
Institute. Eileen Forrester, Software Engineering
Institute.
Will Hayes, Software Engineering
Institute. Mike Konrad, Software
Engineering Institute.
So Norimatsu, Norimatsu Process Engineering Lab,
Inc. Mary Lynn Penn, Lockheed Martin Corporation.
David (Mike) Phillips, Software Engineering Institute
(responsable). Mary Lynn Russo, Software Engineering Institute
(miembro sin voto). Sandy Shrum, Software Engineering Institute.
Kathy Smith, Hewlett Packard.
Barbara Tyson, Software Engineering
Institute. Rawdon Young, Software
comité de control de configuración de cmmi V1.3

El Comité de Control de Configuración aprueba todos los
cambios de los materiales de CMMI, incluyendo los modelos, el
MDD SCAMPI y la formación en la introducción al modelo.
Rhonda Brown, Software Engineering Institute (miembro sin
voto). Michael Campo, Raytheon.
Mary Beth Chrissis, Software Engineering Institute (presidenta).
Kirsten Dauplaise, NAVAIR.
Mike Evanoo, Systems and Software Consortium,
Inc. Rich Frost, General Motors.
Brian Gallagher, Northrop Grumman
Corporation. Sally Godfrey, NASA.
Stephen Gristock, JP Morgan Chase and Co.
Eric Hayes, Software Engineering Institute (miembro sin
voto). Nils Jacobsen, Motorola.
Steve Kapurch, NASA.
Institute. Chris Moore, US Air Force.
Wendell Mullison, General Dynamics Land
Systems. David (Mike) Phillips, Software
Engineering Institute. Robert Rassa, Raytheon
Space and Airborne Systems. Karen Richter,
Institute for Defense Analyses.
Mary Lou Russo, Software Engineering Institute (miembro sin
voto). Warren Schwomeyer, Lockheed Martin Corporation.
John Scibilia, US Army.
Dave Swidorsky, Bank of America.
Barbara Tyson, Software Engineering Institute.
Mary Van Tyne, Software Engineering Institute (miembro sin
voto). Rawdon Young, Software Engineering Institute.
equipo Base del modelo cmmi V1.3

El Equipo Base del Modelo desarrolla el material del modelo para
las tres constelaciones.
Jim Armstrong, Stevens Institute of Technology.
Rhonda Brown, Software Engineering Institute (co-
responsable). Brandon Buteau, Northrop Grumman
Corporation.
Michael Campo, Raytheon.
Sandra Cepeda, Cepeda Systems & Software Analysis/RDECOM
SED. Mary Beth Chrissis, Software Engineering Institute.
Mike D’Ambrosa, Process Performance
Professionals. Eileen Forrester, Software
Will Hayes, Software Engineering Institute.
Mike Konrad, Software Engineering Institute (co-
responsable). So Norimatsu, Norimatsu Process
Engineering Lab, Inc.
Mary Lynn Penn, Lockheed Martin Corporation.
David (Mike) Phillips, Software Engineering
Institute.
Karen Richter, Institute for Defense Analyses.
Mary Lynn Russo, Software Engineering Institute (miembro sin
voto). John Scibilia, US Army.
Sandy Shrum, Software Engineering Institute (co-responsable).
Katie Smith-McGarty, US Navy.
equipo de traducción de cmmi V1.3

El Equipo de Traducción coordina el trabajo de traducción de los
materiales de CMMI.
Richard Basque, Alcyonix.
Jose Antonio Calvo-Manzano, Universidad Politécnica de
Madrid. Carlos Caram, Integrated Systems Diagnostics Brazil.
Gonzalo Cuevas, Universidad Politécnica de
Madrid. Mike Konrad, Software Engineering
Institute.
Antoine Nardeze, Alcyonix.
So Norimatsu, Norimatsu Process Engineering Lab, Inc.
(responsable). Steven Ou, Institute for Information Industry.
Ricardo Panero Lamothe, Accenture.
Mary Lynn Russo, Software Engineering Institute (miembro sin
voto). Winfried Russwurm, Siemens AG.
Tomás San Feliu, Universidad Politécnica de Madrid.
equipo de alta madurez de cmmi V1.3

El Equipo de Alta Madurez desarrolla el material de alta madurez
del modelo.
Dan Bennett, US Air Force.
Will Hayes, Software Engineering Institute.
Rick Hefner, Northrop Grumman
Corporation. Jim Kubeck, Lockheed Martin
Corporation.
Alice Parry, Raytheon.
Mary Lynn Penn, Lockheed Martin Corporation (responsable).
Rawdon Young, Software Engineering Institute.
mini equipo de adquisición de cmmi V1.3

El Mini Equipo de Adquisición proporciona conocimientos en
adqui- sición para el trabajo de desarrollo del modelo.
Rich Frost, General Motors.
Tom Keuten, Keuten and Associates.
David (Mike) Phillips, Software Engineering Institute (responsable).
Karen Richter, Institute for Defense Analyses.
John Scibilia, US Army.
mini equipo de servicios de cmmi V1.3

El Mini Equipo de Servicios proporciona conocimientos para el
trabajo de desarrollo del modelo.
Drew Allison, Systems and Software Consortium,
Inc. Brandon Buteau, Northrop Grumman
Corporation.
Eileen Forrester, Software Engineering Institute (responsable).
Christian Hertneck, Anywhere.24 GmbH.
Pam Schoppert, Science Applications International Corporation.
equipo de actualización de scamPi de cmmi V1.3

El equipo de Actualización de SCAMPI desarrolla los
documentos Appraisal Requirements for CMMI (ARC) y
SCAMPI Method Defini- tion Document (MDD).
Mary Busby, Lockheed Martin Corporation.
Palma Buttles-Valdez, Software Engineering
Institute. Paul Byrnes, Integrated System
Diagnostics.
Will Hayes, Software Engineering Institute
(responsable). Ravi Khetan, Northrop Grumman
Corporation.
Denise Kirkham, The Boeing
Company. Lisa Ming, BAE Systems.
Charlie Ryan, Software Engineering
Institute. Kevin Schaaff, Software
Engineering Institute. Alexander Stall,
Software Engineering Institute. Agapi
Svolou, Software Engineering Institute. Ron
Ulrich, Northrop Grumman Corporation.
equipos de formación de cmmi Versión 1.3

Los dos equipos de formación (uno para CMMI-DEV y CMMI-
ACQ y el otro para CMMI-SVC) desarrollaron los materiales de
formación del modelo.
equipo de formación de acQ y deV

Barbara Baldwin, Software Engineering
Institute. Bonnie Bollinger, Process Focus
Management.
Cat Brandt-Zaccardi, Software Engineering
Institute. Rhonda Brown, Software Engineering
Institute.
Michael Campo, Raytheon.
Mary Beth Chrissis, Software Engineering Institute
(responsable). Stacey Cope, Software Engineering Institute.
Erik Dorsett, Jeppesen.
Dan Foster, PF
Williamson.
Eric Hayes, Software Engineering Institute.
Kurt Hess, Software Engineering Institute.
Institute. Steve Masters, Software
Robert McFeeley, Software Engineering Institute.
Diane Mizukami-Williams, Northrop Grumman
Corporation. Daniel Pipitone, Software Engineering
Institute.
Mary Lou Russo, Software Engineering Institute (miembro sin
voto). Sandy Shrum, Software Engineering Institute.
Katie Smith-McGarty, US Navy.
Barbara Tyson, Software Engineering Institute.
equipo de formación de sVc

Drew Allison, Systems and Software Consortium,
Inc. Mike Bridges, University of Pittsburgh Medical
Center. Paul Byrnes, Integrated System Diagnostics.
Sandra Cepeda, Cepeda Systems & Software Analysis/RDECOM SED.
Eileen Clark, Tidewaters Consulting.
Kieran Doyle, Excellence in Measurement.
Eileen Forrester, Software Engineering Institute (responsable de
forma- ción SVC).
Hillel Glazer, Entinex.
Christian Hertneck, Anywhere.24 GmbH.
Pat Kirwan, Software Engineering
Institute.
Suzanne Miller, Software Engineering
Institute. Judah Mogilensky, PEP.
Heather Oppenheimer, Oppenheimer
Partners. Pat O’Toole, PACT.
Agapi Svolou, Alexanna.
Jeff Welch, Software Engineering Institute.
equipo de calidad de cmmi V1.3

El equipo de Calidad lleva a cabo diversas comprobaciones de
aseguramiento de la calidad sobre el material del modelo para
asegurar su precisión, legibilidad y consistencia.
Rhonda Brown, Software Engineering Institute (co-
responsable). Erin Harper, Software Engineering Institute.
Mike Konrad, Software Engineering Institute.
Mary Lou Russo, Software Engineering
Institute. Mary Lynn Russo, Software
Sandy Shrum, Software Engineering Institute (co-responsable).
aPéndice d
Glosario
El glosario define los términos utilizados en los modelos CMMI.

Las entregas de glosarios son normalmente términos de varias
palabras consistentes en un nombre y uno o más modificadores
restrictivos (existen algunas excepciones a esta regla que
justifican los términos de una palabra en el glosario).
El glosario de términos de CMMI no es un componente
requerido, esperado o informativo de los modelos CMMI.
Interprete los térmi- nos del glosario en el contexto del
componente del modelo en que aparecen.
Para formular las definiciones apropiadas para CMMI, se han
consultado múltiples fuentes. Se ha consultado primero el
diccionario Me- rRIAM-Webster Online dictionary
(http://www.merriam-webster.com/). También se han consultado
otros estándares, cuando fue necesario, incluyendo los
siguientes:
• ISO 9000 [ISO 2005a].

• ISO/IEC 12207 [ISO 2008a].
• ISO/IEC 15504 [ISO 2006a].
• ISO/IEC 15288 [ISO 2008b].
• ISO/IEC 15939 [ISO 2007].
• ISO 20000-1 [ISO 2005b].
• IEEE [IEEE 1991].
• CMM for Software (SW-CMM) v1.1.
• EIA 632 [EIA 2003].
• SA-CMM [SEI 2002].
• People CMM (P-CMM) [Curtis 2009].
• CobiT v. 4.0 [IT Governance 2005].
• ITIL v3 (Service Improvement, Service Design, Service
Operation, Service Strategy, and Service Transition) [Office
of Government Commerce 2007].
573
Se ha desarrollado el glosario reconociendo la importancia de
usar terminología que todos los usuarios del modelo puedan
comprender. También se ha admitido que las palabras y los
términos pueden tener distintos significados en distintos
contextos y entornos. El glosario de los modelos CMMI está
diseñado para documentar los significados de las palabras y
términos que deberían tener el más amplio uso y com- prensión
por parte de los usuarios de los productos CMMI.
Aun cuando el término “producto” incluye tanto servicios
como productos y el término “servicio” está definido como un tipo
de producto, muchos de los términos del glosario contienen
ambas palabras “producto” y “servicio” para enfatizar que CMMI lo
aplica tanto a productos como a servicios.
Cada entrada del glosario tiene de dos a tres componentes.
Siem- pre hay un término y una definición. A veces se
proporcionan notas adicionales.
El término definido aparece en la parte izquierda de la página.
En primer lugar, aparece la definición en un tamaño similar al
término listado. A continuación de la definición, aparecen las
notas del glosario en un tamaño menor.
Acción correctiva (corrective action) Actos o hechos empleados

para remediar una situación o eliminar un error.
Activo de proceso (process asset) Cualquier cosa que la
organiza- ción considere útil para alcanzar las metas de un área de
proceso (véase también “activos de proceso de la organización”).
Activos de proceso de la organización (organizational process as-
sets) Artefactos relativos a la descripción, implementación y me-
jora de procesos.
Algunos ejemplos de estos ARTEFACTOS son LAS POLÍTICAS, LAS descripciones de LAS
mediciones, LAS descripciones de los procesos y LAS herRAMIENTAS de soporte
PARA LA IMPLEMENTACIÓN de los procesos.
El término “ACTIVOS de proceso” se UTILIZA PARA INDICAR que estos ARTEFACTOS se
DESARrOLLAN o ADQUIERen PARA SATISFACER los objetivos de negocio de LA ORGANI-
ZACIÓN y reprESENTAN inversiones de LA ORGANIZACIÓN que se ESPERA proporcio-
nen VALOR AL negocio ACTUAL y futuro (VÉASE TAMBIÉN “BIBLIOTECA de ACTIVOS de
proceso”).
Acuerdo con el proveedor (supplier agreement) Un acuerdo
documentado entre el comprador y el proveedor (véase también
“proveedor”).
Los ACUERdos con el proveedor se conocen TAMBIÉN como CONTRATOS, LICENCIAS y
MEMORANDOS de ACUERdo.
Acuerdo de nivel de servicio (service level agreement) Un acuerdo
de servicio que especifica servicios entregados; medidas de
servicio; niveles de servicios aceptables y no aceptables; y
responsabilidades, compromisos y acciones esperadas tanto
del proveedor como del
Apéndice D Glosario 575
cliente en situaciones previstas (véase también “medida”, “servicio” y
“acuerdo de servicio”).
Un ACUERdo de nivel de servicio es UNA CLASE de ACUERdo de servicio que docu-
MENTA los DETALLES INDICADOS en LA definición.
El uso del término “ACUERdo de servicio” siempre incluye “ACUERdo de nivel de
servicio” como UNA SUBCATEGORÍA y puede UTILIZARSE LA PRIMERA ACEPCIÓN en
LUGAR de LA SEGUNDA por brEVEDAD. Sin EMBARgo, “ACUERdo de nivel de servicio”
es el término preferido CUANDO se DESEA DAR ÉNFASIS A SITUACIONES en LAS que
existen distintos niveles de servicios ACEPTABLES, u otros DETALLES de un ACUERdo
de nivel de servicio PUDIERAN ser IMPORTANTES PARA LA discusión.
Acuerdo de servicio (service agreement) Un registro vinculante
y por escrito de un intercambio prometido de valor entre un
proveedor de servicio y un cliente (véase también “cliente”).
Los ACUERdos de servicio pueden ser COMPLETAMENTE NEGOCIABLES, PARCIALMENTE
NEGOCIABLES o no NEGOCIABLES, y pueden ser rEDACTADOS por el proveedor del
servicio, el cliente o AMBOS, dependiendo de LA SITUACIÓN.
Un “interCAMBIO prometido de VALOR” SIGNIFICA un reconocimiento conjunto y
UNA ACEPTACIÓN de lo que CADA PARTE proporCIONARÁ A LA OTRA PARA SATISFACER
el ACUERdo. NORMALMENTE, el cliente proporCIONA PAGOS A CAMBIO de servicios
entrEGADOS, pero son posibles otros ACUERdos.
Un registro “por escrito” no necesitA estAr contenido en un documento único o en
otro ArtefActo. AlternAtivAmente, puede ser extremAdAmente breve pArA Algunos
tipos de servicios (p.ej., un recibo que identificA un servicio, su precio, su receptor).
Adaptación (tailoring) El acto de hacer, modificar o adaptar
algo para un fin particular.
Por ejemplo, un proyecto o grupo de TRABAJO ESTABLECE su proceso definido ADAP-
tándolo A PARTIR del conjunto de procesos ESTÁNDAR de LA ORGANIZACIÓN PARA
cumplir sus objetivos, LIMITACIONES y entorno. ANÁLOGAMENTE, un proveedor de
servicio ADAPTA los servicios ESTÁNDAR PARA un ACUERdo de servicio PARTICULAR.
Adaptación del proceso (process tailoring) Creación,
modificación o adaptación de una descripción de proceso para
un fin particular.
Por ejemplo, un proyecto o grupo de TRABAJO ADAPTA SU proceso definido A PAR-
tir del conjunto de procesos ESTÁNDAR de LA ORGANIZACIÓN PARA cumplir con los
objetivos, LAS LIMITACIONES y el entorno del proyecto o grupo de TRABAJO (VÉASE
TAMBIÉN “proceso definido”, “conjunto de procesos ESTÁNDAR de LA ORGANIZA-
ción” y “descripción de proceso”).
Adquisición (acquisition) El proceso consistente en obtener
productos o servicios a través de acuerdos con el proveedor
(véase también “acuerdo con el proveedor”).
Alcance de la evaluación (appraisal scope) La definición de los
lími- tes de una evaluación que engloban los límites de la
organización y los límites del modelo CMMI dentro de los cuales
operan los procesos que se van a examinar.
Este término se UTILIZA en los MATERIALES de EVALUACIÓN, TALES como el SCAMPI
MDD.
Análisis causal (causal analysis) El análisis de los resultados
para determinar sus causas.
Análisis de requisitos (requirements analysis) La determinación
de las características funcionales específicas y atributos de
calidad del producto o servicio, basándose en el análisis de las
necesidades, expectativas y limitaciones del cliente; en el
concepto operacional; en los entornos de uso proyectados para
las personas, los productos, los servicios y los procesos; y en las
medidas de eficacia (véase tam- bién “concepto operacional”).
Análisis de riesgos (risk analysis) La evaluación, clasificación y
priorización de los riesgos.
Análisis funcional (functional analysis) Examen de una función
definida con el fin de identificar todas las subfunciones
necesarias para realizarla; identificación de las relaciones
funcionales e interfaces (internas y externas) y captura de
estas relaciones e interfaces en una arquitectura funcional; y
descomposición de los requisitos de mayor nivel y asignación
de estos requisitos a subfunciones de menor nivel (véase
también “arquitectura funcional”).
área de proceso (process area) Un grupo de prácticas
relacionadas en un área que, cuando se implementan de forma
conjunta, satisface un conjunto de metas consideradas
importantes para realizar mejoras en esa área.
Arquitectura (architecture) El conjunto de estructuras
necesarias para obtener un producto. Estas estructuras están
compuestas por los elementos, sus relaciones y las propiedades
de ambos.
En un contexto de servicios, LA ARQUITECTURA NORMALMENTE se APLICA AL SISTEMA
de servicio.
Observe que LA FUNCIONALIDAD es sólo un ASPECTO del producto. Es TAMBIÉN im-
PORTANTE tener en CUENTA los ATRIBUTOS de CALIDAD, TALES como CAPACIDAD de
rESPUESTA, FIABILIDAD y SEGURIDAD. LAS ESTRUCTURAS proporCIONAN los medios
PARA DESTACAR diferentes PARTES de LA ARQUITECTURA (VÉASE TAMBIÉN “ARquitectu-
RA FUNCIONAL”).
Arquitectura del proceso (process architecture) (1) La
secuencia, las interfaces, las interdependencias y otras
relaciones entre los elementos de proceso de un proceso
estándar o (2) las interfaces, las interdependencias y otras
relaciones entre los elementos de proceso y los procesos
externos.
Arquitectura funcional (functional architecture) La organización
je- rárquica de las funciones, de sus interfaces funcionales internas
y externas (externas a la propia agregación) e interfaces físicos
externos, de sus respectivos requisitos, y de sus restricciones de
diseño (véase también “arquitectura”, “análisis funcional” y
“definición de la funcionalidad requerida y de los atributos de
calidad”).
Arranque del proyecto (project startup) Cuando se dedica un
conjunto de recursos interrelacionados a un proyecto para
desarrollar o
entregar uno o más productos o servicios a un cliente o un usuario
final (véase también “proyecto”).
Arranque del trabajo (work startup) Cuando se dedica un
conjunto de recursos interrelacionados de un grupo de trabajo
para desarrollar o entregar uno o más productos o servicios a
un cliente o a un usuario final (véase también “grupo de
trabajo”).
Aseguramiento de la calidad (quality assurance) Un medio
planificado y sistemático de asegurar a la gerencia que se aplican
los están- dares, prácticas, procedimientos y métodos definidos
del proceso.
Atributo de calidad (quality attribute) Una propiedad de un
producto o servicio por la que se juzgará su calidad por las
partes interesadas relevantes. Los atributos de calidad son
caracterizables por alguna medida adecuada.
Los ATRIBUTOS de CALIDAD son no FUNCIONALES, TALES como OPORTUNIDAD, rendi-
miento, CAPACIDAD de rESPUESTA, SEGURIDAD, MODIFICABILIDAD, FIABILIDAD y USABI-
LIDAD. Tienen UNA INFLUENCIA SIGNIFICATIVA SOBRe LA ARQUITECTURA.
Atributo de proceso (process attribute) Una característica
medible de la capacidad del proceso aplicable a cualquier
proceso.
Atributos de producto de trabajo y de tarea (work product and task
attributes) Características de los productos, servicios y tareas
usadas para ayudar a estimar el trabajo. Estas características
incluyen elementos, tales como el tamaño, la complejidad, el
peso, la forma, el ajuste y la función. Se utilizan normalmente
como una entrada para obtener otras estimaciones de recursos
(p. ej., esfuerzo, coste y calendario).
Auditoría (audit) Un examen objetivo de un producto de
trabajo o de un conjunto de productos de trabajo frente a
criterios específicos (p. ej., requisitos) (véase también “evaluar
objetivamente”).
Este es un término UTILIZADO de VARIAS FORMAS en CMMI, incluyendo AUDITORÍAS
de CONFIGURACIÓN y AUDITORÍAS de CONFORMIDAD del proceso.
Auditoría de configuración (configuration audit) Una auditoría
llevada a cabo para verificar que un elemento de configuración o
un conjunto de elementos de configuración que componen una
línea base, se ajustan a un estándar o requisito especificado (véase
tam- bién “auditoría” y “elemento de configuración”).
Biblioteca de activos de proceso (process asset library) Un conjun-
to de activos de proceso que pueden ser utilizados por una organi-
zación, proyecto o grupo de trabajo (véase también “biblioteca de
activos de proceso de la organización”).
Biblioteca de activos de proceso de la organización (organization’s
process asset library) Una biblioteca de información utilizada
para almacenar y poner a disposición los activos de proceso que
son útiles para aquellos que definen, implementan y gestionan los
procesos de la organización.
ESTA BIBLIOTECA contiene ACTIVOS de proceso que incluyen DOCUMENTACIÓN rELATI-
VA A los procesos, TAL como POLÍTICAS, procesos definidos, LISTAS de comprOBACIÓN,
documentos de lecciones APRENDIDAS, PLANTILLAS, ESTÁNDARes, procedimientos,
PLANES y MATERIALES de FORMACIÓN.
Calidad (quality) El grado en que un conjunto de características
inherentes satisface los requisitos.
Calificación de la evaluación (appraisal rating) El valor
asignado por un equipo de evaluación a (a) una meta o área de
proceso de CMMI, (b) el nivel de capacidad de un área de
proceso o (c) el nivel de madurez de una unidad organizativa.
Este término se UTILIZA en los MATERIALES de EVALUACIÓN de CMMI, TALES como
el MDD de SCAMPI. UNA CALIFICACIÓN se DETERMINA APLICANDO el proceso de
CALIFICACIÓN definido PARA el método de EVALUACIÓN que se está EMPLEANDO.
Capacidad de proceso (process capability) El rango de
resultados esperados que pueden lograrse siguiendo un proceso.
Catálogo de servicios (service catalog) Una lista o repositorio de
definiciones de servicios estandarizados.
Los CATÁLOGOS de servicios pueden incluir niveles de DETALLE VARIADOS ACERCA
de los niveles de servicio disponibles, CALIDAD, precios, elementos NEGOCIABLES/
ADAPTABLES, y términos y condiciones.
Un CATÁLOGO de servicios no NECESITA ESTAR contenido en un único documento
u otro ARTEFACTO, y puede ser UNA COMBINACIÓN de elementos que proporCIONAN
INFORMACIÓN EQUIVALENTE (TALES como PÁGINAS web ENLAZADAS A BASES de DATOS).
ALTERNATIVAMENTE, PARA ALGUNOS servicios, un CATÁLOGO EFICAZ puede ser UNA
LISTA imprESA de los servicios disponibles y sus precios.
LA INFORMACIÓN del CATÁLOGO de servicios puede PARTICIONARSE en distintos sub-
conjuntos PARA DAR soporte A diferentes tipos de PARTES interESADAS (p.ej., clien-
tes, USUARIOS FINALES, EMPLEADOS del proveedor, proveedores).
Causa común de variación (common cause of variation) La varia-
ción de un proceso que existe debido a las interacciones normales
y esperadas entre los componentes de un proceso (véase también
“causa especial de variación”).
Causa especial de variación (special cause of variation) Una causa
de un defecto que es específica a alguna circunstancia transitoria
y no es una parte inherente de un proceso (véase también “causa
común de variación”).
Ciclo de vida del producto (product lifecycle) El periodo de
tiempo, compuesto de fases, que comienza cuando se concibe un
producto o servicio y finaliza cuando el producto o servicio ya
no está disponible para su uso.
DADO que UNA ORGANIZACIÓN puede ESTAR produciendo múltiples productos o ser-
vicios PARA múltiples clientes, puede no ser ADECUADO disponer sólo de UNA des-
cripción de ciclo de VIDA de producto. Por TANTO, LA ORGANIZACIÓN puede definir
un conjunto de modelos APROBADOS de ciclo de VIDA del producto. Estos modelos
se ENCUENTRAN NORMALMENTE en LA LITERATURA PUBLICADA y es prOBABLE que se
ADAPTEN PARA SU UTILIZACIÓN por UNA ORGANIZACIÓN.
Un ciclo de VIDA del producto PODRÍA CONSTAR de LAS SIGUIENTES FASES: (1) concep-
to y visión ,(2) VIABILIDAD, (3) DISEÑO/DESARrollo, (4) producción y (5) rETIRADA.
Cliente (customer) La parte responsable de aceptar el producto o
de autorizar el pago.
El cliente es externo AL proyecto o grupo de TRABAJO (excepto posiblemente en
CIERTAS ESTRUCTURAS de proyecto en LAS CUALES el cliente está de hecho en el equi-
po de proyecto o en el grupo de TRABAJO), pero no NECESARIAMENTE externo A LA
orGANIZACIÓN. El cliente puede ser un proyecto o un grupo de TRABAJO de MAYOR
nivel. Los clientes son un subconjunto de LAS PARTES interESADAS (VÉASE TAMBIÉN
“PARTE interESADA”).
En LA MAYORÍA de los CASOS en los que se USA este término, LA definición pre-
cedente es LA que prEVALECE; sin EMBARgo, en ALGUNOS contextos, el término
“cliente” pretende incluir A OTRAS PARTES interESADAS rELEVANTES (VÉASE TAMBIÉN
“requisitos de cliente”).
Los USUARIOS FINALES pueden ESTAR diferENCIADOS de los clientes si LAS PARTES que
reciben dirECTAMENTE el VALOR de los productos y servicios no son LAS MISMAS
que ESTABLECIERon, PAGARon o NEGOCIARon los ACUERdos. En contextos donde los
clientes y los USUARIOS FINALES son ESENCIALMENTE los mismos, el término “clien-
te” puede comprender AMBOS tipos (VÉASE TAMBIÉN “USUARIO FINAL”).
Comité de control de configuración (configuration control board) Un
grupo de personas que se responsabiliza de evaluar y aprobar o re-
chazar los cambios propuestos a los elementos de configuración,
y de asegurar la implementación de los cambios aprobados (véase
también “elemento de configuración”).
Los comités de control de CONFIGURACIÓN TAMBIÉN se conocen como “comités de
control de CAMBIOS”.
Componente de producto (product component) Un producto
de trabajo que es un componente de bajo nivel del producto
(véase también “producto” y “producto de trabajo”).
Los componentes de producto se INTEGRAN PARA producir el producto. Pueden
existir VARIOS niveles de componentes de producto.
En LAS árEAS de proceso, donde se UTILIZAN los términos “producto” y “compo-
nente de producto”, su SIGNIFICADO TAMBIÉN ABARca los servicios, los SISTEMAS de
servicio y sus componentes.
Este término tiene un SIGNIFICADO ESPECIAL en el conjunto de productos CMMI
ADEMÁS de su SIGNIFICADO USUAL.
Componente de sistema de servicio (service system component)
Un recurso requerido por un sistema de servicio para la entrega
con éxi- to de los servicios.
Algunos componentes pueden PERMANECER en prOPIEDAD del cliente, USUARIO fi-
NAL o terCERA PARTE ANTES de que LA entrEGA del servicio comience y después de
LA FINALIZACIÓN de LA entrEGA del servicio (VÉASE TAMBIÉN “cliente” y “USUARIO
FINAL”).
Algunos componentes pueden ser recursos TRANSITORIOS que son PARTE del siste-
MA de servicio por un tiempo LIMITADO (p. ej., elementos que están en rEPARA-
ción en UNA TIENDA de MANTENIMIENTO).
Los componentes pueden incluir procesos y PERSONAL.
LA PALABRA “componente” puede ser UTILIZADA en LUGAR de “componente del
SISTEMA de servicio” por brEVEDAD CUANDO el contexto PERMITA que el SIGNIFICADO
SEA CLARo.
LA PALABRA “INFRAESTRUCTURA” puede UTILIZARSE PARA referirse COLECTIVAMENTE A
los componentes TANGIBLES y ESENCIALMENTE PERMANENTES del SISTEMA de servi-
cio. Dependiendo del contexto y del tipo de servicio, LA INFRAESTRUCTURA puede
incluir recursos HUMANOS.
Componente del modelo CMMI (CMMI model component)
Cual- quiera de los principales elementos de la arquitectura que
componen un modelo CMMI.
Algunos de los PRINCIPALES elementos de un modelo CMMI incluyen LAS prácti-
CAS ESPECÍFICAS, LAS PRÁCTICAS GENÉRICAS, LAS METAS ESPECÍFICAS, LAS METAS gené-
RICAS, LAS árEAS de proceso, los niveles de CAPACIDAD y los niveles de MADURez.
Componentes esperados CMMI (expected CMMI compo-
nents) Componentes de CMMI que describen las actividades que
son importantes para lograr un componente requerido de
CMMI.
Los usuArios del modelo pueden implementAr los componentes esperAdos explíci-
tAmente o implementAr prácticAS AlternAtivAS equivAlentes A estos componentes.
LAS prácticAS específicAS y genéricAS SOn componentes esperAdos del modelo.
Componentes informativos CMMI (informative CMMI compo-
nents) Componentes de CMMI que ayudan a los usuarios del
modelo a comprender los componentes requeridos y esperados de un
modelo.
Estos componentes pueden ser ejemplos, explicAciones detAllAdAS u otrA infor-
mAción útil. LAS SubprácticAS, lAS notAS, lAS referenciAS, los títulos de metAS, los
títulos de prácticAS, lAS fuentes, los ejemplos de productos de trAbAjo y lAS elA-
borAciones de lAS prácticAS genéricAS SOn componentes informAtivos del modelo.
Componentes requeridos CMMI (required CMMI compo-
nents) Componentes CMMI que son esenciales para alcanzar la
mejora de procesos en un área de proceso determinada.
LAS METAS ESPECÍFICAS y LAS METAS GENÉRICAS SON componentes requeridos del
modelo. LA SATISFACCIÓN de LA META SE UTILIZA en LAS EVALUACIONES como BASE
PARA decidir si se HA SATISFECHO un árEA de proceso.
Comprador (acquirer) La parte interesada que adquiere u obtie-
ne un producto o servicio de un proveedor (véase también
“parte interesada”).
Concepto operativo (operational concept) Una descripción
general de la forma en la que una entidad se utiliza u opera.
Un concepto OPERATIVO TAMBIÉN es conocido como “concepto de OPERACIONES”.
Conjunto de procesos estándar de la organización (organization’s set
of standard processes) Un conjunto de definiciones de
procesos que dirigen las actividades de una organización.
ESTAS descripciones de procesos cubren los elementos FUNDAMENTALES de proceso
(y LAS rELACIONES entre ellos, TALES como SECUENCIA e interFACES) que se DEBERÍAN
INCORPORAR en los procesos definidos que se IMPLEMENTAN en los proyectos, en
los grupos de TRABAJO y en el TRABAJO en TODA LA ORGANIZACIÓN. Un proceso están-
DAR permite ACTIVIDADES de DESARrollo y MANTENIMIENTO consistentes en TODA LA
orGANIZACIÓN y es ESENCIAL PARA LA ESTABILIDAD y LA MEJORA A LARgo PLAZO (VÉASE
TAMBIÉN “proceso definido” y “elemento de proceso”).
Conjunto de productos (product suite) Véase “conjunto de produc-
tos CMMI”.
Conjunto de productos CMMI (CMMI Product Suite) El
conjunto completo de productos desarrollados alrededor del
concepto CMMI (véase también “marco CMMI” y “modelo
CMMI”).
Estos productos incluyen el propio MARco, los modelos, los métodos de EVALUA-
ción, los MATERIALES de EVALUACIÓN y los MATERIALES de FORMACIÓN.
Constelación (constellation) Una colección de componentes
CMMI que se utilizan para construir modelos, materiales de
formación y documentos relativos a la evaluación para un área
de interés (p. ej., adquisición, desarrollo, servicios).
Consumible del sistema de servicio (service system consuma-
ble) Un componente del sistema de servicio que deja de estar
disponible o cambia permanentemente al ser utilizado durante la
entrega de un servicio.
El combustible, los suministros de OFICINA y los contenedores de productos dese-
CHABLES son ejemplos de consumibles UTILIZADOS HABITUALMENTE. Tipos PARTICU-
LARes de servicios pueden tener sus propios consumibles ESPECIALIZADOS (p. ej.,
un servicio SANITARIO puede requerir MEDICINAS O SUMINISTRo de SANGRe).
El PERSONAL no es un consumible, pero su tiempo de TRABAJO es un consumible.
Contratista (contractor) Véase “proveedor”.
Control de calidad (quality control) Las técnicas y las
actividades operativas que se utilizan para satisfacer los requisitos
de calidad (véase también “aseguramiento de la calidad”).
Control de configuración (configuration control) Un elemento
de la gestión de configuración que consiste en la evaluación, la
coordinación, la aprobación o el rechazo, y la implementación de
los cambios a los elementos de configuración una vez establecida
formalmente su identificación de configuración (véase también
“identificación de configuración”, “elemento de configuración” y
“gestión de configuración”).
Control de interfaz (interface control) En gestión de
configuración, el proceso de (1) identificar todas las
características funcionales y físicas relevantes para la
interconexión de dos o más elementos de configuración
proporcionados por una o más organizaciones, y (2) asegurar que
los cambios propuestos a estas características se eva- lúan y
aprueban antes de su implementación (véase también “elemento
de configuración” y “gestión de configuración”).
Control de versiones (version control) El establecimiento y el
mantenimiento de las líneas base y la identificación de los
cambios a las líneas base que hacen posible volver a una línea
base previa.
En ALGUNOS contextos, un producto de TRABAJO INDIVIDUAL puede tener su prOPIA
LÍNEA BASE y puede ser suficiente un nivel de control menor que el control de
CONFIGURACIÓN FORMAL.
Control estadístico de procesos (statistical process control)
Análi- sis, basado en estadística, de un proceso y de medidas de
rendimien- to de proceso, que identifican las causas comunes y
especiales de variación en el rendimiento de proceso y mantienen
el rendimiento de proceso dentro de los límites (véase también
“causa común de variación”, “causa especial de variación” y “técnicas
estadísticas”).
Criterios de aceptación (acceptance criteria) Los criterios que
debe satisfacer un entregable para ser aceptado por un usuario, un
cliente u otra entidad autorizada (véase también “entregable”).
Criterios de entrada (entry criteria) Condiciones que deben estar
presentes antes de que un trabajo pueda comenzar con éxito.
Criterios de salida (exit criteria) Condiciones que deben estar
presentes antes de que un esfuerzo pueda terminar con éxito.
Datos (data) Información registrada.
LA INFORMACIÓN rEGISTRADA puede incluir DATOS técnicos, documentos de soft-
WARe, INFORMACIÓN FINANCIERA, INFORMACIÓN de gestión, reprESENTACIÓN de
hechos, números o DATOS de CUALQUIER NATURALEZA que PUEDAN COMUNICARSE,
ALMACENARSE y prOCESARSE.
Declaración de trabajo (statement of work) Una descripción del
trabajo a realizar.
Definición de la funcionalidad requerida y de los atributos de calidad
(definition of required functionality and quality attributes) Una
caracterización de los atributos de calidad y de la funcionalidad re-
querida, que se obtiene a través de la “fragmentación”,
organización, anotación, estructuración o formalización de los
requisitos (funcionales y no funcionales) para facilitar el posterior
refinamiento y obten- ción de los requisitos, así como sobre la
exploración (posiblemente, inicial), la definición y la evaluación de
la solución (véase también “arquitectura”, “arquitectura funcional” y
“atributo de calidad”).
A MEDIDA que progrESAN los procesos de LA SOLUCIÓN TÉCNICA, ESTA CARACTERIZA-
ción puede EVOLUCIONAR AÚN más, HASTA convertirse en UNA descripción de LA
ARQUITECTURA en vez de UNA AYUDA PARA GUIAR su DESARrollo, dependiendo de
los procesos de INGENIERÍA USADOS; LA ESPECIFICACIÓN de requisitos y LENGUAJES
de ARQUITECTURA UTILIZADOS; y LAS herRAMIENTAS y el entorno UTILIZADOS PARA el
DESARrollo del producto o del SISTEMA de servicio.
Definición de proceso (process definition) El acto de definir y des-
cribir un proceso.
El rESULTADO de LA definición del proceso es UNA descripción de proceso (VÉASE
TAMBIÉN “descripción de proceso”).
Densidad de defectos (defect density) Número de defectos por
unidad de tamaño de producto.
Un ejemplo es el número de prOBLEMAS por CADA mil LÍNEAS de código.
Desarrollo (development) Crear un producto o sistema de
servicio con un esfuerzo premeditado.
En ALGUNOS contextos, el DESARrollo puede incluir el MANTENIMIENTO del produc-
to DESARrOLLADO.
Descripción de proceso (process description) Una
especificación documentada de un conjunto de actividades
realizadas para alcanzar un propósito determinado.
UnA descripción de proceso proporcionA unA definición operAtivA de los princi-
pAles componentes de un proceso. LA descripción específicA, de mAnerA completA,
precisA y verificAble, los requisitos, el diseño, el comportAmiento u otrAS cArAc-
terísticAS de un proceso. TAmbién puede incluir procedimientos pArA determinAr
si se hAn sAtisfecho estAS disposiciones. Se pueden encontrAr descripciones de
proceso A nivel de ActividAd, de proyecto, de grupo de trAbAjo o de orgAnizAción.
Director (senior manager) Un rol de gestión situado en un nivel
lo suficientemente alto en la organización donde la
preocupación principal de la persona que desempeña este rol
es la permanencia de la organización a largo plazo en lugar de
las preocupaciones y presio- nes a corto plazo (véase también
“nivel directivo”).
Un director tiene AUTORIDAD PARA dirigir LA ASIGNACIÓN o rEASIGNACIÓN de recur-
sos PARA DAR soporte A LA EFICACIA de LA MEJORA de procesos de LA ORGANIZACIÓN.
Un director puede ser cuAlquier gerente que sAtisfAce estA descripción, incluyen-
do el dirigente máximo de lA OrgAnizAción. Sinónimos pArA “director” incluyen
“ejecutivo” y “gerente de Alto nivel”. Sin embArgo, pArA ASegurAr lA consistenciA
y lA usAbilidAd, estos sinónimos no se utilizAn en los modelos CMMI.
Documento (document) Un conjunto de datos, sin tener en
cuenta el medio en el que se han registrado, que normalmente
perdura y puede ser leído por seres humanos o máquinas.
Los documentos incluyen TANTO los documentos en PAPEL como los electrónicos.
Educción de requisitos (requirements elicitation) Uso de técnicas
sistemáticas, tales como prototipos o encuestas estructuradas,
para identificar y documentar de manera proactiva las
necesidades del cliente y del usuario final.
Ejecutivo (executive) Véase “director”.
Ejemplo de producto de trabajo (example work product) Un
componente informativo del modelo que proporciona ejemplos
de resultados de una práctica específica.
Elaboración de práctica genérica (generic practice elaboration)
Un componente informativo del modelo que aparece después
de una práctica genérica para proporcionar orientación de
cómo podría aplicarse de forma única a un área de proceso (este
componente del modelo no está presente en todos los modelos
CMMI).
Elemento de configuración (configuration item) Una agrupación
de productos de trabajo que se establece para la gestión de
configuración
y se trata como una entidad única en el proceso de gestión de
confi- guración (véase también “gestión de configuración”).
Elemento de proceso (process element) La unidad fundamental de
un proceso.
Se puede definir un proceso en términos de subprocesos o elementos de proceso.
Un subproceso es un elemento de proceso cuAndo no se puede descomponer más
en subprocesos o elementos de proceso (véASe tAmbién “proceso” y “subproceso”).
CAdA elemento de proceso cubre un conjunto de ActividAdes estrechAmente relA-
cionAdAS (p. ej., elemento de estimAción, elemento de revisión entre pAres). Se
pueden describir los elementos de proceso utilizAndo plAntillAS que deben com-
pletArse, AbstrAcciones que deben refinArse o descripciones que deben modifi-
cArse o utilizArse. Un elemento de proceso puede ser unA ActividAd o unA tAreA.
Los términos “proceso”, “subproceso” y “elemento de proceso” FORMAN UNA je-
RARQUÍA SIENDO “proceso” el término más GENERAL y de MAYOR nivel, “los subpro-
cesos” por DEBAJO de él y “elemento de proceso” como el más específico.
Elemento no desarrollado en el proyecto (nondevelopmental
item) Un elemento que fue desarrollado antes de su uso actual en
un proceso de adquisición o de desarrollo.
Dicho elemento puede requerir PEQUEÑAS MODIFICACIONES PARA cumplir los re-
quisitos PARA SU uso previsto ACTUAL.
Empresa (enterprise) La composición completa de una compañía
(véase también “organización”).
UNA COMPAÑÍA puede ESTAR FORMADA por MUCHAS ORGANIZACIONES en MUCHAS
UBICACIONES con distintos clientes.
Entorno de entrega (delivery environment) El conjunto completo
de circunstancias y condiciones bajo las cuales se entregan los ser-
vicios conforme a los acuerdos de servicio (véase también “servicio”
y “acuerdo de servicio”).
El entorno de entrEGA ENGLOBA CUALQUIER COSA que TENGA O PUEDA tener un efecto
SIGNIFICATIVO sobre LA entrEGA del servicio incluyendo, entre otros, LA OPERACIÓN
del SISTEMA de servicio, los fenómenos NATURALES y el COMPORTAMIENTO de TODAS
LAS PARTES, prETENDAN o no tener TAL efecto. Por ejemplo, considere el efecto de
PATRones meteorológicos o de tráfico en un servicio de TRANSPORTE (VÉASE TAM-
bién “SISTEMA de servicio”).
El entorno de entrEGA SE distingue de FORMA ÚNICA de otros entornos (p. ej.,
entornos de SIMULACIÓN, entornos de PRUEBAS). El entorno de entrEGA es donde
se entrEGAN rEALMENTE los servicios y donde se mide el cumplimiento de un
ACUERdo de servicio.
Entregable (deliverable) Un elemento que se suministra a un
comprador o a otro destinatario designado según se
especifique en un acuerdo (véase también “comprador”).
Este elemento puede ser un documento, un elemento HARDWARe, un elemento
SOFTWARe, un servicio o CUALQUIER tipo de producto de TRABAJO.
Equipo (team) Un grupo de personas con habilidades y
experiencia complementarias que trabajan juntas para
alcanzar los objetivos especificados.
Un equipo ESTABLECE y MANTIENE un proceso que IDENTIFICA los roles, LAS respon-
SABILIDADES y LAS interFACES; es suficientemente preciso PARA permitir AL equipo
medir, GESTIONAR y MEJORAR sus rendimientos de TRABAJO; y permite AL equipo
HACER y defender sus compromisos.
ColectivAmente, los miembros del equipo proporcionAn hAbilidAdes y Apoyos Apro-
piAdos A todos los ASpectos de su trAbAjo (p. ej., pArA lAS diferentes fASes de lA vidA
de un producto de trAbAjo) y son responsAbles de cumplir los objetivos especificAdos.
No todo miembro de un proyecto o grupo de TRABAJO debe pertenecer A un
equipo (p.ej., un EMPLEADO que HACE UNA TAREA que es independiente). Así, un
proyecto o grupo de TRABAJO GRANDE puede contener muchos equipos ASÍ como
PERSONAL del proyecto que no PERTENEZCA A ningún equipo. Un proyecto o grupo
de TRABAJO más pequeño puede consistir en un solo equipo (o un individuo).
Equipo de acción de proceso (process action team) Un equipo
que tiene la responsabilidad de desarrollar e implementar
actividades de mejora de procesos para una organización, tal y
como se documentan en un plan de acción de proceso.
Escenario operativo (operational scenario) Una descripción de
una secuencia ficticia de eventos que incluye la interacción del
producto o servicio con su entorno y con los usuarios, así como
la interacción entre sus componentes de producto o de servicio.
Los ESCENARIOS OPERATIVOS se UTILIZAN PARA EVALUAR los requisitos y el diseño del
SISTEMA, y PARA VERIFICAR y VALIDAR el SISTEMA.
Establecer y mantener (establish and maintain) Crear,
documentar, utilizar y modificar los productos de trabajo según
sea necesario para asegurar que siguen siendo útiles.
LA FRASE “ESTABLECER y MANTENER” JUEGA un rol ESPECIAL A LA HORA de COMUNICAR
un principio más profundo de CMMI: Se DEBERÍA prESTAR ESPECIAL ATENCIÓN A los
productos de TRABAJO que tienen un rol CENTRAL o CLAVE en un grupo de TRABAJO,
en un proyecto y en el rendimiento de LA ORGANIZACIÓN, PARA ASEGURAR que se
UTILIZAN y que son útiles en ese rol.
ESTA FRASE tiene UNA PARTICULAR rELEVANCIA en CMMI porque APARece frecuente-
mente en LAS DECLARACIONES de LAS METAS y de LAS PRÁCTICAS, y se DEBERÍA consi-
DERAR como UNA ABREVIATURA del principio ANTERIOR que se APLICARÁ A CUALQUIER
producto de TRABAJO que SEA OBJETO de ESA FRASE.
Estándar (nombre) (standard (noun)) Requisitos formales
desarrollados y utilizados para prescribir aproximaciones
coherentes para la adquisición, desarrollo o servicio.
Algunos ejemplos de ESTÁNDARes son los ESTÁNDARes de ISO/IEC, los ESTÁNDARes
de IEEE y los ESTÁNDARes de LA ORGANIZACIÓN.
Estrategia de adquisición (acquisition strategy) La
aproximación específica para adquirir productos y servicios
teniendo en cuenta las fuentes de suministro, los métodos de
adquisición, los tipos de especificación de requisitos, los tipos
de acuerdo y los riesgos asociados con la adquisición.
Estructura de descomposición del trabajo (WBS, work breakdown
structure) Una distribución de los elementos de trabajo y la rela-
ción entre ellos y con el producto o servicio final.
Estudio de opciones (trade study) Una evaluación de
alternativas, basándose en criterios y análisis sistemáticos, para
seleccionar la mejor alternativa para alcanzar determinados
objetivos.
Evaluación (appraisal) Un examen de uno o más procesos
realizado por un equipo de profesionales cualificados,
utilizando un modelo de referencia de evaluación como base
para determinar, como míni- mo, fortalezas y debilidades.
Este término tiene un SIGNIFICADO ESPECIAL en el Conjunto de Productos CMMI,
Evaluar objetivamente (objectively evaluate) Revisar las
actividades y los productos de trabajo frente a los criterios que
minimicen la subjetividad y el sesgo del revisor (véase también
“auditoría”).
Un ejemplo de UNA EVALUACIÓN OBJETIVA es UNA AUDITORÍA frente A los requisitos,
ESTÁNDARes o procedimientos por UNA función de ASEGURAMIENTO de LA CALIDAD
independiente.
Extensión (addition) Un componente del modelo claramente
desta- cado que contiene información de interés para usuarios
concretos.
En un modelo CMMI, TODAS LAS extensiones que LLEVAN el mismo nombre se
pueden SELECCIONAR de MANERA OPCIONAL PARA UTILIZARLAS como un grupo. En
CMMI PARA Servicios, el árEA de proceso de DESARrollo del SISTEMA de Servicio
(SSD) es UNA extensión.
Formación (training) Opciones de aprendizaje formal e informal.
ESTAS OPCIONES de APRENDIZAJE pueden incluir FORMACIÓN en AULAS, TUTELA infor-
MAL, FORMACIÓN BASADA en web, AUTOESTUDIO dirigido, y prOGRAMAS de FORMA-
ción FORMALIZADOS en el puesto de TRABAJO.
LAS OPCIONES de APRENDIZAJE SELECCIONADAS PARA CADA SITUACIÓN se BASAN en UNA
EVALUACIÓN de LA NECESIDAD de FORMACIÓN y de LAS CARENCIAS de rendimiento A
TRATAR.
Gerente (manager) Una persona que proporciona dirección, y
control técnico y administrativo a aquellos que realizan las
tareas o las actividades dentro del área de responsabilidad del
gerente.
Este término tiene un SIGNIFICADO ESPECIAL en el Conjunto de Productos de
CMMI ADEMÁS de su SIGNIFICADO USUAL. LAS funciones TRADICIONALES de un ge-
rente incluyen LA PLANIFICACIÓN, LA ORGANIZACIÓN, LA dirección y el control del
TRABAJO dentro de un árEA de rESPONSABILIDAD.
Gestión cuantitativa (quantitative management) Gestión de un
proyecto o grupo de trabajo utilizando técnicas estadísticas y
otra téc- nicas cuantitativas para adquirir una comprensión del
rendimiento o del rendimiento previsto de los procesos en
comparación con los objetivos de calidad y de rendimiento de
proceso del proyecto o grupo de trabajo, y para identificar las
acciones correctivas que se pueden necesitar tomar (véase
también “técnicas estadísticas”).
LAS TÉCNICAS ESTADÍSTICAS UTILIZADAS en LA gestión CUANTITATIVA incluyen el
ANÁLISIS, LA crEACIÓN o el uso de modelos de rendimiento de proceso; ANÁLISIS,
crEACIÓN o uso de LÍNEAS BASE de rendimiento de proceso; uso de DIAGRAMAS
de control; ANÁLISIS de VARIANZA, ANÁLISIS de regresión; y uso de INTERVALOS de
CONFIANZA O INTERVALOS de predicción, ANÁLISIS de SENSIBILIDAD, SIMULACIONES y
CONTRASTES de hipótesis.
Gestión de cambios (change management) Uso racional de los
medios para efectuar un cambio, o un cambio propuesto, a un
produc- to o servicio (véase también “gestión de configuración”).
Gestión de configuración (configuration management) Una discipli-
na que aplica la dirección técnica y administrativa, y la
supervisión para (1) identificar y documentar las
características funcionales y físicas de un elemento de
configuración, (2) controlar los cambios a esas características,
(3) registrar e informar sobre el proceso de cambios y su estado
de implementación, y (4) verificar el cumplimiento de los
requisitos especificados. Véase también “auditoría de
configuración”, “control de configuración”, “identificación de la
configuración” e “informe del estado de configuración”.
Gestión de los datos (data management) Los procesos y
sistemas disciplinados que planifican, adquieren y permiten
administrar los datos del negocio y técnicos, consistentemente
con los requisitos de datos, a lo largo del ciclo de vida de los
datos.
Gestión de requisitos (requirements management) La gestión de to-
dos los requisitos recibidos o generados por el proyecto o grupo
de trabajo, incluyendo tanto los requisitos técnicos como los no
técni- cos, así como aquellos requisitos impuestos al proyecto o
grupo de trabajo por la organización (véase también “requisitos
no técnicos”).
Gestión de riesgos (risk management) Un proceso organizado y
ana- lítico para identificar lo que podría causar daño o pérdida
(identificar riesgos); para evaluar y cuantificar los riesgos
identificados; y para desarrollar y, si es necesario, implementar
una aproximación apropiada para prevenir o gestionar las
causas de riesgo que podrían dar como resultado daños o
pérdidas significativos.
NORMALMENTE, LA gestión de riesgos se rEALIZA PARA LAS ACTIVIDADES de un pro-
yecto, de un grupo de TRABAJO, de UNA ORGANIZACIÓN o de OTRAS UNIDADES de LA
orGANIZACIÓN que estén DESARrOLLANDO o entrEGANDO productos o servicios.
Gestionado cuantitativamente (quantitatively managed) Véase
“gestión cuantitativa”.
Grupo de procesos (process group) Un conjunto de
especialistas que proporciona la definición, el mantenimiento y
la mejora de los procesos utilizados por la organización.
Grupo de trabajo (work group) Un conjunto gestionado de
personas y otros recursos asignados que entrega uno o más
productos o servicios a un cliente o a un usuario final (véase
también “proyecto”).
Un grupo de trAbAjo puede ser cuAlquier entidAd de lA OrgAnizAción con un
propósito definido, ApArezcA O no dichA entidAd en un orgAnigrAm A. Los
grupos de trAbAjo pueden ApArecer en cuAlquier nivel de unA OrgAnizAción,
pueden contener otros grupos de trAbAjo y pueden sobrepASAr los límites de
lA OrgAnizAción.
Un grupo de TRABAJO junto con su TRABAJO puede CONSIDERARSE IGUAL que un pro-
yecto si de FORMA INTENCIONADA tiene UNA VIDA LIMITADA.
Guías de adaptación (tailoring guidelines) Las guías de la
organi- zación que permiten a los proyectos, a los grupos de
trabajo y a las funciones de la organización, adaptar
adecuadamente los procesos estándar para su utilización.
El conjunto de procesos ESTÁNDAR de LA ORGANIZACIÓN se describe A nivel GENERAL
y puede no ser dirECTAMENTE UTILIZABLE PARA rEALIZAR un proceso.
LAS GUÍAS de ADAPTACIÓN AYUDAN A AQUELLOS que ESTABLECEN los procesos defini-
dos PARA los proyectos o grupos de TRABAJO. LAS GUÍAS de ADAPTACIÓN cubren (1)
LA SELECCIÓN de un proceso ESTÁNDAR, (2) LA SELECCIÓN de un modelo de ciclo de
VIDA APROBADO, y (3) LA ADAPTACIÓN del proceso ESTÁNDAR y el modelo de ciclo
de VIDA SELECCIONADOS PARA AJUSTARSE A LAS NECESIDADES del proyecto o grupo
de TRABAJO. LAS GUÍAS de ADAPTACIÓN describen qué es lo que puede y no se
puede MODIFICAR e IDENTIFICAN los componentes de proceso que son CANDIDATOS
A MODIFICAR.
Hallazgos (findings) Véase “hallazgos de la evaluación”.
Hallazgos de la evaluación (appraisal findings) Los resultados
de una evaluación que identifican las cuestiones, problemas u
oportunidades más importantes para la mejora de procesos,
dentro del alcance de la evaluación.
Los HALLAZGOS de LA EVALUACIÓN son deducciones DERIVADAS de EVIDENCIAS OBJE-
TIVAS corrOBORADAS.
Identificación de la configuración (configuration identification) Un
elemento de la gestión de configuración que consiste en la
selección de los elementos de configuración para un producto, la
asignación de identificadores únicos y el registro de sus
características funcionales y físicas en la documentación técnica
(véase también “elemen- to de configuración”, “gestión de
configuración” y “producto”).
Identificación de riesgos (risk identification) Una aproximación
organizada y concienzuda utilizada para buscar riesgos
probables o realistas para alcanzar los objetivos.
Incidencia de servicio (service incident) Una indicación de una
interferencia real o potencial en un servicio.
LAS INCIDENCIA de servicio pueden ocurrir en CUALQUIER dominio del servicio
porque LAS QUEJAS del cliente y del USUARIO FINAL son tipos de INCIDENCIAS e in-
cluso el servicio más sencillo puede GENERAR QUEJAS.
LA PALABRA “INCIDENCIA” se puede UTILIZAR en LUGAR de “INCIDENCIA de servicio”
por brEVEDAD, CUANDO el contexto PERMITA que el SIGNIFICADO SEA CLARo.
Informe del estado de configuración (configuration status accoun-
ting) Un elemento de la gestión de configuración que consiste
en el registro y la publicación de la información necesaria para
gestionar eficazmente una configuración (véase también
“identificación de la configuración” y “gestión de configuración”).
ESTA INFORMACIÓN incluye UNA LISTA de LA CONFIGURACIÓN APROBADA, el ESTADO de
los CAMBIOS propuestos A LA CONFIGURACIÓN y el ESTADO de IMPLEMENTACIÓN de los
CAMBIOS APROBADOS.
Ingeniería de hardware (hardware engineering) La aplicación
de una aproximación sistemática, disciplinada y cuantificable para
transformar un conjunto de requisitos que representan el conjunto
de necesidades, expectativas y restricciones de las partes
interesadas utilizando técnicas documentadas y tecnología para
diseñar, implementar y mantener un producto tangible (véase
también “ingeniería de software” e “ingeniería de sistemas”).
En CMMI, lA ingenieríA de hArdwAre representA todos los cAmpos técnicos
(p. ej., eléctrico, mecánico) que TRANSFORMAN los requisitos e IDEAS en productos
TANGIBLES.
Ingeniería de sistemas (systems engineering) La aproximación
interdisciplinaria que rige el esfuerzo total técnico y de gestión
requeridos para transformar un conjunto de necesidades,
expectativas y limitaciones del cliente en una solución y para dar
soporte a dicha solución a lo largo de su vida (véase también
“ingeniería de hardware” e “ingeniería de software”).
ESTA APROXIMACIÓN incluye LA definición de MEDIDAS de rendimiento TÉCNICAS, LA
INTEGRACIÓN de LAS ESPECIALIDADES de INGENIERÍA ENCAMINADAS AL ESTABLECIMIENTO
de UNA ARQUITECTURA, y LA definición de los procesos de soporte del ciclo de VIDA
que equilibren los objetivos de coste, de CALENDARIO y de rendimiento.
Ingeniería de software (software engineering) (1) La aplicación
de una aproximación sistemática, disciplinada y cuantificable
al desarrollo, a la explotación y al mantenimiento de software.
(2) El estudio de las aproximaciones como en (1) (véase
también “ingeniería de hardware” e “ingeniería de sistemas”).
Institucionalización (institutionalization) La forma de trabajar
que está arraigada en una organización y que se sigue de forma
rutinaria como parte de su cultura corporativa.
Límites naturales (natural bounds) El rango de variación
inherente de un proceso, que se establece mediante las medidas de
rendimien- to del proceso.
Los límites NATURALES ALGUNAS veces se DENOMINAN “LA voz del proceso”.
Se UTILIZAN TÉCNICAS TALES como DIAGRAMAS de control, INTERVALOS de CONFIANZA
e INTERVALOS de predicción PARA DETERMINAR si LA VARIACIÓN se debe A CAUSAS
comunes (p. ej., el proceso es predecible o ESTABLE) o se debe A ALGUNA CAUSA
ESPECIAL que puede y que DEBERÍA IDENTIFICARSE y ELIMINARSE (VÉASE TAMBIÉN
“MEDIDA” y “rendimiento de proceso”).
Línea base (baseline) Un conjunto de especificaciones o
productos de trabajo que se ha revisado y acordado
formalmente, que sirve como la base para el desarrollo
posterior y que solamente puede cambiarse mediante
procedimientos de control de cambios (véase también “línea
base de configuración” y “línea base de producto”).
Línea base de configuración (configuration baseline) La informa-
ción de configuración establecida formalmente en un momento
dado durante la vida de un producto o de un componente de pro-
ducto (véase también “ciclo de vida del producto”).
Las líneas base de configuración, más los cambios aprobados a esas
líneas base, constituyen la información de configuración actual.
Línea base de producto (product baseline) El paquete inicial de
datos técnicos aprobado que define un elemento de
configuración durante la producción, operación, mantenimiento
y soporte logístico de su ciclo de vida (véase también “elemento
de configuración”, “gestión de configuración” y “paquete de datos
técnicos”).
Este término está rELACIONADO con gestión de CONFIGURACIÓN.
Línea base de rendimiento de proceso (process performance base-
line) Una caracterización documentada del rendimiento de pro-
ceso, la cual puede incluir tendencia central y variación (véase
también “rendimiento de proceso”).
UNA LÍNEA BASE de rendimiento de proceso puede ser UTILIZADA como punto de
referENCIA PARA COMPARAR el rendimiento rEAL del proceso frente AL rendimiento
ESPERADO del proceso.
Línea de producto (product line) Un grupo de productos que
comparten un conjunto de características comunes y gestionadas
que satisfacen las necesidades específicas de un mercado o de una
mi- sión seleccionada y que son desarrolladas a partir de un
conjunto común de activos básicos de una forma prescrita (véase
también “línea de servicio”).
El DESARrollo o ADQUISICIÓN de productos PARA LA LÍNEA de producto se BASA
en EXPLOTAR lo que es común y LIMITAR LA VARIACIÓN (p. ej., LIMITANDO LA VA-
RIACIÓN de producto INNECESARIA) entre el grupo de productos. El conjunto de
ACTIVOS básicos GESTIONADO (p. ej., requisitos, ARQUITECTURAS, componentes, he-
rRAMIENTAS, ARTEFACTOS de PRUEBA, procedimientos de OPERACIÓN, SOFTWARe) in-
cluye ORIENTACIÓN prESCRIPTIVA PARA SU UTILIZACIÓN en el DESARrollo del producto.
LAS OPERACIONES de LA LÍNEA de producto INVOLUCRAN LA ejecución ENGRANADA de
ACTIVIDADES GENERALES de DESARrollo de ACTIVOS básicos, DESARrollo de producto
y gestión.
MUCHAS PERSONAS USAN “LÍNEA de producto” sólo PARA referirse AL conjunto de
productos producidos por UNA UNIDAD de negocio PARTICULAR, YA SEAN construi-
dos con ACTIVOS COMPARTIDOS o no. LLAMAMOS A ESA colección un “portfolio” y
rESERVAMOS “LÍNEA de producto” PARA tener el SIGNIFICADO técnico DADO AQUÍ.
Línea de servicio (service line) Un conjunto consolidado y
estanda- rizado de servicios y niveles de servicio que satisfacen
las necesidades específicas de un mercado o área de misión
seleccionada (véase también “línea de producto” y “nivel de
servicio”).
Madurez de la organización (organizational maturity) El grado
en el cual una organización ha desplegado de forma explícita y
consistente los procesos que están documentados, gestionados,
medidos, controlados y mejorados de forma continua.
LA MADURez de LA ORGANIZACIÓN puede medirse A TRAVÉS de LAS EVALUACIONES.
Marco CMMI (CMMI Framework) La estructura base que
organiza los componentes CMMI, que incluye los elementos de
los modelos actuales de CMMI, así como las reglas y los
métodos para generar los modelos, los métodos de evaluación
(incluyendo los artefactos asociados) y los materiales de
formación (véase también “modelo CMMI” y “Conjunto de
productos CMMI”).
El MARco permite AÑADIR NUEVAS árEAS de interés A CMMI de FORMA que se in-
tegren con LAS existentes.
Marco de trabajo (framework) Véase “marco CMMI”.
Medición (measurement) Un conjunto de operaciones para
determinar el valor de una medida (véase también “medida”).
LA definición de este término en CMMI es consistente con LA definición de este
término en ISO 15939.
Medición de proceso (process measurement) Un conjunto
de operaciones usadas para determinar los valores de
medidas de un proceso y de sus productos o servicios
resultantes con el pro- pósito de caracterizar y comprender el
proceso (véase también “medición”).
Medida (measure (noun) Variable a la que se asigna un valor
como resultado de una medición (véase también “medida base”,
“medida derivada” y “medición”).
LA definición de este término en CMMI es consistente con LA definición de este
término en ISO 15939.
Medida base (base measure) Medida definida en términos de un
atributo y el método para cuantificarlo (véase también “medida
derivada”).
UNA MEDIDA BASE es FUNCIONALMENTE independiente de OTRAS MEDIDAS.
Medida de la prestación técnica (technical performance measu-
re) Medida técnica definida con precisión de un requisito, ca-
pacidad o alguna combinación de requisitos y capacidades (véase
también “medida”).
Medida de nivel de servicio (service level measure) Una medida
del rendimiento de la entrega de servicio asociada con un nivel de
servicio (véase también “medida” y “nivel de servicio).
Medida derivada (derived measure) Medida que se define como
una función de dos o más valores de medidas base (véase también
“medida base”).
Mejora de procesos (process improvement) Un programa de
actividades diseñado para mejorar el rendimiento y la madurez
de los procesos de la organización y los resultados de dicho
programa.
Mejoras de proceso y de tecnología (process and technology impro-
vements) Mejoras incrementales e innovadoras a los procesos y
a las tecnologías de proceso, producto o servicio.
Memorando de acuerdo (memorandum of agreement)
Documento vinculante de compromiso o de acuerdo entre dos o
más partes.
Un MEMORANDO de ACUERdo es TAMBIÉN conocido como un “MEMORANDO de
compromiso”
Meta específica (specific goal) Un componente requerido del
modelo que describe las características únicas que deben estar
presentes para satisfacer el área de proceso (véase también “nivel
de capacidad”, “meta genérica”, “objetivos de negocio de la
organización” y “área de proceso”).
Meta genérica (generic goal) Un componente requerido del
modelo que describe las características que deben estar
presentes para institucionalizar los procesos que implementan
un área de proceso (véase también “institucionalización”).
Modelo CMMI (CMMI model) Un modelo generado a partir del
marco CMMI (véase también “marco CMMI” y “Conjunto de
Productos CMMI”).
Modelo de ciclo de vida (lifecycle model) Una división en fases de
la vida de un producto, servicio, proyecto, grupo de trabajo o
conjun- to de actividades del trabajo.
Modelo de madurez y de capacidad (capability maturity model)
Un modelo que contiene los elementos esenciales de procesos
eficaces para una o más áreas de interés y describe un camino de
mejora evolutivo desde procesos inmaduros y ad hoc hasta
procesos maduros y disciplinados con una mejora en la eficacia y
en la calidad.
Modelo de referencia (reference model) Un modelo que se
utiliza como punto de referencia para medir un atributo.
Modelo de referencia de evaluación (appraisal reference model)
El modelo CMMI frente al cual un equipo de evaluación
correlaciona las actividades de proceso implementadas.
Este término se UTILIZA en los MATERIALES de EVALUACIÓN de CMMI, TALES como
el SCAMPI MDD.
Modelo de rendimiento de proceso (process performance mo-
del) Una descripción de las relaciones entre los atributos
medibles de uno o más procesos o productos de trabajo que se ha
desarrollado a partir de los datos históricos de rendimiento de
proceso y es utilizada para predecir rendimientos futuros (véase
también “medida”).
Uno o más de los Atributos medibles representAn entrAdAS controlAbles ligAdos A
un subproceso pArA permitir lA ejecución de Análisis ¿qué pASAríA Si…? pArA lA
plAnificAción, replAnificAción dinámicA y resolución de problemAS. Los modelos de
rendimiento de proceso incluyen modelos bASAdos en estAdísticA, probAbilidAd y
simulAción que predicen resultAdos intermedios o finAles conectAndo rendimiento
pASAdo con resultAdos futuros. ModelAn lA vAriAción de los fActores y proporcio-
nAn visión del rAngo esperAdo y vAriAción de los resultAdos pronosticAdos. Un
modelo de rendimiento de proceso puede ser unA colección de modelos que (cuAn-
do se combinAn) sAtisfAcen los criterios de un modelo de rendimiento de proceso.
Nivel de capacidad (capability level) Logro en la mejora de pro-
cesos dentro de un área de proceso individual (véase también
“meta genérica”, “meta específica”, “nivel de madurez” y “área de
proceso”).
Un nivel de CAPACIDAD se define MEDIANTE LAS METAS GENÉRICAS y ESPECÍFICAS
APROPIADAS PARA un árEA de proceso.
Nivel de madurez (maturity level) Nivel de la mejora de procesos
en un conjunto predefinido de áreas de proceso en las que se
alcanzan todas las metas de ese conjunto (véase también “nivel de
capacidad” y “área de proceso”).
Nivel de servicio (service level) Una magnitud, grado o calidad de-
finidos del rendimiento de la entrega del servicio (véase también
“servicio” y “medida del nivel de servicio”).
Nivel directivo (higher level management) La persona o
personas que proporcionan la política y la orientación global para
el proceso, pero que no proporcionan la monitorización ni el
control del proceso directo del día a día (véase también
“director”).
ESTAS PERSONAS pertenecen A un nivel de gestión en LA ORGANIZACIÓN por ENCIMA
del rESPONSABLE del nivel INMEDIATO de proceso y pueden ser (pero no NECESA-
RIAMENTE) directores.
Objetivo cuantitativo (quantitative objective) Valor objetivo
deseado expresado utilizando medidas cuantitativas (véase
también “medida”, “objetivos de mejora de procesos” y “objetivos
de calidad y de rendimiento de proceso”).
Objetivos de calidad y de rendimiento de proceso (quality and pro-
cess performance objectives) Objetivos cuantitativos y
requisitos de la calidad del producto, de la calidad del servicio y
del rendimiento de proceso.
Los objetivos CUANTITATIVOS de rendimiento de proceso incluyen LA CALIDAD; sin
EMBARgo, PARA DAR ÉNFASIS A LA IMPORTANCIA de LA CALIDAD en el conjunto de
productos CMMI, se USA LA FRASE “objetivos de CALIDAD y de rendimiento de
proceso”. Los “objetivos de rendimiento de proceso” se referENCIAN en el nivel
de MADURez 3; el término “objetivos de CALIDAD y de rendimiento de proceso”
IMPLICA el uso de DATOS CUANTITATIVOS y se USA SOLAMENTE en los niveles de MA-
durez 4 y 5.
Objetivos de mejora de procesos (process improvement objecti-
ves) Un conjunto de características objetivo establecidas para
guiar el esfuerzo para mejorar un proceso existente, de manera
es- pecífica y medible, tanto en términos de características del
produc- to o servicio resultantes (p. ej., calidad, rendimiento
del producto, conformidad con los estándares) como en la
manera en la que se ejecuta el proceso (p. ej., eliminación de
pasos redundantes del proceso, combinación de pasos de
proceso, mejora del tiempo de ciclo) (véase también “objetivos de
negocio de la organización” y “objetivo cuantitativo”).
Objetivos de negocio (business objectives) Véase “objetivos de ne-
gocio de la organización”.
Objetivos de negocio de la organización (organization’s business ob-
jectives) Objetivos desarrollados por la dirección diseñados para
asegurar la existencia continuada de la organización y aumentar
su rentabilidad, la cuota de mercado y otros factores que influyen
en el éxito de la organización (véase también “objetivos de
calidad y de rendimiento del proceso” y “objetivo cuantitativo”).
Organización (organization) Una estructura administrativa en la
que el personal gestiona de forma conjunta uno o más
proyectos o grupos de trabajo como un todo, comparten un
director y operan bajo las mismas políticas.
Sin EMBARgo, LA PALABRA “orGANIZACIÓN” TAL y como se UTILIZA en todos los mo-
delos CMMI, TAMBIÉN se puede APLICAR A UNA PERSONA que rEALIZA UNA función
en UNA ORGANIZACIÓN PEQUEÑA y que en UNA ORGANIZACIÓN GRANDE PODRÍA SER
rEALIZADA por un grupo de PERSONAS (VÉASE TAMBIÉN “emprESA”).
Paquete de datos técnicos (technical data package) Una colección
de elementos que pueden incluir los elementos de la lista
siguiente si esa información es adecuada para el tipo de
producto y componente de producto (p. ej., los requisitos de
materiales y de fabricación pueden no ser útiles para los
componentes de producto asociados con los servicios o
procesos de software):
• Descripción de LA ARQUITECTURA de producto.
• Requisitos ASIGNADOS.
• Descripciones de componente de producto.
• Descripciones de procesos del ciclo de VIDA rELATIVOS AL producto si no están
DESCRITAS como componentes de producto independientes.
• CARACTERÍSTICAS CLAVE de producto.
• CARACTERÍSTICAS y LIMITACIONES FÍSICAS rEQUERIDAS.
• Requisitos de InterFAZ.
• Requisitos de MATERIALES (FACTURAS de MATERIAL y CARACTERÍSTICAS del MATERIAL).
• Requisitos de FABRICACIÓN y de producción (TANTO PARA el FABRICANTE ORIGINAL
del EQUIPAMIENTO como PARA el de APOYO sobre el terreno).
• Criterios de VERIFICACIÓN UTILIZADOS PARA ASEGURAR que se HAN cumplido los
requisitos.
• Condiciones de uso (entornos) y ESCENARIOS de OPERACIÓN/USO, modos y ESTA-
dos PARA OPERACIONES, soporte, FORMACIÓN, FABRICACIÓN, rETIRADA y VERIFICACIO-
nes A lo LARgo de LA VIDA del producto.
• RAZÓN PARA LAS decisiones y LAS CARACTERÍSTICAS (p. ej., requisitos, ASIGNACIO-
nes de requisitos, elecciones de diseño).
Paquete de solicitación (solicitation package) Una colección de
documentos formales que incluye una descripción de la forma
de respuesta que se desea de un proveedor potencial, la
declaración de trabajo relevante para el proveedor y las
disposiciones requeridas en el acuerdo con el proveedor.
Parámetros de rendimiento (performance parameters) Las medidas
de eficacia y otras medidas clave que se utilizan para guiar y
controlar el desarrollo progresivo.
Parte interesada (stakeholder) Un grupo o individuo que se ve afec-
tado por o es de alguna manera responsable del resultado de una
empresa (véase también “cliente” y “parte interesada relevante”).
LAS PARTES interESADAS pueden incluir miembros de un proyecto o grupo de
TRABAJO, proveedores, clientes, USUARIOS FINALES y otros.
Parte interesada relevante (relevant stakeholder) Una parte intere-
sada que se identifica por su involucración en actividades
especificadas y que se incluye en un plan (véase también “parte
interesada”).
Participantes en la evaluación (appraisal participants) Miembros de
la unidad organizativa que participan proporcionando información
durante una evaluación.
Perfil alcanzado (achievement profile) Una lista de áreas de
proceso y sus correspondientes niveles de capacidad, que
representan el progreso de la organización en cada área de
proceso según avanza a través de los niveles de capacidad
(véase también “perfil de nivel de capacidad”, “perfil objetivo” y
“representación por objetivos”).
Perfil de nivel de capacidad (capability level profile) Una lista de áreas
de proceso y sus correspondientes niveles de capacidad (véase
también “perfil alcanzado”, “perfil objetivo” y “representación por
objetivos”).
Un perfil de nivel de CAPACIDAD puede ser un “perfil ALCANZADO” CUANDO repre-
SENTA el progreso de LA ORGANIZACIÓN PARA CADA árEA de proceso A MEDIDA que
AVANZA A TRAVÉS de los niveles de CAPACIDAD. O, el perfil puede ser un “perfil
objetivo” CUANDO reprESENTA un objetivo PARA LA MEJORA de procesos.
Perfil objetivo (target profile) Una lista de áreas de proceso y sus
niveles de capacidad correspondientes que representan un
objetivo de mejora de procesos (véase también “perfil alcanzado” y
“perfil de nivel de capacidad”).
Los perfiles objetivo están disponibles SOLAMENTE CUANDO se USA LA reprESENTA-
ción CONTINUA.
Petición de servicio (service request) Una comunicación por
parte de un cliente o un usuario final indicando que se desean una
o más instancias específicas de entrega de servicio (véase también
“acuerdo de servicio”).
ESTAS peticiones se ESTABLECEN dentro del contexto de un ACUERdo de servicio.
En los CASOS en que los servicios se entrEGAN CONTINUA O PERIÓDICAMENTE, AL-
GUNAS peticiones de servicio pueden IDENTIFICARSE EXPLÍCITAMENTE en el mismo
ACUERdo de servicio.
En otros CASOS, LAS peticiones de servicio que ENTRAN en el ALCANCE de un ACUERdo
de servicio ESTABLECIDO prEVIAMENTE, se GENERAN con el tiempo por los clientes o
USUARIOS FINALES según se DESARrOLLAN sus NECESIDADES.
Plan de acción de proceso (process action plan) Un plan, gene-
ralmente resultado de evaluaciones, que documenta cómo serán
implementadas las mejoras específicas dirigidas a las debilidades
detectadas mediante una evaluación.
Plan de mejora de procesos (process improvement plan) Un
plan para alcanzar los objetivos de mejora de procesos de la
organización basándose en una comprensión concienzuda de las
fortalezas y las debilidades actuales de sus procesos y de sus
activos de proceso.
Plan de proyecto (project plan) Un plan que proporciona la
base para realizar y controlar las actividades del proyecto, que
abarcan los compromisos con el cliente del proyecto.
LA PLANIFICACIÓN del proyecto incluye ESTIMAR los ATRIBUTOS de los productos
de TRABAJO y de LAS TAREAS, DETERMINAR los recursos NECESARIOS, NEGOCIAR los
compromisos, ELABORAR un CALENDARIO, e IDENTIFICAR y ANALIZAR los riesgos del
proyecto. Puede ser NECESARIA LA ITERACIÓN entre ESTAS ACTIVIDADES PARA ESTABLE-
cer el PLAN de proyecto.
Plan de trabajo (work plan) Un plan de actividades y asignaciones
de recursos relacionadas para un grupo de trabajo.
LA PLANIFICACIÓN del TRABAJO incluye ESTIMAR los ATRIBUTOS de los productos de
TRABAJO y de LAS TAREAS, DETERMINAR los recursos NECESARIOS, NEGOCIAR los com-
promisos, producir un CALENDARIO, e IDENTIFICAR y ANALIZAR los riesgos. LA ITERA-
ción en ESTAS ACTIVIDADES puede ser NECESARIA PARA ESTABLECER el PLAN de TRABAJO.
Política (policy) Véase “política de la organización”.
Política de la organización (organizational policy) Los
principios rectores establecidos normalmente por la alta dirección
que se adoptan por la organización para influenciar y adoptar
decisiones.
Práctica específica (specific practice) Un componente esperado
del modelo que se considera importante para alcanzar la meta
específi- ca asociada (véase también “área de proceso” y “meta
específica”).
LAS PRÁCTICAS ESPECÍFICAS describen LAS ACTIVIDADES ESPERADAS PARA DAR como
rESULTADO el logro de LAS METAS ESPECÍFICAS de un árEA de proceso.
Práctica genérica (generic practice) Un componente esperado
del modelo que se considera importante para alcanzar las metas
gené- ricas asociadas.
LAS PRÁCTICAS GENÉRICAS ASOCIADAS con UNA META GENÉRICA describen LAS ACTIVI-
DADES que se ESPERA den como rESULTADO LA consecución de LA META GENÉRICA que
contribuyen A LA INSTITUCIONALIZACIÓN de los procesos ASOCIADOS con un árEA de
proceso.
Prestación técnica (technical performance) Característica del
proceso, producto o servicio, generalmente definida por un
requisito funcional o técnico.
Algunos ejemplos de tipos de prESTACIÓN TÉCNICA SON LA precisión en LA ESTIMA-
ción, LAS funciones de USUARIO FINAL, LAS funciones de SEGURIDAD, el tiempo de
rESPUESTA, LA precisión del componente, el peso máximo, LA CAPACIDAD de pro-
ducción MÍNIMA, el RANGO permisible.
Proceso (process) Un conjunto de actividades interrelacionadas,
que transforman entradas en salidas, para alcanzar un propósito
dado (véa- se también “área de proceso”, “subproceso” y “elemento de
proceso”).
HAy un uso especiAl de lA frASe “el proceso” en lAS declArAciones y descripciones
de lAS metAS genéricAS y lAS prácticAS genéricAS. “El proceso”, tAl y como se utilizA
en lA SegundA PArte, es el proceso o procesos que implementAn el áreA de proceso.
Los términos “proceso”, “subproceso” y “elemento de proceso” FORMAN UNA je-
RARQUÍA SIENDO “proceso” el término más GENERAL y de MAYOR nivel, “los subpro-
cesos” por DEBAJO de él y “elemento de proceso” como el más específico. Un
proceso PARTICULAR se puede DENOMINAR subproceso si es PARTE de un proceso
más GRANDE. TAMBIÉN se puede DENOMINAR elemento de proceso si no se des-
compone en subprocesos.
ESTA definición de proceso es consistente con LA definición de proceso en ISO
9000, ISO 12207, ISO 15504 y EIA 731.
Proceso capaz (capable process) Un proceso que puede satisfacer
sus objetivos especificados de calidad de producto, de calidad de
servicio y de rendimiento de proceso (véase también “proceso
estable” y “proceso estándar”).
Proceso de evaluación formal (formal evaluation process)
Una aproximación estructurada para evaluar las soluciones
alternativas frente a los criterios establecidos con el fin de
determinar una solu- ción recomendada para tratar una cuestión.
Proceso definido (defined process) Un proceso gestionado que
se ha adaptado a partir del conjunto de procesos estándar de la
orga- nización de acuerdo a las guías de adaptación de la
organización; tiene una descripción de proceso que se mantiene; y
contribuye a los activos de proceso de la organización con
experiencias relativas al proceso (véase también “proceso
gestionado”).
Proceso estable (stable process) El estado en el que se han
eliminado las causas especiales de variación de proceso y se ha
prevenido su reaparición de forma que sólo permanezcan las
causas comunes de variación de proceso (véase también “proceso
capaz”, “causa común de variación”, “causa especial de variación”, y
“proceso estándar”).
Proceso estándar (standard process) Una definición operativa
del proceso básico que guía el establecimiento de un proceso
común en una organización.
Un proceso ESTÁNDAR describe los elementos de proceso FUNDAMENTALES que se
ESPERA que se incorporen en CUALQUIER proceso definido. TAMBIÉN describe LAS
rELACIONES (p. ej., orDENACIÓN, interFACES) entre estos elementos de proceso (VÉA-
se TAMBIÉN “proceso definido”).
Proceso gestionado (managed process) Un proceso realizado que
se planifica y ejecuta de acuerdo con la política; emplea personas
con habilidades que disponen de los recursos adecuados para
producir salidas controladas; involucra a las partes interesadas
relevantes; se monitoriza, se controla y se revisa, y se evalúa para
determinar su adherencia a su descripción de proceso (véase
también “proceso realizado”).
Proceso incompleto (incomplete process) Un proceso que no se
realiza o que se realiza sólo parcialmente; una o más de las
metas espe- cíficas del área de proceso no se satisfacen.
Un proceso incompleto se conoce TAMBIÉN como de nivel de CAPACIDAD 0.
Proceso planificado (planned process) Un proceso que está
documentado tanto por una descripción como por un plan.
LA descripción y el PLAN DEBERÍAN ESTAR coorDINADOS, y el PLAN DEBERÍA incluir
ESTÁNDARes, requisitos, objetivos, recursos y ASIGNACIONES.
Proceso realizado (performed process) Un proceso que realiza el
trabajo necesario para producir productos de trabajo; se satisfacen
las metas específicas del área de proceso.
Procesos de ciclo de vida relativos al producto (product related life-
cycle processes) Procesos asociados con un producto o servicio
durante una o más fases de su vida (p. ej., desde su concepción
hasta su retirada), tales como los procesos de fabricación y de
soporte.
Producto (product) Un producto de trabajo que está previsto
entregar a un cliente o usuario final.
ADEMÁS de su SIGNIFICADO USUAL. LA FORMA de un producto puede VARIAR según
el contexto (VÉASE TAMBIÉN “cliente”, “componente de producto”, “servicio” y
“producto de TRABAJO”).
Producto de trabajo (work product) Un resultado útil de un
proceso. Este rESULTADO puede incluir ficheros, documentos, productos, PARTES
de un producto, servicios, descripciones de proceso, ESPECIFICACIONES y
FACTURAS. UNA di- ferENCIA CLAVE entre un producto de TRABAJO y un componente
de producto es que un producto de TRABAJO no es NECESARIAMENTE PARTE del
producto FINAL (VÉASE TAMBIÉN “producto” y “componente de producto”).
En los modelos CMMI, LA definición de “producto de TRABAJO” incluye los ser-
vicios, sin EMBARgo, LA FRASE “productos de TRABAJO y servicios” se USA A veces
PARA ENFATIZAR LA inclusión de los servicios en LA discusión.
Productos comerciales (COTS, commercial off-the-shelf)
Elemen- tos que se pueden comprar a un proveedor comercial.
Progreso y rendimiento del proyecto (project progress and performan-
ce) Lo que un proyecto logra con respecto a la implementación de
los planes de proyecto, incluyendo esfuerzo, coste, calendario y
rendimiento técnico (véase también “rendimiento técnico”).
Propietario del proceso (process owner) La persona (o equipo)
responsable de definir y mantener un proceso.
A nivel de LA ORGANIZACIÓN, el prOPIETARIO del proceso es LA PERSONA (o equipo)
rESPONSABLE de LA descripción de un proceso ESTÁNDAR; A nivel de proyecto o
de grupo de TRABAJO, el prOPIETARIO del proceso es LA PERSONA (o equipo) res-
PONSABLE de LA descripción del proceso definido. Por TANTO, un proceso puede
tener VARIOS prOPIETARIOS A diferentes niveles de rESPONSABILIDAD (VÉASE TAMBIÉN
“proceso definido” y “proceso ESTÁNDAR”).
Prototipo (prototype) Un tipo, forma o instancia preliminar de
un producto, servicio, componente de producto o de servicio
que sirve como modelo para etapas posteriores o para la
versión final y completa del producto o servicio.
Este modelo del producto o servicio (p. ej., físico, electrónico, DIGITAL, ANA-
lítico) puede UTILIZARSE entre otros, PARA los siguientes propósitos:
• EVALUACIÓN de LA VIABILIDAD de UNA TECNOLOGÍA NUEVA O no FAMILIAR.
• EVALUACIÓN o MITIGACIÓN de un riesgo técnico.
• VALIDACIÓN de los requisitos.
• DEMOSTRACIÓN de CARACTERÍSTICAS CRÍTICAS.
• CUALIFICACIÓN de un producto o servicio.
• CUALIFICACIÓN de un proceso.
• CARACTERIZACIÓN del rendimiento o de LAS CARACTERÍSTICAS del producto
o servicio.
• EXPLICACIón de principios físicos.
Proveedor (supplier) (1) Una entidad que entrega productos o
realiza servicios que han sido adquiridos. (2) Un individuo,
sociedad, empresa, corporación, asociación u otra entidad que
tiene un acuerdo con un comprador para el diseño, el
desarrollo, la fabricación, el mantenimiento, la modificación o
el suministro de elementos bajo los términos de un acuerdo
(véase también “comprador”).
Proyecto (project) Un conjunto gestionado de actividades y
recursos interrelacionados, incluyendo personal, que entrega
uno o más productos o servicios a un cliente o a un usuario
final.
Un proyecto tiene un comienzo previsto (es decir, el ARRANQUE del proyecto) y
un FINAL. Los proyectos OPERAN NORMALMENTE de ACUERdo A un PLAN. Dicho PLAN
frecuentemente está DOCUMENTADO y ESPECIFICA qué es lo que se VA A entrEGAR o
IMPLEMENTAR, los recursos y LA FINANCIACIÓN que VAN A UTILIZARSE, el TRABAJO que
se VA A rEALIZAR y el CALENDARIO PARA HACER el TRABAJO. Un proyecto puede ESTAR
compuesto de VARIOS proyectos (VÉASE TAMBIÉN “ARRANQUE del proyecto”).
En Algunos contextos, el término “progrAmA” se utilizA pArA referirse A un proyecto.
Prueba unitaria (unit testing) Prueba de unidades individuales
de hardware o de software o de grupos de unidades relacionadas
(véase también “prueba de aceptación”).
Pruebas de aceptación (acceptance testing) Pruebas formales
llevadas a cabo para permitir a un usuario, a un cliente o a
otra entidad autorizada, determinar si acepta un entregable
(véase también “pruebas unitarias”).
Rendimiento de proceso (process performance) Una medida de
los resultados alcanzados al seguir un proceso (véase también
“medida”).
El rendimiento de proceso se cArActerizA tAnto por lAS medidAS de proceso
(p. ej., esfuerzo, tiempo de ciclo, EFICIENCIA en LA ELIMINACIÓN de defectos) como
por MEDIDAS de producto o servicio (por ejemplo, FIABILIDAD, DENSIDAD de defec-
tos, tiempo de rESPUESTA).
Repositorio de medición de la organización (organization’s measu-

rement repository) Un repositorio utilizado para recoger y
poner disponibles resultados de medición de los procesos y de los
productos de trabajo, en particular de aquellos que están
relacionados con el conjunto de procesos estándar de la
organización.
Este repositorio contiene o HACE referENCIA A los rESULTADOS de LAS mediciones
rEALES y LA INFORMACIÓN rELACIONADA NECESARIA PARA comprender y ANALIZAR los
rESULTADOS de LAS mediciones.
Representación (representation) La organización, uso y
presenta- ción de los componentes de CMMI.
En GENERAL, son evidentes dos tipos de APROXIMACIONES PARA prESENTAR LAS bue-
NAS PRÁCTICAS: LA reprESENTACIÓN por ETAPAS y LA reprESENTACIÓN CONTINUA.
Representación continua (continuous representation) Una estructura
del modelo de capacidad y de madurez, donde los niveles de
capacidad proporcionan un orden recomendado para abordar la
mejora de procesos dentro de cada área de proceso especificada
(véase también “nivel de capacidad”, “área de proceso” y
“representación por etapas”).
Representación equivalente (equivalent staging) Una representación
por objetivos, creada utilizando la representación continua, que se
define de forma que los resultados de utilizar la representación por
objetivos se puedan comparar con los niveles de madurez de la repre-
sentación por etapas (véase también “perfil de nivel de capacidad”,
“nivel de madurez”, “perfil objetivo” y “representación por
objetivos”).
DICHA reprESENTACIÓN permite UNA COMPARATIVA del progreso entre orGANIZACIO-
nes, emprESAS, proyectos y grupos de TRABAJO, sin IMPORTAR LA reprESENTACIÓN de
CMMI UTILIZADA. LA ORGANIZACIÓN puede IMPLEMENTAR componentes de modelos
CMMI, más ALLÁ de AQUELLOS que son el objeto de LA reprESENTACIÓN EQUIVALENTE.
LA reprESENTACIÓN EQUIVALENTE rELACIONA como LA ORGANIZACIÓN se COMPARA con
OTRAS ORGANIZACIONES en términos de niveles de MADURez.
Representación por etapas (staged representation) Una estructura
del modelo en la que el alcance de las metas de un conjunto de
áreas de proceso establece un nivel de madurez; cada nivel
construye una base para los niveles siguientes (véase también
“nivel de madurez” y “área de proceso”).
Representación por objetivos (target staging) Una secuencia de
perfiles objetivo que describe el camino de mejora de procesos a
seguir por la organización (véase también “perfil alcanzado”, “perfil
de nivel de capacidad” y “perfil objetivo”).
LA reprESENTACIÓN por objetivos sólo está disponible CUANDO se UTILIZA LA repre-
SENTACIÓN CONTINUA.
Requisito (requirement) (1) Una condición o capacidad
necesi- tada por un usuario para solucionar un problema o
lograr un objetivo. (2) Una condición o capacidad que debe
cumplir o poseer un producto, servicio, componente de
producto o componente de servicio para satisfacer un acuerdo
de proveedor, un estándar, una especificación u otros
documentos impuestos formalmente. (3) Una
representación documentada de una condición o capacidad
como en (1) o en (2) (véase también “acuerdo con el
proveedor”).
Requisito asignado (allocated requirement) Requisito que resulta
de la imposición de todo o parte de un requisito de nivel superior
a un elemento de la arquitectura o componente de diseño de nivel
inferior.
En términos GENERALES, los requisitos pueden ser ASIGNADOS A OTRos componen-
tes lógicos o físicos, incluyendo PERSONAL, consumibles, incrementos de entrEGA
o LA ARQUITECTURA como un todo, dependiendo de lo que mejor PERMITA AL pro-
ducto o servicio ALCANZAR los requisitos.
Requisito de cliente (customer requirement) El resultado de
educir, consolidar y resolver los conflictos entre las necesidades,
las expectativas, las restricciones y las interfaces de las partes
interesadas relevantes del producto, de forma que sea aceptable
para el cliente (véase también “cliente”).
Requisitos contractuales (contractual requirements) Conjunto de
requisitos adecuados para incluir en uno o más paquetes de
solicitación o acuerdos con proveedores obtenidos a partir del análisis
y refinamiento de los requisitos del cliente (véase también
“comprador”, “requisitos del cliente”, “acuerdos con el proveedor” y
“paquete de solicitación”).
Los requisitos CONTRACTUALES incluyen TANTO los requisitos técnicos como los no
técnicos NECESARIOS PARA LA ADQUISICIÓN de un producto o servicio.
Requisitos de componente de producto (product component requi-
rements) Una especificación completa de un componente de pro-
ducto o de servicio, incluyendo el ajuste, la forma, la función, el
rendimiento y cualquier otro requisito.
Requisitos de producto (product requirements) Un refinamiento de
los requisitos de cliente en el lenguaje de los desarrolladores,
transformando los requisitos implícitos en requisitos derivados
explícitos (véase tam- bién “requisitos derivados” y “requisitos de
componente de producto”).
El DESARrOLLADOR UTILIZA los requisitos de producto PARA GUIAR el diseño y LA
construcción del producto o servicio.
Requisitos de servicio (service requirements) El conjunto
completo de requisitos que afectan a la entrega de servicio y al
desarrollo del sistema de servicio (véase también “sistema de
servicio”).
Los requisitos de servicio incluyen TANTO los requisitos técnicos como los no
técnicos. Los requisitos técnicos son CARACTERÍSTICAS del servicio A entrEGAR y
del SISTEMA de servicio NECESITADO PARA permitir LA entrEGA. Los requisitos no
técnicos pueden incluir condiciones ADICIONALES, disposiciones, compromisos y
términos IDENTIFICADOS por los ACUERdos, y rEGULACIONES, ASÍ como CAPACIDADES
y condiciones NECESARIAS DERIVADAS de los objetivos del negocio.
Requisitos derivados (derived requirements) Requisitos que no
es- tán explícitamente establecidos en los requisitos de cliente,
pero se derivan (1) de los requisitos contextuales (p. ej.,
estándares aplicables, leyes, políticas, prácticas comunes,
decisiones de la gerencia)
o (2) de los requisitos necesarios para especificar un
componente de producto o servicio.
Los requisitos derivAdos pueden surgir tAmbién durAnte el Análisis y el diseño de los
componentes del producto o del servicio (véASe tAmbién “requisitos de producto”).
Requisitos no técnicos (nontechnical requirements)
Requisitos
que
afectan a la adquisición o al desarrollo de un producto o
servicio
que no son propiedades del producto o servicio.
Algunos ejemplos son el número de productos o servicios que vAn A Ser entregA-
dos, los derechos de los dAtos de los COTS entregAdos y de los elementos no desA-
rrollAdos en el proyecto entregAdos, lAS fechAS de entregA y los hitos con criterios
de sAlidA. Otros requisitos no técnicos incluyen restricciones de trAbAjo ASOciAdAS
con lA formAción, provisiones de espAcio y cAlendArios de despliegue.
Requisitos técnicos (technical requirements) Propiedades (es
decir, atributos) de productos o servicios a adquirir o desarrollar.
Resultado de la medición (measurement result) Un valor
determinado resultado de realizar una medición (véase también
“medición”). Retorno de la inversión (return on investment) La
proporción entre
los beneficios obtenidos (de un producto o servicio) y los
costes de producción, que determina si una organización se
beneficia de la realización de una acción para producir algo.
Revisión de diseño (design review) Un examen formal,
documentado, exhaustivo y sistemático de un diseño para
determinar si el diseño cumple los requisitos aplicables, para
identificar problemas y para proponer soluciones.
Revisión entre pares (peer review) La revisión de los productos
de trabajo realizada por compañeros del mismo nivel que los
autores durante el desarrollo de los productos de trabajo para
identificar defectos a eliminar (véase también “producto de
trabajo”).
El término “revisión entre PARes” se UTILIZA en el Conjunto de Productos CMMI
en LUGAR del término “inspección del producto de TRABAJO”.
Servicio (service) Un producto que es intangible y no almacenable
(véase también “producto”, “cliente” y “producto de trabajo”).
Los servicios se entrEGAN A TRAVÉS de LA UTILIZACIÓN de los SISTEMAS de servicio
que se HAN DISEÑADO PARA SATISFACER los requisitos de servicio (VÉASE TAMBIÉN
“SISTEMA de servicio”).
Muchos proveedores de servicio entrEGAN COMBINACIONES de servicios y merCAN-
CÍAS. Un único SISTEMA de servicio puede entrEGAR AMBOS tipos de productos.
Por ejemplo, UNA ORGANIZACIÓN de FORMACIÓN puede entrEGAR MATERIALES de for-
MACIÓN junto con sus servicios de FORMACIÓN.
Los servicios pueden entrEGARSE A TRAVÉS de COMBINACIONES de procesos MANUA-
les y AUTOMATIZADOS.
Sistema de servicio (service system) Una combinación
integrada e interdependiente de recursos de componentes que
satisface los
requisitos de servicio (véase también “componente de sistema de
servicio” y “requisitos de servicio”).
Un SISTEMA de servicio comprende todo lo requerido PARA LA entrEGA de servicio,
incluyendo productos de TRABAJO, procesos, INSTALACIONES, herRAMIENTAS, consu-
mibles y recursos HUMANOS.
Observe que un sistemA de servicio incluye el personAl necesArio pArA reAlizAr los
procesos del sistemA de servicio. En contextos donde los usuArios finAles reAlizAn
Algunos procesos pArA que se cumplA lA entregA de servicio, esos usuArios finAles
son tAmbién pArte del sistemA de servicio (Al menos durAnte dichAS interAcciones).
Un SISTEMA de servicio complejo puede dividirse en múltiples SISTEMAS O SUBSIS-
TEMAS de entrEGA y soporte. Aunque ESTAS divisiones y distinciones PUEDAN ser
SIGNIFICATIVAS PARA LA ORGANIZACIÓN prOVEEDORA del servicio, pueden no ser TAN
SIGNIFICATIVAS PARA OTRAS PARTES interESADAS.
Sistema de sistemas (system of systems) Un conjunto u
ordenación de sistemas que resulta cuando sistemas útiles e
independientes se integran en un gran sistema que entrega
capacidades únicas.
Solicitación (solicitation) El proceso consistente en preparar un
paquete para usarse en la selección de un proveedor (véase
también “paquete de solicitación”).
Soporte (sustainment) Los procesos utilizados para asegurar que
un producto o servicio permanece operativo.
Subcontratación (outsourcing) Véase “adquisición”.
Subpráctica (subpractice) Un componente informativo del
modelo que proporciona orientación para interpretar e
implementar las prácticas específicas o genéricas.
LAS SubprácticAS pueden redActArse como si fuerAn preceptivAS, pero reAlmente sólo
pretenden proporcionAr ideAS que puedAn ser útiles pArA lA mejorA de procesos.
Subproceso (subprocess) Un proceso que es parte de un proceso
mayor (véase también “proceso”, “descripción de proceso” y
“elemen- to de proceso”).
A su vez un subproceso puede o no descomponerse en subprocesos o elementos
de proceso más GRANULARes. Los términos “proceso”, “subproceso” y “elemento
de proceso” FORMAN UNA JERARQUÍA, siendo “proceso” el término más GENERAL y
de nivel más ALTO, los “subprocesos” por DEBAJO de él y los “elementos de pro-
ceso” los más específicos. Un subproceso TAMBIÉN puede DENOMINARSE elemento
de proceso si no se descompone en nuevos subprocesos.
Técnicas estadísticas (statistical techniques) Técnicas adaptadas
a partir del campo de la estadística matemática utilizadas para
actividades como la caracterización del rendimiento del
proceso, la com- prensión de la variación del proceso y la
predicción de resultados.
Algunos ejemplos de técnicAS estAdísticAS SOn lAS técnicAS de muestreo, el Análisis
de vAriAnzA, los contrAStes chi-cuAdrAdo y los diAgrAmAS de control de proceso.
Técnicas estadísticas y otras técnicas cuantitativas (statistical and
other quantitative techniques) Técnicas analíticas que
permiten llevar a cabo una actividad cuantificando los
parámetros de la tarea
(p. ej., entradas, tamaño, esfuerzo y rendimiento) (véase también
“técnicas estadísticas” y “gestión cuantitativa”).
Este término es utilizAdo en lAS áreAS de proceso de AltA mAdurez donde se descri-
be el uso de técnicAS estAdísticAS y de otrAS técnicAS cuAntitAtivAS pArA mejorAr
lA comprensión del proyecto, del trAbAjo y de los procesos de lA OrgAnizAción.
Algunos ejemplos de TÉCNICAS CUANTITATIVAS no ESTADÍSTICAS SON el ANÁLISIS de
TENDENCIAS, los run CHARTS, el ANÁLISIS de PAReto, los DIAGRAMAS de BARRAS, los
DIAGRAMAS RADAR y el promedio de DATOS.
LA RAZÓN de UTILIZAR el término compuesto “TÉCNICAS ESTADÍSTICAS y OTRAS téc-
NICAS CUANTITATIVAS” en CMMI es PARA reconocer que AUNQUE se ESPERA que se
utilicen TÉCNICAS ESTADÍSTICAS, TAMBIÉN pueden UTILIZARSE OTRAS TÉCNICAS CUANTI-
TATIVAS de FORMA EFICAZ.
Trazabilidad (traceability) Una asociación discernible entre
dos o más entidades lógicas, tales como requisitos, elementos
del sistema, verificaciones o tareas (véase también “trazabilidad
bidireccional” y “trazabilidad de requisitos”).
Trazabilidad bidireccional (bidirectional traceability) Una
asocia- ción entre dos o más entidades lógicas que es discernible
en ambos sentidos (es decir, hacia y desde una entidad) (véase
también “trazabilidad de requisitos” y “trazabilidad”).
Trazabilidad de requisitos (requirements traceability) Una asocia-
ción discernible entre los requisitos y los requisitos relacionados,
las implementaciones relacionadas y las verificaciones
relacionadas (véase también “trazabilidad bidireccional” y
“trazabilidad”).
Usuario final (end user) La parte que finalmente utiliza un
producto entregado o que recibe el beneficio de un servicio
entregado (véase también “cliente”).
Los USUARIOS FINALES pueden o no ser TAMBIÉN clientes (quienes pueden ESTABLE-
cer y ACEPTAR ACUERdos o AUTORIZAR PAGOS).
En contextos en los que un único Acuerdo de servicio cubre múltiples entregAS de
servicio, cuAlquier pArte que iniciA unA petición de servicio se puede considerAr
usuArio finAl (véASe tAmbién “Acuerdo de servicio” y “petición de servicio”).
Validación (validation) Confirmación de que el producto o
servicio, tal y como se ha proporcionado (o será
proporcionado), cumplirá su uso deseado.
En OTRAS PALABRAS, LA VALIDACIÓN ASEGURA que “construyó lo correcto” (VÉASE
TAMBIÉN “VERIFICACIÓN”).
Verificación (verification) Confirmación de que los productos de
trabajo reflejan adecuadamente los requisitos que se han
especificado para ellos.
En OTRAS PALABRAS, LA VERIFICACIÓN ASEGURA que “lo construyó corrECTAMENTE”
(VÉASE TAMBIÉN “VALIDACIÓN”).
Visión compartida (shared vision) Una comprensión común
de principios de orientación, incluyendo la misión, los
objetivos, el comportamiento esperado, los valores y los
resultados finales, que se desarrollan y utilizan por un proyecto
o grupo de trabajo.

CMMI For Development v1-3 Spanish

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CMMI For Development v1-3 Spanish

Uploaded by

Copyright:

Available Formats

CMMI® para Desarrollo, Versión 1.

Equipo del Producto CMMI

Mejora de los procesos para el desarrollo de mejores productos y

Software Engineering Process Management Program

Libro publicado por Editorial Universitaria Ramón Areces, en donde

primera parte: aCerCa de CMMi para desarroLLo 1

4 rELACIOnES EntrE árEAS dE PrOCESO 59

áreas de proceso avanzadas de Gestión de Procesos 62

5 utILIzAndO LOS MOdELOS CMMI 85

segunda parte: Metas GenÉriCas Y prÁCtiCas GenÉriCas,

MEtAS GEnérICAS y PráCtICAS GEnérICAS 165

tercera parte: apÉndiCes 553

APéndICE A: rEFErEnCIAS 555

Los modelos CMMI® (Capability Maturity Model® Integration)

desarrollo para adaptar CMMI para su uso en el desarrollo de

organización de este documento

• Primera Parte: Acerca de CMMI para Desarrollo.

3. Una evaluación es un examen de uno o más procesos realizada por un equipo de

La Segunda Parte contiene 23 secciones. La primera sección

Como usar este documento

Lectores que se inician en la mejora de procesos

Lectores con experiencia en mejora de procesos

Lectores familiarizados con CMMi

Causal y Resolución, Gestión Cuantitativa del Proyecto,

información adicional y sugerencias del lector

La Cátedra de Mejora de Procesos Software en el Espacio Ibero-

Accenture es una compañía global de consultoría de gestión,

Informática El Corte Inglés es uno de los principales proveedores

Nuevamente everis participa como patrocinador en la traducción

El Instituto Nacional de Tecnologías de la Comunicación, INTECO,

Para más información: www.inteco.es

El Centro de Investigación en Matemáticas, A.C., que ha

Para más información: www.cimat.mx

Después de haber llevado a cabo la traducción al español del

Equipo Coordinador de la traducción

La publicación en español de la edición revisada 1.3 de “CMMI®

Víctor M. Izquierdo LOYOLA

acerca de Cmmi para

Ahora más que nunca, las compañías desean entregar mejores

El énfasis está en el trabajo necesario para construir y

acerca de la mejora de procesos

por WATTS Humphrey

acerca de los modelos de madurez y de capacidad

evolución del Cmmi

CMM for Software Systems Engineering

CMMI for Development

CMMI for Acquisition CMMI for Development CMMI for Services

A la vez que se publicó la versión 1.2, otros dos modelos

2. EIA 731 SECM es el estándar de “Electronic Industries Alliance” o el Systems

Cmmi: Continúa la integración y mejora

por Bob RASSA

la arquitectura del marco Cmmi

por Roger BATE

Cmmi para Desarrollo

Componentes del área de proCeso

En este capítulo se describen los componentes que se encuentran

áreas de proceso base y los modelos CmmI

Componentes requeridos, esperados e informativos

organización. Los componentes requeridos en CMMI son las

Componentes asociados con la segunda parte

*** Inicio Página 21

Las 22 áreas de proceso se presentan a continuación por

• Planificación del Proyecto (PP).