Cmmi 2010

Fundación de Egresados U.D.
Construyendo Profesionales
FUNDAMENTOS DE CMMI
INTRODUCCIÓN
Jose Espinel Mesa
• Ingeniero de sistemas egresado de la Universidad Francisco de Paula Santander.
• Certificado en ISTQB Foundation Level
• Certificado en ISTQB Advanced Level – TM
• Auditor Interno Certificado ISO 9001
• Capacitación en Ingeniería de Requerimientos - IREB
• Capacitación ITIL Fundamentos
• Coordinador QA empresas CMMI Nivel 3
• Implementación Sistema de Gestión de Calidad Empresa TNS Ltda
• Auditor de Sistemas - Firma Consultora Kreston RM
• Auditor de Sistemas - Firma Latin Professional
• Auditor de Sistemas - Firma L&Q
FUNDACION DE EGRESADOS DE LA UNIVERSIDAD DISTRITAL

1
INTRODUCCIÓN
“La calidad de un sistema o producto esta altamente

influenciado por la calidad de los procesos usados
para desarrollarlo y mantenerlo”
SEI
INTRODUCCIÓN
• El CMMI se enfoca en el mejoramiento de los procesos.
• Contiene los elementos esenciales de procesos efectivos para una o

mas disciplinas y describe un camino evolucionado de mejoramiento
desde procesos inmaduros ad hoc a procesos disciplinados maduros
con calidad y efectividad mejorada.
• En 1995 el SEI creó el primer CMMI diseñado para organizaciones de

software y lo publicó en un libro llamado: “Capability Maturity Model:
Guidelines for Improving the Software Process”.
• El valor de este enfoque en mejoramiento de procesos ha sido

confirmado a través del tiempo. Las organizaciones han experimentado
incremento en su productividad y calidad, mejorando los tiempos de
ciclo, cronogramas y presupuestos mas precisos y predecibles.

2
EVOLUCIÓN
EVOLUCIÓN
• Desde 1991 ha sido desarrollado para muchas disciplinas. Algunas de
las más sobresalientes son: ingeniería de sistemas, ingeniería de
software, adquisición de software, administración de la mano de obra y
desarrollo e integración y desarrollo de procesos (IPPD).
• El proyecto CMMIntegration fue formado para solucionar el problema de

usar múltiples CMM. Su misión inicial fue mezclar tres modelos base:
– The Capability Maturity Model of Software (SW-CMM) v2.0 borrador C [SEI 1997b]
– The Systems Enginnering Capability Model (SECM) [EIA 1998]
– The Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98 [SEI
1997a]

3
CMMI PARA DESARROLLO

• Consiste de dos grupos de modelos: CMMI para desarrollo + IPPD y CMMI
para desarrollo (sin IPPD). Sólo el primero se ha publicado pues es opcional
de la organización aplicar IPPD.
• El SEI ha retirado CMM para software y el IPD-CMM.
• El EIA ha retirado el SECM. Todos esos modelos han sido reemplazados

por CMMI para desarrollo.
• Para liberar la versión 1.0 el SEI tuvo que revisar más de 3000 solicitudes de
cambio. Ahora para la versión 1.02 incorporó mejoras menores.
• La versión 1.1 tuvo más de 1500 solicitudes de cambio.
• Finalmente la versión 1.2 tuvo más de 2000 solicitudes de cambio y es la

que actualmente es ampliamente utilizada.
ALCANCE PARA DESARROLLO

• CMMI para desarrollo es un modelo de referencia que cubre las
actividades de desarrollo y mantenimiento aplicadas a productos y
servicios.
• Varias industrias como: aeroespacial, banca, hardware, software,

defensa, automotriz y telecomunicaciones usan este modelo.
• El modelo cubre: gestión de proyectos, gestión de procesos, ingenieria

de sistemas, ingenieria de hardware, ingenieria de software, y otros
procesos de soporte usados en el desarrollo y mantenimiento.
• El material adicional es IPPD que incluye practicas para ayudar a las

organizaciones a alcanzar la colaboración oportuna de las partes
interesadas (stakeholders) a traves de la vida de un producto que
satisfaga las necesidades de un cliente.

4
ENFOQUE HACIA MEJORAMIENTO DE PROCESOS
• El uso de este modelo se puede ver en dos

escenarios:
– Desarrollador de sistemas electrónicos que quiere mejorar su

proceso de desarrollo de producto usando un enfoque continuo.
– Desarrollador de software que usa IPPD, ha venido usando CMM, y

ahora quiere usar CMMI. Esta compañía recientemente ha sido
calificada en el nivel 3 de CMM.
ENTENDIENDO LOS MODELOS

• Los niveles son usados en CMMI para describir el camino de evolución
recomendado para una organización que quiere mejorar los procesos y
los usa para desarrollar y mantener sus productos y servicios.
• CMMI soporta dos caminos de mejoramiento:

– Una habilita a la organización para incrementalmente mejorar los procesos
correspondientes a un área de proceso individual (o áreas de proceso) seleccionada por
la organización.
– El otro camino habilita a la organización para mejorar un conjunto de procesos
relacionados abordando de manera incremental conjuntos sucesivos de áreas de
procesos.
• Para alcanzar un nivel particular, una organización debe satisfacer todas

las metas apropiadas de las areas de proceso o conjunto de areas de
proceso que están apuntando al mejoramiento, independientemente de
si se trata de una capacidad o nivel de madurez.

5
REPRESENTACIONES
Continua Escalonada
NIVEL
UNO
NIVEL NIVEL
CINCO DOS Nivel
Nivel Cinco
Nivel Cuatro
Tres
Nivel
Dos
Nivel
NIVEL NIVEL Uno
CUATRO TRES
REPRESENTACIONES
Continua: La representación continua permite a una organización seleccionar un

área de proceso (o un grupo de áreas de proceso) y mejorar los procesos
relacionados con ésta. Esta representación utiliza unos niveles de capacidad para
caracterizar la mejora concerniente a un área de proceso individual.
Escalonada: La representación por etapas utiliza conjuntos predefinidos de áreas

de proceso para definir un camino de mejora para una organización. Este camino
de mejora se caracteriza por diversos niveles de madurez. Cada nivel de madurez
proporciona un conjunto de áreas de proceso que caracterizan diferentes
comportamientos organizativos.

6
ESTRUCTURA REPRESENTACIONES
Representación Continua
Áreas de
Proceso
Niveles de
capacidad
Metas Metas
Específicas Genéricas
Practicas Practicas
Representación Escalonada Niveles de

Madurez
Áreas de
Proceso
Metas Metas
Practicas Practicas

7
• Niveles de Capacidad: pertenecen a la representación continua,

aplicables a un alcance de mejoramiento de los procesos de una
organización en áreas de proceso individuales. Estos niveles son un
medio para incrementar el mejoramiento de procesos correspondiente a
un area de proceso dada. Hay seis niveles de capacidad, numerados de
0 hasta 5.
• Niveles de Madurez: pertenecen a la representación escalonada,

aplicables a un alcance de mejoramiento de los procesos de una
organización a través de múltiples áreas de proceso. Estos niveles son
un medio para predecir los resultados generales del próximo proyecto
realizado. Hay cinco niveles de madurez, numerados de 1 hasta 5.
Representación continua Representación por etapas

Concede la libertad explícita para seleccionar Permite a las organizaciones tener una
el orden de mejora que mejor satisface los trayectoria predefinida y probada de mejora.
objetivos de negocio de la organización y
atenúa las áreas de riesgo de la organización.
Permite visibilidad incrementada de la Se centra en un conjunto de procesos que
capacidad alcanzada en cada área de proveen a una organización con una
proceso individual. capacidad específica que está
caracterizada por cada nivel de madurez.
Permite que las mejoras de diversos procesos Resume resultados de la mejora de procesos
sean realizadas en diversos valores. en un simple número de nivel de madurez.
Refleja una aproximación nueva, que todavía Se construye sobre una historia relativamente
no tiene los datos para demostrar sus larga del uso, que incluye casos de estudio y
relaciones con el retorno de la inversión. datos que demuestran el retorno de la
inversión.

8
ENTENDIENDO LOS MODELOS DE MADUREZ

• Un nivel de madurez consiste de practicas especificas y genéricas
relacionadas para un conjunto predefinido de áreas de proceso que
mejoran el rendimiento general de la organización.
• Cada nivel de madurez madura un importante subconjunto de procesos

de la organización, preparándolos para moverse al siguiente nivel de
madurez.
• Los niveles de madurez son medidos por el logro de las metas
especificas y metas genéricas asociadas con cada uno de los conjuntos
de áreas de proceso.
• Hay cinco niveles de madurez:

1. Inicial
2. Gestionado
3. Definido
4. Cuantitativamente manejado
5. Optimizado
• Nivel 1: Inicial
– En este nivel los procesos generalmente son ad hoc y caóticos. La organización
usualmente no proporciona un ambiente estable para soportar los procesos. Se depende
de las competencias y héroes y no del uso de procesos probados.
– Las organizaciones están caracterizadas por una tendencia a sobre comprometerse,
abandono de procesos en tiempos de crisis, y a una inhabilidad de repetir sus exitos.
• Nivel 2: Gestionado
– Los proyectos de la organización han asegurado que los procesos son planeados y
ejecutados de acuerdo con la política.
– Los proyectos contratan personas capacitadas quienes tienen recursos adecuados para
producir salidas controladas; involucran a los stakeholders relevante; son monitoreados,
controlados y revisados; se evalúa su adherencia a los procesos descritos.
– Los productos de trabajo y los servicios satisfacen las descripciones de procesos
especificadas, estándares y procedimientos.

9

• Nivel 3: Definido
– Los procesos están bien caracterizados y entendidos y están descritos en estándares,
procedimientos, herramientas y métodos.
– El conjunto estándar de procesos de la organización son establecidos y mejorados a
través del tiempo. Estos procesos estándar son usados para establecer consistencia a
través de toda la organización.
– Una diferencia critica entre el nivel 2 y 3 es que en el 2 el alcance de los estándares,
descripciones de proceso y procedimientos es por cada proyecto, mientras que en el
nivel 3 esos mismos elementos hacen parte del conjunto de procesos estándar de la
organización y son descritos de una manera mas rigurosa.
• Nivel 4: Cuantitativamente Gestionado

– La organización y los proyectos establecen objetivos cuantitativos para calidad y
rendimiento de los procesos y los usan como criterio en procesos definidos.
– Los objetivos cuantitativos están basados en las necesidades del cliente, usuarios
finales, la organización y los implementadores de procesos.
– Una diferencia critica entre los niveles 3 y 4 es la predictibilidad de la ejecución de los
procesos. En el nivel 4, la ejecución de los procesos es controlada usando técnicas
estadísticas y otras cuantitativas, y es cuantitativamente predecible.
• Nivel 5: Optimizado
– Una organización continuamente mejora sus procesos basada en un entendimiento
cuantitativo de las causas comunes de una variación inherente en el proceso.
– Se enfoca en el mejoramiento continuo de la ejecución del proceso a través de procesos
incrementales e innovación y mejoramientos tecnológicos.
– Una diferencia critica entre los niveles 4 y 5 es el tipo de proceso de variación utilizado.
En el nivel 4, la organización se ocupa de abordar las causas especiales de variación
del proceso y proporcionar predictibilidad estadística de los resultados. Aunque los
procesos pueden tener resultados previsibles, los resultados pueden ser insuficientes
para alcanzar los objetivos establecidos.
– En el nivel 5, la organización se ocupa de tratar las causas comunes de variación del
proceso y modificación del proceso (a cambio de la media del rendimiento de los
procesos o reducir la variación de los procesos inherentes con experiencia) para mejorar
el rendimiento del proceso y lograr que el establecido cuantitativo de los objetivos de
mejora.

10
AREAS DE PROCESO
Nombre Categoría Nivel de Madurez
Causal Analysis and Resolution Soporte 5
Configuration Management Soporte 2
Decision Analysis and Resolution Soporte 3
Integrated Project Management Gestión de Proyectos 3
Measurement and Analysis Soporte 2
Organizational Innovation and Gestión de Procesos 5

Deployment
Organizational Process Definition + Gestión de Procesos 3
IPPD
Organizational Process Focus Gestión de Procesos 3
Organizational Process Performance Gestión de Procesos 4
Organizational Training Gestión de Procesos 3
Product Integration Ingeniería 3
Project Monitoring and Control Gestión de Proyectos 2
AREAS DE PROCESO
Nombre Categoría Nivel de Madurez
Project Planning Gestión de Proyectos 2
Process and Product Quality Assurance Soporte 2
Quantitative Project Management Gestión de Proyectos 4
Requeriments Development Ingeniería 3
Requeriments Management Ingeniería 2
Risk Management Gestión de Proyectos 3
Supplier Agreement Management Gestión de Proyectos 2
Technical Solution Ingeniería 3
Validation Ingeniería 3
Verification Ingeniería 3

11
METAS Y PRACTICAS GENERICAS
Meta 1 Meta 2 Meta 3 Meta 4 Meta 5

GP 1.1 GP 2.1 GP 3.1 GP 4.1 GP 5.1
GP 2.2 GP 3.2 GP 4.1 GP 5.1
GP 2.3
GP 2.4
GP 2.5
GP 2.6
GP 2.7
GP 2.8
GP 2.9
GP 2.10
LAS 4 CATEGORIAS DE LAS AREAS DE PROCESO
• Process Management
• Project Management
• Engineering
• Support

12
PROCESS MANAGEMENT
• Organizational Process Focus

• Organizational Process Definition + IPPD
• Organizational Training
• Organizational Process Performance
• Organizational Innovation and Deployment
PROJECT MANAGEMENT
• Project Planning
• Project Monitoring and Control
• Supplier Agreement Management
• Integrated Project Management + IPPD
• Risk Management
• Quantitative Project Management

13
ENGINEERING
• Requirements Development
• Requirements Management
• Technical Solution
• Product Integration
• Verification
• Validation
SUPPORT
• Configuration Management
• Process and Product Quality Assurance
• Measurement and Analysis
• Decision Analysis and Resolution
• Causal Analysis and Resolution

14
USANDO LOS MODELOS CMMI
• La investigación ha mostrado que el mas poderoso paso inicial para el

mejoramiento de procesos es construir una organización soportada por
patrocinadores senior a nivel de gerencia.
• Las actividades ejecutadas por un gerente patrocinador senior, entre otras

son:
– Influenciar la organización para adoptar CMMI.
– Escoger la mejor gente para manejar el esfuerzo de mejora de procesos.
– Monitorear el esfuerzo de mejora de los procesos personalmente.
– Ser un defensor visible y portavoz del esfuerzo de mejora de los procesos.
– Asegurar que los recursos adecuados están disponibles para permitir que el esfuerzo de mejora
de los procesos sea exitoso.
• Tener un programa de mejora que esta influenciado por:

– Selección de parte de la organización
– Selección de un modelo
– Selección de una representación
USANDO LOS MODELOS CMMI
• Utilizar un Appraisal CMMI

– Para determinar que tan bien los procesos de la organización están comparados con las
mejores practicas de CMMI e identificar áreas donde mejoramiento pueda hacerse.
– Para informar a los clientes externos y proveedores acerca de que tan bien los procesos de la
organización están comparados con los de CMMI.
– Para reunir los requerimientos contractuales de uno o mas clientes.
• Prepararse para que sea realizado un SCAMPI

15
PROJECT PLANNING (PP)
• El propósito de PP es establecer y mantener planes que definan actividades

del proyecto.
• Esta área de proceso involucra:
– Desarrollar el plan del proyecto
– Interactuar con los stakeholders apropiadamente
– Obtener acuerdos para el plan
– Mantenimiento del plan
Meta especifica Practica especifica

SG 1 Establecer estimaciones SP1.1 Estimar el alcance del proyecto

Meta especifica Practica Especifica
SG 1 Establecer estimaciones SP1.1 Estimar el alcance del proyecto
SP 1.2 Establecer estimaciones de los productos de

trabajo y atributos de tareas
SP 1.3 Definir el ciclo de vida del proyecto
SP 1.4 Determinar estimaciones del esfuerzo y costo
SG Desarrollar un Plan de Proyecto SP 2.1 Establecer el presupuesto y el cronograma
SP 2.2 Identificar los riesgos del proyecto
SP 2.3 Plan para la Gestión de Datos
SP 2.4 Plan para los recursos del proyecto
SP 2.5 Plan para el conocimiento y habilidades

necesarios
SP 2.6 Plan para involucrar a los stakeholders
SP 2.7 Establecer el plan del proyecto

16

SG 3 Obtener aprobación del Plan SP 3.1 Revisar planes que afecten el proyecto
SP 3.2 Conciliar Niveles de Trabajo y Recursos
SP 3.3 Obtener aprobación del plan
PROJECT MONITORING AND CONTROL (PMC)

• El propósito es proporcionar un entendimiento del progreso del proyecto así
como de las acciones correctivas que pueden ser tomadas cuando la
ejecución del proyecto se desvía significativamente del plan.

– El plan del proyecto
Meta especifica Practica especifica

SG 1 Monitoreo del Proyecto contra el SP1.1 Monitorear los parametros de
Plan planeación del proyecto
SP 1.2 Monitorear los acuerdos
SP 1.3 Monitorear los riesgos del
proyecto
SP 1.4 Monitorear la gestión de datos
SP 1.5 Monitorear el involucramiento de
los stakeholders

17
PROJECT MONITORING AND CONTROL (PMC)

SP 1.6 Conducir Revisiones del progreso
SP 1.7 Conducir Revisiones de Hitos
SG 2 Gestionar Acciones Correctivas de Cierre SP 2.1 Analizar problemas
SP 2.2 Tomar Acciones Correctivas
SP 2.3 Gestionar Acciones Correctivas
INTEGRATED PROJECT MANAGEMENT (IPM)

• El propósito establecer y gestionar el proyecto y el involucramiento de los
stakeholders relevantes de acuerdo a un proceso integrado y definido que
esta anclado en el conjunto estandar de procesos de la organización.

– Establecimiento del proceso definido al inicio del proyecto basado en el conjunto de procesos
estándar de la organización.
– Establecimiento del ambiente de trabajo para el proyecto basado en los ambientes estándar de
la organización.
– Habilitar a los stakeholders relevantes para que sean identificadas, consideradas y cuando sea
apropiado las preocupaciones direccionadas durante el desarrollo del producto.
– Asegurar que los stakeholders relevantes ejecuten sus tareas de una manera coordinada y
oportuna.

18
INTEGRATED PROJECT MANAGEMENT (IPM)

SG 1 Usar el proceso definido del proyecto SP 1.1 Establecer el proceso definido del proyecto
SP 1.2 Uso de los activos organizacionales del

proceso para la planeación de las actividades del
proyecto
SP 1.3 Establecer el Ambiente de Trabajo del
proyecto
SP 1.4 Integrar Planes
SP 1.5 Manejar el proyecto usando los planes

integrados
SP 1.6 Contribuir a los activos del proceso
organizacional
SG 2 Coordinar y Colaborar con Stakeholders SP 2.1 Gestionar el involucramiento de los
relevantes stakeholders
SP 2.2 Gestionar Dependencias
SP 2.3 Resolver problemas de coordinación
RISK MANAGEMENT (RSKM)

• El propósito es identificar problemas potenciales antes que ocurran de manera
que las actividades de manejo de riesgo puedan ser planeadas e invocadas
cuando sea necesario a traves de la vida del producto o proyecto para mitigar
impactos adversos sobre los objetivos alcanzados.

– Definición del riesgo
– Gestión estrategica
– Identificar y analizar riesgo
– Implementación de planes de mitigación de riesgos cuando sea necesario

19
SG 1 Preparación para gestión de riesgos SP 1.1 Determinar fuentes y categorías de riesgo
SP 1.2 Definir los parámetros del riesgo
SP 1.3 Establecer una estrategia de gestión de

riesgos
SG 2 Identificar y Analizar Riesgos SP 2.1 Identificar Riesgos
SP 2.2 Evaluar, Categorizar y Priorizar Riesgos
SG 3 Mitigar Riesgos SP 3.1 Desarrollar Planes de Mitigación de Riesgos
SP 3.2 Implementar Planes de Mitigación de

Riesgos
QUANTITATIVE PROJECT MANAGEMENT (QPM)

• El propósito es gestionar cuantitativamente el proceso definido del proyecto
para alcanzar la calidad y objetivos establecidos para el proyecto.

– Establecimiento y mantenimiento de la calidad del proyecto y los objetivos de rendimiento.
– Identificar subprocesos adecuados que componen el proceso definido del proyecto basado en
estabilidad y capacidad histórica de los datos encontrados en las líneas base o modelos de los
procesos de ejecución.
– Seleccionar los subprocesos del proceso definido del proyecto a ser gestionados
estadísticamente.
– Monitorear el proyecto para determinar si sus objetivos para calidad y ejecución del proceso
están siendo satisfechos, e identificar las acciones correctivas apropiadas.
– Seleccionar las medidas y técnicas analíticas a ser usadas en la gestión estadística de los
subprocesos seleccionados.

20
QUANTITATIVE PROJECT MANAGEMENT (QPM)
SG 1 Gestión cuantitativa del proyecto SP 1.1 Establecer los objetivos del proyecto
SP 1.2 Componer el proceso definido
SP 1.3 Seleccionar los subprocesos que serán

gestionados estadísticamente
SP 1.4 Gestionar la rendimiento del proyecto
SG 2 Gestión Estadística del rendimiento de los

subprocesos
SP 2.1 Selección de medidas y técnicas de análisis
SP 2.2 Aplicación de métodos estadísticos para

entender las variaciones
SP 2.3 Monitoreo del rendimiento de los
subprocesos seleccionados
SP 2.4 Registro estadístico de la gestión de datos
REQUIREMENTS MANAGEMENT (REQM)

• El propósito es gestionar los requerimientos de los componentes de los
productos y productos del proyecto e identificar inconsistencias entre esos
requerimientos y los planes del proyecto y los productos de trabajo.

– Revisión
– Aprobación
– Planeación
– Acuerdos
– Cambios
– Trazabilidad

21
REQUIREMENTS MANAGEMENT (REQM)
SG 1 Gestión de Requerimientos SP 1.1 Obtener un entendimiento de los

requerimientos
SP 1.2 Obtener acuerdo de los requerimientos
SP 1.3 Gestionar cambios en los requerimientos
SP 1.4 Mantener trazabilidad bidireccional de los

requerimientos
SP 1.5 identificar inconsistencias entre el trabajo del
proyecto y los requerimientos
ORGANIZATIONAL PROCESS DEFINITION (OPD)

• El propósito es establecer y mantener un conjunto utilizable de activos de
proceso organizacionales y trabajar ambientes estándar.

– Rendimiento del proceso a través de la organización
– Librería de activos de los procesos de la organización
– Elementos de proceso
– Descripción de los modelos de ciclo de vida
– Guías de procesos institucionalizados
– Documentación relacionada con los procesos

22
ORGANIZATIONAL PROCESS DEFINITION (OPD)
SG 1 Establecer los activos de los procesos SP 1.1 Establecer procesos estándar

organizacionales
SP 1.2 Establecer las descripciones de los modelos
de ciclo de vida
SP 1.3 Establecer criterios institucionales y guías
SP 1.4 Establecer el repositorio organizacional de

medidas
SP 1.5 Establecer la librería de activos de los
procesos organizacionales
SP 1.6 Establecer ambientes estándar de trabajo
Más IPPD SP 2.1 Establecer mecanismos de empoderamiento

SG 2 Habilitar la gestión de IPPD
SP 2.2 Establecer reglas y guías para equipos
integrados
SP 2.3 Balancear las responsabilidades internas y
del equipo organizacional
ORGANIZATIONAL PROCESS FOCUS (OPF)

• El propósito es planear, implementar, y desplegar los mejoramientos a los
procesos organizacionales basados en un conocimiento profundo de las
fortalezas y debilidades de los procesos de la organización y de los activos de
los procesos.

– Mejoramiento
– Lecciones aprendidas
– Resultados de las evaluaciones
– Resultados de benchmarking
– Recomendaciones

23
ORGANIZATIONAL PROCESS FOCUS (OPF)

SG 1 Determinar las oportunidades de mejora para SP 1.1 Establecer necesidades organizacionales

los procesos para los procesos
SP 1.2 Evaluar los procesos organizacionales
SP 1.3 Identificar los mejoramientos a los procesos

de la organización
SP 1.4 Establecer el repositorio organizacional de
medidas
SG 2 Planear e Implementar mejoras a los procesos SP 2.1 Establecer planes de acción para los
procesos
SP 2.2 Implementar planeas de acción para los
procesos
SG 3 Desplegar los activos organizacionales de los SP 3.1 Desplegar los activos organizacionales de los
procesos e incorporar las lecciones aprendidas procesos
SP 3.2 Desplegar procesos estándar
SP 3.3 Monitorear la implementación
SP 3.4 Incorporar experiencias relacionadas con los

procesos dentro de los activos organizacionales de
los procesos
ORGANIZATIONAL TRAINING (OT)

• El propósito es desarrollar las habilidades y conocimiento de las personas de
manera que ellos ejecuten sus roles efectivamente y eficientemente.

– Identificar las necesidades de capacitación necesarias para la organización
– Obtener y proporcionar capacitación para hacer frente a esas necesidades.
– Establecer y mantener capacidad de entrenamiento
– Establecer y mantener registros de capacitación
– Evaluación de la efectividad del entrenamiento.

24
ORGANIZATIONAL TRAINING (OT)
SG 1 Establecer una capacidad organizacional de SP 1.1 Establecer las necesidades estratégicas de

entrenamiento capacitación
SP 1.2 Determinar cuales necesidades de
capacitación son responsabilidad de la organización
SP 1.3 Establecer un Plan táctico organizacional de
capacitación
SP 1.4 Establecer Capacidad de Entrenamiento
SG 2 Proporcionar la capacitación necesaria SP 2.1 Entregar capacitación
SP 2.2 Establecer registros de entrenamiento
SP 2.3 Evaluar la efectividad
ORGANIZATIONAL PROCESS PERFORMANCE (OPP)
• El propósito es establecer y mantener un entendimiento cuantitativo del

rendimiento del conjunto estándar de procesos de la organización en apoyo
de los objetivos de calidad y rendimiento, y proporcionar los datos de
ejecución del proceso, líneas base y modelos de gestión cuantitativa de los
proyectos de la organización.

– Determinar si los procesos se están comportando consistentemente o tienen tendencias
estables (es decir, predecibles)
– Identificar procesos donde el rendimiento esta dentro de los limites naturales que son
consistentes a través de los equipos de implementación de procesos.
– Establecer criterios de identificación si un proceso o subproceso debería ser gestionado
estadísticamente, y determinar las mediciones pertinentes y las técnicas analíticas a ser usadas
un tal gestión.
– Identificar procesos que muestran comportamiento inusual (es decir, impredecible o
esporádico).
– Identificar cualquier aspecto de los procesos que pueden ser mejorados en el conjunto estándar
de procesos de la organización
– Identificar la implementación de un proceso que se ejecuta muy bien.

25
ORGANIZATIONAL PROCESS ANS PERFORMANCE (OPP)
SG 1 Establecer líneas base y modelos de SP 1.1 Seleccionar Procesos

rendimiento
SP 1.2 Establecer mediciones para el rendimiento
del proceso
SP 1.3 Establecer objetivos de calidad y rendimiento
del proceso
SP 1.4 Establecer líneas base del rendimiento del
proceso
SP 1.5 Establecer modelos de rendimiento del
proceso
ORGANIZATIONAL INNOVATION AND DEPLOYMENT(OID)
• El propósito es seleccionar y el desplegar mejoramientos incrementales e

innovadores que mediblemente mejores los procesos y tecnologías de la
organización. Los mejoramientos apoyan a los objetivos de calidad y
rendimiento de los procesos de la organización.
– Mejoramiento de la calidad del producto
– Incremento de la productividad
– Disminución del tiempo de ciclo
– Gran incremento en la satisfacción del cliente y el usuario final
– Desarrollo mas corto o tiempo de producción para cambiar la funcionalidad o adicionar nuevas
características, o adoptar nuevas tecnologías.
– Reducir el tiempo de entrega
– Reducir el tiempo de adaptación a nuevas tecnologías y necesidades del negocio.

26
ORGANIZATIONAL INNOVATION AND DEPLOYMENT (OID)
SG 1 Seleccionar Mejoras SP 1.1 Recolectar y analizar propuestas de mejora
SP 1.2 Identificar y analizar innovaciones
SP 1.3 Mejoras Piloto
SP 1.4 Seleccionar mejoras para desarrollo
SG 2 Desplegar mejoras SP 2.1 Planear el despliegue
SP 2.2 Gestionar el despliegue
SP 2.3 Medición de los efectos de la mejora
MEASUREMENT AND ANALYSIS (MA)
• El propósito es desarrollar y sostener una capacidad de medición que sea

usada para soportar necesidades de gestión de información.
– Especificación de los objetivos de medición y análisis tales que estén alineados con
necesidades y objetivos de información identificados.
– Especificación de las medidas, técnicas de análisis y mecanismos para recolección de datos,
almacenamiento de datos, reportes y retroalimentación
– Implementación de almacenamiento, análisis y reportes de los datos.
– Proporcionar resultados objetivos que puedan ser usados en la toma de decisiones informadas,
y tomar las acciones correctivas apropiadas.

27
MEASUREMENT AND ANALYSIS (MA)
SG 1 Alineación de medidas y actividades de SP 1.1 Establecer objetivos de medición

análisis
SP 1.2 Especificar medidas
SP 1.3 Especificar recolección de datos y

procedimientos de almacenaje
SP 1.4 Especificar procedimientos de análisis
SG 2 Proporcionar resultados de la medición SP 2.1 Recolectar datos de medición
SP 2.2 Analizar datos de medición
SP 2.3 Guardar datos y resultados
SP 2.4 Comunicar resultados
PROCESS AND PRODUCT QUALITY ASSURANCE (PPQA)
• El propósito es proporcionar el personal y la gestión con una visión objetiva de

los procesos y productos de trabajo asociados.

– Evaluación objetiva de los procesos ejecutados, productos de trabajo, y servicios contra la
descripción de procesos aplicable, estándares y procedimientos.
– Identificar y documentar problemas de no conformidad.
– Proporcionar retroalimentación al equipo del proyecto y los directores sobre los resultados de
las actividades de aseguramiento de calidad.
– Asegurar que los problemas de no conformidad son abordados.

28
PROCESS AND PRODUCT QUALITY ASSURANCE (PPQA)
SG 1 Evaluar objetivamente los procesos y SP 1.1 Evaluar objetivamente los procesos

productos de trabajo
SP 1.2 Evaluar objetivamente los productos de
trabajo y los servicios
SG 2 Proporcionar visión a los objetivos SP 2.1 Comunicar y asegurar la solución de
problemas de no conformidad
SP 2.2 Establecer registros
CONFIGURATION MANAGEMENT (CM)
• El propósito es establecer y mantener la integridad de los productos de trabajo

usando identificación de la configuración, control de la configuración, estado
de la configuración y auditoria de la configuración.

– Identificación de la configuración de los productos de trabajo seleccionados que componen las
líneas base en puntos dados en el tiempo.
– Controlar cambios a los ítems de configuración
– Construir o proporcionar especificaciones para construir productos de trabajo desde el sistema
de gestión de configuración.
– Mantenimiento de la integridad de las líneas base.
– Proporcionar estado preciso y configuración actual de los datos a los desarrolladores, usuarios
finales y clientes.

29
SG 1 Establecer líneas base SP 1.1 Identificar los ítems de configuración
SP 1.2 Establecer un sistema de gestión de

configuración
SP 1.3 Crear o liberar líneas base
SG 2 Rastrear y controlar cambios SP 2.1 Rastrear solicitudes de cambio
SP 2.2 Control de Ítems de Configuración
SG 3 Establecer Integridad SP 3.1 Establecer los registros de gestión de

configuración
SP 3.2 Ejecutar Auditorias de Configuración
DECISION ANALYSIS AND RESOLUTION (DAR)
• El propósito es analizar posibles decisiones usando un proceso formal de

evaluación que evalúa alternativas identificadas contra criterios establecidos.

– Establecimiento de los criterios para la evaluación de alternativas.
– Identificar soluciones alternativas.
– Seleccionar métodos para evaluación de alternativas.
– Evaluación de soluciones alternativas usando los criterios y métodos establecidos.
– Seleccionar soluciones recomendadas desde las alternativas basadas en los criterios de
evaluación.

30
DECISION ANALYSIS AND RESOLUTION (DAR)
SG 1 Evaluación de alternativas SP 1.1 Establecer guías para Análisis de Decisión
SP 1.2 Establecer criterios de evaluación
SP 1.3 Identificar alternativas de solución
SP 1.4 Seleccionar métodos de evaluación
SP 1.5 Evaluar alternativas
SP 1.6 Seleccionar soluciones
CAUSAL ANALYSIS AND RESOLUTION (CAR)
• El propósito es identificar causas de defectos y otros problemas y tomar

acción para prevenir que ocurran en el futuro.

– Identificar y analizar las causas de defectos y otros problemas
– Tomar acciones especificas para remover las causas y prevenir la ocurrencia de aquellos tipos
de defectos y problemas en el futuro.

31
CAUSAL ANALYSIS AND RESOLUTION (CAR)
SG 1 Determinar causas de defectos SP 1.1 Seleccionar datos defectuosos para análisis
SP 1.2 Analizar causas
SG 2 Direccionar causas de defectos SP 2.1 Implementar las acciones propuestas
SP 2.2 Evaluar el efecto de los cambios
SP 2.3 Registrar datos
• El propósito de la Gestión de configuración (CM) es establecer y mantener la

integridad de los productos de trabajo utilizando la identificación de
configuración, el control de configuración, el registro del estado de
configuración y las auditorías de configuración.
• El área de proceso de Gestión de configuración implica:

– 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 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 del estado exacto y de la
configuración actual.
• Los productos de trabajo situados bajo gestión de configuración incluyen los

productos que se entregan al cliente, los productos de trabajo internos
designados, los productos adquiridos, las herramientas y otros elementos que
se usan para crear y describir estos productos de trabajo.

32
• Algunos ejemplos de productos de trabajo que pueden ponerse bajo gestión

de configuración son:
– Planes.
– Descripciones de proceso.
– Requerimientos.
– Datos de diseño.
– Dibujos.
– Especificaciones de producto.
– Código.
– Compiladores.
– Ficheros de datos de producto.
– Publicaciones técnicas de producto.
• Un ejemplo de una línea base es una descripción aprobada de un producto

que incluye versiones internamente consistentes de requerimientos, de
matrices de trazabilidad de requerimientos, de diseño, de elementos
específicos de una disciplina y de la documentación del usuario final.
• Los cambios a las líneas base y la liberación de los productos de trabajo

construidos a partir del sistema de gestión de configuración se controlan y se
siguen vía las funciones de control de configuración, de gestión del cambio y
de auditoría de configuración pertenecientes a la gestión de configuración.
• La gestión de configuración se enfoca en el control riguroso de los aspectos

de gestión y técnicos de los productos de trabajo, incluyendo el sistema
entregado.

33
SP 1.1 IDENTIFICAR ELEMENTOS DE CONFIGURACIÓN:
La identificación de la configuración es la selección, creación y especificación

de:
• Productos que se entregan al cliente.

• Productos de trabajo internos designados.
• Productos adquiridos.
• Herramientas y otros activos esenciales del entorno de trabajo del proyecto.
• Otros elementos que se utilizan en la creación y la descripción de estos
productos de trabajo.
Productos de trabajo típicos

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.
2. Asignar identificadores únicos a los elementos de configuración.
3. Especificar las características importantes de cada elemento de configuración.
4. Especificar cuándo cada elemento de configuración se pone bajo gestión de

configuración.
Algunos ejemplos de criterios para determinar cuándo poner los productos de

trabajo bajo gestión de configuración son:
• Etapa del ciclo vida del proyecto.

• Cuándo el producto del trabajo está listo para las pruebas.
• Grado de control deseado en el producto de trabajo.
• Limitaciones de coste y de calendario.
• Requerimientos del cliente.
5. Identificar al propietario responsable de cada elemento de configuración.

34

SP 1.2 ESTABLECER UN SISTEMA DE GESTIÓN DE CONFIGURACIÓN
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 en la gestión de la
configuración.
2. Guardar y recuperar los elementos de configuración en un sistema de gestión de
configuración.
3. Compartir y transferir los elementos de configuración entre los niveles de control dentro
del sistema de gestión de configuración.
4. Almacenar y recuperar versiones archivadas de elementos de configuración.
5. Almacenar, actualizar y recuperar los registros de gestión de configuración.
6. Crear informes de gestión de configuración a partir del sistema de gestión de
configuración.
7. Preservar los contenidos del sistema de gestión de configuración.
8. Corregir la estructura de gestión de configuración según sea necesario.

SP 1.3 CREAR O LIBERAR LÍNEAS BASE
Una línea base es un conjunto de especificaciones o de productos de trabajo que ha sido

revisado y acordado formalmente, que a partir de entonces sirve como base para el
desarrollo o la entrega posterior, y que solamente puede cambiarse mediante
procedimientos de control de cambio.

1. Líneas base.
2. Descripción de las líneas base.
Subprácticas
1. Obtener la autorización del Comité de control de configuración (CCB) antes de crear o
liberar líneas base de elementos de configuración.
2. Crear o liberar líneas base sólo desde 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. Hacer fácilmente disponible el conjunto actual de líneas base.

35

SP 2.1 SEGUIR LAS PETICIONES DE CAMBIO
Las peticiones de cambio se analizan para determinar el impacto que el cambio tendrá 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.
3. Revisar las peticiones de cambio, que serán tratadas en la siguiente línea base, con las
partes interesadas relevantes y conseguir su acuerdo.
4. Seguir el estado de las peticiones de cambio hasta su cierre.

SP 2.2 CONTROLAR LOS ELEMENTOS DE CONFIGURACIÓN
Este control incluye el seguimiento de la configuración de cada uno de los elementos de

configuración, aprobando una nueva configuración, en caso de ser necesario, y actualizando la
línea de base.

1. Historial de revisiones de los elementos de configuración.
2. Archivos de las líneas base.
Subprácticas
1. Controlar los cambios a los elementos de configuración a lo largo de la vida del producto.
2. Obtener la autorización apropiada antes que los elementos de configuración cambiados sean
introducidos en el sistema de gestión de configuración.
3. Comprobar la entrada (check-in) y la salida (check-out) de los elementos de configuración
desde el sistema de gestión de configuración para la incorporación de los cambios de forma que
se mantenga la exactitud y la integridad de los elementos de configuración.
4. Realizar revisiones para asegurar que los cambios no han causado efectos involuntarios en las
líneas base (p. ej., asegurar que los cambios no hayan comprometido la seguridad y/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.

36

SP 3.1 ESTABLECER REGISTROS DE GESTIÓN DE CONFIGURACIÓN

1. Historial de revisión de los elementos de configuración.
2. Registro de cambios.
3. Copia de las peticiones de cambio.
4. Estado de los elementos de la configuración.
5. Diferencias entre líneas base.
1. Registrar las acciones de gestión de configuración con suficiente detalle, para que sea
conocido el contenido y el estado de cada elemento de configuración, y que puedan
recuperarse las versiones anteriores.
2. Asegurar que las partes interesadas relevantes tengan acceso y conocimiento del estado
de la configuración de los elementos de configuración.
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. Corregir cuando sea necesario el estado y la historia (es decir, cambiosy otras acciones)
de cada elemento de configuración.

SP 3.2 REALIZAR AUDITORÍAS DE CONFIGURACIÓN
Las auditorías de configuración confirman que el resultado de las líneas base y de la

documentación están conformes con un estándar o requerimiento especificado. Los
resultados de la auditoría deberían registrarse.

1. Resultados de la auditoria 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 configuración son completos y
correctos.
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.

37
REQUIREMENTS DEVELOPMENT (RD)

El propósito del Desarrollo de requerimientos (RD) es producir y analizar los requerimientos
de cliente, de producto y de componente del producto.
Este área de proceso describe tres tipos de requerimientos: de cliente, de producto y de

componente de producto. Tomados en conjunto, estos requerimientos tratan las necesidades
de las partes interesadas relevantes, incluyendo aquellas pertinentes a las distintas fases del
ciclo de vida del producto (p. ej., criterios de pruebas de aceptación) y a los atributos del
producto (p. ej., seguridad, fiabilidad y facilidad de mantenimiento).
Los requerimientos son la base para el diseño. El desarrollo de requerimientos incluye las
siguientes actividades:
• Extracción, análisis, validación y comunicación de las necesidades, las expectativas y las

restricciones del cliente para obtener los requerimientos de cliente que constituyen una
comprensión de lo que satisfará a las partes interesadas.
• Recogida y coordinación de las necesidades de las partes interesadas.
• Desarrollo de los requerimientos del ciclo de vida del producto.
• Establecimiento de los requerimientos de cliente.
• Establecimiento de los requerimientos iniciales de producto y de componente del producto
consistentes con los requerimientos de cliente.

Como resultado del análisis de requerimientos y del concepto operativo (incluyendo
funcionalidad, soporte, mantenimiento y retirada), la fabricación o el concepto de producción
produce más requerimientos derivados, incluyendo consideraciones de:
• Restricciones de varios tipos.

• Limitaciones tecnológicas.
• Coste y parámetros de coste.
• Restricciones de tiempo y parámetros de calendario.
• Riesgos.
• Consideración de problemas implícitos, pero no declarados explícitamente por el cliente o
por el usuario final.
• Factores introducidos por consideraciones únicas de negocio del desarrollador, por
regulaciones y por leyes.

38

SP 1.1 OBTENER LAS NECESIDADES
La obtención va más allá de la recogida de requerimientos mediante la identificación proactiva de

requerimientos adicionales no explícitamente proporcionados por los clientes. Los requerimientos
adicionales deberían tratar las distintas actividades del ciclo de vida y sus impactos en el producto.
Algunos ejemplos de técnicas para obtener 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 operativos obtenidos de usuarios finales.
• Recorridos operativos y análisis de tarea del usuario final.
• Prototipos y modelos.
• Tormenta de ideas.
• Despliegue de la función de calidad.
• Estudios de mercado.
• Pruebas beta.
• Extracción de fuentes tales como documentos, estándares o especificaciones.
• Observación de productos, entornos y patrones de flujo de trabajo existentes.
• Casos de uso.
• Análisis de casos de negocio.
• Ingeniería inversa (para productos heredados).
• Encuestas de satisfacción del cliente.

SP 1.2 DESARROLLAR LOS REQUERIMIENTOS DE CLIENTE

1. Requerimientos de cliente.
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 requerimientos de cliente documentados.
2. Definir las restricciones para la verificación y la validación.

39

SP 2.1 ESTABLECER LOS REQUERIMIENTOS DEL PRODUCTO Y DE COMPONENTES
DEL PRODUCTO
Los requerimientos de cliente pueden expresarse en los términos del cliente y pueden ser
descripciones no técnicas. Los requerimientos del producto son la expresión de estos
requerimientos en términos técnicos que pueden utilizarse para las decisiones de diseño.
La modificación de los requerimientos debido a los cambios a los requerimientos aprobados

se cubren por la función "mantener" de esta práctica específica; mientras que la
administración de los cambios a los requerimientos se cubre por el área de proceso de
Gestión de requerimientos.

1. Requerimientos derivados.
2. Requerimientos del producto.
3. Requerimientos de componentes del producto.

Subprácticas
1. Desarrollar los requerimientos en los términos técnicos necesarios para el diseño del
producto y de componentes del producto.
2. Derivar los requerimientos resultantes de las decisiones de diseño.
3. Establecer y mantener las relaciones entre los requerimientos para su consideración
durante la gestión del cambio y la asignación de los requerimientos.
Las relaciones entre los requerimientos pueden ayudar en la evaluación del impacto de los
cambios.

40

SP 2.2 ASIGNAR LOS REQUERIMIENTOS DE COMPONENTES DEL PRODUCTO

1. Hojas de asignación de requerimientos.
2. Asignaciones provisionales de requerimientos.
3. Restricciones de diseño.
4. Requerimientos derivados.
5. Relaciones entre requerimientos derivados.
Subprácticas
1. Asignar los requerimientos a las funciones.
2. Asignar los requerimientos a los componentes del producto.
3. Asignar las restricciones de diseño a los componentes del producto.
4. Documentar las relaciones entre requerimientos asignados: Las relaciones incluyen las
dependencias en las cuales un cambio en un requerimiento puede afectar a otros
requerimientos.

SP 2.3 IDENTIFICAR LOS REQUERIMIENTOS DE LA INTERFAZ
Se identifican las interfaces entre las funciones (o entre los objetos).

Las interfaces funcionales pueden conducir el desarrollo de soluciones
alternativas descritas en el área de proceso de Solución técnica.

1. Requerimientos de la interfaz.
Subprácticas
1. Identificar las interfaces tanto externas como internas al producto (es decir, entre las
particiones funcionales u objetos).
2. Desarrollar los requerimientos para las interfaces identificadas.
Los requerimientos 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.

41

SP 3.1 ESTABLECER LOS CONCEPTOS OPERATIVOS Y LOS ESCENARIOS
Un escenario es normalmente una secuencia de eventos que podrían ocurrir en el uso del
producto, el cual se usa para hacer explícitas algunas de las necesidades de las partes
interesadas.
Los conceptos operativos y los escenarios evolucionan para facilitar la selección de

soluciones del componente del producto que, cuando se implementan, satisfarán
el uso previsto del producto.

1. Concepto operativo.
2. Instalación, operación, mantenimiento y conceptos de soporte del producto o
componentes del producto.
3. Conceptos de retirada.
4. Casos de uso.
5. Escenarios de cronología.
6. Nuevos requerimientos.

Subprácticas
1. Desarrollar los conceptos operativos y los escenarios que incluyan funcionalidad,
rendimiento, mantenimiento, soporte y retirada según sea apropiado.
2. Definir el entorno en el cual funcionarán el producto o los componentes del producto,
incluyendo los límites y las restricciones.
3. Revisar los conceptos operativos y los escenarios para refinar y descubrir los
requerimientos.
El concepto operativo y el desarrollo del escenario es un proceso iterativo. Las revisiones
deberían mantenerse periódicamente para asegurar que están de acuerdo con los
requerimientos. La revisión puede ser en la forma de una inspección informal
(walkthrough).
4. Desarrollar un concepto operativo detallado, a medida que se seleccionan los productos y

los componentes del producto, que defina la interacción del producto, del usuario final y del
entorno, y que satisfaga las necesidades operativas, de mantenimiento, de soporte y de
retirada.

42

SP 3.2 ESTABLECER UNA DEFINICIÓN DE LA FUNCIONALIDAD REQUERIDA
La definición de la funcionalidad, también referida como “análisis funcional”, es la descripción de lo

que se pretende que haga el producto. La definición de la funcionalidad puede incluir acciones,
secuencia, entradas, salidas u otra información que comunique la manera en la
cual el producto será usado.

1. Arquitectura funcional.
2. Diagramas de actividad y casos de uso.
3. Análisis orientado a objetos con los servicios o métodos identificados.
Subprácticas
1. Analizar y cuantificar la funcionalidad requerida por los usuarios finales.
2. Analizar los requerimientos para identificar las particiones lógicas o funcionales (p. ej.,
subfunciones).
3. Dividir los requerimientos en grupos, en base a los criterios establecidos (p. ej., funcionalidad
similar, rendimiento o acoplamiento), para facilitar y para enfocar el análisis de requerimientos.
4. Considerar la secuenciación de las funciones críticas en el tiempo tanto inicialmente como
posteriormente durante el desarrollo de componentes del producto.
5. Asignar los requerimientos de cliente a las particiones funcionales, objetos, personal o
elementos de soporte para dar soporte a la síntesis de las soluciones.
6. Asignar los requerimientos funcionales y de rendimiento a las funciones y a las subfunciones

SP 3.3 ANALIZAR LOS REQUERIMIENTOS
A medida que se definen los requerimientos, su relación con requerimientos de más alto nivel y la
funcionalidad definida de más alto nivel deben comprenderse. Una de las otras acciones es la
determinación de qué requerimientos clave serán usados para seguir el progreso.

1. Informes de defectos de los requerimientos.
2. Cambios propuestos a los requerimientos para resolver defectos.
3. Requerimientos claves.
4. Medidas técnicas de rendimiento.
Subprácticas
1. Analizar las necesidades, las expectativas, las restricciones y las interfaces externas de las partes
interesadas para eliminar conflictos y para organizarlos en temas relacionados.
2. Analizar los requerimientos para determinar si satisfacen los objetivos de los requerimientos de nivel
más alto.
3. Analizar los requerimientos para asegurarse de que son completos, factibles, realizables y verificables.
4. Identificar los requerimientos claves que tienen una fuerte influencia en el coste, calendario,
funcionalidad, riesgos o rendimiento.
5. Identificar las medidas de rendimiento técnico que serán seguidas durante el esfuerzo de desarrollo.
6. Analizar los conceptos operativos y los escenarios para refinar las necesidades, las restricciones y las
interfaces del cliente, y para descubrir nuevos requerimientos.

43

SP 3.4 ANALIZAR LOS REQUERIMIENTOS PARA ALCANZAR EL EQUILIBRIO
Las necesidades y las restricciones de las partes interesadas pueden tratar coste,
calendario, rendimiento, funcionalidad, componentes reutilizables, capacidad de
mantenimiento o riesgos.

1. Evaluación de los riesgos relacionados con los requerimientos.
Subprácticas
1. Usar modelos, simulaciones y prototipos probados para analizar el equilibrio entre las
necesidades y las restricciones de las partes interesadas.
2. Ejecutar una evaluación de riesgos sobre los requerimientos y la arquitectura funcional.
3. Examinar los conceptos del ciclo de vida del producto en cuanto a los impactos de los
requerimientos en los riesgos.

SP 3.5 VALIDAR LOS REQUERIMIENTOS
La validación de los requerimientos se ejecuta pronto en el esfuerzo de desarrollo con los usuarios
finales para ganar confianza en que los requerimientos son capaces de guiar un desarrollo que dé
como resultado el éxito de la validación final.
Esta actividad debería integrarse con las actividades de gestión de riesgos. Las organizaciones
maduras normalmente ejecutarán la validación de los requerimientos 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.

1. Registro de los métodos y de los resultados del análisis.
Subprácticas
1. Analizar los requerimientos para determinar el riesgo de que el producto resultante no se
ejecutará apropiadamente en su entorno de uso previsto.
Algunos ejemplos de las técnicas usadas para la validación de los requerimientos son:
• Análisis.
• Simulaciones.
• Prototipos.
• Demostraciones.

44

El propósito de la Gestión de riesgos (RSKM) es identificar los 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 para alcanzar los objetivos.
La gestión de riesgos eficaz incluye la identificación temprana y agresiva de cada riesgo a

través de la colaboración y la involucración de las partes interesadas relevantes, tal y como
se describió en el plan para la involucración de las partes interesadas tratado en el área de
proceso de Planificación de proyecto.
La gestión de riesgos puede dividirse en tres partes: definir una estrategia de gestión de
riesgos, identificar y analizar los riesgos, y manejar los riesgos identificados, incluyendo la
implementación de los planes de mitigación de riesgo, cuando sea necesario.

SP 1.1 DETERMINAR LAS FUENTES Y LAS CATEGORÍAS DE LOS RIESGOS
La identificación de las fuentes de riesgo proporciona una base para examinar

sistemáticamente situaciones cambiantes en el tiempo para descubrir circunstancias que
impactan a la capacidad del proyecto en el cumplimiento de sus objetivos.
Establecer categorías para los riesgos proporciona un mecanismo para recoger y

organizarlos, así como asegurar el escrutinio apropiado y la atención del nivel de gerencia
para aquellos riesgos que puedan tener consecuencias más serias para el cumplimiento de
los objetivos del proyecto.

1. Listas de fuentes de riesgo (externas e internas).
2. Lista de categorías de riesgos.
Subprácticas
1. Determinar las fuentes de riesgo.

45

Las típicas fuentes de riesgo internas y externas incluyen:
• Requerimientos incompletos.
• Esfuerzos sin precedentes — estimaciones no disponibles.
• Diseño inviable.
• Tecnología no disponible.
• Estimaciones o asignación de calendario no realistas.
• Recursos de personal y habilidades inadecuadas.
• Problemas de coste o financiación.
• Capacidad del subcontratista incierta o inadecuada.
• Capacidad del vendedor incierta o inadecuada.
• Comunicación inadecuada con los clientes actuales o potenciales o con sus
representantes.
• Interrupciones de la continuidad de las operaciones.
2. Determinar las categorías de riesgo Las categorías de riesgo reflejan las “divisiones” para
recoger y organizarlos riesgos. Una razón para identificar categorías de riesgo es ayudar en
la futura consolidación de las actividades de los planes de mitigación de riesgo.

SP 1.2 DEFINIR LOS PARÁMETROS DE LOS RIESGOS
Los parámetros para evaluar, categorizar y priorizar los riesgos incluyen:
• 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 disparar las actividades de gestión.

1. Evaluación y categorización de riesgo, y criterios de priorización.
2. Requerimientos de la gestión de riesgos (p. ej., niveles de control y de aprobación, e
intervalos de reevaluación).
Los siguientes factores pueden considerarse cuando se determinan

categorías de riesgo:
• Las fases del modelo de ciclo de vida del proyecto (p. ej., requerimientos,
diseño, fabricación, prueba y evaluación, entrega y retirada).
• Los tipos de procesos usados.
• Los tipos de productos usados.

46

• Los riesgos de la gestión del programa (p. ej., riesgos del contrato, riesgos del
presupuesto/coste, riesgos de calendario, riesgos de recursos, riesgos de rendimiento y
riesgos de mantenimiento).
Subprácticas
1. Definir criterios consistentes para evaluar y cuantificar la probabilidad de riesgo y los
niveles de gravedad.
2. Definir umbrales para cada categoría de riesgo.
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.
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 en coste (CPIs) caigan por debajo del 0,95.
• Los umbrales de calendario podrían establecerse para involucrar a la 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 dirección cuando
los elementos claves especificados (p. ej., la utilización del procesador o los tiempos medios
de respuesta) superan el 125 por ciento del diseño previsto.

SP 2.1 IDENTIFICAR LOS RIESGOS
La identificación de problemas 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 con éxito.
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 riesgo no debería ser un intento para tratar cada evento posible,
independientemente de cómo de improbable pueda ser.
Hay muchos métodos para identificar los riesgos. Los métodos típicos de identificación
incluyen:
• Examinar cada elemento de la estructura de descomposición de tareas del proyecto para
descubrir riesgos.
• Llevar a cabo una evaluación de riesgos usando una taxonomía de riesgos.
• Entrevistar a expertos en la materia.
• Revisar los esfuerzos de la 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 requerimientos del contrato.

47

SP 1.3 ESTABLECER UNA ESTRATEGIA DE GESTIÓN DE RIESGOS
Una estrategia de gestión de riesgos exhaustiva trata elementos tales como:
• El alcance del esfuerzo de la 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.
• Fuentes específicas de riesgos del proyecto.
• La forma que estos riesgos se organizarán, categorizarán, compararán y consolidarán.
• Los parámetros, incluyendo la probabilidad, consecuencia y umbrales, para actuar sobre
los riesgos identificados.
• Técnicas de mitigación de riesgos que serán usadas, tales como prototipos, pilotos,
simulación, diseños alternativos o desarrollo evolutivo.
• Definición de medidas de riesgo para monitorizar el estado de los riesgos.
• Intervalos de tiempo para la monitorización o revisión del riesgo.

1. Estrategia de gestión de riesgos del proyecto.

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.
2. Revisar elementos ambientales que pueden impactar en el proyecto.
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 todos los aspectos del
esfuerzo de trabajo han sido considerados.
4. Revisar todos los elementos del plan del proyecto como parte de la identificación de
riesgos para ayudar a asegurar que todos aspectos del proyecto han sido considerados.
5. Documentar el contexto, las condiciones y las consecuencias potenciales del riesgo.
6. Identificar las partes interesadas relevantes asociadas con cada riesgo.

48

SP 2.2 EVALUAR, CATEGORIZAR Y PRIORIZAR LOS RIESGOS
La evaluación de los riesgos es necesaria para asignar la importancia relativa

a cada riesgo identificado, y se usa en la determinación de cuándo
se requiere la atención apropiada de la gerencia.

1. Lista de riesgos, con una prioridad asignada a cada riesgo.
Subprácticas
1. Evaluar los riesgos identificados usando los parámetros de riesgo definidos.
2. Clasificar y agrupar los riesgos de acuerdo a las categorías de riesgo definidas.
3. Priorizar los riesgos para la mitigación.

SP 3.1 DESARROLLAR LOS PLANES DE MITIGACIÓN DE RIESGOS
Un componente crítico de un plan de mitigación de riesgos es desarrollar cursos de acción

alternativos, soluciones temporales y posiciones de repliegue, con un curso de acción
recomendado para cada riesgo crítico.
Los riesgos se monitorizan y, cuando sobrepasan los límites establecidos, los planes de
mitigación de riesgo se realizan para devolver el esfuerzo impactado a un nivel de riesgo
aceptable.
Algunas de las opciones para tratar los riesgos normalmente

son:
• Evitar el riesgo: Cambiar o reducir los requerimientos mientras todavía cumplan las
necesidades del usuario.
• Controlar el riesgo: Llevar a cabo etapas activas para minimizar los riesgos.
• Transferir el riesgo: Reasignar requerimientos para reducir los riesgos.
• Monitorizar el riesgo: Vigilar y revisar periódicamente el riesgo en cuanto a los cambios de
los parámetros asignados de riesgo.
• Aceptar el riesgo: Reconocer el riesgo pero no tomar ninguna acción.

49

1. Opciones de tratamiento documentadas para cada riesgo identificado.
2. Planes de mitigación de riesgo.
3. Planes de contingencia.
4. Lista de los responsables de seguir y tratar cada riesgo.
Subprácticas
1. Determinar los niveles y los límites que definen cuándo un riesgo pasa a ser inaceptable
y dispara la realización de un plan de mitigación de riesgos o un plan de contingencia.
2. Identificar a la persona o al grupo responsable de tratar cada riesgo.
3. Determinar la relación coste/beneficio de la implementación del plan de mitigación de
riesgos para cada riesgo.
4. Desarrollar un plan general de mitigación de riesgos para el proyecto a fin de organizar
la implementación de los planes individuales de mitigación de riesgos y de contingencia
de riesgos.
5. Desarrollar planes de contingencia para los riesgos críticos seleccionados en caso de
que tengan lugar sus impactos.

SP 3.2 IMPLEMENTAR LOS PLANES DE MITIGACIÓN DE RIESGO
Para controlar y gestionar eficazmente los riesgos durante el esfuerzode trabajo, seguir un programa
proactivo para monitorizar regularmente los riesgos, y el estado y los resultados de las acciones de
tratamiento de riesgos.

1. Listas actualizadas del estado del riesgo.
2. Evaluaciones actualizadas de la probabilidad, consecuencia y umbrales límites del de los riesgos.
3. Listas actualizadas de opciones de tratamiento de riesgos.
4. Listas actualizadas de las acciones tomadas para el tratar el riesgo.
5. Planes de mitigación de riesgos.
Subprácticas
1. Monitorizar el estado del riesgo.
2. Proporcionar un método para seguir los elementos de acción de tratamiento de riesgos abiertos hasta
su cierre.
3. Invocar a las opciones de tratamiento del riesgo seleccionadas cuando los riesgos monitorizados
excedan los límites definidos.
4. Establecer un calendario o un período de realización para cada actividad de tratamiento de riesgos
que incluya la fecha de inicio y la fecha anticipada de finalización.
5. Proporcionar el compromiso continuado de los recursos para cada plan, para permitir la realización
con éxito de las actividades de tratamiento de riesgos.
6. Recoger medidas de rendimiento sobre las actividades de tratamiento de riesgos.

50
TECHNICAL SOLUTION (TS)

El propósito de la Solución técnica (TS) es diseñar, desarrollar e implementar soluciones
para los requerimientos. Las soluciones, los diseños y las implementaciones engloban
productos, componentes de producto y procesos del ciclo de vida asociados al producto,
individualmente o en combinación, según sea apropiado.
El área de proceso de Solución técnica es aplicable en cualquier nivel de la arquitectura de

producto y a cada producto, componente de producto y proceso del ciclo de vida asociado al
producto.
El área de proceso se enfoca en:

• Evaluar y seleccionar soluciones (referidas a veces como “planteamiento de diseño”,
“conceptos de diseño” o “diseños preliminares”) que potencialmente satisfacen un conjunto
apropiado de requerimientos 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.

Para un proyecto de mantenimiento o de sostenimiento, los requerimientos necesitados de
acciones de mantenimiento o de rediseño pueden guiarse por las necesidades de los
usuarios o por los defectos latentes en los componentes de producto.
Nuevos requerimientos pueden surgir de cambios en el entorno operativo. Tales

requerimientos pueden descubrirse durante la verificación del producto(s), donde puede
compararse el rendimiento real frente al rendimiento especificado y puede identificarse una
degradación inaceptable.
SP 1.1 DESARROLLAR LAS SOLUCIONES ALTERNATIVAS Y LOS CRITERIOS DE

SELECCIÓN
Necesitan identificarse y analizarse soluciones alternativas, para permitir la selección de una

solución balanceada a través de la vida de producto en términos de coste, de calendario y
de rendimiento.

51

Algunas consideraciones para las soluciones alternativas y los criterios de selección son:
• Coste de desarrollo, fabricación, aprovisionamiento, mantenimiento y soporte, etc.

• Rendimiento.
• Complejidad del componente de producto y de los procesos del ciclo de vida asociados al
producto.
• Robustez de funcionamiento de producto y de las condiciones de uso, modos de
funcionamiento, entornos y variaciones en los procesos del ciclo de vida asociados al
producto.
• Expansión y crecimiento de producto.
• Limitaciones tecnológicas.
• Sensibilidad de los métodos y de los materiales de construcción.
• Riesgo.
• Evolución de los requerimientos y de la tecnología.
• Retirada.
• Capacidades y limitaciones de los usuarios y operadores finales.
• Características de los productos

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.
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 tecnologías de producto para
ventajas competitivas.
3. Identificar los productos COTS candidatos que satisfagan los requerimientos. Estos
requerimientos incluyen:
• Funcionalidad, rendimiento, calidad y fiabilidad.
• Términos y condiciones de las garantías para los productos.
• Riesgos.
• Responsabilidades de los proveedores del mantenimiento y soporte continuo de los productos.
4. Generar soluciones alternativas.
5. Obtener una asignación completa de los requerimientos para cada alternativa.
6. Desarrollar los criterios para seleccionar la mejor solución alternativa.

52

SP 1.2 SELECCIONAR LAS SOLUCIONES DE COMPONENTES DE PRODUCTO
La selección de los componentes de producto que mejor satisfacen los criterios establece
las asignaciones de los requerimientos a los componentes de producto.
La descripción de las soluciones y el fundamento de selección se documentan. La

documentación evoluciona a través del desarrollo mientras se desarrollan soluciones y
diseños detallados y se implementan esos diseños.

1. Decisiones y razonamiento de la selección de componentes de producto.
2. Relaciones documentadas entre los requerimientos y los componentes de producto.
3. Soluciones, evaluaciones y razonamiento documentados.
Subprácticas
1. Evaluar cada solución/conjunto de soluciones alternativas frente a los criterios de
selección establecidos en el contexto de los conceptos y de los escenarios
operacionales.
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 problemas con las soluciones alternativas y con los requerimientos.
4. Seleccionar el mejor conjunto de soluciones alternativas que satisfagan los criterios de
selección establecidos.
5. Establecer los requerimientos asociados con el conjunto seleccionado de alternativas, así
como con el conjunto de requerimientos asignados a esos componentes de producto.
6. Identificar las soluciones de los componentes de producto que serán
reutilizadas o adquiridas.
7. Establecer y mantener la documentación de las soluciones, de las evaluaciones y de los
fundamentos.

53

SP 2.1 DISEÑAR EL PRODUCTO O EL COMPONENTE DE PRODUCTO
El diseño de producto consiste en dos fases amplias que pueden solaparse en la ejecución:
diseño preliminar y detallado. El diseño preliminar establece las capacidades de producto y
la arquitectura de producto, incluyendo particiones de producto, identificaciones de los
componentes de producto, estados y modalidades del sistema, interfaces principales entre
componentes, e interfaces externas de producto.
La arquitectura define los elementos estructurales y los mecanismos de coordinación que

bien satisfacen directamente los requerimientos o bien dan soporte al logro de los
requerimientos cuando se establecen los detalles de diseño de producto.
Los conceptos operacionales y los escenarios se usan para generar casos de uso y
escenarios de calidad que se usan para refinar la arquitectura.

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.
• Identificar las interfaces internas principales y todas las interfaces externas.
• Identificar los componentes de producto e interfaces entre ellos.
• Definir mecanismos de coordinación (p. ej., para software y hardware).
• Establecer capacidades y servicios de la infraestructura.
• Desarrollar plantillas, o clases y marcos de trabajo de componentes de producto.
• Establecer las reglas de diseño y la autoridad para la toma de decisiones.
• Definir un modelo de proceso/flujos de ejecución (threads).
• Definir el despliegue físico del software al hardware.
• Identificar las principales fuentes y aproximaciones de reutilización.

1. Arquitectura de producto.
2. Diseños de componentes de producto.
Subprácticas
1. Establecer y mantener los criterios frente a los cuales puede evaluarse el diseño.

54

Algunos ejemplos de atributos, además del rendimiento previsto, para los cuales pueden
establecerse criterios de diseño, son:
• Modular.
• Claro.
• Simple.
• Fácil de mantener.
• Verificable.
• Portable.
• Fiable.
• Exacto.
• Seguro.
• Escalable.
• Usable.
2. Identificar, desarrollar o adquirir los métodos de diseño apropiados para el producto.

3. Asegurar que el diseño se adhiere a los estándares y a los criterios de diseño aplicables.
4. Asegurar que el diseño se adhiere a los requerimientos asignados.
5. Documentar el diseño.

SP 2.2 ESTABLECER UN PAQUETE DE DATOS TÉCNICOS
Un paquete de datos técnico proporciona al desarrollador una descripción completa de

producto o del componente de producto a medida que se desarrolla.
El paquete de datos técnicos proporciona la descripción de un producto o componente de

producto (incluyendo los procesos del ciclo de vida relativo al producto si no se manipulan
como componentes de producto separados), que da soporte a una estrategia de adquisición,
o de implementación, producción, ingeniería y fases de soporte logístico del ciclo de vida de
producto.
Un paquete de datos técnicos debería incluir lo siguiente, si tal información es apropiada

para el tipo de producto y de componente de producto (por ejemplo, los requerimientos del
material y de fabricación pueden no ser útiles para los componentes de producto asociados
con los servicios o los procesos software):
• Descripción de la arquitectura de producto.

• Requerimientos asignados.
• Descripciones de los componentes de producto.
• Descripciones de los procesos del ciclo de vida asociados al producto, si no se describe
como componente separado de producto.

55

• Características clave de producto.
• Características físicas requeridas y restricciones.
• Requerimientos de la interfaz.
• Requerimientos de materiales (facturas del material y características de los materiales).
• Requerimientos de fabricación y de manufacturación (tanto para el fabricante del equipamiento original
como para el soporte de campo).
• Criterios de verificación usados para asegurar que se han alcanzado los requerimientos.
• Condiciones de uso (entornos) y escenario de operación/uso, modalidades y estados de las operaciones,
soporte, formación, fabricación, retirada, y las verificaciones a lo largo de la vida de producto.
• Razonamiento de las decisiones y de las características (requerimientos, asignaciones de
requerimientos y opciones de diseño).

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.
2. basar las descripciones de diseño detallado en los requerimientos asignados de los componentes de
producto, en la arquitectura y en los diseños de alto nivel.
3. Documentar el diseño en el paquete de datos técnicos.
4. Documentar los fundamentos de las decisiones claves (es decir, efecto significativo sobre coste,
calendario o funcionamiento técnico) hechas o definidas.
5. Corregir el paquete de datos técnicos según sea necesario.

SP 2.3 DISEÑAR LAS INTERFACES USANDO CRITERIOS
Algunos diseños de interfaz son:

• Origen.
• Destino.
• Características de datos y de estímulo para el software.
• Características eléctricas, mecánicas y funcionales para el hardware.
• Líneas de servicio de comunicación.

1. Especificaciones del diseño de la interfaz.
2. Documentos de control de la interfaz.
3. Criterios de la especificación de la interfaz.
4. Fundamentos del diseño seleccionado de la interfaz.
Subprácticas
1 Definir los criterios de la interfaz.
2. Identificar las interfaces asociadas con otros componentes de producto.
3. Identificar las interfaces asociadas con los elementos externos.
4. Identificar las interfaces entre los componentes de producto y los procesos de ciclo de vida asociados al
producto.
5. Aplicar los criterios para las alternativas de diseño de la interfaz.
6. Documentar los diseños de la interfaz seleccionados y los fundamentos de la selección.

56

SP 2.4 REALIZAR LOS ANÁLISIS SOBRE SI HACER, COMPRAR O REUTILIZAR
La determinación de qué productos o componentes de producto serán adquiridos, se denomina

con frecuencia “análisis sobre si hacer-ocomprar”. Se basa en un análisis de las necesidades del
proyecto.
Algunos factores que afectan la decisión de hacer-o-comprar son:
• Funciones que los productos proporcionarán y cómo estas funciones se adecuarán en el

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 requerimientos de negocio de alto nivel.
• Investigación de mercado de productos disponibles, incluyendo productos.
• Funcionalidad y calidad de productos disponibles.
• Habilidades y capacidades de proveedores potenciales.
• Impactos en las competencias básicas de negocio.
• Licencias, garantías, responsabilidades y limitaciones asociadas con los productos que están
siendo adquiridos.
• Disponibilidad de producto.
• Aspectos de propiedad.
• Reducción del riesgo.

1. Criterios para el diseño y la reutilización de los componentes de producto.

2. Análisis hacer o comprar.
3. Guías para elegir componentes de producto.
Subprácticas
1. Desarrollar los criterios para la reutilización de los diseños de los componentes de
producto.
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 consideran los elementos
comprados o no desarrollados (p. ej., productos comerciales gubernamentales y de
reutilización).

57

SP 3.1 IMPLEMENTAR EL DISEÑO
La implementación del diseño en el nivel superior de la jerarquía de producto involucra la

especificación de cada uno de los componentes de producto en el siguiente nivel de la
jerarquía de producto.

1. Diseño implementado.
Subprácticas
1. Usar métodos eficaces para implementar los componentes de producto.
2. Adherirse a los estándares y a los criterios aplicables.
3. Llevar a cabo revisiones entre pares de los componentes seleccionados de producto.
4. Realizar pruebas unitarias del componente de producto según sea apropiado.
5. Corregir el componente de producto según sea necesario.

SP 3.2 DESARROLLAR LA DOCUMENTACIÓN DE SOPORTE DE 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 requerimientos, el diseño, el producto y los resultados de pruebas para
asegurar que se identifican y resuelven los problemas 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 instalación, de operación
y de mantenimiento.
3. Adherirse a los estándares aplicables de documentación.
5. Llevar a cabo revisiones entre pares de la documentación de instalación, de operación y
de mantenimiento.
6. Corregir la documentación de instalación, de operación y de mantenimiento según sea
necesario.

58
MEJORES PRACTICAS EN
DESARROLLO DE SOFTWARE
Basado en el modelo CMMI-DEV
v1.2

59
INTRODUCCIÓN
Estrategia general para el desarrollo
rápido
Mejor planificación posible
Evitar errores Bases del Gestión de Métodos

clásicos desarrollo riesgos orientados a la
planificación
INTRODUCCIÓN
Cuatro dimensiones de la velocidad de
desarrollo
Personas
Procesos Producto
Tecnología

60
INTRODUCCIÓN
desarrollo
• Personas: OT, SAM
• Procesos: OPD, OPF, PPQA, OPP
• Producto: PI, RSKM, DAR, MA
• Tecnología: TS, VAL, VER
• ¿Dónde ubicarían las áreas de proceso aplicables a proyectos?

– IPM
– PMC
– PP
– QPM
– RD
– RM
INTRODUCCIÓN
desarrollo
Personas Producto
Selección del personal Tamaño del producto
Organización del equipo Características del producto
Motivación
Proceso Tecnología
Evitar repetición de trabajo Herramientas más efectivas
Control de Calidad Componentes
Bases del desarrollo Reutilización
Gestión de riesgos Librerías base
Atención a los recursos
Planificación del ciclo de vida

61
INTRODUCCIÓN
¿Cuál es la dimensión más importante?
Boeing, Microsoft, NASA, Raytheon y otras empresas han aprendido a

desarrollar software de forma que se ajuste a sus necesidades. A nivel
estratégico, estas distintas empresas tienen bastante en común:
• Han aprendido a evitar errores clásicos.

• Aplican las bases de desarrollo.
• Realizan una gestión activa de riesgos.
Diferentes proyectos tienen diferente necesidades, pero en todos los casos la

clave es aceptar los límites en las dimensiones que no podemos cambiar.
CONCLUSIÓN: Todas las dimensiones son importantes. Siempre hay que

buscar el equilibrio dentro de las restricciones del proyecto.
INTRODUCCIÓN
Ejemplos de Errores Clásicos
TALLER 2

62
INTRODUCCIÓN
Errores relacionados Errores relacionados Errores relacionados Errores relacionados
con las personas con el proceso con el producto con la tecnología
Motivación débil Planificación excesivamente Exceso de requerimientos Síndrome de la panacea
optimista
Personal mediocre Gestión de riesgos Cambio en las prestaciones Sobreestimación de las
insuficiente ventajas del empleo de
nuevas herramientas o
métodos
Empleados problemáticos Incumplimiento de los Desarrolladores meticulosos Cambiar de herramientas a
no controlados freelance la mitad del proyecto
Hazañas Planificación insuficiente Tire y afloje en la Falta de control automático
negociación del código fuente
Añadir mas personal a un Abandono de la Desarrollo orientado a la
proyecto retrasado planificación bajo presión investigación
Oficinas repletas y ruidosas Perdida de tiempo en el
inicio disperso
Fricciones entre clientes y Escatimar en las
desarrolladores actividades iniciales
Expectativas poco realistas Diseño inadecuado
INTRODUCCIÓN
Errores relacionados Errores relacionados Errores relacionados Errores relacionados
con las personas con el proceso con el producto con la tecnología
Falta de un promotor Escatimar en el control de
efectivo del proyecto calidad
Falta de participación de los Control insuficiente de la
implicados directiva
Falta de participación del Convergencia prematura o
usuario excesivamente frecuente
Política antes que desarrollo Omitir tareas necesarias en
la estimación
Ilusiones Planificar ponerse al día
mas adelante
Programación a destajo

63
INTRODUCCIÓN
Efectos de los errores en la programación
de un desarrollo
• Motivación débil
• Personal mediocre
• Empleados problemáticos
• Hazañas
• Añadir más personal a un proyecto retrasado
• Oficinas repletas y ruidosas
• Expectativas poco realistas
• Falta de un promotor efectivo del proyecto
• Política antes que desarrollo
• Planificación excesivamente optimista
• Planificación insuficiente
• Pérdida de tiempo en el inicio disperso
• Escatimar en las actividades iniciales
• Diseño inadecuado
GESTIÓN DE RIESGOS
Elementos de la gestión de riesgos
Identificación
de riesgos
Estimación de Análisis de
Riesgos Riesgos
Priorización
de Riesgos
Gestión de
Riesgos Planificación
de la gestión
de riesgos
Control de Resolución de
Riesgos riesgos
Monitorización
de riesgos

64
GESTIÓN DE RIESGOS
Identificación
Es el primer paso y su propósito es identificar los factores que introducen un

riesgo en la planificación. Hay tres riesgos generales en un desarrollo rápido:
• Cometer uno de los errores clásicos.

• Ignorar las bases del desarrollo rápido.
• Fallar en la gestión activa de riesgos.
GESTIÓN DE RIESGOS
Identificación
Riesgos más habituales en la planificación:
• Cambio de requerimientos
• Excesivo detalle.
• Escatimar en la calidad.
• Planificaciones demasiado optimistas.
• Diseño inadecuado.
• Síndrome de la panacea.
• Desarrollo orientado a la investigación.
• Personal mediocre.
• Error en la contratación.
• Diferencias entre el personal de desarrollo y los clientes.

65
GESTIÓN DE RIESGOS
Análisis
Probabilidad Magnitud de Exposición
Riesgo de pérdida la Pérdida al riesgo
(50%) (semanas) (semanas)
Riesgo 1
Riesgo 2
Riesgo 3
.
.
.
Riesgo n
GESTIÓN DE RIESGOS
Análisis
• Estimación de la magnitud de la pérdida: Siempre esta sujeta al tiempo, es decir,
horas, días, semanas o meses.
• Estimación de la probabilidad de la pérdida: Es muy subjetiva y se puede adoptar

alguna de las siguientes técnicas:
• Disponer de una persona con más experiencia con el sistema que estime la
probabilidad de cada riesgo.
• Consenso de grupo hasta que converjan las estimaciones.
• Elección mediante adjetivos como muy probable, bastante probable, probable,
improbable y muy improbable. Tabular y cuantificar.
• Estimación de la exposición al riesgo: Un riesgo es una pérdida no esperada.
La exposición al riesgo es igual a la probabilidad de perdida no esperada multiplicada

por la magnitud de la pérdida. Por ejemplo, si piensa que la probabilidad es del 25% y
puede haber un retraso de 4 semanas, la exposición al riesgo sería:
25% x 4 = 1 semana

66
GESTIÓN DE RIESGOS
Priorización
Una vez tabulados los valores para los diferentes riesgos priorice de acuerdo a
la necesidad del proyecto.
GESTIÓN DE RIESGOS
Control
• Planificación de la gestión de riesgos
Su objetivo es desarrollar un plan que controle cada uno de los riesgos de

prioridad alta identificados. Puede ser tan sencillo como un párrafo para cada
riesgo, describiendo quien, que, cuando y como se gestiona.
• Resolución de riesgos
• Evite el riesgo
• Traslade el riesgo de una parte del sistema a otra
• Obtenga información acerca del riesgo
• Elimine el origen del riesgo
• Asuma el riesgo
• Comunique el riesgo
• Controle el riesgo
• Recuerde el riesgo

67
GESTIÓN DE RIESGOS
Identificación
Taller 3
GESTIÓN DE RIESGOS
Riesgo alto y azar
• Es difícil encontrar algún proyecto que no implique ningún riesgo, y los
proyectos que solo son riesgos son apropiados para alcanzar la máxima
velocidad de desarrollo.
• Los riesgos tienden a alargar los planes de desarrollo, y los riesgos altos
tienen a prolongarlos más. Sin embargo, la realidad empresarial obliga a
encargarse de un plan de desarrollo ambicioso.
• Si se ve obligado a encargarse de un plan ambicioso, infórmese de la

naturaleza del compromiso. Explíqueles a las personas que dependen de
usted que esta dispuesto a tomar riesgos calculados, pero que probablemente
no va a alcanzar a entregar a tiempo.
• No deje nada al azar, sea riguroso en la identificación, monitoreo y control de

los riesgos más altos que haya determinado con el equipo.

68
FUNDAMENTOS PARA EL DESARROLLO RÁPIDO

¿Qué tipo de desarrollo rápido necesita?
Siempre debe plantearse las siguientes preguntas:
• ¿Cuál es la fuerza de la restricción de planificación del producto?
•¿El énfasis en la planificación del proyecto ha surgido porque es realmente

una de las “apariencias del desarrollo rápido”?
• ¿Su proyecto esta limitado por cualquier punto débil que podría impedir llevar
a cabo el desarrollo rápido con éxito?

¿Qué tipo de desarrollo rápido necesita?
Productos típicos
Valor del
Producto
Productos con fuertes

restricciones de
planificación
Tiempo

69

Distribución del tiempo empleado
Consiste en determinar el área en la que se emplea la mayoría del tiempo en

un proyecto típico, y entonces intentar reducir dicho tiempo.
Punto de vista clásico: Fase por Fase (Arquitectura/diseño, diseño

detallado, codificación/depuración, pruebas unitarias, integración, pruebas
integrales)
Puntos clave
• Trabajo repetido
• Cambio de requerimientos
• Especificación de requerimientos
• Inicio disperso o difuso

Distribución del tiempo empleado
Inicio disperso o difuso: La mayoría de directivos tienden a dar poca
prioridad a esta fase, porque el impacto financiero esta lejos. En el inicio
difuso, puede perder tiempo por estas razones:
• Nadie tiene asignada la responsabilidad del desarrollo del producto.

• No existe una sensación de urgencia para realizar una decisión de
comenzar/no comenzar a desarrollar el producto.
• Los aspectos clave de la viabilidad del producto (viabilidad técnica y
atractivo en el mercado) no pueden ser explorados hasta que se aprueba el
presupuesto del proyecto.
• El producto debe esperar un ciclo normal de aprobación de productos o
presupuestos antes de que pueda tener aprobado el presupuesto.
• El equipo que desarrolla el producto no se forma a partir del equipo que ha
trabajado para la aprobación del proyecto.

70

Patrón típico de la mejora de la planificación
Planificación Planificación
Inicial al 50/50
Probabilidad de
terminar exactamente
en la fecha programada
Fecha final programada
• Muchos proyectos tienen retrasos significativos

Patrón típico de la mejora de la planificación
La planificación inicial y la
planificación 50/50 son
iguales
Probabilidad de
terminar exactamente
• Los proyectos con desarrollo eficiente, la variación de la planificación es menor.

• La mayoría de los proyectos se acercan a sus objetivos de costo y planificación.

71

Camino hacia el desarrollo rápido
Reducir el
riesgo
Probabilidad de Aumentar la
terminar exactamente velocidad
Proyectos
Comunes

Camino hacia el desarrollo rápido
Los enfoques que contribuyen al desarrollo rápido son:
• Planificación del ciclo de vida

• Estimación
• Planificación
• Desarrollo orientado al cliente
• Motivación
• Equipo de trabajo
• Estructura del equipo
• Control del conjunto de requerimientos
• Herramientas para aumentar la productividad
• Recuperación de proyectos

72
DESARROLLO ORIENTADO AL CLIENTE

Importancia del cliente en el desarrollo rápido
• Algunos expertos en desarrollo rápido sostienen que la buena comunicación con el
usuario final es uno de los tres factores críticos de los proyectos de desarrollo rápido.
• Las tres razones principales para que los proyectos se terminen tarde, sobrepasen el
presupuesto y tengan una funcionalidad inferior a la deseada son:
• Deficiencia en la participación del usuario
• Especificación de requerimientos incompletas
• Modificación de los requerimientos y especificaciones
• Las buenas relaciones con los clientes aumentan la velocidad de desarrollo actual. Si su
relación es de colaboración en lugar de rivalidad, eliminará una fuente importante de
ineficiencia y errores de desarrollo importantes.
• Las buenas relaciones con los clientes mejoran la percepción de la velocidad de

desarrollo. Si estructura su proyecto de manera que se pueda ver claramente el progreso,
hará que aumente la confianza, con lo que la velocidad de desarrollo será una
preocupación menor.
GESTIÓN DE RIESGOS
Priorización y Matriz
Taller 4

73

El propósito de la Gestión de riesgos (RSKM) es identificar los 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 para alcanzar los objetivos.
La gestión de riesgos eficaz incluye la identificación temprana y agresiva de cada riesgo a

través de la colaboración y la involucración de las partes interesadas relevantes, tal y como
se describió en el plan para la involucración de las partes interesadas tratado en el área de
proceso de Planificación de proyecto.
La gestión de riesgos puede dividirse en tres partes: definir una estrategia de gestión de
riesgos, identificar y analizar los riesgos, y manejar los riesgos identificados, incluyendo la
implementación de los planes de mitigación de riesgo, cuando sea necesario.

SP 1.1 DETERMINAR LAS FUENTES Y LAS CATEGORÍAS DE LOS RIESGOS
La identificación de las fuentes de riesgo proporciona una base para examinar

sistemáticamente situaciones cambiantes en el tiempo para descubrir circunstancias que
impactan a la capacidad del proyecto en el cumplimiento de sus objetivos.
Establecer categorías para los riesgos proporciona un mecanismo para recoger y

organizarlos, así como asegurar el escrutinio apropiado y la atención del nivel de gerencia
para aquellos riesgos que puedan tener consecuencias más serias para el cumplimiento de
los objetivos del proyecto.

1. Listas de fuentes de riesgo (externas e internas).
2. Lista de categorías de riesgos.
Subprácticas
1.Determinar las fuentes de riesgo.

74

Las típicas fuentes de riesgo internas y externas incluyen:
• Requerimientos incompletos.
• Esfuerzos sin precedentes — estimaciones no disponibles.
• Diseño inviable.
• Tecnología no disponible.
• Estimaciones o asignación de calendario no realistas.
• Recursos de personal y habilidades inadecuadas.
• Problemas de coste o financiación.
• Capacidad del subcontratista incierta o inadecuada.
• Capacidad del vendedor incierta o inadecuada.
• Comunicación inadecuada con los clientes actuales o potenciales o con sus
representantes.
• Interrupciones de la continuidad de las operaciones.
2. Determinar las categorías de riesgo Las categorías de riesgo reflejan las “divisiones” para
recoger y organizarlos riesgos. Una razón para identificar categorías de riesgo es ayudar
en la futura consolidación de las actividades de los planes de mitigación de riesgo.

SP 1.2 DEFINIR LOS PARÁMETROS DE LOS RIESGOS
Los parámetros para evaluar, categorizar y priorizar los riesgos incluyen:
• 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 disparar las actividades de gestión.

1. Evaluación y categorización de riesgo, y criterios de priorización.
2. Requerimientos de la gestión de riesgos (p. ej., niveles de control y de aprobación, e
intervalos de reevaluación).
Los siguientes factores pueden considerarse cuando se determinan

categorías de riesgo:
• Las fases del modelo de ciclo de vida del proyecto (p. ej., requerimientos,
diseño, fabricación, prueba y evaluación, entrega y retirada).
• Los tipos de procesos usados.
• Los tipos de productos usados.

75

• Los riesgos de la gestión del programa (p. ej., riesgos del contrato, riesgos del
presupuesto/coste, riesgos de calendario, riesgos de recursos, riesgos de rendimiento y
riesgos de mantenimiento).
Subprácticas
1.Definir criterios consistentes para evaluar y cuantificar la probabilidad de riesgo y los
niveles de gravedad.
2.Definir umbrales para cada categoría de riesgo.
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.
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 en coste (CPIs) caigan por debajo del 0,95.
• Los umbrales de calendario podrían establecerse para involucrar a la 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 dirección cuando
los elementos claves especificados (p. ej., la utilización del procesador o los tiempos medios
de respuesta) superan el 125 por ciento del diseño previsto.

SP 2.1 IDENTIFICAR LOS RIESGOS
La identificación de problemas 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 con éxito.
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 riesgo no debería ser un intento para tratar cada evento posible,
independientemente de cómo de improbable pueda ser.
Hay muchos métodos para identificar los riesgos. Los métodos típicos de identificación
incluyen:
• Examinar cada elemento de la estructura de descomposición de tareas del proyecto para
descubrir riesgos.
• Llevar a cabo una evaluación de riesgos usando una taxonomía de riesgos.
• Entrevistar a expertos en la materia.
• Revisar los esfuerzos de la 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 requerimientos del contrato.

76

SP 1.3 ESTABLECER UNA ESTRATEGIA DE GESTIÓN DE RIESGOS
Una estrategia de gestión de riesgos exhaustiva trata elementos tales como:
• El alcance del esfuerzo de la 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.
• Fuentes específicas de riesgos del proyecto.
• La forma que estos riesgos se organizarán, categorizarán, compararán y consolidarán.
• Los parámetros, incluyendo la probabilidad, consecuencia y umbrales, para actuar sobre
los riesgos identificados.
• Técnicas de mitigación de riesgos que serán usadas, tales como prototipos, pilotos,
simulación, diseños alternativos o desarrollo evolutivo.
• Definición de medidas de riesgo para monitorizar el estado de los riesgos.
• Intervalos de tiempo para la monitorización o revisión del riesgo.

1. Estrategia de gestión de riesgos del proyecto.

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.
2.Revisar elementos ambientales que pueden impactar en el proyecto.
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 todos los aspectos del esfuerzo de
trabajo han sido considerados.
4.Revisar todos los elementos del plan del proyecto como parte de la identificación de
riesgos para ayudar a asegurar que todos aspectos del proyecto han sido considerados.
5.Documentar el contexto, las condiciones y las consecuencias potenciales del riesgo.
6.Identificar las partes interesadas relevantes asociadas con cada riesgo.

77

SP 2.2 EVALUAR, CATEGORIZAR Y PRIORIZAR LOS RIESGOS
La evaluación de los riesgos es necesaria para asignar la importancia relativa

a cada riesgo identificado, y se usa en la determinación de cuándo
se requiere la atención apropiada de la gerencia.

1. Lista de riesgos, con una prioridad asignada a cada riesgo.
Subprácticas
1.Evaluar los riesgos identificados usando los parámetros de riesgo definidos.
2.Clasificar y agrupar los riesgos de acuerdo a las categorías de riesgo definidas.
3.Priorizar los riesgos para la mitigación.

SP 3.1 DESARROLLAR LOS PLANES DE MITIGACIÓN DE RIESGOS
Un componente crítico de un plan de mitigación de riesgos es desarrollar cursos de acción

alternativos, soluciones temporales y posiciones de repliegue, con un curso de acción
recomendado para cada riesgo crítico.
Los riesgos se monitorizan y, cuando sobrepasan los límites establecidos, los planes de
mitigación de riesgo se realizan para devolver el esfuerzo impactado a un nivel de riesgo
aceptable.
Algunas de las opciones para tratar los riesgos normalmente

son:
• Evitar el riesgo: Cambiar o reducir los requerimientos mientras todavía cumplan las
necesidades del usuario.
• Controlar el riesgo: Llevar a cabo etapas activas para minimizar los riesgos.
• Transferir el riesgo: Reasignar requerimientos para reducir los riesgos.
• Monitorizar el riesgo: Vigilar y revisar periódicamente el riesgo en cuanto a los cambios de
los parámetros asignados de riesgo.
• Aceptar el riesgo: Reconocer el riesgo pero no tomar ninguna acción.

78

1. Opciones de tratamiento documentadas para cada riesgo identificado.
2. Planes de mitigación de riesgo.
3. Planes de contingencia.
4. Lista de los responsables de seguir y tratar cada riesgo.
Subprácticas
1.Determinar los niveles y los límites que definen cuándo un riesgo pasa a ser inaceptable y
dispara la realización de un plan de mitigación de riesgos o un plan de contingencia.
2.Identificar a la persona o al grupo responsable de tratar cada riesgo.
3.Determinar la relación coste/beneficio de la implementación del plan de mitigación de
riesgos para cada riesgo.
4.Desarrollar un plan general de mitigación de riesgos para el proyecto a fin de organizar la
implementación de los planes individuales de mitigación de riesgos y de contingencia de
riesgos.
5.Desarrollar planes de contingencia para los riesgos críticos seleccionados en caso de que
tengan lugar sus impactos.

SP 3.2 IMPLEMENTAR LOS PLANES DE MITIGACIÓN DE RIESGO
Para controlar y gestionar eficazmente los riesgos durante el esfuerzode trabajo, seguir un programa
proactivo para monitorizar regularmente los riesgos, y el estado y los resultados de las acciones de
tratamiento de riesgos.

1. Listas actualizadas del estado del riesgo.
2. Evaluaciones actualizadas de la probabilidad, consecuencia y umbrales límites del de los riesgos.
3. Listas actualizadas de opciones de tratamiento de riesgos.
4. Listas actualizadas de las acciones tomadas para el tratar el riesgo.
5. Planes de mitigación de riesgos.
Subprácticas
1.Monitorizar el estado del riesgo.
2.Proporcionar un método para seguir los elementos de acción de tratamiento de riesgos abiertos hasta su
cierre.
3.Invocar a las opciones de tratamiento del riesgo seleccionadas cuando los riesgos monitorizados
excedan los límites definidos.
4.Establecer un calendario o un período de realización para cada actividad de tratamiento de riesgos que
incluya la fecha de inicio y la fecha anticipada de finalización.
5.Proporcionar el compromiso continuado de los recursos para cada plan, para permitir la realización con
éxito de las actividades de tratamiento de riesgos.
6. Recoger medidas de rendimiento sobre las actividades de tratamiento de riesgos.

79
• El propósito de la Gestión de configuración (CM) es establecer y mantener la

integridad de los productos de trabajo utilizando la identificación de
configuración, el control de configuración, el registro del estado de
configuración y las auditorías de configuración.
• El área de proceso de Gestión de configuración implica:

– 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 especificaciones para construir los productos de trabajo a partir del
– Mantener la integridad de las líneas base.
– Proporcionar a los desarrolladores, usuarios finales y clientes datos del estado exacto y de la
configuración actual.
• Los productos de trabajo situados bajo gestión de configuración incluyen los

productos que se entregan al cliente, los productos de trabajo internos
designados, los productos adquiridos, las herramientas y otros elementos que
se usan para crear y describir estos productos de trabajo.
• Algunos ejemplos de productos de trabajo que pueden ponerse bajo gestión

de configuración son:
– Planes.
– Descripciones de proceso.
– Requerimientos.
– Datos de diseño.
– Dibujos.
– Especificaciones de producto.
– Código.
– Compiladores.
– Ficheros de datos de producto.
– Publicaciones técnicas de producto.
• Un ejemplo de una línea base es una descripción aprobada de un producto

que incluye versiones internamente consistentes de requerimientos, de
matrices de trazabilidad de requerimientos, de diseño, de elementos
específicos de una disciplina y de la documentación del usuario final.

80
• Los cambios a las líneas base y la liberación de los productos de trabajo

construidos a partir del sistema de gestión de configuración se controlan y se
siguen vía las funciones de control de configuración, de gestión del cambio y
de auditoría de configuración pertenecientes a la gestión de configuración.
• La gestión de configuración se enfoca en el control riguroso de los aspectos

de gestión y técnicos de los productos de trabajo, incluyendo el sistema
entregado.
SP 1.1 IDENTIFICAR ELEMENTOS DE CONFIGURACIÓN:
La identificación de la configuración es la selección, creación y especificación

de:
• Productos que se entregan al cliente.

• Productos de trabajo internos designados.
• Productos adquiridos.
• Herramientas y otros activos esenciales del entorno de trabajo del proyecto.
• Otros elementos que se utilizan en la creación y la descripción de estos
productos de trabajo.

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.

81
2. Asignar identificadores únicos a los elementos de configuración.
3. Especificar las características importantes de cada elemento de configuración.
4. Especificar cuándo cada elemento de configuración se pone bajo gestión de

configuración.
Algunos ejemplos de criterios para determinar cuándo poner los productos de

trabajo bajo gestión de configuración son:
• Etapa del ciclo vida del proyecto.

• Cuándo el producto del trabajo está listo para las pruebas.
• Grado de control deseado en el producto de trabajo.
• Limitaciones de coste y de calendario.
• Requerimientos del cliente.
5. Identificar al propietario responsable de cada elemento de configuración.

SP 1.2 ESTABLECER UN SISTEMA DE GESTIÓN DE CONFIGURACIÓN
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 en la gestión de la
configuración.
2.Guardar y recuperar los elementos de configuración en un sistema de gestión de
configuración.
3.Compartir y transferir los elementos de configuración entre los niveles de control dentro del
4.Almacenar y recuperar versiones archivadas de elementos de configuración.
5.Almacenar, actualizar y recuperar los registros de gestión de configuración.
6. Crear informes de gestión de configuración a partir del sistema de gestión de
configuración.
7. Preservar los contenidos del sistema de gestión de configuración.
8. Corregir la estructura de gestión de configuración según sea necesario.

82

SP 1.3 CREAR O LIBERAR LÍNEAS BASE
Una línea base es un conjunto de especificaciones o de productos de trabajo que ha sido

revisado y acordado formalmente, que a partir de entonces sirve como base para el
desarrollo o la entrega posterior, y que solamente puede cambiarse mediante
procedimientos de control de cambio.

1. Líneas base.
2. Descripción de las líneas base.
Subprácticas
1. Obtener la autorización del Comité de control de configuración (CCB) antes de crear o
liberar líneas base de elementos de configuración.
2. Crear o liberar líneas base sólo desde 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. Hacer fácilmente disponible el conjunto actual de líneas base.

SP 2.1 SEGUIR LAS PETICIONES DE CAMBIO
Las peticiones de cambio se analizan para determinar el impacto que el cambio tendrá 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.
3. Revisar las peticiones de cambio, que serán tratadas en la siguiente línea base, con las
partes interesadas relevantes y conseguir su acuerdo.
4. Seguir el estado de las peticiones de cambio hasta su cierre.

83

SP 2.2 CONTROLAR LOS ELEMENTOS DE CONFIGURACIÓN
Este control incluye el seguimiento de la configuración de cada uno de los elementos de

configuración, aprobando una nueva configuración, en caso de ser necesario, y actualizando la
línea de base.

1. Historial de revisiones de los elementos de configuración.
2. Archivos de las líneas base.
Subprácticas
1. Controlar los cambios a los elementos de configuración a lo largo de la vida del producto.
2. Obtener la autorización apropiada antes que los elementos de configuración cambiados sean
introducidos en el sistema de gestión de configuración.
3. Comprobar la entrada (check-in) y la salida (check-out) de los elementos de configuración
desde el sistema de gestión de configuración para la incorporación de los cambios de forma que
se mantenga la exactitud y la integridad de los elementos de configuración.
4. Realizar revisiones para asegurar que los cambios no han causado efectos involuntarios en las
líneas base (p. ej., asegurar que los cambios no hayan comprometido la seguridad y/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.

SP 3.1 ESTABLECER REGISTROS DE GESTIÓN DE CONFIGURACIÓN

1. Historial de revisión de los elementos de configuración.
2. Registro de cambios.
3. Copia de las peticiones de cambio.
4. Estado de los elementos de la configuración.
5. Diferencias entre líneas base.
1.Registrar las acciones de gestión de configuración con suficiente detalle, para que sea
conocido el contenido y el estado de cada elemento de configuración, y que puedan
recuperarse las versiones anteriores.
2.Asegurar que las partes interesadas relevantes tengan acceso y conocimiento del estado
de la configuración de los elementos de configuración.
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. Corregir cuando sea necesario el estado y la historia (es decir, cambiosy otras acciones)
de cada elemento de configuración.

84

SP 3.2 REALIZAR AUDITORÍAS DE CONFIGURACIÓN
Las auditorías de configuración confirman que el resultado de las líneas base y de la

documentación están conformes con un estándar o requerimiento especificado. Los
resultados de la auditoría deberían registrarse.

1. Resultados de la auditoria 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 configuración son completos y
correctos.
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.
INTEGRATED PROJECT MANAGEMENT(IPM)

El propósito de la Gestión integrada de 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 de la organización.
La Gestión integrada de proyecto implica:
• Establecer el proceso definido del proyecto al inicio del mismo, mediante la adaptación del
conjunto de procesos estándar de la organización.
• 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.
• Utilizar y contribuir a los activos de proceso de la organización.
• Permitir que las inquietudes de las partes interesadas relevantes sean identificadas,
consideradas, y, cuando sea apropiado, tratadas durante el desarrollo del producto.
• Asegurar que las partes interesadas relevantes realizan sus tareas de una forma
coordinada y oportuna (1) para tratar los requerimientos
del producto y de los componentes del producto, los planes, los objetivos, los problemas y
los riesgos; (2) para satisfacer sus compromisos; y (3) para identificar, seguir y resolver los
problemas de coordinación.

85

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 requerimientos, diseño y verificación).

• Actividades de servicio (p. ej., entrega, help desk, operaciones y contacto con el cliente).
• Actividades de adquisición (p. ej., propuesta, monitorización del contrato y transición a
operación).
• Actividades de soporte (p. ej., gestión de configuración, documentación, marketing y
formación).
SG 1 UTILIZAR EL PROCESO DEFINIDO DEL PROYECTO
El proceso definido del proyecto debe incluir aquellos procesos del conjunto de procesos
estándar de la organización que tratan todos los procesos necesarios para adquirir o
desarrollar y mantener el producto.
SP 1.1 ESTABLECER EL PROCESO DEFINIDO DEL PROYECTO
El proceso definido del proyecto consiste en procesos definidos que forman un ciclo de vida
integrado y coherente para el proyecto.

El proceso definido del proyecto se basa en los siguientes factores:
• Requerimientos de cliente.
• Requerimientos del producto y de los componentes de producto.
• Compromisos.
• Objetivos y necesidades del proceso de la organización.
• Conjunto de procesos estándar y guías de adaptación de la organización.
• Entorno operacional.
• Entorno del negocio.
Conforme el proyecto progresa, la descripción del proceso definido del proyecto se elabora y
corrige para un mejor cumplimiento de los requerimientos del proyecto, y las necesidades y
objetivos de proceso de la organización.

1.El proceso definido del proyecto.
Subprácticas
1. Seleccionar un modelo de ciclo de vida a partir de aquellos disponibles en los activos de
proceso de la organización.

86

2. Seleccionar los procesos estándar a partir del conjunto de procesos estándar de la
organización que mejor se ajusten a las necesidades
del proyecto.
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 producir el proceso definido
del proyecto.
4. Utilizar otros artefactos de la biblioteca de activos de proceso de la organización según

sea apropiado.
5. Documentar el proceso definido del proyecto.
6. Realizar revisiones entre pares del proceso definido del proyecto.
7. Corregir 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

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.
2.Utilizar el repositorio de medición de la organización para estimar los parámetros de
planificación del proyecto.
Esta estimación normalmente incluye:

• Utilizar los datos históricos apropiados de este proyecto o de proyectos similares.
• Explicar y registrar las semejanzas y diferencias entre el proyecto actual y aquellos
proyectos cuyos datos históricos se usen.
• Validar de manera independiente los datos históricos.
• Registrar el razonamiento, las suposiciones y el fundamento utilizado para seleccionar los
datos históricos.

87

SP 1.3 ESTABLECER EL ENTORNO DE TRABAJO DEL PROYECTO
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 apoyo de los objetivos de negocio y del proyecto.

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.
2.Proporcionar el mantenimiento y el soporte operacional continuos para el entorno de
trabajo del proyecto.
3.Mantener la organización de los componentes del entorno de trabajo del proyecto.
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.

SP 1.4 INTEGRAR LOS PLANES.
El desarrollo del plan del proyecto debería tener en cuenta las necesidades actuales y
proyectadas, los objetivos y los requerimientos de la organización, del cliente, de los
proveedores y de los usuarios finales, según sea apropiado.

1.Planes integrados.
Subprácticas
1. Integrar otros planes que afectan al proyecto con el plan del proyecto.
Otros planes que afectan al proyecto pueden incluir:
• Planes de aseguramiento de la calidad.
• Planes de gestión de la configuración.
• Estrategias de gestión de riesgos.
• Planes de documentación.
2. Incorporar al plan del proyecto las definiciones de las medidas y de las actividades de
medición para gestionar el proyecto.

88

3. Identificar y analizar los riesgos de la interfaz del proyecto y del producto.
4. Programar las tareas en una secuencia que tenga en cuenta los factores críticos del
desarrollo y los riesgos del proyecto.
5. Incorporar los planes para realizar revisiones entre pares sobre los productos de trabajo
del proceso definido del proyecto.
6. Incorporar la formación necesaria para ejecutar el proceso definido del proyecto en los
planes de formación del proyecto.
7. Establecer los 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).
8. Asegurar que el plan del proyecto es apropiadamente compatible con los planes de las
partes interesadas relevantes.
9. Identificar cómo serán resueltos los conflictos que surjan entre las partes interesadas
relevantes.
SP 1.5 GESTIONAR EL PROYECTO UTILIZANDO LOS PLANES INTEGRADOS

1. Productos de trabajo creados al realizar el proceso definido del proyecto.
2. Medidas recogidas (“reales”) y registros o informes de progreso.
3. Requerimientos, planes y compromisos corregidos.
4. Planes integrados.

Subprácticas
1.Implementar el proceso definido del proyecto utilizando la biblioteca de activos de proceso
de la organización.
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 afectan al proyecto.
3.Obtener y analizar las medidas seleccionadas para gestionar el proyecto y dar soporte a
las necesidades de la organización.
4.Revisar y alinear periódicamente el rendimiento del proyecto conlas necesidades, objetivos
y requerimientos actuales y previstos de la organización, del cliente y de los usuarios finales,
según sea apropiado.
SP 1.6 CONTRIBUIR 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 de proceso, planes, módulos
de formación, listas de comprobación y lecciones aprendidas ejemplares).
4. Artefactos de proceso asociados a la adaptación al proyecto e implementación
del conjunto de procesos estándar de la organización.

89

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 medición de la
organización.
3. Enviar la documentación para su posible inclusión en la biblioteca de activos de proceso
de la organización.
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 organización en apoyo de las actividades de
monitorización del proceso de la organización.

Métodos orientados al cliente
• Mejora la eficiencia.
• Menor trabajo repetido.
• Reducción de riesgos.
• Ausencia de fricción.
• Los métodos orientados al cliente se pueden dividir en las siguientes

categorías:
• Planificación
• Análisis de requerimientos
• Diseño
• Construcción

90

Métodos orientados al cliente
Categoría Método
Planificación Seleccione un modelo de ciclo de vida apropiado
Identifique al cliente real
Establezca un método eficiente para interactuar con el cliente
Cree un proyecto satisfactorio para todos
Gestión de riesgos
Análisis de requerimientos Recopilar requerimientos reales
Convergencia de interpretación (cliente: amplia, desarrollador: reducida)
Utilización de métodos de recopilación
Creación de grupos, grabación en video, realización de encuestas
Diseño Utilización de métodos de diseño que permitan al cliente cambiar de opinión
ocasionalmente
Construcción Métodos de implementación que creen un código legible y modificable
rápidamente
Utilice métodos de monitoreo del progreso, para informar al cliente sobre él.
Seleccione un modelo de ciclo de vida que ofrezca al cliente signos de

progreso tangibles.

Gestión de las expectativas del cliente
• Muchos de los problemas se derivan de la falta de cumplimiento de

expectativas que no eran realistas.
• Establezca de forma explicita las expectativas para poder sacar a la luz las
suposiciones poco realistas de sus clientes.
• Esforzarse por entender las expectativas del cliente ahorra muchas fricciones
y trabajo extra.
• Probablemente hayan tenido alguna experiencia con clientes que no

entienden algo que es tan básico que no se le haya ocurrido siquiera que sea
posible que no le comprendan.
• Parte del trabajo de los desarrolladores es educar a los clientes para que
comprendan mejor el desarrollo de software.

91
HERRAMIENTAS PARA AUMENTAR LA PRODUCTIVIDAD

Papel de las herramientas de la productividad en el desarrollo
• Actualmente los fabricantes de herramientas de desarrollo y de las
herramientas de soporte entendieron que el desarrollador debe preocuparse
más por el requerimiento que por la investigación.
• Ahora los desarrolladores están más concentrados en como plasmar el

requerimiento que investigar como la herramienta puede utilizarse para
desarrollar el requerimiento.
• Las bibliotecas de componentes son la estructura más común hoy en día

para las herramientas de desarrollo y aumentan drásticamente la
productividad.
• Compare, p.ej., a un desarrollador Java con uno .NET que están

desarrollando el mismo requerimiento: ¿Cuál será mas productivo?.

Estrategia de las herramientas para productividad
• Una estrategia efectiva para la adquisición e implantación de nuevas

herramientas debe incluir los siguientes elementos:
• Identificación temprana de nuevas herramientas interesantes.

• Evaluación ágil y precisa de las nuevas herramientas.
• Implantación de las nuevas herramientas que demuestran ser ineficaces.
• No utilizar nuevas herramientas que resultan ser ineficaces.
• Continuar confiando en herramientas anteriores y comprobadas.

92

Adquisición de herramientas para productividad
• Los problemas mas habituales con la adquisición de herramientas son:
• La adquisición de malas herramientas interfiere con la adquisición de

mejores herramientas.
• El 30% de la herramientas adquiridas no cubren suficientemente las
necesidades de los usuarios para ser efectivas.
• El 10% no se utilizan nunca una vez adquiridas.
• El 25% se usan menos de lo que deberían a causa de la falta de
formación.
• El 15% son seriamente incompatibles con las herramientas existentes, y
exigen ciertos tipos de modificaciones para adaptar la nueva herramienta
dentro del entorno deseado.

Adquisición de herramientas para productividad
• Se deben tener en cuenta los siguientes aspectos cuando se vaya a adquirir una
herramienta:
• Plan de adquisición:
• Grupo de herramientas.
• Recolección de información.
• Evaluación.
• Coordinación.
• Diseminación.
• Capacitación
• Criterios de selección:
• Beneficios estimados.
• Estabilidad del vendedor.
• Calidad
• Madurez
• Tiempo de formación
• Aplicabilidad
• Compatibilidad
• Ámbito de crecimiento
• Compromiso

93

Uso de herramientas para productividad
• Cuando adoptar las herramientas

• Importancia de la formación
• Reducción realista del plan

El síndrome de la panacea
Pensar que una herramienta tiene las características

para aumentar la productividad y la velocidad de
desarrollo resultando en un error clásico: “Desarrollo
para investigación”

94
METODOS RECOMENDABLES
Grupo de control de cambios
Trabaja reuniendo representantes de cada parte implicada dándoles la máxima autoridad para
aceptar o rechazar un cambio propuesto.
Beneficios:
• Incrementar la visibilidad del cambio de requerimientos.
• Reducir el numero de cambios no controlados.
Eficacia:
Reducción potencial de la planificación nominal Media
Mejora en la visibilidad del progreso Media
Efecto sobre el riesgo de la planificación Disminuye
Posibilidad de éxito inicial Muy Buena
Posibilidad de éxito a largo plazo Excelente
Riesgos principales:
• Aprobar demasiados cambios o aprobar muy pocos.
Interacciones y equilibrios principales:

• Puede combinarse libremente con los demás métodos.
Construcción y prueba diarias
Es un proceso en el que un producto de software es construido completamente cada día, y
entonces es sometido a una serie de pruebas para comprobar su funcionamiento básico.
Beneficios:
• Reducción de fracaso en la integración.
• Aumenta la calidad general del producto.
Eficacia:
Reducción potencial de la planificación nominal Buena
Mejora en la visibilidad del progreso Buena
• Presión para entregar versiones intermedias de un programa con demasiada frecuencia.

• Es especialmente efectivo cuando se usa con los hitos miniatura.
• Ofrece el soporte necesario para modelos de ciclo de vida de desarrollo incremental.

95
Diseño para el cambio
Su éxito depende de la identificación de los cambios probables, el desarrollo de un plan de
cambios y la ocultación de decisiones de diseño, de modo que los cambios no se propaguen
dentro de un programa.
Beneficios:
• Disminuye el retrabajo.
Eficacia:
Mejora en la visibilidad del progreso Ninguna
Posibilidad de éxito inicial Buena
• Basarse demasiado en el uso de lenguajes de programación para resolver problemas de
diseño, en lugar de en métodos de diseño orientados al cambio.

• Los métodos de diseño implicados trabajan firmemente unidos con la reutilización de
software.
Entrega evolutiva
Consigue un equilibrio entre el control de la entrega por etapas y la flexibilidad del prototipado
evolutivo. Proporciona la posibilidad de cambiar de dirección del producto a medio camino.
Beneficios:
• Mejora la calidad del producto.
• Reduce el tamaño del código
Eficacia:
Mejora en la visibilidad del progreso Excelente
• Cambio en los requerimientos.
• Disminución del control del proyecto.
• Uso ineficiente del tiempo por parte de los desarrolladores.

• El éxito depende del uso del diseño para el cambio.

96
Prototipado evolutivo
Es un modelo de ciclo de vida donde el sistema se desarrolla en incrementos, de forma que puede
modificarse de manera inmediata en respuesta a la retroalimentación del cliente y el usuario final.
Beneficios:
• Iniciar con la interfaz de usuario.
• Puede comenzar desde cualquier área de riesgo.
Eficacia:
Reducción potencial de la planificación nominal Excelente
Mejora en la visibilidad del progreso Excelente
• Expectativas poco realistas de presupuesto y planificación.
• Mal diseño.
• Dificultades para el mantenimiento.

• Sacrifica una reducción en el control del proyecto para aumentar la realimentación del usuario final y
del cliente y mejorar la visibilidad del progreso.
Inspecciones
Las inspecciones son un tipo de revisión técnica formal, en las que los participantes en la revisión
están bien formados en métodos de revisión y tienen asignadas tareas específicas. Las inspecciones
prácticamente se pueden utilizar en cualquier tipo de proyecto, tanto para nuevos desarrollos como
para mantenimiento.
Eficacia:
Reducción potencial de la planificación nominal Muy Buena
• Ninguno.

• Se puede combinar prácticamente con cualquier otro método de desarrollo rápido.

97
Desarrollo del conjunto de prestaciones
JAD es una metodología de definición de requerimientos y de diseño de la interfaz de usuario en la
cual los usuarios finales, ejecutivos y desarrolladores asisten a intensas reuniones para trabajar sobre
los detalles del sistema. Su éxito depende de la efectividad de los lideres de las sesiones JAD; en la
participación de los usuarios finales, dirigentes y desarrolladores clave.
Eficacia:
• Previsiones de productividad poco realistas tras las sesiones JAD.
• Estimaciones incorrectas y prematuras del trabajo pendiente tras las sesiones JAD.

• Funciona mejor cuando se combina con un modelo de ciclo de vida de desarrollo incremental.
• Se puede combinar con lenguajes de desarrollo rápido y herramientas de prototipado.
Planificación Promotor
• Personalización Ejecutivo
• Sesión
• Generación de Documentación
Aprobación
Revisar material
Diseño
Promotor
• Personalización
• Sesión
Ejecutivo
• Generación de Documentación
Revisar material Aprobación
Implementación

98
Selección del modelo del ciclo de vida
La elección de un modelo de ciclo de vida apropiado asegura que todo el esfuerzo se utiliza
eficientemente. Todo proyecto utiliza un ciclo de vida de un tipo u otro (explicita o implícitamente) y
este método asegura que la elección se hace explícitamente y que maximiza las posibles ventajas.
Eficacia:
• La selección de un ciclo de vida no contiene en sí mismo ningún riesgo. Los modelos de ciclo de vida
específicos pueden contener riesgos adicionales.

• Ninguno.
Medidas
Las medidas son un método que ofrece beneficios sobre la motivación a corto plazo y beneficios a
largo plazo sobre el costo, la calidad y la planificación. Las medidas ofrecen un antídoto frente a los
problemas habituales de malas estimaciones, mala planificación y mala visibilidad del progreso.
Eficacia:
Reducción potencial de la planificación nominal Muy buena
Mejora en la visibilidad del progreso Buena
• Sobreoptimización de las medidas de un solo factor.
• Mal uso de las medidas para evaluación de los empleados.
• Información equivocada de las medidas de líneas de código.

• Sienta las bases para obtener mejoras en la estimación, planificación, evaluación de herramientas
para productividad y evaluación de métodos de programación.

99
Medidas
Datos de costo y recursos
Esfuerzo por actividad, fase y tipo de personal
Recursos informáticos
Tiempo transcurrido
Datos sobre cambios y defectos
Defectos por clasificación
Estado de informe de problemas
Método de detección de defectos
Esfuerzo para detectar y corregir cada defecto
Datos del proceso
Definición del proceso
Adecuación del proceso
Tiempo esperado para terminar
Progreso de los hitos
Crecimiento del código a lo largo del tiempo
Cambios en el código a lo largo del tiempo
Cambios en los requerimientos a lo largo del tiempo
Hitos Miniatura – Ganancias Rápidas
Es un enfoque granular para el seguimiento y control de los proyectos que ofrece una visibilidad
excepcional del estado del proyecto. Las claves para el éxito en su uso incluyen vencer la resistencia
de las personas que van a ser gestionadas con el método y permanecer fiel a la naturaleza “miniatura”
del proyecto.
Eficacia:
Mejora en la visibilidad del progreso Muy Buena
• Ninguno.

• Especialmente indicado para la recuperación de proyectos.
• Especialmente efectivo cuando se combina con el método de construcción y pruebas diarias.
• Funciona bien con el prototipado evolutivo, el prototipado de la interfaz de usuario, especificación de
requerimientos y otras actividades difíciles de gestionar en los proyectos.
• Sacrifica el incremento del esfuerzo del seguimiento del proyecto por una visibilidad y control del
estado mucho mayores.

100
Desarrollo externo (Outsourcing)
Las compañías externas pueden tener más experiencia en el área de aplicación, más desarrolladores
disponibles para trabajar en un momento dado, y una biblioteca más amplia de código reutilizable de la
que disponer.
Eficacia:
Efecto sobre el riesgo de la planificación Aumenta
Posibilidad de éxito a largo plazo Muy Buena
• Transferencia de experiencia fuera de la organización.
• Pérdida de control sobre los desarrollos futuros.
• Compromiso de información confidencial.
• Pérdida de visibilidad y control del progreso.

• Sacrifica la pérdida de control y la reducción de capacidad de desarrollo interna por una mejora en la
velocidad del desarrollo, una reducción de coste o ambas.
Negociación conveniente
Es una estrategia de negociación basada en mejorar la comunicación y en la creación de opciones
satisfactorias para todos. Sus beneficios para el desarrollo rápido se derivan de clarificar las
expectativas e identificar exactamente lo necesario con el objetivo de preparar el proyecto para tener
éxito.
Eficacia:
Reducción potencial de la planificación nominal Ninguna
Mejora en la visibilidad del progreso Muy buena
• Ninguno.

• Ninguno.

101
Entornos productivos
El desarrollo de software es una actividad altamente intelectual que requiere largos periodos de
concentración ininterrumpida. El uso de este tipo de entornos puede beneficiar cualquier tipo de
proyecto.
Eficacia:
Efecto sobre el riesgo de la planificación Sin efecto
• Pérdida de productividad por mejoras en los despachos orientadas al estatus.
• Tiempo de transición.
• Repercusiones politicas del trato preferente a los profesionales del software.

• Requiere un pequeño incremento en el costo a cambio de un gran aumento en la productividad.
Lenguajes para desarrollo rápido (LDR)
Es un término general que se refiere a cualquier lenguaje de programación que ofrezca una
implementación más rápida que la tradicional.
Eficacia:
• Síndrome de la panacea y sobreestimación del ahorro.
• Fallo al escalar a proyectos grandes.
• Refuerzo de malos hábitos de programación.

• Sacrifica alguna flexibilidad en el diseño y la implementación a cambio de reducir el tiempo de
implementación.
• El aumento de velocidad en la construcción soporta el prototipado evolutivo y los métodos
incrementales relacionados con éste.

102
Filtrado de requerimientos
Es un método en el que se examina cuidadosamente la especificación de un producto buscando
requerimientos innecesarios o demasiado complejos, que son suprimidos. El filtrado de requerimientos
puede usarse en prácticamente cualquier proyecto.
Eficacia:
Reducción potencial de la planificación nominal Muy Buena
• Eliminación de requerimientos que posteriormente serán recuperados.

• Ninguno.
Reutilización
Es una estrategia a largo plazo en la que una organización construye una biblioteca de componentes
usados con frecuencia, permitiendo montar rápidamente nuevos programas a partir de componentes
existentes. Como estrategia a corto plazo, recuperando código para un nuevo programa a partir de
programas existentes.
Eficacia:
Posibilidad de éxito inicial Baja
• Pérdida de esfuerzo si los componentes preparados para su reutilización no son seleccionados
cuidadosamente.

• La reutilización necesita estar coordinada con el uso de herramientas para aumentar la productividad.
• La reutilización planificada tiene que implementarse sobre los cimientos de los fundamentos de
desarrollo de software.

103
Compromiso
La motivación es el factor que más influye en la productividad. El compromiso es la técnica que en
algunos casos ha llevado a niveles extraordinarios de motivación. Su éxito depende de tener una
visión clara con la que puedan comprometerse los miembros del equipo, y en controlar activamente el
proyecto para asegurarse de que el equipo comprometido desarrolla el producto en una dirección
aceptable.
Eficacia:
Reducción potencial de la planificación nominal Muy buena
Posibilidad de éxito inicial Media
Posibilidad de éxito a largo plazo Buena
• Incrementar la ineficiencia.
• Reducción de la visibilidad y control del estado.
• Disponibilidad de menos personal calificado para el proyecto.
• Agotamiento.

• Sacrifica posibles disminuciones en visibilidad, control y eficiencia por un mayor incremento de la
motivación.
Gestión Theory-W
Proporciona un entorno de trabajo para la gestión de proyectos orientado a la reconciliación de
intereses opuestos. Reduce la planificación mejorando la eficiencia en las relaciones laborales,
mejorando la visibilidad del progreso y reduciendo el riesgo.
Eficacia:
Posibilidad de éxito inicial Excelente
• Ninguno.

• Diseñado para su uso combinado con el método de ciclo de vida en espiral.
• Particularmente efectivo durante las negociaciones de planificación.
• Se basa en el uso del método de negociación conveniente.

104
Gestión Theory-W
1. Establecer un conjunto de precondiciones donde todos ganen antes de iniciar el
proyecto:
- Comprender la forma en que las personas quieren ganar.
- Establecer expectativas razonables por parte de todos los implicados.
- Adecuar las tareas de las personas con sus condiciones de éxito.
-Proporcionar un entorno que soporte los objetivos del proyecto.
2. Estructurar un proceso software donde todos ganen:
- Establecer un plan realista.
- Utilizar el plan para controlar el proyecto.
- Identificar y gestionar los riesgos donde todos pierden o donde unos pierden y otros ganan.
- Mantener implicadas a las personas
3. Estructurar un producto software con el que todos ganen
- Adecuar el producto a las condiciones de éxito de los usuarios finales y de las personas de
mantenimiento
Prototipos desechables
Se desarrolla código para explotar factores críticos de éxito del sistema, y posteriormente se desecha
este código. La interfaz de usuario es generalmente el elemento más prototipado habitualmente de un
sistema, pero hay otras partes de algunos sistemas que también pueden beneficiarse del prototipado.
Eficacia:
• Mantener un prototipo desechable.
• Uso ineficiente del tiempo de prototipado.
• Expectativas poco realistas de planificación y presupuesto.

• Ninguno.

105
Desarrollo en ventanas temporales
Es un método orientado al tiempo de construcción, que ayuda a infundir un sentido de urgencia en un
equipo de desarrollo, y ayuda a mantener la atención del proyectó en los requerimientos mas
importantes. Su éxito depende del uso exclusivo en tipos apropiados de proyectos, y en la voluntad de
los directivos y usuarios de recortar requerimientos en lugar de reducir la planificación.
Eficacia:
• Intentar aplicar ventanas temporales a productos donde no resulta adecuado.
• Sacrificar la calidad en lugar de los requerimientos.

• Depende del uso del prototipado evolutivo.
• Sacrifica el control del conjunto de requerimientos a cambio del control del tiempo de desarrollo.
Grupo de Herramientas
Consiste en definir un grupo que es responsable de recoger información sobre la evaluación,
coordinación del uso y difusión de nuevas herramientas dentro de una organización. Un grupo de
herramientas permite reducir el esfuerzo de prueba y error, y minimiza el numero de grupos de
desarrollo que serán perjudicados por el uso de herramientas inadecuadas.
Eficacia:
Posibilidad de éxito a largo plazo Muy buena
• Exceso de control burocrático sobre la información y la implantación de nuevas herramientas.

• Esta misma estructura básica puede ser usada por los grupos de reutilización del software y del
proceso de ingeniería de software.

106
Lista de los 10 riesgos principales
Es una herramienta sencilla que le permite controlar los riesgos de un proyecto de software. La
actualización y revisión semanal de la lista eleva la conciencia de los riesgos y contribuye a su
resolución en el tiempo adecuado.
Eficacia:
• Ninguno.

• Puede usarse en combinación con cualquier otro método.
Horas extras voluntarias
Consiste en ofrecer a los desarrolladores un trabajo significativo, de modo que junto con otras
contribuciones a la motivación interna, éstos deseen trabajar más de lo que se les exige. Las horas
extras moderadas y voluntarias pueden usarse prácticamente en cualquier entorno, pero su
aplicabilidad esta limitada por el hecho de que las horas extra excesivas, obligatorias, se utilizan ya
bastante a menudo.
Eficacia:
Posibilidad de éxito inicial Media
• Penalizaciones sobre la planificación resultantes de una excesiva presión en la planificación y un
exceso de horas extra.
• Reducción de la capacidad de responder a una necesidad de emergencia de mas horas de trabajo.

• Requiere el uso de métodos de motivación sincera y sin manipulación.
• Generalmente se requiere como soporte para los hitos miniatura o modelos de ciclo de vida
incrementales y desarrollo en ventanas temporales.

107
CONCLUSIONES
Conclusiones/Comentarios
1. Evalúe la situación: Determinar cómo es de crítica realmente la fecha límite y la
precisión necesaria para conseguirla.
2. Aplique el análisis Theory-W: ¿Que necesitan usted y su equipo para triunfar?¿Que

necesitan sus clientes?¿Qué necesita hacer para salvar la relación con los clientes?.
No se centre en el pasado. Céntrese en el presente.
3. Prepárese para corregir el proyecto: Dese cuenta de que no puede arreglar el

proyecto haciendo las mismas cosas que ha hecho. Preparase mentalmente para
hacer cambios significativos. Prepare tanto a su equipo como a la directiva para que
vean los cambios significativos que serán necesarios si desea salvar el proyecto.
4. Pregunte al equipo sobre lo que se necesita hacer: Pregunte a todos los miembros
del equipo para que contribuyan con al menos cinco ideas prácticas sobre cómo salvar
el proyecto.
5. Sea realista: Cuando comience la recuperación de su proyecto, admita que no sabe

cuánto tiempo tardará en finalizar. Explique su plan para conseguir volver a encarrilar
su proyecto, y luego de una fecha con la cual se pueda comprometer.

108
CMMI PARA
DESARROLLADORES
PRODUCT INTEGRATION (PI)
• El propósito de PP es ensamblar el producto desde sus componentes,

asegurando que el producto, cuando este integrado, funciona
apropiadamente, y se entrega adecuadamente.
• Su alcance es lograr la integración completa del producto a través de un

ensamblaje progresivo de sus componentes en una etapa o en etapas
progresivas, de acuerdo a la secuencia de integración y procedimientos
definidos.
• Un aspecto critico es la gestión de las interfaces internas y externas del

producto y sus componentes para asegurar compatibilidad entre las
interfaces.
• Puede ser conducida incrementalmente, usando un proceso iterativo de

ensamblaje de los componentes del producto, evaluándolos, y entonces
ensamblando mas componentes.

109
• Este proceso puede empezar con análisis y simulaciones (p.ej., hilos,

prototipos rápidos, prototipos virtuales y prototipos físicos) y progresos
constantes a través de incrementalmente mas funcionalidad real hasta que el
producto final sea alcanzado.
• En cada construcción sucesiva, los prototipos son construidos, evaluados,

mejorados, y reconstruidos basados en el conocimiento ganado en la
evaluación del proceso.
• Un aspecto critico es la gestión de las interfaces internas y externas del

producto y sus componentes para asegurar compatibilidad entre las
interfaces.

SG 1 Preparación para la Integración del Producto SP1.1 Determinar la secuencia de Integración
SP 1.2 Establecer el ambiente de integración del

producto
SP 1.3 Establecer los criterios y procedimientos de
integración del producto
SG 2 Asegurar la compatibilidad de la interface SP 2.1 Revisión de la completitud de la descripción
de la interface
SP 2.2 Gestión de Interfaces
SG 3 Ensamble de los componentes del producto y SP 3.1 Confirmar la disposición de los componentes
entrega del producto del producto para la integración
SP 3.2 Ensamblar los componentes del producto
SP 3.3 Evaluar los componentes ensamblados del

producto
SP 3.4 Empacar y Entregar el producto o sus
componentes

110

SP1.1 Determinar la secuencia de Integración
• Productos típicos de trabajo
– Secuencia de integración del producto
– Razón de ser para seleccionar o rechazar las secuencias de integración
• Subprácticas:
– Identificar los componentes del producto a ser integrado
– Identificar las verificaciones a ser ejecutadas durante la integración de los componentes del
producto
– Identificar las secuencias de integración alternativas del producto.
– Seleccionar la mejor secuencia de integración
– Periódicamente revisar la secuencia de integración y revisar tanto como sea necesario.
– Registrar la razón de ser de las decisiones tomadas y aplazadas.

SP 1.2 Establecer el ambiente de integración del producto
– Verificación del ambiente para la integración del producto
– Documentación de soporte para el ambiente de integración del producto.
• Subprácticas:
– Identificar los requerimientos del ambiente de integración del producto.
– Identificar los criterios de verificación y procedimientos para el ambiente de integración del
producto.
– Decidir si hacer o comprar el ambiente necesario para la integración del producto.
– Desarrollar un ambiente de integración si un ambiente adecuado no se puede adquirir.
– Mantener el ambiente de integración del producto a través del proyecto.
– Disponer de las porciones del ambiente que ya no son útiles.

111

SP 1.3 Establecer los criterios y procedimientos de integración del producto

– Procedimientos de integración del producto.
– Criterios de integración del producto.
• Subprácticas:
– Establecer y mantener los procedimientos de integración del producto para los componentes del
producto.
– Establecer y mantener criterios para la integración y evaluación de los componentes del
producto.
– Establecer y mantener criterios de validación y entrega de la integración del producto .

SP 2.1 Revisión de la completitud de la descripción de la interface

– Categorías de interface.
– Lista de interfaces por categoría.
– Mapeo de las interfaces a los componentes del producto y el ambiente de integración del
producto.
• Subprácticas:
– Revisión de la completitud de la interface de datos y aseguramiento del completo cubrimiento
de todas las interfaces.
– Asegurar que los componentes del producto y las interfaces esta hechas para asegurar su fácil
y correcta conexión al unirse.
– Periódicamente revisar la adecuación de la descripción de las interfaces.

112

SP 2.2 Gestión de Interfaces

– Tabla con las relaciones entre los componentes del producto y el ambiente externo.
– Tabla de las relaciones entre los diferentes componentes del producto.
– Lista de las interfaces acordadas definidas para cada par de componentes del producto, cuando
aplique.
– Reportes de las reuniones del grupo de control de trabajo de interfaces.
– Puntos de acción para interfaces de actualización.
– API
– Descripción actualizada de la interface.
• Subprácticas:
– Asegurar la compatibilidad de las interfaces a través de la vida del producto.
– Resolver conflictos, no conformidades, y problemas de cambio.
– Mantener un repositorio para las interfaces de datos accesible a los participantes del proyecto.

SP 3.1 Confirmar la disposición de los componentes del producto para la integración

– Documentos de aceptación para los componentes de producto recibidos.
– Recepción de Entrega (Recibido).
– Lista de empaquetado chequeadas.
– Reportes de excepción.
– Requerimientos que inicialmente solicitó el cliente/usuario y que después declinó.
• Subprácticas:
– Seguimiento del estado de todos los componentes del producto tan pronto como estén
disponibles para la integración.
– Asegurar que los componentes del producto son liberados al ambiente de integración del
producto de acuerdo con la secuencia de integración y los procedimientos disponibles.
– Confirmar la recepción de cada componente de producto bien identificado.
– Asegurar que cada componente del producto recibido cumple su descripción.
– Verificar el estado de la configuración contra la configuración esperada.
– Ejecutar una preverificación de todas las interfaces físicas antes de conectar todos los
componentes entre si.

113

SP 3.2 Ensamblar los componentes del producto

– Producto o componentes de producto ensamblados.
• Subprácticas:
– Asegurar la disposición del ambiente de integración del producto.
– Asegurar que la secuencia de ensamblado se ejecutó apropiadamente.
– Revisar que la secuencia de integración del producto y los procedimientos disponibles sean los
apropiados.

SP 3.3 Evaluar los componentes ensamblados del producto

– Reportes de excepción.
– Reportes de evaluación de interface.
– Reportes resumen de la integración del producto.
• Subprácticas:
– Dirigir la evaluación de los componentes de producto ensamblados siguiendo la secuencia de
integración del producto y los procedimientos disponibles.
– Registrar los resultados de la evaluación.

114

SP 3.4 Empacar y Entregar el producto o sus componentes

– Producto o sus componentes empaquetados.
– Entrega de documentación.
• Subprácticas:
– Revisar los requerimientos, diseño, producto, resultados de la verificación y documentación que
asegure que los problemas que afectan el empaque y entrega del producto están identificados y
resueltos.
– Usar métodos efectivos de empaque y entrega del producto ensamblado.
– Satisfacer los requerimientos y estándares aplicables para empacar y entregar el producto.
– Preparar el sitio operacional para la instalación del producto.
– Entregar el producto, la documentación asociada y confirmar su recepción.
– Instalar el producto en el sitio operacional y confirmar su correcta operación.
• El propósito de RD es producir y analizar requerimientos del cliente, producto

y componentes del producto.
• Estos requerimientos abordan la necesidad de los stakeholders relevantes,

incluyendo aquellos que pertenecen a varias fases del ciclo de vida del
producto (criterios de aceptación) y atributos del producto (es decir, seguridad,
confiabilidad y mantenibilidad).
• El desarrollo de requerimientos incluye las siguientes actividades:

– Extracción, análisis, validación y comunicación de las necesidades del cliente, expectativas y
restricciones para obtener requerimientos del cliente que constituyan un entendimiento de lo
que será satisfactorio a los stakeholders.
– Recolección y coordinación de las necesidades de los stakeholders.
– Desarrollo del ciclo de vida de los requerimientos del producto.
– Establecimiento de los requerimientos del cliente
– Establecimiento de los requerimientos del producto inicial y sus componentes en concordancia
con los requerimientos del cliente.

115

SG 1 Desarrollo de los requerimientos del cliente SP1.1 Extraer necesidades
SP 1.2 Desarrollar los requerimientos del cliente
SG 2 Desarrollar los requerimientos del producto SP 2.1 Establecer los requerimientos del producto y
sus componentes
SP 2.2 Asignar los requerimientos de los
componentes del producto
SP 2.3 Identificar requerimientos de interface
SG 3 Analizar y Validar Requerimientos SP 3.1 Establecer conceptos operacionales u

escenarios
SP 3.2 Establecer una definición de la funcionalidad
requerida
SP 3.3 Analizar Requerimientos
SP 3.4 Analizar Requerimientos para lograr balance
SP 3.5 Validar requerimientos

SP 1.1 Extraer necesidades
• Ejemplos de técnicas de extracción

– Demostraciones de Tecnología.
– Grupos de trabajo en interfaces.
– Grupos de trabajo técnicos.
– Revisores internos de proyecto.
– Cuestionarios, entrevistas y escenarios operacionales obtenidos de los usuarios finales.
– Tutoriales operacionales y análisis de tareas de usuario final.
– Prototipos y modelos.
– Lluvia de ideas.
– Encuestas de mercado.
– Pruebas beta.
– Extracción de fuentes tales como: documentos, estándares o especificaciones.
– Observación de productos existentes, ambientes y patrones de flujo de trabajo.
– Casos de uso
– Análisis de casos de uso.
– Ingeniería inversa.
– Encuestas de satisfacción de usuario

116

SP 1.1 Extraer necesidades
• Ejemplos de fuentes de requerimientos que podrían no ser identificadas por el

cliente:
– Políticas del negocio.
– Estándares.
– Requerimientos ambientales del negocio.
– Tecnología.
– Productos Legacy o componentes de producto.
• Subpracticas
– Participación de los stakeholders relevantes usando métodos para extraer necesidades,
expectativas, restricciones e interfaces externas.

SP 1.2 Desarrollo de los requerimientos del cliente

– Requerimientos del cliente.
– Restricciones del cliente en la conducción de la verificación.
– Restricciones del cliente en la conducción de la validación.
• Subpracticas.
– Traducir las necesidades, expectativas, restricciones e interfaces del stakeholder en
requerimientos documentados de cliente.
– Definir restricciones para verificación y validación.

117

SP 2.1 Establecer Requerimientos del producto y sus componentes

– Requerimientos derivados.
– Requerimientos de producto.
– Requerimientos de componente del producto.
• Subprácticas.
– Desarrollar requerimientos en términos técnicos necesarios para el diseño del producto y de los
componentes del producto.
– Derivar requerimientos que resulten de decisiones de diseño.
– Establecer y mantener relaciones entre requerimientos para considerarlas durante la gestión del
cambio y la ubicación de requerimientos.

SP 2.2 Asignar los requerimientos de los componentes del producto

– Hojas de asignación de requerimientos.
– Asignaciones provisionales de requerimientos.
– Restricciones de diseño.
– Relaciones entre requerimientos derivados.
• Subprácticas.
– Asignar requerimientos a funciones.
– Asignar requerimientos a componentes del producto.
– Asignar restricciones de diseño a componentes del producto.
– Documentar relaciones entre asignación de requerimientos.

118

SP 2.2 Asignar los requerimientos de los componentes del producto

– Hojas de asignación de requerimientos.
– Asignaciones provisionales de requerimientos.
– Restricciones de diseño.
– Relaciones entre requerimientos derivados.
• Subprácticas.
– Asignar requerimientos a funciones.
– Asignar requerimientos a componentes del producto.
– Asignar restricciones de diseño a componentes del producto.
– Documentar relaciones entre asignación de requerimientos.

SP 2.3 Identificar Requerimientos de Interface

– Requerimientos de interface.
• Subprácticas.
– Identificar interfaces tanto internas como externas del producto.
– Desarrollar los requerimientos para las interfaces identificadas.

119

SP 3.1 Establecer conceptos operacionales u escenarios

– Concepto operacional.
– Conceptos de instalación, operación, mantenimiento y soporte del producto o sus componentes.
– Conceptos de eliminación.
– Casos de uso.
– Escenarios
– Nuevos requerimientos.
• Subprácticas.
– Desarrollar conceptos operacionales y escenarios que incluyan funcionalidad, rendimiento,
mantenimiento, soporte y eliminación tanto como sea necesario.
– Definir el ambiente el cual el producto o sus componentes operarán, incluyendo limites y
restricciones.
– Revisar conceptos operacionales y escenarios que redefinan o descubran requerimientos.
– Desarrollar un concepto operacional detallado, para tantos productos o componentes de
producto sean seleccionados, que definan la interacción del producto, el usuario final, y el
ambiente, y que satisfagan las necesidades operacionales, de mantenimiento, de soporte y de
eliminación.

SP 3.2 Establecer una definición de la funcionalidad requerida

– Arquitectura funcional.
– Diagramas de actividad y casos de uso.
– Análisis orientado a objetos con servicios o métodos identificados.
• Subprácticas.
– Analizar y cuantificar la funcionalidad requerida para los usuarios finales.
– Analizar requerimientos para identificar particiones lógicas o funcionales (es decir,
subfunciones).
– Partición de requerimientos en grupos, basados en criterios establecidos (es decir,
funcionalidad similar, ejecución, o acoplamiento), para facilitar y enfocar el análisis de
requerimientos.
– Considerar la secuencialidad de funciones criticas en tiempo, tanto las iniciales como las
subsecuentes durante el desarrollo de los componentes del producto.
– Ubicar los requerimientos del usuario en particiones funcionales, objetos, personas, o
elementos de soporte para apoyar la síntesis de soluciones.
– Ubicar requerimientos funcionales y de ejecución a funciones y subfunciones.

120

SP 3.3 Analizar requerimientos
– Reportes de defectos en requerimientos.
– Cambios propuestos a los requerimientos para resolver defectos.
– Requerimientos clave.
– Medidas técnicas de rendimiento.
• Subprácticas.
– Analizar las necesidades, expectativas, restricciones de los stakeholders e interfaces externas
para quitar conflictos y organizar en asuntos relacionados.
– Analizar requerimientos para determinar si ellos satisfacen los objetivos de los requerimientos
de mas alto nivel.
– Analizar requerimientos para asegurar que estén completos, confiables, realizables y
verificables.
– Identificar los requerimientos clave que tienen una fuerte influencia en el costo, el cronograma,
la funcionalidad, el riesgo o el rendimiento.
– Identificar las medidas técnicas de rendimiento que serán seguidas durante el esfuerzo de
desarrollo.
– Analizar los conceptos operacionales y escenarios para redefinir las necesidades del cliente, las
restricciones .e interfaces para descubrir nuevos requerimientos.

SP 3.4 Analizar requerimientos para alcanzar balance
– Evaluación de los riesgos relacionados con los requerimientos.
• Subprácticas.
– Usar modelos probados, simulaciones, y prototipado para analizar el balance de las
necesidades y restricciones de los stakeholders.
– Ejecutar una evaluación de riesgo sobre los requerimientos y la arquitectura funcional.
– Examinar los conceptos de ciclo de vida del producto para el impacto de los requerimientos
sobre los riesgos.

121

SP 3.5 Validar requerimientos
– Registro de métodos de análisis y resultados.
• Subprácticas.
– Analizar los requerimientos para determinar el riesgo que del producto resultante no ejecutara
apropiadamente en su ambiente de uso pretendido.
– Explorar la adecuación y completitud de los requerimientos mediante el desarrollo de
representaciones del producto (p.ej., prototipos, simulaciones, modelos, escenarios, y pruebas
de escritorio).
– Evaluar tanto el diseño como la madurez en el contexto de la validación del ambiente de los
requerimientos para identificar problemas de validación, exponer necesidades sin especificar y
requerimientos del cliente.
SUPPLIER AGREEMENT MANAGEMENT (SAM)
• El propósito de RD es gestionar la adquisición de productos de proveedores.
• Involucra lo siguiente:
– Determinar el tipo de adquisición que será usada para los productos a ser adquiridos.
– Seleccionar proveedores.
– Establecer y mantener acuerdos con los proveedores.
– Monitoreo de los procesos con los proveedores seleccionados.
– Evaluar los productos de trabajo del proveedor seleccionado.
– Aceptación de la entrega de los productos adquiridos.
– Transicionar los productos adquiridos al proyecto.
• Un acuerdo formal es establecido para gestionar la relación entre la

organización y el proveedor. Un acuerdo formal es cualquier acuerdo legal
entre la organización y el proveedor. Este acuerdo puede ser un contrato,
licencia, acuerdo de nivel de servicio, o memorando de acuerdo.

122

SG 1 Establecer acuerdos con proveedores SP1.1 Determinar el tipo de adquisición
SP 1.2 Seleccionar Proveedores
SP 1.3 Establecer Acuerdos con Proveedores
SG 2 Satisfacer los acuerdos con proveedores SP 2.1 Ejecutar el acuerdo con el proveedor
SP 2.2 Monitorear los procesos del proveedor

seleccionado
SP 2.3 Evaluar los productos de trabajo del
proveedor seleccionado
SP 2.4 Aceptar el producto adquirido
SP 2.5 Transicionar los productos

SP1.1 Determinar el tipo de adquisición

– Lista de los tipos de adquisición que serán usados para todos los productos y componentes a
ser adquiridos.

123

SP 1.2 Seleccionar Proveedores

– Estudios de mercado.
– Lista de proveedores candidatos.
– Lista de proveedores preferidos.
– Estudio de mercado u otros registros de criterios de evaluación, ventajas y desventajas de
proveedores candidatos, y razón de ser de la selección de proveedores.
– Solicitud de materiales y requerimientos.
• Subprácticas
– Establecer y documentar criterios para la evaluación de potenciales proveedores.
– Identificar proveedores potenciales y distribución de solicitud de materiales y requerimientos.
– Evaluar propuestas de acuerdo a los criterios de evaluación.
– Evaluar riesgos asociados con cada proveedor propuesto.
– Evaluar la habilidad de los proveedores propuestos para ejecutar el trabajo.
– Seleccionar el proveedor.

SP 1.3 Establecer Acuerdos con Proveedores
– Planes de trabajo.
– Contratos.
– Memorando de acuerdo.
– Acuerdo de licencia.
• Subprácticas
– Revisar los requerimientos que deben ser cumplidos por el proveedor que reflejen la
negociación con el proveedor cuando sea necesario.
– Documentar que es lo que le va a proporcionar el proyecto al proveedor.
– Documentar el acuerdo con el proveedor.
– Periódicamente revisar el acuerdo con el proveedor para asegurarlo y que refleje la relación del
proyecto con el proveedor y los riesgos actuales y las condiciones del mercado.
– Asegurar que todas las partes en el acuerdo comprenden y aceptan todos los requisitos antes
de aplicar el acuerdo o cualquier cambio.
– Revisar el acuerdo con el proveedor según sea necesario para reflejar los cambios a los
procesos del proveedor o productos de trabajo.
– Revisar el plan del proyecto y los acuerdos, incluyendo cambios a los procesos del proyecto o
productos de trabajo, según sea necesario para reflejar el acuerdo con el proveedor.

124

SP 2.1 Ejecutar el acuerdo con el proveedor
– Reportes de progreso del acuerdo y medidas de rendimiento.
– Revisión de materiales y reportes del proveedor.
– Seguimiento a los ítems ejecutados para el cierre.
– Documentación del producto y las entregas.
• Subprácticas
– Monitorear el progreso y rendimiento del proveedor (cronograma, esfuerzo, costo y ejecución
técnica) según lo definido en el acuerdo.
– Dirigir revisiones con el proveedor según lo especificado en el acuerdo.
– Dirigir revisiones técnicas con el proveedor según lo definido en el acuerdo.
– Dirigir revisiones de gestión con el proveedor según lo definido en el acuerdo.
– Usar los resultados de las revisiones para mejorar el rendimiento del proveedor y establecer
nutrir las relaciones a largo plazo con los proveedores preferidos.
– Monitorear los riesgos que involucran al proveedor y tomar acciones correctivas según sea
necesario.

SP 2.2 Monitorear los procesos del proveedor seleccionado
– Lista de los procesos seleccionados para monitorear o la razon de ser para no serlo.
– Reportes de actividad.
– Reportes de ejecución.
– Curvas de rendimiento.
– Reportes de discrepancia.
• Subprácticas
– Identificar los procesos del proveedor que son críticos para el éxito del proyecto.
– Monitorear los procesos del proveedor seleccionados para el cumplimiento de los
requerimientos del acuerdo.
– Analizar los resultados de monitorear los procesos seleccionados para detectar problemas tan
pronto como sea posible que puedan afectar la habilidad del proveedor para satisfacer los
requerimientos del acuerdo.

125

SP 2.3 Evaluar los productos de trabajo del proveedor seleccionado
– Lista de los productos de trabajo seleccionados para monitorear o la razón de ser para no serlo.
– Reportes de actividad.
– Reportes de discrepancia.
• Subprácticas
– Identificar aquellos productos de trabajo que son críticos para el éxito del proyecto y que
deberían ser evaluados para ayudar a detectar problemas tempranamente.
– Evaluar los productos de trabajo seleccionados.
– Determinar y documentar las acciones necesarias para hacer frente a las deficiencias
identificadas en las evaluaciones.

SP 2.4 Aceptar el producto adquirido
– Aceptación de los procedimientos de prueba.
– Aceptación de los resultados de la prueba.
– Reportes de discrepancia o plan de acción correctiva.
• Subprácticas
– Definir los procedimientos de aceptación.
– Revisión y obtención de los acuerdos con los stakeholders relevantes sobre los procedimientos
de aceptación antes de la revisión o prueba de aceptación.
– Verificar que los productos adquiridos satisfacen sus requerimientos.
– Confirmar que los compromisos asociados con el trabajo adquirido están cumplidos.
– Documentar los resultados de la revisión o prueba de aceptación.
– Establecer y obtener el acuerdo con el proveedor sobre el plan de acción para cualquier
producto de trabajo adquirido que no pase su revisión o prueba de aceptación.
– Identificar, documentar, y rastrear los elementos para el cierre.

126

SP 2.5 Transicionar los productos
– Planes de transición.
– Reportes de capacitación.
– Reportes de soporte y mantenimiento.
• Subprácticas
– Asegurar que hay facilidades apropiadas para recibir, guardar, usar y mantener los productos
adquiridos.
– Asegurar que la capacitación adecuada es proporcionada por aquellos que están involucrados
en la recepción, almacenaje, uso y mantenimiento del producto adquirido.
– Asegurar que el almacenaje, la distribución y el uso de los productos adquiridos son ejecutados
de acuerdo a los términos y condiciones especificadas en el acuerdo con el proveedor o la
licencia.
TECHNICAL SOLUTION (TC)
• El propósito de la Solución técnica (TS) es diseñar, desarrollar e implementar

soluciones para los requerimientos. Las soluciones, los diseños y las
implementaciones engloban productos, componentes de producto y procesos
del ciclo de vida asociados al producto, individualmente o en combinación,
según sea apropiado.
• Se enfoca en:
– Evaluar y seleccionar soluciones (referidas a veces como “planteamiento de diseño”,
“conceptos de diseño” o “diseños preliminares”) que potencialmente satisfacen un conjunto
apropiado de requerimientos 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.
• Los procesos asociados al área de proceso de Solución técnica reciben los

requerimientos de producto y de los componentes de producto desde los
procesos de Gestión de requerimientos..

127

SG 1 Seleccionar las soluciones de componentes de SP 1.1 Desarrollar las soluciones alternativas y los
producto 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 el componente 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 de producto SP 3.1 Implementar el diseño
SP 3.2 Desarrollar la documentación de soporte de

producto

SP 1.1 Desarrollar las soluciones alternativas y los criterios de selección
– Criterios de filtrado de la solución alternativa.
– Informes de evaluación de nuevas tecnologías.
– Soluciones alternativas.
– Criterios de selección para la selección final.
– Informes de evaluación de los productos.
• Subprácticas
– Identificar los criterios de filtrado para seleccionar un conjunto de soluciones alternativas a
considerar.
– Identificar las tecnologías actualmente en uso y las nuevas tecnologías de producto para
ventajas competitivas.
– Identificar los productos candidatos que satisfagan los requerimientos.
– Generar soluciones alternativas.
– Obtener una asignación completa de los requerimientos para cada alternativa.
– Desarrollar los criterios para seleccionar la mejor solución alternativa.

128

SP 1.2 Seleccionar las soluciones de componentes de producto
– Decisiones y razonamiento de la selección de componentes de producto.
– Relaciones documentadas entre los requerimientos y los componentes de producto.
– Soluciones, evaluaciones y razonamiento documentados.
• Subprácticas
– Evaluar cada solución/conjunto de soluciones alternativas frente a los criterios de selección
establecidos en el contexto de los conceptos y de los escenarios operacionales..
– Con base en la evaluación de alternativas, evaluar la adecuación de los criterios de selección y
actualizar estos criterios según sea necesario.
– Identificar y resolver problemas con las soluciones alternativas y con los requerimientos.
– Seleccionar el mejor conjunto de soluciones alternativas que satisfagan los criterios de
selección establecidos.
– Establecer los requerimientos asociados con el conjunto seleccionado de alternativas, así como
con el conjunto de requerimientos asignados a esos componentes de producto.
– Identificar las soluciones de los componentes de producto que serán reutilizadas o adquiridas.
– Establecer y mantener la documentación de las soluciones, de las evaluaciones y de los
fundamentos.

SP 2.1 Diseñar el producto o el componente de producto
– Arquitectura de producto.
– Diseños de componentes de producto.
• Subprácticas
– Establecer y mantener los criterios frente a los cuales puede evaluarse el diseño
– Identificar, desarrollar o adquirir los métodos de diseño apropiados para el producto.
– Asegurar que el diseño se adhiere a los estándares y a los criterios de diseño aplicables.
– Asegurar que el diseño se adhiere a los requerimientos asignados.
– Documentar el diseño.

129

– Paquete de datos técnicos.
• Paquete de Datos Técnico:

– Descripción de la arquitectura de producto.
– Requerimientos asignados.
– Descripciones de los componentes de producto.
– Descripciones de los procesos del ciclo de vida asociados al producto, si no se describe como
componente separado de producto.
– Características clave de producto.
– Características físicas requeridas y restricciones.
– Requerimientos de la interfaz.
– Requerimientos de materiales (facturas del material y características de los materiales).
– Requerimientos de fabricación y de manufacturación (tanto para el fabricante del equipamiento
original como para el soporte de campo).
– Criterios de verificación usados para asegurar que se han alcanzado los requerimientos.

• Paquete de Datos Técnico:
– Condiciones de uso (entornos) y escenario de operación/uso, modalidades y estados de las
operaciones, soporte, formación, fabricación, retirada, y las verificaciones a lo largo de la vida
de producto.
– Razonamiento de las decisiones y de las características (requerimientos, asignaciones de
requerimientos y opciones de diseño).
• Subprácticas
– Determinar el número de niveles de diseño y el nivel apropiado de documentación para cada
nivel de diseño.
– Basar las descripciones de diseño detallado en los requerimientos asignados de los
componentes de producto, en la arquitectura y en los diseños de alto nivel.
– Documentar el diseño en el paquete de datos técnicos.
– Documentar los fundamentos de las decisiones claves (es decir, efecto significativo sobre coste,
calendario o funcionamiento técnico) hechas o definidas.
– Corregir el paquete de datos técnicos según sea necesario.

130

SP 2.3 Diseñar las interfaces usando criterios
– Especificaciones del diseño de la interfaz.
– Documentos de control de la interfaz.
– Criterios de la especificación de la interfaz.
– Fundamentos del diseño seleccionado de la interfaz.
• Subprácticas
– Definir los criterios de la interfaz.
– Identificar las interfaces asociadas con otros componentes de producto.
– Identificar las interfaces asociadas con los elementos externos.
– Identificar las interfaces entre los componentes de producto y los procesos de ciclo de vida
asociados al producto.
– Aplicar los criterios para las alternativas de diseño de la interfaz.
– Documentar los diseños de la interfaz seleccionados y los fundamentos de la selección.

SP 2.4 Realizar los Análisis sobre si hacer, comprar o reutilizar
• Algunos factores que afectan la decisión de hacer-o-comprar son:
– Funciones que los productos proporcionarán y cómo estas funciones se adecuarán en el
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 requerimientos de negocio de alto nivel.
– Investigación de mercado de productos disponibles, incluyendo productos
– Funcionalidad y calidad de productos disponibles.
– Habilidades y capacidades de proveedores potenciales.
– Impactos en las competencias básicas de negocio.
– Licencias, garantías, responsabilidades y limitaciones asociadas con los productos que están
siendo adquiridos.
– Disponibilidad de producto.
– Aspectos de propiedad.
– Reducción del riesgo.

131

SP 2.4 Realizar los Análisis sobre si hacer, comprar o reutilizar
• Productos típicos de trabajo:
– Criterios para el diseño y la reutilización de los componentes de producto.
– Análisis hacer o comprar.
– Guías para elegir componentes de producto.
• Subprácticas
– Desarrollar los criterios para la reutilización de los diseños de los componentes de producto.
– Analizar los diseños para determinar si deberían desarrollarse, reutilizarse o comprarse los
componentes de producto.
– Analizar las implicaciones para el mantenimiento cuando se consideran los elementos
comprados o no desarrollados (p. ej., productos comerciales gubernamentales y de
reutilización).

SP 3.1 Implementar el diseño
– Diseño implementado.
• Subprácticas
– Usar métodos eficaces para implementar los componentes de producto.
– Adherirse a los estándares y a los criterios aplicables.
– Llevar a cabo revisiones entre pares de los componentes seleccionados de producto.
– Para más información sobre la realización de revisiones entre pares, consúltese el área de
proceso de Verificación.
– Realizar pruebas unitarias del componente de producto según sea apropiado.
– Corregir el componente de producto según sea necesario.

132

SP 3.2 Desarrollar la documentación de soporte de producto
– Materiales de formación del usuario final.
– Manual de usuario.
– Manual del operador.
– Manual de mantenimiento.
– Ayuda en línea
• Subprácticas
– Revisar los requerimientos, el diseño, el producto y los resultados de pruebas para asegurar que se
identifican y resuelven los problemas que afectan a la documentación de instalación, de operación y de
mantenimiento.
– Utilizar métodos eficaces para desarrollar la documentación de instalación, de operación y de
mantenimiento.
– Adherirse a los estándares aplicables de documentación.
– Desarrollar las versiones preliminares de la documentación de instalación, de operación y de
mantenimiento en fases tempranas del ciclo de vida del proyecto para la revisión por las partes
interesadas relevantes.
– Llevar a cabo revisiones entre pares de la documentación de instalación, de operación y de
mantenimiento.
– Corregir la documentación de instalación, de operación y de mantenimiento según sea necesario.
VALIDATION (VAL)
• El propósito de Validación (VAL) es demostrar que un producto o componente

de producto se ajusta a su uso previsto cuando se sitúa en su entorno
previsto.
• Las actividades de validación pueden aplicarse a todos los aspectos del

producto en cualquiera de sus entornos previstos, tales como los servicios de
operación, de formación, de fabricación, de mantenimiento y de soporte.
• El entorno de validación debería representar el entorno previsto para el

producto y los componentes de producto, así como representar el entorno
previsto adecuado para las actividades de validación con los productos de
trabajo.
• Siempre que sea posible, la validación debería realizarse usando el producto

o el componente del producto operando en su entorno previsto. Se puede
usar el entorno completo o sólo una parte del mismo.

133
VALIDATION (VAL)

SG1 Preparar la validación SP 1.1 Seleccionar los productos a validar
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 SP 2.1 Realizar la validación
producto
SP 2.2 Analizar los resultados de la validación
VALIDATION (VAL)
SP 1.1 Seleccionar los productos a validar
• Algunos ejemplos de métodos de validación son:
– Discusiones con los usuarios, 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 servicio e interfaces de usuario).
– Pilotos de materiales de formación.
– Pruebas de productos y de componentes de producto por los usuarios finales y por otras partes
interesadas relevantes.
– Análisis de producto y de componentes de producto (p. ej., simulaciones, modelado y análisis
de usuario).

134
VALIDATION (VAL)
SP 1.1 Seleccionar los productos a validar
– Listas de productos y de componentes de producto seleccionados para la validación.
– Métodos de validación para cada producto o componente de producto.
– Requerimientos para realizar la validación para cada producto o componente de producto.
– Restricciones de validación para cada producto o componente de producto.
• Subprácticas
– Identificar los principios, características y fases clave para la validación del producto o del
componente de producto durante toda la vida del proyecto.
– Determinar qué categorías de las necesidades del usuario (operacional, mantenimiento,
formación o soporte) serán validadas.
– Seleccionar el producto y componentes de producto a validar.
– Seleccionar los métodos de evaluación para la validación del producto o del componente de
producto.
– Revisar la selección, las restricciones y los métodos de validación con las partes interesadas
relevantes.
VALIDATION (VAL)
– Entorno de validación.
• Subprácticas
– Identificar los requerimientos del entorno de validación.
– Identificar los productos suministrados por el cliente.
– Identificar los elementos de reutilización.
– Identificar el equipamiento y las herramientas de prueba.
– Identificar los recursos de validación que están disponibles para reutilización y modificación.
– Planificar en detalle la disponibilidad de los recursos.

135
VALIDATION (VAL)
• Algunos ejemplos de este tipo de elementos en un entorno de validación son:
– Herramientas de prueba conectadas con el producto que está siendo validado (p. ej.,
medidores, dispositivos electrónicos y sensores).
– Software de prueba embebido temporalmente.
– Herramientas de registro para volcar información o para posterior análisis y reproducción.
– Subsistemas o componentes simulados (a través de software, electrónica o mecánica).
– Sistema de interfaz simulados (p. ej., un barco de guerra falso 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 usar todos los elementos precedentes.
– Entorno informático de pruebas o de redes dedicado (p. ej., banco de pruebas de redes de
telecomunicación pseudo-operacionales o instalación de pruebas con líneas troncales,
electrónica de red y sistemas establecidos para ensayos realistas de integración y de
validación).
VALIDATION (VAL)
SP 1.3 Establecer los procedimientos y los criterios de validación
– Procedimientos de validación.
– Criterios de validación.
– Procedimientos de prueba y evaluación para mantenimiento, formación y soporte.
• Subprácticas
– Revisar los requerimientos del producto para asegurar que se identifican y se resuelven los
problemas que afectan a la validación del producto o del componente de producto.
– Documentar el entorno, escenario operacional, procedimientos, entradas, salidas y criterios
para la validación del producto o del componente de producto seleccionado.
– Evaluar el diseño a medida que madura en el contexto del entorno de validación, para identificar
problemas de validación.

136
VALIDATION (VAL)
SP 2.1 Realizar la validación
– Informes de validación.
– Resultados de validación.
– Matriz de referencias cruzadas de validación.
– Registro de procedimientos tal como se ejecutaron.
– Demostraciones operacionales.
VALIDATION (VAL)
SP 2.2 Analizar los resultados de la validación
– Informes de deficiencias en la validación.
– Problemas de validación.
– Petición de cambio de procedimiento.
• Subprácticas
– Comparar los resultados reales con los resultados esperados.
– En base a los criterios de validación establecidos, identificar los productos y los componentes
de producto que no funcionan adecuadamente en sus entornos operacionales previstos, o
identificar los problemas con los métodos, con los criterios y/o con el entorno.
– Analizar los datos de validación en cuanto a defectos.
– Registrar los resultados del análisis e identificar los problemas.
– Usar los resultados de la validación para comparar las mediciones y el rendimiento reales para
el uso previsto o la necesidad operacional.

137
VERIFICATION (VER)
• El propósito de la Verificación (VER) es asegurar que los productos de trabajo

seleccionados cumplen sus requerimientos especificados.
• La verificación incluye la verificación del producto y de los productos de

trabajo intermedios frente a todos los requerimientos seleccionados,
incluyendo requerimientos del cliente, del producto y del componente de
producto.
• La verificación es inherentemente un proceso incremental, debido a que

ocurre durante todo el desarrollo del producto y de los productos de trabajo,
comenzando con la verificación de los requerimientos, progresando a través
de la verificación de los productos de trabajo según van evolucionando y
culminando en la verificación del producto finalizado.
VERIFICATION (VER)

SG 1 Preparar la verificación SP 1.1 Seleccionar los productos de trabajo a
verificar
SP 1.2 Establecer el entorno de verificación
SP 1.3 Establecer los procedimientos y los criterios

de verificación
SG 2 Realizar revisiones entre pares SP 2.1 Preparar las revisiones entre pares
SP 2.2 Llevar a cabo las revisiones entre pares
SP 2.3 Analizar los datos de la revisión entre pares
SG 3 Verificar los productos de trabajo SP 3.1 Realizar la verificación

seleccionados
SP 3.2 Analizar los resultados de la verificación

138
VERIFICATION (VER)
SP 1.1 Seleccionar los productos de trabajo a verificar
– Lista de productos de trabajo seleccionados para la verificación.
– Métodos de verificación para cada producto de trabajo seleccionado.
• Subprácticas
– Identificar los productos de trabajo a verificar.
– Identificar los requerimientos a satisfacer por cada producto de trabajo seleccionado.
– Identificar los métodos de verificación que están disponibles para
– usar.
– Definir los métodos de verificación a usar para cada producto de trabajo seleccionado.
– Enviar la identificación de los productos de trabajo a verificar, los requerimientos a satisfacer y
los métodos a usar para su integración con el plan del proyecto.
VERIFICATION (VER)
SP 1.2 Establecer el entorno de verificación
– Entorno de verificación.
• Subprácticas
– Identificar los requerimientos del entorno de verificación.
– Identificar los recursos de verificación que están disponibles para su reutilización y modificación.
– Identificar el equipamiento y las herramientas de verificación.
– Adquirir el equipamiento de soporte y un entorno de verificación, tales como equipamiento y
software de prueba.

139
VERIFICATION (VER)
SP 1.3 Establecer los procedimientos y los criterios de verificación
– Procedimientos de verificación.
– Criterios de verificación
• Subprácticas
– Generar el conjunto completo e integrado de procedimientos de verificación para productos de
trabajo y para cualquier producto, según sea necesario.
– Desarrollar y refinar los criterios de verificación cuando sea necesario.
– Identificar los resultados esperados, cualquier tolerancia permitida en la observación, y otros
criterios para satisfacer los requerimientos.
– Identificar cualquier equipamiento y componentes ambientales necesarios para dar soporte a la
verificación.
VERIFICATION (VER)
SP 2.1 Preparar las revisiones entre pares
– Calendario de la revisión entre pares.
– Listas de comprobación de la revisión entre pares.
– Criterios de entrada y de salida para los productos de trabajo.
– Criterios para solicitar otra revisión entre pares.
– Material de formación de la revisión entre pares.
– Productos de trabajo seleccionados para revisar.
• Subprácticas
– Determinar qué tipo de revisión entre pares será llevada a cabo.
– Definir los requerimientos para recoger datos durante la revisión entre pares.
– Establecer y mantener criterios de entrada y de salida para la revisión
– entre pares.
– Establecer y mantener criterios para solicitar otra revisión entre pares.
– Establecer y mantener listas de comprobación para asegurar que los productos de trabajo se
revisan consistentemente.

140
VERIFICATION (VER)
SP 2.1 Preparar las revisiones entre pares
• Subprácticas
– Desarrollar un calendario detallado de la revisión entre pares, incluyendo as 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.
– Asegurar que el producto de trabajo satisface los criterios de entrada de la revisión entre pares
antes de su distribución.
– Distribuir a los participantes el producto de trabajo a revisar y su información relativa, con la
suficiente antelación para permitir a los participantes prepararse adecuadamente para la
revisión entre pares.
– Asignar los roles para la revisión entre pares según sea apropiado.
– Preparar la revisión entre pares revisando el producto de trabajo antes de llevar a cabo la
propia revisión entre pares
VERIFICATION (VER)
SP 2.2 Llevar a cabo las revisiones entre pares
– Resultados de la revisión entre pares.
– Problemas de la revisión entre pares.
– Datos de la revisión entre pares.
• Subprácticas
– Llevar a cabo los roles asignados en la revisión entre pares.
– Identificar y documentar los defectos y otros problemas en el producto de trabajo.
– Registrar los resultados de la revisión entre pares, incluyendo los elementos de acción.
– Recoger los datos de la revisión entre pares.
– Identificar los elementos de acción y comunicar los problemas a las partes interesadas
relevantes.
– Llevar a cabo una revisión entre pares adicional si el criterio definido indica esta necesidad.
– Asegurar que se satisfacen los criterios de salida para la revisión entre pares.

141
VERIFICATION (VER)
SP 2.3 Analizar los datos de la revisión entre pares
– Datos de la revisión entre pares.
– Elementos de acción de la revisión entre pares.
• Subprácticas
– Registrar los datos relativos a la preparación, realización y resultados de la revisión entre pares.
– Almacenar los datos para futura referencia y análisis.
– Proteger los datos para asegurar que los datos de la revisión entre pares no se usan de forma
inapropiada.
– Analizar los datos de la revisión entre pares.
VERIFICATION (VER)
SP 3.1 Realizar la verificación
– Resultados de la verificación.
– Informes de la verificación.
– Demostraciones.
– Registro de los procedimientos tal como se ejecutan.
• Subprácticas
– Realizar la verificación de los productos de trabajo seleccionados frente a sus requerimientos.
– Registrar los resultados de las actividades de verificación.
– Identificar los elementos de acción resultantes de la verificación de los productos de trabajo.
– Documentar el método de verificación “tal como se ejecuta” y las desviaciones de los métodos y
de los procedimientos disponibles descubiertas durante su realización.

142
VERIFICATION (VER)
SP 3.2 Analizar los resultados de la verificación
– 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, y tendencias).
– Informes de problemas.
– Peticiones de cambio para métodos, criterios y entorno de verificación.
• Subprácticas
– Comparar los resultados reales con los resultados esperados.
– En base a los criterios de verificación establecidos, identificar los productos que no han
cumplido sus requerimientos o identificar problemas con los métodos, con los procedimientos,
con los criterios y con el entorno de verificación.
– Analizar los datos de verificación sobre defectos.
– Registrar todos los resultados del análisis en un informe.
– Usar los resultados de verificación para comparar las mediciones y el rendimiento reales con los
parámetros técnicos de rendimiento.
– Proporcionar información sobre cómo pueden resolverse los defecto (incluyendo los métodos
de verificación, los criterios y el entorno de verificación) e iniciar las acciones correctivas.

143

Cmmi 2010

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Cmmi 2010

Cargado por

Copyright:

Formatos disponibles

Fundación de Egresados U.D.

FUNDACION DE EGRESADOS DE LA UNIVERSIDAD DISTRITAL

“La calidad de un sistema o producto esta altamente

• Contiene los elementos esenciales de procesos efectivos para una o

• En 1995 el SEI creó el primer CMMI diseñado para organizaciones de

• El valor de este enfoque en mejoramiento de procesos ha sido

FUNDACION DE EGRESADOS DE LA UNIVERSIDAD DISTRITAL

• El proyecto CMMIntegration fue formado para solucionar el problema de

FUNDACION DE EGRESADOS DE LA UNIVERSIDAD DISTRITAL

CMMI PARA DESARROLLO

• El SEI ha retirado CMM para software y el IPD-CMM.

• El EIA ha retirado el SECM. Todos esos modelos han sido reemplazados

• La versión 1.1 tuvo más de 1500 solicitudes de cambio.

• Finalmente la versión 1.2 tuvo más de 2000 solicitudes de cambio y es la

ALCANCE PARA DESARROLLO

• Varias industrias como: aeroespacial, banca, hardware, software,

• El modelo cubre: gestión de proyectos, gestión de procesos, ingenieria

• El material adicional es IPPD que incluye practicas para ayudar a las

FUNDACION DE EGRESADOS DE LA UNIVERSIDAD DISTRITAL

ENFOQUE HACIA MEJORAMIENTO DE PROCESOS

• El uso de este modelo se puede ver en dos

– Desarrollador de sistemas electrónicos que quiere mejorar su

– Desarrollador de software que usa IPPD, ha venido usando CMM, y

ENTENDIENDO LOS MODELOS

• CMMI soporta dos caminos de mejoramiento:

• Para alcanzar un nivel particular, una organización debe satisfacer todas

FUNDACION DE EGRESADOS DE LA UNIVERSIDAD DISTRITAL

Continua: La representación continua permite a una organización seleccionar un

Escalonada: La representación por etapas utiliza conjuntos predefinidos de áreas

FUNDACION DE EGRESADOS DE LA UNIVERSIDAD DISTRITAL

Representación Escalonada Niveles de

FUNDACION DE EGRESADOS DE LA UNIVERSIDAD DISTRITAL

• Niveles de Capacidad: pertenecen a la representación continua,

• Niveles de Madurez: pertenecen a la representación escalonada,

Representación continua Representación por etapas

FUNDACION DE EGRESADOS DE LA UNIVERSIDAD DISTRITAL

ENTENDIENDO LOS MODELOS DE MADUREZ

• Cada nivel de madurez madura un importante subconjunto de procesos

• Hay cinco niveles de madurez:

ENTENDIENDO LOS MODELOS DE MADUREZ

FUNDACION DE EGRESADOS DE LA UNIVERSIDAD DISTRITAL

ENTENDIENDO LOS MODELOS DE MADUREZ

• Nivel 4: Cuantitativamente Gestionado

ENTENDIENDO LOS MODELOS DE MADUREZ

FUNDACION DE EGRESADOS DE LA UNIVERSIDAD DISTRITAL

Causal Analysis and Resolution Soporte 5

Configuration Management Soporte 2

Decision Analysis and Resolution Soporte 3

Integrated Project Management Gestión de Proyectos 3

Measurement and Analysis Soporte 2

Organizational Innovation and Gestión de Procesos 5

Organizational Process Performance Gestión de Procesos 4

Organizational Training Gestión de Procesos 3

Product Integration Ingeniería 3

Project Monitoring and Control Gestión de Proyectos 2

Project Planning Gestión de Proyectos 2

Process and Product Quality Assurance Soporte 2

Quantitative Project Management Gestión de Proyectos 4

Requeriments Development Ingeniería 3

Requeriments Management Ingeniería 2

Risk Management Gestión de Proyectos 3

Supplier Agreement Management Gestión de Proyectos 2

Technical Solution Ingeniería 3