Ingeniería de Sofware - Calidad - Metricas - Metodologías Ágiles - Procesos - Proyecto

Modelos formales: CMMI
1
CMM
CMM (Capability
(Capability Maturity
Maturity Model)
Model)
 Deficiencias en las metodologías  Incapacidad para manejar el

proceso de software
 En 1986, SEI (Software Engineering Institute): marco de trabajo

sobre madurez de procesos
 En 1991, SEI desarrolló Capability Maturity Model (CMM)

 Conjunto de prácticas recomendadas en determinadas áreas clave de
proceso
 Mejora la capacidad del proceso de software
 Guía en la selección de estrategias de mejora de proceso

 Establecer la madurez de los procesos
 Determina cuestiones críticas para la calidad y la mejora del proceso
2
Organizaciones
Organizaciones de
de software
software maduras
maduras // inmaduras
inmaduras
Idea principal: distinción entre empresas maduras/inmaduras
En una organización inmadura:

- Procesos de software: improvisados o no respetados (si existen)
- Planificación en función de los problemas
- Presupuestos y planificación incumplidos
- Sin base objetiva para evaluar la calidad o para resolver problemas
- Inexistencia o reducción de las actividades de mejora de la calidad
 En una organización madura:

- Capacidad de gestión: desarrollo de software y procesos de mantenimiento
- Proceso de software difundido al equipo y planificado
- Procesos modificables: pruebas piloto controladas y análisis de coste/beneficio
- Roles y responsabilidades establecidos en el proyecto y la organización
- Gestores: monitorización la calidad de los productos y de los procesos
- Planificaciones y presupuestos realistas: rendimientos históricos
- Proceso disciplinado en el que todos los participantes entienden su valor,
existiendo además la infraestructura necesaria para soportar el proceso
3
Proyecto
Proyecto CMMI
CMMI
 DoD (Departamento de Defensa de los Estados Unidos), SEI (Software

Engineering Institute) y NDIA (National Defense Industrial Association).
 Más de 100 organizaciones involucradas
 U.S. Army, Navy, Air Force  KPMG
 Federal Aviation Administration  Lockheed Martin
 National Security Agency  Motorola
 Software Engineering Institute  Northrop Grumman
 ADP, Inc.  Pacific Bell
 AT&T Labs  Q-Labs
 BAE  Raytheon
 Boeing  Reuters
 Computer Sciences Corporation  Rockwell Collins
 EER Systems  SAIC
 Ericsson Canada  Software Productivity Consortium
 Ernst and Young  Sverdrup Corporation
 General Dynamics  TeraQuest
 Harris Corporation  Thomson CSF
 Honeywell  TRW
4
Modelos
Modelos CMMI
CMMI
 Modelo combinado
System Engineering/Software
Engineering
MM I -SE/SW CMMI-SE
/SW  Aplicable:
C
– Sólo a proyectos de software
Staged tion ous
Continu tion
enta n ta engineering
Repres Represe
– Sólo a proyectos de system
engineering
– Ambos
¿Continua
¿Continua oo escalonada?
escalonada?
 Ambas incluyen el mismo contenido y consiguen idénticos

objetivos
 La representación continua centra su actuación en la
CAPACIDAD DE LOS PROCESOS
 La representación escalonada centra su actuación en la
MADUREZ DE LA ORGANIZACIÓN
5
¿Por
¿Por qué
qué dos
dos representaciones
representaciones del
del modelo?
modelo?
 Heredado de los modelos de origen.

 Software CMM--Escalonado
 SECM--Continuo
 IPD CMM--Híbrido
 En el del equipo de desarrollo de CMMI había defensores de de

cada una de las representaciones.
 Seleccionar una única representación se planteaba como algo “too

hard”.
 Compromiso: Inicialmente soportar dos representaciones del

modelo con contenidos equivalentes.
6
Un
Un modelo,
modelo, dos
dos representaciones
representaciones
Continuo Escalonado
ML5
5
Capacidad
4
ML4
3
ML3
1 2
ML2
ML 1
0
PA PA PA
. . .para un área de proceso . . .para un conjunto de
o un conjunto de áreas de proceso áreas de proceso establecido
7
Capacidad
Capacidad yy madurez
madurez
 Capacidad es un atributo que se aplica a los procesos y define la

eficacia del mismo para conseguir los objetivos previstos.
 Madurez es un atributo que se aplica a la organización y define su

potencial de calidad en la producción.
5
ML5
4
ML4
3
ML3
2
ML2
1
ML 1
0
8
Niveles
Niveles de
de capacidad
capacidad
 0 – Incompleto
Los procesos no se realizan, o no consiguen sus objetivos
 1 – Ejecutado
Los procesos se ejecutan y se logran los objetivos específicos del área
 2 – Gestionado
Los procesos que además de considerarse “ejecutados” son también planificados,
revisados y evaluados para comprobar que cumplen los requisitos
 3 – Definido
Los procesos que además de considerarse “gestionados” se ajustan al conjunto de
procesos estándar conforme a las líneas directivas de la organización
 4 – Gestión cuantificada
Procesos “definidos” que son controlados utilizando técnicas estadísticas u otras
técnicas cuantitativas
 5 – Optimizado
Procesos “gestionados cuantificadamente” que son cambiados y adaptados para
conseguir objetivos relevantes de negocio
9
Dimensión
Dimensión de
de la
la capacidad
capacidad
Los valores describen “cómo de bien” se realiza el proceso (nivel

de capacidad del proceso).
Proceso bien ejecutado y

mejorado continuamente
Capacidad
Proceso no ejecutado
Area Area Area Area

Proceso 1 Proceso 2 Proceso 3 Proceso n
Procesos
10
Niveles
Niveles de
de madurez
madurez
 1 – Inicial
Control deficiente e impredecibilidad de los resultados
 2 – Gestionado
Es posible obtener niveles de calidad previamente alcanzados
 3 – Definido
Los procesos realizados se encuentran normalizados, son conocidos y
comprendidos
 4 – Gestionado cuantitativamente
Los procesos incluyen indicadores de medición y control
 5 – Optimizado
Centralización en la mejora de los procesos
11
Dimensión
Dimensión de
de la
la madurez
madurez
Optimizado
5 Centrado en la mejora de
procesos
Gestionado
4 Proceso medido cuantitativamente
y controlado
Definido
3 Proceso caracterizado
para la organización y
proactivo
Gestionado
2 Proceso caracterizado
para los proyectos y a
menudo reactivo
Inicial
1 Proceso imprevisible, poco
controlado y reactivo
12
Áreas
Áreas de
de procesos
procesos
 CMMI recoge prácticas para 22 áreas de procesos
 Las áreas de procesos agrupan a las actividades necesarias para

la ejecución de los proyectos de ingeniería de sistemas y de
software
 El modelo en su representación escalonada clasifica a las 22

áreas de proceso en aquellas cuya gestión es necesaria para
lograr cada nivel de calidad
 El modelo en su representación continua las clasifica según a la

categoría que pertenecen: Gestión de proyectos, ingeniería,
soporte y gestión de procesos
13
Áreas
Áreas de
de procesos
procesos en
en la
la representación
representación escalonada
escalonada
NIVEL DE MADUREZ ÁREAS DE PROCESO
Innovación y desarrollo
5 OPTIMIZADO
4 GESTIONADO Gestión cuantificada de proyectos

CUANTITATIVAMENTE Rendimiento de los procesos de la organización
Desarrollo de requisitos
Solución técnica
Verificación
Validación
Integración de producto
3 DEFINIDO Procesos orientados a la organización
Definición de los procesos de la organización
Formación
Gestión integrada de proyecto
Gestión de riesgos
Análisis y resolución de decisiones
Gestión de requisitos
Planificación de proyecto
Monitorización y control de proyectos
2 GESTIONADO Gestión y acuerdo con suministradores
Medición y análisis
Gestión de la calidad de procesos y productos
Gestión de la configuración
1 INICIAL
14
Áreas
Áreas de
de procesos
procesos en
en la
la representación
representación continua
continua
CATEGORÍA ÁREAS DE PROCESO
Planificación de proyecto
Monitorización y control de proyecto
Gestión y acuerdo con proveedores
GESTIÓN DE PROYECTOS Gestión integrada de proyecto
Gestión de riesgos
Gestión cuantificada de proyecto
Gestión de la configuración
Gestión de la calidad de procesos y productos
SOPORTE Medición y análisis

Análisis y resolución de decisiones
Análisis y resolución de problemas
Desarrollo de requisitos
Gestión de requisitos
Soluciones técnicas
INGENIERÍA Integración de producto
Verificación
Validación
Definición de los procesos de la organización
GESTIÓN DE PROCESOS Procesos orientados a la organización

Formación
Rendimiento de los procesos de la organización
Innovación y desarrollo
15
Cómo
Cómo usar
usar el
el modelo
modelo
Área
Área de
de proceso
proceso
Conjunto de practicas relacionadas que son ejecutadas de forma conjunta para conseguir un
conjunto de objetivos.
Componentes
Componentes requeridos
requeridos
Objetivo genérico
Los objetivos genéricos asociados a un nivel de capacidad establecen lo que una organización debe
alcanzar en ese nivel de capacidad.
El logro de cada uno de esos objetivos en un área de proceso significa mejorar el control en la
ejecución del área de proceso
Objetivo específico
Los objetivos específicos se aplican a una única área de proceso y localizan las particularidades que
describen que se debe implementar para satisfacer el propósito del área de proceso
16
Cómo
Cómo usar
usar el
el modelo
modelo
Componentes
Componentes esperados
esperados
Práctica genérica
Una practica genérica se aplica a cualquier área de proceso porque puede mejorar el funcionamiento
y el control de cualquier proceso.
Práctica específica
Una practica específica es una actividad que se considera importante en la realización del objetivo
especifico al cual está asociado.
Las prácticas específicas describen las actividades esperadas para lograr la meta específica de un
área de proceso.
Componentes
Componentes informativos
informativos
Propósito
Notas introductorias
Referencias
Las referencias son indicadores de otras áreas de proceso relacionadas que pueden aportar
información adicional o más detallada
Nombres
Tablas de relaciones práctica-objetivo
Prácticas
17
Cómo
Cómo usar
usar el
el modelo
modelo
Componentes
Componentes informativos
informativos
Propósito
Notas introductorias
Referencias
Las referencias son indicadores de otras áreas de proceso relacionadas que pueden aportar
información adicional o más detallada
Nombres
Tablas de relaciones práctica-objetivo
Prácticas
Productos típicos
Subprácticas
Una subpractica es una descripción detallada que sirve como guía para la interpretación de una
practica genérica o especifica
Ampliaciones de disciplina
Las ampliaciones contienen información relevante de una disciplina particular y relacionada con una
practica especifica.
Elaboraciones de prácticas genéricas
Una elaboración de una practica genérica es una guía de cómo la practica genérica debe aplicarse al
área de proceso.
18
Mapa
Mapa del
del documento
documento
Área de proceso
Propósito
Notas Objetivos específicos
Objetivos genéricos
Referencias
19
Mapa
Mapa del
del documento
documento
R. Metas-Practicas
Practicas especificas
Nombres 20
Mapa
Mapa del
del documento
documento
Notas Practicas genericas
Productos de
trabajo
Subpracticas
Elaboraciones
21
Áreas
Áreas de
de proceso
proceso
 CMMI SE/SW incluye 22 áreas de proceso
 Las áreas de proceso son iguales en ambas representaciones del modelo
 En la representación continua, las áreas de proceso se agrupan por categorías: Gestión de

proyectos, Ingeniería, Soporte y Gestión de procesos
Process areas by capability
 En la representación escalonada, las áreas de proceso se agrupan por niveles de madurez (2 –

5)
Process areas by maturity level
22
Áreas
Áreas de
de proceso
proceso
Gestión
Gestión de
de proyecto
proyecto
Las áreas de procesos de gestión de proyectos cubren las actividades relacionadas con la
planificación, monitorización y control del proyecto.
El modelo CMMI SE/SW incluye seis áreas de proceso en gestión de proyectos:

 Planificación de proyecto
 Monitorización y control de proyecto
 Gestión y acuerdos con proveedores
 Gestión integrada de proyecto
 Gestión de riesgos
 Gestión cuantificada de proyecto
23
Áreas
Áreas de
de proceso
proceso
Gestión
Gestión de
de proyecto:
proyecto: áreas
áreas básicas
básicas
PMC Estado, cuestiones, resultados

Acciones de evaluaciones de producto,
Correctivas Medidas y análisis
Acciones
Que
Correctivas
Replanificar controlar
Estado, Que construir

cuestiones, PP Que hacer
resultados de
progreso y Áreas de proceso
Comprom Soporte e Ingeniería
revisiones de isos
hitos
Planes
Necesidades de medición
SAM
Acuerdos
Proveedor
Requisitos de componente de producto

Cuestiones técnicas
Proveedor
Revisiones y test de aceptación
24
Áreas
Áreas de
de proceso
proceso
Gestión
Gestión de
de proyecto:
proyecto: planificación
planificación de
de proyecto
proyecto
Propósito: establecer y mantener planes que definan las actividades del proyecto
Establecer Datos Desarrollar Plan

Estimaciones Planificación de Proyecto
Obtener
Planes de
Compromisos
Proyecto
con el Plan
PMC
25
Áreas
Áreas de
de proceso
proceso
Gestión
Gestión de
de proyecto:
proyecto: monitorización
monitorización yy control
control
Propósito: Proporcionar información sobre el progreso del proyecto que permita tomar acciones
correctivas cuando la ejecución del proyecto se desvía significativamente del plan.
Gestionar
Monitorizar Proyecto contra Planes Acciones Correctivas
Monitorizar Analizar
Monitorizar Monitorizar Conducir
Parámetros Cuestiones
Riesgos Implicación Revisiones
Planificación
Stakeholder
Tomar
Monitorizar Conducir
Monitorizar Acciones
Gestión Revisiones
Compromisos correctivas
Datos de Progreso
Gestionar
Acciones
correctivas
PP Planes de Proyecto
26
Áreas
Áreas de
de proceso
proceso
Gestión
Gestión de
de proyecto:
proyecto: gestión
gestión yy acuerdos
acuerdos con
con proveedores
proveedores
Propósito: Gestionar la adquisición de productos a proveedores según un acuerdo formal existente.
Establecer Acuerdos con Proveedores
Determinar Establecer
Tipo Seleccionar Acuerdos
Adquisición Proveedores
Lista de productos
Requisitos Proveedor Producto Acuerdo Proveedor
Satisfacer
Acuerdos
Proveedor Ejecutar
Acuerdos
Revisar Aceptar Transición
Productos Producto Productos
COTS
27
Áreas
Áreas de
de proceso
proceso
Ingeniería
Ingeniería
Las áreas de proceso de ingeniería cubren las practicas de desarrollo y mantenimiento compartidas
por diferentes disciplinas como ingeniería de software e ingeniería de sistemas.
El modelo CMMI SE/SW incluye seis áreas de proceso en ingeniería:

 Desarrollo de requisitos
 Gestión de requisitos
 Soluciones técnicas
 Integración de producto
 Verificación
 Validación
28
Áreas
Áreas de
de proceso
proceso
Ingeniería:
Ingeniería: áreas
áreas básicas
básicas
Requisitos
REQM
Requisitos de producto &

Componente de producto
Soluciones
Alternativas Componentes
Producto Producto
RD TS PI CLIENTE
Requisi-
tos
Componentes de producto, productos del trabajo,

informes de verificación y validación
VER VAL
Necesidades del cliente

29
Áreas
Áreas de
de proceso
proceso
Ingeniería:
Ingeniería: gestión
gestión de
de requisitos
requisitos
Propósito: Gestionar los requisitos del producto y de componentes del producto del proyecto e
identificar inconsistencias entre los requisitos, los planes del proyecto y los resultados del trabajo.
Gestión de Requisitos
Entender Identificar
los Inconsistencias
Requisitos entre
Requisitos
Proyecto y
Requisitos
Gestionar Mantener
Obtener Trazabilidad
compromisos Cambios
Requisitos
a Requisitos Requisitos
Matriz
Trazabilidad
30
Áreas
Áreas de
de proceso
proceso
Ingeniería:
Ingeniería: desarrollo
desarrollo de
de requisitos
requisitos
Propósito: Producir y analizar los requisitos del cliente, del producto y de los componentes de
producto.
Desarrollar Desarrollar Analizar y

Requisitos Requisitos Validar
del Cliente del Producto Requisitos
Requisitos Requisitos Requisitos

Cliente Producto Validados
31
Áreas
Áreas de
de proceso
proceso
Ingeniería:
Ingeniería: solución
solución técnica
técnica
Propósito: Desarrollar, diseñar e implementar soluciones a los requisitos.
Requisitos
Validados
Seleccionar Desarrollar Implementar

Soluciones
Diseño Producto
Producto-Comp.
Diseños alternativos Diseño detallado & Producto

y Criterios de evaluación Documentacion Entregado
32
Áreas
Áreas de
de proceso
proceso
Ingeniería:
Ingeniería: integración
integración de
de producto
producto
Propósito: Ensamblar el producto asegurando que funciona apropiadamente y entregar el producto.
DAR
Preparar Integración Plan Garantizar

Producto Integración Interfaces
Compatibles
Assemblies
Sub-
Solución
Técnica assemblies
Ensamblar
Comp. Producto y
Entregar Producto
33
Áreas
Áreas de
de proceso
proceso
Ingeniería:
Ingeniería: verificación
verificación
Propósito: Asegurar que los resultados del trabajo seleccionados cumplen los requisitos
especificados.
Preparar para Ejecutar

Verificación Peer Reviews
Plan
Verificación
Verificar Productos
Seleccionados
Acciones
Correctivas
34
Áreas
Áreas de
de proceso
proceso
Ingeniería:
Ingeniería: validación
validación
Propósito: Demostrar que un producto o componente de producto satisface su uso previsto en el

entorno previsto.
- Requisitos Cliente
- Requisitos Producto
- Productos
- Validación de Requisitos Validar Producto o
Componentes Producto
Preparar para
Validación
-Conformidad
-Deficiencias
- Plan Validación Requisitos

- Plan Validación Producto
- Procesos y necesidades de Soporte
35
Áreas
Áreas de
de proceso
proceso
Soporte
Soporte
Las áreas de procesos de soporte cubren las practicas que sirven de base para el desarrollo del
producto y su mantenimiento.
El modelo CMMI SE/SW incluye cinco áreas de proceso en soporte:

 Gestión de la configuración
 Gestión de la calidad de procesos y productos
 Medición y análisis
 Análisis y resolución de decisiones
 Análisis y resolución de problemas
36
Áreas
Áreas de
de proceso
proceso
Soporte:
Soporte: áreas
áreas básicas
básicas
Calidad y no
Medidas, conformidades
análisis
MA Todas las áreas de proceso PPQA
Información Procesos y
necesaria resultados;
estándares y
Elementos de procedimientos
configuración;
peticiones de Líneas base;
cambio informes de auditoria
CM
37
Áreas
Áreas de
de proceso
proceso
Soporte:
Soporte: gestión
gestión de
de la
la configuración
configuración
Propósito: Establecer y mantener la integridad de todos los productos de trabajo, utilizando

identificación de la configuración, control de la configuración, informes de estado de configuración y
auditorias de la configuración.
Sistema
Gestión
Configuración
Establecer Estado
Líneas BBDD
Base Peticiones
de cambio Resultados
Auditoria
Establecer
Peticiones Integridad
de cambio Elementos
Acción
Seguir y controlar cambios
38
Áreas
Áreas de
de proceso
proceso
Soporte:
Soporte: aseguramiento
aseguramiento de
de la
la calidad
calidad de
de procesos
procesos yy producto
producto
Propósito: Proporcionar un entendimiento objetivo de los procesos y los productos del trabajo
asociado.
Evaluar objetivamente procesos y productos de trabajo
Evaluación Evaluación
Objetiva Objetiva
Productos P. Trabajo
Procesos
trabajo y Servicios
Informes y Registros
Proporcionar entendimiento objetivo
Comunicar
y Garantizar Establecer
Resolución de Registros
No Conformidades
39
Áreas
Áreas de
de proceso
proceso
Soporte:
Soporte: medición
medición yy análisis
análisis
Propósito: Desarrollar y mantener una capacidad para medir, utilizada para dar soporte a las
necesidades de información de la gerencia.
Ajustar actividades de medición y análisis
Objetivos Medición Repositorio

Medición Procedimientos,
Herramientas
Personal Indicadores Medición
Medición
Proporcionar resultados de mediciones
40
Áreas
Áreas de
de proceso
proceso
Gestión
Gestión de
de procesos
procesos
Las áreas de procesos de soporte cubren las actividades de definición, planificación, recursos,
desarrollo, implementación, monitorización, control, evaluación, medición y mejora de procesos.
El modelo CMMI SE/SW incluye cinco áreas de proceso en gestión de procesos:

 Definición de procesos
 Enfoque de procesos a la organización
 Formación
 Rendimiento de los procesos
 Innovación y desarrollo
41
Áreas
Áreas de
de proceso
proceso
Gestión
Gestión de
de procesos:
procesos: áreas
áreas básicas
básicas
Necesidades
y objetivos
de procesos
Senior Formación en
Management procesos
Objetivos
Negocio
OT Necesidades
Formación
Procesos
Estándares y
Propios Procesos
Estándares Áreas de proceso de
y Propios gestión de proyecto,
OPF Recursos y
OPD soporte e ingeniería
Coordinación
Información de mejora
Propósitos de mejora de (e.j., lessons learned, datos)
procesos; Participación
en definir, evaluar, y
desarrollar procesos
42
Modelos ágiles
43
Gestión de proyectos
Desavenencias
Desavenencias
Gestión formal Gestión ágil
Trabajo
Trabajo yy gestión
gestión guiada
guiada por
por un
un plan
plan general
general del
del La
La planificación
planificación del
del trabajo
trabajo sólo
sólo comprende
comprende elel ciclo
ciclo
proyecto
proyecto que
que comprende
comprende todo
todo su
su ciclo
ciclo de
de en
en el
el que
que se
se está
está trabajando
trabajando (normalmente
(normalmente 3030
desarrollo.
desarrollo. días).
días). Algunos
Algunos modelos
modelos ágiles
ágiles prohíben
prohíben el
el uso
uso de
de
gráficos
gráficos de
de Gantt
Gantt
Conocimiento
Conocimiento detallado
detallado de
de los
los requisitos
requisitos antes
antes de
de Descubrimiento
Descubrimiento progresivo
progresivo de
de requisitos,
requisitos, ee
comenzar
comenzar el
el diseño
diseño del
del proyecto
proyecto incorporación
incorporación de
de cambios
cambios en
en cualquier
cualquier iteración
iteración del
del
desarrollo
desarrollo
“Hacerlo
“Hacerlo bien a la primera”.
primera”. “Refactorización”
“Refactorización” de código como modelo
modelo dede
Evitar
Evitar la
la re-codificación
re-codificación y el re-trabajo que supone trabajo compatible con el punto anterior.
trabajo compatible con el punto anterior.
una
una pérdida
pérdida de
de eficiencia.
Comunicación
Comunicación formal
formal según
según el
el plan
plan de
de Comunicación
Comunicación directa
directa entre
entre los
los integrantes
integrantes del
del
comunicación del proyecto
comunicación del proyecto equipo
equipo (incluidos cliente y usuarios) prefiriendo
(incluidos cliente y usuarios) prefiriendo la
la
verbal
verbal directa.
directa.
Gestión
Gestión de
de equipos
equipos yy personas
personas centralizada
centralizada en
en el Equipos
Equipos auto-gestionados.
auto-gestionados.
gestor
gestor del
del proyecto
proyecto
44
Gestión de proyectos
Incompatibilidades
Incompatibilidades
Gestión formal Gestión ágil
Desarrollo
Desarrollo de
de sistemas
sistemas innovadores,
innovadores, enen entornos no Desarrollo
Desarrollo de
de sistemas
sistemas poco
poco innovadores
innovadores enen
conocidos
conocidos enen los
los que no resulta posible conocer los entornos
entornos conocidos
conocidos enen los
los que
que resulta
resulta posible
posible
requisitos
requisitos con
con detalle
detalle al
al empezar,
empezar, y elel grado
grado dede conocer
conocer con
con detalle
detalle los
los requisitos
requisitos desde
desde el
el principio.
principio.
inestabilidad
inestabilidad de
de requisitos
requisitos resulta
resulta elevado.
elevado. Sin
Sin la
la La
La gestión
gestión ágil
ágil conlleva
conlleva ciclos
ciclos de
de prototipado
prototipado
comunicación
comunicación yy revisión
revisión próxima
próxima del
del cliente
cliente yy con
con evolutivo
evolutivo cuando
cuando resultarían
resultarían másmás eficientes
eficientes
modelos
modelos formales
formales dede gestión
gestión de
de requisitos
requisitos peligra
peligra el
el modelos
modelos dede cascada.
cascada.
presupuesto
presupuesto yy lala calidad
calidad del
del proyecto.
proyecto.
Equipos
Equipos pequeños
pequeños en
en entornos
entornos yy mercados
mercados ágiles
ágiles Equipos
Equipos grandes,
grandes, físicamente
físicamente dispersos (verificación
(verificación
en
en los
los que
que el
el tiempo
tiempo de
de salida
salida al
al mercado
mercado es independiente,
independiente, varios
varios representantes
representantes de de los
los
importante.
importante. Los
Los modelos
modelos formales
formales implican
implican intereses
intereses de
de cliente:
cliente: sponsor,
sponsor, usuarios
usuarios
formalidades
formalidades que
que aportan
aportan muy
muy pocos
pocos beneficios
beneficios aa departamentales,
departamentales, varios
varios proveedores
proveedores trabajando
trabajando enen
este
este tipo
tipo de
de proyectos.
proyectos. el
el proyecto,
proyecto, etc.).
etc.). Sin
Sin un
un nivel
nivel formal
formal de
de
comunicación
comunicación yy coordinación
coordinación se se incrementan
incrementan los
los
riesgos
riesgos del
del proyecto.
proyecto.
Contratos
Contratos centrados
centrados enen “producto”
“producto” concon
funcionalidades,
funcionalidades, costes
costes yy fecha
fecha de
de entrega
entrega
cerrados.
cerrados. Sin
Sin conocer
conocer concon certeza
certeza los
los requisitos
requisitos yy
sin
sin hacer
hacer una
una planificación
planificación global
global sobre
sobre ellos
ellos no
no es
es
posible
posible hacer
hacer ningún
ningún cálculo
cálculo fiable.
fiable.
45
Gestión ágil de proyectos
Scrum
46
Gestión ágil de proyectos: Scrum
La
La esencia
esencia de
de Scrum
Scrum
 Al iniciar cada iteración, el equipo revisa el trabajo

pendiente del proyecto y selecciona la parte que
terminará como un incremento de funcionalidad
incorporado al software al terminar la iteración.
 Al final de la iteración el equipo presenta el incremento
de funcionalidad a las partes implicadas en el proyecto.
El equipo revisa los requisitos, considera la tecnología disponible, evalúa sus

conocimientos, y de forma colectiva determina cómo implementar la funcionalidad.
Roles
Roles
Scrum tiene una estructura muy simple. Todas las responsabilidades del proyecto se
reparten en 3 roles:
 Propietario del producto
 Equipo
 Scrum Master
47
Scrum
Scrum
Scrum es un método ágil de gestión de proyectos desarrollado por Ken Schwaber y Mike Beedle.
Se basa en los principios ágiles:
 Colaboración estrecha con el cliente.
 Predisposición y respuesta al cambio
 Prefiere el conocimiento tácito de las personas al explícito de los procesos
 Desarrollo incremental con entregas funcionales frecuentes
 Comunicación verbal directa entre los implicados en el proyecto
 Motivación y responsabilidad de los equipos por la auto-gestión, auto-organización y
compromiso.
 Simplicidad. Supresión de artefactos innecesarios en la gestión del proyecto.
48
Roles
Roles
Propietario
Propietario del
del producto
producto
Representa a todos los interesados en el producto final.
Sus áreas de responsabilidad son:
 Financiación del proyecto

 Requisitos del sistema
 Retorno de la inversión del proyecto
 Lanzamiento del proyecto
Equipo
Equipo
Responsable de transformar el Backlog de la iteración en un incremento de la
funcionalidad del software
 Auto-gestionado
 Auto-organizado
 Multi-funcional
Scrum
Scrum Master
Master
Responsable del proceso Scrum
 Formación y entrenamiento del proceso

 Incorporación de Scrum en la cultura de la empresa
 Garantía de cumplimiento de roles y responsabilidad
49
Roles:
Roles: gallinas
gallinas yy cerdos
cerdos
Una gallina y un cerdo paseaban por la carretera. La gallina dijo al

cerdo: “Quieres abrir un restaurante conmigo”. El cerdo consideró la
propuesta y respondió: “Sí, me gustaría. ¿Y cómo lo llamaríamos?”. La
gallina respondió: “Huevos con beicon”.
El cerdo se detuvo, hizo una pausa y contestó: “Pensándolo mejor,

creo que no voy a abrir un restaurante contigo. Yo estaría
realmente comprometido, mientras que tu estarías sólo implicada”.
Scrum diferencia claramente entre estos

dos grupos para garantizar que quienes
tienen la responsabilidad tienen también
la autoridad necesaria para poder lograr
el éxito, y que quienes no tienen la
responsabilidad no producen
interferencias innecesarias
IMPLICADOS EN EL PROYECTO
COMPROMETIDOS EN EL PROYECTO Marketing
Dueño del producto Comercial
Equipo Etc.
Scrum Master
50
El
El flujo
flujo de
de Scrum
Scrum
Nueva funcionalidad
Sprint Backlog
Product Backlog
seleccionado
Product Backlog
Requisitos priorizados
Visión:
ROI – versiones
hitos
Fuente: Agile Project Management with Scrum
Ken Schwaber
51
El
El flujo
flujo de
de Scrum
Scrum
52
Sprint
Sprint
Es el periodo de tiempo durante el que se desarrolla un incremento de funcionalidad.

Constituye el núcleo de Scrum, que divide de esta forma el desarrollo de un proyecto
en un conjunto de pequeñas “carreras”.
 Duración máxima: 30 días.

 Durante el sprint no se puede modificar el trabajo que se ha acordado en el Backlog.
 Sólo es posible cambiar el curso de un sprint, abortándolo, y sólo lo puede hacer el
Scrum Master si decide que no es viable por alguna de las razones siguientes:
 La tecnología acordada no funciona.
 Las circunstancias del negocio han cambiado.
 El equipo ha tenido interferencias.
53
Artefactos
Artefactos
Product
Product Backlog
Backlog
Listado con los requisitos del sistema
 Es responsabilidad del dueño del producto
 Contenido
 Priorización
 Disponibilidad
 Nunca llega a ser una lista completa y definitiva
 El empleado para planificar el proyecto es sólo una estimación inicial de requisitos
 Es un documento dinámico que incorpora constantemente las necesidades del sistema
 Se mantiene durante todo el ciclo de vida (hasta la retirada del sistema).
54
Artefactos
Artefactos
Product
Product Backlog
Backlog
Estimación inicial
Estim. ajustada
Trabajo pendiente
Complejidad
Product Backlog
Sprint
2
1
4
ID Elemento
1 Nuevo formulario para peticiones de clientes 2 0.2 2,4 2,4 0 0 0
2 Configuración de respuestas automáticas 3 0.2 3,6 3,6 0 0 0
3 Envío automático de respuestas 1 0.2 1,2 1,2 0 0 0
4 Consulta para los clientes de peticiones enviadas 1 0.2 1,2 1,2 0 0 0
5 Modificación del cliente de sus peticiones enviadas 2 0.2 2,4 2,4 0 0 0
6 Acceso a peticiones sólo para clientes del portal jurídico 5 0.2 6 6 0 6 0
7 Consulta de peticiones por parte del staff 1 0.2 1,2 1,2 0 0 0
SPRINT 1 15 18 18 0 0 0
8 Inserción de comentarios y reasignación a peticiones (staff) 2 0.2 1,2 1,2 1,2 0 0
9 Consultas por clientes, fechas y temas 3 0,2 3,6 3,6 3,6 0 0
10 [Continúa]….
55
Artefactos
Artefactos
Sprint
Sprint Backlog
Backlog
Trabajo o tareas determinadas por el equipo para realizar en un sprint y lograr al final del mismo
un incremento de la funcionalidad.
Se recomienda que las tareas reflejadas tengan una duración comprendida entre las 4 y las 16
horas de trabajo.
Las de mayor duración deben intentar descomponerse en sub-tareas de ese rango de tiempo.
56
Artefactos
Artefactos
Gráfica
Gráfica de
de progreso
progreso
57
Comunicación
Comunicación
Reunión diaria
Revisión del sprint
Reunión retrospectiva
La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de

un equipo de desarrollo es mediante la conversación cara a cara.
Manifiesto Ágil
58
Comunicación
Comunicación
Reunión
Reunión diaria
diaria
Reunión del equipo con duración máxima de 15 minutos.
 Todos los días en el mismo sitio y a la misma hora.
 Se recomienda que sea la primera actividad del día.
 Deben acudir todos los miembros del equipo.
 Moderada por el Scrum Master, que pregunta a todos los asistentes
 ¿Cuál ha sido el trabajo realizado desde la última revisión diaria?
 ¿Cuál es el trabajo previsto para hoy?
 ¿Hay algo que necesitas, o que te impide realizar el trabajo previsto?
 No se permite entrar en divagaciones o salirse del guión.
 Sólo habla la persona que informa de su trabajo, el resto escucha y no hay lugar para
otras conversaciones.
 Cuando un miembro informa de algo de interés para otros, o necesita ayuda de otros,
estos se reúnen al terminar la revisión diaria.
 Las gallinas no pueden intervenir ni distraer, y el Scrum Master puede limitar el número
de gallinas asistentes si lo considera oportuno.
 ¿Qué trabajo has realizado desde la última reunión?

 ¿Qué tienes previsto para hoy?
 ¿Qué necesitas?
59
Comunicación
Comunicación
Revisión
Revisión del
del sprint
sprint
Reunión del equipo, Scrum Master, propietario del producto con todas las personas implicadas en
el proyecto (gallinas).
 Duración máxima: 4 horas.
 Finalidad: presentar al propietario del producto y a las gallinas las nuevas funcionalidades
implementadas.
 Las funcionalidades no implementadas no se presentan.
 En la reunión, los miembros del equipo muestran las nuevas funcionalidades.
 Al final de la reunión se interroga individualmente a todos los asistentes para recabar
impresiones, sugerencias de cambio y mejora, y su relevancia.
 El propietario del producto trata con los asistentes y con el equipo las posibles
modificaciones en el Backlog.
60
Comunicación
Comunicación
Reunión
Reunión retrospectiva
retrospectiva
Acuden el equipo y el Scrum Master, y opcionalmente el Propietario del Producto.
 Todos los miembros del equipo responden a dos preguntas:
 ¿Qué cosas fueron bien en el último sprint?
 ¿Qué cosas se podrían mejorar?
 El Scrum Master anota todas las respuestas
 El equipo prioriza las mejoras posibles
 El Scrum Master no proporciona respuestas, sino que ayuda al equipo a encontrar la
mejor forma de trabajar con Scrum.
 Las acciones de mejora localizadas que se puedan implementar en el próximo Sprint
deben introducirse en el Backlog como elementos no funcionales.
61
Gestión de organizaciones de Software
62
Gestión de organizaciones de software
Retos
Retos en
en organizaciones
organizaciones de
de software
software
Retos
Retos de
de negocio
negocio Retos
Retos del
del software
software
 Mercado  Incumplimiento de fechas

 Definición de productos / servicios  Modificaciones de requisitos
 Competencia  Costes desbordados
 Financiación  Presión en el desarrollo
 Estrategia  Funcionalidades inadecuadas
 Etc.  Etc.
¿El software es así?

63
Software,
Software, ¿reto
¿reto oo ventaja?
ventaja?
 Amplitud de mercado
 Economía de escala en su producción
 Distribución
 Maleabilidad y desarrollo incremental
Todas las empresas quieren producir más rápido, mejor y con menores
costes, y sin duda esto es posible porque la naturaleza del software no es
origen de riesgos y problemas, sino una fuente de oportunidades
Según como afrontan las organizaciones el desarrollo del software, éste puede
comportarse como factor de riesgo o amenaza para el negocio; o por el contrario
como una poderosa oportunidad de negocio.
64
Madurez
Madurez de
de la
la organización
organización yy capacidad
capacidad de
de sus
sus procesos
procesos
El éxito o fracaso de las organizaciones que trabajan sin metodologías depende del conocimiento
tácito de su personal, pero teniendo en cuenta que se trata del conocimiento que cada uno traía
ya de la calle, o del que adquiere motu proprio, porque estamos hablando de "ninguna
metodología", lo que implica que como mucho los procesos de formación de la empresa llegan al
"ahí tienes manuales y libros, por si hubiera algo que no sabes".
Este es sin duda el modelo con el que empiezan muchas empresas "start-up": un equipo de
emprendedores con talento, capaces de construir sistemas de software con calidad.
Los resultados serán tan buenos como ellos los sepan hacer. El cumplimiento de agendas
dependerá de su capacidad de previsión y organización. Pero no hay que engañarse; en este caso
no se trata de empresas que saben hacer software, sino de personas que saben hacer software.
Los procesos o la normalización en los métodos de trabajo son

necesarios para dar el paso de personas que saben hacer software a
empresa que sabe hacer software. Salto que supone que no van a ser
ya los emprendedores, sino su empresa la que deberá producir de
forma eficiente y repetible en todos sus proyectos, resultados de calidad
65
Características
Características de
de los
los procesos
procesos
 Repetibilidad de resultados. Al conseguir que la calidad del resultado sea consecuencia del
proceso, producir aplicando el mismo proceso garantiza la homogeneidad de los resultados.
 Escalabilidad. Es una consecuencia de la repe-tibilidad. No sólo un equipo consigue resultados
homogéneos en todos los proyectos, sino que los obtienen todos los equipos.
 Mejora continua. Al aplicar meta-procesos que trabajan sobre los propios procesos de
producción, midiendo y analizando los resultados se obtienen los criterios de gestión necesarios
para aplicar medidas que mejoran de forma continua la eficiencia y calidad de los procesos
base, y por tanto de los resultados.
 Un know-how propio, consiguiendo finalmente una empresa que sabe hacer, porque su
modelo de procesos termina conteniendo un activo valioso de la organización: la clave para
hacer las cosas bien, con eficiencia y de forma homogénea.
66
Pero
Pero no
no sólo
sólo son
son procesos
procesos
PERSONAS
PROCESOS TECNOLOGÍA
67
Pero
Pero no
no sólo
sólo son
son procesos
procesos
Los procesos marcan pautas para realizar el trabajo, pero sin las personas y las herramientas
(tecnología) necesarias, lo que se puede producir con ellos es más bien poco.
Las únicas combinaciones válidas para formar sistemas capaces de producir resultados son:
Personas + tecnología Producción heroica
Personas + procesos + tecnología Producción basada en procesos
La realidad de los procesos es cierta, pero en el triángulo personas - procesos - tecnología cada
elemento actúa con un peso específico, diferente en función del tipo de producción, e incluso de
las características de personalidad de cada empresa.
Cada sector y cada empresa, más que importar una metodología estándar sacada del manual del
perfecto consultor, debe comenzar por el gnosce te ipsum, y a partir de ahí analizar y descubrir la
potencia de cada uno de los tres elementos de la producción para componer el diseño de un
sistema de producción a su medida.
La “talla única” no existe, ni para modelos de procesos ni para modelos de gestión
68
Personalidad
Personalidad de
de la
la organización
organización
Capital
Capital Estructural Humano
Modelo
Modelo de
de
producción
producción
Factores
Factores del
del Procesos Tecnología Personas
sistema
sistema de
de producción
producción
Artesanía
conocimiento - valor
Ubicación del
conocimiento
Producción heroica
Producción industrial
Conocimiento
Conocimiento Conocimiento
Conocimiento
explícito
explícito tácito
tácito
69
Personalidad
Personalidad de
de la
la organización
organización
El capital estructural está formado por los bienes que quedan en la empresa
cuando las personas se van a sus casas: patentes, licencias, cartera de clientes,
equipos, maquinaria, vehículos, etc.
El capital humano es el compuesto por el valor que la empresa emplea

en su negocio y que resulta inseparable de las personas.
Todas las industrias necesitan ambos tipos de capitales para elaborar los productos o servicios de
su negocio, pero la relevancia con la que cada uno de ellos puede influir en el resultado final es
muy diferente de unas empresas a otras.
Es frecuente que para las empresas dedicadas a la fabricación de productos el componente
estructural sea más crítico que para las dedicadas a los servicios, en las que el elemento humano
tiene más relevancia.
Pero este no es un principio universal, y dentro de la misma industria o del mismo sector, la
estrategia y la táctica de cada empresa también influyen en los niveles de relevancia que van a
tener el capital humano y el estructural.
70
Personalidad
Personalidad de
de la
la organización
organización
Procesos Tecnología Personas Conseguir que el sistema de procesos, tecnología y

personas formen una ventaja competitiva frente a la
competencia, y no un reto más del negocio, no es fácil, ni
puede importarse con la implantación “prêt-à porter” de un
modelo estándar.
Como refleja la figura, la clave del éxito radica en
Valor
Valor aportado
aportado Valor que se conseguir que cada factor pueda aportar el mayor valor
en
en la
la producción
producción podría aportar hasta el límite de su mejor relación eficiencia / calidad.
En esta tarea nunca está dicha la última palabra, y la labor
de innovación constante en procesos y tecnología puede ir
ampliando los límites de valor a un factor para conseguir
un nuevo equilibrio con mejores parámetros de eficiencia y
calidad en el sistema.
La obsesión por la excelencia mal entendida, lleva a muchos gestores a centrar sus esfuerzos en la
incorporación de modelos o técnicas, bien de procesos, bien de recursos humanos o de innovación
tecnológica; o de todos a la vez sin los criterios adecuados.
71
Gestión
Gestión específica
específica yy sistémica
sistémica
El
El mito
mito de
de la
la “talla
“talla única”
única”
Las organizaciones
El software
72
Gestión
Gestión sistémica
sistémica
Para conseguir eficiencia en su estrategia de producción esta deberá ser consecuente y estar
alineada con:
 La visión: Qué quiere llegar a ser la organización y cuál es su meta.

 Estrategia: foco y plan de negocio, contemplando el mercado, las
fortalezas y debilidades propias, etc.
El mayor o menor grado de éxito en la calidad y eficiencia en el desarrollo de software depende del
equilibrio que se consiga al conjugar los siguientes factores:
 Características de los proyectos de software gestionados.
 Visión de la organización.
 Cultura de la organización.
 Diseño y gestión del equilibrio productivo personas-procesos-tecnología.
73
Gestión
Gestión sistémica
sistémica
Características
Características de
de los
los proyectos
proyectos de
de software
software
Organizativas
El concepto sistema de software es muy amplio, y tan sistema de software es el integrado
en un teléfono celular, como el desarrollado en un proyecto Open Source por iniciativa del
propio grupo de desarrolladores; o el diseñado para asistir el pilotaje de un avión
comercial
Tamaño
El tamaño también importa. Un sistema puede requerir el esfuerzo de un programador durante
un par de meses, o de un equipo de varias decenas de personas durante un par de años
Contractuales
Las características del proyecto quizá la funcionalidad alcanzada en cada versión, así como la
precisión en el cumplimiento de las fechas puede ser poco trascendente o vital para el
negocio del cliente.
Integridad del sistema

El nivel de integridad del sistema, o daño que pueden producir los fallos del sistema, también
determina el rigor de los procesos que deben aplicarse en su desarrollo
74
Gestión
Gestión sistémica
sistémica
Visión,
Visión, misión
misión yy estrategia
estrategia de
de la
la organización
organización
 ¿Tiene la organización una visión definida, compartida y trasladada a toda la

organización?
 ¿Por qué desarrolla software?
 Pone el en mercado productos cerrados de software
 Desarrolla soluciones basadas en sistemas de software
 Es el departamento de una universidad en un proyecto Open Source
 …
 ¿Qué papel juega la innovación y vanguardia tecnológica en su misión?
 ¿Y la seguridad y fiabilidad del software que desarrollo.
 ¿Los desarrollos son para clientes finales externos, clientes internos de la organización,
subsistemas para la integración en sistemas mayores de otras organizaciones…?
 ¿Mantienen operativos otros sistemas ya desarrollados?
 ¿Programan sistemas poco innovadores sobre plataformas contrastadas en negocios y
entornos conocidos.
 ¿Apuestas por la innovación, implementación sobre dispositivos nuevos, o diseñan
soluciones para entornos novedosos?
75
Gestión
Gestión sistémica
sistémica
Cultura
Cultura
 ¿Es una organización con niveles jerárquicos y funciones claramente definidas?

 ¿Cuáles son los niveles de confianza, delegación, empowerment y responsabilidad?
 ¿Clima laboral, motivación?
Equilibrio
Equilibrio personas-procesos-tecnología
personas-procesos-tecnología
 ¿Cuál es la estrategia productiva?

 Tecnología empleada en el desarrollo: equipos, red, sistemas de pruebas, plataformas
operativas, herramientas CAD…
 ¿Qué porcentaje del conocimiento necesario para la ejecución de los proyectos está
garantizado en los procesos, y cuánto en las personas?
 ¿Son coherentes las políticas o procesos deformación, contratación, planes de carrera,
modelos de procesos, calidad y mejora?.
76
Gestión
Gestión sistémica
sistémica
Estrategia
Estrategia de
de gestión
gestión
Para diseñar y gestionar entornos de producción eficientes se debe trabajar con

pensamiento sistémico, comprendiendo que todos los factores implicados en la
producción de software componen un sistema interrelacionado, imbricado y alineado con
la misión de la organización
Evitar la gestión lineal
Gestión lineal o a-sistémica, consiste en aplicar soluciones sintomáticas para cada

situación.
La gestión lineal, carece de la perspectiva necesaria, y responde de forma azuzada a la
presión del día a día.
Sin esa perspectiva no se ve el sistema, y el marco de trabajo se presenta como un
campo de batalla desordenado que requiere actuaciones en cada uno de los frentes que
presenta
Las soluciones obvias no funcionan. En el mejor de los casos introducen mejoras en el
corto plazo que terminarán por empeorar la situación.
La presión del día a día ofrece dos atajos muy tentadores que se deben evitar:
 Aplicar soluciones enfocadas en resultados en el corto plazo.
 Obtener mediciones y datos que demuestren un buen comportamiento.
77
Eficiencia
Eficiencia
La eficiencia es el resultado de la idoneidad y equilibrio de todos los

componentes de la producción
(modelos
(modelos de
de procesos,
procesos, cultura
cultura de
de empresa, gestión de recursos humanos, plataforma de
programación…)
Claves
Claves para
para realizar
realizar una
una gestión
gestión eficiente
eficiente
 Personalidad de la organización
Esta es la referencia final con la que deben alinearse y sincronizarse todas las variables
que operan juntas para lograr los objetivos
 Conocimiento de la propia empresa
Objetivos, debilidades, fortalezas, relevancia del capital estructural y del capital
humano, composición actual, composición deseable…
 Conocimiento de nuestra industria
Situación de tecnologías, plataformas, modelos de producción y calidad, etc.
 Gestión sistémica
Conducir la gestión desde la visión de la organización
 Revisión y adaptación
El mercado, el entorno tecnológico y la misma base de conocimiento de nuestra
industria están en continua evolución. Es necesario vigilar el entorno e innovar.
78

Ingeniería de Sofware - Calidad - Metricas - Metodologías Ágiles - Procesos - Proyecto

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

Ingeniería de Sofware - Calidad - Metricas - Metodologías Ágiles - Procesos - Proyecto

Cargado por

Copyright:

Formatos disponibles

Modelos formales: CMMI

 Deficiencias en las metodologías  Incapacidad para manejar el

 En 1986, SEI (Software Engineering Institute): marco de trabajo

 En 1991, SEI desarrolló Capability Maturity Model (CMM)

 Guía en la selección de estrategias de mejora de proceso

Idea principal: distinción entre empresas maduras/inmaduras

En una organización inmadura:

 En una organización madura:

 DoD (Departamento de Defensa de los Estados Unidos), SEI (Software

 Ambas incluyen el mismo contenido y consiguen idénticos

 Heredado de los modelos de origen.

 En el del equipo de desarrollo de CMMI había defensores de de

 Seleccionar una única representación se planteaba como algo “too

 Compromiso: Inicialmente soportar dos representaciones del

 Capacidad es un atributo que se aplica a los procesos y define la

 Madurez es un atributo que se aplica a la organización y define su

Los valores describen “cómo de bien” se realiza el proceso (nivel

Proceso bien ejecutado y

Area Area Area Area

 CMMI recoge prácticas para 22 áreas de procesos

 Las áreas de procesos agrupan a las actividades necesarias para

 El modelo en su representación escalonada clasifica a las 22

 El modelo en su representación continua las clasifica según a la

4 GESTIONADO Gestión cuantificada de proyectos

SOPORTE Medición y análisis

Definición de los procesos de la organización

GESTIÓN DE PROCESOS Procesos orientados a la organización

Notas Objetivos específicos

 CMMI SE/SW incluye 22 áreas de proceso

 Las áreas de proceso son iguales en ambas representaciones del modelo

 En la representación continua, las áreas de proceso se agrupan por categorías: Gestión de

 En la representación escalonada, las áreas de proceso se agrupan por niveles de madurez (2 –

El modelo CMMI SE/SW incluye seis áreas de proceso en gestión de proyectos:

PMC Estado, cuestiones, resultados

Estado, Que construir

Requisitos de componente de producto

Establecer Datos Desarrollar Plan

Propósito: Gestionar la adquisición de productos a proveedores según un acuerdo formal existente.

Establecer Acuerdos con Proveedores

El modelo CMMI SE/SW incluye seis áreas de proceso en ingeniería:

Requisitos de producto &

Componentes de producto, productos del trabajo,

Necesidades del cliente

Desarrollar Desarrollar Analizar y

Requisitos Requisitos Requisitos

Propósito: Desarrollar, diseñar e implementar soluciones a los requisitos.

Seleccionar Desarrollar Implementar

Diseños alternativos Diseño detallado & Producto

Propósito: Ensamblar el producto asegurando que funciona apropiadamente y entregar el producto.

Preparar Integración Plan Garantizar

Preparar para Ejecutar

Propósito: Demostrar que un producto o componente de producto satisface su uso previsto en el

- Plan Validación Requisitos

El modelo CMMI SE/SW incluye cinco áreas de proceso en soporte:

Propósito: Establecer y mantener la integridad de todos los productos de trabajo, utilizando

Evaluar objetivamente procesos y productos de trabajo

Proporcionar entendimiento objetivo

Ajustar actividades de medición y análisis

Objetivos Medición Repositorio

Proporcionar resultados de mediciones

El modelo CMMI SE/SW incluye cinco áreas de proceso en gestión de procesos:

Gestión formal Gestión ágil

Gestión formal Gestión ágil