Documente Academic
Documente Profesional
Documente Cultură
Tabla de contenido
Prlogo
Verificacin y validacin
Mantenimiento
Gestin de la configuracin
Agilidad
Conocimiento
Sntesis entre procesos y agilidad
Scrum: el marco
Scrum: Mtricas
Scrum: prcticas
Kanban
Gestin en organizaciones giles
Prlogo
Este Compendio de Ingeniera del Software recopila apuntes preparados por el autor para
formacin, que resumen aspectos pragmticos de Ingeniera del Software.
Se comparten con una licencia abierta1 para su uso en autoformacin, o en foros que requieran la
exposicin de alguna de las reas de la Ingeniera del Software que cubren, con un enfoque
ejecutivo o general, sin la densidad propia del texto acadmico:
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 pragmticas para la industria
del software.
Si resulta posible, en futuras versiones, adems de la revisin de este contenido, se incluirn temas
que por razones de tiempo y prioridad se quedan fuera.
Juan Palacio
(1) Para consultar los usos autorizados de este trabajo o contactar con el autor:
http://www.safecreative.org/work/1401289956290
Introduccin a la
Ingeniera del Software
1.0
1952
1965
1950
1960
1970
Crisis
del
Software
1980
1990
1990
2000
En 1968 los programadores se debatan entre el uso de la sentencia GoTo, y la nueva idea
de programacin estructurada; ese era el caldo de cultivo en el que Edsger Dijkstra escribi
su famosa carta GoTo Statement Considered Harmful en 1968.
La primera publicacin sobre programacin estructurada no vio la luz hasta 1974, publicada
por Larry Constantine, Glenford Myers y Wayne Stevens.
El primer libro sobre mtrica de software fue publicado en 1977 por Tom Gilb.
C. Bhm y G. Jacopini publicaron en 1966 el documento que creaba una fundacin para la
eliminacin de GoTo y la creacin de la programacin estructurada.
INGENIERA DE PROCESOS
(Produccin basada en procesos / mejora continua del proceso)
GESTIN DE PROYECTOS
10
1980
11
1986
12
1990
13
2000
14
2005
15
2010
2000
1998
1995
1994
24%
Problemtico
44%
19%
32%
53%
23%
29%
49%
28%
40%
31%
xito
28%
46%
33%
53%
26%
27%
16%
Fuente: Standish Group Survey,
16
2000
1998
1995
1994
24%
Problemtico
44%
19%
32%
53%
23%
29%
49%
28%
40%
31%
xito
28%
46%
33%
53%
26%
27%
16%
Fuente: Standish Group Survey,
17
Otras definiciones
Disciplina para producir software de calidad desarrollado sobre las agendas y
costes previstos y satisfaciendo los requisitos.
S. Schach 1990, Software Engineering
18
19
De las mejores prcticas, extraer modelos de cmo ejecutar esos procesos para
evitar los problemas de la crisis del software
20
21
ISO
Organizacin Internacional para la Estandarizacin. Fundada en 1947
Son miembros 87 pases.
En 1987 la Organizacin Internacional para la Estandarizacin (ISO) y la Comisin
Internacional Electrotcnica (IEC), establecieron un Comit Internacional (JTC1) para las
Tecnologas de la Informacin. La misin del JTC1 es la estandarizacin en el campo de
campo de los sistemas de tecnologas de la informacin, incluyendo microprocesadores y
equipos.
Los estndares o instrucciones tcnicas ms importantes para la Ingeniera del Software:
SEI
ISO/IEC 12207
ISO/IEC TR 15504
IEEE
IEEE
IEEE
IEEE
IEEE
23
Std.
Std.
Std.
Std.
Std.
De las mejores prcticas, extraer modelos de cmo ejecutar esos procesos para
evitar los problemas de la crisis del software
CMM / CMMI
ISO/IEC TR 15504
24
25
1 Software, Engineering Coordinating Comitee, Comisin creada por IEEE Computer Society y ACM (Association for Computer Machinery) para definir
el cuerpo de la Ingeniera del Software
Requisitos
Diseo
Construccin
Pruebas
Mantenimiento
Gestin de la configuracin
Gestin
Procesos
Herramientas y mtodos
Calidad
Es importante resaltar que estas reas no incluyen aspectos importantes de las tecnologas de la
informacin, tales como lenguajes especficos de programacin, bases de datos relacionales o redes
o tecnologa de redes y comunicaciones.
Esta es una consecuencia de la distincin que entre esencia y accidente se establece desde un
enfoque de ingeniera.
26
Por supuesto que un Ingeniero de Software debe conocer las tcnicas de cada momento, pero la
definicin de procesos y metodologa de trabajo es la esencia de la profesin. As por ejemplo, el
rea de conocimiento de requisitos, s que puede considerarse como esencia de la profesin. Los
problemas que pueden derivarse en un proyecto por una mala obtencin o gestin de los requisitos
son indistintos del hardware o lenguaje de programacin empleado. Eran los mismos hace dos
dcadas que ahora, y todo nos hace suponer que seguirn siendo idnticos dentro de otros cuatro
lustros.
27
5.1 Adquisicin
6.1 Documentacin
5.2 Suministro
5.3
Operacin
6.4 Verificacin
6.5 Validacin
5.3
Desarrollo
6.6 Reuniones
5.3
Mantenimiento
6.7 Auditora
6.8 Resolucin de problemas
7. Procesos organizacionales
7.1 Gestin
7.2 Infraestructura
7.3 Mejora
7.4 Formacin
(1) La versin actual de este estndar ha modificado el esquema de procesos. Para el mbito de estos apuntes se mantiene esta versin
de 2005 por ofrecer una estructura ms comprensible.
29
(1) Para el mbito y finalidad de estos apuntes, manejamos mejor la versin previa de 2005 por ofrecer una estructura ms comprensible
30
ISO 1227 define los procesos que componen el ciclo de vida del software
Actividad 1
Tarea 1
Tarea 2
Proceso
Tarea n
Ciclo de vida
Concepto
Retirada
Proceso
N
Actividad n
Tarea 1
Tarea 2
Tarea n
31
ACTIVIDAD 1
TAREA 1
TAREA X
ACTIVIDAD n
TAREA 1
INICIO
PLAN
Tareas, agenda,
asignaciones
ACT
Problemas y acciones
correctivas
PROCESO
DO
Ejecicin de planes
y tareas
CHECK
Evaluacin y
medicin
32
FIN
ISO 12207 establece un nexo con la Ingeniera de sistemas al considerar al software como
parte de un sistema.
Desde esta perspectiva se establece a la Ingeniera de sistemas como fundamento de la
Ingeniera del Software.
Qu es un sistema?
Coleccin de componentes organizados para cumplir una funcin o conjunto de funciones
especficas.
IEEE Standard 610.12-1990
Sistema de
Entrada
Elemento del
sistema
Elemento del
sistema
Sistema
Elemento del
sistema
Elemento del
sistema
Sistema de
Salida
33
Sistema de software
Sistema o sub-sistema formado por una coleccin de programas y documentacin que de forma
conjunta satisfacen unos determinados requisitos.
Un sistema de software puede ser en s mismo un sistema independiente que, por ejemplo, realiza
su objetivo en un ordenador independiente. A este tipo de sistemas se les denomina tambin
sistema intensivo de software, porque el sistema es prcticamente software.
Un sistema de software puede ser tambin una parte de un sistema mayor. En cuyo caso se trata
en realidad de un sub-sistema de software.
Por ejemplo, el sistema de software de un avin de combate es en realidad el sub-sistema de
software del avin.
Ingeniera de sistemas
El trmino Ingeniera de sistemas surgi por primera vez en 1956, y fue propuesto por H. Hitch,
presidente del departamento de Ingeniera Aeronatica de la Universidad de Pensilvania, para
intentar desarrollar una disciplina de ingeniera que pudiera abarcar el desarrollo de grandes
sistemas que empleaban diversas disciplinas de ingenieras especficas: construccin de
bombarderos, submarinos, etc.
Los principios de Ingeniera de sistemas desarrollados en los 60 y 70 se aplicaron en programas
como el Apolo, o el programa de misiles balsticos USAF/USN.
34
Los procesos de ingeniera de sistemas integran las secuencias de actividades y decisiones que
transforman la definicin de una necesidad en un sistema, que con un ciclo de vida optimizado,
consigue un balance ptimo de todos sus componentes.
USAF, 1985
La principal funcin de la ingeniera de sistemas es garantizar que el sistema satisface los requisitos
durante todo el ciclo de vida. Todas las dems consideraciones se alinean sobre esta funcin.
Wymore 1993
La ingeniera de sistemas define el plan para gestionar las actividades tcnicas del
proyecto. Identifica el ciclo de desarrollo y los procesos que ser necesario aplicar. Desde
la Ingeniera de sistemas se desarrolla la lnea base tcnica para todo el desarrollo, tanto
de hardware como de software.
35
36
Anlisis de la solucin: Determinar las opciones posibles para satisfacer los requisitos y las
restricciones. Estudiar y analizar las posibles soluciones. Seleccionar la mejor, sopesando las
necesidades inmediatas, opciones de implementacin, utilidad, evolucin del sistema
Planificacin de los procesos: Determinar los grupos de tareas tcnicas que se deben realizar,
el esfuerzo requerido para cada una, su prioridad y los riesgos que implican para el proyecto.
Control de los procesos: Determinar los mtodos para controlar las actividades tcnicas del
proyecto y los procesos; la medicin del progreso, revisin de los productos intermedios y
ejecucin de las acciones correctivas, cuando corresponda.
Anlisis del
sistema
Pruebas del
sistema
Diseo del
sistema
Ingeniera de sistemas
Anlisis de
requisitos del sw
Pruebas del
sistema de sw
Pruebas de
integracin del sw
Diseo detallado
del software
Codificacin
Pruebas unitarias
37
Pruebas de
integracin del sis
Ingeniera de sistemas
38
Planificacin
Organizacin
Personal
Direccin
Control
1950
1960
1970
1980
1990
1990
2000
Ingeniera de sistemas
Crisis
del
Software
Gestin de proyectos
39
INGENIERA DE PROCESOS
(Produccin basada en procesos / mejora continua del proceso)
GESTIN DE PROYECTOS
40
Gestin de proyectos
predictiva
1.0
41
42
(predictiva)
Gestin basada en
PLANIFICACIN
SEGUIMIENTO
43
Qu hacer?
Ejecucin y control
1965.- IPMA
1969.- PMI
1989.- PRINCE 2
44
A tiempo
En costes
XITO
Calidad
45
cc-by: LizMarie
47
Lo previsto
A tiempo
En costes
48
15 Turnos
Lo previsto
A tiempo
En costes
49
XITO
Gestin basada en
PLANIFICACIN
SEGUIMIENTO
1
Qu hacer?
Ejecucin y control
LA FORMA MS EFICIENTE DE
HACER UN TRABAJO, ES
HACERLO BIEN A LA PRIMERA
Watts S. Humphrey
51
LA FORMA MS EFICIENTE DE
HACER UN TRABAJO, ES
HACERLO BIEN A LA PRIMERA
Watts S. Humphrey
53
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
La finalidad del proyecto es realizar algo que
no se piensa repetir de forma sistemtica.
54
Gestin de agenda
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
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 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
55
Gestin de
proyectos
Gestin y
Negocio del
administracin
proyecto
56
57
Diseo Web
Desarrollo Web
Anlisis
Integracin
Diseo Admin
58
Desarrollo Admin
Implantacin
Optimizacin
Conceptos clave para la optimizacin del proyecto
Paso adelante
Paso atrs
Ruta crtica
Reasignacin de recursos
59
60
61
62
63
Actividades crticas
Actividades que estn en la ruta crtica y que no tienen demora permisible. Sus retrasos afectan al proyecto
64
65
66
67
Recomendaciones
68
69
Gestin de agenda
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
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 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
70
71
72
OBJETIVO
A tiempo
73
En costes
Calidad
74
AGENDA Y COSTE
SON
RESULTADO DE LA
PLANIFICACIN
75
GESTIN DE RIESGOS
77
IDENTIFICACIN
ANLISIS
TRATAMIENTO
Plan de gestin
de riesgos
British Standard
BS 31100
78
Descripcin
Estndar publicado por ISO
COSO ERM
ISO IEC 73
79
Descripcin
La gestin de riesgos debe ser proporcional al nivel de criticidad
del proyecto.
Exhaustiva
Institucionalizada
Dinmica
Alineada
80
RISK AVOIDANCE
RISK CRITERIA
RISK DESCRIPTION
RISK EVALUATION
RISK FINANCING
RISK IDENTIFICATION
RISK MANAGEMENT
RISK MANAGEMENT AUDIT
RISK MANAGEMENT FRAMEWORK
RISK MANAGEMENT PLAN
RISK MANAGEMENT POLICY
RISK MANAGEMENT PROCESS
RISK MATRIX
RISK OWNER
RISK PERCEPTION
RISK PROFILE
RISK REGISTER
RISK REPORTING
RISK RETENTION
RISK SHARING
RISK SOURCE
RISK TOLERANCE
RISK TREATMENT
STAKEHOLDER
VULNERABILITY
Experiencia
Anlisis y clasificacin
Operacin
Y registro de informacin
81
Informacin
MTODOS CUALITATIVOS
Los ms utilizados cuando:
El nivel de riesgo es bajo y no justifica el esfuerzo de realizar anlisis completos.
Los datos numricos (anlisis cuantitativos) resultan inapropiados.
Alguinos mtodos cualitativos: Tormenta de ideas, what if, cuestionarios y entrevistas
estructuradas, juicio de expertos (Tcnica Delphi), checklists
MTODOS CUANTITATIVOS
Permiten asignar valores objetivos de probabilidad y ocurrencia para realizar anlisis de
probabilidades, consecuencias o simulaciones computacionales.
MTODOS SEMICUANTITATIVOS
Utilizan rangos de estimacin como alto medio bajo en una escala apropiada para
estimar el nivel de riesgo o sus consecuencias.
82
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
Agenda
Coste
Calidad
Operacin
83
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
84
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.
85
86
MEDIO
Moderada
Alta
RELEVANTE
ALTO
Escasa
Mnima
Extrema
BAJO
RELEVANTE
Muy grave
Grave
MEDIO
Media
Bajo
Mnimo
cc-by: LizMarie
89
Produccin basada en
procesos
1.0
90
1950
1960
1970
Crisis
del
Software
91
1980
1990
1990
2000
Gestin de
proyectos
predictiva
92
Produccin
basada en
procesos
Jurn / Humphrey
93
Eficiencia
Calidad
PROCESOS
94
Repetibilidad
cc-by: LizMarie
95
Jurn / Humphrey
96
Eficiencia
Calidad
PROCESOS
97
Repetibilidad
Modelos genricos
1979
BS 5750
1987
ISO 9000
Modelos
especficos
para software.
1959
MIL-Q 9858
98
1997
TickIT
1991
ISO 9000-3
Trillium
Bootstrap
1995
ISO 12207
1995
Proy. SPICE
TR 15504
2003-05
ISO 15504
1993
CMM-SW
Modelos
CMM
2001
CMMI
99
ISO 9000-3
ISO/IEC 12207
ISO/IEC 15504
ngeniera de
procesos
ESTNDARES PARA LA
INGENIERA DEL
SOFTWARE
CMM-SW
CMMI
Gestin
Predictiva
Ingeniera
del software
PMBOK
1950
1960
1970
1980
1990
1990
2000
100
1959
MIL-Q 9858
1979
BS 5750
1997
TickIT
1991
ISO 9000-3
Trillium
1987
ISO 9000
Modelos
especficos
para software.
PROCESOS
Modelos genricos
Bootstrap
1995
ISO 12207
1995
Proy. SPICE
TR 15504
2003-05
ISO 15504
1993
CMM-SW
Modelos
CMM
2001
CMMI
DSDM
AGILIDAD
SCRUM
CRYSTAL
XP
ASD
PP
ISD
AM
1995
101
2000
Manifiesto gil
Ingeniera de procesos de
software
1.0
102
Qu es un proceso?
103
104
ACTIVIDAD 1
TAREA 1
TAREA X
ACTIVIDAD n
TAREA 1
INICIO
PLAN
Tareas, agenda,
asignaciones
ACT
Problemas y acciones
correctivas
PROCESO
DO
Ejecicin de planes
y tareas
CHECK
Evaluacin y
medicin
105
FIN
106
107
Diagramas de flujo: Tcnica para especificar los detalles de un proceso en trminos de actividades, tareas,
entradas, salidas, condiciones.
UML...
108
PDCA
IDEALSM
Modelos genricos
Basados en ciclos de
mejora continua
109
Tienen similitudes
PDCA
PLAN
DO
Identificar el problema
Analizar el problema
Desarrollar soluciones
Implementar una solucin
CHECK
ACT
110
IDEAL
Fase Inicial
Fase de Diagnstico
Fase de establecimiento
Fase de accin
Fase de aprendizaje
111
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.
Improvements
5.
Implement
improv.
Results
4. Plan
improv.
112
6. Confirm
improv.
Action
plan
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
113
DEFINICIN
MEDICIN
ANLISIS
IMPLEMENTACIN Y CAMBIO
114
115
CARACTERIZAR
EVALUAR
PREDECIR
MEJORAR
SALIDAS
PROCESO
(resultado)
CONTEXTO
116
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)
2)
117
Paradigmas
ANALTICO/A
ANLISIS COMPARATIVO
(Benchmarking)
118
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
ENTENDER
CONSOLIDAR
Ejemplos:
119
REVISAR
2 arquitecturas generales con distintas asunciones en cuanto al orden en el que medir los
procesos: continua y escalonada
120
121
OBJETIVO
REQUISITO
MTRICA
INDICADOR
Objetivos
negocio
Qu tengo que
conseguir?
Qu quiero
conocer?
Indicador
122
Entidad 1
Entidad 2
...
Entidad Financiera
Fabricantes de
coches
Establecimiento
hotelero
124
Fiabilidad
Sin averas
Rapidez
G1
G2
Q1
I1
I2
M1
125
Q2
Q3
I3
M2
I4
M3
126
Modelo de procesos
CMMI
1.0
127
128
129
130
KPMG
Lockheed Martin
Motorola
Northrop Grumman
Pacific Bell
Q-Labs
Raytheon
Reuters
Rockwell Collins
SAIC
Software Productivity Consortium
Sverdrup Corporation
TeraQuest
Thomson CSF
TRW
Modelo combinado
System Engineering/Software
Engineering
Aplicable:
Continua o escalonada?
131
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
132
Software CMM--Escalonado
SECM--Continuo
IPD CMM--Hbrido
Escalonado
Continuo
Capacidad
ML5
ML4
ML3
ML2
ML 1
PA
PA
PA
. . .para un conjunto de
reas de proceso establecido
ML5
ML4
ML3
ML2
ML 1
134
0 Incompleto
1 Ejecutado
2 Gestionado
3 Definido
4 Gestin cuantificada
5 Optimizado
135
Capacidad
Proceso no ejecutado
Area
Proceso 1
Area
Proceso 2
Area
Proceso 3
Procesos
136
Area
Proceso n
1 Inicial
2 Gestionado
3 Definido
4 Gestionado cuantitativamente
5 Optimizado
137
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
138
139
5 OPTIMIZADO
4 GESTIONADO
CUANTITATIVAMENTE
REAS DE PROCESO
Innovacin y desarrollo
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
1 INICIAL
140
REAS DE PROCESO
Planificacin de proyecto
Monitorizacin y control de proyecto
Gestin y acuerdo con proveedores
GESTIN DE PROYECTOS
Gestin de la configuracin
Gestin de la calidad de procesos y productos
SOPORTE
Medicin y anlisis
Anlisis y resolucin de decisiones
Gestin de requisitos
INGENIERA
Soluciones tcnicas
Integracin de producto
Verificacin
Validacin
GESTIN DE PROCESOS
141
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
142
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
143
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.
144
Objetivos especficos
Objetivos genricos
Referencias
145
Practicas especificas
146
Nombres
Practicas genericas
Productos de
trabajo
Subpracticas
Elaboraciones
147
148
149
PMC
Acciones
Correctivas
Que
controlar
Replanificar
Acciones
Correctivas
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
150
Establecer
Estimaciones
Datos
Planificacin
Desarrollar Plan
de Proyecto
Obtener
Compromisos
con el Plan
Planes de
Proyecto
PMC
151
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
152
Planes de Proyecto
Seleccionar
Proveedores
Establecer
Acuerdos
Lista de productos
Requisitos Proveedor
Producto
Satisfacer
Acuerdos
Proveedor
Revisar
Productos
COTS
153
Acuerdo Proveedor
Ejecutar
Acuerdos
Aceptar
Producto
Transicin
Productos
154
REQM
Requisitos
TS
RD
Componentes
Producto
PI
Producto
Requisitos
VER
VAL
CLIENTE
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
156
157
Desarrollar
Requisitos
del Cliente
Desarrollar
Requisitos
del Producto
Requisitos
Cliente
Requisitos
Producto
Analizar y
Validar
Requisitos
Requisitos
Validados
Requisitos
Validados
Seleccionar
Soluciones
Producto-Comp.
Desarrollar
Diseo
Diseos alternativos
y Criterios de evaluacin
158
Implementar
Producto
Producto
Entregado
DAR
Preparar Integracin
Producto
Plan
Integracin
Garantizar
Interfaces
Compatibles
Assemblies
Solucin
Tcnica
Ensamblar
Comp. Producto y
Entregar Producto
159
Subassemblies
Preparar para
Verificacin
Ejecutar
Peer Reviews
Plan
Verificacin
Verificar Productos
Seleccionados
Acciones
Correctivas
160
- Requisitos Cliente
- Requisitos Producto
- Productos
- Validacin de Requisitos
Validar Producto o
Componentes Producto
Preparar para
Validacin
161
-Conformidad
-Deficiencias
Gestin de la configuracin
Gestin de la calidad de procesos y productos
Medicin y anlisis
Anlisis y resolucin de decisiones
Anlisis y resolucin de problemas
162
Calidad y no
conformidades
Medidas,
anlisis
Todas las reas de proceso
MA
Informacin
necesaria
Procesos y
resultados;
estndares y
procedimientos
Elementos de
configuracin;
peticiones de
cambio
Lneas base;
informes de auditoria
CM
163
PPQA
Sistema
Gestin
Configuracin
Establecer
Lneas
Base
Estado
BBDD
Peticiones
de cambio
Peticiones
de cambio
Establecer
Integridad
Resultados
Auditoria
Elementos
Accin
Productos
trabajo
Evaluacin
Objetiva
Procesos
Evaluacin
Objetiva
P. Trabajo
y Servicios
Informes y Registros
Proporcionar entendimiento objetivo
Comunicar
y Garantizar
Resolucin de
No Conformidades
165
Establecer
Registros
Objetivos Medicin
Personal
Medicin
Repositorio
Medicin
Indicadores Medicin
166
Procedimientos,
Herramientas
167
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
168
OPD
Procesos
Estndares
y Propios
reas de proceso de
gestin de proyecto,
soporte e ingeniera
Informacin de mejora
(e.j., lessons learned, datos)
Modelo de procesos
ISO / IEC 15504
1.0
169
mbito de aplicacin
170
P1
P9
Vocabulario
P7
P8
Gua
para mejora
de procesos
P3
Realizacin
de
evaluacin
Modelo de ref.
para procesos
y capacidad
171
P2
P6
Gua de
evaluacin
Modelo de
evaluacin
y gua de indic.
P5
Guia de
capacitacin de
evaluadores
P4
172
Dimensin de proceso
Caracterizada por las declaraciones del propsito de un proceso, que son objetivos esenciales
mensurables de un proceso.
Procesos de soporte
Procesos primarios
CUS: Cliente Proveedor
SUP: Soporte
ENG: Ingeniera
Procesos organizacionales
MAN: Gestin
ORG: Organizacin
173
174
175
176
177
178
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
179
180
181
PA 4.1 Medicin
182
183
Desde el punto de vista del estndar (v. Introduccin a la Ingeniera del Software) un proceso es un
conjunto de actividades y tareas relacionadas, que al ejecutarse de forma conjunta transforman una
entrada en una salida.
184
185
187
188
ADQUISICIN
emplea
PROCESO DE ADQUISICIN
Adquiriente
contrato
emplea
ROL
PROCESO DE SUMINISTRO
Suministrador
SUMINISTRO
emplea
ROL
OPERACIN
emplea
emplea
emplea
Operador
Usuario
PROCESO DE OPERACIN
usa
ROL
INGENIERA
ROL
SOPORTE
ROL
ORGANIZACIONAL
189
Desarrollador
Mantenedor
usa
PROCESO DE
MANTENIMIENTO
Usuario del
proceso de
soporte
Documentacin
Gestin de la configuracin
Aseguramiento calidad
Verificacin
Gestor
Gestin
Infraestructura
PROCESO DE
DESARROLLO
emplea
Validacin
Reuniones de seguimiento
Auditora
Resolucin de problemas
Mejora
Formacin
PROCESOS DE SOPORTE
ROL
Ciclos de desarrollo y
patrones de gestin de
proyectos
1.0
190
SECUENCIAL (cascada)
Fases
o
CONCURRENTE
Fases
191
Los procesos
y tecnologa
INGENIERA DE
PROCESOS
192
Las
personas
AGILIDAD
COMPLETA
INCREMENTAL
193
CONTINUA
194
ITERATIVA
195
Secuencial
Libre
Equipo
Polivalente
Especialistas
GESTIN
PREDICTIVA
DESARROLLO
Estrategia
Tctica
TRABAJO
CONOCIMIENTO
Prcticas
PMBOK
INGENIERA
SECUENCIAL
Completo
Plan de proyecto
Cascada
GESTIN
EVOLUTIVA
Prcticas giles
Procesos
Incremento Iterativo
AGILIDAD
Incremental
196
INGENIERA
CONCURRENTE
Incremento continuo
Fases solapadas
Personas
GESTIN
PREDICTIVA
DESARROLLO
Estrategia
Tctica
TRABAJO
CONOCIMIENTO
Prcticas
PMBOK
INGENIERA
SECUENCIAL
Completo
Plan de proyecto
Cascada
GESTIN
EVOLUTIVA
Prcticas giles
Procesos
Incremento Iterativo
AGILIDAD
Incremental
197
INGENIERA
CONCURRENTE
Incremento continuo
Fases solapadas
Personas
GESTIN
PREDICTIVA
DESARROLLO
Estrategia
Tctica
TRABAJO
CONOCIMIENTO
Prcticas
PMBOK
INGENIERA
SECUENCIAL
Completo
Plan de proyecto
Cascada
GESTIN
EVOLUTIVA
Prcticas giles
Procesos
Incremento Iterativo
AGILIDAD
Incremental
198
INGENIERA
CONCURRENTE
Incremento continuo
Fases solapadas
Personas
GESTIN
PREDICTIVA
DESARROLLO
Estrategia
Tctica
TRABAJO
CONOCIMIENTO
Prcticas
PMBOK
INGENIERA
SECUENCIAL
Completo
Plan de proyecto
Cascada
GESTIN
EVOLUTIVA
Prcticas giles
Procesos
Incremento Iterativo
AGILIDAD
Incremental
199
INGENIERA
CONCURRENTE
Incremento continuo
Fases solapadas
Personas
GESTIN
PREDICTIVA
DESARROLLO
Estrategia
Tctica
TRABAJO
CONOCIMIENTO
Prcticas
PMBOK
INGENIERA
SECUENCIAL
Completo
Plan de proyecto
Cascada
GESTIN
EVOLUTIVA
Prcticas giles
Procesos
Incremento Iterativo
AGILIDAD
Incremental
200
INGENIERA
CONCURRENTE
Incremento continuo
Fases solapadas
Personas
GESTIN
PREDICTIVA
DESARROLLO
Estrategia
Tctica
TRABAJO
CONOCIMIENTO
Prcticas
PMBOK
INGENIERA
SECUENCIAL
Completo
Plan de proyecto
Cascada
GESTIN
EVOLUTIVA
Prcticas giles
Procesos
Incremento Iterativo
AGILIDAD
Incremental
201
INGENIERA
CONCURRENT
E
Incremento continuo
Fases solapadas
Personas
Diseo del modelo especfico de ciclo de vida para el proyecto (sobre las bases de los
diseos ms apropiados, para el desarrollo y la evolucin del sistema de software.
Desarrollo del plan para la gestin del ciclo de vida del proyecto.
202
203
204
Requisitos deficientes
La planificacin de agendas y estimaciones de costes no se realizaron en base a los
requisitos
Deficiencias en la aplicacin de procesos y desconocimiento del ciclo de vida del proyecto
205
206
TOTAL: 52%
Fase en la que se
detecta el fallo
Requisitos
1X
1X
Arquitectura
Diseo detallado
Construccin
Requisitos
Arquitectura
Diseo detallado
construccin
Produccin
Estimacin
Planificacin
Diseo
Construccin
V&V
Los errores en los requisitos se comportan como una enfermedad contagiosa que siempre repercute
en todas las fases del proyecto.
Estimacin: No es posible estimar con rigor costes y recursos necesarios para desarrollar
algo que no se conoce.
Planificacin No se puede confiar en la planificacin para el desarrollo de algo que no se
sabe bien como es.
Diseo: Los errores en requisitos, las modificaciones frecuentes, las deficiencias en
restricciones o futuras evoluciones, producen arquitecturas que ms tarde se confirmarn
como errneas y sern modificadas.
Construccin: Las deficiencias en los requisitos obligan a programar en ciclos de prueba y
error que derrochan horas y paciencia de programacin sobre patrones de recodificacin
continua y programacin heroica.
Validacin y verificacin: Terminado el desarrollo del sistema, si las especificaciones tienen
errores de bulto, o peor an, no estn reflejadas en una especificacin de requisitos, no
ser posible validar el producto con el cliente.
208
209
Implicacin insuficiente
del cliente
Problemas en la validacin
del producto obtenido
Requisitos crecientes
y cambiantes
Degradacin de la estructura
y arquitectura del producto
Requisitos ambiguos
Prdida de tiempo en
re-codificacin
Requisitos
innecesarios
Trabajo innecesario
Requisitos mnimos
(insuficientes)
Problemas en la validacin
del producto obtenido
Requisitos mnimos
(insuficientes)
Error en la estimacin
y planificacin
Usuarios insatisfechos
210
[1] Calculating the Return of Investment from More Effective Requirement Management, Leffingwell, Dean. 1997.
212
213
214
215
Acuerdo entre desarrolladores, clientes y usuarios sobre el trabajo que debe realizarse.
Unos requisitos bien elaborados y validados con el cliente evitan descubrir al terminar el
proyecto que el sistema no era lo que se peda.
Acuerdo entre desarrolladores, clientes y usuarios sobre los criterios que se emplearn para su
validacin.
Resulta muy difcil demostrar al cliente que el producto desarrollado hace lo que el pidi si su
peticin no est documentada y validada por l.
Base objetiva para la estimacin de recursos (coste, personal en nmero y competencias, equipos
y tiempo)
Si los requisitos no comprenden necesidades reales, las estimaciones no dejan de ser meras
apuestas. Las estimaciones en el fondo son clculos de probabilidad que siempre implican un
margen de error; por esta razn disponer de la mayor informacin posible reduce el error.
Conceptos clave.
Requisitos
del software
Requisitos
del sistema
Procesos de
ingeniera de
requisitos
216
Especificacin
Obtencin
Anlisis
Gestin
Validacin y
verificacin
Procesos
Obtencin
Anlisis
mbitos
Especif.
V&V
Gestin
Sistema
Software
217
Nuestro punto de vista contempla las 5 reas clave, que se trabajan tanto en el mbito de los
requisitos del sistema como en los requisitos del software.
Obtener informacin
Clasificarla, localizar
inconsistencias, dar
prioridades, pasar a
requisitos
OBTENCIN
ANLISIS
Registro y contrastacin
Controlar las
modificaciones
Escribir los
requisitos
Registrar cambios,
estudiar su impacto,
actualizar
documentacin
ESPECIFICACIN
VERIFICACIN
&
VALIDACIN
GESTIN
Obtencin (elicitation)
El primer paso consiste en conocer y comprender las necesidades y problemas del cliente.
En la obtencin se identifican todas las fuentes de requisitos implicadas en el sistema y, en funcin
de las caractersticas del entorno y del proyecto se emplean las tcnicas ms apropiadas para la
identificacin de las necesidades que deben satisfacerse.
Anlisis
Una vez obtenida la informacin necesaria del entorno, es necesario sintetizarla, darle prioridades,
analizar posibles contradicciones o conflictos, descomponer el sistema y distribuir las necesidades
de cada parte, delimitar los lmites del sistema y definir su interaccin con el entorno.
218
219
Software
mbitos
220
221
El documento que recoge los deseos del usuario, sin requerir una cuantificacin medible.
Por ejemplo, el usuario puede indicar que desea que los tiempos de respuesta de las
consultas sean rpidos, y las razones de su deseo, sin necesidad de cuantificar esos
trminos. Ms adelante, el desarrollo y anlisis de los requisitos del sistema, el analista
concretar y cuantificar esos deseos.
Los proyectos de tamao pequeo requieren descripciones de sistema menos formales, pero no
por su reducido tamao debe ignorarse.
Si el proyecto de software forma parte de un proyecto mayor, la descripcin del sistema de
software puede ser un documento separado, o ir incluido en la descripcin del sistema completo.
El estndar puede aplicarse a todos los tipos de sistemas de software: slo software, intensivos
de software o software/ hardware/personas. Aunque los conceptos del estndar tambin podran
aplicarse a sistemas de hardware, esta no es su finalidad.
El estndar identifica los elementos que al menos debe incluir una Descripcin del sistema. El
usuario puede incorporar otros elementos, agregando clusulas y sub-clusulas.
222
223
SISTEMA
224
EVOLUCIN
PREVISTA
Interfaces externos. Cmo debe interactuar el software con las personas, el sistema de
hardware, o con otros sistemas (software y hardware).
225
QU, no el CMO
Una descripcin de requisitos del sistema limita las alternativas de diseo posibles, pero esto no
significa que deba decidir cul debe ser la solucin de diseo del sistema.
La especificacin de requisitos de software determina qu funcionalidades deben realizarse, qu
datos deben generarse en cada resultado, en qu lugar y quin los debe producir. La SRS debe
centrarse en los servicios que se realizarn, pero, en general, no debe especificar elementos de
diseo como los siguientes:
226
Algunos ejemplos de restricciones de diseo vlidas los constituyen los requisitos fsicos, los de
rendimiento y el cumplimiento de estndares en el desarrollo y procesos de garanta de calidad.
Coste.
Agenda de entregas.
Procedimientos de seguimiento.
Mtodos de desarrollo del software.
Control de calidad.
Criterios de validacin y verificacin.
Procedimientos de aceptacin
227
SRS
5.1 Adquisicin
5.1 Adquisicin
5.2 Suministro
5.2 Suministro
5.4
Operacin
5.3
Desarrollo
5.4
Operacin
5.3
Desarrollo
5.5
Mantenimiento
5.5
Mantenimiento
228
229
ENTORNO DE LA SOLUCIN
SRS
ANALIZAR EL PROBLEMA
DEFINIR EL SISTEMA
Analizar el
problema
230
Comprender las
necesidades de
los usuarios
Definir el sistema
Desarrollar los
requisitos del
software
Gestionar los
requisitos
Analizar el problema
Consiste en comprender los problemas reales de los usuarios, y proponer soluciones que cubran
sus necesidades.
El objetivo del anlisis es conseguir la mayor comprensin posible antes de que empiece el
desarrollo.
El analista de requisitos es en realidad un solucionador de problemas.
Durante el anlisis debe comprender las necesidades de los usuarios, y proponer soluciones. En
esta tarea es necesario explorar y comprender el entorno del cliente.
Al realizar el anlisis hay que
Evitar la tendencia frecuente a los prejuicios creyendo que ya conocemos las necesidades del
cliente, y que su principal problema en realidad es que no entiende cul es su problema.
Tener en cuenta que siempre hay varias maneras de abordar un problema, y que en ocasiones,
cambiar la perspectiva del usuario puede generar la solucin ms eficiente y rentable, aunque no
siempre es posible.
Comenzar el anlisis sin ideas preconcebidas y teniendo presente el objetivo: conseguir la mayor
comprensin posible del problema.
El anlisis del problema comprende
1.2.3.4.-
231
Definir el sistema
La descripcin del sistema marca el punto intermedio entre el anlisis del problema, y la
descripcin detallada de los requisitos del software. Es el documento que ofrece una visin general,
y ofrece la idea global del sistema en su conjunto. Marca una pausa antes de seguir avanzando
hacia los detalles, para evitar que los rboles nos impidan ver el bosque.
El resultado de esta fase es el documento de Definicin del sistema,
frecuentemente llamado tambin ConOps (Concept of Operations).
232
Definir el sistema
La descripcin del sistema el resultado del anlisis conceptual, y debe contener toda la informacin
necesaria para describir las necesidades de los usuarios, expectativas, entorno operativo, procesos
y caractersticas del sistema que se ha ideado para darles solucin.
Los elementos esenciales de la descripcin del sistema son:
Por Definir el sistema no consideramos slo la redaccin del Con Ops por
el ingeniero de requisitos. Tambin comprende la verificacin y
validacin del documento.
Por verificacin se entiende la supervisin del documento para garantizar que
resulta formalmente correcto.
Validacin implica la conformidad de las partes afectadas por el sistema
(usuarios, clientes, etc.).
233
234
Requisitos
Diseo
Codificacin
Integracin/
pruebas
235
Sistemas complejos.
Sistemas para dar soporte a procesos de negocio poco maduros.
Desarrollos evolutivos impuestos por la necesidad de implantaciones parciales tempranas
para los usuarios.
Avance del desarrollo del proyecto
236
237
238
239
Los interlocutores nombrados por el cliente no son conocedores expertos de los procesos cubiertos por el sistema.
Faltan representantes de partes implicadas por procesos importantes del nuevo sistema.
Escasa implicacin del cliente, que por falta de recursos, tiempo o incluso por pereza intelectual no se sienta con el
ingeniero de requisitos a desmenuzar las particularidades de sus procesos, dando por vlidos los requisitos finalmente
obtenidos, sin prcticamente mirarlos.
240
241
242
Ya est todo?
Cundo se puede dar por terminado un trabajo?
Cuando ya no queda ms por hacer.
Cmo sabe el ingeniero de requisitos que ha descubierto
todos los requisitos necesarios?.
La nica forma de afrontar esta circunstancia es dedicar tiempo suficiente a la obtencin y anlisis,
e identificar a todos los participantes o partes implicadas en el proyecto.
Aunque nunca podr afirmar haber localizado todos los requisitos, el objetivo en este caso es
alcanzar el convencimiento de haber descubierto lo suficiente, y que las posibles omisiones
pertenecern a cuestiones menores, que pueden surgir durante la gestin de los requisitos, o a lo
largo del mantenimiento del futuro sistema.
243
244
245
Organizacin
Entorno
Proyecto
246
247
Problema: inestabilidad
Los requisitos son inestables y cambian durante el desarrollo y tras la entrada en servicio del
sistema.
La solucin para evitar problemas radica en el proceso de gestin de requisitos.
[1] Goodrich, Victoria, and Olfman, Lorne. An experimental Evaluacion of Task annd Methodology Variables for Requirements
Definition Phase Success. In Bruce D. Shriver (editor), Proceedings of the twenty-third Annnual Hawaii International Conference on
System Sciences, p. 201-209. IEEE Computer Society, January 1990
248
ESCENARIOS
PROTOTIPOS
Prototipos rpidos
prototipos evolutivos
TCNICAS
OBSERVACIN
249
Introspeccin
anlisis de protocolo
documentacin, otros sistemas
REQUISITO
TIPOS DE REQUISITOS
NO FUNCIONALES
RESTRICCIN
REQUISITO
DE INTERFAZ
RESTRICCIN
Requisitos funcionales
Definen el comportamiento del sistema.
Describen las tareas que el sistema debe realizar.
Al definir un requisito funcional es importante mantener el equilibrio entre la excesiva generalidad,
insuficiencia de detalle o ambigedad, y el exceso de detalle con precisiones o descripciones
innecesarias o redundantes.
250
Requisitos no funcionales
Definen aspectos, que sin ser funcionalidades, (tareas que el sistema debe realizar) resultan
deseables desde el punto de vista del usuario. Generalmente comprenden atributos de calidad:
Tiempos de respuesta.
Caractersticas de usabilidad.
Facilidad de mantenimiento.
etc.
Requisitos de interfaz
Definen las interacciones del sistema con su entorno:
251
Usuarios
Otros sistemas
Restricciones
Los requisitos, en su definicin purista definen el QU, y no el CMO; pero en el conjunto de
necesidades que debe cubrir un sistema, no slo hay que tener en cuenta QU cosas hay que
hacer, sino tambin en ocasiones CMO deben hacerse.
La clasificacin entre requisitos puros (QU) y restricciones (CMO) la debe considerar el analista
para que el equipo de trabajo sepa hasta qu punto determinados aspectos limitan sus opciones de
trabajo, y poder mantener as la trazabilidad con su origen (necesidad apuntada por el usuario,
normativa legal, limitacin tcnica, etc.)
Con carcter general las restricciones imponen limitaciones:
El analista del sistema elige entre todas las opciones tecnolgicamente posibles aquellas que segn
su criterio profesional y las circunstancias del sistema, aportan mejor solucin para la
implementacin de los requisitos funcionales y no funcionales.
La indicacin por parte del cliente de instrucciones como:
Debe emplearse base de datos Oracle.
Los procesos de desarrollo deben ser conformes a Mtrica 3.
El sistema final debe ejecutarse sobre la plataforma libre Linux.
Debe desarrollarse empleando Java.
El interfaz de comunicacin con un programa externo de contabilidad debe hacerse de la siguiente
forma...
252
Requisitos
254
Posibles
Completa
Necesarios
Correcta
Priorizados
Consistente
Concretos
Modificable
Verificables
Trazable
Necesarios
Un requisito es necesario si es algo:
Alto
externo o estndar.
Coste
Alto
255
Valor
256
Comprensin
Un requisito es concreto si tiene una nica interpretacin. Como mnimo esto requiere que cada
caracterstica del producto final se describa empleando un trmino nico. En los casos en los
que el trmino puede tener diferentes significados segn el contexto, ste debe incluirse en el
glosario de la SRS con el significado con el que se emplea.
257
Punto
ptimo
Ambigedad
258
Definicin de las respuestas del software a todas las posibles entradas de datos en toda
clase de situaciones. Es importante especificar las respuesta tanto para datos de
entrada vlidos, como invlidos.
Referencias a todas las imgenes, tablas y diagramas y definicin de todos los trminos
propios y unidades de medida no normalizadas.
259
Conocemos
No Conocemos
Entrevistas y revisiones
Entendemos
Prototipado
Prototipado y
casos de uso
No Entendemos
260
A
B
B
Revisin y aprobacin
Requisitos
Correctos
C
Requisitos
Especificados
261
Conflictos
Objetos
Lgicos
C=A+B
C=A*B
Trminos
RF 10 Informe A
cierre de caja
RF 50 Informe A
262
Que tenga una organizacin coherente y fcil, con una tabla de contenidos y un ndice..
Que no sea redundante. (p. ej. que el mismo requisito no aparezca en dos lugares del
documento)
Exprese cada requisito por separado, mejor que mezclados con otros requisitos.
La redundancia, por s misma no es un error, pero puede acarrearlos. En ocasiones la
redundancia puede hacer un SRS ms legible, pero puede generar errores al actualizar el
documento, y generar inconsistencias si slo se actualiza una de las apariciones, olvidando la
otra.
263
264
265
Desarrollar software
Desarrollar una
solucin
Tomar requisitos
del usuario
Comprender el entorno
y necesidades del usuario
Realizar procesos
normalizados para el
desarrollo de requisitos
Descripcin de requisitos
correcta
MEDIOS
Aplicar tcnicas
y procesos
266
FIN
Conseguir
el objetivo
Diseo de software
1.0
267
Definicin
El proceso de definicin de la arquitectura, componente, interfaces y otras
caractersticas de un sistema o de un componente.
El resultado de este proceso.
IEEE std. 610.12-1990 Glossary of software engineering terminology
El diseo del software comprende la descripcin de la arquitectura del sistema con el nivel de
detalle suficiente para guiar su construccin.
Descomposicin del sistema
Organizacin entre los componentes del sistema
Interfaces entre los componentes
268
Requisitos
269
Diseo
Construccin
270
Considerando que la descripcin del sistema (ConOps) dibuja una primera aproximacin del
sistema en su conjunto, algunos autores diferencian entre:
Diseo del sistema (la visin del documento de descripcin del sistema).
Diseo de la arquitectura
Diseo del detallado del software
271
Por qu?
El resumen de las razones expuestas que hacen necesarias las tareas de diseo antes de
comenzar la construccin de un sistema son:
272
Descomposicin de la complejidad
Class nombredeclase{
Public: funcion() {}
}
273
Requisitos
?
274
Disponibilidad
Coste desarrollo
Coste mantenimiento
Robustez
Tiempos de respuesta
Hardware necesario
Etc.
275
276
estn realizados
277
Descripciones estructurales
Las notaciones para descripciones estructurales suelen ser grficas y representan los
diferentes componentes y sus relaciones.
Lenguajes de descripcin de arquitecturas (ADL): AADL, AESOP, CODE, MetaH,
Gestalt, Modechart, UML, Unicon, Modechart, etc.
Diagramas de clases y objetos
Diagramas de componentes
Diagramas entidad-relacin
Lenguajes de descripcin de interfaz
Etc.
Descripciones de comportamiento
278
Diagramas de actividad
Diagramas de colaboracin
Diagramas de flujo de datos
Diagramas de flujo
Pseudo-cdigo y lenguajes de diseo (PDL)
Diagramas de secuencia
Etc.
Diseo estructurado
Esta es la aproximacin clsica y se centra en la identificacin y descomposicin de las
principales funciones del sistema hacia niveles ms detallados.
Para cada estrategia hay numerosos mtodos (notaciones, lenguajes de modelado, tcnicas).
279
Estrategias
Las estrategias OO cubren tanto los requisitos como el anlisis, diseo y programacin.
Anlisis Orientado a Objetos (OOA)
Diseo Orientado a Objetos (OOD)
Programacin Orientada a Objetos (OOP)
Mtodos
Las metodologas ms importantes de anlisis y diseo de sistemas, orientado a objetos, han
terminado confluyendo en lo que es el UML (www.uml.org), bajo el respaldo del Object
Management Group (www.omg.org).
Algunas de las principales metodologas, pioneras que han terminado confluyendo en el UML
son:
Object-Oriented Design (OOD), Booch.
Object Modeling Technique (OMT), Rumbaugh.
Object Oriented Analysis (OOA), Coad/Yourdon.
Hierarchical Object Oriented Design (HOOD), ESA.
Object Oriented Structured Design (OOSD), Wasserman.
Object Oriented Systems Analysis (OOSA), Shaler y Mellor.
Responsibility Driven Design (RDD), Wirfs-Brock, entre otros.
280
Enfoque OO
Este paradigma centra su foco en el concepto Objeto.
Objeto es aquello que tiene estado (propiedades ms valores), comportamiento (acciones y
reacciones a mensajes) e identidad (propiedad que lo distingue de los dems objetos).
La estructura y comportamiento de objetos similares estn definidos en su clase comn; los
trminos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que
comparten una estructura y comportamiento comn.
La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe
en tiempo y espacio, mientras que una clase representa una abstraccin, la "esencia" de un
objeto, tal como son. De aqu que un objeto no es una clase, sin embargo, una clase puede
ser un objeto.
282
Concurrencia . Propiedad que distingue un objeto que est activo de uno que no lo est.
Tipificacin. Definicin precisa de un objeto de forma tal que objetos de diferentes tipos
no puedan ser intercambiados o, a lo sumo, pueden intercambiarse de manera muy
restringida.
Persistencia. Propiedad de un objeto por la cual su existencia trasciende al tiempo (es
decir, el objeto continua existiendo despus de que su creador ha dejado de existir) y/o al
espacio (es decir, la localizacin del objeto se mueve del espacio de direccin en que fue
creado).
283
Diagrama de clases
Diagrama de objetos
Diagrama de componentes
Diagrama de despliegue
Comportamiento dinmico
Modularizacin
Paquetes
Subsistemas
Modelos
284
1.- Introduccin
1.1 Propsito
1.2 Alcance
1.3 Definiciones y acrnimos
2.- Referencias
3.- Descomposicin de la informacin
3.1 Descomposicin modular
3.1.1. Descripcin del mdulo 1
3.1.2. Descripcin del mdulo 2
3.2 Descomposicin de los proceesos
3.2.1. Descomposicin del proceso
1
3.2.2. Descomposicin del proceso
2
3.3 Descomposicin de los datos
3.3.1. Descripcin de la entidad 1
3.3.2. Descripcin de la entidad 2
285
286
QU
CMO
287
288
El coste de esfuerzo
Riesgos tcnicos
Gestin de riesgos
289
Documentacin de usUario
1.0
290
Documentacin de usuario
Conceptos generales
Formatos de distribucin
Interno
Documentacin de usuario
Conceptos generales
Tipos de documentos y contenidos posibles
La documentacin de usuario de un sistema de software puede estar comprendida en uno o varios
documentos fsicos.
Un documento puede abordar uno o varios de los siguientes mbitos:
Instalacin / desinstalacin.
Uso del sistema.
Administracin.
Un sistema de software puede disponer de manuales diferentes para cada uno de los subsistemas
que lo componen.
292
Documentacin de usuario
Conceptos generales
Modos descriptivos
La documentacin de usuario puede adoptar dos modos narrativos diferentes: formativo o
referencia, en funcin de la finalidad con la que el lector va a usar el texto:
Para aprender a trabajar con el software (modo formativo)
Para refrescar la memoria, realizando consultas puntuales (modo referencia).
A su vez, los textos formativos pueden orientar la exposicin de sus contenidos para indicar al lector
cmo realizar cada tarea paso a paso. (orientados a tareas), o para transmitirle la informacin y
conocimientos tcnicos necesarios para emplear el software de forma adecuada (orientados a la
informacin).
Formativo
Orientado a la
informacin
Orientado a tareas
Modos descriptivos
Referencia
293
Documentacin de usuario
Conceptos generales
Los factores que deben determinarse antes de desarrollar la documentacin son:
Documentos necesarios
En funcin de las caractersticas del sistema, de los usuarios e incluso de parmetros del proyecto,
es necesario determinar cules son los documentos que debernelaborarse.
Algunos factores que pueden resultar tiles en su determinacin son:
Naturaleza del producto, fin previsto, entorno en el que se emplear, complejidad de uso
vista desde el punto de vista del usuario. Cmo de complejo es instalar, operar y mantener
el sistema.
Nivel de conocimientos de los usuarios, instaladores y personal de mantenimiento.
En el uso de sistemas informticos.
En los procesos y negocio gestionados por el sistema.
Tamao y complejidad del sistema, junto con las tecnologas empleadas en su desarrollo y
mantenimiento.
Requisitos contratados.
Ciclo de desarrollo del producto.
As por ejemplo, un producto con desarrollo incremental puede tener como requisitos en el contrato
la elaboracin de manuales de usuario para cada subsistema entregado, o uno global para todo el
sistema.
294
Documentacin de usuario
Conceptos generales
Caractersticas de la audiencia o audiencias
Audiencia: grupo de usuarios con caractersticas similares, tanto de operacin con el sistema,
como de conocimientos y experiencia informtica y profesional.
295
[1] Brockmann, R.J. (1990). Writing Better Computer Documentation: From Paper to Hypertext
Documentacin de usuario
Conceptos generales
Clasificacin de usuarios
Nivel de sofisticacin informtica
Inexperto[1]
Principiante
Intermedio
Experto
Intermitente
296
Caractersticas
Documentacin de usuario
Conceptos generales
297
Documentacin de usuario
Estructura de la documentacin de usuario
Recomendaciones del estndar IEEE 1063-2001 para la estructura
Estructura general
298
Documentacin de usuario
Estructura de la documentacin de usuario
Recomendaciones del estndar IEEE 1063-2001 para la estructura
Cada documento debe incluir
INFORMACIN IDENTIFICATIVA
INTRODUCCIN
Audiencia
Alcance y propsito del documento
Descripcin general del propsito y funcionalidad
del software, as como del entorno de operacin
299
Documentacin de usuario
Estructura de la documentacin de usuario
Recomendaciones del estndar IEEE 1063-2001 para la estructura
Informacin crtica
Contenido
300
Documentacin de usuario
Estructura de la documentacin de usuario
Recomendaciones del estndar IEEE 1063-2001 para la estructura
Componentes recomendados para la documentacin de usuario
COMPONENTE
301
OBLIGATORIO?
Informacin identificativa
Tabla de contenidos
S, en documentos de ms de 8 pginas
Lista de imgenes
Opcional
Introduccin
Documentacin de usuario
Estructura de la documentacin de usuario
Recomendaciones del estndar IEEE 1063-2001 para la estructura
Componentes recomendados para la documentacin de usuario
COMPONENTE
302
OBLIGATORIO?
Procedimientos
S, en modo formativo
S, en modo referencia
Glosario
Opcional
ndice
S, en documentos de ms de 40 pginas
Capacidad de bsqueda
Documentacin de usuario
Estructura de la documentacin de usuario
Recomendaciones generales
Legibilidad
La documentacin impresa y electrnica debe resultar legible para el usuario, teniendo en cuenta la
distancia que se emplear en las condiciones normales del entorno de consulta. Deben emplearse
tipos de letra y colores fcilmente legibles sobre el color de fondo empleado. La documentacin
impresa debe mantenerse legible si el usuario agranda o reduce la ventana de visualizacin.
El estndar IEEE 1063, por ejemplo, da algunas recomendaciones especficas como:
No abusar de las letras maysculas, indicando que no se emplee en ms de 25 palabras
seguidas.
No emplear en los textos electrnicos letras menores de 3mm. (aprox. 7,5 puntos).
En la documentacin electrnica deben considerarse tambin las combinaciones de colores
previendo el caso de que el usuario vaya a imprimirla en una impresora monocromo.
Correccin
Los textos deben ser lxica, ortogrfica y sintcticamente correctos.
Verificacin y validacin
1.0
304
Verificacin y validacin
Introduccin
La complejidad del desarrollo de un sistema de software
Durante el desarrollo de un sistema de software, antes de producir el producto ejecutable final, se
generan mltiples productos intermedios:
Especificaciones de requisitos.
Diseo.
Planes de prueba.
Cdigo.
Al mismo tiempo el producto final se genera a travs de las tareas y actividades realizadas en
diferentes procesos:
Adquisicin.
Suministro.
Desarrollo.
Etc.
305
Verificacin y validacin
Introduccin
Verificacin y validacin
Aunque en el lenguaje coloquial estos trminos pueden considerarse sinnimos, en el contexto de la
ingeniera del software tienen significados diferentes:
[1] Boehm Software Engineering Economics 1981 Marciniak J.J. Encyclopedia of Software Engineering 1994 Neal, R.D. A Case
Study of IV & V Cost Efectiveness 1997
306
Verificacin y validacin
Conceptos
Verificacin y validacin
Es la disciplina de gestin y actividad tcnica para garantizar que el software operar segn lo
especificado en los requisitos y las necesidades del usuario, que se lleva a cabo a travs de:
Verificacin
Se est construyendo adecuadamente el producto?
La verificacin se realiza contra el entorno de desarrollo o del proyecto.
Validacin:
Se est construyendo el producto adecuado?
La validacin se realiza contra el entorno cliente, donde el producto debe
cumplir su finalidad.
307
Verificacin y validacin
Conceptos
Verificacin: Mtodo empleado para garantizar que el producto resultante de una
actividad o fase del desarrollo cumple con los requisitos de esa actividad o fase en lo
relativo a correccin, calidad, rendimiento, cumplimiento de agendas y usabilidad.
Validacin: Mtodo que garantiza que el producto es conforme para el uso que tiene
previsto.
308
Verificacin y validacin
Verificacin y validacin en los procesos de desarrollo
5. Procesos primarios
5.1 Adquisicin
6.1 Documentacin
5.2 Suministro
5.3
Operacin
6.4 Verificacin
6.5 Validacin
5.3
Desarrollo
6.6 Reuniones
5.3
Mantenimiento
6.7 Auditora
6.8 Resolucin de problemas
7. Procesos organizacionales
309
7.1 Gestin
7.2 Infraestructura
7.3 Mejora
7.4 Formacin
Verificacin y validacin
Verificacin y validacin en los procesos de desarrollo
Procesos de soporte
Las actividades de verificacin y validacin pueden realizarse en diversas fases y sobre diversos
productos del desarrollo.
Por esta razn estn clasificados como procesos de soporte, que son llamados por otros procesos
del ciclo de vida.
As, por ejemplo, si el estndar 830 de IEEE se emplea para regular cmo debe hacerse el
documento de especificacin de requisitos del software, resulta posible y probable que durante el
curso del desarrollo se revise el documento para ver si se ajusta a las caractersticas definidas en el
estndar (verificacin).
Tambin resulta posible (y muy recomendable) que se contraste el documento generado con
interlocutores del cliente para comprobar que lo escrito refleja sus necesidades (validacin).
Si la agenda del plan de proyecto prevea disponer del diseo en la fecha X, parece lgico que
regularmente se verifique si los procesos estn inyectando causas de problemas en el proyecto
(incumpliendo agendas, en este caso).
El esfuerzo de verificacin y validacin debe ajustarse a las caractersticas del proyecto. En
algunos casos resultar aconsejable o necesario generar un plan de verificacin y validacin del
software que se ajuste a estndares como el IEEE 1012-1998, y en otros casos bastar con tareas
bsicas de verificacin yvalidacin, contempladas y dimensionadas en el plan del proyecto.
310
Verificacin y validacin
Relacin entre V&V y Aseguramiento de Calidad
Aseguramiento de la calidad
La funcin del Aseguramiento de la Calidad es garantizar que la organizacin realiza el trabajo
conforme a los procedimientos y mtodos establecidos para el proyecto.
IEEE Std. 730-1998
311
Verificacin y validacin
Adecuacin del V&V a las caractersticas del proyecto
Definiendo los objetivos
Las consideraciones que deben contemplarse para evaluar la planificacin de las actividades de
Validacin y Verificacin son:
312
Los criterios que se emplearn en las tareas de V&V para establecer los parmetros
mnimos de correccin, consistencia, precisin
Verificacin y validacin
Adecuacin del V&V a las caractersticas del proyecto
Criticidad del producto
El estndar IEEE 1012 establece que el plan de validacin y verificacin del software (SVVP) debe
especificar un mtodo para clasificar el nivel de integridad del software de cada subsistema de
software del proyecto.
313
Verificacin y validacin
Adecuacin del V&V a las caractersticas del proyecto
Anlisis de criticidad
Proceso para identificar, evaluar y categorizar el grado de criticidad de los elementos del producto
de software.
La definicin formal incluida en el estndar IEEE 1012-1998 es:
La evaluacin estructurada de las caractersticas del software (p. ej. Seguridad, complejidad,
rendimiento) para determinar la severidad del impacto de un fallo del sistema, de su degradacin o
de su no cumplimiento con los requisitos o los objetivos del sistema.
En otras palabras:
Anlisis de daos
(hazard analysis)
Anlisis de criticidad
Anlisis de riesgos
(risk analysis)
314
Verificacin y validacin
Adecuacin del V&V a las caractersticas del proyecto
Anlisis de criticidad: anlisis de daos
La definicin formal del anlisis de daos (a nivel de sistema) es:
Anlisis de fuentes potenciales de daos o de situaciones que pueden generar daos en trminos
de daos a personas, daos a la salud, o al entorno, o una combinacin de ellos.
IEC 60300-3-9, 1995
No obstante el estndar para validacin y verificacin IEEE 1012-1998 da una definicin ms amplia
que incluye tambin prdidas econmicas, fallo en la misin del sistema, o impacto social adverso.
Para nosotros dao en el marco de validacin y verificacin de software incluye por tanto:
Para realizar el anlisis de daos deben identificarse las consecuencias que pueden ocasionar
los fallos en el software. Es posible que no generen daos fsicos, pero s en trminos de
prdidas econmicas (para el desarrollador, para el cliente, para los usuarios), o de impacto social
adverso (desprestigio del cliente, del desarrollador, de los usuarios, de terceros).
315
Verificacin y validacin
Adecuacin del V&V a las caractersticas del proyecto
Anlisis de criticidad: anlisis de riesgos
Riesgo: probabilidad de que se produzca un dao identificado
En el desarrollo de un sistema de software se pueden producir adversidades que afecten a:
Los planes del proyecto.
Al producto o subproductos del desarrollo.
Los riesgos inherentes a un proyecto suelen ser de tres naturalezas:
Intrnsecos al sistema que se desarrolla
Derivados de las particularidades de desarrollo del software.
Propios del desarrollo de proyectos.
316
Verificacin y validacin
Adecuacin del V&V a las caractersticas del proyecto
Anlisis de criticidad: anlisis de riesgos
NATURALEZA DEL RIESGO
Propios del sistema
CAUSAS TPICAS
Los identificados en el anlisis de daos
Complejidad innecesaria
Baja calidad
[1] En los proyectos de software se suelen dar con mayor intensidad los riesgos tpicos indicados.
317
Verificacin y validacin
Adecuacin del V&V a las caractersticas del proyecto
Anlisis de criticidad: anlisis de riesgos
Validacin y Verificacin no gestionan las causas de los riesgos. Esa gestin pertenece a la gestin
de riesgos, dentro de la gestin del proyecto.
Validacin
Verificacin
Gestin de proyecto
(Gestin de riesgos)
[1] En los proyectos de software se suelen dar con mayor intensidad los riestos tpicos indicados.
Verificacin y validacin
Adecuacin del V&V a las caractersticas del proyecto
Niveles de integridad
Anlisis de daos
(hazard analysis)
NIVEL DE
INTEGRIDAD
Anlisis de criticidad
Anlisis de riesgos
(risk analysis)
Una vez realizado el anlisis de criticidad a travs de los anlisis de
daos y de riesgos, resulta posible establecer el nivel de integridad
del proyecto y adecuar a l las tareas de validacin y verificacin.
Adecuacin de las
tareas de
VALIDACIN
y
VERIFICACIN
319
POSIBILIDAD DE MITIGACIN
DEL DAO
Verificacin y validacin
Adecuacin del V&V a las caractersticas del proyecto
Niveles de integridad
El estndar IEEE 1012-1998 define 4 niveles de integridad.
En el borrador de 2004 las definiciones que se recogen para cada uno son:
Nivel
4
Mitigacin aplicable
Prdida de vida
Prdida del sistema
Graves prdidas econmicas o sociales
No es posible mitigar
los daos producidos
No es necesario mitigar
los daos
El modelo del estndar resulta vlido, pero cualquier modelo, adecuado a las circunstancias del
sistema y del entorno de desarrollo, puede resultar igualmente vlido.
320
Verificacin y validacin
Adecuacin del V&V a las caractersticas del proyecto
Independencia
La determinacin de las personas responsables de las tareas de verificacin y validacin, depende
de:
Nivel de integridad
321
Independencia de gestin
Las personas que realizan las tareas de verificacin y validacin se gestion al margen de la
organizacin que realiza el desarrollo. Tienen la autoridad para tomar decisiones sobre el
trabajo de V&V, incluyendo qu elementos se van a analizar, con qu herramientas. Facilitan
la informacin de sus conclusiones tanto a los desarrolladores como al adquiriente, pero
slo el adquiriente puede modificar la lnea de trabajo de validacin y verificacin.
Independencia tcnica
Las personas que analizan el proyecto son ajenas al grupo de desarrollo. Emplean sus
propias herramientas, mtodos y recursos.
Independencia financiera
Las tareas de verificacin y validacin cuentan con presupuesto propio, y la autoridad para
modificar su presupuesto est fuera de la organizacin desarrolladora.
Verificacin y validacin
Adecuacin del V&V a las caractersticas del proyecto
Tipos de independencia
La validacin y verificacin independiente (IV&V) se clasifica en 4 tipos, en funcin del rigor con el
que se realiza: clsica, modificada, interna y domstica. Los proyectos con nivel de integridad 4
requieren independencia rigurosa en todas sus reas.
El estndar IEEE 1012-1998 muestra con la siguiente tabla el grado de independencia generalmente
proporcionado por cada tipo, para cada faceta del proyecto.
reas
Tipos de independencia
322
Gestin
Tcnica
Financiera
CLSICA
MODIFICADA
I-R
INTERNA
I-R
I-R
I-R
DOMSTICA
I-M
I-M
I-M
I: Independencia rigurosa
Verificacin y validacin
Adecuacin del V&V a las caractersticas del proyecto
Tipos de independencia
IV&V CLSICA
Normalmente requerida para proyectos con nivel de integridad 4.
Exige rigurosa independencia en las 3 reas del proyecto.
IV&V MODIFICADA
Suele emplearse en proyectos con nivel de integridad 3.
El desarrollo y la V&V lo realizan organizaciones diferentes, pero la responsabilidad de la gestin en
el proyecto es nica, y es la que recibe la informacin de ambas partes. No obstante, los
presupuestos y el personal tcnico estn separados.
IV&V INTERNA
Se emplea cuando el equipo de V&V pertenece a la misma organizacin desarrolladora, pero en la
forma de una entidad diferenciada del grupo de desarrollo del proyecto.
IV&V DOMSTICA
Se emplea personal de la organizacin desarrolladora para realizar la V&V. El personal de desarrollo
y de validacin y verificacin trabaja conjuntamente. No se puede garantizar la independencia
tcnica, y la gestin y el presupuesto son nicos para desarrollo y V&V.
323
Verificacin y validacin
Verificacin y validacin en el ciclo de vida del software
Las tareas de verificacin y validacin se deben realizar en paralelo con los procesos del ciclo de
vida, incluyendo tambin la gestin del proyecto.
Gestin
Adquisicin
Suministro
Desarrollo
Operacin
Mantenim.
Verificacin y Validacin
GESTIN
El objetivo del trabajo de verificacin y validacin es garantizar que el software tiene la integridad
requerida.
Este trabajo debe realizarse de forma integrada en la gestin del proyecto y puede comprender:
y verificacin.
Verificacin y validacin
Verificacin y validacin en el ciclo de vida del software
ADQUISICIN
En el proceso de adquisicin el trabajo de verificacin y validacin debe incluir siempre
Revisin de la descripcin del sistema.
En funcin del nivel de integridad del proyecto, puede cubrir tambin:
Valoracin de la dimensin y alcance de los trabajos de V&V.
Planificacin de la comunicacin entre los trabajos de V&V y la organizacin desarrolladora.
SUMINISTRO
El proceso de verificacin y validacin comienza cuando un suministrador decide atender la peticin
de adquisicin. V&V se enfoca en determinar si la documentacin e informacin facilitada por el
adquiriente es consistente y si, en opinin del suministrador, la solucin satisfar las necesidades de
los clientes.
Este proceso se denomina verificacin del contrato.
325
Verificacin y validacin
Verificacin y validacin en el ciclo de vida del software
DESARROLLO
La verificacin y validacin en el desarrollo centra su actividad en 6 tareas, que corresponden a las
5 tpicas de los ciclos de desarrollo en cascada, ms instalacin.
V&V EN EL PROCESO DE DESARROLLO
CONCEPTO
REQUISITOS
DISEO
IMPLEMENTACIN
PRUEBAS
INSTALACIN
326
Verificacin y validacin
Verificacin y validacin en el ciclo de vida del software
V & V REQUISITOS
En esta fase, la verificacin y validacin comprueba el principal producto generado en esta fase: la
especificacin de requisitos del software.
Se analizan las propiedades de calidad
DEL DOCUMENTO
Completo
Correcto
Consistente
Modificable
Trazable
DE LOS REQUISITOS
Posibles
Necesarios
Priorizados
Correctos
Verificables
V & V DISEO
Comprobacin de que el diseo realizado comprende todos los requisitos sin omisiones y sin
complejidad innecesaria. Los aspectos generales que se analizan son:
Trazabilidad entre requisitos y diseo.
No hay omisiones ni aadidos.
El diseo es apropiado para los objetivos deseados del sistema.
El diseo es conforme con los estndares, prcticas y convenciones acordadas para el
proyecto
El diseo es comprensible por el equipo de desarrollo y el posterior de mantenimiento.
Contiene informacin suficiente para realizar las pruebas de unidad y de integracin.
La documentacin est completa, incluyendo grficas o especificaciones necesarias.
327
Verificacin y validacin
Verificacin y validacin en el ciclo de vida del software
V & V IMPLEMENTACIN
La implementacin transforma la descripcin del diseo en componentes de que juntos integran el
producto final de software. La labor de verificacin y validacin comprueba:
Conformidad del cdigo
Con las especificaciones del diseo
Con los estndares aplicables
La idoneidad del cdigo para obtener el producto con el nivel de integridad deseado.
V & V PRUEBAS
La verificacin y validacin de las pruebas garantiza que se han cumplido los requisitos del sistema
y del software, alcanzando los niveles de integridad requeridos.
En sistemas con niveles de integridad 3 y 4 es necesario que el equipo de verificacin y validacin
realice los planes y procesos de prueba, as como su ejecucin.
Para niveles 1 y 2 es suficiente con verificar las pruebas realizadas por el equipo de desarrollo.
V & V INSTALACIN
Se comprueba el rendimiento del sistema de software al ejecutarse en el entorno del cliente, as
como que los procedimientos de instalacin son correctos.
328
Verificacin y validacin
Verificacin y validacin en el ciclo de vida del software
V & V OPERACIN
Una vez instalado y puesto en servicio el sistema de software, la verificacin y validacin valora el
impacto que los cambios pueden suponer en el nivel de integridad del sistema, o los riesgos o daos
que pueden introducir.
Incluye la monitorizacin y evaluacin del entorno de operacin.
V & V MANTENIMIENTO
Una vez puesto en servicio el sistema de software, las modificaciones del entorno, o la presencia de
errores, o la necesidad de ampliar su funcionalidad requerirn emprender tareas de mantenimiento,
que en esencia, y a menor escala son pequeas acciones de desarrollo que pueden introducir
modificaciones en el nivel de integridad, y requerir revisiones en los anlisis de criticidad, daos y
riesgos, as como requerir posteriores acciones de verificacin y validacin sobre las modificaciones
de requisitos, diseo, desarrollo y pruebas.
329
Mantenimiento
1.0
330
Mantenimiento
Introduccin
La complejidad del mantenimiento de un sistema de software
CONSUME MUCHOS RECURSOS
El mantenimiento consume ms
del 60% del coste de todo el
ciclo de vida
Mantenimiento
Introduccin
Definicin
Modificacin de un producto de software, despus de su entrega para corregir errores,
mejorar el rendimiento u otros atributos o adaptar el producto a cambios del entorno.
IEEE Std. 1219-1998
Producto de software no comprende slo el cdigo. Incluye tambin la documentacin y los datos de
configuracin
PRODUCTO DE SOFTWARE
Cdigo
332
Datos de configuracin
y estructuras de datos
Requisitos, documentos
de anlisis, plan de V&V
Manuales y
documentacin de usuario
Mantenimiento
Tipos de mantenimiento
El mantenimiento del software se clasifica generalmente en tres categoras, en funcin de cul es la
causa que motiva el cambio:
Adaptativo
Correctivo
Perfectivo
ADAPTATIVO
Permite al software continuar en funcionamiento, adaptndose a cambios producidos en su entorno
de operacin.
Los cambios tpicos se suelen centrar en el hardware con el que interacta, en el sistema operativo,
o en formatos de datos que recibe o enva.
CORRECTIVO
Tiene como finalidad corregir fallos o problemas. Dentro del mantenimiento correctivo se suele
diferenciar entre de emergencia o de agenda; en funcin de la urgencia con la que deba
aplicarse la solucin.
En algunas ocasiones el cliente necesita urgentemente la reparacin del fallo, y en otras, puede
seguir operando con el error presente, y esperar a la prxima versin que normalmente incluye
cambios acumulados en la agenda de mantenimiento, tanto de tipo adaptattivo, como correctivo y
perfectivo.
333
Mantenimiento
Tipos de mantenimiento
PERFECTIVO
Se realiza para dar respuesta a nuevos requisitos del cliente, o para mejorar el rendimiento del
sistema.
Clasificacin
Porcentajes habituales
Adaptativo
Mantenimiento
De emergencia
Correctivo
De agenda
Perfectivo
[Preventivo]
PREVENTIVO
En su versin de 1993, el estndar IEEE 1229 inclua tambin en su clasificacin el mantenimiento
preventivo como aquel que se realiza para evitar la aparicin futura de errores, o para mejorar la
integridad de producto en prevencin de stos. Algunos textos lo consideran como un 4 tipo de
mantenimiento, y otros lo incluyen como mantenimiento correctivo.
334
Mantenimiento
Dificultad del mantenimiento
El mantenimiento es una de las fases ms difciles del ciclo de vida, y generalmente no est lo
suficientemente reconocida.
Las principales razones de esta situacin son:
En muchos sentidos, el mantenimiento resulta ms difcil tanto desde el punto de vista tcnico como
de gestin del proyecto. Algunos de los factores que hacen del mantenimiento un proceso difcil
son:
335
Mantenimiento
Dificultad del mantenimiento
Dificultad por degradacin del sistema
Cuanto mejor diseado, codificado y documentado est un sistema, ms fcil resulta su
mantenimiento.
Las propias tareas de mantenimiento tienden a degradar el diseo, la limpieza del cdigo y su
documentacin, generando de esta forma una espiral que se retroalimenta y que con el tiempo
incrementa la dificultad de mantenimiento de un sistema.
Los factores que favorecen esta situacin, y que por tanto es necesario gestionar adecuadamente
son:
Los mitos ya apuntados de no otorgar al mantenimiento la importancia y rigor necesarios.
Las presiones de tiempo y recursos con las que suelen ejecutarse.
La consideracin por parte del personal tcnico de tareas de segunda divisin
Diseo
336
Cdigo
Datos
Documentacin
Mantenimiento
Dificultad del mantenimiento
Dificultad por degradacin del sistema
DIFICULTAD
DEL MANTENIMIENTO
Factores agravantes
SISTEMA MS DIFCIL
DE MANTENER
337
Escasa concienciacin
organizacional de la relevancia del
mantenimiento.
Peticiones de cambios con presin
de fechas y presupuestos.
Consideracin del personal tcnico
de que se trata de un trabajo de
segunda categora
Mantenimiento
Dificultad del mantenimiento
Las tareas de mantenimiento deben ejecutarse dentro de un marco de gestin, de igual forma que
si se trata el desarrollo de un sistema nuevo.
Tambin es frecuente que en este aspecto tambin el mantenimiento suele ser tratado como la
cenicienta en los proyectos de software, y generalmente resulta ms difcil la gestin de un
proyecto de mantenimiento que la de un desarrollo nuevo. De hecho puede ocurrir que dentro del
mantenimiento de un sistema se incluya tambin el desarrollo de un nuevo sub-sistema paraa
ampliar su funcionalidad.
Por tanto todas las tareas e indicaciones propias de la gestin de proyectos de software son
aplicables a los proyectos de mantenimiento: estimacin del esfuerzo necesario, identificacin de
procesos necesarios, planificacin de costes y agendas, gestin de riesgos, etc.
338
Mantenimiento
Las 7 fases del mantenimiento
Para identificar y comprender las actividades que deben tenerse en cuenta en el mantenimiento, los
pasos que deben seguirse y las herramientas y mtodos que deben emplearse, resulta muy til
considerar que los procesos de cambio o modificaciones de un sistema de software comprenden 7
fases:
Al realizar tareas de mantenimiento, en cada una de estas fases deben considerarse los siguientes
elementos:
EN CADA FASE
Entradas
339
Procesos
Control
Salidas
Mtricas
Mantenimiento
Las 7 fases del mantenimiento
1.- Identificacin del problema, clasificacin y priorizacin
Cada peticin de cambio debe identificarse, clasificarse y asignarle una prioridad, teniendo en
cuenta qu tipo de mantenimiento implica (correctivo, adaptativo, perfectivo y si es de emergencia)
Entradas
Peticin de cambio
340
Procesos
Asignar n de
identificacin
Clasificar por tipo
de mantenimiento
Analizar y determinar se se acepta
rechaza o pospone
Primera estimacin
de su magnitud
Priorizar la
modificacin
Asignar la peticin
a qu bloque de
modificaciones
prevista va a ir
Control
Una vez identificada
la peticin de
cambio, debe
quedar registrada
en un registro de
peticiones de
cambio
Salidas
Peticin de cambio
validada que queda
en un registro con la
siguiente
informacin:
Definicin del
problema o del
nuevo requisito
Evaluacin
Tipo de mantenim.
Prioridad inicial
Estimacin inicial
de recursos
necesarios
Mtricas
N de omisiones
en la P.C.
N de P.C.
enviadas
N de peticiones
de cambio
duplicadas
Tiempo invertido
en la validacin.
Factores medidos:
correccin y
mantenibilidad
Mantenimiento
Las 7 fases del mantenimiento
2.- Anlisis
La fase de anlisis emplea la relacin de peticiones de cambio registradas y validadas para analizar
su viabilidad, alcance de las modificaciones y preparar un plan preliminar de diseo implementacin
y entrega
Entradas
Peticin de cambio
validada
Estimacin inicial
de recursos y
dems informacin
registrada.
Documentacin del
proyecto (si la
hay).
341
Procesos
Anlisis de
viabilidad
(impacto,
soluciones
alternativas,
implicaciones de
seguridad, coste y
beneficio de la
modificacin)
Anlisis detallado
(SRS de la
modificacin,
elementos a
modificar,
estrategia de
pruebas)
Control
Salidas
Realizar revisiones
tcnicas y revisar
Estrategia
de
pruebas.
Que la documentacin est
completa y
actualizada e
incluye parmetros
de seguridad
Informe de
viabilidad de las
P.C.
Informe del anlisis detallado.
Requisitos
actualizados (y
trazables)
Lista preliminar
de mofificaciones.
Plan de pruebas
Plan de
implementacin
Mtricas
Modificaciones de
requisitos
% de errores en
la documentacin
Esfuerzo por rea
(SQA, SE, etc.)
Tiempo empleado
% de errores
generados por
prioridad y tipo.
Factores: flexibilidad
trazabilidad
usabilidad
mantenibilidad
reusabilidad
Mantenimiento
Las 7 fases del mantenimiento
3.- Diseo
En esta fase se emplea toda la documentacin del sistema, del proyecto y la generada en la fase
anterior (anlisis) para disear la modificacin del sistema.
Entradas
Salidas de la fase
de anlisis.
Documentacin del
sistema y del
proyecto
Cdigo,
comentarios y
bases de datos del
sistema.
342
Procesos
Identificacin
de
los mdulos
afectados.
Documentacin de
las modificaciones
Creacin de casos
de prueba para las
modificaciones
Identificacin y
creacin de
pruebas de
regresin
Actualizacin de
documentacin
(SRS manuales)
Control
Inspeccin /
verificacin del
diseo
Inspeccin /
verificacin de la
documentacin
asociada
Salidas
Revisados:
Lista de
modificacines
Anlisis detallado
Plan de
implementacin
actualizado
Lnea base de
diseo
Planes de
pruebas
Mtricas
Complejidad del
software
Cambios diseo
Esfuerzo por rea
Cambios en
planes de prueba
Nmero de
mdulos
N lneas de
cdigo aadidas o
modificadas
Mantenimiento
Las 7 fases del mantenimiento
4.- Implementacin
A partir del diseo realizado y verificado, el cdigo y la documentacin del sistema y del proyecto se
lleva a cabo el trabajo de implementacin.
Entradas
Resultados de la
fase de diseo.
Cdigo fuente y
bases de datos del
sistema.
Documentacin del
sistema y del
proyecto.
Procesos
Codificacin y
pruebas unitarias
Integracin
Anlisis de riesgos
Revisin de
pruebas
Control
343
Revisiones de
cdigo
Verificacin de la
integracin.
Verificacin de
modificaciones y
actualizaciones
de
documentacin.
Gestin de
riesgos y
supervisin
durante las
pruebas
Salidas
Revisados:
Software
actualizado.
Documentacin
de diseo,
pruebas,
manuales
documentacin
de formacin
actualizados.
Definicin de
riesgos e
impactos.
Informe de
revisin de las
pruebas
Mtricas
Volumen (puntos
de funcin /
lneas de cdigo)
Porcentaje de
errores
generados.
Mantenimiento
Las 7 fases del mantenimiento
5.- Pruebas de sistema y de regresin
Tras la implementacin deben realizarse las pruebas del sistema modificado. Las pruebas de
regresin son parte de las pruebas del sistema que comprueban que el cdigo modificado no ha
introducido errores nuevos.
Entradas
Informe
de las
pruebas.
Documentacin de
los planes de
prueba, casos de
prueba,
procedimientos de
prueba, manuales
de usuario, diseo.
Sistema
actualizado
344
Procesos
Prueba funcional
del sistema.
Pruebas de
interfaz.
Pruebas de
regresin.
Control
Salidas
Revisados:
Sistema revisado.
Informes de
pruebas.
Mtricas
Porcentajes de
errores por
prioridad y tipo:
Generados y
corregidos.
Mantenimiento
Las 7 fases del mantenimiento
6.- Pruebas de aceptacin
Sobre el sistema completamente integrado, el cliente, los usuarios o un tercero nombrado por el
cliente lleva a cabo las pruebas de aceptacin
Entradas
Informes
de
pruebas.
Sistema
completamente
integrado.
Planes de pruebas
de aceptacin.
Casos de prueba
de aceptacin.
Procedimientos de
aceptacin
Procesos
Ejecucin
de las
pruebas de
aceptacin a nivel
funcional.
Ejecucin de
pruebas de
interoperabilidad.
Ejecucin de
pruebas de
regresin.
Control
345
Ejecucin de
planes de
aceptacin.
Auditora
funcional.
Puesta bajo
control de
configuracin de
la nueva
documentcin.
Establecimiento
de la nueva lnea
base del sistema.
Informe de los
resultados de
auditora
funcional.
Salidas
Mtricas
Porcentajes de
errores por
prioridad y tipo:
Generados y
corregidos.
Mantenimiento
Las 7 fases del mantenimiento
7.- Entrega
Entrega del sistema modificado.
Entradas
El sistema
modificado segn
se represente en la
nueva lnea base.
346
Procesos
Auditora fsica de
la configuracin.
Notificacin a la
comunidad de
usuarios.
Desarrollo y
archivo de una
copia de seguridad
del nuevo sistema.
Instalacin y
formacin de
usuarios.
Control
Ejecucin de la
auditora fsica de
la configuracin.
Documento de
descripcin de la
versin.
Salidas
Informe de la
auditora fsica.
Documento de
descripcin de la
versin.
Mtricas
Cambios en la
documentacin
(manuales de
usuario, de
operacin,
documento
descripcin de
versin, etc.)
Mantenimiento
Mantenibilidad
Con este trmino, que aunque inexistente en el lxico espaol se ha hecho hueco en nuestra jerga,
se define una propiedad del software que se puede definir como:
347
Mantenimiento
Mantenibilidad
Medicin
Vista la definicin de mantenibilidad, y los factores que la forman
Cmo se mide la mantenibilidad?. Es posible afirmar que este sistema tiene una mantenibilidad
de 6, o alta, o peor que la de aquel otro sistema?.
No es un atributo ni fsico ni simple. No puede medirse directamente.
Las mediciones siempre tendrn carcter de aproximacin, y se pueden realizar indirectamente
midiendo aspectos relacionados:
348
Mantenimiento
Mantenibilidad
Reingeniera
Cmo abordar el mantenimiento de un sistema de software con problemas de
mantenibilidad?
349
Mantenimiento
Mantenibilidad
Modelo de reingeniera del software
El modelo comprende 6 actividades. La primera es un anlisis de inventario del que se decidir si de
aplica reingeniera, y en caso afirmativo se emplearn alguna o todas de las cinco actividades
restantes.
Anlisis de
inventario
Qu
hacer?
Reconstruccin
Ingeniera inversa
Ingeniera
inversa
350
Reestructuracin
de datos
Reestructuracin
de cdigo
Reestructuracin
de documentos
Ingeniera
progresiva
Mantenimiento
Mantenibilidad
Modelo de reingeniera del software
Anlisis de inventario
El inventario del sistema comprende la informacin necesaria para el anlisis que servir para
decidir si resulta ms conveniente rehacer de nuevo el sistema, o aplicar tcnicas de reingeniera:
Mantenimiento
Mantenibilidad
Modelo de reingeniera del software
Reestructuracin de documentos
Los sistemas en los que se cuestiona aplicar reingeniera suelen tener deficiencias en su
documentacin.
En funcin de las caractersticas del proyecto, tras el anlisis del inventario las opciones son:
352
Mantenimiento
Mantenibilidad
Modelo de reingeniera del software
Ingeniera inversa
La ingeniera inversa realiza un anlisis de un sistema de software para conseguir especificar su
documentacin; generalmente su diseo.
Obviamente se aplica cuando no se dispone del diseo, o ste est obsoleto.
Un proceso de ingeniera inversa debe ser capaz de:
Derivar las representaciones de diseo de procedimientos.
Extraer la estructura de datos.
Representar el modelo de los flujos de datos y de control.
Representar el modelo de entidades y relaciones.
353
Mantenimiento
Mantenibilidad
Modelo de reingeniera del software
Reestructuracin de cdigo
Los sistemas que tras un anlisis de inventario quedan como candidatos a una reestructuracin de
cdigo suelen presentar una arquitectura de programa relativamente slida, pero presentan
mdulos individuales que por haber sufrido modificaciones poco ortodoxas, o por las razones que
sean presentan un cdigo sucio de difcil comprensin, comprobacin y mantenibilidad.
Reestructuracin de datos
Las deficiencias en las estructuras de datos son una de las principales causas de errores.
Es necesario realizar reestructuracin (rediseo y posterior migracin de la informacin al nuevo
diseo) en las bases de datos que por no tener un diseo normalizado, o sin integridad relacional
presentan un riesgo de error cuyo impacto aconseje su reestructuracin.
La reestructuracin de datos suele implicar tambin modificaciones de cdigo.
Ensame tu cdigo y mantn ocultas tus estructuras de datos, y me seguirs engaando.
Mustrame tus estructuras de datos y normalmente no necesitar que me ensees tu cdigo:
resultar evidente
Fred Brooks
354
Mantenimiento
Mantenibilidad
Modelo de reingeniera del software
Ingeniera progresiva
Por el estado actual de las herramientas CASE se trata de un modelo ideal de proceso, ms que de
un proceso que se pueda aplicar directamente.
Su objetivo es ejecutar ingeniera inversa y reestructuracin de cdigo de forma automtica a
travs de herramientas CASE que analicen el cdigo y generen su diseo, as como su
reestructuracin.
355
Gestin de la configuracin
1.0
356
Gestin de la configuracin
Introduccin
El problema
Entorno de desarrollo de un sistema de software de tamao medio:
Equipo de 10 programadores.
75 mdulos de programa.
Media de dos versiones de cada mdulo.
Documentacin del proyecto: descripcin del sistema, SRS, plan
de proyecto, anlisis, etc.
Cada programador modifica un mdulo cada da.
Modificaciones de requisitos
Varios programadores deben trabajar de forma concurrente
sobre el mismo mdulo.
Etc.
Consecuencias
357
Gestin de la configuracin
Definicin
Gestin de la configuracin del software es una disciplina formal de la ingeniera del software
que proporciona mtodos y herramientas para identificar y controlar el software durante su
desarrollo y posterior uso.
Comprende las siguientes actividades:[1]
Identificacin y establecimiento de las lneas base.
Revisin, aprobacin o rechazo, control y seguimiento de los cambios.
Auditoras y revisiones de la evolucin de los productos de software.
Control de la relacin del sistema de software en su interfaz de operacin.
Temporal
Entorno
Sistema
Desarrollo
Mantenimiento
Ciclo de vida
[1] En la exposicin del captulo se abordan con detalle cada una de ellas.
358
Gestin de la configuracin
Conceptos clave
Lnea base
Peticin de
cambio
Comit de
control de la
configuracin
359
Librera
Elementos de
configuracin
del software
Gestin de la configuracin
Conceptos clave
Lnea base
Especificacin de un producto que ha sido formalmente revisada y aceptada para servir como
punto de referencia para su posterior desarrollo, y slo puede modificarse a travs de un
procedimiento formal de control de cambio.
El nmero y tipo de lneas base de un proyecto puede ser diferente en funcin de las
caractersticas y modelo de ciclo de vida del mismo, pero las habituales son:
360
Gestin de la configuracin
Conceptos clave
Elemento de configuracin del software
Un elemento de configuracin del software (SWCI) es un conjunto de
productos de trabajo documentados que se han producido en los
procesos del ciclo de vida, o que se emplean en los mismos.
Por producto de trabajo se entiende a un elemento tangible que es el
resultado de determinadas actividades o tareas de desarrollo: planes de
pruebas, documentos de requisitos, documentos de diseo, cdigo, manuales
de usuario, etc.
Los elementos de configuracin del software son cualquier parte del desarrollo o del producto
entregable y necesitan poder identificarse, almacenarse, cambiarse, revisarse o mantenerse de
forma independiente.
Estos elementos no comprende slo los productos de software que se entregan al cliente, tambin
incluyen los elementos que son necesarios para crear esos productos.
Categoras
361
Gestin de la configuracin
Conceptos clave
Peticin de cambio
Las peticiones de cambio documentan la necesidad de modificar un elemento de
configuracin del software.
Las peticiones de cambio deben incluir:
Razn por la que hay que realizar el cambio (deteccin de un fallo,
modificacin de requisitos, etc.)
Elemento de configuracin afectado y lnea base a la que pertenece.
Urgencia del cambio.
Persona que lo solicita e indicacin de si el origen es interno o externo.
362
Gestin de la configuracin
Conceptos clave
Comit de control de la configuracin
Para conseguir que las peticiones de cambio se procesen de forma ordenada,
correcta y a tiempo, el proyecto debe establecer quin o quienes configuran el
comit de control de la configuracin.
En funcin del tamao y caractersticas del proyecto puede ser que lo forme una
sola persona (p. ej. el analista o el gestor del proyecto), o que est formado por
varias: gestor de proyecto, cliente, gestor de calidad, etc.
Las funciones del comit incluyen:
Sopesar las ventajas e inconveniente de la introduccin del cambio (beneficios esperados,
coste de la implementacin)
Evaluar el impacto de la modificacin sobre los parmetros del proyecto (agenda, costes,
riesgos, etc.).
El comit no slo decide si debe realizarse el cambio, tambin determina su prioridad, cundo y
cmo debe llevarse a cabo y cmo deber comprobarse y verificarse su implementacin.
363
Gestin de la configuracin
Conceptos clave
Libreras
Las libreras constituyen los dispositivos de almacenamiento necesarios para
llevar a cabo los cambios y el control histrico de los mismos que requiere la
gestin de la configuracin, de forma que queden guardadas y puedan
recuperarse las diferentes lneas base en cualquiera de sus versiones.
El nmero y tipo de libreras puede variar en funcin de las caractersticas del
proyecto, pero generalmente son 3:
364
Librera dinmica
Es el entorno de almacenamiento usado y gestionado por el equipo de programacin en el que se
ubican los elementos con los que estn trabajando.
Librera controlada
Es la librera empleada para guardar las lneas base y controlar los cambios que sobre ellas se
realizan. Los elementos se almacenan en esta librera despus de haber sido identificados como
elementos de configuracin asignados a su lnea base, documentados y aceptados por el comit
de gestin de la configuracin.
Librera esttica
Tambin llamada repositorio de software. Guarda las lneas base una vez que han sido validadas y
verificadas para su distribucin y uso final.
Gestin de la configuracin
Conceptos clave
Libreras
LIBRERA DINMICA
Tambin llamada Directorio de programacin.
Controlada por el equipo de programacin.
LIBRERA CONTROLADA
Tambin llamado Directorio maestro.
Contiene todas las lneas base del proyecto.
LIBRERA ESTTICA
Tambin llamado Repositorio de software
Comprende las lneas base que finalmente se entregan.
Versin 1.0
365
Versin 1.1
Gestin de la configuracin
reas clave
Gestin de la configuracin
del software
Identificacin de
la configuracin
366
Control de la
configuracin
Medicin del
estado de la
configuracin
Auditoras y
revisiones
Control de las
relaciones de
interfaz
Gestin de la configuracin
reas clave
Identificacin de la configuracin
367
367
Identificacin
Seleccin
Revisin
tcnica y
formal
Lneas base
Nomenclatura y
adquisicin
Actividades
Adquisicin: Una vez identificado cada elemento, debe incorporarse a su respectiva librera.
Gestin de la configuracin
reas clave
Control de la configuracin
Comprende la gestin de las revisiones y de los procesos de aprobacin, para
evitar que se produzcan cambios de forma descontrolada.
Garantiza
Que
Que
Que
Que
Identificacin
del cambio
Comunicacin
formal
Validacin
y evaluacin
368
Aprobacin
o rechazo
Por urgencia
Por Naturaleza (error, mejora, mod. Requisitos)
Por categora de elementos modificados (producto,
Software adquirido, Software suministrado, software
de pruebas o software de apoyo).
Implementacin
EVALUACIN
Tcnico
En los interfaces de configuracin
En la agenda
En el presupuesto
Gestin de la configuracin
reas clave
Medicin del estado de la configuracin
Medicin y registro de los cambios, contenidos e histricos de la gestin de la
configuracin
Registra
Auditoras y revisiones
Con menor o mayor rigor, segn se trate de revisiones o auditoras, estos
procesos tambin se deben aplicar sobre la gestin de la configuracin para
garantizar:
369
Gestin de la configuracin
reas clave
Control de las relaciones de interfaz
El desarrollo y mantenimiento de sistemas de software no suele ser autocontenido. Normalmente el software debe relacionarse con hardware y con otro
software. El control de las relaciones de Interfaz contempla y gestiona las
situaciones posibles:
SITUACIONES
La gestin de la configuracin
debe registrar tambin las
plataformas y componentes
externos, evaluando las posibles
evoluciones y cambios.
370
IMPLICCIONES DE INTERFAZ
Gestin de la configuracin
Control de versiones
Evolucin simple
Variantes
4.1
Tronco: 1.1 1.2 1.3
2.1
2.2
2.3
1.2
1.3
3.1
371
1.4
3.2
Gestin de la configuracin
Control de versiones
Propagacin de cambios
Cambio aplicable a varias ramas
3.1
2.1
2.2
3.2
2.3
3.3
2.4
2.4 = 2.3 + (1.5 1.4)
1.2
1.3
1.4
1.5
372
Gestin de la configuracin
Control de versiones
Fusin de ramas
3.1
2.1
1.2
2.2
1.3
3.2
2.3
1.4
4.1
1.5
4.2
373
Gestin de la configuracin
Control de versiones
Tcnicas de almacenamiento
DELTAS DIRECTOS
Inicial
1.0
1.1
cambios
cambios
1.2
cambios
1.3
2.1
cambios
cambios
1.4
cambios
1.5
1.5
Final
1.5
2.2
DELTAS INVERSOS
1.1
cambios
1.2
cambios
cambios
374
1.3
2.1
cambios
cambios
1.4
2.2
cambios
Gestin de la configuracin
Control de versiones
Tcnicas de almacenamiento
MARCADO SELECTIVO
>>
<< 1.3
>>
AGILIDAD
Entrega temprana
Incremento continuo
cc-by fox_kiyo
376
espublico.com
2000
377
safecreative.org
2007
Web Mail
Tienda virtual (libros e informtica)
Legislacin
Jurisprudencia
Subvenciones
Modelos de expedientes
Formacin Aula virtual
Noticias
Revista - entrevistas
Foros
Encuestas
Preguntas frecuentes
Consultas
378
A tiempo
379
En costes
Lo previsto
Time to market
380
1 ao
Desperdicio: 80%
381
INCERTIDUMBRE
382
VELOCIDAD
383
Fotografa cc-by:Amnemona
2.007
Time to market
384
2.008
2 meses
2.009
2.011
Desperdicio: 20%
385
Web Mail
Tienda virtual (libros e informtica)
Legislacin
Jurisprudencia
Subvenciones
Modelos de expedientes
Formacin Aula virtual
Noticias
Revista - entrevistas
Foros
Encuestas
Preguntas frecuentes
Consultas
386
?
387
Valor
Visin
Tiempo
Objetivo:
En la fecha prevista
Versin 1.0
388
Valor
Visin
Tiempo
389
Valor
Versin
390
Tiempo
Valor
Versin
391
Tiempo
Valor
Versin
392
Tiempo
Valor
Versin
393
Tiempo
Valor
Tiempo
Se anticipa la presencia en el mercado.
Las previsiones inversin / ROI se suavizan.
Se mantiene la ventaja innovadora del producto en un mercado en
movimiento.
394
2.007
2.008
2.009
AGILIDAD
2.011
Valor temprano
Time to market
2 meses
Incremento continuo y
frecuente
395
Desperdicio: 20%
1959
MIL-Q 9858
1979
BS 5750
1997
TickIT
1991
ISO 9000-3
Trillium
1987
ISO 9000
Modelos
especficos
para software.
PROCESOS
Modelos genricos
Bootstrap
1995
ISO 12207
1995
Proy. SPICE
TR 15504
2003-05
ISO 15504
1993
CMM-SW
Modelos
CMM
2001
CMMI
DSDM
AGILIDAD
SCRUM
CRYSTAL
XP
ASD
PP
ISD
AM
1995
396
2000
Manifiesto gil
AGILIDAD
MANIFIESTO GIL
Marzo - 2001
www.agilemanifesto.org
397
AGILIDAD
MANIFIESTO GIL
VALOR
PERSONAS Y
SU INTERACCIN
Cc by Santi Siri
HERRAMIENTAS
Y PROCESOS
Cc by Tech Writer Boy
398
AGILIDAD
MANIFIESTO GIL
VALOR
SOFTWARE QUE
FUNCIONA
Cc by Thor
DOCUMENTACIN
EXHAUSTIVA
Cc by Joe Hall
399
AGILIDAD
MANIFIESTO GIL
VALOR
COLABORACIN
CON CLIENTE
Cc by Karsten Konrad
NEGOCIACIN
CONTRACTUAL
Cc by Kate Bingaman
400
AGILIDAD
MANIFIESTO GIL
VALOR
RESPUESTA
AL CAMBIO
Cc by Jonny Hunter
SEGUIMIENTO
DE UN PLAN
Cc by J.P. Dalbra
401
AGILIDAD
Los 12 principios del manifiesto gil
AGILIDAD
Los 12 principios del manifiesto gil
403
AGILIDAD
Los 12 principios del manifiesto gil
AGILIDAD
Los 12 principios del manifiesto gil
AGILIDAD
Los 12 principios del manifiesto gil
406
AGILIDAD
Los 12 principios del manifiesto gil
AGILIDAD
Prctica
cc-by: LizMarie
408
AGILIDAD
Prctica
15.- Minutos
En grupos
AGILIDAD
Ciclo de desarrollo gil
1.- Concepto
410
AGILIDAD
Ciclo de desarrollo gil
2.- Especulacin
411
AGILIDAD
Ciclo de desarrollo gil
3.- Exploracin
412
Desarrollo de un incremento
AGILIDAD
Ciclo de desarrollo gil
4.- Revisin
413
Entrega y retro-informacin
AGILIDAD
Ciclo de desarrollo gil
5.- Cierre
414
Producto final
AGILIDAD
Ciclo de desarrollo gil
Concepto
Cierre
Especulacin
Iteraciones
Revisin
415
Exploracin
AGILIDAD
MANIFIESTO GIL
1950
1960
1970
1980
1990
1990
AGILIDAD
PROCESOS
416
2000
AGILIDAD
ANTTESIS A LOS MODELOS DE PROCESOS: AGILIDAD
Adaptaciones
para softw.
1959
MIL-Q 9858
1979
BS 5750
1997
TickIT
1991
ISO 9000-3
Trillium
1987
ISO 9000
Modelos
especficos
para software.
PROCESOS
Modelos genricos
Bootstrap
1995
ISO 12207
1995
Proy. SPICE
TR 15504
2003-05
ISO 15504
1993
CMM-SW
Modelos
CMM
2001
CMMI
DSDM
AGILIDAD
SCRUM
CRYSTAL
XP
ASD
PP
ISD
AM
1995
417
2000
Manifiesto gil
AGILIDAD
EVOLUCIN DEL CONOCIMIENTO
1950
1960
Crisis del
software
418
1970
1980
1990
2000
2010
AGILIDAD
EVOLUCIN DEL CONOCIMIENTO
1950
1960
1970
1980
Crisis del
software
TESIS
ISO 9001
ISO 9000-3
CMM
CMMI
SPICE
419
1990
2000
2010
AGILIDAD
EVOLUCIN DEL CONOCIMIENTO
1950
1960
1970
1980
1990
2000
Crisis del
software
TESIS
ANTTESIS
ISO 9001
ISO 9000-3
CMM
CMMI
SPICE
420
XP
TDD - FDD
Scrum
Crystal
2010
AGILIDAD
EVOLUCIN DEL CONOCIMIENTO
1950
1960
1970
1980
1990
2000
2010
Crisis del
software
TESIS
ANTTESIS
ISO 9001
ISO 9000-3
CMM
CMMI
SPICE
421
SNTESIS
XP
TDD - FDD
Scrum
Crystal
AGILIDAD
EVOLUCIN DEL CONOCIMIENTO
Tesis1
Espiral del conocimiento. Hirotaka Takeuchi, Ikujiro Nonaka, Hitotsubashi on Knowledge Management, 2004
422
AGILIDAD
EVOLUCIN DEL CONOCIMIENTO
Tesis1
Anttesis1
Espiral del conocimiento. Hirotaka Takeuchi, Ikujiro Nonaka, Hitotsubashi on Knowledge Management, 2004
423
AGILIDAD
EVOLUCIN DEL CONOCIMIENTO
Sntesis1
Tesis1
Anttesis1
Espiral del conocimiento. Hirotaka Takeuchi, Ikujiro Nonaka, Hitotsubashi on Knowledge Management, 2004
424
AGILIDAD
EVOLUCIN DEL CONOCIMIENTO
Sntesis1
T2
Tesis1
A2
Anttesis1
Espiral del conocimiento. Hirotaka Takeuchi, Ikujiro Nonaka, Hitotsubashi on Knowledge Management, 2004
425
T
A
S
TESIS
ANTTESIS
SNTESIS
AGILIDAD
EVOLUCIN DEL CONOCIMIENTO
S3
T4
S2
Sntesis1
T2
Tesis1
T3
A3
A2
Anttesis1
Espiral del conocimiento. Hirotaka Takeuchi, Ikujiro Nonaka, Hitotsubashi on Knowledge Management, 2004
426
T
A
S
TESIS
ANTTESIS
SNTESIS
AGILIDAD
EVOLUCIN DEL CONOCIMIENTO
S3
T4
S2
Sntesis1
T2
Tesis1
T3
A3
A2
Anttesis1
Espiral del conocimiento. Hirotaka Takeuchi, Ikujiro Nonaka, Hitotsubashi on Knowledge Management, 2004
427
T
A
S
TESIS
ANTTESIS
SNTESIS
AGILIDAD
Adaptaciones
para softw.
1959
MIL-Q 9858
1979
BS 5750
1997
TickIT
1991
ISO 9000-3
TESIS
Trillium
1987
ISO 9000
Modelos
especficos
para software.
PROCESOS
Bootstrap
1995
ISO 12207
1995
Proy. SPICE
TR 15504
2003-05
ISO 15504
1993
CMM-SW
Modelos
CMM
2001
CMMI
DSDM
AGILIDAD
SCRUM
ANTTESIS
CRYSTAL
XP
ASD
PP
ISD
AM
1995
428
2000
Manifiesto gil
(Conocimiento)
429
Conocimiento
Procesos y previsin / Agilidad y cambio continuo?
430
Conocimiento
Un parntesis sobre el conocimiento
431
Conocimiento
Conocimiento para realizar un trabajo:
Tcito
Explcito
Conocimiento
Los elementos de produccin
PERSONAS
Tcito
Explcito
PROCESOS
433
TECNOLOGA
Conocimiento
TESIS: Responsabilidad del resultado
PERSONAS
PROCESOS
434
TECNOLOGA
Conocimiento
Anttesis: responsabilidad del resultado
PERSONAS
PROCESOS
435
TECNOLOGA
Conocimiento
Visin de sntesis: Procesos = PROCEDIMIENTOS
PERSONAS
PROCEDIMIENTOS
Procesos
Rutinas
436
TECNOLOGA
Conocimiento
Visin de sntesis: PERSONAS
Trabajo
PERSONAS
Conocimiento
PROCESOS
437
TECNOLOGA
Conocimiento
Prctica: conocimiento tcito y explcito
cc-by: LizMarie
438
Conocimiento
sobre el conocimiento )
439
440
PLANIFICACIN
441
ADAPTACIN
Clsica
Tradicional
Predictiva
formal
Pesada
Gestin de proyectos
gil
Adaptable
Evolutiva
Adaptativa
442
Caractersticas y comportamientos
regulares
443
OBJETIVO
A tiempo
444
En costes
Lo previsto
UNIVERSALIDAD
PREVISIN
445
446
EVOLUTIVA
Definicin
Visin
Diseo
Exploracin
Construccin
Adaptacin
447
EVOLUTIVA
CRITERIOS DE IDONEIDAD
EVOLUTIVA
Valor
Cumplimiento
Entorno inestable
Entorno estable
Modificable
Difcil de modificar
COSTE DE PROTOTIPADO
Bajo
Alto
Baja
Alta
Pequeo
Grande
PRIORIDAD DE NEGOCIO
ESTABILIDAD DE REQUISITOS
PREDICTIVA
449
450
EL CLIENTE
LA ORGANIZACIN
EL PROYECTO
451
ESTRATEGIA
DE DESARROLLO
NIVEL
PROFESIONAL
MALEABILIDAD
CULTURA
ORGANIZACIN
CRITICIDAD
TAMAO DEL EQUIPO
452
453
454
455
(Materia prima)
456
COSTE / BENEFICIO
PROTOTIPADO
NO REHACER - PLANIFICAR
457
PROBAR Y EXPLORAR
458
459
460
461
462
CARACTERSTICAS DE LA ORGANIZACIN
EVOLUTIVA
Senior
Junior
CULTURA ORGANIZATIVA
Horizontal, flexible
Vertical, rgida
MODELO DE DESARROLLO
Personas
Procesos
NIVEL PROFESIONAL
463
PREDICTIVA
EVOLUTIVA
Valor
Cumplimiento
Entorno inestable
Entorno estable
Modificable
Difcil de modificar
COSTE DE PROTOTIPADO
Bajo
Alto
Baja
Alta
Pequeo
Grande
PRIORIDAD DE NEGOCIO
ESTABILIDAD DE REQUISITOS
PREDICTIVA
Scrum
465
Scrum
El origen de Scrum
Fases
466
Scrum: el marco
Roles, componentes y reuniones
Exposicin de prioridades
Resolucin de dudas
PP
PP
SM
COMPONENTES
PRODUCT
BACKLOG
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
INC
SM PP
REUNIONES
PLANIFICACIN
DEL SPRINT
DIARIA
REVISIN DEL
SPRINT
467
( )
PP
SM
Scrum: el marco
Roles: comprometidos e implicados
468
Scrum: el marco
Roles: comprometidos e implicados
IMPLICADOS
Usuarios, Marketing,
Comercial, Cliente,
Direccin
COMPROMETIDOS
Propietario de
producto
469
Equipo
Scrum: el marco
Roles: comprometidos e implicados
Propietario
producto
Equipo
Interesados
Scrum
Manager
470
Auto-organizado
Multifuncional
Retro-informacin
Asesora
Garanta de funcionamiento
del modelo
Scrum: el marco
Implantaciones flexibles
Direccin
LA ASIGNACIN DE
RESPONSABILIDADES
RR.HH.
Calidad
SE ADAPTA A LA
ORGANIZACIN
Oficina proyectos
Comercial
Programacin
471
Scrum: el marco
Roles
472
Scrum: el marco
Roles
Equipo
Responsable de transformar la
pila de la iteracin en un
incremento de la funcionalidad
del software
Auto-gestionado
Auto-organizado
Multifuncional
473
Scrum: el marco
Roles
Interesados
Cliente, usuarios, marketing,
comercial, direccin
Retro-informacin
Asesora, sugerencias
Colaboracin
474
Scrum: el marco
Roles
Scrum Master
Como rol
Marco de scrum estndar o acadmico
Recomendable en organizaciones y equipos
que comienzan a trabajar con scrum.
Como responsabilidad
En implantaciones flexibles o avanzadas de
Scrm
Recomendable en organizaciones y equipos
conocedores y experimentados con scrum
475
Scrum: el marco
Roles
Scrum Master
Formador y entrenamiento del proceso
Introduccin de Scrum en la cultura de la
empresa
Garanta de cumplimiento de roles y
formas del modelo
Coaching de las personas
476
Scrum: el marco
Roles
Scrum: el marco
Componentes
Product
Backlog
Sprint
Backlog
Incremento
478
Scrum: el marco
Reuniones
Planificacin
del sprint
Diaria
Revisin del
sprint
479
Scrum: el marco
Prctica: Simulacin de un ciclo scrum
cc-by: LizMarie
480
Scrum: el marco
Prctica
Product Backlog
Funcionalidades priorizadas
481
Scrum: el marco
Prctica
Scrum: el marco
Pila de producto
(product backlog)
(1) Idealmente. En realidad, todo lo que represente trabajo para desarrollar el producto
483
Scrum: el marco
Requisitos con gestin predictiva y evolutiva
Predictivo
Evolutivo
SISTEMA
Requisitos del sistema
ConOps
ISO/IEC 12207
IEEE 1362
SOFTWARE
SRS
IEEE 830
484
Scrum: el marco
Requisitos con gestin predictiva y evolutiva
485
Scrum: el marco
Ejercicio
Product Backlog
Funcionalidades priorizadas
Funcionalidades estimadas
486
Scrum: el marco
Ejercicio
Product Backlog
Caractersticas del product backlog
Funcionalidades priorizadas
Estimadas
Documento vivo
Se trata de determinar
Cmo de valiosa o urgente es cada funcionalidad
Cmo de costosa es cada funcionalidad
Scrum: el marco
Ejercicio
488
Scrum: el marco
Ejercicio
489
Scrum: el marco
Ejercicio
Sprint
1.- Revisin individual de la(s) tareas con las que est cada uno
2.- Estimacin del trabajo pendiente
3.- Dibujo del grfico de avance (Burn Down)
490
Scrum: el marco
Ejercicio
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Esfuerzo pendiente
Sprint
Seguimiento diario
Scrum: el marco
PRIORIDAD
PRODUCT
BACKLOG
FUNCIONALIDADES
Ciclo de
trabajo
Sprint
(xx das)
SPRINT
BACKLOG
492
INCREMENTO
Scrum: el marco
Pila de producto
Ejemplo de formato
Id
493
Prioridad
Descripcin
Est.
Por
Muy alta
Plataforma tecnolgica
30
AR
Muy alta
Interfaz usuario
40
LR
Muy alta
40
LR
Alta
60
AR
Alta
Etc
999
XX
Scrum: el marco
Pila de producto
Ejemplo de formato
Id
494
Prioridad
Mdulo
Descripcin
Est.
Por
Muy alta
Plataforma tecnolgica
30
JM
Muy alta
Interfaz de usuario
40
LR
Muy alta
40
LR
Alta
Trastienda
60
JM
Alta
Trastienda
Etc
999.
XX
Scrum: el marco
Pila de producto
Ejemplo de formato
495
Criterio validacin
Id
Orden
Est.
Descripcin
Obs.
10
30
Plataforma tecnolgica
20
40
30
40
Diseo de datos
40
60
50
999.
Etc
Etc
Scrum: el marco
Pila de producto
Ejemplo de formato
Id
Mdulo
Descripcin
Est.
Por
Crtico
1
Plataforma tecnolgica
30
AR
Cliente
Interfaz de usuario
40
LR
Cliente
40
LR
Trastienda
60
AR
Trastienda
Etc
999.
XX
Necesario
496
Cliente
30
AR
Cliente
15
LR
Cliente
35
LR
Scrum: el marco
Pila de producto
IMPRESCINDIBLE
SEGN PROYECTO
Id
Obs.
Orden / prioridad
Asignado
Descripcin
N Sprint
Criterio validacin
Etc.
Estimacin
497
Scrum: el marco
Pila del sprint
498
Scrum: el marco
Pila del sprint
499
Scrum: el marco
Incremento
Entregable
Terminada!
Implementada
500
Probada
Documentada
Scrum: el marco
Pila del sprint
Incremento
Parte del producto desarrollada en un
sprint
En condiciones de ser usada
Es una funcionalidad
501
Scrum: el marco
Las reuniones
SEGUIMIENTO
DEL SPRINT
Ciclo de
trabajo
PLANIFICACIN
DEL SPRINT
REVISIN
DEL SPRINT
Sprint
(15 30 das)
Incremento
502
Scrum: el marco
Planificacin del sprint
ANTES DE EMPEZAR
Estn determinados los recursos posibles
Hay un product backlog (lista de producto) preparado y
vlido
Propietario del producto y equipo trabajan juntos
El equipo conoce las tecnologas empleadas y el negocio del
producto
503
Scrum: el marco
Planificacin del sprint
PRODUCT BACKLOG
PRODUCTO DESARROLLADO
INFORMACIN ENTORNO
OBJETIVO
DEL
SPRINT
504
SPRINT
BACKLOG
PLAN DEL
SPRINT
Scrum: el marco
Planificacin del sprint
Mximo: 1 da
Exposicin
Product backlog
505
Resolucin
Sprint backlog
Scrum: el marco
Seguimiento del sprint
(stand up)
Scrum: el marco
Revisin del sprint
PRESENTACIN DEL EQUIPO AL PROPIETARIO DEL PRODUCTO
Y TODOS LOS IMPLICADOS (GALLINAS) DEL INCREMENTO
REALIZADO EN EL SPRINT
507
POWERPOINTS
No es un acontecimiento social. NO DEBE REQUERIR
NINGUNA PREPARACIN ESPECIAL
Objetivos:
Comprobar el trabajo realizado
Retro-informacin para la evolucin del Product
Backlog
No es una reunin para valoraciones y crticas.
Scrum: mtricas
Mtricas: fondos de escala
ORGANIZACIN
DESARROLLO
Rendimiento
Esfuerzo
Densidad de fallos
Satisfaccin
clientes
Coste
Complejidad de diseo
Tamao
Disponibilidad
Eficiencia
Desempeo
508
PROYECTO
Scrum: mtricas
Mtricas: fondos de escala
ORGANIZACIN
DESARROLLO
Rendimiento
Esfuerzo
Densidad de fallos
Satisfaccin
clientes
Coste
Complejidad de diseo
Tamao
Disponibilidad
Eficiencia
Desempeo
509
PROYECTO
Scrum: mtricas
Mtrica ?
VALOR APORTADO
510
Scrum: mtricas
Magnitudes: velocidad trabajo - tiempo
511
Scrum: mtricas
Unidades de tiempo
Tiempo real
Sprint
512
Scrum: mtricas
Unidades de trabajo
Scrum: mtricas
Unidades de trabajo: tiempo ideal
Tiempo ideal
Cunto cuesta programar el
registro de un nuevo usuario?
?
514
En tiempo ideal, o
en tiempo real?
Scrum: mtricas
Unidades de trabajo: tiempo ideal
Fotografa cc-by: SD
Dirk
Scrum: mtricas
Unidades de trabajo: tiempo ideal
Tiempo ideal
Sin interrupciones
516
Scrum: mtricas
Unidades de trabajo: tiempo ideal
Puntos
Cantidad de trabajo considerando:
Dificultad
Tamao
Unidad relativa
Unidad propia del equipo / organizacin
517
Scrum: mtricas
Unidades de trabajo: tiempo ideal
cc-by: LizMarie
518
Scrum: mtricas
Estimacin de pquer: serie natural
0
0 1 2 3 5
2
1
?
6 7 ?
?
6
519
Scrum: mtricas
Estimacin de pquer: serie Fibonacci
0
0 1 2 3 5
2
8 13 21 ?
?
21
13
8
520
21
13
Scrum: mtricas
Prctica de estimacin de pquer
cc-by: LizMarie
521
Scrum: mtricas
Medicin del trabajo
522
Scrum: mtricas
Medicin del trabajo
Para estimar
esfuerzo y
duracin de las
tareas
200
523
7-feb
6-feb
3-feb
1-feb
50
Seguir el
avance del
proyecto
2-feb
100
8-feb
150
Scrum: mtricas
Se puede estimar con precisin?
?
Los requisitos no son realidades de solucin nica
La capacidad y calidad de cada persona es diferente
Los entornos de trabajo influyen en la productividad
524
Scrum: mtricas
Estrategia de la estimacin gil
PRECISIN RELATIVA
JUICIO DE EXPERTOS
525
Scrum: mtricas
Unidades giles
Velocidad
Trabajo
Por
Sprint
Fotografa cc-by: fdecomite
526
(Scrum acadmico)
Scrum: mtricas
Unidades giles
Velocidad
Trabajo por
unidad de
tiempo
Fotografa cc-by: Luis
Argerich
527
(Scrum flexible)
Scrum: prcticas
Product Backlog
Id
528
Historias
Trabajo
Criterio de validacin
Historia A 1.0
150
Historia B 1.0
250
Historia C 1.0
250
Historia D 1.0
300
Pellentesque turpis
Historia A 1.1
250
Historia D 1.1
350
Historia E 1.0
150
Historia B 1.1
500
Historia C 1.1
150
10
Historia E 1.1
200
11
Historia F 1.0
TBD
12
Historia A.1.2
TBD
13
Historia B 1.2
TBD
14
Historia F 1.1
TBD
Scrum: prcticas
Plan de producto: Grfico burn-up
Id
Historias
Trabajo
Criterio de validacin
Historia A 1.0
150
Historia B 1.0
250
Historia C 1.0
250
Historia D 1.0
300
Pellentesque turpis
Historia A 1.1
250
Historia D 1.1
350
Historia E 1.0
150
Historia B 1.1
500
Historia C 1.1
150
10
Historia E 1.1
200
11
Historia F 1.0
TBD
12
Historia A.1.2
TBD
13
Historia B 1.2
TBD
14
Historia F 1.1
TBD
529
Estimacin:
950 PUNTOS
Versin 1.0
1.700 PUNTOS
Versin 1.1
Versin 1.2
Scrum: prcticas
Plan de producto: Grfico burn-up
Equipo
Sprints
530
Sprint
Versin 1.2
Versin 1.1
4 personas
20 das
laborables
(1 mes)
Versin 1.0
1
2
3
4
5
6
7
8
1 - MAR 1 - ABR 1 - MAY 1 - JUN 1 - JUL 1 - AGO 1 - SEP
Scrum: prcticas
Sprints
531
1
2
3
4
5
6
7
8
1 - MAR 1 - ABR 1 - MAY 1 - JUN 1 - JUL 1 - AGO 1 - SEP
Scrum: prcticas
Sprints
532
1
2
3
4
5
6
7
8
1 - MAR 1 - ABR 1 - MAY 1 - JUN 1 - JUL 1 - AGO 1 - SEP
Scrum: prcticas
Sprints
533
1
2
3
4
5
6
7
8
1 - MAR 1 - ABR 1 - MAY 1 - JUN 1 - JUL 1 - AGO 1 - SEP
Scrum: prcticas
Sprints
534
1
2
3
4
5
6
7
8
1 - MAR 1 - ABR 1 - MAY 1 - JUN 1 - JUL 1 - AGO 1 - SEP
Scrum: prcticas
Sprints
535
Versin 1.0
1
2
3
4
5
6
7
8
1 - MAR 1 - ABR 1 - MAY 1 - JUN 1 - JUL 1 - AGO 1 - SEP
Scrum: prcticas
Sprints
536
Versin 1.0
1
2
3
4
5
6
7
8
1 - MAR 1 - ABR 1 - MAY 1 - JUN 1 - JUL 1 - AGO 1 - SEP
Scrum: prcticas
Plan de producto: Grfico burn-up
Versin 1.2
Sprints
537
Versin 1.1
Versin 1.0
1
2
3
4
5
6
7
8
1 - MAR 1 - ABR 1 - MAY 1 - JUN 1 - JUL 1 - AGO 1 - SEP
Scrum: prcticas
Evolucin del esfuerzo pendiente en la pila del sprint
A
B
538
Scrum: prcticas
(burn down)
539
18
17
16
15
14
13
12
11
10
Esfuerzo pendiente
Grfico de avance
Scrum: prcticas
Grfico de avance
(burn down)
Se cumplimenta da a da
200
150
100
540
8-feb
7-feb
6-feb
3-feb
2-feb
1-feb
50
Scrum: prcticas
Grfico de avance
(burn down)
18
17
16
15
14
13
12
11
10
Esfuerzo pendiente
Scrum: prcticas
(burn down)
Esfuerzo pendiente
542
18
17
16
15
14
13
12
11
10
Esfuerzo pendiente
Grfico de avance
Scrum: prcticas
Grfico de avance
(burn down)
543
18
17
16
15
14
13
12
11
10
Esfuerzo pendiente
Scrum: prcticas
Grfico de avance
(burn down)
544
18
17
16
15
14
13
12
11
10
Esfuerzo pendiente
Scrum: prcticas
Grfico de avance
(burn down)
545
18
17
16
15
14
13
12
11
10
Esfuerzo pendiente
Kanban
Conceptos kanban y lean engestin gil
1.0
546
SCRUM CMMI
KANBAN
XP
LEAN
PMI
TDD
SCRUMBAN
547
SCRUM
PROPIETARIO DEL
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
Exposicin de prioridades
Resolucin de dudas
PP
PROPIETARIODEL
DEL
PROPIETARIO
PRODUCTO
PRODUCTO
PP
SM
COMPONENTES
PRODUCT
BACKLOG
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
INC
SM PP
REUNIONES
PLANIFICACIN
DEL SPRINT
DIARIA
REVISIN DEL
SPRINT
548
( )
PP
SM
KANBAN
PROPIETARIO DEL
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
Exposicin de prioridades
Resolucin de dudas
PP
PROPIETARIODEL
DEL
PROPIETARIO
PRODUCTO
PRODUCTO
PP
PRODUCT
BACKLOG
Reunin diaria
SM
SM
( )
PP
COMPONENTES
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
KANBAN NO
INC
SM PP
REUNIONES
PLANIFICACIN
DEL SPRINT
DIARIA
REVISIN DEL
SPRINT
549
KANBAN
PROPIETARIO DEL
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
Exposicin de prioridades
Resolucin de dudas
PP
PROPIETARIODEL
DEL
PROPIETARIO
PRODUCTO
PRODUCTO
PP
PRODUCT
BACKLOG
PDP
Reunin diaria
SM
SM
( )
PP
COMPONENTES
SPRINT
BACKLOG
PDS
INCREMENTO
INC
REUNIONES
PLANIFICACIN
DEL SPRINT
DIARIA
REVISIN DEL
SPRINT
550
KANBAN
PROPIETARIO DEL
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
Exposicin de prioridades
Resolucin de dudas
PP
PROPIETARIODEL
DEL
PROPIETARIO
PRODUCTO
PRODUCTO
PP
PRODUCT
BACKLOG
Reunin diaria
SM
SM
( )
PP
COMPONENTES
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
INC
REUNIONES
PLANIFICACIN
DEL SPRINT
DIARIA
REVISIN DEL
SPRINT
551
KANBAN
PROPIETARIO DEL
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
Exposicin de prioridades
Resolucin de dudas
PP
PROPIETARIODEL
DEL
PROPIETARIO
PRODUCTO
PRODUCTO
PP
PRODUCT
BACKLOG
PDP
Reunin diaria
SM
SM
( )
PP
COMPONENTES
SPRINT
BACKLOG
PDS
INCREMENTO
INC
REUNIONES
PLANIFICACIN
DEL SPRINT
DIARIA
REVISIN DEL
SPRINT
552
KANBAN
PROPIETARIO DEL
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
Exposicin de prioridades
Resolucin de dudas
PP
PROPIETARIODEL
DEL
PROPIETARIO
PRODUCTO
PRODUCTO
PP
PRODUCT
BACKLOG
PDP
Reunin diaria
SM
SM
( )
PP
COMPONENTES
SPRINT
BACKLOG
PDS
INCREMENTO
INC
REUNIONES
PLANIFICACIN
DEL SPRINT
DIARIA
REVISIN DEL
SPRINT
553
KANBAN
PROPIETARIO DEL
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
Exposicin de prioridades
Resolucin de dudas
PP
PROPIETARIODEL
DEL
PROPIETARIO
PRODUCTO
PRODUCTO
PP
PRODUCT
BACKLOG
PDP
Reunin diaria
SM
SM
( )
PP
COMPONENTES
SPRINT
BACKLOG
PDS
INCREMENTO
INC
REUNIONES
PLANIFICACIN
DEL SPRINT
DIARIA
REVISIN DEL
SPRINT
554
KANBAN
PROPIETARIO DEL
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
Exposicin de prioridades
Resolucin de dudas
PP
PROPIETARIODEL
DEL
PROPIETARIO
PRODUCTO
PRODUCTO
PP
PRODUCT
BACKLOG
PDP
Reunin diaria
SM
SM
( )
PP
COMPONENTES
SPRINT
BACKLOG
PDS
INCREMENTO
INC
REUNIONES
PLANIFICACIN
DEL SPRINT
DIARIA
REVISIN DEL
SPRINT
555
KANBAN
PROPIETARIO DEL
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
Exposicin de prioridades
Resolucin de dudas
PP
PROPIETARIODEL
DEL
PROPIETARIO
PRODUCTO
PRODUCTO
PP
PRODUCT
BACKLOG
PDP
Reunin diaria
SM
SM
( )
PP
COMPONENTES
SPRINT
BACKLOG
PDS
INCREMENTO
INC
REUNIONES
PLANIFICACIN
DEL SPRINT
DIARIA
REVISIN DEL
SPRINT
556
KANBAN
PROPIETARIO DEL
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
Exposicin de prioridades
Resolucin de dudas
PP
PROPIETARIODEL
DEL
PROPIETARIO
PRODUCTO
PRODUCTO
PP
PRODUCT
BACKLOG
Reunin diaria
SM
SM
( )
PP
COMPONENTES
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
KANBAN NO
INC
SM PP
REUNIONES
PLANIFICACIN
DEL SPRINT
DIARIA
REVISIN DEL
SPRINT
557
KANBAN
PROPIETARIO DEL
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
Exposicin de prioridades
Resolucin de dudas
PP
PROPIETARIODEL
DEL
PROPIETARIO
PRODUCTO
PRODUCTO
PP
PRODUCT
BACKLOG
Reunin diaria
SM
SM
( )
PP
COMPONENTES
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
KANBAN NO
INC
SM PP
REUNIONES
PLANIFICACIN
DEL SPRINT
DIARIA
REVISIN DEL
SPRINT
558
KANBAN
PROPIETARIO DEL
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
Exposicin de prioridades
Resolucin de dudas
PP
PROPIETARIODEL
DEL
PROPIETARIO
PRODUCTO
PRODUCTO
PP
PRODUCT
BACKLOG
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
INC
Reunin diaria
SM
SM
( )
PP
COMPONENTES
SM PP
REUNIONES
PLANIFICACIN
DEL SPRINT
DIARIA
REVISIN DEL
SPRINT
559
KANBAN
PROPIETARIO DEL
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
Exposicin de prioridades
Resolucin de dudas
PP
PROPIETARIODEL
DEL
PROPIETARIO
PRODUCTO
PRODUCTO
PP
PRODUCT
BACKLOG
PDP
Reunin diaria
SM
SM
( )
PP
COMPONENTES
SPRINT
BACKLOG
PDS
INCREMENTO
INC
REUNIONES
PLANIFICACIN
DEL SPRINT
ETC..
DIARIA
REVISIN DEL
SPRINT
560
561
SCRUM CMMI
KANBAN
XP
LEAN
PMI
TDD
SCRUMBAN
562
GESTIN
PREDICTIVA
DESARROLLO
Estrategia
Tctica
TRABAJO
CONOCIMIENTO
Prcticas
PMBOK
INGENIERA
SECUENCIAL
Completo
Plan de proyecto
Cascada
GESTIN
EVOLUTIVA
Prcticas giles
Procesos
Incremento Iterativo
AGILIDAD
Incremental
563
INGENIERA
CONCURRENTE
Incremento continuo
Fases solapadas
Personas
GESTIN
PREDICTIVA
DESARROLLO
Estrategia
Tctica
TRABAJO
CONOCIMIENTO
Prcticas
PMBOK
INGENIERA
SECUENCIAL
Completo
Plan de proyecto
Cascada
GESTIN
EVOLUTIVA
Prcticas giles
Procesos
Incremento Iterativo
AGILIDAD
Incremental
564
INGENIERA
CONCURRENTE
Incremento continuo
Fases solapadas
Personas
GESTIN
PREDICTIVA
DESARROLLO
Estrategia
Tctica
TRABAJO
CONOCIMIENTO
Prcticas
PMBOK
INGENIERA
SECUENCIAL
Completo
Plan de proyecto
Cascada
GESTIN
EVOLUTIVA
Prcticas giles
Procesos
Incremento Iterativo
AGILIDAD
Incremental
565
INGENIERA
CONCURRENTE
Incremento continuo
Fases solapadas
Personas
GESTIN
PREDICTIVA
DESARROLLO
Estrategia
Tctica
TRABAJO
CONOCIMIENTO
Prcticas
PMBOK
INGENIERA
SECUENCIAL
Completo
Plan de proyecto
Cascada
GESTIN
EVOLUTIVA
Prcticas giles
Procesos
Incremento Iterativo
AGILIDAD
Incremental
566
INGENIERA
CONCURRENTE
Incremento continuo
Fases solapadas
Personas
GESTIN
PREDICTIVA
DESARROLLO
Estrategia
Tctica
TRABAJO
CONOCIMIENTO
Prcticas
PMBOK
INGENIERA
SECUENCIAL
Completo
Plan de proyecto
Cascada
GESTIN
EVOLUTIVA
Prcticas giles
Procesos
Incremento Iterativo
AGILIDAD
Incremental
567
INGENIERA
CONCURRENTE
Incremento continuo
Fases solapadas
Personas
GESTIN
PREDICTIVA
DESARROLLO
Estrategia
Tctica
TRABAJO
CONOCIMIENTO
Prcticas
PMBOK
INGENIERA
SECUENCIAL
Completo
Plan de proyecto
Cascada
GESTIN
EVOLUTIVA
Prcticas giles
Procesos
Incremento Iterativo
AGILIDAD
Incremental
568
INGENIERA
CONCURRENTE
Incremento continuo
Fases solapadas
Personas
GESTIN
PREDICTIVA
DESARROLLO
Estrategia
Tctica
TRABAJO
CONOCIMIENTO
Prcticas
PMBOK
INGENIERA
SECUENCIAL
Completo
Plan de proyecto
Cascada
GESTIN
EVOLUTIVA
Prcticas giles
Procesos
Incremento Iterativo
AGILIDAD
Incremental
569
INGENIERA
CONCURRENTE
Incremento continuo
Fases solapadas
Personas
Artesanal
En cadena
KANBAN
Modelos de
produccin
Lean
CMMI
Informacin y gestin
visual
Tcnicas
KANBAN
ANDON
POKA YOKE
Prevencin de
errores
Herramientas polivalentes
TDD
Predictivo
Modelos de
Gestin de
proyectos
570
Evolutivo
gil
Incremento iterativo
Ingeniera
(Produccin
basada en procesos)
concurrente
Incremento continuo
(Incremento: Historia de usuario principio: flujo
lean)
571
572
PRINCIPIOS
METODOLOGAS
SCRU
M
XP
PMI
TDD
CMMISCRUMBAN
573
Experta
Principios
Conocimiento tcito
GESTIN
Tcnica
Tcnicas
Conocimiento explcito
574
DE LA ARTESANA
A LA MANUFACTURA
LEAN
1.0
575
576
USTED
EST
AQU
Kitchiro Toyoda Taichi
Ohno
Produccin: just in time,
pull y sin desperdicio
Modelo Toyota o Lean
577
En cadena
Lean
Tcnicas
Informacin y gestin
visual
Prevencin de
errores
Herramientas polivalentes
578
KANBAN
ANDON
POKA YOKE
GESTIN
PREDICTIVA
DESARROLLO
Estrategia
Tctica
TRABAJO
CONOCIMIENTO
Prcticas
PMBOK
INGENIERA
SECUENCIAL
Completo
Plan de proyecto
Cascada
GESTIN
EVOLUTIVA
Prcticas giles
Procesos
Incremento
o
Iterativo
AGILIDAD
Incremental
579
INGENIERA
CONCURRENTE
Incremento
continuo
Fases solapadas
Personas
580
581
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
582
Secuencial
Libre
Equipo
Polivalente
Especialistas
583
584
Taiichi Ohnos
Los dos pilares del sistema de produccin de Toyota son justin-time y automatizacin humanizada o autonomatizacin
(autonomation). La herramienta que utilizamos para operar
con el sistema es kanban.
Taiichi Ohnos
585
KANBAN
Tarjeta de seal
586
Se adhiere al auto en la
cadena de montaje.
Contiene indicaciones
legibles para humanos y
mquinas de todos los
detalles del vehculo.
587
Kanban de transporte
Kanban de produccin
588
TABLEROS KANBAN
Herramienta de gestin
visual
589
Cmo es el modelo de
gestin Kanban?
cc-by-sa ImproveIt
cc-by-sa ImproveIt
cc-by Gilgongo
cc-by heliomedeiros
590
Cmo es el modelo de
gestin Kanban?
Un tablero kanban es
una herramienta para
cc-by-sa ImproveIt
GESTIN GIL
cc-by-sa ImproveIt
cc-by Gilgongo
cc-by heliomedeiros
591
cc-by-sa ImproveIt
Cul es el formato
correcto de un tablero
kanban?
cc-by Gregg
cc-by alq666
cc-by-sa ImproveIt
592
Cul es el formato
correcto de un tablero
kanban?
cc-by-sa ImproveIt
FLEXIBILILDAD
cc-by Gregg
cc-by-sa ImproveIt
593
cc-by alq666
cc-by-sa H.D.N
594
595
FLUJO DE AVANCE
CONTINUO
596
597
Wq
Ws
Nq
NS
N
(n op / unidad
598
PENDIENTE
Lorem
Ipsum
Lorem
Ipsums
Loremsit
amet,
consecutur
Lorem
Ipsum
dolor sit
EN CURSO
Lorem
Ipsum
Nq
Lorem
Ipsum
dolor sit
HECHO
Lorem
Ipsums
uy lskd
Lorem
Ipsum
dkd
NS
N
599
W: Lead time
: Ritmo de
entrada
: Ritmo de salida
(carga)
=
Lorem
Ipsum
600
Lorem
Ipsums
=1
Lorem
Ipsums
uy lskd
Lorem
Ipsum
dkd
< 1 Infrautilizado
= 1 Estacionario
> 1 Saturado
REA DE GESTIN
PROPIETARO DEL PRODUCTO
REA DE GESTIN
EQUIPO
Tcticas:
RGIMEN DE
LLEGADAS
(Ritmo)
601
DISCIPLINA DE LA COLA
(Priorizacin)
WIP
(Ajuste del
WIP)
LEAD TIME
(Lean)
RGIMEN DE LLEGADAS
PRIORIZANDO LOS
DISCIPLINA DE LA COLA
TRABAJOS.
CRITERIOS POSIBES:
602
WIP
TCNICAS LEAN
603
NMERO DE SERVIDORES
604
INFORMACIN VISUAL
Favorece la comunicacin directa.
605
606
Burocracia
Sobreproduccin
Multiproyecto
Esperas
Ir haciendo
Desajustes de
capacidad
Errores
607
Prctica 1
Informacin en el rea de
producto
Informacin
visual
Gestin visual
608
Prctica 2
Desarrollo de producto
En incremento continuo
Posibles tableros para representar y guiar la gestin de trabajo de un equipo de desarrollo que
reflejen:
Pila de tareas.
Tareas ya estimadas y preparadas para entrar a desarrollo.
Tareas en anlisis.
Tareas en codificacin.
Tareas terminadas.
Tareas integradas en el servidor de desarrollo (labs)
Tareas integradas en produccin.
609
Prctica 3
Desarrollo de producto
En incremento iterativo
Posibles tableros para representar y guiar la gestin de trabajo de un equipo de desarrollo que
reflejen:
Pila de tareas.
Tareas ya estimadas y preparadas para entrar a desarrollo.
Tareas en anlisis.
Tareas en codificacin.
Tareas terminadas.
Tareas integradas en el servidor de desarrollo (labs)
Tareas integradas en produccin.
610
Prctica 3
Equipo de operacin y
mantenimiento
Estado de las tareas programadas para la semana y persona que est trabajando con cada
una.
Estado de incidencias no previstas y urgentes y persona que est trabajando con cada una.
611
Gestin en
organizaciones giles
1.0
612
613
614
615
COSTE
616
COSTE
PROTOTIPADO
NO REHACER - PLANIFICAR
617
PROBAR Y EXPLORAR
COSTE / BENEFICIO
PROTOTIPADO
NO REHACER - PLANIFICAR
618
PROBAR Y EXPLORAR
MALEABILIDAD
NO REHACER - PLANIFICAR
619
PROBAR Y EXPLORAR
TALENTO
620
Tiempos y mtodos
Optimizacin de procesos
Excelencia
Cultura y entorno
ECONOMA DE ESCALA
EFICIENCIA
621
VALOR
Gestin de
proyectos
predictiva
622
Produccin
basada en
procesos
cc-by: LizMarie
623
De
Tcito
Externalizacin
624
Explcito
De
Tcito
SAS
SAS
SAS
NO
g
Externalizacin
625
Explcito
Estructural
Elementos
Tecnologa
Empresa
Personas
Ubicacin del
conocimiento - valor
Tipos
de
industrias
Procesos
Humano
Artesana
Empresas industriales
Conocimiento
explcito
626
Conocimiento
tcito
627
VELOCIDAD
628
Fotografa cc-by:Amnemona
INCERTIDUMBRE
629
630
631
632
633
634
635
1985
638
639
640
642
PRINCIPIO GIL
PRCTICAS GILES
Burn-down
Seguimiento prximo
(diario)
Kanban de tareas
Grfico de carrera
PRINCIPIO GIL
PRCTICAS GILES
Burn-down
Seguimiento prximo
(diario)
Kanban de tareas
Grfico de carrera
FLEXIBILIDAD
Fundamentalismo (RAE): Exigencia intransigente de
sometimiento a una doctrina o prctica establecida
644
PRODUCTO
PROYECTO
GERENCIA
645
AM
DSDM
ASD
SCRUM
ASD
CRYSTAL
Lean
646
PRODUCTO
GERENCIA
647
GERENCIA
648
PRODUCTO
GERENCIA
649
PRODUCTO
GERENCIA
650
GERENCIA
PROCESOS
PRODUCCIN
651
Gerencia
Equilibrio sistmico de la empresa
Coherencia del modelo
Medios y formacin
Procesos / calidad
Configuracin de Scrum
Mejora continua
Garanta de funcionamiento de Scrum
Ejecucin
Visin del producto
Autoorganizacin
Tecnologa gil
652
Direccin
Scrum
Manager
Propietario
producto
equipo
653
Configuracin de Scrum
Mejora continua
Garanta de funcionamiento de Scrum
Autoorganizacin
Tecnologa gil
Management
Equilibrio sistmico de la empresa
Coherencia del modelo
Medios y formacin
Procesos / calidad
Configuracin de Scrum
Mejora continua
Garanta de funcionamiento de Scrum
Ejecucin
Visin del producto
Auto-organizacin
Tecnologa gil
654
Direccin
RR.HH.
Calidad
Oficina proyectos
655
Comercial
Programacin
Direccin
LA ASIGNACIN DE
RESPONSABILIDADES
RR.HH.
Calidad
SE ADAPTA A LA
ORGANIZACIN
Oficina proyectos
Comercial
Programacin
FLEXIBILIDAD / GLOBALIDAD
656
Direccin
RR.HH.
Calidad
Oficina proyectos
657
Comercial
Programacin
Direccin
RR.HH.
Calidad
Configuracin de Scrum
Mejora continua
658
Oficina proyectos
Comercial
Garanta de funcionamiento
Programacin
Autoorganizacion
Tecnologa gil
ADOPTAR PRCTICAS
MS O MENOS GILES
PREVISIBILIDAD
AGILIDAD
NO ES EL OBJETIVO
659
TRABAJAR DE FORMA
MS O MENOS GIL
PREVISIBILIDAD
AGILIDAD
NO ES EL OBJETIVO
660
TRABAJAR DE FORMA
ADECUADA A LA
ORGANIZACIN
PREVISIBILIDAD
AGILIDAD
ES EL OBJETIVO
661
662
Juan Palacio
Para consultar los usos autorizados de este trabajo o contactar con el autor:
http://www.safecreative.org/work/1401289956290
663