Modelos para Calidadimp

1.
- Agilidad y procesos
1
Agilidad y procesos
Visión simplificada de modelos formales y ágiles
Modelos genéricos Modelos para software
Adaptaciones
para softw.
1997
Modelos y estándares
formales de calidad
TickIT
1991
ISO 9000-3
1959 1979 1987 Trillium
MIL-Q 9858 BS 5750 ISO 9000 Bootstrap
1995
Modelos específicos
ISO 12207
para software.
1995 TR 15504 2003-05
Proy. SPICE ISO 15504
1993 Modelos 2001
CMM-SW CMM CMMI
DSDM
Técnicas y métodos
SCRUM
CRYSTAL
XP
ágiles
ASD
PP
ISD
AM
2000
1995 Manifiesto
Ágil
2
Modelos formales: CMMI
CMM (Capability Maturity 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
3
Organizaciones de software maduras / inmadudas
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
4
Proyecto 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
5
Modelos CMMI
 Modelo combinado
System Engineering/Software
Engineering
MM I - SE/SW CMMI-SE
/SW  Aplicable:
C
ous – Sólo a proyectos de software
Staged tion Continu tion
enta nta engineering
Repres Represe
– Sólo a proyectos de system
engineering
– Ambos
¿Continua o 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
6
¿Por qué dos representaciones del 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.
7
Un modelo, dos 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
8
Capacidad y 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
9
Niveles de 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
10
Dimensión de la 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
11
Niveles de 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
12
Dimensión de la 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
13
Áreas de 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
14
Áreas de procesos en la representación 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
15
Áreas de procesos en la representación 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
16
Cómo usar el modelo

Área de proceso
Conjunto de practicas relacionadas que son ejecutadas de forma conjunta para conseguir un
conjunto de objetivos.
Componentes 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
17

Componentes 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 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
18

Componentes 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.
19
Mapa del documento
Área de proceso
Propósito
Notas Objetivos específicos
Objetivos genéricos
Referencias
20
Mapa del documento

R. Metas-Practicas
Practicas especificas
Nombres 21
Mapa del documento

Notas Practicas genericas
Productos de
trabajo
Subpracticas
Elaboraciones
22
Áreas de 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
23
Áreas de proceso
Gestión de 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
24
Modelos formales: ISO/IEC 15504
ISO/IEC 15504: Origen

Proyecto SPICE
En enero de 1993 la comisión ISO/IEC JTC1 aprobó un programa de trabajo
para el desarrollo de un modelo que fuera la base de un futuro estándar
internacional para la evaluación de los procesos del ciclo de vida del software.
Este trabajo recibió el nombre de proyecto SPICE (Software Process
Improvement and Capability dEtermination), y en junio de 1995, con la
publicación de su primer borrador, desde ISO fueron invitadas diferentes
organizaciones para aplicarlo y valorar sus resultados.
Proyecto -> Instrucción Técnica -> Estándar
En 1998, pasada la fase de proyecto, y tras las primeras evaluaciones, el trabajo pasó
a la fase de informe técnico con la denominación ISO/IEC TR 15504.
La instrucción técnica consta de 9 apartados, recogidos en volúmenes independientes,
que se han ido publicando como redacción definitiva del estándar internacional
ISO/IEC 15504 durante el periodo 2003-2005.
Ámbito de aplicación
 Cualquier organización de software que quiera establecer y mejorar su capacidad en
adquisición, suministro, desarrollo, operación evolución y soporte de software.
 Independientemente de estructuras, filosofías de gestión, modelos de ciclo de vida de

software, tecnologías o metodologías de desarrollo.
25
Estructura
Conceptos
P1 P9
y guía de Vocabulario
introducción
P7
P8 P6
Guía Guia para det. Guia de
para mejora capacidad de capacitación de
de procesos proveedores evaluadores
Realización
Guía de
de
P3 evaluación P4
evaluación
Modelo de ref. Modelo de

para procesos P2 evaluación P5
y capacidad y guía de indic.
26
Características
 Marco para métodos de evaluación, no es un método o modelo en sí.
 Comprende:
 Evaluación de procesos
 Mejora de procesos
 Determinación de capacidad
 Alineado con ISO/IEC 12207 Information Technology Software Life Cycle
Processes
Dimensiones del modelo
El modelo tiene una arquitectura basada en dos dimensiones:
 Dimensión de proceso
Caracterizada por las declaraciones del propósito de un proceso,
que son objetivos esenciales mensurables de un proceso.
 Dimensión de capacidad de proceso

Caracterizada por una serie de atributos de proceso, aplicables a
cualquier proceso, que representan características mensurables
necesarias para gestionar un proceso y mejorar su capacidad.
27
Características
Dimensión de proceso
Agrupa los procesos en tres grupos correspondientes a los procesos del

ciclo de vida que contienen cinco categorías de acuerdo al tipo de
actividad.
Procesos primarios Procesos de soporte

 CUS: Cliente – Proveedor  SUP: Soporte
 ENG: Ingeniería
Procesos organizacionales
 MAN: Gestión
 ORG: Organización
28
CUS: Cliente - proveedor
La categoría CUS está formada por procesos que afectan directamente al

cliente, soportan el desarrollo y la transición del software al cliente y
permiten la correcta operación y uso del producto y/o servicio de software.
 CUS.1 Proceso de adquisición

 CUS.1.1 Proceso de preparación de la adquisición
 CUS.1.2 Proceso de selección de proveedor
 CUS.1.3 Procesos de seguimiento de proveedor
 CUS.1.4 Proceso de aceptación del cliente
 CUS.2 Proceso de suministro
 CUS.3 Proceso de obtención de requisitos
 CUS.4 Proceso de operación
 CUS.4.1 Proceso de uso operacional
 CUS.4.2 Proceso de soporte al cliente
29
ENG: Ingeniería
La categoría ENG está formada por procesos que directamente especifican,

implementan o mantienen el producto de software, su relación con el
sistema y documentación.
 ENG.1 Proceso de desarrollo
 ENG.1.1 Proceso de análisis y diseño de requisitos de sistema.
 ENG.1.2 Proceso de análisis de requisitos de software.
 ENG.1.3 Procesos de diseño de software.
 ENG.1.4 Proceso de construcción de software.
 ENG.1.5 Proceso de integración de software.
 ENG.1.6 Proceso de prueba de software.
 ENG.1.7 Proceso de integración y prueba de sistema.
 ENG.2 Proceso de mantenimiento de software
30
SUP: Soporte
La categoría SUP está formada por procesos que dan soporte al resto de
procesos (incluidos los SUP), en distintos puntos del ciclo de vida del
software.
 SUP.1 Proceso de documentación
 SUP.2 Proceso de gestión de configuración
 SUP.3 Proceso de aseguramiento de calidad
 SUP.4 Proceso de verificación
 SUP.5 Proceso de validación
 SUP.6 Proceso de revisión conjunta
 SUP.7 Proceso de auditoría
31
MAN: Gestión
La categoría MAN está formada por procesos utilizados en la gestión de

cualquier tipo de proyecto o proceso en el ciclo de vida del software.
 MAN.1 Proceso de gestión
 MAN.2 Proceso de gestión de proyecto
 MAN.3 Gestión de calidad
 MAN.4 Gestión de riesgos
32
ORG: Organización
La categoría ORG está formada por procesos que establecen los objetivos
de negocio de la organización.
 ORG.1 Proceso de alineación organizacional.
 ORG.2 Proceso de mejora
 ORG.2.1 Proceso de definición de proceso.
 ORG.2.2 Proceso de evaluación de proceso.
 ORG.2.3 Proceso de mejora de proceso.
 ORG.3 Proceso de gestión de RR.HH.
 ORG.4 Proceso de infraestructura
 ORG.5 Proceso de medición
 ORG.6 Proceso de reutilización
33
Componentes de proceso
 Identificador
Identifica la categoría del proceso y el nº de secuencia en la categoría.
Distingue entre procesos de primer y segundo nivel.
 Nombre
Frase descriptivo del contenido del proceso
 Tipo
Hay 5 tipos de proceso. 3 de primer nivel (básico, extendido y nuevo) y 2 de
segundo nivel (componente, componente extendido)
 Propósito
Párrafo que establece el propósito del proceso indicando los objetivos
globales de su ejecución.
 Salidas
Lista de resultados observables de la implementación exitosa del proceso
 Notas
34
Dimensión de capacidad
Capacidad de proceso: rango de resultados que espera obtenerse

al seguir el proceso.
 Define una escala de medida para determinar la capacidad de cualquier
proceso
 Consta de seis niveles de capacidad
Nivel 0 Incompleto
Nivel 1 Realizado
Nivel 2 Gestionado
Nivel 3 Establecido
Nivel 4 Predecible
Nivel 5 En optimización
 ...y un conjunto de atributos de procesos asociados al nivel de
capacidad
35
Niveles de capacidad y atributos
 Nivel 0: Proceso Incompleto

 Nivel 1: Proceso Realizado
 Nivel 2: Proceso Gestionado
 PA 2.1 Gestión de realización
 PA 2.2 Gestión productos
 Nivel 3: Proceso Establecido
 PA 3.1 Definición de proceso
 PA 3.2 Recursos de proceso
 Nivel 4: Proceso Predecible
 PA 4.1 Medición
 PA 4.2 Control de proceso
 Nivel 5: Proceso en optimización
 PA 5.1 Cambio de proceso
 PA 5.2 Mejora continua 36
Medición de atributos
Los atributos de un proceso se evalúan con N (Not), P (Partially), L
(Largely) y F (Fully), siendo:
No alcanzado (0% a 15%).
N Escasa o ninguna evidencia de la consecución del atributo.
Parcialmente alcanzado (16% a 50%).

Evidencia de un enfoque sistemático y de la consecucióndel
P
atributo. Algunos aspectos de la consecución pueden ser
impredecibles.
Ampliamente alcanzado (51% a 85%).
Evidencia de un enfoque sistemático y de una consecución
L significativa del atributo.
La realización del proceso puede variar en algunas áreas.
Totalmente alcanzado (86% a 100%).

Evidencia de un enfoque completo y sistemático y de la
F
consecución plena del atributo.
37
Origen de los “métodos ágiles” Agilidad y procesos
Manifiesto ágil (2001)
En marzo de 2001, 17 críticos de estos modelos, convocados por Kent

Beck, que acababa de definir una nueva metodología denominada Extreme
Programming, se reunieron en Salt Lake City para discutir sobre los
modelos de desarrollo de software.
En la reunión se acuñó el término “Métodos Ágiles” para definir a
aquellos que estaban surgiendo como alternativa a las metodologías
formales, (CMM-SW, PMI, SPICE) a las que consideraban excesivamente
“pesadas” y rígidas por su carácter normativo y fuerte dependencia de
planificaciones detalladas, previas al desarrollo.
Los integrantes de la reunión resumieron en cuatro postulados lo que ha
quedado denominado como “Manifiesto Ágil”, que compendia el espíritu en
el que se basan estos métodos.
Aunque como se verá más adelante, en la actualidad hay aproximaciones
que combinan lo mejor de ambos enfoques (formal y ágil), hasta 2005, en
cada lado sus defensores adoptaron posturas radicales, quizá más
ocupadas en descalificar a la contraria que en estudiarla y conocerla para
mejorar la propia.
38
Manifiesto ágil (2001)
Agilidad y procesos
Estamos poniendo al descubierto mejores métodos para

desarrollar software, haciéndolo y ayudando a otros a
que lo hagan. Con este trabajo hemos llegado a valorar:
A los individuos y su por de los procesos y las

interacción
El software que encima
por herramientas
de la documentación
funciona
La colaboración con el encima
por exhaustiva
la negociación
cliente
La respuesta al encima
por contractual
seguimiento de un
cambio encima plan
Aunque hay valor en los elementos de la derecha,
valoramos más los de la izquierda
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair
Cockburn, Ward Cunningham, Martin Fowler, James
Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon
Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken
Schwaber, Jeff Sutherland, Dave Thomas
http://agilemanifesto.org/
39
Agilidad y procesos
12 principios del manifiesto ágil
1.- Nuestra principal prioridad es satisfacer al cliente a

través de la entrega temprana y continua de software
de valor.
2.- Son bienvenidos los requisitos cambiantes,

incluso si llegan tarde al desarrollo. Los procesos
ágiles se doblegan al cambio como ventaja
competitiva para el cliente.
3.- Entregar con frecuencia software que funcione, en
periodos de un par de semanas hasta un par de
meses, con preferencia en los periodos breves.
4.- Las personas del negocio y los desarrolladores

deben trabajar juntos de forma cotidiana a través del
proyecto.
40
Agilidad y procesos
5.- Construcción de proyectos en torno a individuos

motivados, dándoles la oportunidad y el respaldo que
necesitan y procurándoles confianza para que realicen
la tarea.
6.- 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.
7.- El software que funciona es la principal medida del

progreso.
8.- Los procesos ágiles promueven el desarrollo

sostenido. Los patrocinadores, desarrolladores y
usuarios deben mantener un ritmo constante de forma
indefinida.
41
Agilidad y procesos
9.- La atención continua a la excelencia técnica

enaltece la agilidad.
10.- La simplicidad como arte de maximizar la

cantidad de trabajo que se hace, es esencial.
11.- Las mejores arquitecturas, requisitos y diseños

emergen de equipos que se auto-organizan.
12.- En intervalos regulares, el equipo reflexiona sobre

la forma de ser más efectivo y ajusta su conducta en
consecuencia.
42
3.- Modelos ágiles
43
Modelos ágiles
Ubicación en el panorama general de modelos y procesos
Modelos genéricos Modelos para software
Adaptaciones
para softw.
1997
TickIT
Modelos y estándares
1991
ISO 9000-3
de calidad
1959 1979 1987 Trillium

MIL-Q 9858 BS 5750 ISO 9000 Bootstrap
1995
Modelos específicos
ISO 12207
para software.
1995 TR 15504 2003-05
Proy. SPICE ISO 15504
1993 Modelos 2001
CMM-SW CMM CMMI
DSDM
Técnicas y métodos
SCRUM
CRYSTAL
XP
ágiles
ASD
PP
ISD
AM
2000
1995 Manifiesto
Ágil
44
Modelos ágiles
DSDM: Dynamic Systems Development Method
Es la metodología más veterana de las auto-denominadas ágiles. Surgió en 1994 de los trabajos de
Jennifer Stapleton, la actual directora del DSDM Consortium.
DSDM es la metodología ágil más próxima a los métodos formales, de hecho la implantación de un
modelo DSDM en una organización la lleva a alcanzar lo que CMM consideraría un nivel 2 de
madurez.
Sin embargo los aspectos que DSDM reprocha a CMM son:
 Aunque es cierto que se ha desarrollado con éxito en algunas organizaciones, lo que

funciona bien en unos entornos no tiene por qué servir para todos.
 CMM no le da al diseño la importancia que debería tener.
 CMM plantea un foco excesivo en los procesos, olvidando la importancia que en
nuestra industria tiene el talento de las personas.
 El tener procesos claramente definidos no es sinónimo de tener buenos procesos.
En común con los métodos ágiles, DSDM considera imprescindible una implicación y una relación
estrecha con el cliente durante el desarrollo, así como la necesidad de trabajar con métodos de
desarrollo incremental y entregas evolutivas.
DSDM cubre los aspectos de gestión de proyectos, desarrollo de los sistemas, soporte y
mantenimiento y se autodefine como un marco de trabajo para desarrollo rápido más que como un
método específico para el desarrollo de sistemas.
45
eXtreme Programming (XP)
Modelos ágiles
Este es el método que más popularidad ha alcanzado entre las
metodologías ágiles, y posiblemente sea también el más
transgresor de la ortodoxia basada en procesos.
Su creador, Kent Beck fue el alma mater del Manifiesto Ágil.
Extreme Programming (XP) se irgue sobre la suposición de que es
posible desarrollar software de gran calidad a pesar, o incluso
como consecuencia del cambio continuo. Su principal asunción es
que con un poco de planificación, un poco de codificación y unas
pocas pruebas se puede decidir si se está siguiendo un camino
acertado o equivocado, evitando así tener que echar marcha atrás
demasiado tarde.
Valores que inspiran XP
SIMPLICIDAD FEEDBACK CORAJE COMUNICACIÓN
46
Modelos ágiles
Comunicación
XP pone en comunicación directa y continua a clientes y desarrolladores. El cliente se
integra en el equipo para establecer prioridades y resolver dudas. De esta forma ve el
avance día a día, y es posible ajustar la agenda y las funcionalidades de forma
consecuente
Feedback rápido y continuo
Una metodología basada en el desarrollo incremental de pequeñas

partes, con entregas y pruebas frecuentes y continuas, proporciona
un flujo de retro-información valioso para detectar los problemas o
desviaciones.
 De esta forma fallos se localizan muy pronto.
 La planificación no puede evitar algunos errores, que sólo se
evidencian al desarrollar el sistema.
 La retro-información es la herramienta que permite reajustar
la agenda y los planes.
47
Modelos ágiles
Simplicidad
La simplicidad consiste en desarrollar sólo el sistema que realmente se

necesita. Implica resolver en cada momento sólo las necesidades actuales.
Los costes y la complejidad de predecir el futuro son muy elevados, y la
mejor forma de acertar es esperar al futuro.
Con este principio de simplicidad, junto con la comunicación y el feedback

resulta más fácil conocer las necesidades reales
Coraje
El coraje implica saber tomar decisiones difíciles. Reparar un error

cuando se detecta. Mejorar el código siempre que tras el feedback
y las sucesivas iteraciones se manifieste susceptible de mejora.
Tratar rápidamente con el cliente los desajustes de agendas para
decidir qué partes y cuándo se van a entregar.
48
Las 12 prácticas de XP Modelos ágiles
XP no es un modelo de procesos ni un marco de trabajo, sino un
conjunto de 12 prácticas que se complementan unas a otras y deben
implementarse en un entorno de desarrollo cuya cultura se base en
los cuatro valores citados
PRÁCTICAS DE CODIFICACIÓN
1.- Simplicidad de código y de diseño para producir software fácil de modificar.
2.- Reingeniería continua para lograr que el código tenga un diseño óptimo.
3.- Desarrollar estándares de codificación, para comunicar ideas con claridad a través
del código.
4.- Desarrollar un vocabulario común, para comunicar las ideas sobre el código con
claridad.
PRÁCTICAS DE DESARROLLO
1.- Adoptar un método de desarrollo basado en las pruebas para asegurar que el
código se comporta según lo esperado.
2.- Programación por parejas, para incrementar el conocimiento, la experiencia y
las ideas.
3.- Asumir la propiedad colectiva del código, para que todo el equipo sea
responsable de él.
4.- Integración continua, para reducir el impacto de la incorporación de nuevas
funcionalidades.
49
Modelos ágiles
Las 12 prácticas de XP
PRÁCTICAS DE NEGOCIO
1.- Integración de un representante del cliente en el equipo,

para encauzar las cuestiones de negocio del sistema de forma
directa, sin retrasos o pérdidas por intermediación.
2.- Adoptar el juego de la planificación para centrar en la agenda
el trabajo más importante.
3.- Entregas regulares y frecuentes para satisfacer la inversión
del cliente.
4.- Ritmo de trabajo sostenible, para terminar la jornada
cansado pero no agotado.
50
Scrum
Modelos ágiles
No es propiamente un método o metodología de desarrollo, e implantarlo como
tal resulta insuficiente.
Scrum define métodos de gestión y control para complementar la aplicación de
otros métodos ágiles como XP que, centrados en prácticas de tipo técnico,
carecen de ellas.
Los principios de Scrum son:
 Equipos autogestionados.
 Una vez dimensionadas las tareas no es posible agregarles
trabajo extra.
 Reuniones diarias en las que los miembros del equipo se plantean
3 cuestiones:
 ¿Qué has hecho desde la última revisión?
 ¿Qué obstáculos te impiden cumplir la meta?
 ¿Qué vas a hacer antes de la próxima reunión?
 Iteraciones de desarrollo de frecuencia inferior a un mes, al final
de las cuales se presenta el resultado a los externos del equipo de
desarrollo, y se realiza una planificación de la siguiente iteración, guiada
por cliente.
51
Modelos ágiles
Scrum
52
Otros métodos ágiles
Modelos ágiles
Familia de métodos Crystal
La familia de metodologías Crystal ofrece diferentes métodos para
seleccionar el más apropiado para cada proyecto.
Crystal identifica con colores diferentes cada método, y su elección debe ser
consecuencia del tamaño y criticidad del proyecto, de forma que los de
mayor tamaño, o aquellos en los que la presencia de errores o
desbordamiento de agendas implique consecuencias graves, deben adoptar
metodologías más pesadas.
Los métodos Crystal no prescriben prácticas concretas
ASD (Adaptative Software Development)
Método que como alternativa a los procedimientos formales,

aborda el desarrollo de grandes sistemas con el uso de técnicas
propias de las metodologías ágiles.
No se trata de una metodología, sino de la implantación de una
cultura en la empresa, basada en la adaptabilidad.
53
Otros métodos ágiles
Modelos ágiles
PP (Pragmatic Programming)
Pragmatic Programming es la colección de 70 prácticas de programación,
comunes a otros métodos ágiles, cuya aplicación resulta útil para solucionar
los problemas cotidianos
AM (Agile Modeling)
Agile Modeling es la presentación de un nuevo enfoque para realizar el

modelado de sistemas,(diseño) y basado en los principios de los métodos
ágiles remarca la conveniencia de reducir el volumen de la documentación.
ISD (Internet Speed Development)

Es el más reciente de los métodos ágiles, surgido como respuesta para
las situaciones que requieren ciclos de desarrollo muy breves con
entregas rápidas.
Se centra en el talento de las personas sobre los procesos.
ISD es un entorno de gestión orientado al negocio
FDD (Feature Driven Development)

Prescribe un proceso iterativo de 5 pasos, con iteraciones de dos semanas.El
punto de referencia son las características que debe reunir el software, y se
centra en las fases de diseño e implementación del sistema
54
Modelos ágiles
Modelos de propiedad Comercial: MSF
MSF es la metodología empleada por Microsoft para el desarrollo de software.

Hasta su versión 3 (principios de 2005) MSF se definía como un marco de desarrollo flexible para
adaptarse a las necesidades de cada proyecto, en oposición a lo que sería una metodología
prescriptiva; porque parte de la base de que no hay una estructura de procesos óptima para las
necesidades de todos los entornos de desarrollo posibles.
El marco MSF se asienta sobre unos Principios Fundamentales que definen la cultura del entorno
de desarrollo:
MSF: PRINCIPIOS FUNDAMENTALES
 Fomento de la comunicación abierta.

 Trabajo en torno a una visión compartida.
 Apoderar a los integrantes del equipo (“empowerment”)
 Establecimiento de responsabilidades claras y compartidas.
 Centrar el objetivo en la entrega de valor para el negocio.
 Permanecer ágiles y esperar e cambio.
 Invertir en calidad.
 Aprender de la experiencia.
55
Modelos ágiles

Elementos que componen el modelo
Principios fundamentales Principios básicos en los que se basa todo el modelo (los 8 de la pág. ant.)
Modelos Mapas mentales de organización. Hay 2: De equipo y de procesos
Áreas de trabajo en las que se usan métodos determinados (Gestión de

Disciplinas proyecto, de riesgos y de la mejora del talento)
Ideas que dan soporte a los principios y disciplinas de MSF y se muestran

Conceptos clave a través de prácticas específicas contrastadas.
Prácticas que han demostrado su efectividad en proyectos en diferentes

Prácticas contrastadas condiciones de entornos reales
Recomendaciones Prácticas opcionales, sugeridas por el modelo.
56
Modelos ágiles

Relación entre los componentes del modelo
Este diagrama es un ejemplo para mostrar la interconexión y relación entre los componentes de
Microsoft Solutions Framework
Principio Modelo o Concepto Práctica

Recomendac.
Fundamental Disciplina Clave Contrastada
Aprender de Uso de
Modelo de Disposición al Hitos de
las facilitadores
˜ ˜ ˜ ˜
procesos aprendizaje revisión
experiencias externos
Definir y
Permanecer Evaluación Creación de
Gestión de monitorizar
˜ ˜ ˜ ˜
ágil y esperar continua de una BD de
riesgos disparadores
el cambio riesgos riesgos
de riesgos
˜
Está relacionado
En 2005, el desarrollo del nuevo producto de Microsoft “Visual Studio 2005 Team System” ha
ganerado la evolución de MSF hacia la nueva versión 4.0 con dos líneas paralelas:
 Microsoft Solutions Framework (MSF) for Agile Software Development.
 Microsoft Solutions Framework (MSF) for CMMI Process Improvement.
57
Modelos ágiles
Modelos de propiedad Comercial: RUP
Rational Unified Process

Es un proceso de Ingeniería del Software que proporciona una visión disciplinada para la asignación
de tareas y responsabilidades en las organizaciones de desarrollo de software.
RUP es un “modelo-producto” desarrollado y mantenido por Racional Software, integrado en su
conjunto de herramientas de desarrollo, y distribuido por IBM.
RUP integra un conjunto de “buenas prácticas” para el desarrollo de software en un marco de
procesos válido para un rango amplio de tipos de proyectos y organizaciones.
RUP: Buenas Prácticas
Desarrollo iterativo.
Gestión de requisitos.
Uso de arquitecturas basadas en componentes.
Uso de técnicas de modelado visual.
Verificación continua de la calidad.
Gestión y control de cambios.
58
Modelos ágiles
Rational Unified Process: Visión estática

En su visión estática, el modelo RUP está compuesto por:
 Roles: analista de sistemas, diseñador, diseñador de pruebas, roles de gestión y roles de
administración.
 Actividades: RUP determina el trabajo de cada rol a través de actividades. Cada actividad
del proyecto debe tener un propósito claro, y se asigna a un rol específico. Las actividades
pueden tener duración de horas o de algunos días; y son elementos base de planificación y
progreso.
 Artefactos: Son los elementos de entrada y salida de las actividades. Son productos
tangibles del proyecto. Las cosas que el proyecto produce o usa para componer el producto
final (modelos, documentos, código, ejecutables…)
 Disciplinas: son “contenedores” empleados para organizar las actividades del proceso. RUP
comprende 6 disciplinas técnicas y 3 de soporte.
Técnicas: modelado del negocio, requisitos, análisis y diseño, implementación, pruebas y
desarrollo.
Soprte: gestión de proyecto, gestión de configuración y cambio, y entorno.
 Flujos de trabajo: son el “pegamento”de los roles, actividades, artefactos y disciplinas, y
constituyen la secuencia de actividades que producen resultados visibles.
59
Modelos ágiles
Rational Unified Process: Visión dinámica

En su visión dinámica, la visión de la estructura del ciclo de vida RUP se basa en un desarrollo
iterativo, jalonado por hitos para revisar el avance y planear la continuidad o los posibles cambios de
rumbo.
Cuatro son las fases que dividen el ciclo de vida de un proyecto RUP:
 1.- Inicio. Es la fase de la idea, de la visión inicial de producto, su alcance. El esbozo de una
arquitectura posible y las primeras estimaciones. Concluye con el “hito de objetivo”.
 2.- Elaboración. Comprende la planificación de las actividades y del equipo necesario. La
especificación de las necesidades y el diseño de la arquitectura. Termina con el “hito de
Arquitectura”.
 3.- Construcción. Desarrollo del producto hasta que se encuentra disponible para su
entrega a los usuarios. Termina con el “hito del inicio de la capacidad operativa”.
 4.- Transición. Traspaso del producto a los usuarios. Incluye: manufactura, envío,
formación, asistencia y el mantenimiento hasta lograr la satisfacción de los usuarios.
Termina con el “hito de entrega del producto”.
60
4.- Gestión de proyectos: formal y ágil
61
Gestión de proyectos
Cómo gestionar los proyectos de software
Referentes de la gestión formal de proyectos

Las principales referencias de la gestión formal de proyectos son las asociaciones:
 PMI (Project Management Institute)
 IPMA (International Project Management Association)
Y la metodología:
 PRINCE2 (Projects in Controlled Environments)
IPMA se constituyó en 1965, PMI lo hizo en 1969, y PRINCE2 se comenzó a desarrollar en 1989.
Forma inicial y evolución

PMI e IPMA son organizaciones que han ido desarrollando estándares, métodos y modelos de
certificación profesional (www.pmi.org – www.ipma.ch).
Siguiendo un camino inverso, PRINCE2 no nace como asociación, sino como metodología alrededor
de la cual se ha formado un grupo de desarrollo.
Gestión formal de proyectos
62
Referentes de la gestión formal de proyectos
Ámbito global de la gestión formal

PMI E IPMA defienden que la gestión de proyectos comprende un cuerpo de conocimiento que debe
ser profesionalizado, y que resulta válido y aplicable a los proyectos de cualquier industria:
construcción, química, aeroespacial, TI, etc.
Aunque en la actualidad también comparten esta visión, también en este caso el origen de PRINCE2
fue el contrario: su desarrollo inicial lo llevó a cabo la CCTA (Central Computer and
Telecommunications Agency) del Gobierno Británico, para que sirviera como estándar en los
proyectos de Tecnologías de la Información. Sin embargo, el ámbito de aplicación se fue ampliando
y en su revisión de 1996 se le dio cobertura global para los proyectos de todas las industrias.
63
Objeciones a la gestión formal de proyectos

Los modelos ágiles para el desarrollo de software plantean objeciones a la teoría de la gestión
formal de proyectos.
Características específicas del software
El software no resulta comparable a la materia prima de otras ingenierías.

El software no es físico, y los sistemas de soft, a diferencia de los artefactos físicos son muy
maleables. Por esta razón, resulta tendencioso comparar la construcción de un edificio, un avión, o
un dispositivo de hardware con un sistema de software.
A nadie se le ocurriría construir un proyecto de arquitectura con el método de prueba y error,
levantando las plantas del edificio para luego demolerlas, o ampliarlas si no son como desea el
cliente; o desarrollar una embarcación básica, para ir ampliando y modificando sus características, a
medida que por el uso las van descubriendo los clientes.
Sin embargo con el software esto es posible.
Los 12 principios del Manifiesto Ágil (v. agilidad y procesos) plantean principios que pueden resultar
viables para los proyectos de software de determinadas características, pero que se apartan de los
métodos formales de gestíón.
¿Es posible un marco único y universal para la gestión de proyectos?
64
Referentes de la gestión ágil de proyectos

Las principales referencias de la gestión ágil de proyectos son:
 Scrum
 Rational Unified Process (RUP)
 Microsoft Solutions Framework (MSF)
Características
Scrum es un modelo ágil no centrado en prácticas de programación (como XP p. ej.), sino en
prácticas de gestión. Por eso puede y suele combinarse Scrum junto con otro de prácticas técnicas.
RUP.
Rational Unified Process es un proceso iterativo para desarrollo de software creado por Rational
Software (IBM).
MSF es un marco de desarrollo que define procesos, principios, modelos, disciplinas, conceptos y
prácticas contrastadas por Microsoft.
No son modelos de procesos sino marcos de trabajo adaptables a las circunstancias de las
organizaciones de los proyectos.
Gestión ágil de proyectos
65
Fundamentos de la cultura ágil con problemas de encaje en

la gestión formal de proyectos
 Entrega temprana de software operativo.

 Trabajo con incertidumbre de requisitos, y apertura constante a cambios en los mismos.
 Entregas frecuentes de funcionalidades operativas.
 Preferencia de la comunicación verbal sobre otros medios.
 Infravaloración de métricas teóricas y formales, considerando como válida “el software que
funciona”.
 Auto-organización de equipos.
La gestión formal se asienta sobre la dirección del proyecto sobre un plan general con visibilidad y
ámbito de certidumbre hasta el final del proyecto.
La planificación de la gestión ágil es informal (algunos modelos llegan a prohibir el uso de diagramas
de Gannt), y solo cubre el ciclo de software que se está elaborando (generalmente 1 mes).
La gestión formal hace hincapié en la necesidad de conocer con el mayor detalle los requisitos desde
el principio para dar rigor al plan del proyecto.
La gestión ágil
66
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 que se 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 incorporación
incorporación de cambios en cualquier iteración del
desarrollo
desarrollo
“Hacerlo
“Hacerlo bien
bien aa la
la primera”.
primera”. “Refactorización”
“Refactorización” de código como modelo
modelo dede
Evitar
Evitar la
la re-codificación
re-codificación yy el
el re-trabajo
re-trabajo que
que supone
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
comunicación del proyecto equipo
equipo (incluidos cliente
cliente y usuarios) prefiriendo
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
67
Incompatibilidades
Gestión formal Gestión ágil
Desarrollo
Desarrollo de
de sistemas
sistemas innovadores,
innovadores, en entornos no Desarrollo
Desarrollo de
de sistemas
sistemas poco
poco innovadores
innovadores enen
conocidos
conocidos en los que no resulta posible conocer los entornos
entornos conocidos
conocidos en loslos 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 ciclos de 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ás eficientes
modelos
modelos formales de gestión
gestión de
de requisitos
requisitos peligra
peligra el
el modelos
modelos dede cascada.
cascada.
presupuesto
presupuesto yy la
la 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
dispersos (verificación
(verificación
en
en los
los que
que el
el tiempo
tiempo de
de salida
salida al
al mercado
mercado es
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 en
este
este tipo
tipo de
de proyectos.
proyectos. el
el proyecto, etc.). Sin un nivel formal de
comunicación
comunicación yy coordinación
coordinación se
se incrementan los
riesgos
riesgos del
del proyecto.
proyecto.
Contratos
Contratos centrados
centrados en
en “producto”
“producto” con
con
funcionalidades,
funcionalidades, costes y fecha de entrega
cerrados.
cerrados. Sin
Sin conocer
conocer con
con certeza
certeza los requisitos y
sin
sin hacer
hacer una
una 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.
68
Gestión de proyectos: principales conceptos y prácticas

Gestión de riesgos
GESTIÓN DE RIESGOS
 IDENTIFICACIÓN
 ANÁLISIS
 TRATAMIENTO
Plan de gestión
de riesgos
IEEE Std P1540-2001
69

Gestión de riesgos
Causas y consecuencias
consecuencia
CONSECUENCIA
consecuencia
Cau CONSECUENCIA
sa
CONSECUENCIA consecuencia
Desbordamiento
costes
Más horas
Incumplimiento
Requis
fechas
itos
crecie
ntes Más errores
peor calidad
Presión equipo
Desmotivación
menor eficiencia
70

Gestión de riesgos
La gestión de proyectos incorpora métodos sistemáticos de control de riesgos con
soluciones genéricas.
RIESGO TIPO SOLUCIÓN TIPO
Verificación
Verificación // validación
validación de
de
Desbordamiento
Desbordamiento de
de costes
costes requisitos
requisitos yy diseño
diseño
Verificación
Verificación // validación
validación
Errores
Errores en
en los
los productos
productos pruebas
pruebas enen el
el desarrollo
desarrollo
Procesos
Procesos de
de desarrollo
desarrollo Desarrollo
Desarrollo sobre
sobre procesos
procesos
incontrolados
incontrolados definidos
definidos
Gestión
Gestión de
de la
la configuración
configuración
Producto
Producto incontrolado
incontrolado SQA
SQA
Normalización
Normalización document.
document.
Problemas
Problemas de
de comunicación Comunicación,
Comunicación, resolución
resolución prob.
Si en un proyecto se adecuan las decisiones importantes, la planificación, los recursos, el

presupuesto y el esfuerzo para reducir las probabilidades y el impacto de los riesgos,
entonces se puede considerar que hay una GESTIÓN DE RIESGOS.
Cuando los riesgos se conocen y tratan con el “estándar” propio de la gestión de
proyectos resulta más propio decir que los riesgos se tratan a través de la GESTIÓN DEL
PROYECTO.
71
Gestión ágil de proyectos: Scrum
Roles: gallinas y 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
72

Modelos para Calidadimp

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Modelos para Calidadimp

Caricato da

Copyright:

Formati disponibili

1.

Visión simplificada de modelos formales y ágiles

Modelos genéricos Modelos para software

CMM (Capability Maturity Model)

 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

Organizaciones de software maduras / inmadudas

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

¿Por qué dos representaciones del modelo?

 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

Un modelo, dos representaciones

 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

Áreas de procesos en la representación escalonada

4 GESTIONADO Gestión cuantificada de proyectos

Áreas de procesos en la representación continua

CATEGORÍA ÁREAS DE PROCESO

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

Cómo usar el modelo

Cómo usar el modelo

Cómo usar el modelo

Mapa del documento

Notas Objetivos específicos

Mapa del documento

Mapa del documento

 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:

ISO/IEC 15504: Origen

 Independientemente de estructuras, filosofías de gestión, modelos de ciclo de vida de

Modelo de ref. Modelo de

El modelo tiene una arquitectura basada en dos dimensiones:

 Dimensión de capacidad de proceso

Agrupa los procesos en tres grupos correspondientes a los procesos del

Procesos primarios Procesos de soporte

CUS: Cliente - proveedor

La categoría CUS está formada por procesos que afectan directamente al

 CUS.1 Proceso de adquisición

La categoría ENG está formada por procesos que directamente especifican,

La categoría MAN está formada por procesos utilizados en la gestión de

Capacidad de proceso: rango de resultados que espera obtenerse

Niveles de capacidad y atributos

 Nivel 0: Proceso Incompleto