Cis 2 04

Compendio de Ingeniera del Software II
Rev. 0.03 Junio 2006

Juan Palacio Baeres
Tabla de contenido
Prlogo
Derechos
1.- Introduccin a la ingeniera del software
2.- Ciclo de vida
3.- Requisitos
4.- Anlisis y diseo
5.- Documentacin de usuario
6.- Verificacin y validacin
7.- Mantenimiento
8.- Gestin de la configuracin
Prlogo
Derechos
9.- Ingeniera de procesos del software
10.- Agilidad y procesos.
11.- Modelos formales: CMMI
12.- Modelos formales: ISO / IEC 15504
13.- Modelos giles
14.- Gestin de proyectos
14.1.- Gestin formal de proyectos
14.2.- Gestin gil de proyectos: Scrum
15.- Gestin de organizaciones de Software
Prlogo
CIS ofrece una visin prctica y sinptica de la Ingeniera del Software.
El formato de exposicin que emplea resulta adecuado para foros que requieren una exposicin
didctica de la Ingeniera del Software, o de alguna de sus reas (requisitos, CMMI, etc.) de
carcter ejecutivo o general, sin entrar en la densidad del libro especializado:
Formacin de Ingeniera del Software como asignatura complementaria en programas de

estudio tcnicos.
Formacin continua de gestores intermedios o directivos de empresas de software.
Etc.
Presentaciones de asesora y formacin profesional durante la implantacin de procesos de

mejora.
Este no es un trabajo completo, y por su carcter general no pretende cubrir todos los modelos,
tcnicas o lneas de trabajo de la Ingeniera del Software, sino las ms relevante y las que mayor
repercusin o uso tienen en la industria del desarrollo y mantenimiento de software.
Si resulta posible, en futuras revisiones se incluirn temas que por razones de tiempo y prioridad
an se han quedado fuera (DSDM, mtricas, estimaciones, etc.). Tambin en ellas se revisarn los
contenidos actuales.
Obra y derechos registrados en safecreative.net. Cdigo de obra: 0710040050155

Puede consultar la forma en la que puede emplear y distribuir este trabajo en:
http://www.safecreative.org/work/0710040050155
3
9.- Ingeniera de procesos del software
Ingeniera de procesos del software

Procesos: conceptos generales
Qu es un proceso?
Conjunto repetitivo ...
De actividades interrelacionadas ...
Que se realizan sistemticamente ...
Mediante las cuales ...
Un entrada se convierte en una salida o resultado, ... despus de aadirle valor

Ingeniera de procesos de software: definicin
Finalidad de los procesos de Ingeniera del Software
Facilitar el entendimiento y comunicacin

Dar soporte a la gestin y mejora de procesos
Proporcionar un soporte / gua automatizado
Los procesos deben ser adecuados a la organizacin y

tipo de proyectos
Naturaleza del trabajo (Mto. / Desarrollo)

Dominio de aplicacin
Estructura del proceso de entrega (incremental, evolutivo, cascada...)
Madurez de la organizacin

Ejemplo: estructura de procesos en ISO 12207
PROCESO
Un proceso est compuesto por actividades.
Una actividad est compuesta de tareas.
ACTIVIDAD 1
TAREA 1
TAREA X
ACTIVIDAD n
TAREA 1
La descomposicin del proceso en actividades y tareas se realiza sobre el concepto de ciclo de

mejora PDCA Plan Do Chek Act (Planificacin, ejecucin, medicin y mejora)
INICIO
PLAN
Tareas, agenda,
asignaciones
ACT
Problemas y acciones
correctivas
PROCESO
DO
Ejecicin de planes
y tareas
CHECK
Evaluacin y
medicin
FIN
7

Modelos de documentacin de procesos
Hay diferentes MODELOS para definir y documentar procesos:
Diferentes niveles de abstraccin - Diferentes tipos de definicin
Modelos de proceso del ciclo de vida del software

Las principales referencias son:
Modelos de marco del ciclo de vida del software

Los ms comunes son: evolutivo / incremental, cascada, prototipado, prototipado
evolutivo, espiral, software reutilizable.
o ISO/IEC 12207 IT Software Life Cycle Processes

o ISO/IEC 15504 IT Software Process Assesment

Notaciones
Lenguajes de modelado grfico que sirven para representar a los procesos.
Diagramas de flujo: Tcnica para especificar los detalles de un proceso en trminos de actividades, tareas,
entradas, salidas, condiciones.
IDEF0: Estndar para desarrollar representaciones grficas estructuradas de un sistema o entorno

empresarial. Permite la construccin de modelos que comprenden funciones del sistema (actividades,
acciones, operaciones, procesos), relaciones y datos.
UML...

Proceso de Ingeniera de Software
Niveles del proceso de Ingeniera del Software

El proceso de ingeniera del software puede examinarse en 2 niveles:
Actividades tcnicas y de gestin ejecutadas durante la adquisicin, desarrollo,

mantenimiento y retirada
Meta-nivel concerniente a la definicin, implementacin, medicin y mejora de los

procesos
10

Ingeniera de procesos de software
Modelos ms relevantes de ingeniera de procesos
PDCA
IDEALSM
Modelos genricos
Basados en ciclos de
mejora continua
ISO 15504, Parte 7
Tienen similitudes
ISO 9004:2000
11

PDCA
PLAN
DO
Identificar el problema
Analizar el problema
Desarrollar soluciones
Implementar una solucin
CHECK
ACT
Evaluar los resultados

Determinar los siguientes pasos
12

IDEAL
Fase Inicial
Fase de Diagnstico
Fase de establecimiento
Fase de accin
Fase de aprendizaje
13

ISO / IEC 15504
1.
Examine
needs
Organizations
needs
Quantified
results
Instituc.
gains
7. Sustain
gains
Confirmed
improvements
8. Monitor
perform.
Scope
2. Initiate
improv.
Preliminary
plan
ent
m
s
s
sse est
a
e
R
u
req
3.
Conduct
assess.
6. Confirm
improv.
Improvements
5.
Implement
improv.
Results
4. Plan
improv.
Action
plan
14

Patrones comunes
Medicin
Definicin
Establecer
infraestructura
Planificar
implementacin y
cambio de
procesos
Base
Experiencia
Evaluacin del
proceso
Anlisis cualitativo
Implementacin y
cambio
Implementacin y
cambio de
procesos
Medicin
Anlisis cualitativo
Implementacin y cambio
15

Ingeniera de procesos: Patrones comunes
DEFINICIN
MEDICIN
ANLISIS
IMPLEMENTACIN Y CAMBIO
16

Medicin
Obtener, analizar e interpretar informacin CUANTITATIVA para:
CARACTERIZAR
EVALUAR
PREDECIR
MEJORAR
Entender el proceso actual, entorno, etc.

Disponer de informacin de la situacin anterior al cambio
Determinar la consecucin de objetivos
Identificar fortalezas y debilidades del proceso
Entender las relaciones entre procesos y productos
Establecer objetivos alcanzables de calidad, costes y agendas
Identificar causas y oportunidades de mejora
Seguir el rendimiento de los cambios y compararlo con lneas base
17

Medicin
Se puede medir la calidad del proceso (en si mismo) o la calidad de sus salidas.
SALIDAS
PROCESO
(resultado)
CONTEXTO
18

Medicin
Qu medir
La forma de identificar qu medir y cmo hacerlo ms eficiente es basndose en los objetivos del
proceso (goal-oriented / goal driven)
1)
Empezar por especificar las necesidades de informacin
2)
Despus, identificar las medidas que satisfacen esas necesidades
Fiabilidad: Margen de error de la medicin

Validez: Capacidad de medir realmente lo que creemos que mide
19

Medicin
Paradigmas
ANALTICO/A
ANLISIS COMPARATIVO
(Benchmarking)
Evidencias cuantitativas
de la necesidad de mejoras
y del xito de iniciativas
de mejoras
Comparacin con
organizacin excelente en
un campo y documentar sus
practicas y herramientas
20

Medicin
El modelo ANALTICO consiste en:
ENTENDER
CONSOLIDAR
REVISAR
Ejemplos:
Estudios experimentales y de observacin

Simulacin de procesos
Clasificacin ortogonal de defectos
Control estadstico de procesos
21

Medicin
El modelo ANLISIS COMPARATIVO consiste en medir:
La madurez de una organizacin
o la capacidad de sus procesos
Los modelos de evaluacin de procesos recogen lo que se consideran best practices

SW-CMM y CMMI CBA IPI y SCAMPI
ISO 15504 ISO 15504, Part 8
ISO 9001
2 arquitecturas generales con distintas asunciones en cuanto al orden en el que medir los
procesos: continua y escalonada
22

Medicin orientada a objetivos GQM (Goal Question Metric)
OBJETIVO
Cada mtrica debe esta dirigida a cubrir / medir un

objetivo. La idea es que debemos tener buenas razones
para recoger datos.
REQUISITO
Cada objetivo debe contestarse con uno o varios

requisitos (preguntas). El requisito debe establecerse de
forma que la mtrica pueda responderlo claramente.
MTRICA
INDICADOR
El indicador debe ser una entidad cuantitativa que de

respuesta a un requisito especifico.
23

Resumen de los pasos de GQM
1. Establecer los objetivos / expectativas
de la coleccin de datos
Objetivos
negocio
2. Desarrollar una lista de

requisitos / criterios de inters
3. Establecer los indicadores
4. Disear los medios para recoger los datos
Qu tengo que
conseguir?
5. Recoger y validar los datos

6. Analizar los datos
Qu quiero
conocer?
Indicador
24

Ayuda para identificar requisitos: listar entidades y cuestiones relacionadas
con los objetivos.
Entidad 1
Entidad 2
...
Descartar segn sean comprensibles, cuantificables, conscientes,

coherentes.
25

Ejemplos de requisitos:
Entidad Financiera
Fabricantes de
coches
Establecimiento
hotelero
Fiabilidad
Sin averas
Rapidez
Sin cargos o abonos

improc.
Conformidad importe
p- importe c
...
Sin reparacin no
accidental antes de 2
aos
...
Recepcin de
mensajes < 15 min.
Chequeo inmediato
...
26

G1
G2
Q1
I1
Q2
I2
M1
Q3
I3
M2
I4
M3
27

28
10.- Agilidad y procesos
29
Agilidad y procesos
Manifiesto gil (2001)
Origen de los mtodos giles
En marzo de 2001, 17 crticos de estos modelos, convocados por Kent Beck, que acababa de definir
una nueva metodologa denominada Extreme Programming, se reunieron en Salt Lake City para
discutir sobre los modelos de desarrollo de software.
En la reunin se acu el trmino Mtodos giles para definir a aquellos que estaban surgiendo
como alternativa a las metodologas formales, (CMM-SW, PMI, SPICE) a las que consideraban
excesivamente pesadas y rgidas por su carcter normativo y fuerte dependencia de
planificaciones detalladas, previas al desarrollo.
Los integrantes de la reunin resumieron en cuatro postulados lo que ha quedado denominado
como Manifiesto gil, que compendia el espritu en el que se basan estos mtodos.
Aunque como se ver ms 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 ms ocupadas en descalificar a la contraria que en estudiarla y conocerla para
mejorar la propia.
30
Agilidad y procesos
Manifiesto gil (2001)
Estamos poniendo al descubierto mejores mtodos para desarrollar software, hacindolo y

ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
A los individuos y su interaccin
por encima
de los procesos y las herramientas
El software que funciona
por encima
de la documentacin exhaustiva
La colaboracin con el cliente
por encima
la negociacin contractual
La respuesta al cambio
por encima
seguimiento de un plan
Aunque hay valor en los elementos de la derecha, valoramos ms 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/
31
Agilidad y procesos
12 principios del manifiesto gil
1.- Nuestra principal prioridad es satisfacer al cliente a travs 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 travs del proyecto.
32
Agilidad y procesos
5.- Construccin de proyectos en torno a individuos motivados, dndoles la

oportunidad y el respaldo que necesitan y procurndoles confianza para que
realicen la tarea.
6.- La forma ms eficiente y efectiva de comunicar informacin de ida

y vuelta dentro de un equipo de desarrollo es mediante la
conversacin 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.
33
Agilidad y procesos
9.- La atencin continua a la excelencia tcnica 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 diseos emergen de equipos que se

auto-organizan.
12.- En intervalos regulares, el equipo reflexiona sobre la forma de ser ms

efectivo y ajusta su conducta en consecuencia.
34
Agilidad y procesos
Visin simplificada de modelos formales y giles
Tcnicas y mtodos
giles
Adaptaciones
para softw.
Modelos para software

1997
TickIT
1991
ISO 9000-3
Trillium
1959
1979
1987
MIL-Q 9858
BS 5750
ISO 9000
Modelos especficos
para software.
Modelos y estndares
formales de calidad
Modelos genricos
Bootstrap
1995
ISO 12207
1995
Proy. SPICE
1993
CMM-SW
TR 15504
2003-05
ISO 15504
Modelos
CMM
2001
CMMI
DSDM
SCRUM
CRYSTAL
XP
ASD
PP
ISD
AM
1995
2000
Manifiesto
gil
35
11.- Modelos formales: CMMI
36
Modelos formales: CMMI

CMM (Capability Maturity Model)
Deficiencias en las metodologas

proceso de software
Incapacidad para manejar el
En 1986, SEI (Software Engineering Institute): marco de trabajo

sobre madurez de procesos
En 1991, SEI desarroll Capability Maturity Model (CMM)
Conjunto de prcticas recomendadas en determinadas reas clave de

proceso
Mejora la capacidad del proceso de software
Gua en la seleccin de estrategias de mejora de proceso
Establecer la madurez de los procesos

Determina cuestiones crticas para la calidad y la mejora del proceso
37

Organizaciones de software maduras / inmadudas
Idea principal: distincin entre empresas maduras/inmaduras

En una organizacin inmadura:
-
Procesos de software: improvisados o no respetados (si existen)

Planificacin en funcin de los problemas
Presupuestos y planificacin incumplidos
Sin base objetiva para evaluar la calidad o para resolver problemas
Inexistencia o reduccin de las actividades de mejora de la calidad
En una organizacin madura:

-
Capacidad de gestin: desarrollo de software y procesos de mantenimiento

Proceso de software difundido al equipo y planificado
Procesos modificables: pruebas piloto controladas y anlisis de coste/beneficio
Roles y responsabilidades establecidos en el proyecto y la organizacin
Gestores: monitorizacin la calidad de los productos y de los procesos
Planificaciones y presupuestos realistas: rendimientos histricos
Proceso disciplinado en el que todos los participantes entienden su valor,
existiendo adems la infraestructura necesaria para soportar el proceso
38

Proyecto CMMI
DoD (Departamento de Defensa de los Estados Unidos), SEI (Software
Engineering Institute) y NDIA (National Defense Industrial Association).
Ms de 100 organizaciones involucradas
U.S. Army, Navy, Air Force

Federal Aviation Administration
National Security Agency
Software Engineering Institute
ADP, Inc.
AT&T Labs
BAE
Boeing
Computer Sciences Corporation
EER Systems
Ericsson Canada
Ernst and Young
General Dynamics
Harris Corporation
Honeywell
KPMG
Lockheed Martin
Motorola
Northrop Grumman
Pacific Bell
Q-Labs
Raytheon
Reuters
Rockwell Collins
SAIC
Software Productivity Consortium
Sverdrup Corporation
TeraQuest
Thomson CSF
TRW
39

Modelos CMMI
Modelo combinado
System Engineering/Software
Engineering
Aplicable:
Slo a proyectos de software

engineering
Slo a proyectos de system
engineering
Ambos
Continua o escalonada?
Ambas incluyen el mismo contenido y consiguen idnticos
objetivos
La representacin continua centra su actuacin en la
CAPACIDAD DE LOS PROCESOS
La representacin escalonada centra su actuacin en la
MADUREZ DE LA ORGANIZACIN
40

Por qu dos representaciones del modelo?
Heredado de los modelos de origen.
En el del equipo de desarrollo de CMMI haba defensores de de

cada una de las representaciones.
Seleccionar una nica representacin se planteaba como algo too

hard.
Compromiso: Inicialmente soportar dos representaciones del

modelo con contenidos equivalentes.
Software CMM--Escalonado
SECM--Continuo
IPD CMM--Hbrido
41
Un modelo, dos representaciones
Escalonado
Continuo
Capacidad
ML5
ML4
ML3
ML2
ML 1
PA
PA
PA
. . .para un rea de proceso

o un conjunto de reas de proceso
. . .para un conjunto de
reas de proceso establecido
42

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 organizacin y define su

potencial de calidad en la produccin.
ML5
ML4
ML3
ML2
ML 1
43

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 especficos del rea
2 Gestionado
Los procesos que adems de considerarse ejecutados son tambin planificados,

revisados y evaluados para comprobar que cumplen los requisitos
3 Definido
Los procesos que adems de considerarse gestionados se ajustan al conjunto de

procesos estndar conforme a las lneas directivas de la organizacin
4 Gestin cuantificada
Procesos definidos que son controlados utilizando tcnicas estadsticas u otras

tcnicas cuantitativas
5 Optimizado
Procesos gestionados cuantificadamente que son cambiados y adaptados para

conseguir objetivos relevantes de negocio
44

Dimensin de la capacidad
Los valores describen cmo de bien se realiza el proceso (nivel
de capacidad del proceso).
Capacidad
Proceso bien ejecutado y

mejorado continuamente
Proceso no ejecutado
Area
Proceso 1
Area
Proceso 2
Area
Proceso 3
Area
Proceso n
Procesos
45

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 medicin y control
5 Optimizado
Centralizacin en la mejora de los procesos
46

Dimensin de la madurez
Optimizado
5
Centrado en la mejora de
procesos
Gestionado
cuantitativamente
Proceso medido
y controlado
Definido
3
Proceso caracterizado
para la organizacin y
proactivo
Gestionado
2
Proceso caracterizado
para los proyectos y a
menudo reactivo
Inicial
1
Proceso imprevisible, poco

controlado y reactivo
47

reas de procesos
CMMI recoge prcticas para 22 reas de procesos

Las reas de procesos agrupan a las actividades necesarias para
la ejecucin de los proyectos de ingeniera de sistemas y de
software
El modelo en su representacin escalonada clasifica a las 22
reas de proceso en aquellas cuya gestin es necesaria para

lograr cada nivel de calidad
El modelo en su representacin continua las clasifica segn a la

categora que pertenecen: Gestin de proyectos, ingeniera,
soporte y gestin de procesos
48

reas de procesos en la representacin escalonada
NIVEL DE MADUREZ
5 OPTIMIZADO
4 GESTIONADO
CUANTITATIVAMENTE
REAS DE PROCESO
Innovacin y desarrollo
Gestin cuantificada de proyectos

Rendimiento de los procesos de la organizacin
Desarrollo de requisitos
Solucin tcnica
Verificacin
Validacin
3 DEFINIDO
Integracin de producto
Procesos orientados a la organizacin

Definicin de los procesos de la organizacin
Formacin
Gestin integrada de proyecto
Gestin de riesgos
Anlisis y resolucin de decisiones
Gestin de requisitos
Planificacin de proyecto
Monitorizacin y control de proyectos
2 GESTIONADO
Gestin y acuerdo con suministradores

Medicin y anlisis
Gestin de la calidad de procesos y productos
Gestin de la configuracin
1 INICIAL
49

reas de procesos en la representacin continua
CATEGORA
REAS DE PROCESO
Monitorizacin y control de proyecto
Gestin y acuerdo con proveedores
GESTIN DE PROYECTOS

Gestin de riesgos
Gestin cuantificada de proyecto
SOPORTE
Medicin y anlisis
Anlisis y resolucin de problemas
INGENIERA
Soluciones tcnicas
Verificacin
Validacin
Definicin de los procesos de la organizacin
GESTIN DE PROCESOS
Procesos orientados a la organizacin

Formacin
Rendimiento de los procesos de la organizacin
50

Cmo 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 genrico
Los objetivos genricos asociados a un nivel de capacidad establecen lo que una organizacin 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
ejecucin del rea de proceso
Objetivo especfico
Los objetivos especficos se aplican a una nica rea de proceso y localizan las particularidades que
describen que se debe implementar para satisfacer el propsito del rea de proceso
51

Cmo usar el modelo
Componentes esperados
Prctica genrica
Una practica genrica se aplica a cualquier rea de proceso porque puede mejorar el
funcionamiento y el control de cualquier proceso.
Prctica especfica
Una practica especfica es una actividad que se considera importante en la realizacin del objetivo
especifico al cual est asociado.
Las prcticas especficas describen las actividades esperadas para lograr la meta especfica de un
rea de proceso.
Componentes informativos
Propsito
Notas introductorias
Referencias
Las referencias son indicadores de otras reas de proceso relacionadas que pueden aportar
informacin adicional o ms detallada
Nombres
Tablas de relaciones prctica-objetivo
Prcticas
52

Cmo usar el modelo
Componentes informativos
Propsito
Notas introductorias
Referencias
Las referencias son indicadores de otras reas de proceso relacionadas que pueden aportar
informacin adicional o ms detallada
Nombres
Tablas de relaciones prctica-objetivo
Prcticas
Productos tpicos
Subprcticas
Una subpractica es una descripcin detallada que sirve como gua para la interpretacin de una
practica genrica o especifica
Ampliaciones de disciplina
Las ampliaciones contienen informacin relevante de una disciplina particular y relacionada con una
practica especifica.
Elaboraciones de prcticas genricas
Una elaboracin de una practica genrica es una gua de cmo la practica genrica debe aplicarse al
rea de proceso.
53

Mapa del documento
rea de proceso
Propsito
Notas
Objetivos especficos
Objetivos genricos
Referencias
54

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

Mapa del documento
Notas
Practicas genericas
Productos de
trabajo
Subpracticas
Elaboraciones
56

reas de proceso
CMMI SE/SW incluye 22 reas de proceso
Las reas de proceso son iguales en ambas representaciones del modelo
En la representacin continua, las reas de proceso se agrupan por categoras: Gestin de

proyectos, Ingeniera, Soporte y Gestin de procesos
Process areas by capability
En la representacin escalonada, las reas de proceso se agrupan por niveles de madurez (2

5)
Process areas by maturity level
57

reas de proceso
Gestin de proyecto
Las reas de procesos de gestin de proyectos cubren las actividades relacionadas con la
planificacin, monitorizacin y control del proyecto.
El modelo CMMI SE/SW incluye seis reas de proceso en gestin de proyectos:
Monitorizacin y control de proyecto
Gestin y acuerdos con proveedores
Gestin de riesgos
Gestin cuantificada de proyecto
58

reas de proceso
Gestin de proyecto: reas bsicas
PMC
Acciones
Correctivas
Que
controlar
Replanificar
Acciones
Correctivas
Estado, cuestiones, resultados

de evaluaciones de producto,
Medidas y anlisis
Que construir
Estado,
cuestiones,
resultados de
progreso y
revisiones de
hitos
PP
Que hacer
reas de proceso
Soporte e Ingeniera
Planes
SAM
Necesidades de medicin
Acuerdos
Proveedor
Proveedor
Requisitos de componente de producto

Cuestiones tcnicas
Revisiones y test de aceptacin
59

reas de proceso
Gestin de proyecto: planificacin de proyecto
Propsito: establecer y mantener planes que definan las actividades del proyecto
Establecer
Estimaciones
Datos
Planificacin
Desarrollar Plan
de Proyecto
Obtener
Compromisos
con el Plan
Planes de
Proyecto
PMC
60

reas de proceso
Gestin de proyecto: monitorizacin y control
Propsito: Proporcionar informacin sobre el progreso del proyecto que permita tomar acciones
correctivas cuando la ejecucin del proyecto se desva significativamente del plan.
Monitorizar Proyecto contra Planes

Monitorizar
Parmetros
Planificacin
Monitorizar
Riesgos
Monitorizar
Compromisos
Monitorizar
Implicacin
Stakeholder
Monitorizar
Gestin
Datos
Conducir
Revisiones
Conducir
Revisiones
de Progreso
Gestionar
Acciones Correctivas
Analizar
Cuestiones
Tomar
Acciones
correctivas
Gestionar
Acciones
correctivas
PP
Planes de Proyecto
61

reas de proceso
Gestin de proyecto: gestin y acuerdos con proveedores
Propsito: Gestionar la adquisicin de productos a proveedores segn un acuerdo formal existente.
Establecer Acuerdos con Proveedores

Determinar
Tipo
Adquisicin
Seleccionar
Proveedores
Establecer
Acuerdos
Lista de productos
Requisitos Proveedor
Producto
Satisfacer
Acuerdos
Proveedor
Revisar
Productos
COTS
Acuerdo Proveedor
Ejecutar
Acuerdos
Aceptar
Producto
Transicin
Productos
62

reas de proceso
Ingeniera
Las reas de proceso de ingeniera cubren las practicas de desarrollo y mantenimiento compartidas
por diferentes disciplinas como ingeniera de software e ingeniera de sistemas.
El modelo CMMI SE/SW incluye seis reas de proceso en ingeniera:
Soluciones tcnicas
Verificacin
Validacin
63

reas de proceso
Ingeniera: reas bsicas
REQM
Requisitos
Requisitos de producto &

Componente de producto
Soluciones
Alternativas
TS
RD
Componentes
Producto
PI
Producto
CLIENTE
Requisitos
Componentes de producto, productos del trabajo,

informes de verificacin y validacin
VER
VAL
Necesidades del cliente

64

reas de proceso
Ingeniera: gestin de requisitos
Propsito: 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.
Gestin de Requisitos
Entender
los
Requisitos
Obtener
compromisos
a Requisitos
Requisitos
Identificar
Inconsistencias
entre
Proyecto y
Requisitos
Mantener
Trazabilidad
Requisitos
Gestionar
Cambios
Requisitos
Matriz
Trazabilidad
65

reas de proceso
Ingeniera: desarrollo de requisitos
Propsito: Producir y analizar los requisitos del cliente, del producto y de los componentes de
producto.
Desarrollar
Requisitos
del Cliente
Desarrollar
Requisitos
del Producto
Requisitos
Cliente
Requisitos
Producto
Analizar y
Validar
Requisitos
Requisitos
Validados
66

reas de proceso
Ingeniera: solucin tcnica
Propsito: Desarrollar, disear e implementar soluciones a los requisitos.
Requisitos
Validados
Seleccionar
Soluciones
Producto-Comp.
Desarrollar
Diseo
Diseos alternativos
y Criterios de evaluacin
Implementar
Producto
Diseo detallado &

Documentacion
Producto
Entregado
67

reas de proceso
Ingeniera: integracin de producto
Propsito: Ensamblar el producto asegurando que funciona apropiadamente y entregar el producto.
DAR
Preparar Integracin
Producto
Plan
Integracin
Garantizar
Interfaces
Compatibles
Assemblies
Solucin
Tcnica
Subassemblies
Ensamblar
Comp. Producto y
Entregar Producto
68

reas de proceso
Ingeniera: verificacin
Propsito: Asegurar que los resultados del trabajo seleccionados cumplen los requisitos
especificados.
Preparar para
Verificacin
Ejecutar
Peer Reviews
Plan
Verificacin
Verificar Productos
Seleccionados
Acciones
Correctivas
69

reas de proceso
Ingeniera: validacin
Propsito: Demostrar que un producto o componente de producto satisface su uso previsto en el
entorno previsto.
- Requisitos Cliente
- Requisitos Producto
- Productos
- Validacin de Requisitos
Validar Producto o
Componentes Producto
Preparar para
Validacin
-Conformidad
-Deficiencias
- Plan Validacin Requisitos

- Plan Validacin Producto
- Procesos y necesidades de Soporte
70

reas de proceso
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:
Medicin y anlisis
Anlisis y resolucin de problemas
71

reas de proceso
Soporte: reas bsicas
Calidad y no
conformidades
Medidas,
anlisis
Todas las reas de proceso
MA
Informacin
necesaria
PPQA
Procesos y
resultados;
estndares y
procedimientos
Elementos de
configuracin;
peticiones de
cambio
Lneas base;
informes de auditoria
CM
72

reas de proceso
Soporte: gestin de la configuracin
Propsito: Establecer y mantener la integridad de todos los productos de trabajo, utilizando
identificacin de la configuracin, control de la configuracin, informes de estado de configuracin y
auditorias de la configuracin.
Sistema
Gestin
Configuracin
Establecer
Lneas
Base
Estado
BBDD
Peticiones
de cambio
Peticiones
de cambio
Establecer
Integridad
Resultados
Auditoria
Elementos
Accin
Seguir y controlar cambios

73

reas de proceso
Soporte: aseguramiento de la calidad de procesos y producto
Propsito: Proporcionar un entendimiento objetivo de los procesos y los productos del trabajo
asociado.
Evaluar objetivamente procesos y productos de trabajo
Productos
trabajo
Evaluacin
Objetiva
Procesos
Evaluacin
Objetiva
P. Trabajo
y Servicios
Informes y Registros
Proporcionar entendimiento objetivo
Comunicar
y Garantizar
Resolucin de
No Conformidades
Establecer
Registros
74

reas de proceso
Soporte: medicin y anlisis
Propsito: Desarrollar y mantener una capacidad para medir, utilizada para dar soporte a las
necesidades de informacin de la gerencia.
Ajustar actividades de medicin y anlisis
Objetivos Medicin
Personal
Medicin
Repositorio
Medicin
Procedimientos,
Herramientas
Indicadores Medicin
Proporcionar resultados de mediciones
75

reas de proceso
Gestin de procesos
Las reas de procesos de soporte cubren las actividades de definicin, planificacin, recursos,
desarrollo, implementacin, monitorizacin, control, evaluacin, medicin y mejora de procesos.
El modelo CMMI SE/SW incluye cinco reas de proceso en gestin de procesos:
Definicin de procesos
Enfoque de procesos a la organizacin
Formacin
Rendimiento de los procesos
76

reas de proceso
Gestin de procesos: reas bsicas
Necesidades
y objetivos
de procesos
Senior
Management
Formacin en
procesos
Objetivos
Negocio
OT
Necesidades
Formacin
Procesos
Estndares y
Propios
OPF
Recursos y
Coordinacin
Propsitos de mejora de
procesos; Participacin
en definir, evaluar, y
desarrollar procesos
OPD
Procesos
Estndares
y Propios
reas de proceso de
gestin de proyecto,
soporte e ingeniera
Informacin de mejora
(e.j., lessons learned, datos)
77
12.- Modelos formales: ISO/IEC 15504
78
Modelos formales: ISO/IEC 15504

ISO/IEC 15504: Origen
Proyecto SPICE
En enero de 1993 la comisin ISO/IEC JTC1 aprob un programa de trabajo
para el desarrollo de un modelo que fuera la base de un futuro estndar
internacional para la evaluacin 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
publicacin de su primer borrador, desde ISO fueron invitadas diferentes organizaciones para
aplicarlo y valorar sus resultados.
Proyecto -> Instruccin Tcnica -> Estndar

En 1998, pasada la fase de proyecto, y tras las primeras evaluaciones, el trabajo pas a la fase de
informe tcnico con la denominacin ISO/IEC TR 15504.
La instruccin tcnica consta de 9 apartados, recogidos en volmenes independientes, que se han
ido publicando como redaccin definitiva del estndar internacional ISO/IEC 15504 durante el
periodo 2003-2005.
mbito de aplicacin
Cualquier organizacin de software que quiera establecer y mejorar su capacidad en adquisicin,

suministro, desarrollo, operacin evolucin y soporte de software.
Independientemente de estructuras, filosofas de gestin, modelos de ciclo de vida de software,

tecnologas o metodologas de desarrollo.
79

Estructura
Conceptos
y gua de
introduccin
P1
P9
Vocabulario
P7
P8
Gua
para mejora
de procesos
P3
Realizacin
de
evaluacin
Modelo de ref.
para procesos
y capacidad
P2
P6
Guia para det.

capacidad de
proveedores
Gua de
evaluacin
Modelo de
evaluacin
y gua de indic.
Guia de
capacitacin de
evaluadores
P4
P5
80

Caractersticas
Marco para mtodos de evaluacin, no es un mtodo o modelo en s.

Comprende:
Evaluacin de procesos
Mejora de procesos
Determinacin 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:
Dimensin de proceso
Caracterizada por las declaraciones del propsito de un proceso, que son objetivos esenciales
mensurables de un proceso.
Dimensin de capacidad de proceso

Caracterizada por una serie de atributos de proceso, aplicables a cualquier proceso, que
representan caractersticas mensurables necesarias para gestionar un proceso y mejorar su
capacidad.
81

Caractersticas
Dimensin de proceso
Agrupa los procesos en tres grupos correspondientes a los procesos del ciclo de vida que contienen
cinco categoras de acuerdo al tipo de actividad.
Procesos de soporte
Procesos primarios
CUS: Cliente Proveedor
SUP: Soporte
ENG: Ingeniera
Procesos organizacionales
MAN: Gestin
ORG: Organizacin
82

Dimensin de proceso
CUS: Cliente - proveedor
La categora CUS est formada por procesos que afectan directamente al cliente, soportan el
desarrollo y la transicin del software al cliente y permiten la correcta operacin y uso del producto
y/o servicio de software.
CUS.1 Proceso de adquisicin

CUS.1.1 Proceso de preparacin de la adquisicin
CUS.1.2 Proceso de seleccin de proveedor
CUS.1.3 Procesos de seguimiento de proveedor
CUS.1.4 Proceso de aceptacin del cliente
CUS.2 Proceso de suministro
CUS.3 Proceso de obtencin de requisitos
CUS.4 Proceso de operacin
CUS.4.1 Proceso de uso operacional
CUS.4.2 Proceso de soporte al cliente
83

Dimensin de proceso
ENG: Ingeniera
La categora ENG est formada por procesos que directamente especifican, implementan o
mantienen el producto de software, su relacin con el sistema y documentacin.
ENG.1 Proceso de desarrollo

ENG.1.1 Proceso de anlisis y diseo de requisitos de sistema.
ENG.1.2 Proceso de anlisis de requisitos de software.
ENG.1.3 Procesos de diseo de software.
ENG.1.4 Proceso de construccin de software.
ENG.1.5 Proceso de integracin de software.
ENG.1.6 Proceso de prueba de software.
ENG.1.7 Proceso de integracin y prueba de sistema.
ENG.2 Proceso de mantenimiento de software
84

Dimensin de proceso
SUP: Soporte
La categora 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 documentacin

SUP.2 Proceso de gestin de configuracin
SUP.3 Proceso de aseguramiento de calidad
SUP.4 Proceso de verificacin
SUP.5 Proceso de validacin
SUP.6 Proceso de revisin conjunta
SUP.7 Proceso de auditora
85

Dimensin de proceso
MAN: Gestin
La categora MAN est formada por procesos utilizados en la gestin de cualquier tipo de proyecto o
proceso en el ciclo de vida del software.
MAN.1 Proceso de gestin

MAN.2 Proceso de gestin de proyecto
MAN.3 Gestin de calidad
MAN.4 Gestin de riesgos
86

Dimensin de proceso
ORG: Organizacin
La categora ORG est formada por procesos que establecen los objetivos de negocio de la
organizacin.
ORG.1 Proceso de alineacin organizacional.

ORG.2 Proceso de mejora
ORG.2.1 Proceso de definicin de proceso.

ORG.2.2 Proceso de evaluacin de proceso.
ORG.2.3 Proceso de mejora de proceso.
ORG.3 Proceso de gestin de RR.HH.

ORG.4 Proceso de infraestructura
ORG.5 Proceso de medicin
ORG.6 Proceso de reutilizacin
87

Dimensin de proceso
Componentes de proceso
Identificador
Identifica la categora del proceso y el n de secuencia en la categora. 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 (bsico, extendido y nuevo) y 2 de segundo nivel (componente,
componente extendido)
Propsito
Prrafo que establece el propsito del proceso indicando los objetivos globales de su ejecucin.
Salidas
Lista de resultados observables de la implementacin exitosa del proceso
Notas
88

Dimensin 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 optimizacin
...y un conjunto de atributos de procesos asociados al nivel de capacidad
89

Niveles de capacidad y atributos
Nivel 0: Proceso Incompleto

Nivel 1: Proceso Realizado
Nivel 2: Proceso Gestionado
PA 2.1 Gestin de realizacin
PA 2.2 Gestin productos

Nivel 3: Proceso Establecido
PA 3.1 Definicin de proceso
PA 3.2 Recursos de proceso

Nivel 4: Proceso Predecible
PA 4.1 Medicin
PA 4.2 Control de proceso

Nivel 5: Proceso en optimizacin
PA 5.1 Cambio de proceso
PA 5.2 Mejora continua
90

Medicin de atributos
Los atributos de un proceso se evalan con N (Not), P (Partially), L (Largely) y F (Fully), siendo:
No alcanzado (0% a 15%).

Escasa o ninguna evidencia de la consecucin del atributo.
Parcialmente alcanzado (16% a 50%).

Evidencia de un enfoque sistemtico y de la consecucindel atributo.
Algunos aspectos de la consecucin pueden ser impredecibles.
Ampliamente alcanzado (51% a 85%).

Evidencia de un enfoque sistemtico y de una consecucin significativa del atributo.
La realizacin del proceso puede variar en algunas reas.
Totalmente alcanzado (86% a 100%).

Evidencia de un enfoque completo y sistemtico y de la consecucin plena del atributo.
91
13.- Modelos giles
92
Modelos giles
Ubicacin en el panorama general de modelos y procesos
Tcnicas y mtodos
giles
Adaptaciones
para softw.
Modelos para software

1997
TickIT
1991
ISO 9000-3
Trillium
1959
1979
1987
MIL-Q 9858
BS 5750
ISO 9000
Modelos especficos
para software.
Modelos y estndares
de calidad
Modelos genricos
Bootstrap
1995
ISO 12207
1995
Proy. SPICE
1993
CMM-SW
TR 15504
2003-05
ISO 15504
Modelos
CMM
2001
CMMI
DSDM
SCRUM
CRYSTAL
XP
ASD
PP
ISD
AM
1995
2000
Manifiesto
gil
93
Modelos giles
DSDM: Dynamic Systems Development Method
Es la metodologa ms veterana de las auto-denominadas giles. Surgi en 1994 de los trabajos de
Jennifer Stapleton, la actual directora del DSDM Consortium.
DSDM es la metodologa gil ms prxima a los mtodos formales, de hecho la implantacin de un
modelo DSDM en una organizacin la lleva a alcanzar lo que CMM considerara 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 diseo la importancia que debera tener.
El tener procesos claramente definidos no es sinnimo de tener buenos procesos.
CMM plantea un foco excesivo en los procesos, olvidando la importancia que en nuestra industria
tiene el talento de las personas.
En comn con los mtodos giles, DSDM considera imprescindible una implicacin y una relacin
estrecha con el cliente durante el desarrollo, as como la necesidad de trabajar con mtodos de
desarrollo incremental y entregas evolutivas.
DSDM cubre los aspectos de gestin de proyectos, desarrollo de los sistemas, soporte y
mantenimiento y se autodefine como un marco de trabajo para desarrollo rpido ms que como un
mtodo especfico para el desarrollo de sistemas.
94
Modelos giles
eXtreme Programming (XP)
Este es el mtodo que ms popularidad ha alcanzado entre las metodologas giles, y posiblemente
sea tambin el ms 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 suposicin de que es posible desarrollar software de
gran calidad a pesar, o incluso como consecuencia del cambio continuo. Su principal asuncin es que
con un poco de planificacin, un poco de codificacin y unas pocas pruebas se puede decidir si se
est siguiendo un camino acertado o equivocado, evitando as tener que echar marcha atrs
demasiado tarde.
Valores que inspiran XP

SIMPLICIDAD
FEEDBACK
CORAJE
COMUNICACIN
95
Modelos giles
Comunicacin
XP pone en comunicacin 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 da a da, y es
posible ajustar la agenda y las funcionalidades de forma consecuente
Feedback rpido y continuo

Una metodologa basada en el desarrollo incremental de pequeas partes, con entregas y pruebas
frecuentes y continuas, proporciona un flujo de retro-informacin valioso para detectar los problemas
o desviaciones.
De esta forma fallos se localizan muy pronto.
La retro-informacin es la herramienta que permite reajustar la agenda y los planes.
La planificacin no puede evitar algunos errores, que slo se evidencian al desarrollar el

sistema.
96
Modelos giles
Simplicidad
La simplicidad consiste en desarrollar slo el sistema que realmente se necesita. Implica resolver en
cada momento slo 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 comunicacin y el feedback resulta ms fcil conocer
las necesidades reales
Coraje
El coraje implica saber tomar decisiones difciles. Reparar un error cuando se detecta. Mejorar el
cdigo siempre que tras el feedback y las sucesivas iteraciones se manifieste susceptible de mejora.
Tratar rpidamente con el cliente los desajustes de agendas para decidir qu partes y cundo se van
a entregar.
97
Modelos giles
Las 12 prcticas de XP
XP no es un modelo de procesos ni un marco de trabajo, sino un conjunto de 12 prcticas
que se complementan unas a otras y deben implementarse en un entorno de desarrollo
cuya cultura se base en los cuatro valores citados
PRCTICAS DE CODIFICACIN
1.- Simplicidad de cdigo y de diseo para producir software fcil de modificar.
2.- Reingeniera continua para lograr que el cdigo tenga un diseo ptimo.
3.- Desarrollar estndares de codificacin, para comunicar ideas con claridad a travs del cdigo.
4.- Desarrollar un vocabulario comn, para comunicar las ideas sobre el cdigo con claridad.
PRCTICAS DE DESARROLLO
1.- Adoptar un mtodo de desarrollo basado en las pruebas para asegurar que el cdigo se
comporta segn lo esperado.
2.- Programacin por parejas, para incrementar el conocimiento, la experiencia y las ideas.
3.- Asumir la propiedad colectiva del cdigo, para que todo el equipo sea responsable de l.
4.- Integracin continua, para reducir el impacto de la incorporacin de nuevas funcionalidades.
98
Modelos giles
Las 12 prcticas de XP
PRCTICAS DE NEGOCIO
1.- Integracin de un representante del cliente en el equipo, para encauzar las cuestiones de
negocio del sistema de forma directa, sin retrasos o prdidas por intermediacin.
2.- Adoptar el juego de la planificacin para centrar en la agenda el trabajo ms importante.
3.- Entregas regulares y frecuentes para satisfacer la inversin del cliente.
4.- Ritmo de trabajo sostenible, para terminar la jornada cansado pero no agotado.
99
Modelos giles
Scrum
No es propiamente un mtodo o metodologa de desarrollo, e implantarlo como tal resulta
insuficiente.
Scrum define mtodos de gestin y control para complementar la aplicacin de otros mtodos giles
como XP que, centrados en prcticas de tipo tcnico, 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 revisin?

Qu obstculos te impiden cumplir la meta?
Qu vas a hacer antes de la prxima reunin?
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 planificacin
de la siguiente iteracin, guiada por cliente.
100
Modelos giles
Scrum
101
Modelos giles
Otros mtodos giles
Familia de mtodos Crystal
La familia de metodologas Crystal ofrece diferentes mtodos para seleccionar el ms apropiado para
cada proyecto.
Crystal identifica con colores diferentes cada mtodo, y su eleccin debe ser consecuencia del
tamao y criticidad del proyecto, de forma que los de mayor tamao, o aquellos en los que la
presencia de errores o desbordamiento de agendas implique consecuencias graves, deben adoptar
metodologas ms pesadas.
Los mtodos Crystal no prescriben prcticas concretas
ASD (Adaptative Software Development)

Mtodo que como alternativa a los procedimientos formales, aborda el desarrollo de grandes
sistemas con el uso de tcnicas propias de las metodologas giles.
No se trata de una metodologa, sino de la implantacin de una cultura en la empresa, basada en la
adaptabilidad.
102
Modelos giles
Otros mtodos giles
PP (Pragmatic Programming)
Pragmatic Programming es la coleccin de 70 prcticas de programacin, comunes a otros mtodos
giles, cuya aplicacin resulta til para solucionar los problemas cotidianos
AM (Agile Modeling)
Agile Modeling es la presentacin de un nuevo enfoque para realizar el modelado de
sistemas,(diseo) y basado en los principios de los mtodos giles remarca la conveniencia de
reducir el volumen de la documentacin.
ISD (Internet Speed Development)

Es el ms reciente de los mtodos giles, surgido como respuesta para las situaciones que requieren
ciclos de desarrollo muy breves con entregas rpidas.
Se centra en el talento de las personas sobre los procesos.
ISD es un entorno de gestin 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 caractersticas que debe reunir el software, y se centra en las fases de
diseo e implementacin del sistema
103
Modelos giles
Modelos de propiedad Comercial: MSF
MSF es la metodologa empleada por Microsoft para el desarrollo de software.
Hasta su versin 3 (principios de 2005) MSF se defina como un marco de desarrollo flexible para
adaptarse a las necesidades de cada proyecto, en oposicin a lo que sera una metodologa
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 comunicacin abierta.

Trabajo en torno a una visin 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.
104
Modelos giles
Elementos que componen el modelo
Principios fundamentales
Modelos
Disciplinas
Conceptos clave
Prcticas contrastadas
Recomendaciones
Principios bsicos en los que se basa todo el modelo (los 8 de la pg. ant.)
Mapas mentales de organizacin. Hay 2: De equipo y de procesos
reas de trabajo en las que se usan mtodos determinados (Gestin de

proyecto, de riesgos y de la mejora del talento)
Ideas que dan soporte a los principios y disciplinas de MSF y se muestran
a travs de prcticas especficas contrastadas.
Prcticas que han demostrado su efectividad en proyectos en diferentes
condiciones de entornos reales
Prcticas opcionales, sugeridas por el modelo.
105
Modelos giles
Relacin entre los componentes del modelo
Este diagrama es un ejemplo para mostrar la interconexin y relacin entre los componentes de
Microsoft Solutions Framework
Principio
Modelo o
Concepto
Prctica
Fundamental
Disciplina
Clave
Contrastada
Aprender de
las
experiencias
Modelo de
procesos
Disposicin al
aprendizaje
Hitos de
revisin
Permanecer
gil y esperar
el cambio
Gestin de
riesgos
Evaluacin
continua de
riesgos
Definir y
monitorizar
disparadores
de riesgos
Recomendac.
Uso de
facilitadores
externos
Creacin de
una BD de
riesgos
Est relacionado
En 2005, el desarrollo del nuevo producto de Microsoft Visual Studio 2005 Team System ha
ganerado la evolucin de MSF hacia la nueva versin 4.0 con dos lneas paralelas:
Microsoft Solutions Framework (MSF) for Agile Software Development.

Microsoft Solutions Framework (MSF) for CMMI Process Improvement.
106
Modelos giles
Modelos de propiedad Comercial: RUP
Rational Unified Process
Es un proceso de Ingeniera del Software que proporciona una visin disciplinada para la asignacin
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 prcticas para el desarrollo de software en un marco de
procesos vlido para un rango amplio de tipos de proyectos y organizaciones.
RUP: Buenas Prcticas
Desarrollo iterativo.
Gestin de requisitos.
Uso de arquitecturas basadas en componentes.
Uso de tcnicas de modelado visual.
Verificacin continua de la calidad.
Gestin y control de cambios.
107
Modelos giles
Rational Unified Process: Visin esttica
En su visin esttica, el modelo RUP est compuesto por:
Roles: analista de sistemas, diseador, diseador de pruebas, roles de gestin y roles de

administracin.
Actividades: RUP determina el trabajo de cada rol a travs de actividades. Cada actividad
del proyecto debe tener un propsito claro, y se asigna a un rol especfico. Las actividades
pueden tener duracin de horas o de algunos das; y son elementos base de planificacin 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, cdigo, ejecutables)
Disciplinas: son contenedores empleados para organizar las actividades del proceso. RUP
comprende 6 disciplinas tcnicas y 3 de soporte.
Tcnicas: modelado del negocio, requisitos, anlisis y diseo, implementacin, pruebas y
desarrollo.
Soprte: gestin de proyecto, gestin de configuracin y cambio, y entorno.
Flujos de trabajo: son el pegamentode los roles, actividades, artefactos y disciplinas, y

constituyen la secuencia de actividades que producen resultados visibles.
108
Modelos giles
Rational Unified Process: Visin dinmica
En su visin dinmica, la visin 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 visin inicial de producto, su alcance. El esbozo de una
arquitectura posible y las primeras estimaciones. Concluye con el hito de objetivo.
2.- Elaboracin. Comprende la planificacin de las actividades y del equipo necesario. La

especificacin de las necesidades y el diseo de la arquitectura. Termina con el hito de
Arquitectura.
3.- Construccin. 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.- Transicin. Traspaso del producto a los usuarios. Incluye: manufactura, envo,
formacin, asistencia y el mantenimiento hasta lograr la satisfaccin de los usuarios.
Termina con el hito de entrega del producto.
109
14.- Gestin de proyectos: formal y gil
110
Gestin de proyectos
Cmo gestionar los proyectos de software
Referentes de la gestin formal de proyectos
Las principales referencias de la gestin formal de proyectos son las asociaciones:
PMI (Project Management Institute)
IPMA (International Project Management Association)
Y la metodologa:
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 evolucin

PMI e IPMA son organizaciones que han ido desarrollando estndares, mtodos y modelos de
certificacin profesional (www.pmi.org www.ipma.ch).
Siguiendo un camino inverso, PRINCE2 no nace como asociacin, sino como metodologa alrededor
de la cual se ha formado un grupo de desarrollo.
Gestin formal de proyectos
111
Gestin de proyectos
Referentes de la gestin formal de proyectos
mbito global de la gestin formal
PMI E IPMA defienden que la gestin de proyectos comprende un cuerpo de conocimiento que debe
ser profesionalizado, y que resulta vlido y aplicable a los proyectos de cualquier industria:
construccin, qumica, aeroespacial, TI, etc.
Aunque en la actualidad tambin comparten esta visin, tambin 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 Britnico, para que sirviera como estndar en los
proyectos de Tecnologas de la Informacin. Sin embargo, el mbito de aplicacin se fue ampliando
y en su revisin de 1996 se le dio cobertura global para los proyectos de todas las industrias.
112
Gestin de proyectos
Objeciones a la gestin formal de proyectos
Los modelos giles para el desarrollo de software plantean objeciones a la teora de la gestin
formal de proyectos.
Caractersticas especficas del software

El software no resulta comparable a la materia prima de otras ingenieras.
El software no es fsico, y los sistemas de soft, a diferencia de los artefactos fsicos son muy
maleables. Por esta razn, resulta tendencioso comparar la construccin de un edificio, un avin, o
un dispositivo de hardware con un sistema de software.
A nadie se le ocurrira construir un proyecto de arquitectura con el mtodo de prueba y error,
levantando las plantas del edificio para luego demolerlas, o ampliarlas si no son como desea el
cliente; o desarrollar una embarcacin bsica, para ir ampliando y modificando sus caractersticas, 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 caractersticas, pero que se apartan de los
mtodos formales de gestn.
Es posible un marco nico y universal para la gestin de proyectos?
113
Gestin de proyectos
Referentes de la gestin gil de proyectos
Las principales referencias de la gestin gil de proyectos son:
Scrum
Rational Unified Process (RUP)
Microsoft Solutions Framework (MSF)
Caractersticas
Scrum es un modelo gil no centrado en prcticas de programacin (como XP p. ej.), sino en
prcticas de gestin. Por eso puede y suele combinarse Scrum junto con otro de prcticas tcnicas.
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
prcticas contrastadas por Microsoft.
No son modelos de procesos sino marcos de trabajo adaptables a las circunstancias de las
organizaciones de los proyectos.
Gestin gil de proyectos
114
Gestin de proyectos
Fundamentos de la cultura gil con problemas de encaje en
la gestin 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 comunicacin verbal sobre otros medios.
Infravaloracin de mtricas tericas y formales, considerando como vlida el software que
funciona.
Auto-organizacin de equipos.
La gestin formal se asienta sobre la direccin del proyecto sobre un plan general con visibilidad y
mbito de certidumbre hasta el final del proyecto.
La planificacin de la gestin 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 gestin 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 gestin gil
115
Gestin de proyectos
Desavenencias
Gestin formal
Gestin gil
Trabajo y gestin guiada por un plan general del

proyecto que comprende todo su ciclo de
desarrollo.
La planificacin del trabajo slo comprende el ciclo

en el que se est trabajando (normalmente 30
das). Algunos modelos giles prohben el uso de
grficos de Gantt
Conocimiento detallado de los requisitos antes de

comenzar el diseo del proyecto
Descubrimiento progresivo de requisitos, e

incorporacin de cambios en cualquier iteracin del
desarrollo
Hacerlo bien a la primera.

Evitar la re-codificacin y el re-trabajo que supone
una prdida de eficiencia.
Refactorizacin de cdigo como modelo de

trabajo compatible con el punto anterior.
Comunicacin formal segn el plan de

comunicacin del proyecto
Comunicacin directa entre los integrantes del

equipo (incluidos cliente y usuarios) prefiriendo la
verbal directa.
Gestin de equipos y personas centralizada en el

gestor del proyecto
Equipos auto-gestionados.
116
Gestin de proyectos
Incompatibilidades
Gestin formal
Gestin gil
Desarrollo de sistemas innovadores, en entornos

no conocidos en los que no resulta posible conocer
los requisitos con detalle al empezar, y el grado de
inestabilidad de requisitos resulta elevado. Sin la
comunicacin y revisin prxima del cliente y con
modelos formales de gestin de requisitos peligra
el presupuesto y la calidad del proyecto.
Desarrollo de sistemas poco innovadores en

entornos conocidos en los que resulta posible
conocer con detalle los requisitos desde el
principio. La gestin gil conlleva ciclos de
prototipado evolutivo cuando resultaran ms
eficientes modelos de cascada.
Equipos pequeos en entornos y mercados giles

en los que el tiempo de salida al mercado es
importante. Los modelos formales implican
formalidades que aportan muy pocos beneficios a
este tipo de proyectos.
Equipos grandes, fsicamente dispersos

(verificacin independiente, varios representantes
de los intereses de cliente: sponsor, usuarios
departamentales, varios proveedores trabajando
en el proyecto, etc.). Sin un nivel formal de
comunicacin y coordinacin se incrementan los
riesgos del proyecto.
Contratos centrados en producto con
funcionalidades, costes y fecha de entrega
cerrados. Sin conocer con certeza los requisitos y
sin hacer una planificacin global sobre ellos no es
posible hacer ningn clculo fiable.
117
14.1.- Gestin formal de proyectos
118

Operaciones y proyectos
Las empresas y las organizaciones en general llevan a cabo su trabajo bajo la forma de proyectos o
de operaciones.
Caractersticas comunes a las operaciones y los proyectos
Son realizados por personas

Disponen de recursos limitados
Su ejecucin se controla y responde a una planificacin.
Diferencias entre operaciones y proyectos

Los proyectos son temporales y nicos, mientras que las operaciones realizan siempre los
mismos procesos de forma continua.
119

Proyectos
Caractersticas de los proyectos
Son realizados por personas
Disponen de recursos limitados
Su ejecucin se controla y responde a una planificacin.
Tienen un inicio y fin definidos
Tienen como finalidad producir un producto o servicio nico
Ciclo de vida planificado
Temporalidad
Cada proyecto tiene un inicio y fin definidos.
El fin se alcanza cuando se consiguen los
objetivos del proyecto por razones objetivas
se decide abortar su ejecucin.
Producto nico
Ciclo de vida planificado

Caracterstica derivada de la temporalidad y el
objetivo nico. El producto o servicio se lleva
a cabo de forma incremental siguiendo unos
pasos planificados que constituyen el ciclo de
vida del desarrollo.
La finalidad del proyecto es realizar algo que

no se piensa repetir de forma sistemtica.
120

reas de conocimiento de la gestin de proyectos
Gestin de la integracin del
proyecto
Gestin del mbito del

proyecto
Gestin de agenda
Desarrollo del plan de proyecto

Ejecucin del plan de proyecto
Control integrado del cambio
Inicio
Planificacin del mbito
Definicin del mbito
Verificacin del mbito
Control de cambio del mbito
Definicin de la actividad
Secuencia de la actividad
Estimacin de tiempos
Desarrollo de la agenda
Control de la agenda
Gestin de la calidad del

proyecto
Gestin de los recursos

humanos del proyecto
Plan de recursos
Estimacin de costes
Presupuesto
Control de costes
Plan de calidad
Aseguramiento de la calidad
Control de calidad
Plan de organizacin
Incorporacin de personas
Desarrollo del equipo
Gestin de las comunicaciones

del proyecto
Gestin de riesgos
delproyecto
Gestin de compras
Plan de comunicaciones
Distribucin de la informacin
Informes de eficiencia
Cierre administrativo
Plan de riesgos
Identificacin de riesgos
Anlisis cuantitativo de riesgos
Anlisis cualitativo de riesgos
Plan de exposicin de riesgos
Monitorizacin y control de ries.
Plan de necesidades
Plan de compras
Compras
Seleccin de proveedores
Contratacin administrativa
Cierre de contrato
Gestin de costes
Fuente: PMBOK
121

Relacin de la G. de proyectos con otras reas de gestin
Gestin de
proyectos
Gestin y
Negocio del
administracin
proyecto
El principal conocimiento que se necesita para gestionar proyectos es exclusivo de la gestin de

proyectos, pero para llevar a cabo la gestin debe complementarse con conocimientos que
pertenecen al rea de management en general y con conocimientos especficos del negocio al que
va a servir el proyecto.
122

Gestin de proyectos: principales conceptos y prcticas
WBS
Work Breakdown Structure: Estructura de las
tareas en las que se descompone el proyecto.
Planificando el proyecto: Tipos de dependencias entre tareas
FC (de Fin a Comienzo) la ms habitual
CC (de Comienzo a Comienzo)
FF (de Fin a Fin)
CF (de Comienzo a Fin) suele ser problemtica

123

Tipos de dependencias entre tareas
Diseo Web
Desarrollo Web
Anlisis
Integracin
Diseo Admin
Implantacin
Desarrollo Admin
124

Asignacin de recursos y personas a las tareas
Optimizacin
Conceptos clave para la optimizacin del proyecto
Paso adelante
Paso atrs
Ruta crtica
Reasignacin de recursos
125

Paso adelante
Estimar la fecha ms temprana para comenzar y terminar cada tarea
Comenzando por la fecha de inicio del proyecto
Estima la fecha de fin ms optimista
126

Paso atrs
Estimar cuales pueden ser las fechas mas retrasadas para el inicio y fin de cada tarea sin
causar retrasos en el proyecto.
Se puede estimar con la fecha de entrega calculada por paso adelante, o con la fecha de
entrega deseada
Al calcular con la fecha de entrega por paso adelante se debe obtener a la misma
fecha de inicio.
Al calcular con la fecha de entrega esperada se obtiene la fecha lmite para
comenzar el proyecto
127

Demora total
Diferencia entre las fechas calculadas con paso adelante y paso atrs para cada tarea
Retraso mximo para una tarea sin retrasar sin afectar a la fecha de entrega del proyecto
La demora total se comparte entre las tareas en una cadena. Si se emplea en una tarea ya no
queda disponible para otras.
128

Demora permisible
Tiempo que puede retrasarse una tarea sin afectar a la agenda del proyecto
Algunos programas como MS Project

pueden hacer los clculos de forma
automtica
129

Ruta crtica
Es la ruta ms larga en el plan del proyecto, y delimita la fecha de entrega ms temprana posible
Actividades crticas
Actividades que estn en la ruta crtica y que no tienen demora permisible. Sus retrasos afectan al proyecto
130

Optimizacin de agenda
1.- Dirigir el esfuerzo de trabajo sobre las actividades de la ruta crtica
2.- Revisar la asignacin de personas
131

3.- Modificar la asignacin
4.- Redistribuir a las personas
132

Nueva ruta crtica
Asignacin mas eficiente
133

Reduccin de la demora total
Recomendaciones
Duplicar la asignacin de personas no significa la mitad de tiempo

Menos tiempo de entrega no significa menor presupuesto
Cada tarea debe tener un resultado cuantificable para comprobar que se ha realizado
Usar el sentido comn
134

GESTIN DE RIESGOS
Gestin de riesgos
IDENTIFICACIN
ANLISIS
TRATAMIENTO
Plan de gestin
de riesgos
IEEE Std P1540-2001

135

Gestin de riesgos
Causas y consecuencias
consecuencia
CONSECUENCIA
Causa
consecuencia
CONSECUENCIA
CONSECUENCIA
Ms horas
consecuencia
Desbordamiento
costes
Incumplimiento
fechas
Requisitos
crecientes
Presin equipo
Ms errores
peor calidad
Desmotivacin
menor eficiencia
136

Gestin de riesgos
La gestin de proyectos incorpora mtodos sistemticos de control de riesgos con
soluciones genricas.
RIESGO TIPO
SOLUCIN TIPO
Desbordamiento de costes
Verificacin / validacin de
requisitos y diseo
Errores en los productos
Verificacin / validacin
pruebas en el desarrollo
Procesos de desarrollo
incontrolados
Desarrollo sobre procesos

definidos
Producto incontrolado
SQA
Problemas de comunicacin
Normalizacin document.
Comunicacin, resolucin prob.
Si en un proyecto se adecuan las decisiones importantes, la planificacin, los recursos, el

presupuesto y el esfuerzo para reducir las probabilidades y el impacto de los riesgos,
entonces se puede considerar que hay una GESTIN DE RIESGOS.
Cuando los riesgos se conocen y tratan con el estndar propio de la gestin de
proyectos resulta ms propio decir que los riesgos se tratan a travs de la GESTIN DEL
PROYECTO.
137

Gestin de riesgos: IDENTIFICACIN
Mtodo sistemtico y organizado para descubrir los riesgos
Pueden identificarse directa o indirectamente.
DIRECTA: Identificando los orgenes (causas) que pueden ser:
Programacin: agendas impuestas, excesivas restricciones contractuales,
riesgos polticos
Requisitos: inconsistencias, TBDs, crecientes
Tcnicos: requisitos de rendimiento, seguridad, plataforma tecnolgica
Calidad: deficiencias en las prcticas de desarrollo
Logsticos: mantenibilidad, operacin, disponibilidad (el impacto se produce
cuando el sistema est en uso.
Despliegue: integracin, instalacin, distribucin
INDIERECTA: Identificando el impacto y buscando las causas. Las reas de impacto

son:
Agenda
Coste
Calidad
Operacin
138

Riesgos de agenda
Tcnicas que ayudan a identificarlos son: CPM, PERT, Simulaciones de Montecarlo
RED DE ACTIVIDAD:
F
(2)
C
(3)
A
(1)
(1)
B
(6)
(1)
(1)
G
(5)
I
(2)
K
(1)
L
(1)
10
Letras = Actividades; Nmeros = hitos, (x) = duracin
139

Riesgos de costes
Los principales factores que influyen en los riesgos de costes son:
Incertidumbre en los requisito

Estimacin incorrecta de costes
Requisitos crecientes
Presin de agendas
Costes irrazonables
Riesgos de requisitos
Las principales causas de riesgo por los requisitos son:
Requisitos incorrectos
Requisitos incompletos
Requisitos inconsistentes
Requisitos de dificultad imprevista
Requisitos imposibles
Requisitos ambiguos
Volatilidad
140

Gestin de riesgos: ANLISIS
Examen de los riesgos para determinar sus dos caractersticas principales:
Probabilidad
Impacto
El anlisis de los riesgos es una tarea de ejecucin cclica que debe realizarse y revisarse
peridicamente de forma adecuada a las caractersticas del proyecto.
El resultado del anlisis se plasma en un registro de los riesgos con la identificacin de su
descripcin y caractersticas, con apoyo de herramientas para su consulta, revisin, priorizacin,
etc.
141

Gestin de riesgos: TRATAMIENTO
El tratamiento de los riesgos es el tercer paso del proceso de gestin de riesgos y comprende la
implementacin de mtodos y tcnicas para reducir el impacto o la probabilidad.
Las tcnicas se clasifican en 5 categoras en funcin de su finalidad:

1.2.3.4.5.-
Evitacin del riesgo.

Aceptacin o asuncin del riesgo.
Control del problema (prevencin).
Transferencia del riesgo.
Refinamiento del conocimiento.
142
14.2.- Gestin gil de proyectos

Scrum
143
Gestin gil de proyectos: Scrum

Introduccin
Scrum es una metodologa gil de desarrollo de proyectos que toma su nombre y

principios de los estudios realizados sobre nuevas prcticas de produccin por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80.
En 1996 se defini por primera vez un patrn para aplicar esos principios de
desarrollo en campos de scrum al software.
Esta fue la primera definicin de un patrn Scrum aplicado al software, diseada por
Jeff Sutherland y Ken Schwaber y presentada en OOPSLA 96
Esta presentacin describe esa primera definicin de

1996
144

La esencia de Scrum
Al iniciar cada iteracin, 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 iteracin.
Al final de la iteracin el equipo presenta el incremento

de funcionalidad a las partes implicadas en el proyecto.
El equipo revisa los requisitos, considera la tecnologa disponible, evala sus

conocimientos, y de forma colectiva determina cmo implementar la funcionalidad.
Roles
Scrum tiene una estructura muy simple. Todas las responsabilidades del proyecto se
reparten en 3 roles:
Propietario del producto

Equipo
Scrum Master
145

Scrum
Scrum es un mtodo gil de gestin de proyectos desarrollado por Ken Schwaber y Mike Beedle.
Se basa en los principios giles:
Colaboracin estrecha con el cliente.
Simplicidad. Supresin de artefactos innecesarios en la gestin del proyecto.
Predisposicin y respuesta al cambio

Prefiere el conocimiento tcito de las personas al explcito de los procesos
Desarrollo incremental con entregas funcionales frecuentes
Comunicacin verbal directa entre los implicados en el proyecto
Motivacin y responsabilidad de los equipos por la auto-gestin, auto-organizacin y
compromiso.
146

Roles
Propietario del producto
Representa a todos los interesados en el producto final.
Sus reas de responsabilidad son:
Financiacin del proyecto

Requisitos del sistema
Retorno de la inversin del proyecto
Lanzamiento del proyecto
Equipo
Responsable de transformar el Backlog de la iteracin en un incremento de la
funcionalidad del software
Auto-gestionado
Auto-organizado
Multi-funcional
Scrum Master
Responsable del proceso Scrum
Formacin y entrenamiento del proceso

Incorporacin de Scrum en la cultura de la empresa
Garanta de cumplimiento de roles y responsabilidad
147

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 gustara. Y cmo lo llamaramos?. La
gallina respondi: Huevos con beicon.
El cerdo se detuvo, hizo una pausa y contest: Pensndolo mejor,
creo que no voy a abrir un restaurante contigo. Yo estara
realmente comprometido, mientras que tu estaras slo implicada.
Scrum diferencia claramente entre estos

dos grupos para garantizar que quienes
tienen la responsabilidad tienen tambin
la autoridad necesaria para poder lograr
el xito, y que quienes no tienen la
responsabilidad no producen
interferencias innecesarias
COMPROMETIDOS EN EL PROYECTO
Dueo del producto
Equipo
Scrum Master
IMPLICADOS EN EL PROYECTO
Marketing
Comercial
Etc.
148

El flujo de Scrum
Sprint Backlog
Nueva funcionalidad
Product Backlog
seleccionado
Product Backlog
Requisitos priorizados
Visin:
ROI versiones
hitos
Fuente: Agile Project Management with Scrum
Ken Schwaber
149

El flujo de Scrum
150

Sprint
Es el periodo de tiempo durante el que se desarrolla un incremento de funcionalidad.
Constituye el ncleo de Scrum, que divide de esta forma el desarrollo de un proyecto
en un conjunto de pequeas carreras.
Duracin mxima: 30 das.

Durante el sprint no se puede modificar el trabajo que se ha acordado en el Backlog.
Slo es posible cambiar el curso de un sprint, abortndolo, y slo lo puede hacer el
Scrum Master si decide que no es viable por alguna de las razones siguientes:
La tecnologa acordada no funciona.
Las circunstancias del negocio han cambiado.
El equipo ha tenido interferencias.
151

Artefactos
Product Backlog
Listado con los requisitos del sistema
Es responsabilidad del dueo del producto
Contenido
Priorizacin
Disponibilidad
Nunca llega a ser una lista completa y definitiva
El empleado para planificar el proyecto es slo una estimacin inicial de requisitos
Es un documento dinmico que incorpora constantemente las necesidades del sistema
Se mantiene durante todo el ciclo de vida (hasta la retirada del sistema).
152

Artefactos
Nuevo formulario para peticiones de clientes
2 0.2 2,4
2,4
Configuracin de respuestas automticas
3 0.2 3,6
3,6
Envo automtico de respuestas
1 0.2 1,2
1,2
Consulta para los clientes de peticiones enviadas
1 0.2 1,2
1,2
Modificacin del cliente de sus peticiones enviadas
2 0.2 2,4
2,4
Acceso a peticiones slo para clientes del portal jurdico
5 0.2
Consulta de peticiones por parte del staff
1 0.2 1,2
1,2
18
18
Product Backlog
ID
Complejidad
Estim. ajustada
Estimacin inicial
Product Backlog
Trabajo pendiente
Sprint
Elemento
SPRINT 1
15
Insercin de comentarios y reasignacin a peticiones (staff)
2 0.2 1,2
1,2
1,2
Consultas por clientes, fechas y temas
3 0,2 3,6
3,6
3,6
10
[Contina].
153

Artefactos
Sprint 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 duracin comprendida entre las 4 y las 16
horas de trabajo.
Las de mayor duracin deben intentar descomponerse en sub-tareas de ese rango de tiempo.
154

Artefactos
Grfica de progreso
155

Comunicacin
Reunin diaria
Revisin del sprint
Reunin retrospectiva
La forma ms eficiente y efectiva de comunicar informacin de ida y vuelta dentro de

un equipo de desarrollo es mediante la conversacin cara a cara.
Manifiesto gil
156

Comunicacin
Reunin diaria
Reunin del equipo con duracin mxima de 15 minutos.
Todos los das en el mismo sitio y a la misma hora.
Se recomienda que sea la primera actividad del da.

Deben acudir todos los miembros del equipo.
Moderada por el Scrum Master, que pregunta a todos los asistentes
Cul ha sido el trabajo realizado desde la ltima revisin diaria?
Cul 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 guin.

Slo 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 inters para otros, o necesita ayuda de otros,
estos se renen al terminar la revisin diaria.
Las gallinas no pueden intervenir ni distraer, y el Scrum Master puede limitar el nmero
de gallinas asistentes si lo considera oportuno.
Qu trabajo has realizado desde la ltima reunin?
Qu tienes previsto para hoy?
Qu necesitas?
157

Comunicacin
Revisin del sprint
Reunin del equipo, Scrum Master, propietario del producto con todas las personas implicadas en
el proyecto (gallinas).
Duracin mxima: 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 reunin, los miembros del equipo muestran las nuevas funcionalidades.
Al final de la reunin 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.
158

Comunicacin
Reunin 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 podran 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 prximo Sprint

deben introducirse en el Backlog como elementos no funcionales.
159
15.- Gestin de organizaciones de Software
160
Gestin de organizaciones de software

Retos en organizaciones de software
Retos de negocio
Mercado
Definicin de productos / servicios
Competencia
Financiacin
Estrategia
Etc.
Retos del software
Incumplimiento de fechas
Modificaciones de requisitos
Costes desbordados
Presin en el desarrollo
Funcionalidades inadecuadas
Etc.
El software es as?
161

Software, reto o ventaja?
Amplitud de mercado
Economa de escala en su produccin
Distribucin
Maleabilidad y desarrollo incremental
Todas las empresas quieren producir ms rpido, 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
Segn 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.
162

Madurez de la organizacin y capacidad de sus procesos
El xito o fracaso de las organizaciones que trabajan sin metodologas depende del conocimiento
tcito de su personal, pero teniendo en cuenta que se trata del conocimiento que cada uno traa
ya de la calle, o del que adquiere motu proprio, porque estamos hablando de "ninguna
metodologa", lo que implica que como mucho los procesos de formacin 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 sern tan buenos como ellos los sepan hacer. El cumplimiento de agendas
depender de su capacidad de previsin y organizacin. Pero no hay que engaarse; en este caso
no se trata de empresas que saben hacer software, sino de personas que saben hacer software.
Los procesos o la normalizacin en los mtodos 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
163
Gestin de organizaciones de Software

Caractersticas de los 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 slo un equipo consigue resultados

homogneos en todos los proyectos, sino que los obtienen todos los equipos.
Mejora continua. Al aplicar meta-procesos que trabajan sobre los propios procesos de
produccin, midiendo y analizando los resultados se obtienen los criterios de gestin 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 organizacin: la clave para
hacer las cosas bien, con eficiencia y de forma homognea.
164

Pero no slo son procesos
PERSONAS
PROCESOS
TECNOLOGA
165

Pero no slo son procesos
Los procesos marcan pautas para realizar el trabajo, pero sin las personas y las herramientas
(tecnologa) necesarias, lo que se puede producir con ellos es ms bien poco.
Las nicas combinaciones vlidas para formar sistemas capaces de producir resultados son:
Personas + tecnologa
Produccin heroica
Personas + procesos + tecnologa
Produccin basada en procesos
La realidad de los procesos es cierta, pero en el tringulo personas - procesos - tecnologa cada
elemento acta con un peso especfico, diferente en funcin del tipo de produccin, e incluso de
las caractersticas de personalidad de cada empresa.
Cada sector y cada empresa, ms que importar una metodologa estndar 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 produccin para componer el diseo de un
sistema de produccin a su medida.
La talla nica no existe, ni para modelos de procesos ni para modelos de gestin
166

Personalidad de la organizacin
Capital
Procesos
Tecnologa
Humano
Modelo de
produccin
Personas
Artesana
Ubicacin del
conocimiento - valor
Factores del
sistema de produccin
Estructural
Produccin heroica
Produccin industrial
Conocimiento
explcito
Conocimiento
tcito
167

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, vehculos, 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 fabricacin de productos el componente
estructural sea ms crtico que para las dedicadas a los servicios, en las que el elemento humano
tiene ms relevancia.
Pero este no es un principio universal, y dentro de la misma industria o del mismo sector, la
estrategia y la tctica de cada empresa tambin influyen en los niveles de relevancia que van a
tener el capital humano y el estructural.
168

Procesos
Valor aportado
en la produccin
Tecnologa
Personas
Valor que se
podra aportar
Conseguir que el sistema de procesos, tecnologa y

personas formen una ventaja competitiva frente a la
competencia, y no un reto ms del negocio, no es fcil, ni
puede importarse con la implantacin prt- porter de un
modelo estndar.
Como refleja la figura, la clave del xito radica en

conseguir que cada factor pueda aportar el mayor valor
hasta el lmite de su mejor relacin eficiencia / calidad.
En esta tarea nunca est dicha la ltima palabra, y la labor
de innovacin constante en procesos y tecnologa puede ir
ampliando los lmites de valor a un factor para conseguir
un nuevo equilibrio con mejores parmetros de eficiencia y
calidad en el sistema.
La obsesin por la excelencia mal entendida, lleva a muchos gestores a centrar sus esfuerzos en la
incorporacin de modelos o tcnicas, bien de procesos, bien de recursos humanos o de innovacin
tecnolgica; o de todos a la vez sin los criterios adecuados.
169

Gestin especfica y sistmica
El mito de la talla nica
Las organizaciones
El software
170

Gestin sistmica
Para conseguir eficiencia en su estrategia de produccin esta deber ser consecuente y estar
alineada con:
La visin: Qu quiere llegar a ser la organizacin y cul 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:
Caractersticas de los proyectos de software gestionados.

Visin de la organizacin.
Cultura de la organizacin.
Diseo y gestin del equilibrio productivo personas-procesos-tecnologa.
171

Gestin sistmica
Caractersticas de los proyectos de software
Organizativas
El concepto sistema de software es muy amplio, y tan sistema de software es el integrado
en un telfono celular, como el desarrollado en un proyecto Open Source por iniciativa del
propio grupo de desarrolladores; o el diseado para asistir el pilotaje de un avin
comercial
Tamao
El tamao tambin 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
aos
Contractuales
Las caractersticas del proyecto quiz la funcionalidad alcanzada en cada versin, as como la
precisin 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 dao que pueden producir los fallos del sistema, tambin
determina el rigor de los procesos que deben aplicarse en su desarrollo
172

Gestin sistmica
Visin, misin y estrategia de la organizacin
Tiene la organizacin una visin definida, compartida y trasladada a toda la

organizacin?
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 innovacin y vanguardia tecnolgica en su misin?
Mantienen operativos otros sistemas ya desarrollados?
Y la seguridad y fiabilidad del software que desarrollo.

Los desarrollos son para clientes finales externos, clientes internos de la organizacin,
subsistemas para la integracin en sistemas mayores de otras organizaciones?
Programan sistemas poco innovadores sobre plataformas contrastadas en negocios y
entornos conocidos.
Apuestas por la innovacin, implementacin sobre dispositivos nuevos, o disean

soluciones para entornos novedosos?
173

Gestin sistmica
Cultura
Es una organizacin con niveles jerrquicos y funciones claramente definidas?

Cules son los niveles de confianza, delegacin, empowerment y responsabilidad?
Clima laboral, motivacin?
Equilibrio personas-procesos-tecnologa
Cul es la estrategia productiva?
Qu porcentaje del conocimiento necesario para la ejecucin de los proyectos est

garantizado en los procesos, y cunto en las personas?
Son coherentes las polticas o procesos deformacin, contratacin, planes de carrera,

modelos de procesos, calidad y mejora?.
Tecnologa empleada en el desarrollo: equipos, red, sistemas de pruebas, plataformas

operativas, herramientas CAD
174

Gestin sistmica
Estrategia de gestin
Para disear y gestionar entornos de produccin eficientes se debe trabajar con
pensamiento sistmico, comprendiendo que todos los factores implicados en la
produccin de software componen un sistema interrelacionado, imbricado y alineado con
la misin de la organizacin
Evitar la gestin lineal

Gestin lineal o a-sistmica, consiste en aplicar soluciones sintomticas para cada
situacin.
La gestin lineal, carece de la perspectiva necesaria, y responde de forma azuzada a la
presin del da a da.
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 terminarn por empeorar la situacin.
La presin del da a da 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.
175

Eficiencia
La eficiencia es el resultado de la idoneidad y equilibrio de todos los
componentes de la produccin
(modelos de procesos, cultura de empresa, gestin de recursos humanos, plataforma de
programacin)
Claves para realizar una gestin eficiente
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, composicin actual, composicin deseable
Conocimiento de nuestra industria

Situacin de tecnologas, plataformas, modelos de produccin y calidad, etc.
Gestin sistmica
Conducir la gestin desde la visin de la organizacin
Revisin y adaptacin
El mercado, el entorno tecnolgico y la misma base de conocimiento de nuestra
industria estn en continua evolucin. Es necesario vigilar el entorno e innovar.
176
Juan Palacio
jpalacio@navegapolis.net
http://www.navegapolis.net
Obra y derechos registrados en safecreative.net. Cdigo de obra: 0710040050155

Puede consultar la forma en la que puede emplear y distribuir este trabajo en:
http://www.safecreative.org/work/0710040050155
177

Cis 2 04

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cis 2 04

Uploaded by

Copyright:

Available Formats

Compendio de Ingeniera del Software II

Rev. 0.03 Junio 2006

Formacin de Ingeniera del Software como asignatura complementaria en programas de

Formacin continua de gestores intermedios o directivos de empresas de software.

Presentaciones de asesora y formacin profesional durante la implantacin de procesos de

Obra y derechos registrados en safecreative.net. Cdigo de obra: 0710040050155

9.- Ingeniera de procesos del software

Ingeniera de procesos del software

Conjunto repetitivo ...

De actividades interrelacionadas ...

Que se realizan sistemticamente ...

Mediante las cuales ...

Un entrada se convierte en una salida o resultado, ... despus de aadirle valor

Ingeniera de procesos del software

Finalidad de los procesos de Ingeniera del Software

Facilitar el entendimiento y comunicacin

Los procesos deben ser adecuados a la organizacin y

Naturaleza del trabajo (Mto. / Desarrollo)

Ingeniera de procesos del software

Un proceso est compuesto por actividades.

Una actividad est compuesta de tareas.

La descomposicin del proceso en actividades y tareas se realiza sobre el concepto de ciclo de

Ingeniera de procesos del software

Diferentes niveles de abstraccin - Diferentes tipos de definicin

Modelos de proceso del ciclo de vida del software

Modelos de marco del ciclo de vida del software

o ISO/IEC 12207 IT Software Life Cycle Processes

Ingeniera de procesos del software

IDEF0: Estndar para desarrollar representaciones grficas estructuradas de un sistema o entorno

Ingeniera de procesos del software

Niveles del proceso de Ingeniera del Software

Actividades tcnicas y de gestin ejecutadas durante la adquisicin, desarrollo,

Meta-nivel concerniente a la definicin, implementacin, medicin y mejora de los

Ingeniera de procesos del software

Ingeniera de procesos del software

Modelos ms relevantes de ingeniera de procesos

ISO 15504, Parte 7

Ingeniera de procesos del software

Evaluar los resultados

Ingeniera de procesos del software

Ingeniera de procesos del software

Ingeniera de procesos del software

Ingeniera de procesos del software

Ingeniera de procesos del software

Entender el proceso actual, entorno, etc.

Ingeniera de procesos del software

Ingeniera de procesos del software

Empezar por especificar las necesidades de informacin

Despus, identificar las medidas que satisfacen esas necesidades

Fiabilidad: Margen de error de la medicin

Ingeniera de procesos del software

Ingeniera de procesos del software

Estudios experimentales y de observacin

Ingeniera de procesos del software

Los modelos de evaluacin de procesos recogen lo que se consideran best practices

Ingeniera de procesos del software

Cada mtrica debe esta dirigida a cubrir / medir un

Cada objetivo debe contestarse con uno o varios

El indicador debe ser una entidad cuantitativa que de

Ingeniera de procesos del software

2. Desarrollar una lista de

5. Recoger y validar los datos

Ingeniera de procesos del software