Cis PDF

Compendio de Ingeniera del Software
Rev. 1.0 Mayo 2014
Juan Palacio
Tabla de contenido
Prlogo Verificacin y validacin

Introduccin a la ingeniera del software Mantenimiento
Gestin de proyectos predictiva Gestin de la configuracin
Produccin basada en procesos Agilidad
Ingeniera de procesos de software Conocimiento
Modelo de procesos CMMI Sntesis entre procesos y agilidad
Modelo de procesos ISO IEC 15504 Scrum: el marco
Ciclo de vida del software Scrum: Mtricas
Ciclos de desarrollo y patrones de gestin de Scrum: prcticas
proyectos
Kanban
Los requisitos del software
Gestin en organizaciones giles
Diseo del software
Documentacin de usuario
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:
Formacin de Ingeniera del Software como asignatura complementaria en programas de

estudio tcnicos.
Formacin continua de gestores intermedios o directivos de empresas de software.
Presentaciones de asesora y formacin profesional durante la implantacin de procesos de
mejora.
Etc.
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
3
Introduccin a la
Ingeniera del Software
1.0
4
Introduccin Ingeniera del Software
1952
5
1965
6
Crisis del software
1950 1960 1970 1980 1990 1990 2000
Crisis
del
Software
?
7
Crisis del software
Este problema se identific por primera vez en 1968, ao en el que la organizacin NATO desarroll
la primera conferencia sobre desarrollo de software, y en la que se acuaron los trminos crisis
del software para definir a los problemas que surgan en el desarrollo de sistemas de software, e
ingeniera del software para describir el conjunto de conocimientos que existan en aquel
estado inicial.
Algunas referencias tiles para comprender cules eran los conocimientos estables para el
desarrollo de software en 1968 son:
En 1962 se public el primer algoritmo para bsquedas binarias.

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.
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.
El primero sobre anlisis de requisitos apareci en 1979
8
LA PRIMERA SOLUCIN A LA CRISIS DEL SOFTWARE
INGENIERA DEL SOFTWARE

Aplicacin de un enfoque sistemtico, disciplinado y cuantificable en el
desarrollo, operacin y mantenimiento de software.
INGENIERA DE PROCESOS
(Produccin basada en procesos / mejora continua del proceso)
Aplicacin del principio de calidad de Jurn empleado en la produccin

industrial a la produccin de sotware: La calidad del resultado depende de
la calidad del proceso -> modelos de procesos: CMMI, ISO 15504
GESTIN DE PROYECTOS
(Aplicacin del modelo de gestin de proyectos predictivo en los proyectos de software)
Aplicacin de procesos de planificacin, ejecucin y control para alcanzar un

objetivo final en un plazo de tiempo determinado con el coste y nivel de
calidad previstos
9
1980
10
1986
11
1990
12
2000
13
2005
14
2010
15
Crisis del software
Proyectos para desarrollo de sistemas de software
Fracaso Problemtico xito
2009 24% 44% 32%
2004 19% 53% 29%
2000 23% 49% 28%
1998 28% 46% 26%
1995 40% 33% 27%
1994 31% 53% 16%
Fuente: Standish Group Survey,

16
Crisis del software
Proyectos para desarrollo de sistemas de software
Fracaso Problemtico xito
2009 24% 44% 32%
2004 19% 53% 29%
2000 23% 49% 28%
1998 28% 46% 26%
1995 40% 33% 27%
1994 31% 53% 16%
Fuente: Standish Group Survey,

17
Ingeniera del software
Definicin original:
Establecimiento y uso de principios de ingeniera para obtener software

econmico que trabaje de forma eficiente en mquinas reales.
Fritz Baver, 1968 (conferencia NATO)
Otras definiciones
Disciplina para producir software de calidad desarrollado sobre las agendas y

costes previstos y satisfaciendo los requisitos.
S. Schach 1990, Software Engineering
(1) La aplicacin de mtodos sistemticos, disciplinados y cuantificables para el

desarrollo, operacin y mantenimiento de software; esto es, la aplicacin de la
ingeniera al software.
(2) El estudio de (1).
IEEE 1993
18
Desde 1968 hasta la fecha han sido muchos los esfuerzos realizados por los departamentos de
informtica de las universidades, y por organismos de estandarizacin (SEI, IEEE, ISO) para
identificar las causas del problema y definir pautas estndar para la produccin y mantenimiento del
software.
Los esfuerzos se han encaminado en tres direcciones principales.
Identificacin de los factores clave que determinan la calidad del software.
Identificacin de los procesos necesarios para producir y mantener software.
Acotacin, estructuracin y desarrollo de la base de conocimiento necesaria para la
produccin y mantenimiento de software.
El resultado ha sido la necesidad de profesionalizar el desarrollo, mantenimiento y
operacin de los sistemas de software, introduciendo mtodos y formas de trabajo
sistemticos, disciplinados y cuantificables.
La forma de trabajo de programadores individuales surgida por la necesidad de los primeros
programas, ha creado una cultura de la programacin heroica, para el desarrollo de software que es
la principal causa de los problemas apuntados, y en la actualidad una de las principales resistencias
a la implantacin de tcnicas de ingeniera para el desarrollo de sistemas
19

La Ingeniera del Software es una ingeniera muy joven que necesitaba:
Definirse a s misma: Cules son las reas de conocimiento que la comprenden?
Definir los procesos que intervienen en el desarrollo, mantenimiento y operacin

del software
De las mejores prcticas, extraer modelos de cmo ejecutar esos procesos para
evitar los problemas de la crisis del software
Definir criterios unificadores para las tareas de requisitos, pruebas, gestin de la

configuracin, etc.
Los estndares son tiles porque:
Agrupan lo mejor y ms apropiado de las buenas prcticas y usos del desarrollo de

software.
Engloban los conocimientos.
Proporcionan un marco para implementar procedimientos de aseguramiento de la calidad.
Proporcionan continuidad y entendimiento entre el trabajo de personas y organizaciones
distintas.
20
Desde la identificacin del fenmeno crisis del software, han sido muchas las organizaciones que
han abordado, con mayor o menor rigor, el anlisis de problemas en el desarrollo de sistemas de
software. Sus trabajos se han encaminado a la localizacin de las causas; y a la exposicin en
textos didcticos, normativos o estndares de procesos o prcticas necesarias para abordar el
desarrollo, mantenimiento y operacin con las mayores garantas de xito.
Han sido muchos los departamentos de universidades, organismos de normalizacin o investigacin
nacionales o internacionales, sociedades de profesionales, departamentos de defensa,
departamentos de calidad y procesos de empresas los que han ido generando normas y estndares.
Este compendio considera como entidades de mayor reconocimiento internacional, por sus trabajos
y esfuerzos realizados para la normalizacin, y reconocimiento de la Ingeniera del software a: ISO,
IEEE- Computer Society y SEI.
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:
ISO/IEC 12207
ISO/IEC TR 15504
SEI
Instituto de Ingeniera del software. (SEI http://www.sei.cmu.edu/).
Integrado en la Universidad Carnegie Mellon.
Los trabajos y aportaciones realizadas por el Instituto de Ingeniera del Software a la
Ingeniera del software son tambin referente mundial de primer orden, siendo la aportacin
ms significativa los modelos de madurez de las capacidades: CMM y CMMI; que en sus casi
15 aos de implantacin efectiva en entornos de produccin de software han demostrado su
efectividad en las dos finalidades que cubren: como marco de referencia para mejora de
procesos, y como criterio de evaluacin para determinar la madurez, y por tanto fiabilidad de
resultados previsibles de una organizacin de software.
22
IEEE Computer Society

IEEE Es el Instituto de Ingenieros en electricidad y electrnica (Institute
of Electrical and Electronics Engineers).
Su misin es preservar, investigar y promover la informacin de las
tecnologas elctricas y electrnicas.
Surgi en 1963 con la fusin del AIEE (Instituto Americano de Ingenieros Elctricos) y el
Instituto de Ingenieros de Radio (IRE).
La IEEE Computer Society (www.computer.org) es una sociedad integrada en IEEE, formada en
la actualidad por ms de 100.000 miembros en todo el mundo.
Su finalidad es avanzar en la teora, prctica y aplicacin de las tecnologas de la informacin.
Realiza conferencias, publicaciones, cursos de formacin, y desarrolla estndares.
Estndares para la Ingeniera del Software
IEEE ha desarrollado estndares para todas las reas de Ingeniera del Software.
Algunos de ellos, correspondientes a las principales reas especficas de la Ingeniera del
Software son:
IEEE Std. 830 Prcticas recomendadas para las especificaciones de software.

IEEE Std. 1362 Gua para la especificacin del documento de requisitos ConOps
IEEE Std. 1063 Estndar para la documentacin de usuario de software.
IEEE Std. 1012 Estndar para la verificacin y validacin de software.
IEEE Std. 1219 Estndar para el mantenimiento del software
23

La Ingeniera del Software es una ingeniera muy joven que necesitaba:
Definirse a s misma: Cules son las reas de conocimiento que la comprenden?
SWEBOK: Software Engineering Body of knowledge
Definir los procesos que intervienen en el desarrollo, mantenimiento y operacin

del software
ISO/IEC 12207: Procesos del ciclo de vida del software
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
Definir estndares menores para dibujar criterios unificadores en requisitos,

pruebas, gestin de la configuracin, etc.
IEEE 830 - IEEE 1362 - ISO/IEC 14764
24
SWEBOK
El proyecto SWEBOK (Software Engineering Body of Knowledge) comenz sus actividades de

manera efectiva dentro del SWECC1 en 1997 (aunque el comit SWECC se cre en 1993).
En el proyecto tambin estn representados:
los dos principales organizaciones de estandarizacin en Ingeniera del Software: IEEE e ISO/IEC
JTC1/SC/.
Los autores de las tres principales obras de Ingeniera del Software: Steve Mc Connell, Roger
Pressman e Ian Sommerville.
Universidad de Qubec (Montreal)
Empresas y organizaciones como: Rational, SAP, Boeing, Construx, MITRE, Raytheon,
En 2001 el proyecto public ya una definicin consensuada del cuerpo de conocimiento aceptado en
la ingeniera del software (http://www.swebok.org).
Las fuentes de informacin para la identificacin de las reas de conocimiento han sido los ndices
de textos genricos sobre la Ingeniera del Software, los curricula para licenciatura y postgrado en
Ingeniera de Software, y los criterios de admisin que se utilizan en el postgrado. Todos estos
datos se han organizado siguiendo el estndar ISO/IEC 12207.
El cuerpo de conocimiento identificado por el proyecto SWEBOK se ha configurado como el estudio

ms relevante y como la referencia de ms autoridad en toda la comunidad informtica para la
acotacin y descripcin de los conocimientos que configuran la Ingeniera del software.
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
25
SWEBOK da el primer paso necesario para constituir a la Ingeniera del Software como profesin: la
delimitacin del cuerpo de conocimiento que comprende la profesin. Sin esta delimitacin no es
posible validar de forma universal exmenes de licenciatura, no es posible la preparacin para
acceder a la profesin, y no hay un consenso sobre el contenido de su currculo.
El proyecto parte de la suposicin de que es necesario establecer cul es el cuerpo de conocimiento
que deben conocer los ingenieros del software, y en su desarrollo ha agrupado este conocimiento en
10 reas
Requisitos Gestin de la configuracin

Diseo Gestin
Construccin Procesos
Pruebas Herramientas y mtodos
Mantenimiento 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.
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.
26
ISO 12207: PROPSITO
Establecer un estndar para evitar una situacin de Torre de Babel en la gestin e

ingeniera del software, proporcionando un marco y un lenguaje comn en la disciplina
del software
Establece un marco comn para el ciclo de vida del software para
Adquisicin, suministro, desarrollo, operacin y mantenimiento del software

Gestionar, controlar y mejorar el marco
Como base de referencia para el trabajo e intercambio entre organizaciones de software
Ciclo de vida del software

Periodo de tiempo que comienza al concebir la idea de un nuevo sistema de software, y
termina cuando este se retira y deja de funcionar.
27
ISO 12207: PROPSITO
El estndar no prescribe:
Que deba emplearse ningn tipo de documentacin especfica.

Que deba emplearse un tipo especfico de ciclo de desarrollo.
Mtodos concretos para el desarrollo, mantenimiento u operacin del software.
Define el QU, no el CMO.

Dice cules son los procesos, actividades y tareas implicados en el desarrollo,
mantenimiento y operacin de los sistemas de software, asentando un marco estndar de
referencia internacional, pero no se ocupa ni prescribe tcnicas especficas.
El estndar sirve de referencia desde dos perspectivas diferentes:
Para la adquisicin de sistemas y servicios de software.

Para el suministro, desarrollo, mantenimiento y operacin de productos de software.
El estndar no cubre el desarrollo de productos de software para distribucin comercial masiva

(productos en caja).
No se trata de un estndar de certificacin, tipo ISO 9000, sino de un estndar para la

normalizacin.
28
ISO 12207 (20051): PROCESOS

5. Procesos primarios 6.- Procesos de soporte
5.1 Adquisicin 6.1 Documentacin
5.2 Suministro 6.2 Gestin de la configuracin
6.3 Control de calidad
5.3
6.4 Verificacin
Operacin
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
ISO 12207 (20081): PROCESOS
(1) Para el mbito y finalidad de estos apuntes, manejamos mejor la versin previa de 2005 por ofrecer una estructura ms comprensible
30
ISO 12207
ISO 1227 define los procesos que componen el ciclo de vida del software
Actividad 1
Tarea 1
Tarea 2
Proceso

1
Tarea n
Ciclo de vida

Concepto
Proceso Actividad n
Retirada
N Tarea 1
Tarea 2

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

mejora PDCA Plan Do Chek Act (Planificacin, ejecucin, medicin y mejora)
INICIO PLAN
Tareas, agenda,
asignaciones
ACT DO
Problemas y acciones PROCESO Ejecicin de planes
correctivas y tareas
CHECK
Evaluacin y
medicin FIN
32
INGENIERA DE SISTEMAS
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
sistema
Elemento del Elemento del

sistema sistema
Elemento del
sistema Sistema de
Salida
Coleccin de elementos relacionados de forma que puedan realizar un objetivo tangible.

Pressman 1982
33
Sistema
conjunto de elementos de hardware, software, personas, procedimientos, herramientas y otros
factores organizativos, organizados para llevar a cabo un objetivo comn.
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
Algunas definiciones
Ingeniera de sistemas comprende la funcin de gestionar todo el esfuerzo de desarrollo para

conseguir un balance ptimo entre todos los elementos del sistema. Es el proceso que transforma la
necesidad operacional en la descripcin de los parmetros del sistema, e integra esos parmetros
para mejorar la eficiencia general del sistema.
Defense Systems Management College, 1989
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
Funciones de la Ingeniera de sistemas
Definicin del problema: Determinacin de las expectativas hacia el producto, necesidades y

restricciones obtenidas y analizadas en los requisitos del sistema. Trabaja cerca del cliente para
establecer las necesidades operacionales.
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.
Evaluacin del producto: Determinar la calidad y cantidad de los productos elaborados, a

travs de evaluaciones, pruebas, anlisis, inspecciones
36
Ingeniera de sistemas Ingeniera de sistemas de software
Anlisis del
Pruebas del
sistema
sistema
Diseo del Pruebas de

sistema integracin del sis
Ingeniera de sistemas de software

Anlisis de Pruebas del
requisitos del sw sistema de sw
Diseo de la ar- Pruebas de

quitectura del sw integracin del sw
Ingeniera del software Ingeniera del software

Diseo detallado Pruebas del sub-
del software sistema de softw.
Codificacin
Pruebas unitarias
37
Ing. de sistemas Gestin de proyectos predictiva Ing. del Software
Gestin de proyectos
predictiva
Planificacin
Organizacin
Personal
Direccin
Control
Ingeniera de sistemas Ingeniera del software
Definicin del problema Diseo del software

Anlisis de la solucin Codificacin
Planificacin de procesos Pruebas unitarias
Control de procesos Integracin del
Evaluacin del producto subsistema de software
38
1950 1960 1970 1980 1990 1990 2000
Crisis Ingeniera del software
del
Software Desarrollo basado en procesos
Gestin de proyectos
39
INGENIERA DEL SOFTWARE

Aplicacin de un enfoque sistemtico, disciplinado y cuantificable en el
desarrollo, operacin y mantenimiento de software.
INGENIERA DE PROCESOS
(Produccin basada en procesos / mejora continua del proceso)
Aplicacin del principio de calidad de Jurn empleado en la produccin

industrial a la produccin de sotware: La calidad del resultado depende de
la calidad del proceso -> modelos de procesos: CMMI, ISO 15504
GESTIN DE PROYECTOS
(Aplicacin del modelo de gestin de proyectos predictivo en los proyectos de software)
Aplicacin de procesos de planificacin, ejecucin y control para alcanzar un

objetivo final en un plazo de tiempo determinado con el coste y nivel de
calidad previstos.
40
Gestin de proyectos
predictiva
1.0
41
Gestin de proyectos predictiva
PROYECTOS
Conjunto nico de actividades necesarias

para producir un resultado definido, en un
rango de fechas determinado y con una
asignacin especfica de recursos
42
GESTIN DE PROYECTOS (predictiva)
Gestin basada en
PLANIFICACIN
SEGUIMIENTO
1 Qu hacer?
2 Planificacin del trabajo
3 Ejecucin y control
43
PROYECTOS
1965.- IPMA
1969.- PMI
1989.- PRINCE 2
44
PROYECTOS
A tiempo
En costes
XITO
Calidad
45
NUEVA PROFESIN
Profesionalizacin del cuerpo de

conocimiento para desarrollo de
proyectos
46
PRCTICA: GESTIN PREDICTIVA
cc-by: LizMarie
47
Lo previsto
A tiempo 15 Turnos
En costes
48
Lo previsto
A tiempo
XITO
En costes
49
Gestin basada en
PLANIFICACIN
SEGUIMIENTO
1 Qu hacer?
2 Planificacin del trabajo
3 Ejecucin y control
La forma ms eficiente de hacer un trabajo es hacerlo bien a la primera

Watts S. Humphrey
50
GESTIN PREDICTIVA<->PRODUCCIN BASADA EN PROCESOS
LA FORMA MS EFICIENTE DE
HACER UN TRABAJO, ES
HACERLO BIEN A LA PRIMERA
Watts S. Humphrey
Creador de los modelos CMM - CMMI
51
GESTIN PREDICTIVA<->PRODUCCIN BASADA EN PROCESOS
LA FORMA MS EFICIENTE DE
HACER UN TRABAJO, ES
HACERLO BIEN A LA PRIMERA
Watts S. Humphrey
Creador de los modelos CMM - CMMI
Requisitos
Diseo
Codificacin
Pruebas
Integracin
Mantenim.
52
OPERACIONES Y PROYECTOS
Las empresas y las organizaciones en general llevan a cabo su trabajo bajo la forma de proyectos o
de operaciones.
Caractersticas comunes a las operaciones y los proyectos

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

Los proyectos son temporales y nicos, mientras que las operaciones realizan siempre los
mismos procesos de forma continua.
53
PROYECTOS
Caractersticas de los proyectos
Son realizados por personas

Disponen de recursos limitados
Su ejecucin se controla y responde a una planificacin.
Tienen un inicio y fin definidos
Tienen como finalidad producir un producto o servicio nico
Ciclo de vida planificado
Temporalidad
Cada proyecto tiene un inicio y fin definidos.
El fin se alcanza cuando se consiguen los
objetivos del proyecto por razones objetivas Ciclo de vida planificado
se decide abortar su ejecucin. Caracterstica derivada de la temporalidad y el
objetivo nico. El producto o servicio se lleva
a cabo de forma incremental siguiendo unos
pasos planificados que constituyen el ciclo de
Producto nico vida del desarrollo.
La finalidad del proyecto es realizar algo que
no se piensa repetir de forma sistemtica.
54
reas de conocimiento de la gesdtin de proyectos
Gestin de la integracin del Gestin del mbito del

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

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

Gestin de compras
del proyecto delproyecto
Plan de comunicaciones Plan de riesgos Plan de necesidades
Distribucin de la informacin Identificacin de riesgos Plan de compras
Informes de eficiencia Anlisis cuantitativo de riesgos Compras
Cierre administrativo Anlisis cualitativo de riesgos Seleccin de proveedores
Plan de exposicin de riesgos Contratacin administrativa
Monitorizacin y control de ries. Cierre de contrato
Fuente: PMBOK
55
Relacin de la G. de proyectos con otras reas de gestin
Gestin de
proyectos
Gestin y Negocio del

administracin proyecto
El principal conocimiento que se necesita para gestionar proyectos es exclusivo de la gestin de

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

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

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

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

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

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

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

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

pueden hacer los clculos de forma
automtica
63

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

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

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

Nueva ruta crtica
Asignacin mas eficiente
67

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

Menos tiempo de entrega no significa menor presupuesto
Cada tarea debe tener un resultado cuantificable para comprobar que se ha realizado
Usar el sentido comn
68
GESTIN DE PROYECTOS PREDICTIVA
cc-by: Betsy Fletcher

Vdeo: Construccin Plaza Carso y Museo Soumaya (Mexico)
69
Gestin de la integracin del Gestin del mbito del

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

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

Gestin de compras
del proyecto delproyecto
Plan de comunicaciones Plan de riesgos Plan de necesidades
Distribucin de la informacin Identificacin de riesgos Plan de compras
Informes de eficiencia Anlisis cuantitativo de riesgos Compras
Cierre administrativo Anlisis cualitativo de riesgos Seleccin de proveedores
Plan de exposicin de riesgos Contratacin administrativa
Monitorizacin y control de ries. Cierre de contrato
70
71
72
OBJETIVO
A tiempo En costes Calidad
73
GESTIN DE PROYECTOS CARACTERSTICAS
74
GESTIN DE PROYECTOS CARACTERSTICAS
AGENDA Y COSTE
SON
RESULTADO DE LA
PLANIFICACIN
75
CONCLUSIONES
Caractersticas de los proyectos

Obra nica
Inicio y fin definidos
Objetivo de la gestin de proyectos

Realizar la obra definida, en la fecha prevista y por el coste estimado
Puntos de apoyo de la gestin de proyectos

Definir qu hacer
Planificar el trabajo
Gestionar el cumplimiento
Necesita requisitos estables
La agenda y los costes son clculos realizados sobre el
plan del proyecto
76
Gestin de riesgos: principales conceptos y prcticas
GESTIN DE RIESGOS
IDENTIFICACIN
ANLISIS
TRATAMIENTO
Plan de gestin
de riesgos
77

Principales estndares para gestin de riesgos
Estndar Descripcin
ISO 31000 Estndar publicado por ISO
British Standard Estndar publicado por el instituto britnico de estandarizacin

BS 31100
Marco para riesgos corporativos desarrollado por el Comitee of

COSO ERM
Sponsoring Organizations of the Treadway Commission (coso.org)
ISO IEC 73 Glosario estndar para la gestin de riesgos.
78

Principios de la gestin de riesgos
Principio Descripcin
La gestin de riesgos debe ser proporcional al nivel de criticidad

Proporcional
del proyecto.
Para que resulte no debe dejar reas generadoras de riesgos

Exhaustiva
sin cubrir.
Las actividades de gestin de riesgos deben formar parte de

Institucionalizada
las prcticas propias de la organizacin.
Las actividades de gestin de riesgos deben estar incluidas en

Dinmica
ciclos institucionalizados de actualizacin y mejora continua.
Las actividades de gestin de riesgos en los proyectos deben

Alineada
estar alineadas con la cultura y madurez de la organizacin.
79

Trminos incluidos en ISO IEC 73
COMMUNICATION & CONSULTATION RISK AVOIDANCE

CONSEQUENCE RISK CRITERIA
CONTROL RISK DESCRIPTION
ESTABLISHING THE CONTEXT RISK EVALUATION
EVENT RISK FINANCING
EXPOSURE RISK IDENTIFICATION
EXTERNAL CONTEXT RISK MANAGEMENT
FREQUENCY RISK MANAGEMENT AUDIT
HAZARD RISK MANAGEMENT FRAMEWORK
INTERNAL CONTEXT RISK MANAGEMENT PLAN
LEVEL OF RISK RISK MANAGEMENT POLICY
LIKELIHOOD RISK MANAGEMENT PROCESS
MONITORING RISK MATRIX
PROBABILITY RISK OWNER
RESIDUAL RISK RISK PERCEPTION
RESILIENCE RISK PROFILE
REVIEW RISK REGISTER
RISK RISK REPORTING
RISK ACCEPTANCE RISK RETENTION
RISK AGGREGATION RISK SHARING
RISK ANALYSIS RISK SOURCE
RISK APPETITE RISK TOLERANCE
RISK ASSESSMENT RISK TREATMENT
RISK ATTITUDE STAKEHOLDER
RISK AVERSION VULNERABILITY
80

Gestin de riesgos
Identificacin de los riesgos
Anlisis y clasificacin
Informacin
Experiencia
Tratamiento (evitar, prevenir,

aceptar, proteger)
Plan de riesgos y recursos
Operacin
Y registro de informacin
81

Anlisis clasificacin
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

Identificacin
Mtodo sistemtico y organizado para descubrir los riesgos
Pueden identificarse directa o indirectamente.
DIRECTA: Identificando los orgenes (causas) que pueden ser:
Programacin: agendas impuestas, excesivas restricciones contractuales,

riesgos polticos
Requisitos: inconsistencias, TBDs, crecientes
Tcnicos: requisitos de rendimiento, seguridad, plataforma tecnolgica
Calidad: deficiencias en las prcticas de desarrollo
Logsticos: mantenibilidad, operacin, disponibilidad (el impacto se produce
cuando el sistema est en uso.
Despliegue: integracin, instalacin, distribucin
INDIRECTA: Identificando el impacto y buscando las causas. Las reas de impacto

son:
Agenda
Coste
Calidad
Operacin
83

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

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

Anlisis
Examen de los riesgos para determinar sus dos caractersticas principales:
Probabilidad
Impacto
El anlisis de los riesgos es una tarea de ejecucin cclica que debe realizarse y revisarse
peridicamente de forma adecuada a las caractersticas del proyecto.
El resultado del anlisis se plasma en un registro de los riesgos con la identificacin de su

descripcin y caractersticas, con apoyo de herramientas para su consulta, revisin, priorizacin,
etc.
85

Gestin de riesgos: probabilidad e impacto
86

Tratamiento
El tratamiento de los riesgos es el tercer paso del proceso de gestin de riesgos y comprende la
implementacin de mtodos y tcnicas para reducir el impacto o la probabilidad.
Las tcnicas se clasifican en 5 categoras en funcin de su finalidad:
1.- Evitar.
No proceder con esa actividad o escoger una alternativa. Para riesgos con ratio probabiliad /
impacto no admisible.
2.- Prevenir.
Para reducir los parmetros de probabilidad y/o impacto. Actividades ms utilizada:
Formacin / informacin, mantenimiento preventivo, disminucin del nivel de exposicin,
3.- Aceptacin o asuncin del riesgo.

Puede resultar suficiente para riesgos de escaso impacto y probabilidad no usar medidas
preventivas, si se dispone de reactivas en el caso de que se produzca, y su uso estadstico
global supone menor coste global que la prevencin.
4.- Proteger. Medidas que reducen

La probabilidad (Discos redundantes, sistemas elctricos redundantes, SAI)
Reducen las consecuencias (Backup, extintor)
5.- Transferencia del riesgo. Se traspasa el riesgo a otra compaa, departamento o mbito.
ejemplo: contratacin de un seguro, outsourcing
87
Extrema
PROBABILIDAD DEL RIESGO
Alta
RELEVANTE
ALTO MEDIO
Moderada
Escasa
BAJO
RELEVANTE MEDIO
Mnima
Muy grave Grave Media Bajo Mnimo

IMPACTO DE LAS CONSECUENCIAS
88
Produccin basada en procesos
PRCTICA: ANLISIS DE RIESGOS
cc-by: LizMarie
89
Produccin basada en
procesos
1.0
90
EL PROBLEMA
1950 1960 1970 1980 1990 1990 2000
Crisis
del
Software
?
91
LAS PRIMERA SOLUCIN: PRODUCCIN BASADA EN PROCESOS
Gestin de Produccin
proyectos basada en
predictiva procesos
92
ESCENARIO DE LOS 80: PRODUCCIN BASADA EN PROCESOS
LA CALIDAD DEL RESULTADO

DEPENDE DE LA CALIDAD DE
LOS PROCESOS
TQM - CMM - CMMI
Jurn / Humphrey
93
Eficiencia
Calidad
PROCESOS
Repetibilidad
94
PRCTICA: PRODUCCIN BASADA EN PROCESOS
cc-by: LizMarie
95
LA CALIDAD DEL RESULTADO

DEPENDE DE LA CALIDAD DE
LOS PROCESOS
TQM - CMM - CMMI
Jurn / Humphrey
96
Eficiencia
Calidad
PROCESOS
Repetibilidad
97
MODELOS DE PROCESOS
Modelos genricos Modelos para software
Adaptaciones
para softw.
1997
TickIT
1991
ISO 9000-3
1959 1979 1987 Trillium

MIL-Q 9858 BS 5750 ISO 9000 Bootstrap
1995
ISO 12207
para software.
especficos
1995 2003-05
Modelos
TR 15504
Proy. SPICE ISO 15504
1993 Modelos 2001
CMM-SW CMM CMMI
98
REFERENTES DE LA PRIMERA SOLUCIN
ISO 9000-3
ISO/IEC 12207
del software
Ingeniera
ISO/IEC 15504
ESTNDARES PARA LA
INGENIERA DEL
SOFTWARE
ngeniera de
procesos
CMM-SW
CMMI
Predictiva
Gestin
PMBOK
99
1950 1960 1970 1980 1990 1990 2000
Ingeniera del software Ingeniera de procesos

100
POSTERIOR ANTTESIS A LOS MODELOS DE PROCESOS: AGILIDAD

Adaptaciones
para softw.
1997
TickIT
1991
ISO 9000-3
PROCESOS
1959 1979 1987 Trillium

1995
ISO 12207
para software.
especficos
1995 2003-05
Modelos
TR 15504
1993 Modelos 2001
CMM-SW CMM CMMI
DSDM
SCRUM
AGILIDAD
CRYSTAL
XP
ASD
PP
ISD
AM
2000
1995
Manifiesto gil
101
Ingeniera de procesos de
software
1.0
102
Ingeniera de procesos de software
PROCESOS: CONCEPTOS GENERALES
Qu es un proceso?
Conjunto repetitivo ...
De actividades interrelacionadas ...
Que se realizan sistemticamente ...
Mediante las cuales ...
Un entrada se convierte en una salida o resultado, ... despus de aadirle valor
103
Ingeniera de procesos de software: definicin
Finalidad de los procesos de Ingeniera del Software

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

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

Dominio de aplicacin
Estructura del proceso de entrega (incremental, evolutivo, cascada...)
Madurez de la organizacin
104
Ejemplo: estructura de procesos en ISO 12207
PROCESO
Un proceso est compuesto por actividades.
ACTIVIDAD 1 ACTIVIDAD n
Una actividad est compuesta de tareas.
TAREA 1 TAREA X TAREA 1
La descomposicin del proceso en actividades y tareas se realiza sobre el concepto de ciclo de

mejora PDCA Plan Do Chek Act (Planificacin, ejecucin, medicin y mejora)
INICIO PLAN
Tareas, agenda,
asignaciones
ACT DO
Problemas y acciones PROCESO Ejecicin de planes
correctivas y tareas
CHECK
Evaluacin y
medicin FIN
105
Modelos de documentacin de procesos
Hay diferentes MODELOS para definir y documentar procesos:

Diferentes niveles de abstraccin - Diferentes tipos de definicin
Modelos de marco del ciclo de vida del software
Los ms comunes son: evolutivo / incremental, cascada, prototipado, prototipado
evolutivo, espiral, software reutilizable.
Modelos de proceso del ciclo de vida del software
Las principales referencias son:
o ISO/IEC 12207 IT Software Life Cycle Processes
o ISO/IEC 15504 IT Software Process Assesment
106
Notaciones
Lenguajes de modelado grfico que sirven para representar a los procesos.
Diagramas de flujo: Tcnica para especificar los detalles de un proceso en trminos de actividades, tareas,
entradas, salidas, condiciones.
IDEF0: Estndar para desarrollar representaciones grficas estructuradas de un sistema o entorno
empresarial. Permite la construccin de modelos que comprenden funciones del sistema (actividades,
acciones, operaciones, procesos), relaciones y datos.
UML...
107
Proceso de ingeniera del software
Niveles del proceso de Ingeniera del Software

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

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

procesos
Ingeniera de procesos del software
108
Ingeniera de procesos del software (del ciclo de vida del software)
Modelos ms relevantes de ingeniera de procesos
PDCA
Modelos genricos
IDEALSM
Basados en ciclos de
mejora continua
ISO 15504, Parte 7 Tienen similitudes
ISO 9004:2000
109
PDCA
PLAN
Identificar el problema
Analizar el problema
DO
Desarrollar soluciones
Implementar una solucin
CHECK
Evaluar los resultados
ACT
Determinar los siguientes pasos
110
IDEAL
Fase Inicial
Fase de Diagnstico
Fase de establecimiento
Fase de accin
Fase de aprendizaje
111
ISO / IEC 15504
Organizations 7. Sustain
Instituc. gains
needs
1. gains
Examine Confirmed
needs Quantified 8. Monitor improvements
results perform.
Scope
2. Initiate 6. Confirm
improv. improv.
sm ent
s
e a sse est
R u
Preliminary req
Improvements
plan 3.
Conduct
assess. 5.
Implement
improv.
Results
Action
4. Plan plan
improv.
112
PATRONES COMUNES
Medicin
Definicin
Planificar Anlisis cualitativo
implementacin y
Establecer cambio de
infraestructura procesos
Implementacin y
cambio
Base Implementacin y
Experiencia cambio de
procesos
Evaluacin del Medicin

proceso
Anlisis cualitativo
Implementacin y cambio
113
INGENIERA DE PROCESOS: Patrones comunes
DEFINICIN
MEDICIN
ANLISIS
IMPLEMENTACIN Y CAMBIO
114
Medicin
Obtener, analizar e interpretar informacin CUANTITATIVA para:

CARACTERIZAR
Entender el proceso actual, entorno, etc.
Disponer de informacin de la situacin anterior al cambio
EVALUAR
Determinar la consecucin de objetivos
Identificar fortalezas y debilidades del proceso
PREDECIR
Entender las relaciones entre procesos y productos
Establecer objetivos alcanzables de calidad, costes y agendas
MEJORAR
Identificar causas y oportunidades de mejora
Seguir el rendimiento de los cambios y compararlo con lneas base
115
Medicin
Se puede medir la calidad del proceso (en si mismo) o la calidad de sus salidas.
PROCESO SALIDAS
(resultado)

CONTEXTO
116
Medicin
Qu medir
La forma de identificar qu medir y cmo hacerlo ms eficiente es basndose en los objetivos del
proceso (goal-oriented / goal driven)
1) Empezar por especificar las necesidades de informacin

2) Despus, identificar las medidas que satisfacen esas necesidades
Fiabilidad: Margen de error de la medicin

Validez: Capacidad de medir realmente lo que creemos que mide
117
Medicin
Paradigmas
Evidencias cuantitativas
de la necesidad de mejoras
ANALTICO/A y del xito de iniciativas
de mejoras
Comparacin con
ANLISIS COMPARATIVO organizacin excelente en
(Benchmarking) un campo y documentar sus
practicas y herramientas
118
Medicin
El modelo ANALTICO consiste en:
ENTENDER
CONSOLIDAR REVISAR
Ejemplos:
Estudios experimentales y de observacin
Simulacin de procesos
Clasificacin ortogonal de defectos
Control estadstico de procesos
119
Medicin
El modelo ANLISIS COMPARATIVO consiste en medir:

La madurez de una organizacin
o la capacidad de sus procesos
Los modelos de evaluacin de procesos recogen lo que se consideran best practices

SW-CMM y CMMI CBA IPI y SCAMPI
ISO 15504 ISO 15504, Part 8
ISO 9001
2 arquitecturas generales con distintas asunciones en cuanto al orden en el que medir los
procesos: continua y escalonada
120
Medicin Orientada a Objetivos (GQM) (Goal Question Metric)
Cada mtrica debe esta dirigida a cubrir / medir un

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

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

INDICADOR respuesta a un requisito especifico.
121
Resumen de los pasos de GQM

1. Establecer los objetivos / expectativas Objetivos
de la coleccin de datos negocio
2. Desarrollar una lista de
requisitos / criterios de inters
3. Establecer los indicadores Qu tengo que
4. Disear los medios para recoger los datos conseguir?
5. Recoger y validar los datos
6. Analizar los datos
Qu quiero
conocer?
Indicador
122
Ayuda para identificar requisitos: listar entidades y cuestiones relacionadas

con los objetivos.

Entidad 1

Entidad 2

...
Descartar segn sean comprensibles, cuantificables, conscientes,

coherentes.
123
Ejemplos de requisitos:
Sin cargos o abonos

improc.
Entidad Financiera Fiabilidad Conformidad importe
p- importe c
...
Sin reparacin no
accidental antes de 2
Fabricantes de
Sin averas aos
coches ...
Recepcin de
Establecimiento mensajes < 15 min.
Rapidez
hotelero Chequeo inmediato
...
124
G1 G2
Q1 Q2 Q3
I1 I2 I3 I4
M1 M2 M3
125
126
Modelo de procesos
CMMI
1.0
127
Modelo de procesos : CMMI
CMM (Capabiliti Maturity Model)
Deficiencias en las metodologas Incapacidad para manejar el

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

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

Conjunto de prcticas recomendadas en determinadas reas clave de
proceso
Mejora la capacidad del proceso de software
Gua en la seleccin de estrategias de mejora de proceso

Establecer la madurez de los procesos
Determina cuestiones crticas para la calidad y la mejora del proceso
128
Organizaciones de software maduras / inmaduras
Idea principal: distincin entre empresas maduras/inmaduras
En una organizacin inmadura:

- Procesos de software: improvisados o no respetados (si existen)
- Planificacin en funcin de los problemas
- Presupuestos y planificacin incumplidos
- Sin base objetiva para evaluar la calidad o para resolver problemas
- Inexistencia o reduccin de las actividades de mejora de la calidad
En una organizacin madura:

- Capacidad de gestin: desarrollo de software y procesos de mantenimiento
- Proceso de software difundido al equipo y planificado
- Procesos modificables: pruebas piloto controladas y anlisis de coste/beneficio
- Roles y responsabilidades establecidos en el proyecto y la organizacin
- Gestores: monitorizacin la calidad de los productos y de los procesos
- Planificaciones y presupuestos realistas: rendimientos histricos
- Proceso disciplinado en el que todos los participantes entienden su valor,
existiendo adems la infraestructura necesaria para soportar el proceso
129
Proyecto CMMI
DoD (Departamento de Defensa de los Estados Unidos), SEI (Software

Engineering Institute) y NDIA (National Defense Industrial Association).
Ms de 100 organizaciones involucradas
U.S. Army, Navy, Air Force KPMG
Federal Aviation Administration Lockheed Martin
National Security Agency Motorola
Software Engineering Institute Northrop Grumman
ADP, Inc. Pacific Bell
AT&T Labs Q-Labs
BAE Raytheon
Boeing Reuters
Computer Sciences Corporation Rockwell Collins
EER Systems SAIC
Ericsson Canada Software Productivity Consortium
Ernst and Young Sverdrup Corporation
General Dynamics TeraQuest
Harris Corporation Thomson CSF
Honeywell TRW
130
Modelos CMMI
Modelo combinado
System Engineering/Software
Engineering
Aplicable:
Slo a proyectos de software
engineering
Slo a proyectos de system
engineering
Ambos
Continua o escalonada?
Ambas incluyen el mismo contenido y consiguen idnticos

objetivos
La representacin continua centra su actuacin en la
CAPACIDAD DE LOS PROCESOS
La representacin escalonada centra su actuacin en la
MADUREZ DE LA ORGANIZACIN
131
Por qu dos representaciones del modelo?
Heredado de los modelos de origen.

Software CMM--Escalonado
SECM--Continuo
IPD CMM--Hbrido
En el del equipo de desarrollo de CMMI haba defensores de de

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

hard.
Compromiso: Inicialmente soportar dos representaciones del

modelo con contenidos equivalentes.
132
Un modelo, dos representaciones
Continuo Escalonado
ML5
Capacidad
ML4
ML3
ML2
ML 1
PA PA PA
. . .para un rea de proceso . . .para un conjunto de
o un conjunto de reas de proceso reas de proceso establecido
133
Capacidad y madurez
Capacidad es un atributo que se aplica a los procesos y define la

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

potencial de calidad en la produccin.
ML5
ML4
ML3
ML2
ML 1
134
Niveles de capacidad
0 Incompleto
Los procesos no se realizan, o no consiguen sus objetivos
1 Ejecutado
Los procesos se ejecutan y se logran los objetivos especficos del rea
2 Gestionado
Los procesos que adems de considerarse ejecutados son tambin planificados,
revisados y evaluados para comprobar que cumplen los requisitos
3 Definido
Los procesos que adems de considerarse gestionados se ajustan al conjunto de
procesos estndar conforme a las lneas directivas de la organizacin
4 Gestin cuantificada
Procesos definidos que son controlados utilizando tcnicas estadsticas u otras
tcnicas cuantitativas
5 Optimizado
Procesos gestionados cuantificadamente que son cambiados y adaptados para
conseguir objetivos relevantes de negocio
135
Dimensin de la capacidad
Los valores describen cmo de bien se realiza el proceso (nivel

de capacidad del proceso).
Proceso bien ejecutado y

mejorado continuamente
Capacidad
Proceso no ejecutado
Area Area Area Area

Proceso 1 Proceso 2 Proceso 3 Proceso n
Procesos
136
Niveles de madurez
1 Inicial
Control deficiente e impredecibilidad de los resultados
2 Gestionado
Es posible obtener niveles de calidad previamente alcanzados
3 Definido
Los procesos realizados se encuentran normalizados, son conocidos y
comprendidos
4 Gestionado cuantitativamente
Los procesos incluyen indicadores de medicin y control
5 Optimizado
Centralizacin en la mejora de los procesos
137
Dimensin de la madurez
Optimizado
5 Centrado en la mejora de
procesos
Gestionado
4 Proceso medido cuantitativamente
y controlado
Definido
3 Proceso caracterizado
para la organizacin y
proactivo
Gestionado
2 Proceso caracterizado
para los proyectos y a
menudo reactivo
Inicial
1 Proceso imprevisible, poco
controlado y reactivo
138
reas de procesos
CMMI recoge prcticas para 22 reas de procesos
Las reas de procesos agrupan a las actividades necesarias para

la ejecucin de los proyectos de ingeniera de sistemas y de
software
El modelo en su representacin escalonada clasifica a las 22

reas de proceso en aquellas cuya gestin es necesaria para
lograr cada nivel de calidad
El modelo en su representacin continua las clasifica segn a la

categora que pertenecen: Gestin de proyectos, ingeniera,
soporte y gestin de procesos
139
reas de procesos en la representacin escalonada

NIVEL DE MADUREZ REAS DE PROCESO
Innovacin y desarrollo
5 OPTIMIZADO
4 GESTIONADO Gestin cuantificada de proyectos

CUANTITATIVAMENTE Rendimiento de los procesos de la organizacin
Desarrollo de requisitos
Solucin tcnica
Verificacin
Validacin
Integracin de producto
3 DEFINIDO Procesos orientados a la organizacin
Definicin de los procesos de la organizacin
Formacin
Gestin integrada de proyecto
Gestin de riesgos
Anlisis y resolucin de decisiones
Gestin de requisitos
Planificacin de proyecto
Monitorizacin y control de proyectos
2 GESTIONADO Gestin y acuerdo con suministradores
Medicin y anlisis
Gestin de la calidad de procesos y productos
Gestin de la configuracin
1 INICIAL
140
reas de procesos en la representacin continua
CATEGORA REAS DE PROCESO

Monitorizacin y control de proyecto
Gestin y acuerdo con proveedores
GESTIN DE PROYECTOS Gestin integrada de proyecto
Gestin de riesgos
Gestin cuantificada de proyecto
SOPORTE Medicin y anlisis

Anlisis y resolucin de problemas
Soluciones tcnicas
INGENIERA Integracin de producto
Verificacin
Validacin
Definicin de los procesos de la organizacin
GESTIN DE PROCESOS Procesos orientados a la organizacin

Formacin
Rendimiento de los procesos de la organizacin
141
Cmo usar el modelo

rea de proceso
Conjunto de practicas relacionadas que son ejecutadas de forma conjunta para conseguir un
conjunto de objetivos.
Componentes requeridos
Objetivo genrico
Los objetivos genricos asociados a un nivel de capacidad establecen lo que una organizacin debe
alcanzar en ese nivel de capacidad.
El logro de cada uno de esos objetivos en un rea de proceso significa mejorar el control en la
ejecucin del rea de proceso
Objetivo especfico
Los objetivos especficos se aplican a una nica rea de proceso y localizan las particularidades que
describen que se debe implementar para satisfacer el propsito del rea de proceso
142
Cmo usar el modelo

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

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

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

Notas Practicas genericas
Productos de
trabajo
Subpracticas
Elaboraciones
147
reas de proceso
CMMI SE/SW incluye 22 reas de proceso
Las reas de proceso son iguales en ambas representaciones del modelo
En la representacin continua, las reas de proceso se agrupan por categoras: Gestin de

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

5)
Process areas by maturity level
148
reas de proceso
Gestin de proyecto
Las reas de procesos de gestin de proyectos cubren las actividades relacionadas con la
planificacin, monitorizacin y control del proyecto.
El modelo CMMI SE/SW incluye seis reas de proceso en gestin de proyectos:

Monitorizacin y control de proyecto
Gestin y acuerdos con proveedores
Gestin integrada de proyecto
Gestin de riesgos
Gestin cuantificada de proyecto
149
reas de proceso
Gestin de proyecto: reas bsicas
PMC Estado, cuestiones, resultados

Acciones de evaluaciones de producto,
Correctivas Medidas y anlisis
Acciones
Que
Correctivas
Replanificar controlar
Estado, Que construir

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

Cuestiones tcnicas
Proveedor
Revisiones y test de aceptacin
150
reas de proceso
Gestin de proyecto: planificacin de proyecto
Propsito: establecer y mantener planes que definan las actividades del proyecto
Establecer Datos Desarrollar Plan

Estimaciones Planificacin de Proyecto
Obtener
Planes de
Compromisos
Proyecto
con el Plan
PMC
151
reas de proceso
Gestin de proyecto: monitorizacin y control
Propsito: Proporcionar informacin sobre el progreso del proyecto que permita tomar acciones
correctivas cuando la ejecucin del proyecto se desva significativamente del plan.
Gestionar
Monitorizar Proyecto contra Planes Acciones Correctivas
Monitorizar Analizar
Monitorizar Monitorizar Conducir
Parmetros Cuestiones
Riesgos Implicacin Revisiones
Planificacin
Stakeholder
Tomar
Monitorizar Conducir
Monitorizar Acciones
Gestin Revisiones
Compromisos correctivas
Datos de Progreso
Gestionar
Acciones
correctivas
PP Planes de Proyecto
152
reas de proceso
Gestin de proyecto: gestin y acuerdos con proveedores
Propsito: Gestionar la adquisicin de productos a proveedores segn un acuerdo formal existente.
Establecer Acuerdos con Proveedores
Determinar Establecer
Tipo Seleccionar Acuerdos
Adquisicin Proveedores
Lista de productos
Requisitos Proveedor Producto Acuerdo Proveedor
Satisfacer
Acuerdos
Proveedor Ejecutar
Acuerdos
Revisar Aceptar Transicin
Productos Producto Productos
COTS
153
reas de proceso
Ingeniera
Las reas de proceso de ingeniera cubren las practicas de desarrollo y mantenimiento compartidas
por diferentes disciplinas como ingeniera de software e ingeniera de sistemas.
El modelo CMMI SE/SW incluye seis reas de proceso en ingeniera:

Soluciones tcnicas
Integracin de producto
Verificacin
Validacin
154
reas de proceso
Ingeniera: reas bsicas
Requisitos
REQM
Requisitos de producto &

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

informes de verificacin y validacin
VER VAL
Necesidades del cliente

155
reas de proceso
Ingeniera: gestin de requisitos
Propsito: Gestionar los requisitos del producto y de componentes del producto del proyecto e
identificar inconsistencias entre los requisitos, los planes del proyecto y los resultados del trabajo.
Gestin de Requisitos
Entender Identificar
los Inconsistencias
Requisitos entre
Requisitos
Proyecto y
Requisitos
Gestionar Mantener
Obtener Trazabilidad
compromisos Cambios
Requisitos
a Requisitos Requisitos
Matriz
Trazabilidad
156
reas de proceso
Ingeniera: desarrollo de requisitos
Propsito: Producir y analizar los requisitos del cliente, del producto y de los componentes de
producto.
Desarrollar Desarrollar Analizar y

Requisitos Requisitos Validar
del Cliente del Producto Requisitos
Requisitos Requisitos Requisitos

Cliente Producto Validados
157
reas de proceso
Ingeniera: solucin tcnica
Propsito: Desarrollar, disear e implementar soluciones a los requisitos.
Requisitos
Validados
Seleccionar Desarrollar Implementar

Soluciones Diseo Producto
Producto-Comp.
Diseos alternativos Diseo detallado & Producto

y Criterios de evaluacin Documentacion Entregado
158
reas de proceso
Ingeniera: integracin de producto
Propsito: Ensamblar el producto asegurando que funciona apropiadamente y entregar el producto.
DAR
Preparar Integracin Plan Garantizar

Producto Integracin Interfaces
Compatibles
Assemblies
Sub-
Solucin
Tcnica assemblies
Ensamblar
Comp. Producto y
Entregar Producto
159
reas de proceso
Ingeniera: verificacin
Propsito: Asegurar que los resultados del trabajo seleccionados cumplen los requisitos
especificados.
Preparar para Ejecutar

Verificacin Peer Reviews
Plan
Verificacin
Verificar Productos
Seleccionados
Acciones
Correctivas
160
reas de proceso
Ingeniera: validacin
Propsito: Demostrar que un producto o componente de producto satisface su uso previsto en el

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

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

Medicin y anlisis
Anlisis y resolucin de problemas
162
reas de proceso
Soporte: reas bsicas
Calidad y no
Medidas, conformidades
anlisis
MA Todas las reas de proceso PPQA
Informacin Procesos y
necesaria resultados;
estndares y
Elementos de procedimientos
configuracin;
peticiones de Lneas base;
cambio informes de auditoria
CM
163
reas de proceso
Soporte: gestin de la configuracin
Propsito: Establecer y mantener la integridad de todos los productos de trabajo, utilizando

identificacin de la configuracin, control de la configuracin, informes de estado de configuracin y
auditorias de la configuracin.
Sistema
Gestin
Configuracin
Establecer Estado
Lneas BBDD
Base Peticiones
de cambio Resultados
Auditoria
Establecer
Peticiones Integridad
de cambio Elementos
Accin
Seguir y controlar cambios
164
reas de proceso
Soporte: aseguramiento de la calidad de procesos y producto
Propsito: Proporcionar un entendimiento objetivo de los procesos y los productos del trabajo
asociado.
Evaluar objetivamente procesos y productos de trabajo
Evaluacin Evaluacin
Objetiva Objetiva
Productos P. Trabajo
Procesos
trabajo y Servicios
Informes y Registros
Proporcionar entendimiento objetivo
Comunicar
y Garantizar Establecer
Resolucin de Registros
No Conformidades
165
reas de proceso
Soporte: medicin y anlisis
Propsito: Desarrollar y mantener una capacidad para medir, utilizada para dar soporte a las
necesidades de informacin de la gerencia.
Ajustar actividades de medicin y anlisis
Objetivos Medicin Repositorio

Medicin Procedimientos,
Herramientas
Personal Indicadores Medicin
Medicin
Proporcionar resultados de mediciones
166
reas de proceso
Gestin de procesos
Las reas de procesos de soporte cubren las actividades de definicin, planificacin, recursos,
desarrollo, implementacin, monitorizacin, control, evaluacin, medicin y mejora de procesos.
El modelo CMMI SE/SW incluye cinco reas de proceso en gestin de procesos:

Definicin de procesos
Enfoque de procesos a la organizacin
Formacin
Rendimiento de los procesos
167
reas de proceso
Gestin de procesos: reas bsicas
Necesidades
y objetivos
de procesos
Senior Formacin en
Management procesos
Objetivos OT Necesidades
Negocio Formacin
Procesos
Estndares y
Propios Procesos
Estndares reas de proceso de
y Propios gestin de proyecto,
OPF Recursos y OPD soporte e ingeniera
Coordinacin
Informacin de mejora
Propsitos de mejora de (e.j., lessons learned, datos)
procesos; Participacin
en definir, evaluar, y
desarrollar procesos
168
Modelo de procesos
ISO / IEC 15504
1.0
169
Modelo de procesos : ISO / IEC 15504
ISO/IEC 15504: Origen

Proyecto SPICE
En enero de 1993 la comisin ISO/IEC JTC1 aprob un programa de trabajo
para el desarrollo de un modelo que fuera la base de un futuro estndar
internacional para la evaluacin de los procesos del ciclo de vida del software.
Este trabajo recibi el nombre de proyecto SPICE (Software Process
Improvement and Capability dEtermination), y en junio de 1995, con la
publicacin de su primer borrador, desde ISO fueron invitadas diferentes organizaciones para
aplicarlo y valorar sus resultados.
Proyecto -> Instruccin Tcnica -> Estndar

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

tecnologas o metodologas de desarrollo.
170
Estructura
Conceptos
P1 P9
y gua de Vocabulario
introduccin
P7
P8 P6
Gua Guia para det. Guia de
para mejora capacidad de capacitacin de
de procesos proveedores evaluadores
Realizacin
Gua de
de
P3 evaluacin P4
evaluacin
Modelo de ref. Modelo de

para procesos P2 evaluacin P5
y capacidad y gua de indic.
171
Caractersticas
Marco para mtodos de evaluacin, no es un mtodo o modelo en s.

Comprende:
Evaluacin de procesos
Mejora de procesos
Determinacin de capacidad
Alineado con ISO/IEC 12207 Information Technology Software Life Cycle Processes
Dimensiones del modelo

El modelo tiene una arquitectura basada en dos dimensiones:
Dimensin de proceso
Caracterizada por las declaraciones del propsito de un proceso, que son objetivos esenciales
mensurables de un proceso.
Dimensin de capacidad de proceso

Caracterizada por una serie de atributos de proceso, aplicables a cualquier proceso, que
representan caractersticas mensurables necesarias para gestionar un proceso y mejorar su
capacidad.
172
Caractersticas
Dimensin de proceso
Agrupa los procesos en tres grupos correspondientes a los procesos del ciclo de vida que contienen
cinco categoras de acuerdo al tipo de actividad.
Procesos primarios Procesos de soporte

CUS: Cliente Proveedor SUP: Soporte
ENG: Ingeniera
Procesos organizacionales
MAN: Gestin
ORG: Organizacin
173
Dimensin de proceso
CUS: Cliente - proveedor
La categora CUS est formada por procesos que afectan directamente al cliente, soportan el
desarrollo y la transicin del software al cliente y permiten la correcta operacin y uso del producto
y/o servicio de software.
CUS.1 Proceso de adquisicin

CUS.1.1 Proceso de preparacin de la adquisicin
CUS.1.2 Proceso de seleccin de proveedor
CUS.1.3 Procesos de seguimiento de proveedor
CUS.1.4 Proceso de aceptacin del cliente
CUS.2 Proceso de suministro
CUS.3 Proceso de obtencin de requisitos
CUS.4 Proceso de operacin
CUS.4.1 Proceso de uso operacional
CUS.4.2 Proceso de soporte al cliente
174
Dimensin de proceso
ENG: Ingeniera
La categora ENG est formada por procesos que directamente especifican, implementan o
mantienen el producto de software, su relacin con el sistema y documentacin.
ENG.1 Proceso de desarrollo

ENG.1.1 Proceso de anlisis y diseo de requisitos de sistema.
ENG.1.2 Proceso de anlisis de requisitos de software.
ENG.1.3 Procesos de diseo de software.
ENG.1.4 Proceso de construccin de software.
ENG.1.5 Proceso de integracin de software.
ENG.1.6 Proceso de prueba de software.
ENG.1.7 Proceso de integracin y prueba de sistema.
ENG.2 Proceso de mantenimiento de software
175
Dimensin de proceso
SUP: Soporte
La categora SUP est formada por procesos que dan soporte al resto de procesos (incluidos los
SUP), en distintos puntos del ciclo de vida del software.
SUP.1 Proceso de documentacin

SUP.2 Proceso de gestin de configuracin
SUP.3 Proceso de aseguramiento de calidad
SUP.4 Proceso de verificacin
SUP.5 Proceso de validacin
SUP.6 Proceso de revisin conjunta
SUP.7 Proceso de auditora
176
Dimensin de proceso
MAN: Gestin
La categora MAN est formada por procesos utilizados en la gestin de cualquier tipo de proyecto o
proceso en el ciclo de vida del software.
MAN.1 Proceso de gestin

MAN.2 Proceso de gestin de proyecto
MAN.3 Gestin de calidad
MAN.4 Gestin de riesgos
177
Dimensin de proceso
ORG: Organizacin
La categora ORG est formada por procesos que establecen los objetivos de negocio de la
organizacin.
ORG.1 Proceso de alineacin organizacional.

ORG.2 Proceso de mejora
ORG.2.1 Proceso de definicin de proceso.
ORG.2.2 Proceso de evaluacin de proceso.
ORG.2.3 Proceso de mejora de proceso.
ORG.3 Proceso de gestin de RR.HH.
ORG.4 Proceso de infraestructura
ORG.5 Proceso de medicin
ORG.6 Proceso de reutilizacin
178
Dimensin de proceso
Componentes de proceso
Identificador
Identifica la categora del proceso y el n de secuencia en la categora. Distingue entre procesos de primer y
segundo nivel.
Nombre
Frase descriptivo del contenido del proceso
Tipo
Hay 5 tipos de proceso. 3 de primer nivel (bsico, extendido y nuevo) y 2 de segundo nivel (componente,
componente extendido)
Propsito
Prrafo que establece el propsito del proceso indicando los objetivos globales de su ejecucin.
Salidas
Lista de resultados observables de la implementacin exitosa del proceso
Notas
179
Dimensin de capacidad
Capacidad de proceso: rango de resultados que espera obtenerse al seguir el proceso.
Define una escala de medida para determinar la capacidad de cualquier proceso

Consta de seis niveles de capacidad
Nivel 0 Incompleto
Nivel 1 Realizado
Nivel 2 Gestionado
Nivel 3 Establecido
Nivel 4 Predecible
Nivel 5 En optimizacin
...y un conjunto de atributos de procesos asociados al nivel de capacidad
180
Niveles de capacidad y atributos
Nivel 0: Proceso Incompleto

Nivel 1: Proceso Realizado
Nivel 2: Proceso Gestionado
PA 2.1 Gestin de realizacin
PA 2.2 Gestin productos
Nivel 3: Proceso Establecido
PA 3.1 Definicin de proceso
PA 3.2 Recursos de proceso
Nivel 4: Proceso Predecible
PA 4.1 Medicin
PA 4.2 Control de proceso
Nivel 5: Proceso en optimizacin
PA 5.1 Cambio de proceso
PA 5.2 Mejora continua
181
Medicin de atributos
Los atributos de un proceso se evalan con N (Not), P (Partially), L (Largely) y F (Fully), siendo:
No alcanzado (0% a 15%).

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

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

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

F Evidencia de un enfoque completo y sistemtico y de la consecucin plena del atributo.
182
1.0
183
Introduccin
En este tema se tratan los siguientes conceptos:
Ciclo de vida del software.

Procesos del ciclo de vida.
Modelos de ciclo de vida.
El marco del ciclo de vida del software cubre desde la conceptuacin de las ideas iniciales del
producto hasta el fin de su uso (retirada).
ISO/IEC 12207 1995
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
Procesos primarios del ciclo de vida del software

12207 define los siguientes procesos primarios en el ciclo de vida del software:
ADQUISICIN
Proceso global que sigue el adquiriente para obtener el producto.
SUMINISTRO
Proceso global que sigue el suministrador para proporcionar el producto.
DESARROLLO
Proceso empleado por el suministrador para el diseo, construccin y pruebas del producto.
OPERACIN
Proceso seguido por el operador en el da a da para el uso del producto.
MANTENIMIENTO
Proceso empleado para mantener el producto, incluyendo tanto los cambios en el propio
producto como en su entorno de operacin.
185
Procesos de soporte del ciclo de vida del software

El estndar 12207 identifica los procesos de soporte que pueden ser utilizados desde un proceso
primario, o incluso desde otro proceso de soporte.
Los procesos de soporte son:
DOCUMENTACIN
Actividades empleadas para registrar informacin especfica empleada por otros procesos.
GESTIN DE LA CONFIGURACIN
Actividades empleadas para mantener un registro de los productos generados en la ejecucin

de los procesos.
ASEGURAMIENTO DE LA CALIDAD
Actividades empleadas para garantizar de forma objetiva que el producto y los procesos
asociados son conformes a los requisitos documentados y a las planificaciones.
VERIFICACIN
Actividades empleadas para verificar el producto.
VALIDACIN
Actividades empleadas para validar el producto.
186
Procesos de soporte del ciclo de vida del software
REUNIONES DE REVISIN
Reuniones empleadas por las dos partes para evaluar el estado del producto y de las
actividades.
AUDITORAS
Actividades para determinar que el proyecto cumple con los requisitos, planes y contratos.
RESOLUCIN DE PROBLEMAS
Actividades para analizar y resolver problemas relativas al proyecto, sea cual sea su fuente y
naturaleza.
187
Procesos organizacionales
El estndar 12207 identifica los procesos que deben realizarse en el contexto de la organizacin que
va a ejecutar el proyecto.
Normalmente estos procesos se aplican de forma comn sobre mltiples proyectos. De hecho las
organizaciones ms maduras los identifican e institucionalizan.
GESTIN
Describe las actividades de gestin de la organizacin, incluyendo tambin la gestin de

proyectos.
INFRAESTRUCTURA
Actividades necesarias para que puedan realizarse otros procesos del ciclo de vida. Incluye
entre otros el capital y el personal.
MEJORA
Actividades realizadas para mejorar la capacidad del resto de procesos.
FORMACIN
188
VISIN GENERAL DE LOS PROCESOS, RELACIONES Y ROLES
emplea
ROL
Adquiriente PROCESO DE ADQUISICIN
PROCESOS DE SOPORTE
ADQUISICIN
contrato
emplea
ROL Suministrador PROCESO DE SUMINISTRO
SUMINISTRO
emplea emplea emplea
emplea
ROL Operador
PROCESO DE OPERACIN
Usuario
OPERACIN
usa
emplea
Desarrollador PROCESO DE usa PROCESO DE
ROL
Mantenedor MANTENIMIENTO DESARROLLO
INGENIERA
Usuario del Documentacin Validacin

ROL proceso de Gestin de la configuracin Reuniones de seguimiento
SOPORTE soporte Aseguramiento calidad Auditora
Verificacin Resolucin de problemas
ROL
Gestor Gestin Infraestructura Mejora Formacin
ORGANIZACIONAL
189
Ciclos de desarrollo y
patrones de gestin de
proyectos
1.0
190
Ciclos de desarrollo y patrones de gestin de proyectos
El trabajo
Se puede realizar de forma
SECUENCIAL (cascada)
Fases 1 2 3 4 5 6
CONCURRENTE
Fases 1 2 3 4 5 6
191
El conocimiento
o know how necesario se encuentra dividido en mayor o menor % en:
Los procesos
Las
y tecnologa
personas
INGENIERA DE
AGILIDAD
PROCESOS
192
El desarrollo
Se realiza de forma
COMPLETA
INCREMENTAL
193
En un DESARROLLO INCREMENTAL
Las entregas se pueden producir con secuencia:
CONTINUA ITERATIVA
194
Para gestionar un DESARROLLO INCREMENTAL
Con un flujo continuo de trabajo Sin empaquetar tareas en

timeboxing (sprints)
Son apropiadas las tcnicas de gestin visual kanban para

evitar los cuellos de botella y los tiempos muertos.
Ajustndolas con criterios de flexibilidad a las circunstancias

de nuestro trabajo y equipo
Secuencial Polivalente
Trabajo Equipo
Libre Especialistas
195
Gestin de proyectos: diagrama de conceptos
DESARROLLO TRABAJO CONOCIMIENTO

Estrategia Tctica
Prcticas
PREDICTIVA
PMBOK
GESTIN
INGENIERA
SECUENCIAL
Completo Plan de proyecto Cascada
Prcticas giles
INGENIERA
EVOLUTIVA
CONCURRENTE
GESTIN
Procesos
Incremento Iterativo
o
AGILIDAD
Incremental Incremento continuo Fases solapadas Personas
196
Gestin predictiva

Estrategia Tctica
Prcticas
PREDICTIVA
PMBOK
GESTIN
INGENIERA
SECUENCIAL
Prcticas giles
INGENIERA
EVOLUTIVA
CONCURRENTE
GESTIN
Procesos
o
AGILIDAD
197
Ingeniera concurrente

Estrategia Tctica
Prcticas
PREDICTIVA
PMBOK
GESTIN
INGENIERA
SECUENCIAL
Prcticas giles
INGENIERA
EVOLUTIVA
CONCURRENTE
GESTIN
Procesos
o
AGILIDAD
198
Agilidad

Estrategia Tctica
Prcticas
PREDICTIVA
PMBOK
GESTIN
INGENIERA
SECUENCIAL
Prcticas giles
INGENIERA
EVOLUTIVA
CONCURRENTE
GESTIN
Procesos
o
AGILIDAD
199
Prcticas Scrum

Estrategia Tctica
Prcticas
PREDICTIVA
PMBOK
GESTIN
INGENIERA
SECUENCIAL
Prcticas giles
INGENIERA
EVOLUTIVA
CONCURRENTE
GESTIN
Procesos
o
AGILIDAD
200
Prcticas kanban

Estrategia Tctica
Prcticas
PREDICTIVA
PMBOK
GESTIN
INGENIERA
SECUENCIAL
Prcticas giles
INGENIERA
EVOLUTIVA
CONCURRENT
GESTIN
Procesos E
o
AGILIDAD
201
Eleccin del modelo de gestin y ciclo de desarrollo
Al iniciar el proyecto, el responsable de la arquitectura de procesos debe realizar los siguientes

pasos:
Anlisis de las circunstancias ambientales del proyecto.
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.
Mapeo de las actividades sobre el modelo.
Desarrollo del plan para la gestin del ciclo de vida del proyecto.
Debe considerar aspectos como:

Posibilidad de descomposicin del sistema en subsistemas de software, con agendas y
entregas diferenciadas.
Estabilidad esperada de los requisitos.
Novedad del proceso o procesos gestionados por el sistema en el entorno del cliente.
Criticidad de las agendas y presupuestos.
Grado de complejidad del interfaz de operacin, criticidad de la usuabilidad.
Grado de conocimiento y familiaridad con el entorno de desarrollo, componentes externos
empleados, etc.
202
Los requisitos del software
en la gestin de proyectos
predictiva
1.0
203
Los requisitos del software en la gestin de proyectos predictiva
Importancia de los requisitos
Para que un esfuerzo de desarrollo de software tenga xito, es esencial comprender

perfectamente los requisitos del software. Independientemente de lo bien diseado o
codificado que est un programa, si se ha analizado y especificado pobremente,
decepcionar al usuario y desprestigiar al que lo ha desarrollado.
Roger S. Pressman Ingeniera del Software Mc Graw Hill 1995
La parte ms difcil en la construccin de sistemas software es decidir

precisamente qu construir. Ninguna otra parte del trabajo conceptual es tan ardua
como establecer los requerimientos tcnicos detallados, incluyendo todas las
interfaces con humanos, mquinas y otros sistemas software. Ninguna otra parte
del trabajo puede perjudicar tanto el resultado final si se realiza de forma errnea.
Ninguna otra parte es tan difcil de rectificar posteriormente.
Frederick P. Brooks, Jr., The Mythical Man-Month, Addison-Wesley, 1995.
204
Qu porcentaje de proyectos concluyen con xito?

Un estudio realizado por Standish Group analiz el desarrollo de 8000 proyectos de software,
realizados por 350 empresas diferentes y concluy que slo el 16% de los proyectos de
software se realizan con xito.
El estudio identific como principales causas de los problemas:
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
Los criterios para determinar el xito de un proyecto son:
Sin desviaciones en las fechas previstas.

Sin desviaciones en los costes estimados.
Que el producto final cubra las expectativas y necesidades del cliente.
Que funcione correctamente.
205
Porqu fracasan los proyectos?
Requisitos incompletos: 13% Expectativas no realistas: 10%

Cambios en requisitos: 9% Producto no necesario: 8%
No implicacin de usuarios: 12%
TOTAL: 52%
206

50-200X
Coste de la
correccin
50-200X
Fase en la que se
detecta el fallo
Requisitos 1X
Arquitectura 1X
Diseo detallado
Construccin
Requisitos Arquitectura Diseo detallado construccin Produccin
Fase en la que se soluciona el fallo

207
Sus defectos repercuten en todas las fases
REQUISITOS
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
Los defectos comunes en los requisitos y sus consecuencias.
Implicacin insuficiente Problemas en la validacin

del cliente del producto obtenido
Requisitos crecientes Degradacin de la estructura

y cambiantes y arquitectura del producto
Prdida de tiempo en
Requisitos ambiguos
re-codificacin
Requisitos
Trabajo innecesario
innecesarios
Requisitos mnimos Problemas en la validacin

(insuficientes) del producto obtenido
Requisitos mnimos Error en la estimacin

(insuficientes) y planificacin
Omisin de las necesidades

Usuarios insatisfechos
de grupos de usuarios
209

Implicacin insuficiente del cliente
Algunos clientes no comprenden la importancia de trabajar con rigor en la obtencin de los
requisitos, para garantizar la calidad de los resultados.
Tambin es frecuente que los desarrolladores prefieran comenzar a trabajar en la
construccin del sistema, porque les resulta ms atractivo que reunirse con el cliente.
Hay situaciones en las que resulta difcil encontrar representantes del cliente que conozcan
a fondo el problema, o que por tratarse de un sistema o negocio nuevo, nadie en el
entorno del cliente tenga claras todas las funcionalidades que se necesitan.
Requisitos crecientes y cambiantes
Independientemente del punto del ciclo de vida en que nos encontremos, el sistema cambiar y
la tendencia al cambio persistir a lo largo de todo el ciclo de vida
Software Configuration Management, Prentice-Hall, 1980.
Es normal que los requisitos evolucionen durante el desarrollo del sistema, pero los cambios
deben partir de una descripcin inicial correcta, y gestionarse convenientemente, midiendo su
impacto en la planificacin del proyecto, y consensundolo con todos los participantes.
La evolucin de los requisitos durante el desarrollo de los proyectos puede incrementar o
modificar funcionalidades ya implementadas, desbordando los costes y agendas planificados.
210

Requisitos crecientes y cambiantes
Partir de una especificacin de requisitos incompleta incrementar el nmero de modificaciones
que sufrir el proyecto durante el desarrollo. Si los desarrolladores han diseado un sistema que
no corresponde con las expectativas del cliente, la introduccin sistemtica (generalmente con
agendas apretadas, o sin modificar las agendas iniciales), generar parches de programacin,
con insercin de cdigo adicional que puede trastocar principios bsicos de diseo y degradar la
arquitectura del sistema obteniendo finalmente un producto con serias deficiencias tcnicas.
Requisitos ambiguos
La ambigedad es un defecto habitual de las descripciones de requisitos.
Si lectores diferentes obtienen interpretaciones diferentes, o si un lector puede interpretar los
requisitos de formas diferentes, stos son ambiguos.
La ambigedad crea expectativas diferentes entre las partes del proyecto, y hace que los
desarrolladores programen funcionalidades que no se ajustan a lo que los usuarios necesitan.
La consecuencia inevitable de este problema es la re-programacin
La reprogramacin puede consumir ms del 40% del coste total de un desarrollo y se ha
estimado que hasta un 85% de las revisiones pueden deberse a errores en los requisitos [1] .
Para evitarla hay que confirmar que se comparte la visin obtenida con la que tienen las
diferentes fuentes de requisitos, y que los distintos participantes obtienen la misma
interpretacin de la documentacin de requisitos.
[1] Calculating the Return of Investment from More Effective Requirement Management, Leffingwell, Dean. 1997.
211

Requisitos innecesarios
Es frecuente la tendencia de algunos desarrolladores a incluir funcionalidades que no figuran en
la especificacin de requisitos, con la suposicin de que los usuarios lo agradecern. Muchas
veces los usuarios no les encuentran utilidad y quedan finalmente programadas pero sin uso,
suponiendo un coste de desarrollo innecesario.
Las sugerencias y posibilidades aportadas por el equipo de desarrollo pueden descubrir mejoras
importantes para el cliente o los usuarios, pero no deben implementarse sin consultarlas y
validarlas previamente.
Desde el punto de vista del equipo de desarrollo la mejor perspectiva es respetar la sencillez y
funcionalidad, y no ir ms all de los requisitos, sin la aprobacin del cliente.
Tambin es frecuente que el cliente pida funcionalidades que a primera vista pueden parecer
necesarias, pero que en realidad no aaden funcionalidad al producto, y que sin embargo
suponen un esfuerzo importante de desarrollo. Identificar estas funcionalidades, y pensar dos
veces si realmente se necesitan puede ahorrar trabajo innecesario
212

Requisitos insuficientes (mnimos)
Muchas veces el cliente tiene tan slo el concepto general del producto que desea, y no
comprende por qu es tan importante detallar los requisitos.
La tentacin en estos casos es partir de una descripcin mnima, o incluso de una explicacin
verbal, e ir preguntando y revisando a los programadores conforme el desarrollo avanza.
Esta forma de trabajo puede resultar apropiada slo para la construccin de sistemas
experimentales o prototipos, pero en general suele terminar con la frustracin de los
desarrolladores y el desconcierto y desesperacin del cliente.
Este planteamiento tambin genera la situacin muy frecuente de contar a los desarrolladores la
idea general de un nuevo producto, para pedirles una estimacin del tiempo necesario para
desarrollarlo.
Normalmente la visin general, sin descender a los detalles que implica, genera previsiones
optimistas que terminarn desbordadas al descubrir durante el desarrollo las implicaciones que
pasan inadvertidas en la concepcin inicial.
Las estimaciones prematuras, basadas en informacin limitada pueden fcilmente desbordarse
en ms del doble. Siempre que sea preciso ofrecer valoraciones previas es conveniente ofrecer
varias posibilidades (mejor caso, caso probable, peor caso), o incluir un porcentaje posible de
error probable.
213

Omisin de las necesidades de algunos grupos de usuarios
Entre los usuarios de un sistema es frecuente que se incluyan grupos de personas con
necesidades diferentes, que empleen funcionalidades distintas, e incluso que presenten diversos
perfiles de experiencia y conocimientos.
Al identificar las posibles fuentes de requisitos hay que localizar todos los posibles usuarios y
obtener informacin de sus caractersticas, necesidades y expectativas
214
Beneficios de los buenos requisitos.

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.
Concrecin de los atributos de calidad (ergonoma, mantenibilidad, etc.)

Ms all de funcionalidades precisas, los requisitos recogen atributos de calidad necesarios
que en ocasiones son desconocidos por los desarrolladores, produciendo finalmente sistemas
sobredimensionados o con serias deficiencias de rendimiento.
Eficiencia en el consumo de recursos: reduccin de la re-codificacin, reduccin de omisiones y

malentendidos.
Tener un conocimiento preciso de lo que hay que hacer evita la prueba y error, repeticin de
partes ya desarrolladas, etc.
215
Conceptos
Conceptos clave.
Requisitos Especificacin
Obtencin
del software
Requisitos Anlisis
del sistema
Procesos de
Validacin y
ingeniera de Gestin
verificacin
requisitos
216
Conceptos
Ingeniera de requisitos
Procesos mbitos
Obtencin Anlisis Especif. V&V Gestin Sistema Software
La ingeniera del software y la ingeniera de requisitos son ingenieras muy recientes.

En la actualidad acaba de cerrarse la versin 1.0 de SWEBOK, que constituye el esfuerzo ms serio
y consensuado hasta la fecha para definir las reas de conocimiento que la integran.
En este estado de cosas no es extrao encontrar que, diferentes autores clasifican o presentan los
conceptos clave de forma diferente, si bien los conceptos bsicos siempre son los mismos:
Obtencin, anlisis, especificacin, validacin y verificacin y gestin.
As por ejemplo, Karl Wiegers centra su inters clasificatorio en la diferencia entre el desarrollo de lo
requisitos y su posterior gestin.
SWEBOK plantea una representacin esquemtica plana (no distingue entre gestin y desarrollo) y
centra su inters slo en los requisitos del software.
IEEE carga el peso de la clasificacin en la diferencia entre requisitos del sistema y del software.
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.
217
Conceptos
Controlar las
Obtener informacin Registro y contrastacin
modificaciones
Clasificarla, localizar Comprobar que son Registrar cambios,

inconsistencias, dar Escribir los formalmente estudiar su impacto,
Obtener informacin
prioridades, pasar a requisitos correctos y lo que el actualizar
requisitos cliente quiere documentacin
VERIFICACIN
OBTENCIN ANLISIS ESPECIFICACIN & GESTIN
VALIDACIN
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
Conceptos
Especificacin
Cuando ya se conoce el entorno del cliente y sus necesidades, es necesario plasmarlas en forma de
requisitos en los documentos que sirven de base de entendimiento y acuerdo entre cliente y
desarrollador, y que establecern tanto la gua desarrollo como los criterios de validacin del
producto final.
Documentar los requisitos es la condicin ms importante para gestionarlos correctamente.
Verificacin y validacin
Los requisitos deben ser formal y tcnicamente correctos (verificacin), y satisfacer las necesidades
del sistema, sin omitir ninguna ni incluir funcionalidades innecesarias (validacin).
El significado de estos dos trminos genera confusiones habitualmente. El criterio bsico que los
diferencia es que verificacin se refiere a la calidad formal, en este caso de los documentos de
requisitos (no son ambiguos, no son incompletos, son posibles, verificables, etc.) y validacin
comprende la adecuacin en el entorno de produccin, en el caso de la documentacin de
requisitos, la conformidad por parte del cliente de que reflejan lo que l quiere.
Gestin
Los requisitos cambiarn durante el desarrollo del sistema, y es necesario poder trazar en cada
cambio todas las partes afectadas, as como poder medir el impacto que cada modificacin implica
en la planificacin del proyecto.
219
Conceptos
Descripcin del sistema

Sistema ConOps
mbitos
Requisitos del software
Software
SRS

Documento, tambin denominado ConOps y normalizado en el estndar IEEE Std. 1362-1998.
Definicin:
Documento dirigido a los usuarios, que describe las caractersticas de un sistema propuesto,
desde el punto de vista del usuario. La Descripcin del Sistema es el medio de comunicacin que
recoge la visin general, cualitativa y cuantitativa de las caractersticas del sistema; compartido
por la parte cliente y desarrolladora.
220
Conceptos
Propsito de la descripcin del sistema

El desarrollo de la Descripcin del Sistema proporciona una actividad de anlisis y un documento
que tiene la funcin de enlace entre las necesidades del usuario, y las especificaciones tcnicas
del desarrollo.
La Descripcin del sistema proporciona:
La descripcin de las necesidades operacionales del usuario sin entrar en detalles
tcnicos.
La documentacin de las caractersticas del sistema y las necesidades operacionales del
usuario, de forma que puedan ser verificadas sin requerir conocimientos tcnicos.
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.
El documento en el que, comprador y suministrador, reflejan las posibles estrategias de
solucin, y las restricciones que deben respetarse.
221
Propsito del estndar IEEE 1362

Ofrece un formato y contenidos para la confeccin de las descripciones de sistema en los
desarrollos y modificaciones de sistemas intensivos de software.
El estndar no especifica tcnicas exactas, sino que proporciona las lneas generales que deben
respetarse. No es por tanto un modelo final, sino una gua de referencia sobre la que cada
organizacin debe desarrollar sus propias prcticas y procedimientos para preparar y actualizar
su documentacin con las descripciones de los sistemas.
Las partes esenciales de un ConOps son:
Punto 3: descripcin del sistema existente.
Punto 4: justificacin del desarrollo o de la modificacin,
Punto 5: Descripcin del sistema propuesto.
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 EVOLUCIN
PREVISTA
224
Especificacin de requisitos del software (SRS)
Un documento SRS es la especificacin de las funciones que realiza un determinado producto de

software, programa o conjunto de programas en un determinado entorno.
El documento de especificacin de requisitos puede desarrollarlo personal representativo de la
parte suministradora, o de la parte cliente; si bien es aconsejable la intervencin de ambas partes.
Los aspectos bsicos que una descripcin de requisitos debe cubrir son:
Funcionalidad. Descripcin de lo que el software debe hacer.
Interfaces externos. Cmo debe interactuar el software con las personas, el sistema de
hardware, o con otros sistemas (software y hardware).
Rendimiento. Indicacin de la velocidad, disponibilidad, tiempos de respuesta, tiempos de
recuperacin, tiempos de determinadas funciones.
Atributos. Consideraciones de portabilidad, correccin, mantenibilidad, seguridad, etc.
Restricciones de diseo en la implementacin. Indicacin de las restricciones que
puedan afectar por la necesidad de sometimiento a estndares, lenguajes, polticas de
integridad de bases de datos, lmites de recursos disponibles para el desarrollo, sistema
operativo, etc.
Las especificaciones de requisitos de software deben evitar incluir requisitos de diseo o de
proyecto.
225
No deben incluir restricciones de diseo gratuitas

Deben especificar el 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:
Divisin del software en mdulos.
Distribucin de funciones en los mdulos.
Descripcin del flujo de informacin entre los mdulos.
Eleccin de las estructuras de datos.
Deben centrarse nicamente en el punto de vista externo

del sistema, y no en el funcionamiento interno
226
Restricciones de diseo necesarias

En algunos casos especiales, los requisitos pueden restringir el diseo de forma severa. Por
ejemplo, algunos requisitos de seguridad pueden implicar consideraciones de diseo como:
Mantener ciertas funciones en mdulos separados.
Permitir o limitar la comunicacin entre determinadas reas del programa.
Comprobar la integridad de los datos en variables crticas.
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.
Exclusin de parmetros y datos de planificacin del proyecto

La especificacin de requisitos de software se centra en el producto, no en el proceso de produccin
del producto.
Los requisitos de proyecto representan los trminos contractuales entre el cliente y el suministrador, y
no deben incluirse en la SRS. Normalmente incluyen informacin relativa a los procesos de adquisicin
o de suministro:
Coste.
Agenda de entregas.
Procedimientos de seguimiento.
Mtodos de desarrollo del software.
Control de calidad.
Criterios de validacin y verificacin.
Procedimientos de aceptacin
227
Diferencias: descripcin del sistema SRS
Pertenecen a procesos primarios diferentes

DESCRIPCIN
SRS
DEL SISTEMA
5.1 Adquisicin 5.1 Adquisicin
5.2 Suministro 5.2 Suministro
5.4 5.4
Operacin Operacin
5.3 5.3
Desarrollo Desarrollo
5.5 5.5
Mantenimiento Mantenimiento
Procesos primarios del ciclo de vida del software (ISO 12207)
228
Diferencias: descripcin del sistema SRS
Pertenecen a entornos diferentes
ENTORNO DEL PROBLEMA ENTORNO DE LA SOLUCIN
DESCRIPCIN DEL SISTEMA SRS
229
Conceptos clave
Independientemente de las tcnicas o procesos que se apliquen para realizar las diferentes tareas
relacionadas con el rea de requisitos, son cinco los objetivos que hay que cubrir:
ANALIZAR EL PROBLEMA
COMPRENDER LAS NECESIDADES DE LOS USUARIOS
DEFINIR EL SISTEMA
DESARROLLAR LOS REQUISITOS DEL SOFTWARE
GESTIONAR LOS REQUISITOS
Analizar el Comprender las Definir el sistema Desarrollar los Gestionar los

problema necesidades de requisitos del requisitos
los usuarios software
230
Conceptos clave
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.- Identificacin del problema.

2.- Identificacin de las partes implicadas.
3.- Delimitacin de la solucin.
4.- Identificacin de las restricciones.
231
Conceptos clave
Comprender las necesidades de los usuarios

La obtencin de los requisitos es sin duda la parte ms difcil del desarrollo de un sistema, y en la
actualidad es la principal causa de problemas.
En el apartado Obtencin de requisitos desarrolla de forma exclusiva este punto.
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
Conceptos clave
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:
Descripcin del sistema o de la situacin actual.
Descripcin de las necesidades que han motivado el desarrollo de un sistema nuevo, o de
la necesidad de modificar el actual.
Modos de operacin propuestos para el nuevo sistema.
Tipos de usuarios y caractersticas.
Funcionalidades propuestas.
Restricciones que debe respetar el sistema.
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
Conceptos clave
Desarrollar los requisitos del software

Tras analizar los problemas y necesidades de los usuarios, conocer las limitaciones que tener en
cuenta, y haber sintetizado en la descripcin del sistema la visin global de la solucin que se
pretende construir, es el momento de profundizar en los detalles.
El nivel de precisin que se debe alcanzar en la descripcin de los requisitos del software (SRS),
depende de varios factores, incluyendo el contexto de la aplicacin, los conocimientos del equipo
de desarrollo, as como su experiencia en desarrollos similares.
Los requisitos del software tambin deben verificarse y validarse, para garantizar, por un lado, que
son formalmente correctos, y por otro que dan respuesta a las necesidades de todas las partes
implicadas.
234
Conceptos clave
Gestionar los requisitos

Una vez que se ha comprendido el problema del usuario, se ha definido y descrito el sistema que
se desea construir para solucionarlo, y detallado los requisitos del software, comienza la fase de
diseo y desarrollo.
Se puede considerar que la fase de requisitos ya ha terminado al generar los documentos de
descripcin del sistema y descripcin de requisitos del software. Pero lo cierto es que los ciclos de
desarrollo secuenciales, o de cascada pura son muy raros, y, aun el caso de que inicialmente se
haya planteado este ciclo, desde la gestin del proyecto se debe considerar la posibilidad de
incorporar modificaciones en los requisitos durante el periodo de desarrollo.
Cuanto ms complejo sea el sistema, y ms larga la agenda de desarrollo, habr mayor
probabilidad de modificaciones sobre los requisitos; y si no se gestionan convenientemente
deteriorarn, en mayor o menor medida, la planificacin y la calidad del proyecto.
Si bien es cierto que no es posible plantear escenarios de desarrollo ideales en los que, tras una
definicin inicial de los requisitos, stos se van a mantener inamovibles durante todo el desarrollo
del producto; tampoco es posible incorporar modificaciones sobre los requisitos que han servido de
base para la planificacin del proyecto, y el diseo de la solucin, sin que la incorporacin obligue a
medir las consecuencias que van a tener sobre el trabajo ya realizado, el pendiente de realizar, las
posibles reconsideraciones de diseo, y en consecuencia sobre los costes y agendas del proyecto.
Requisitos Integracin/
Diseo Codificacin
pruebas
La gestin de requisitos da continuidad a esta rea durante todo el proyecto
235
Conceptos clave

El hecho de tener que gestionar los requisitos durante todo el ciclo de vida del sistema no quiere
decir que cualquier momento del desarrollo sea un buen momento para seguir descubriendo cules
son las necesidades de los clientes. La incorporacin de nuevos requisitos, o la modificacin de los
iniciales resulta mucho ms costosa conforme van avanzando las fases del proyecto. Por esta
razn, los ciclos secuenciales o de cascada con escasas iteraciones de retroceso son los ms
eficientes en el consumo de recursos.
Las razones que normalmente no permiten llegar a un conocimiento detallado del problema en la
fase inicial de los requisitos suelen ser:
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
Coste de la introduccin de modificaciones de requisitos
236
Conceptos clave

Al analizar el problema del cliente, y desarrollar los documentos de requisitos no hay que
escamotear esfuerzos para profundizar en las funcionalidades del sistema, y caer en la tentacin
de dejar pendientes de concrecin, o insuficientemente analizadas partes del problema para ms
adelante.
La gestin de los requisitos implica que cada modificacin de requisitos:
Debe provenir de una fuente autorizada.
Debe alcanzar el consenso de las partes implicadas.
Obliga a un anlisis del impacto.
Implica una revisin de la planificacin del proyecto.
Debe informarse al cliente de los efectos sobre la planificacin y recursos necesarios, para
obtener su aprobacin.
Debe incorporarse formalmente a la documentacin de requisitos
237
Obtencin de los requisitos
Sndromes en la obtencin de los requisitos

Cuatro son los principales desafos para el analista de requisitos:
S pero no exactamente as.

Vaya!, pues esto no debera ser as.
Ya est todo?
Usuarios contra desarrolladores
238
Vaya!, pues esto no debera ser as.

Este es un problema inherente al desarrollo de software.
Los usuarios no ver el sistema hasta que lo empiezan a usar, y es normal
que sea entonces cuando descubran que algunas partes no se adecuan
exactamente a sus expectativas.
El software no es fsico ni tangible. Al cliente de una vivienda se le puede
mostrar una maqueta o un plano. Un proyecto de mobiliario se puede
dibujar, pero nuestro producto no es fsico, es difcil de representar, de
conceptualizar de forma concreta y objetiva.
Si el analista de requisitos no comprende bien lo que el cliente necesita,
ste se dar cuenta de la disparidad de criterios cuando ya sea tarde,
cuando el sistema est en sus manos; de forma que habremos producido
algo que no cumple sus expectativas.
Por esta razn, inherente a la intangibilidad del software, la obtencin de
requisitos es la fase ms importante de un desarrollo.
El ingeniero de requisitos debe tener en cuenta que este sndrome es un riesgo consustancial con su trabajo, y que su
misin es anticipase para que al final del desarrollo produzca el menor efecto posible.
Los medios para reducir su efecto son:
Evitar quedarse con las primeras descripciones genricas.

No dar nada por supuesto.
Evitar las ambigedades.
Conocer el entorno y las necesidades del cliente.
Dedicar esfuerzo y tiempo para la obtencin de requisitos, adecuado al tamao y complejidad del sistema.
239

Este sndrome es similar al anterior, porque tiene el mismo resultado:
el descubrimiento tardo por parte del cliente de que determinadas
partes del sistema no solucionan adecuadamente su problema, pero a
diferencia del anterior, su origen no est en omisiones o
ambigedades en el proceso de obtencin, sino en la inmadurez de los
procesos a los que el nuevo sistema debe dar soporte, o en el
desconocimiento o actitud por parte de los interlocutores del cliente.
Aunque tenga el mismo efecto que el sndrome anterior, identificar
que tienen causas diferentes interesa en la medida en que requieren
soluciones, o formas de trabajo distintas.
El ingeniero de requisitos debe identificar mayores probabilidades de
riesgo si en el contexto adquieren relevancia las siguientes
situaciones:
El sistema no sustituye o modifica a otroexistente, sino que se desarrolla para dar soporte a procesos de negocio
novedosos para la organizacin que lo solicita.
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

Estas situaciones aumentan las probabilidades de terminar un sistema
perfectamente validable sobre una descripcin de requisitos correcta y
completa, sin ambigedades, pero en el que al final el cliente
descubrir que en, menor o mayor medida, no le soluciona el
problema como hubiera sido deseable.
Por supuesto en esta situacin, como desarrolladores podremos
argumentar que tenemos la razn de nuestra parte, puesto que
habremos construido lo que el cliente nos pidi, y el problema estriba
en que l no saba bien lo que quera, o se ha dado cuenta de lo que
en realidad necesita, cuando ha empezado a trabajar con el nuevo
sistema que hemos desarrollado.
De cualquier forma no es una situacin ni cmoda ni deseable.
Nuestro cliente como experto en su negocio tiene su ego,
y difcilmente reconocer que no saba o no quiso explicarnos lo que debamos construir. Si afortunadamente
disponemos de un documento de requisitos formalmente correcto, validado con su firma, tendremos un salvoconducto
para hacer efectiva nuestra factura, o defendernos de acciones legales, pero en ningn caso habremos cubierto nuestro
objetivo: desarrollar soluciones para los clientes, y habremos creado un sistema que no sirve y un cliente cabreado y
descontento.
Este sndrome tambin es inherente al desarrollo de sistemas de software, y con l resulta fcil deducir las funciones y
competencias que debe cubrir el ingeniero de requisitos, as como de ser persona con ojo clnico y registro amplio de
recursos.
Si se enfrenta a procesos poco maduros deber involucrarse en mayor medida en el entorno organizacional del cliente y
aportar en su trabajo parte ms propia de consultora que de analista de requisitos.
241

Deber tambin aportar asesora profesional al cliente informndole
del riesgo alto que encierra el proyecto de producir versiones que se
demostrarn inadecuadas para la realidad de sus procesos, y de la
conveniencia de profundizar el mximo posible en el conocimiento de
los procesos antes de elaborar los requisitos, as como de emplear
tcnicas de prototipado en la obtencin de requisitos, y ciclos de
desarrollo en cascada. Resultan ms aconsejables desarrollos
incrementales o evolutivos, con ciclos en espiral y seguimiento por
parte del cliente.
Si el analista se encuentra con problemas de comunicacin o de
actitud por parte del cliente deber conducir la situacin y adaptar su
registro de actuacin de forma que sin perder la asertividad, logre
establecer una implicacin adecuada del cliente y un flujo de
comunicacin productivo.
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?.
Esta incertidumbre es tambin inherente al trabajo del
ingeniero de requisitos, porque nunca tendr la certeza de
haber descubierto todas las necesidades y restricciones, y
sobre todo porque siempre puede dar por descontado que
algo se queda sin descubrir.
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

No es posible saber qu necesita el cliente, si no disponemos de
comunicacin fluida con los interlocutores de su organizacin; y por
desgracia es demasiado frecuente que los desarrolladores y los
usuarios, se relacionen sobre la base de la desconfianza mutua, y
empleen idiomas distintos.
Tanto la actitud de los desarrolladores como la de los usuarios no
suele ser favorable para trabajar unos con otros. Los primeros
prefieren concentrar su trabajo en el entorno tcnico, y olvidarse de
hablar con los clientes.
Los usuarios, por su parte, esperan su nuevo programa, con la misma
actitud que podran esperar un coche tras haberlo encargado en el
concesionario.
Los analistas y los usuarios pertenecen a dos comunidades que
desconfan mutuamente.
Los usuarios ven a los desarrolladores como personas incapaces de conseguir sistemas que funcionen correctamente
sin la necesidad de estar constantemente parchendolos.
Los desarrolladores se ven solos y desamparados como nicos responsables de todo cuando ocurra o tenga relacin con
el sistema.
Por supuesto, nosotros no esperamos que los usuarios cambien, pero tenemos que conocer estos problemas, y el
ingeniero de requisitos debe estar preparado para encontrarse con estas dificultades y minimizar sus consecuencias.
Se supone que durante la obtencin de los requisitos, tanto los usuarios como los desarrolladores comparten el mismo
objetivo: definir cmo ha de ser el nuevo sistema, pero lo cierto es que cada uno tiene objetivos diferentes.
Por nuestra parte estamos interesados en desarrollar una buena descripcin de requisitos, completa y correcta.
Queremos especificar un sistema tcnicamente viable, que integre la funcionalidad necesaria de forma eficiente sobre
un diseo limpio y robusto.
244

Por su parte los usuarios (cuando se implican) centran su inters en
definir el sistema con que esperan trabajar, sin querer saber nada de
agendas, viabilidad, prioridades, etc.
Para abordar con las mayores garantas de xito este problema, por
nuestra parte:
Debemos sumergirnos en la organizacin del cliente; estudiar, analizar
y comprender los procesos y problemas a los que tiene que dar
cobertura el nuevo sistema.
En las comunicaciones de requisitos, as como en la descripcin del
sistema, tenemos que emplear un lenguaje natural, sin tecnicismos; y
adoptar la terminologa habitual del entorno del cliente.
Mantener un enfoque y unidad de criterio comn por todas las
personas de nuestra organizacin, de cara al cliente.
Por parte del cliente:
Debe facilitar interlocutores conocedores de los procesos y problemas que debemos conocer, con tiempo y motivacin
suficiente para trabajar con nosotros.
Los interlocutores deben ser concretos y especficos en sus descripciones, revisar y validar los documentos de requisitos
generados.
245
Problemas frecuentes en la obtencin de requisitos

Los problemas ms frecuentes pertenecen a 3 categoras:
Delimitacin confusa del mbito del sistema.
Comprensin
Inestabilidad
Problema: delimitacin confusa del mbito del sistema

Antes de entrar en la obtencin de requisitos con detalle es necesario conocer cules son los
objetivos y los lmites del sistema.
Si no controlamos los lmites y objetivos esperados del sistema, el sistema nos

controlar a nosotros
Los contextos que es necesario conocer para centrar apropiadamente el sistema en su entorno
son:
Organizacin
Entorno
Proyecto
246
Problema: delimitacin confusa del mbito del sistema

Para evitarlo deben analizarse y conocerse los tres mbitos sealados
ORGANIZACIN
Para llevar a cabo la obtencin de requisitos es preciso conocer y comprender la organizacin
en la que trabajar el sistema, y los objetivos que se pretenden conseguir.
ENTORNO
Los factores del entorno del sistema influyen de forma determinante en el proceso de
obtencin de requisitos. Los ms importantes son:
Restricciones: de hardware, sobre el software o sobre los procesos de desarrollo.
Madurez de los procesos del entorno de operacin.
Grado de certidumbre de los interfaces con otros sistemas.
PROYECTO
El contexto en el que se desarrolla el proyecto tambin afecta a los procesos de obtencin de
requisitos, que deber adecuar los mtodos y tcnicas de obtencin a las caractersticas del
proyecto:
Caractersticas especficas de cada grupo de agentes implicados en el proyecto
(usuarios, cliente, desarrolladores, normativas, etc.)
Restricciones impuestas por las partes implicadas en la obtencin de los requisitos
(agenda, coste, parmetros de calidad deseados, etc.)
247
Problema: comprensin
El 56% de los errores deslizados en los sistemas desarrollados se deben a deficiencias en la
comunicacin usuario analista durante la obtencin de los requisitos, y este tipo de errores son
los ms caros de corregir porque llegan a consumir hasta el 82% del tiempo de desarrollo [1].
Los problemas de comprensin producen requisitos incompletos, con ambigedades,
inconsistentes; y en definitiva incorrectos, porque no definen las necesidades reales de los
usuarios.
Estos problemas se pueden agrupar en tres categoras:
Dar por supuesto lo desconocido.
Lenguaje.
Informacin desestructurada.
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
Tcnicas de obtencin de requisitos
Reuniones JAD, cuestionarios

ENTREVISTAS reuniones de grupo
entrevista, lluvia de ideas
Casos de uso, tarjetas CRC

ESCENARIOS diagramas de flujo, escenarios
TCNICAS
Prototipos rpidos
PROTOTIPOS prototipos evolutivos
Introspeccin
OBSERVACIN anlisis de protocolo
documentacin, otros sistemas
249
Clasificacin de los requisitos
REQUISITO
FUNCIONALES
RESTRICCIN
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:
Usuarios
Otros sistemas
251
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:
En la libertad de los analistas al realizar el diseo del sistema.
En los procesos o formas de trabajar que se emplearn en el desarrollo del sistema.
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
Problemas de clasificacin y nivel de rigor necesario

Para nosotros la base terica de clasificacin es un marco de referencia con la definicin de los
criterios de clasificacin.
En la relacin de requisitos de un sistema, no resulta interesante entrar en anlisis puristas para
determinar si cada requisito lo es de interfaz, funcional, etc.
La diferencia entre:
El sistema comprueba la autentificacin y autorizacin del usuario y le da acceso a una
pantalla con el men general o en caso de error le redirige a la pantalla de usuario y
contrasea otra vez
Y:
RS. 3 El sistema slo permite el acceso al men principal a usuarios autorizados.
RT.3.1 El sistema identifica al usuario solicitando a travs de la pantalla de operacin
su nombre y contrasea de acceso.
En el segundo caso, el equipo de trabajo sabe que debe descartar opciones de identificacin a
travs de tarjetas, o dispositivos biomtricos, o cualquier otra opcin posible.
Se trata por tanto de conocer y comprender el concepto de restriccin, para aplicarlas

slo cuando son necesarias, dejando as el mayor margen posible de libertad para el
diseo de la solucin de software.
253
Calidad de la documentacin
Caractersticas de las buenas descripciones de requisitos
Requisitos Especificacin
Posibles Completa
Necesarios Correcta
Priorizados Consistente
Concretos Modificable
Verificables Trazable
254
Propiedades de los buenos requisitos
Posibles
Cada requisito debe poder implementarse dentro de las capacidades y limitaciones conocidas
del sistema y su entorno. El director tcnico deber comprobar la viabilidad de los requisitos
antes de comprobar el documento.
Necesarios
Un requisito es necesario si es algo:
que el cliente realmente necesita Alto

requerido para la conformidad con un requisito
requerido para la conformidad con un interfaz,
externo o estndar.
Para evitar requisitos innecesarios,

el cliente debe valorar cada Coste
funcionalidad y como afectar
al sistema si esta o no.
Alto
Valor
255
Requisitos priorizados
Los requisitos de una SRS deben incluir una indicacin de la importancia del requisito en el
conjunto del sistema.
Normalmente todos los requisitos de un producto de software no son igual de importantes.
Algunos resultan esenciales, y otros son deseables.
Cada requisito debe identificar estas diferencias de forma clara, de esta forma ayuda a:
Los clientes tengan una consideracin ms adecuada de cada requisito, y a menudo
clarifica asunciones que pudieran estar ocultas.
Que los desarrolladores tomen decisiones de diseo correctas y dediquen niveles de
esfuerzo apropiado a las diferentes partes del producto.
Que el gestor del proyecto pueda establecer prioridades de ejecucin, y disponga de
informacin adicional en caso de problemas de agenda.
256
Concretos
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.
Punto
Comprensin
ptimo
Punto ptimo: Mayor grado de comprensin con la

menor ambigedad Ambigedad
Modos eficaces de evitar la ambigedad:

Inspecciones formales de los documentos de requisitos.
Escritura de casos de prueba
Elaboracin de casos de uso.
Elaboracin de diagramas.
257
Verificable
Un requisito es verificable si, y slo si a travs de un proceso concreto y finito es posible
comprobar si el software lo cumple. En general los requisitos ambiguos no son verificables.
Los requisitos no verificables incluyen sentencias como que trabaje eficientemente,interfaz de
usuario amigable, debe responder rpidamente. Estos requisitos no son verificables porque no
es posible definir los trminos eficiente, amigable, rpido. La sentencia el programa no
debe entrar nunca en un bucle infinito tampoco es verificable porque un nivel de pruebas
absoluto es tericamente imposible.
Un ejemplo de requisito verificable es:
El tiempo de respuesta para la compra de un billete sencillo no debe superar los 2 segundos el
90% de las veces, y una transaccin de compra de un billete sencillo nunca debe tardar ms de
5 segundos.
Esta sentencia es verificable porque emplea trminos concretos y magnitudes medibles y
comprobables.
Si no es posible establecer un mtodo para comprobar si el software cumple con un
determinado requisito, el requisito debe eliminarse o revisarse
258
Propiedades de la documentacin
Completa
Una SRS es completa si, y slo si incluye los elementos siguientes:
Todos los requisitos significativos, relativos a funcionalidad, rendimientos, restricciones
de diseo, atributos e interfaces externos.
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.
No puede considerarse completa una SRS si en la descripcin de algunos requisitos se incluye la
frase A determinar o la expresin inglesa TBD (to be determined).
Si excepcionalmente se indica que un requisito se concretar ms adelante es necesario indicar
tambin:
Descripcin de las causas por las que no se ha concretado el requisito.
Descripcin de qu debe realizarse para poder eliminar el TBD, quin es la persona
responsable de llevarlo a cabo, y cundo debe eliminarse
259

Completos
Conocemos No Conocemos
Entrevistas y revisiones
A B
Entendemos Este bloque pertenece a Este bloque pertenece a
los requisitos que los requisitos que
conocemos y sabemos conocemos pero no
que son aplicables al conocemos, es decir que
problema sabemos que existen pero
no hemos realizado su
anlisis.
Prototipado Prototipado y
casos de uso
C D
Este bloque pertenece a Este bloque pertenece a
los requisitos que los requisitos que no
No Entendemos sabemos que son conocemos y tampoco
aplicables al problema sabemos que no
pero que no entendemos conocemos
260
Correcta
Una especificacin de requisitos de software es correcta si, y solo si todos y cada uno de los
requisitos indicados son los que debe cubrir el software del sistema.
No hay ninguna herramienta que pueda garantizar la correccin. Una SRS debe compararse con
las especificaciones de rango superior del proyecto (Descripcin del sistema, documentacin
referenciada, etc.) para comprobar que cumple sus indicciones.
Tambin es recomendable que la parte cliente determine si la especificacin de requisitos de
software refleja sus necesidades actuales
Necesidades
del Usuario
B
B Revisin y aprobacin Requisitos
Correctos
C
Requisitos
Especificados
261
Consistente
El atributo de consistencia se refiere a consistencia interna no a conformidad o congruencia con
documentos superiores (ej. descripcin del sistema). La ausencia de esta congruencia supondra
un problema de correccin y no de consistencia.
Una documentacin es internamente consistente si, y solo si, no se establecen conflictos entre
requisitos individuales o grupos de requisitos. Los tres tipos de conflictos posibles son:
Conflictos
Objetos Lgicos Trminos
RF 10 Informe A
C=A+B
cierre de caja
C=A*B RF 50 Informe A
cierre diario de operaciones
262
Modificable
Un documento de requisitos es modificable si, y slo si su estilo y estructura permiten que
puedan llevarse a cabo modificaciones en los requisitos manteniendo la estructura y el estilo, de
forma fcil, completa y consistente. La modificabilidad generalmente requiere en la
documentacin:
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
Trazable
Un SRS es trazable si establece de forma clara el origen de cada requisito, y facilita su
referencia en las futuras etapas del desarrollo, o en las actualizaciones de la documentacin. Se
recomiendan los dos tipos siguientes de trazabilidad:
Trazabilidad remota (hacia fases previas del desarrollo). Para ello se debe referenciar la fuente
del requisito.
Trazabilidad futura (hacia fases posteriores del desarrollo). Para ello cada requisito debe tener
un nombre o referencia nica.
La trazabilidad remota es importante cuando el producto de software entra en la fase de
operacin y mantenimiento. Al modificar el diseo y el cdigo es esencial poder determinar
todos los requisitos que quedan afectados por una modificacin
264
Conclusiones
OBJETIVO
Desarrollar una
Desarrollar software
solucin
Tomar requisitos Comprender el entorno

del usuario y necesidades del usuario
Realizar procesos
Descripcin de requisitos
normalizados para el
correcta
desarrollo de requisitos
265
Conclusiones
MEDIOS FIN
Aplicar tcnicas Conseguir

y procesos el objetivo
266
Diseo de software
1.0
267
Diseo del software
Diseo
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
Diseo del software
Conclusiones
Diseo es la actividad del ciclo de vida en la que se analizan los requisitos del software para
desarrollar una descripcin de la estructura interna y la organizacin del sistema que servir de
base para su construccin.
Requisitos Diseo Construccin
269
Diseo del software
Conclusiones
El diseo como creacin de modelos

Una vez conocidas las necesidades de los usuarios es preciso disear una solucin.
Empleando el smil con la construccin de edificios, tras conocer cuales son las necesidades que
se desean cubrir con un edificio (hotel, colegio, vivienda familiar, edificio de apartamentos),
es el momento de disear la solucin.
Las posibilidades son muchas, y exceptuando proyectos de tamao mnimo, la complejidad de
concebir todas las facetas e interacciones del sistema desborda la capacidad de abstraccin
mental para concebirlo en una nica visin. Al mismo tiempo es necesario que todas las
personas implicadas en el proyecto conozcan y compartan los planos de la solucin.
As pues, las razones del diseo son:
Concepcin u anlisis de las posibles soluciones.
Apoyo metodolgico para abordar la complejidad de la solucin.
Registro documentado como medio de comunicacin entre los participantes.
Un modelo es una representacin simplificada de la realidad.
De igual forma que al concebir un edificio se divide la complejidad del sistema para hacerlo
digerible, y se generan diversos modelos de los diferentes aspectos: planos de estructura,
planos del subsistema de fontanera, del de electricidad, etc. los sistemas de software son
tambin realidades complejas que es preciso conocer (modelizar) para llevar a cabo el diseo
de su solucin.
270
Diseo del software
Actividades del diseo del software
El diseo del software comprende dos actividades intermedias entre la fase de requisitos y la de
construccin:
Diseo de la arquitectura del software

Descripcin de la arquitectura general, identificacin de
sus componentes y su organizacin y relaciones en el
sistema.
Diseo detallado del software

Definicin y estructura de los componentes y datos.
Definicin de los interfaces
Elaboracin de las estimaciones de tiempo y tamao.
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
Diseo del software
Razones del diseo del software
Por qu?
El resumen de las razones expuestas que hacen necesarias las tareas de diseo antes de
comenzar la construccin de un sistema son:
Permite la descomposicin del problema en partes y vistas de menor tamao, ms
manejables para el trabajo intelectual del diseo de la solucin.
Permite el desarrollo de modelos que se pueden analizar para determinar si cumplen
los distintos requisitos.
Permite examinar soluciones alternativas.
Los modelos se pueden utilizar para planificar el desarrollo de las actividades, y son el
punto de partida para empezar las actividades de codificacin y pruebas.
272
Diseo del software
Conclusiones
Descomposicin de la complejidad
Class nombredeclase{
Public: funcion() {}
}
273
Diseo del software
Conclusiones
Anlisis de soluciones posibles a travs de su modelado.
Requisitos
?

Disponibilidad
Coste desarrollo

Coste mantenimiento
Robustez

Tiempos de respuesta
Hardware necesario Etc.
274
Diseo del software
Conclusiones
Elemento de comunicacin, Base de planificacin y del desarrollo
275
Diseo del software
Fin del proceso de diseo
Se considera que el proceso de diseo se ha completado cuando

Todas las preguntas Como tienen respuesta
La descripcin del diseo de la arquitectura est completada
La revisin del diseo se ha completado y cada equipo/persona implicado est de acuerdo
con el diseo.
Los borradores de manuales para mantenimiento y administracin estn realizados
Se ha realizado la trazabilidad del diseo
Se ha revisado el diseo de la arquitectura
Se ha verificado el diseo de la arquitectura
Se ha escrito la planificacin de la integracin del software.
Se ha establecido la lnea base del producto
276
Diseo del software
Vistas del diseo de la arquitectura
Un sistema de software es una entidad ortogonal que puede contemplarse o analizarse desde
diferentes vistas:
Puede enfocarse la atencin en:
Distribucin fsica del software entre los diferentes elementos del sistema.
Descomposicin en las diferentes funcionalidades que realiza.
Estructuras de la informacin que gestiona.
Etc.
De esta forma el diseo puede generar modelos para cada una de las diferentes vistas empleadas
en su anlisis (modelo fsico, modelo de datos, modelo se procesos, etc.).
277
Diseo del software
Notacin empleada
Si bien el concepto y la finalidad del diseo o modelado de un sistema de software es siempre el

mismo, las notaciones pueden variar en funcin de las caractersticas de cada proyecto o de los
conocimientos o preferencias de las personas u organizacin que lo realice.
A travs del lenguaje de modelado empleado (UML, IDEF, Diagramas de flujo, etc.) se consiguen
realizar dos tipo de descripciones:
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
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.
278
Diseo del software
Estrategias y mtodos de diseo
Las principales estrategias que suelen emplearse para el diseo del software son:
Orientadas a funciones (estructurada)
Orientada a objetos (diseo orientado a objetos)
Diseo centrado en las estructuras de datos (menos empleado)
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.
Diseo orientado a objetos

Es la aproximacin ms popular actualmente, sobre la que se han desarrollado numerosos
mtodos partiendo de su concepcin inicial en la dcada de los 80
A travs del diseo orientado a objetos (OOD), se desarrollan las especificaciones de sistemas
como modelos de objetos (sistemas compuestos por conjuntos de objetos que interactan
entre ellos). que, expuesta de forma muy bsica, identifica a los nombres como objetos, a los
verbos como los comportamientos que pueden ofrecer y a los adjetivos como sus mtodos.
Para cada estrategia hay numerosos mtodos (notaciones, lenguajes de modelado, tcnicas).
279
Diseo del software
Paradigma OO Orientacin a objetos

OO no es una estrategia de diseo. El paradigma de orientacin a objetos es ms amplio
y abarca un enfoque general para conceptualizar, disear y programar los sistemas de
software.
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
Diseo del software
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.
Beneficios del enfoque OO

Los beneficios sealados por Booch en 1986 son:
Potencia, el uso del modelo OO ayuda a explotar el poder expresivo de los lenguajes de
programacin basados u orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS,
Ada, Java, C#
Reutilizacin, el uso del modelo OO favorece la reutilizacin, no solo del software, sino de
diseos completos.
Mantenibilidad, produce sistemas que estn construidos en formas intermedias estables y
por ello son ms resistentes al cambio en especificaciones y tecnologa.
281
Diseo del software
Principios del modelo OO

Fundamentales: Abstraccin, encapsulacin, modularidad y jerarqua. Booch afirma que
un modelo en el que no est presente alguno de estos principios NO es un modelo OO.
Complementarios: Tipificacin, concurrencia y persistencia
Abstraccin. Simplificacin en la descripcin o especificacin de un sistema consistente

en enfatizar algunos detalles o propiedades del sistema, con detrimento o supresin de
otros.
Encapsulacin. Ocultacin de los detalles de un objeto que no contribuyen a sus
caractersticas esenciales.
Modularidad. Propiedad de un sistema que ha sido descompuesto en un conjunto de
mdulos coherentes e independientes.
Jerarqua o herencia. Orden de las abstracciones organizado por niveles.
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.
Concurrencia . Propiedad que distingue un objeto que est activo de uno que no lo est.
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).
282
Diseo del software
UML
UML es un lenguaje de modelado que permite especificar, visualizar y documentar modelos de

sistemas de software.
Desde sus inicios fue concebido para ayudar a las tareas de anlisis de los sistemas de software, y
este es sin duda el mbito de mayor utilizacin, si bien es cierto que en la actualidad tambin se
emplea en el modelado y diseo de otros tipos de sistemas (modelos de negocio, producciones
cinematogrficas, etc.)
Tipos de diagramas UML

UML proporciona diagramas para representar modelos de las visiones estticas y dinmicas del
sistema, as como de su modularizacin.
REPRESENTACIONES
Estructura esttica Comportamiento dinmico Modularizacin
Diagrama de casos de uso
Diagrama de clases Diagrama de secuencia
Diagrama de objetos Diagrama de colaboracin Paquetes
Diagrama de componentes Diagrama de actividad Subsistemas
Diagrama de despliegue Diagrama de colaboracin Modelos
Diagrama de estados
283
Diseo del software
Descripcin del diseo de software (SDD)
El resultado del proceso de diseo es la documentacin denominada Descripcin del Diseo del
Software.
Un estndar empleado para desarrollar esta documentacin de forma normalizada es el IEEE Std.
1016-1998.
IEEE Std. 1016-1998

Describe prcticas recomendadas para describir los diseos de software. Especifica la informacin
que debe contener, y recomienda cmo organizarla.
Puede emplearse en software comercial, cientfico o militar sin limitaciones por el tamao,
complejidad o nivel de criticidad.
El estndar no establece ni limita determinadas metodologas de diseo, gestin de la
configuracin o aseguramiento de la calidad.
284
Diseo del software
Descripcin del diseo de software (SDD)
Ejemplo de una posible organizacin de la informacin en una SDD
1.- Introduccin 4.- Descripcin de las dependencias

1.1 Propsito 4.1 Dependencias intermolulares
1.2 Alcance 4.2 Dependencias inter-procesos
1.3 Definiciones y acrnimos 4.3 Dependencias de los datos
2.- Referencias 5.- Descripcin de interfaces
3.- Descomposicin de la informacin 5.1 Interfaces entre mdulos
3.1 Descomposicin modular 5.1.1 Interfaz del mdulo 1
3.1.1. Descripcin del mdulo 1 5.1.2 Interfaz del mdulo 2
3.1.2. Descripcin del mdulo 2 5.2 Interfaces entre procesos
3.2 Descomposicin de los proceesos 5.2.1 Interfaz del proceso 1
3.2.1. Descomposicin del proceso 5.2.2 Interfaz del proceso 2
1 6.- Diseo detallado
3.2.2. Descomposicin del proceso 6.1 Diseo detallado de los mdulos
2 6.1.1 Detalle del mdulo 1
3.3 Descomposicin de los datos 6.1.2 Detalle del mdulo 2
3.3.1. Descripcin de la entidad 1 6.2 Diseo detallado de los datos
3.3.2. Descripcin de la entidad 2 6.1.1 Detalle de la entidad 1
6.1.2 Detalle de la entidad 2
285
Diseo del software
Prcticas recomendadas
Trazabilidad del diseo
Comprobacin de que el diseo incluye todos los requisitos
Comprobacin de que el diseo no incluye funciones adicionales no
especificadas en el SRS.
Los resultados de la trazabiliad del diseo deben estar
documentados para la reunin de revisin del diseo
Reunin de revisin del diseo de la arquitectura

Revisin del diseo de la arquitectura
Un equipo apropiado (Usuarios, cliente, ingeniero de soft) revisan el diseo.
Una vez aprobado este diseo se puede comenzar a realizar el diseo detallado.
Verificacin del diseo de la arquitectura

El diseo se verifica contra el SRS
El proceso de verificacin analiza si el diseo es incompleto, incorrecto, ineficiente, difcil de
mantener, presenta un interfaz de usuario difcil de utilizar o aprender, o la documentacin
es de baja calidad.
Se realiza un informe para documentar los posibles problemas encontrados y tomar nota de
posibles incompatibilidades entre documentos.
LNEA BASE DE REQUISITOS QU
LNEA BASE DE DISEO CMO
286
Diseo del software
Base para las tareas de planificacin

La planificacin comienza con la misma decisin de desarrollar un sistema de software, y es un
esfuerzo continuo que termina cuando el proyecto ha concluido.
La planificacin consiste en la especificacin de:

Metas y objetivos para el proyecto
Estrategias, poltica, y procedimientos
Explicndolo de otra forma es la decisin de:
qu hacer
cmo hacerlo
cuando hacerlo
quien va a hacerlo.
A lo largo del ciclo de vida, desde la concepcin inicial del proyecto, la planificacin se va
revisando y depurando, y una vez obtenido el diseo se dispone de una base slida.
El diseo es la representacin formal de qu hacer y cmo hacerlo, sobre la que se

puede asignar cando y quin.
287
Diseo del software
Planificacin = Tareas de ingeniera de software y de gestin

La planificacin del proyecto est dividido entre dos componentes relacionados:
Planificacin realizada por el gestor

Planificacin realizada por el ingeniero de sistemas
Ingeniero de Software decide: Gestor de Proyecto decide:
Qu tareas hay que realizar Las habilidades necesarias para realizar las tareas
Orden y Dependencias de tareas La agenda para terminar el proyecto
Tamao (Esfuerzo en horas) El coste de esfuerzo
Solucin tcnica para la resolucin del problema Metodologa para evaluar el estatus del proyecto
Qu herramientas de anlisis y diseo hay que

Qu herramientas de planificacin hay que utilizar
utilizar
Riesgos tcnicos Gestin de riesgos
El modelo de procesos (Tcnicas) El modelo de procesos (Gestin)
Actualizar la planificacin cuando los requisitos o el Actualizar la planificacin cuando condiciones de

entorno cambian. gestin y entorno cambian.
288
Diseo del software
Consideraciones
El diseo es la estrategia de solucin.

Las tareas de codificacin, integracin y mantenimiento del sistema son la tctica.
La estrategia debe ser adecuada a las necesidades de los usuarios (requisitos y atributos
de calidad esperados).
No surge de procesos, herramientas o lenguajes de modelado.
Surge del talento de su creador.
Los procesos, las herramientas y los lenguajes de modelado pueden resultar tiles como
ayuda para descomponer la complejidad, y para comunicar el diseo a los participantes del
proyecto.
El talento de algunos profesionales les puede permitir manejar niveles de complejidad
elevados sin necesitar apoyo de procesos, herramientas o lenguajes de modelado.
A travs del cdigo es posible ver el diseo y la arquitectura del sistema.
La documentacin del cdigo resulta til para comunicar su diseo a travs del espacio en
sistemas en los que intervienen muchos desarrolladores, y del tiempo para facilitar su
mantenimiento.
Al emplear documentacin para la comunicacin del diseo es necesario trabajar con
procesos suficientes para garantizar su integridad y actualidad a travs de los cambios.
El diseo no cumple su finalidad hasta que no queda plasmado en el cdigo.
El resultado del diseo puede fallar tanto errores en su estrategia como por distorsiones
introducidas en la codificacin, integracin y mantenimiento.
289
Documentacin de usUario
1.0
290
Conceptos generales
Formatos de distribucin
Interno
Documentacin de usuario que se encuentra integrada y es accesible a travs del software.
Externo
Documentacin de usuario que cuyo acceso no est integrado en la operativa del software.
El formato externo no quiere decir que emplee una distribucin no informtica, sino que se
encuentra apartada de la operacin del software.
De hecho la documentacin externa puede distribuirse en CD, a travs de descargas desde
la web, etc.
Importancia de la calidad de la documentacin

A pesar de su importancia, las organizaciones productoras de software suelen descuidar la calidad
de la documentacin de usuario.
En muchos casos la documentacin se prepara en el ltimo minuto, y orientando su desarrollo ms
como trmite que como herramienta de informacin para el usuario.
Ayuda al cliente a obtener todo el valor de su inversin.

La operacin de sistemas complejos sin un conocimiento detallado de los mismos puede
dejar sin uso un porcentaje importante de los mismos.
Una documentacin completa y til incrementa la facilidad de uso del sistema.
LA PRODUCCIN DE DOCUMENTACIN DE USUARIO INADECUADA ES UN PROBLEMA

COMN EN LA INDUSTRIA DEL SOFTWARE
291
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
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).
Orientado a la
informacin
Formativo
Orientado a tareas
Modos descriptivos
Referencia
293
Conceptos generales
Los factores que deben determinarse antes de desarrollar la documentacin son:
Cules son los documentos necesarios.

Las caractersticas de la audiencia o audiencias de la documentacin.
El modo descriptivo de cada documento.
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
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.
Antes de comenzar el desarrollo de la documentacin es importante clasificar a los usuarios del

sistema por audiencias, identificando las caractersticas clave.
La documentacin debe plantearse pensando en las caractersticas y necesidades de la audiencia.
Algunos criterios tiles para identificar las audiencias y sus caractersticas:
Educacin:Cul es el nivel educativo de la audiencia?

Actitud: Cul es la actitud de la audiencia?. Son reacios al uso de ordenadores?.
Presentan resistencia al cambio?
Nivel de sofisticacin informtica. A ttulo de ejemplo, Brockmann[1] identifica cinco
niveles de sofisticacin informtica de los usuarios, que se muestran en la pgina siguiente.
Familiaridad con los procesos y negocio de la aplicacin.
[1] Brockmann, R.J. (1990). Writing Better Computer Documentation: From Paper to Hypertext
295
Conceptos generales
Clasificacin de usuarios
Nivel de sofisticacin informtica Caractersticas
Muy poca o ninguna experiencia con ordenadores

Tratan volmenes reducidos de informacin
Inexperto[1] No confan en la informtica
Trabajadores concretos
Alguna experiencia con ordenadores

Pueden comprender conceptos aislados
Principiante Emplean ejemplos concretos
Emplean siempre las opciones por defecto
Usuario novel con pocos meses de experiencia con

ordenadores
Intermedio Comienza a enlazar conceptos aislados
Emplea acciones por defecto y sus opciones.
Es la evolucin de un usuario intermedio.

Comprende las relaciones entre conceptos aislados.
Experto Tiene un nivel alto de autoconfianza.
Comprende el lenguaje abstracto
Puede ser inexperto, principiante, intermedio o

experto. Trabaja muy poco con el sistema.
Intermitente Se conduce a travs de los mens y mensajes del
sistema
[1] La denominacin original que hace Brockmann en su libro es lorito (parrot)

296
Conceptos generales
Por estructura de la documentacin se entiende la manera en la que la informacin se divide en
apartados, y el orden en el que stos se presentan.
La estructura afecta tanto a documentos impresos como a documentos electrnicos.
La documentacin puede estructurarse en uno o varios documentos.
La estructura debe ayudar a localizar y comprender la informacin.
Cuando la documentacin de un sistema se dirige a audiencias diferentes debe emplearse uno de
los siguientes criterios:
Separar en secciones diferentes la informacin dirigida a audiencias diferentes, identificando
en la introduccin de cada seccin la audiencia a la que va dirigida.
Separar en documentos diferentes la informacin para cada audiencia.
297
Estructura de la documentacin de usuario

Recomendaciones del estndar IEEE 1063-2001 para la estructura
Estructura general
La documentacin de un sistema de software puede consistir en uno o ms documentos, y cada

documento puede comprender uno o varios volmenes. Por ejemplo la referencia de comandos de
un lenguaje de programacin puede tener un volumen con la mitad de ellos y otro con la otra
mitad.
Son recomendables (aunque no obligatorio) las siguientes divisiones dentro de cada documento:
Documentos impresos: Captulos, temas y sub-temas.
Documentos electrnicos: temas.
La unidad de presentacin para los primeros es la pgina, y para los segundos la pantalla.
Cada pgina o pantalla debe tener una identificacin nica (por ejemplo el ttulo del captulo y
el n de pgina), que debe aparecer al imprimirla el usuario.
Los documentos impresos no deben tener ms de tres niveles de subdivisin dentro de un
captulo. As, por ejemplo, un sub-tema con nivel 1.2.3.4 debe ser el mayor nivel de sub-divisin.
Los documentos electrnicos deben permitir acceder a cualquier informacin con menos de 3
saltos (links) desde la pgina inicial.
Los documentos que contengan informacin en varios modos descriptivos (formativo y de
referencia) deben estar claramente separados en captulos diferentes, o al menos en temas
diferentes o manteniendo formatos tipogrficos distintos.
La documentacin en modo de referencia debe estar estructurada para facilitar la bsqueda y
acceso a los diferentes elementos. Por ejemplo, ordenando alfabticamente una lista de
comandos, o de informes de error.
298

Cada documento debe incluir
INFORMACIN IDENTIFICATIVA
Ttulo del documento
Versin del documento y fecha de publicacin
Nombre del producto de software y versin
Organizacin que edita el documento
TABLA DE CONTENIDOS (ndice)
INTRODUCCIN
Audiencia
Alcance y propsito del documento
Descripcin general del propsito y funcionalidad
del software, as como del entorno de operacin
299

Informacin crtica
La informacin crtica debe aparecer en una ubicacin destacada de la

documentacin.
!

Las advertencias de carcter general deben incluirse en la introduccin del
documento.
Las advertencias particulares deben aparecer en la misma pgina o pantalla en
la que se da informacin del procedimiento implicado
Contenido
La informacin debe ser completa

Si es en modo formativo debe incluir descripcin suficiente para que los
individuos con menos experiencia de la audiencia puedan realizar
eficientemente las funciones descritas.
En modo referencia se deben incluir todas las instancias de los elementos
seleccionados.
La informacin debe ser actual y acorde a la versin del software indicada.
300

Componentes recomendados para la documentacin de usuario
COMPONENTE OBLIGATORIO?
Informacin identificativa S
Tabla de contenidos S, en documentos de ms de 8 pginas
Lista de imgenes Opcional
Introduccin S
Informacin para el uso de la documentacin S
Informacin conceptual de las funcionalidades

S
generales
301

Componentes recomendados para la documentacin de usuario
COMPONENTE OBLIGATORIO?
Procedimientos S, en modo formativo
Informacin de comandos de software S, en modo referencia
Mensajes de error y resolucin de problemas S
S, si la documentacin incluye trminos

Glosario
desconocidos para la audiencia
Fuentes de informacin adicionales Opcional
ndice S, en documentos de ms de 40 pginas
Capacidad de bsqueda S, en documentacin sobre formato electrnico
302

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.
Consistencia en la terminologa y en el formato

El documento debe emplear de forma consistente la terminologa empleada para nombrar los
elementos del interfaz de usuario, nombres de operaciones, funciones, procesos y conceptos claves
del sistema.
Asimismo debe respetar a travs de todo el documento unas caractersticas grficas homogneas:
cabeceras, pies de pgina, estilos de ttulos y prrafos, mrgenes, estilos de vietas, etc.
Las convenciones empleadas para mostrar las advertencias y notas resaltadas deben presentarse
con las mismas caractersticas de estilo en todo el documento.
303
1.0
304
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.
Los errores introducidos en los productos intermedios se transmiten al

producto final.
Las calidad del producto final depende de la calidad imprimida en las

diferentes tareas, actividades y procesos.
305
Introduccin
Aunque en el lenguaje coloquial estos trminos pueden considerarse sinnimos, en el contexto de la
ingeniera del software tienen significados diferentes:
Verificacin: Determinacin con medios objetivos y repetibles de que un elemento

satisface los requisitos.
Validacin: Determinacin con medios objetivos y repetibles de que un elemento puede

emplearse para el fin que tiene asignado.
Coste de la validacin y verificacin

Las actividades de validacin y verificacin en un proyecto requieren un esfuerzo, que debe
estimarse y planificarse de forma apropiada en el plan del proyecto.
En funcin de las caractersticas del proyecto los costes directos e indirectos suelen situarse en
rangos del 5% al 40%[1] del coste total del proyecto.
[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
Conceptos
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:
Proceso proactivo de anlisis, revisin y pruebas.

Gestin en paralelo con las actividades de desarrollo para garantizar que el software cumple
los objetivos de correccin, calidad, rendimiento, agendas y usabilidad.
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.
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
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 en los procesos de desarrollo

5. Procesos primarios 6.- Procesos de soporte
5.1 Adquisicin 6.1 Documentacin
5.2 Suministro 6.2 Gestin de la configuracin
6.3 Control de calidad
5.3
6.4 Verificacin
Operacin
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
309
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
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
Relacin con Verificacin y validacin.

Es frecuente encontrar cierta confusin entre estas dos reas.
El Aseguramiento de la calidad (SQA) es una metodologa interna cuya principal finalidad es
garantizar que el flujo del trabajo cumple con las normas que tiene impuestas el desarrollador (por
su normativa interna, por imposicin del cliente, etc.).
SQA no evala el producto producido en esa fase o en ese proyecto, sino el

proceso que lo ha producido. No mira el producto, mira el proceso.
Validacin y Verificacin enfocan su anlisis en atributos del producto

generado.
311
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:
Nivel de integridad del proyecto.

Concepto desarrollado en las pginas siguientes. Mide la criticidad del software.
Mnimo de tareas recomendadas para el nivel de integridad del proyecto.

La regulacin interna de la organizacin desarrolladora puede determinar qu tareas de V&V
deben realizarse para cada nivel de integridad.
El estndar IEEE 1012 define 4 niveles de integridad e incorpora una tabla en la que se
estipulan las actividades mnimas de V&V en funcin del nivel.
Intensidad y rigor necesarios en las tareas de Validacin y verificacin.

El nivel de integridad no slo determina qu tareas deben realizarse, sino tambin su
intensidad y rigor. Por ejemplo, si lo realiza el propio personal de desarrollo, otro equipo de
desarrollo diferente, o incluso una organizacin externa (auditora).
Los criterios que se emplearn en las tareas de V&V para establecer los parmetros
mnimos de correccin, consistencia, precisin
312

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

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:
Si el sistema falla, se degrada o no consigue realizar las funciones de los

requisitos, qu impacto tiene en la seguridad o en el rendimiento?
Anlisis de daos
(hazard analysis)
Anlisis de riesgos
(risk analysis)
314

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:
Daos a las personas.

Daos al medio ambiente.
Prdidas econmicas.
Fallo en la finalidad del sistema.
Impacto social adverso.
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

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

NATURALEZA DEL RIESGO CAUSAS TPICAS
Propios del sistema Los identificados en el anlisis de daos
Complejidad innecesaria
Complejidad intrnseca del diseo mayor de la necesaria
Baja calidad
Incumplimiento de estndares necesarios
Inestabilidad de los requisitos
Propios del desarrollo Problemas con herramientas y mtodos
de software Inestabilidad, bugs en compiladores, etc.
Comportamiento imprevisto de los interfaces
Interfaces con hardw. y softw. externo en la implementac.
Inestabilidad y cambio rpido de las
plataformas tecnolgicas
Propios de los desarrollos Presin en costes y agendas.

Lagunas en planificacin y gestin.
por proyecto[1] Retrasos en subcontrataciones.
[1] En los proyectos de software se suelen dar con mayor intensidad los riesgos tpicos indicados.
317

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 Dirige el esfuerzo en la identificacin de los riesgos y la

cuantificacin de su posible impacto, para determinar
Verificacin
el nivel de integridad del proyecto.
Dirige el esfuerzo en la identificacin de los riesgos para

desarrollar un plan de accin para reducir la probabilidad
Gestin de proyecto de cada riesgo en funcin de la magnitud de su impacto,
(Gestin de riesgos) as como para prever las acciones si se llegan a producir
Daos.
[1] En los proyectos de software se suelen dar con mayor intensidad los riestos tpicos indicados.

Niveles de integridad
Anlisis de daos
(hazard analysis)
NIVEL DE
INTEGRIDAD
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
El nivel de criticidad depende de dos factores:

MAGNITUD DEL DAO POSIBLE POSIBILIDAD DE MITIGACIN
DEL DAO
319

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 Dimensin del dao por fallo del Software Mitigacin aplicable
Prdida de vida
No es posible mitigar
4 Prdida del sistema
los daos producidos
Graves prdidas econmicas o sociales
El sistema no realiza el fin previsto ni en

Es posible una mitigacin
3 todo ni en parte.
parcial de los daos producidos
Graves prdidas econmicas o sociales
No se pueden realizar funcionalidades

Se pueden mitigar los
2 parciales del sistema.
daos producidos
Prdidas econmicas o sociales importantes
Una determinada funcionalidad del sistema

No es necesario mitigar
1 no se realiza.
los daos
Consecuencias mnimas
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

Independencia
La determinacin de las personas responsables de las tareas de verificacin y validacin, depende
de:
Caractersticas y naturaleza del proyecto
Nivel de integridad
La independencia puede aplicarse a distintas reas del proyecto:
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.
321

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
Gestin Tcnica Financiera
CLSICA I I I
MODIFICADA I-R I I
INTERNA I-R I-R I-R
DOMSTICA I-M I-M I-M
I: Independencia rigurosa IR: Independencia con reparos IM: Independencia mnima
322

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 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:
Desarrollo del plan de validacin y verificacin.

Valoracin de las modificaciones.
Supervisin de las actividades de verificacin y validacin
Planificacin, monitorizacin y control del trabajo de validacin y verificacin.
Etc.
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
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
Si en el ciclo de vida empleado por el proyecto, la incorporacin de estas actividades est

modificada, el proceso de verificacin y validacin tambin se adecuar a las caractersticas del
proyecto.
V & V CONCEPTO
La verificacin y validacin del concepto trabaja sobre la descripcin del sistema, lleva a cabo el
anlisis de criticidad, estudiando y evaluando daos y riesgos; y genera o actualiza el plan de
validacin y verificacin.
326
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 DE LOS REQUISITOS

Completo Posibles
Correcto Necesarios
Consistente Priorizados
Modificable Correctos
Trazable 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
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
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
EL SISTEMA YA EST EN USO

Las actividades de mantenimiento resultan muy visibles para el
cliente.
Pueden afectar negativamente a la imagen de la organizacin.
ES UNA ACTIVIDAD CRTICA

GENERALMENTE INFRACONSIDERADA
331
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
Datos de configuracin Requisitos, documentos Manuales y
y estructuras de datos de anlisis, plan de V&V documentacin de usuario
332
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
De emergencia
Mantenimiento 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 las organizaciones de software no aparece asociada a nuevas oportunidades de negocio,

que es sin duda un aspecto mucho ms atractivo para sus gestores.
Los trabajos de mantenimiento suelen tener asignados sus propios presupuestos pre-
establecidos, y se ven como un negocio normal, por lo que no suelen atraer la atencin de
la actividad del negocio.
El personal tcnico suele preferir trabajar en proyectos nuevos y no en mantener sistemas
ya desarrollados.
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:
Posibilidad de introduccin de errores en cascada o distorsionar funcionalidades ya

implementadas al insertar nuevas modificaciones.
El equipo de mantenimiento debe tener un conocimiento global del producto.
Las pruebas suelen resultar especialmente complicadas porque generalmente las
limitaciones de tiempo no hacen posible ejecutar pruebas completas de regresin.
Desde el punto de vista de gestin, las tres categoras de mantenimiento (correctivo,
perfectivo y adaptativo) suelen realizarse de manera simultnea, con gestin de prioridades
de cada peticin de cambio, y respetando la gestin de la configuracin del sistema.
335
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
reas de degradacin creciente
Diseo Cdigo Datos Documentacin
336
Mantenimiento

Dificultad por degradacin del sistema
DIFICULTAD
DEL MANTENIMIENTO
Factores agravantes
Escasa concienciacin
SISTEMA MS DIFCIL organizacional de la relevancia del
mantenimiento.
DE MANTENER
Peticiones de cambios con presin
de fechas y presupuestos.
Consideracin del personal tcnico
de que se trata de un trabajo de
segunda categora
Degradacin del sistema

Diseo cada vez ms turbio
Cdigo parcheado cada vez ms
sucio
Estructurad de datos van
perdiendo su normalizacin e
integridad referencial
Actualizacin deficiente o nula de
la documentacin
337
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.
Las actividades de mantenimiento deben realizarse con tcnicas de gestin

de proyectos
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:
Identificacin clasificacin y priorizacin del problema o de la modificacin.

Anlisis.
Diseo.
Implementacin.
Pruebas de sistema y de regresin.
Pruebas de aceptacin.
Entrega.
Al realizar tareas de mantenimiento, en cada una de estas fases deben considerarse los siguientes
elementos:
EN CADA FASE
Entradas Procesos Control Salidas Mtricas
339
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)
Peticin de cambio Asignar n de Una vez identificada Peticin de cambio N de omisiones

identificacin la peticin de validada que queda en la P.C.
Clasificar por tipo cambio, debe en un registro con la N de P.C.
de mantenimiento quedar registrada siguiente enviadas
Analizar y deter- en un registro de informacin: N de peticiones
minar se se acepta peticiones de de cambio
rechaza o pospone cambio Definicin del duplicadas
Primera estimacin problema o del Tiempo invertido
de su magnitud nuevo requisito en la validacin.
Priorizar la Evaluacin
modificacin Tipo de mantenim. Factores medidos:
Asignar la peticin Prioridad inicial correccin y
a qu bloque de Estimacin inicial mantenibilidad
modificaciones de recursos
prevista va a ir necesarios
340
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
Peticin de cambio Anlisis de Realizar revisiones Informe de Modificaciones de

validada viabilidad tcnicas y revisar viabilidad de las requisitos
Estimacin inicial (impacto, P.C. % de errores en
de recursos y soluciones Estrategia de Informe del anli- la documentacin
dems informacin alternativas, pruebas. sis detallado. Esfuerzo por rea
registrada. implicaciones de Que la documen- Requisitos (SQA, SE, etc.)
Documentacin del seguridad, coste y tacin est actualizados (y Tiempo empleado
proyecto (si la beneficio de la completa y trazables) % de errores
hay). modificacin) actualizada e Lista preliminar generados por
Anlisis detallado incluye parmetros de mofificaciones. prioridad y tipo.
(SRS de la de seguridad Plan de pruebas
modificacin, Plan de Factores: flexibilidad
elementos a implementacin trazabilidad
modificar, usabilidad
estrategia de mantenibilidad
pruebas) reusabilidad
341
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.
Salidas de la fase Identificacin de Inspeccin / Revisados: Complejidad del

de anlisis. los mdulos verificacin del Lista de software
Documentacin del afectados. diseo modificacines Cambios diseo
sistema y del Documentacin de Anlisis detallado Esfuerzo por rea
proyecto las modificaciones Inspeccin / Plan de Cambios en
Cdigo, Creacin de casos verificacin de la implementacin planes de prueba
comentarios y de prueba para las documentacin actualizado Nmero de
bases de datos del modificaciones asociada Lnea base de mdulos
sistema. Identificacin y diseo N lneas de
creacin de Planes de cdigo aadidas o
pruebas de pruebas modificadas
regresin
Actualizacin de
documentacin
(SRS manuales)
342
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.
Resultados de la Codificacin y Revisiones de Revisados: Volumen (puntos

fase de diseo. pruebas unitarias cdigo Software de funcin /
Cdigo fuente y Integracin Verificacin de la actualizado. lneas de cdigo)
bases de datos del Anlisis de riesgos integracin. Documentacin Porcentaje de
sistema. Revisin de Verificacin de de diseo, errores
Documentacin del pruebas modificaciones y pruebas, generados.
sistema y del actualizaciones manuales
proyecto. de documentacin
documentacin. de formacin
Gestin de actualizados.
riesgos y Definicin de
supervisin riesgos e
durante las impactos.
pruebas Informe de
revisin de las
pruebas
343
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.
Informe de las Prueba funcional Las pruebas del Revisados: Porcentajes de

pruebas. del sistema. sistema se han Sistema revisado. errores por
Documentacin de Pruebas de realizado segn Informes de prioridad y tipo:
los planes de interfaz. los planes SQA. pruebas. Generados y
prueba, casos de Pruebas de Control de la corregidos.
prueba, regresin. gestin de la
procedimientos de configuracin de:
prueba, manuales cdigo, peticiones
de usuario, diseo. de cambio,
Sistema documentacin
actualizado de pruebas
344
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
Informes de Ejecucin de las Ejecucin de Nueva lnea base Porcentajes de

pruebas. pruebas de planes de del sistema. errores por
Sistema aceptacin a nivel aceptacin. Informe de prioridad y tipo:
completamente funcional. Auditora auditora Generados y
integrado. Ejecucin de funcional. funcional. corregidos.
Planes de pruebas pruebas de Puesta bajo Informe de
de aceptacin. interoperabilidad. control de pruebas de
Casos de prueba Ejecucin de configuracin de aceptacin.
de aceptacin. pruebas de la nueva
Procedimientos de regresin. documentcin.
aceptacin Establecimiento
de la nueva lnea
base del sistema.
Informe de los
resultados de
auditora
funcional.
345
Mantenimiento

7.- Entrega
Entrega del sistema modificado.
El sistema Auditora fsica de Ejecucin de la Informe de la Cambios en la

modificado segn la configuracin. auditora fsica de auditora fsica. documentacin
se represente en la Notificacin a la la configuracin. Documento de (manuales de
nueva lnea base. comunidad de Documento de descripcin de la usuario, de
usuarios. descripcin de la versin. operacin,
Desarrollo y versin. documento
archivo de una descripcin de
copia de seguridad versin, etc.)
del nuevo sistema.
Instalacin y
formacin de
usuarios.
346
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:
la medida cualitativa de la facilidad para comprender, corregir y adaptar o

mejorar el software.
Los factores que conforman la mantenibilidad de un sistema de software son:
Mayor o menor profesionalidad en las fases de diseo, codificacin y prueba.

Adecuada cualificacin del equipo desarrollador del software.
Facilidad de comprensin de la estructura del software.
Facilidad de uso del sistema.
Uso de lenguajes de programacin y sistemas operativos estandarizados.
Grado de normalizacin de la documentacin.
Disponibilidad de la documentacin de los casos de prueba.
Facilidades de depuracin con las que cuenta el sistema.
Disponibilidad de medios e infraestructura para realizar el mantenimiento.
Madurez en la planificacin del mantenimiento.
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:
Tiempos invertidos en las tareas de mantenimiento

Para indentificar el problema, para analizarlo, para modificar x lneas de cdigo, etc.
Midiendo la complejidad del sistema de software.
En esta lnea las propuestas de medicin apuntan a la medicin de la complejidad
ciclotmica, la legibilidad, etc.
Esta lnea presenta el problema de utilizar atributos indirectos que tambin son de difcil
medicin.
La mantenibilidad es un atributo de calidad del software.
348
Mantenimiento
Mantenibilidad
Reingeniera
Cmo abordar el mantenimiento de un sistema de software con problemas de

mantenibilidad?
No se dispone de documentacin (diseo, requisitos)

Con deficiente gestin de la configuracin.
Que ha sufrido mltiples y cambios que han degradado el sistema, o desfasado la
documentacin.
Analizar el sistema y decidir si conviene rehacerlo de nuevo, o por el contrario resulta

ms apropiado aplicar tcnicas de reingeniera.
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
Reconstruccin
hacer?
Ingeniera inversa
Ingeniera Reestructuracin Reestructuracin Reestructuracin Ingeniera

inversa de datos de cdigo de documentos progresiva
350
Mantenimiento
Mantenibilidad
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:
Identificacin del sistema de software

Ao de creacin
Nmero de cambios importantes realizados
Esfuerzo invertido en esos cambios
Fecha y esfuerzo del ltimo cambio importante
Sistema o sistemas en los que se integra el software
Sistemas con los que se relaciona
Bases de datos a las que accede
Errores detectados en los ltimos x meses (12)
Nmero de usuarios
Complejidad de la arquitectura, cdigo y documentacin
Calidad de la documentacin
Mantenibilidad general
Longevidad acumulada y previsible del proyecto
Nmero de cambios previstos en los prximos x meses
Coste anual del mantenimiento
Valor actual del negocio que gestiona
Importancia estratgica para el negocio del cliente y del desarrollador
351
Mantenimiento
Mantenibilidad
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:
Dejarlo como est

Razones:
Se trata de un sistema con escasa previsin de cambios futuros.
Se trata de un sistema que se encuentra cercano al fin de su ciclo de vida.
Los recursos necesarios para crear la documentacin no compensan con el beneficio
obtenido.
Documentar slo las partes que se modifican

Razones:
Se dispone de recursos limitados.
Tras el anlisis de inventario resulta necesario actualizar la documentacin.
Reducir la documentacin al mnimo imprescindible
Razones:
Se trata de un sistema crtico para el negocio.
Es preciso volver a documentarlo
352
Mantenimiento
Mantenibilidad
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
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
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
1.0
356
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
La versin del programa no coincide con la documentacin.
Estamos en la versin 2.3, y debemos revisar un error que se ha
producido en una instalacin de la versin 1.7. Dnde est el cdigo de
esa versin?
Ese error ya se corrigi hace un mes.. Porqu ha vuelto a aparecer?
Quin aprob esa modificacin de requisitos, y porqu no est en la
versin actual de SRS?
Se est dando mantenimiento a usuarios con diferentes versiones del
sistema Qu versin del componente de acceso a datos se integr en
la versin 2.0 del sistema?.
Etc.
357
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.
mbito de la gestin de la configuracin

De aplicacin Temporal
Los componentes del sistema y su Desde el inicio del proyecto hasta
relacin con el entorno que se deja de usar y se retira.
Entorno
Sistema
Desarrollo Mantenimiento
Ciclo de vida
[1] En la exposicin del captulo se abordan con detalle cada una de ellas.
358
Conceptos clave
Lnea base
Peticin de
Librera
cambio
Comit de Elementos de
control de la configuracin
configuracin del software
359
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:
Lnea base funcional

Describe las funcionalidades que realizar el sistema, y se establece despus de la
revisin de la descripcin del sistema y del diseo del sistema.
Lnea base de requisitos (tambin lnea base asignada)
Documenta las funciones que desarrollar el software y se establece despus de la
revisin de la especificacin de requisitos del software (SRS). Tambin se denomina
Lnea base asignada, porque en ella se asignan al software los requisitos de la
descripcin del sistema.
Lnea base de desarrollo
Esta lnea base crece y evoluciona durante el desarrollo del sistema y recoge la
configuracin en cada fase del diseo, codificacin y pruebas. Los elementos contenidos
en esta lnea base van incrementando y son normalmente revisados por el equipo del
desarrollo.
Lnea base de producto
Contiene el producto completo en su versin final. Se establece tras comprobar con la
validacin y verificacin del producto que ste es conforme a las especificaciones de los
requisitos.
360
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.
Producto: Productos intermedios o finales desarrollados durante el proyecto.
Software adquirido: Mdulos o componentes adquiridos o subcontratados.

Categoras
Software suministrado: Software proporcionado por el cliente para que se integre en el sistema.
Software de pruebas: Software empleado para realizar las pruebas.
Software de apoyo: Software empleado para desarrollar el sistema de software (compiladores, etc.)
361
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
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
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:
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.
364
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 Versin 1.1
365
reas clave
del software
Medicin del Control de las

Identificacin de Control de la Auditoras y
estado de la relaciones de
la configuracin configuracin revisiones
configuracin interfaz
366
reas clave
Identificacin de la configuracin
Determinacin de los elementos de configuracin del software y de las lneas
base a las que pertenecen.
Seleccin de los elementos de configuracin y agrupacin en lneas base.

Deben considerarse productos que puedan disearse, desarrollarse, probarse y
Identificacin
modificarse de forma independiente.
Documentos
Revisin
Cdigo Seleccin tcnica y Lneas base
formal
Datos
Actividades
No deben identificarse muy pocos, ni tampoco demasiados. Los criterios de

seleccin deben ser acordes con las caractersticas del proyecto.
Nomenclatura: Cada elemento de configuracin debe nombrarse con un identificador nico. Es

habitual que el identificador contenga:
Nomenclatura y
adquisicin
NOMBRE: descriptivo del elemento.

IDENTIFICADOR DE CONFIGURACION: Usado en la gestin interna de la librera.
IDENTIFICADOR DE VERSION: Usado para identificar las diferentes versiones.
Adquisicin: Una vez identificado cada elemento, debe incorporarse a su respectiva librera.
367
367
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.
Que para cada cambio se evala y considera el impacto en el proyecto.

Que slo se implementan los cambios aprobados.
Garantiza
Que todos los cambios aprobados se implementan.
Que las lneas base se mantienen controladas y actualizadas.
CLASIFICACIN
Aprobacin
Identificacin Por urgencia
o rechazo
del cambio Por Naturaleza (error, mejora, mod. Requisitos)
Por categora de elementos modificados (producto,
Software adquirido, Software suministrado, software
de pruebas o software de apoyo).
Comunicacin
Implementacin
formal
EVALUACIN
Tcnico
Check-out lnea base
En los interfaces de configuracin
Ejecucin de cambios
En la agenda
Pruebas y verificacin
Validacin En el presupuesto
Aprobacin de la ejecucin
y evaluacin Chech-in lnea base
368
reas clave
Medicin del estado de la configuracin

Medicin y registro de los cambios, contenidos e histricos de la gestin de la
configuracin
Versin inicial aprobada de los elementos de la configuracin.

Estado de las peticiones de cambio.
Registra
Estado de implantacin de los cambios aprobados.
Esta es la informacin mnima que debera registrarse (Std. IEEE 828-1998).
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:
Que los elementos de la configuracin se encuentran en el estado que

deberan estar.
Que las actividades, las tareas y los resultados de la gestin de la
configuracin son correctos.
369
reas clave
Control de las relaciones de interfaz

El desarrollo y mantenimiento de sistemas de software no suele ser auto-
contenido. 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 IMPLICCIONES DE INTERFAZ
El software debe ejecutarse La gestin de la configuracin

sobre plataformas operativas debe registrar tambin las
comerciales plataformas y componentes
externos, evaluando las posibles
evoluciones y cambios.
El producto de software debe
integrar componentes externos
El desarrollo de partes del Las gestiones de configuracin del proyecto de

software se subcontrata a un software y del subcontratado deben comunicarse y
proveedor externo. gestionar las implicaciones de cambio derivadas de uno
a otro.
La gestin de la configuracin del sistema global debe

Evolucin paralela del hardware relacionarse con la del proyecto de software por las
del sistema global implicaciones de cambios que pueden derivarse en sta
de aquella.
370
Control de versiones
Evolucin simple
1 2 3
Variantes
4.1
Tronco: 1.1 1.2 1.3

2.1 2.2 2.3 Cabeza: ltima versin del tronco
Ramas: 2.1 3.1.. 4.1.
Delta: Cambio de una versin respecto a
1 1.2 1.3 1.4 su anterior: 3.2<- 3.1 / 2.3 <- 2.2
3.1 3.2
371
Propagacin de cambios
Cambio aplicable a varias ramas
3.1 3.2 3.3
2.1 2.2 2.3 2.4
2.4 = 2.3 + (1.5 1.4)

1 1.2 1.3 1.4 1.5 3.3 = 3.2 + (1.5 1.4)
La herramientas de control de versiones suelen incorporar la funcionalidad Diff-Merge para

gestionar la propagacin de cambios.
372
Fusin de ramas
3.1 3.2
2.1 2.2 2.3 4.1 4.2
1 1.2 1.3 1.4 1.5

4.1 = 2.3 + (3.2 2.2)
4.1 = 3.2 + (2.3 2.2)
La herramientas de control de versiones suelen incorporar la funcionalidad Two-way merge

para gestionar la fusin de dos ramaz.
373
Tcnicas de almacenamiento
DELTAS DIRECTOS
Inicial cambios cambios cambios cambios

1.0 1.1 1.2 1.3 1.4 1.5
cambios 2.1 cambios 2.2
DELTAS INVERSOS
Final
1.1 cambios 1.2 cambios 1.3 cambios 1.4 cambios 1.5 1.5
cambios 2.1 cambios 2.2
374
Tcnicas de almacenamiento
MARCADO SELECTIVO
<< 1.3, 1.2
>>
<< 1.3
>>
La herramientas de control de versiones suelen incorporar funcionalidades diff o diff-merge para

recuperar el contenido de una versin, empleando una de estas tcnicas.
375
AGILIDAD
Entrega temprana
Incremento continuo
cc-by fox_kiyo
376
AGILIDAD: entrega temprana, incremento continuo
espublico.com safecreative.org
2000 2007
377
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 En costes Lo previsto

379
?
Time to market 1 ao Desperdicio: 80%
380
Visin: Informacin global y on-line de derechos de

propiedad intelectual en Internet
Requisitos:
Registro de obras con informacin de autora y derechos
y.
Fotografa cc-by: Frdric Dupont

381
INCERTIDUMBRE

382
VELOCIDAD
Fotografa cc-by:Amnemona
383
2.007 2.008 2.009 2.011
Time to market 2 meses Desperdicio: 20%
384
Registro bsico web.

Certificados y notas informativas
Web Mail Buscador bsico
Tienda virtual (libros e informtica) Registro desde RSS.
Legislacin Multiautora
Jurisprudencia Buscador avanzado
Subvenciones Notificaciones cesae & desist.
Modelos de expedientes Interfaz API
Formacin Aula virtual Programa cliente de registro (ART)
Noticias Plataforma de licenciamiento
Revista - entrevistas Monitor de ventas y iquidaciones
Foros Informacin de consultas y descargas
Encuestas Asistente para generacin de contratos
Preguntas frecuentes Licencias personalizadas
Consultas Licencias temporales
API y programa de registro remoto.
Asesora jurdica
Registro en U.S. Copyright Office
Directorio de contratos y consultas
Etc.
385
La gestin predictiva tiene como objetivo

construir el producto planificado en el tiempo y
con los costes previstos
386
La gestin gil tiene como objetivo entregar el

mayor valor posible en el menor tiempo, e
incrementarlo de forma constante
387
?
GESTIN PREDICTIVA: entrega de valor al cliente
Valor
Visin Objetivo: costes previst
Tiempo
Objetivo:
En la fecha prevista
Versin 1.0
388
GESTIN PREDICTIVA: entrega de valor al cliente
Valor
Visin
Tiempo
389
GESTIN GIL: entrega de valor al cliente
Valor
Tiempo
Versin
390
Valor
Tiempo
Versin
391
Valor
Tiempo
Versin
392
Valor
Tiempo
Versin
393
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 2.011
AGILIDAD
Valor temprano
Time to market 2 meses Desperdicio: 20%
Incremento continuo y
frecuente
395
POSTERIOR ANTTESIS A LOS MODELOS DE PROCESOS: AGILIDAD

Adaptaciones
para softw.
1997
TickIT
1991
ISO 9000-3
PROCESOS
1959 1979 1987 Trillium

1995
ISO 12207
para software.
especficos
1995 2003-05
Modelos
TR 15504
1993 Modelos 2001
CMM-SW CMM CMMI
DSDM
SCRUM
AGILIDAD
CRYSTAL
XP
ASD
PP
ISD
AM
2000
1995
Manifiesto gil
396
AGILIDAD
MANIFIESTO GIL
Marzo - 2001
Estamos poniendo al descubierto mejores

mtodos para desarrollar software
www.agilemanifesto.org
397
AGILIDAD
MANIFIESTO GIL
PERSONAS Y
SU INTERACCIN
VALOR
Cc by Santi Siri
HERRAMIENTAS
Y PROCESOS
Cc by Tech Writer Boy
398
AGILIDAD
MANIFIESTO GIL
SOFTWARE QUE
FUNCIONA
VALOR
Cc by Thor
DOCUMENTACIN
EXHAUSTIVA
Cc by Joe Hall
399
AGILIDAD
MANIFIESTO GIL
COLABORACIN
CON CLIENTE
VALOR
Cc by Karsten Konrad
NEGOCIACIN
CONTRACTUAL
Cc by Kate Bingaman
400
AGILIDAD
MANIFIESTO GIL
RESPUESTA
AL CAMBIO
VALOR
Cc by Jonny Hunter
SEGUIMIENTO
DE UN PLAN
Cc by J.P. Dalbra
401
AGILIDAD
Los 12 principios del manifiesto gil
1.- Nuestra principal prioridad es satisfacer

al cliente a travs de la entrega temprana
y continua de software de valor.
2.- Son bienvenidos los requisitos

cambiantes, incluso si llegan tarde al
desarrollo. Los procesos giles se doblegan
al cambio como ventaja competitiva para
el cliente.
402
AGILIDAD
3.- Entregar con frecuencia software que

funcione, en periodos de un par de
semanas hasta un par de meses, con
preferencia en los periodos breves.
4.- Las personas del negocio y los

desarrolladores deben trabajar juntos de
forma cotidiana a travs del proyecto.
403
AGILIDAD
5.- Construccin de proyectos en torno a

individuos motivados, dndoles la
oportunidad y el respaldo que necesitan y
procurndoles confianza para que realicen
la tarea.
6.- La forma ms eficiente y efectiva de

comunicar informacin de ida y vuelta
dentro de un equipo de desarrollo es
mediante la conversacin cara a cara
404
AGILIDAD
7.- El software que funciona es la principal

medida del progreso.
8.- Los procesos giles promueven el

desarrollo sostenido. Los patrocinadores,
desarrolladores y usuarios deben
mantener un ritmo constante de forma
indefinida.
405
AGILIDAD
9.- La atencin continua a la excelencia

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

maximizar la cantidad de trabajo que se
hace, es esencial.
406
AGILIDAD
11.- Las mejores arquitecturas, requisitos

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

reflexiona sobre la forma de ser ms
efectivo y ajusta su conducta en
consecuencia.
407
AGILIDAD
Prctica
cc-by: LizMarie
408
AGILIDAD
Prctica
15.- Minutos
En grupos
Palabra o palabras (Mx. 3)

de sntesis de cada principio
409
AGILIDAD
Ciclo de desarrollo gil
1.- Concepto
Visin del producto

410
AGILIDAD
2.- Especulacin
Presentacin y discusin con usuarios

411
AGILIDAD
3.- Exploracin
Desarrollo de un incremento
412
AGILIDAD
4.- Revisin
Entrega y retro-informacin
413
AGILIDAD
5.- Cierre
Producto final
414
AGILIDAD
Cierre
Concepto Especulacin
Iteraciones
Revisin Exploracin
415
AGILIDAD
MANIFIESTO GIL
1950 1960 1970 1980 1990 1990 2000
AGILIDAD
PROCESOS
416
AGILIDAD
ANTTESIS A LOS MODELOS DE PROCESOS: AGILIDAD

Adaptaciones
para softw.
1997
TickIT
1991
ISO 9000-3
PROCESOS
1959 1979 1987 Trillium

1995
ISO 12207
para software.
especficos
1995 2003-05
Modelos
TR 15504
1993 Modelos 2001
CMM-SW CMM CMMI
DSDM
SCRUM
AGILIDAD
CRYSTAL
XP
ASD
PP
ISD
AM
2000
1995
Manifiesto gil
417
AGILIDAD
EVOLUCIN DEL CONOCIMIENTO
1950 1960 1970 1980 1990 2000 2010
Crisis del
software
418
AGILIDAD
1950 1960 1970 1980 1990 2000 2010
Crisis del
software
TESIS
ISO 9001
ISO 9000-3
CMM
CMMI
SPICE

419
AGILIDAD
1950 1960 1970 1980 1990 2000 2010
Crisis del
software
TESIS
ANTTESIS
ISO 9001
ISO 9000-3
CMM XP
CMMI TDD - FDD
SPICE Scrum
Crystal

420
AGILIDAD
1950 1960 1970 1980 1990 2000 2010
Crisis del
software
TESIS
ANTTESIS
ISO 9001
ISO 9000-3 SNTESIS
CMM XP
CMMI TDD - FDD
SPICE Scrum
Crystal

421
AGILIDAD
Tesis1
Espiral del conocimiento. Hirotaka Takeuchi, Ikujiro Nonaka, Hitotsubashi on Knowledge Management, 2004
422
AGILIDAD
Tesis1 Anttesis1
423
AGILIDAD
Sntesis1
Tesis1 Anttesis1
424
AGILIDAD
Sntesis1
T2 A2
T TESIS
Tesis1 Anttesis1 A ANTTESIS
S SNTESIS
425
AGILIDAD
S3
T4
S2
Sntesis1 T3 A3
T2 A2
T TESIS
S SNTESIS
426
AGILIDAD
S3
T4
S2
Sntesis1 T3 A3
T2 A2
T TESIS
S SNTESIS
427
AGILIDAD
ANTTESIS A LOS MODELOS DE PROCESOS: AGILIDAD
Adaptaciones
para softw.
1997
TickIT
1991
TESIS
ISO 9000-3
PROCESOS
1959 1979 1987 Trillium

1995
ISO 12207
para software.
especficos
1995 2003-05
Modelos
TR 15504
1993 Modelos 2001
CMM-SW CMM CMMI
DSDM
SCRUM
ANTTESIS
AGILIDAD
CRYSTAL
XP
ASD
PP
ISD
AM
2000
1995
Manifiesto gil
428
(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 TECNOLOGA
433
Conocimiento
TESIS: Responsabilidad del resultado
PERSONAS
PROCESOS TECNOLOGA
434
Conocimiento
Anttesis: responsabilidad del resultado
PERSONAS
PROCESOS TECNOLOGA
435
Conocimiento
Visin de sntesis: Procesos = PROCEDIMIENTOS
PERSONAS
PROCEDIMIENTOS TECNOLOGA
Procesos
Rutinas
436
Conocimiento
Visin de sntesis: PERSONAS
Trabajo
PERSONAS
Conocimiento
PROCESOS TECNOLOGA
437
Conocimiento
Prctica: conocimiento tcito y explcito
cc-by: LizMarie
438
Conocimiento
sobre el conocimiento )
439
Sntesis entre procesos y
agilidad
440
Sntesis entre procesos y agilidad
Hiptesis inicial
PLANIFICACIN ADAPTACIN
441
gil, clsica, predictiva?
Clsica
Tradicional
Predictiva
formal
Pesada
Gestin de proyectos
gil
Adaptable
Evolutiva
Adaptativa
442
Premisas de la gestin de proyectos predictiva
Caractersticas y comportamientos
regulares
443
gil, clsica, predictiva?
OBJETIVO
A tiempo En costes Lo previsto
444
Caractersticas de la gestin de proyectos predictiva
UNIVERSALIDAD
PREVISIN
445
Gestin predictiva gestin evolutiva
PREDICTIVA EVOLUTIVA
Definicin Visin
Diseo Exploracin
Construccin Adaptacin
446
PREDICTIVA EVOLUTIVA
447
CRITERIOS DE IDONEIDAD
EVOLUTIVA PREDICTIVA
PRIORIDAD DE NEGOCIO Valor Cumplimiento
ESTABILIDAD DE REQUISITOS Entorno inestable Entorno estable
RIGIDEZ DEL PRODUCTO Modificable Difcil de modificar
COSTE DE PROTOTIPADO Bajo Alto
CRITICIDAD DEL SISTEMA Baja Alta
TAMAO DEL EQUIPO Pequeo Grande
448
Producto, fecha y costes planificados?
449
Mismo patrn de gestin para todos?
450
Criterios dependientes de:
EL CLIENTE
LA ORGANIZACIN
EL PROYECTO
451
Criterios
PRIORIDAD DE NEGOCIO
ESTRATEGIA REQUISITOS
DE DESARROLLO
NIVEL
PROFESIONAL MALEABILIDAD
CULTURA
ORGANIZACIN CRITICIDAD
TAMAO DEL EQUIPO

452
Prioridad de negocio
453
Requisitos
454
Maleabilidad (Materia prima)
455
Coste de prototipado
456
Coste de prototipado
COSTE / BENEFICIO
PROTOTIPADO
NO REHACER - PLANIFICAR PROBAR Y EXPLORAR

457
Criticidad del sistema
458
Tamao del equipo
459
Cultura de la organizacin
460
Nivel profesional
461
Modelo de desarrollo
462
CARACTERSTICAS DE LA ORGANIZACIN
NIVEL PROFESIONAL Senior Junior
CULTURA ORGANIZATIVA Horizontal, flexible Vertical, rgida
MODELO DE DESARROLLO Personas Procesos
463
CARACTERSTICAS DEL PROYECTO
PRIORIDAD DE NEGOCIO Valor Cumplimiento
ESTABILIDAD DE REQUISITOS Entorno inestable Entorno estable
RIGIDEZ DEL PRODUCTO Modificable Difcil de modificar
COSTE DE PROTOTIPADO Bajo Alto
CRITICIDAD DEL SISTEMA Baja Alta
TAMAO DEL EQUIPO Pequeo Grande
464
Scrum
465
Scrum
El origen de Scrum
The New New Product Development Game
1986 Nonaka Takeuchy & Ikujiro Nonaka
Fases 1 2 3 4 5 6
466
Scrum: el marco
Roles, componentes y reuniones
PP
PP
Exposicin de prioridades
Resolucin de dudas
E
Estimacin del esfuerzo para
cada requisito
Reunin diaria SM E
( )PP I
Objetivo del Sprint Revisin del trabajo;

resolucin de trabas
PP SM E
COMPONENTES
PRODUCT
BACKLOG
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
INC
SM PP E I
REUNIONES
PLANIFICACIN
DEL SPRINT Presentacin del incremento,
sugerencias, anuncio prximo sprint
DIARIA
REVISIN DEL
SPRINT
467
Scrum: el marco
Roles: comprometidos e implicados

Una gallina y un cerdo paseaban por la
carretera. La gallina dijo al cerdo: Quieres
abrir un restaurante conmigo. El cerdo
consider la propuesta y respondi: S, me
gustara. Y cmo lo llamaramos?. La gallina
respondi: Huevos con beicon.
El cerdo se detuvo, hizo una pausa y contest:

Pensndolo mejor, creo que no voy a abrir un
restaurante contigo. Yo estara realmente
comprometido, mientras que tu estaras slo
implicada.
468
Scrum: el marco
IMPLICADOS
Usuarios, Marketing,
Comercial, Cliente,
Direccin
COMPROMETIDOS
Propietario de
Equipo
producto
469
Scrum: el marco
Propietario
Visin del producto
producto
Auto-organizado
Equipo Multifuncional
Retro-informacin
Interesados Asesora
Scrum Garanta de funcionamiento

del modelo
Manager
470
Scrum: el marco
Implantaciones flexibles
Direccin
LA ASIGNACIN DE
RESPONSABILIDADES
Calidad RR.HH.
SE ADAPTA A LA
ORGANIZACIN
Oficina proyectos Comercial
Programacin
471
Scrum: el marco
Roles
Propietario del producto
Representa a todos los

interesados en el producto final.
Sus reas de responsabilidad son:
Financiacin del proyecto

Funcionalidad del sistema
Retorno de la inversin del proyecto
Lanzamiento del proyecto
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
Rol Scrum Master
En primeras implantaciones
En equipos con rotacin de personas
Asesora para product backlog al propietario del producto

Moderacin de reuniones, asesora estimacin, velocidad
Gestin de personas para trabajo colaborativo
Resolucin de impedimentos
Vigilar las formas scrum: objetivos de las reuniones,
revisiones diarias, compartir la visin, etc.
Asesora y formacin sobre el modelo y forma de trabajo
Agendas de sprints, y respeto a las pautas del modelo
477
Scrum: el marco
Componentes
Product Lista de funcionalidades del

Backlog sistema
Tareas que se van a realizar

Sprint en el sprint
Backlog
Incremento Parte del producto

desarrollada en un sprint
478
Scrum: el marco
Reuniones
Planificacin Cunto va a durar el sprint

del sprint y qu vamos a hacer?
Diaria Seguimiento diario del

avance
Revisin del Revisin del incremento

sprint realizado en el 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
Premisas para desarrollo gil

El sistema que necesita el cliente se puede descomponer en
funcionalidades
Tiene sentido y valor para el negocio del cliente poder
disponer de ellas de forma parcial y cuanto antes
Primera accin del cliente

Definir la visin de lo que quiere conseguir
Identificar las primeras necesidades (Product Backlog)
Priorizarlas segn el valor para su entorno de negocio
482
Scrum: el marco
Pila de producto (product backlog)
Los requisitos del sistema en un desarrollo gil estn

en continua revisin.
El backlog las lista como historias de usuario
priorizadas por las necesidades de negocio del cliente
Lista de funcionalidades1 del sistema
Priorizadas
Documento vivo
Accesible a todos los roles
Todos pueden contribuir y aportar elementos
Es propiedad del responsable del producto
(product manager, product owner, cliente,
marketing, etc.)
(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 Visin del producto
ConOps
ISO/IEC 12207
Product Backlog
IEEE 1362 Historias de usuario
SOFTWARE
Objetivo del sprint
SRS Historias de usuario
IEEE 830
Sprint Backlog
484
Scrum: el marco
Requisitos con gestin predictiva y evolutiva
485
Scrum: el marco
Ejercicio
Product Backlog
Funcionalidades estimadas
486
Scrum: el marco
Ejercicio
Product Backlog
Caractersticas del product backlog
Estimadas
Documento vivo
Se trata de determinar
Cmo de valiosa o urgente es cada funcionalidad
Cmo de costosa es cada funcionalidad
Y tener los criterios de decicin para
La reunin de planificacin de sprint

487
Scrum: el marco
Ejercicio
Planificacin del sprint

1.- Calcular la velocidad del equipo
2.- Funcionalidades prioritarias del cliente
3.- Descomposicin en tareas, estimacin y asignacin
4.- Plan del sprint y Sprint Backlog
488
Scrum: el marco
Ejercicio

AUTOGESTIN DEL EQUIPO
Cliente y programadores determinan cunto tiempo va a
durar el Sprint, y qu van a hacer
Descomponen, estiman y asignan el trabajo (no un gestor de
proyectos)
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
Sprint
Esfuerzo pendiente
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Seguimiento diario
Grfica Burn Down como indicador de progreso
El avance se mide por lo que falta, no por lo que se ha
hecho
491
Scrum: el marco
Los componentes de scrum

FUNCIONALIDADES
PRIORIDAD
PRODUCT
BACKLOG
Ciclo de
trabajo
Sprint
(xx das)
SPRINT
BACKLOG INCREMENTO
492
Scrum: el marco
Pila de producto
Ejemplo de formato
Id Prioridad Descripcin Est. Por

1 Muy alta Plataforma tecnolgica 30 AR
2 Muy alta Interfaz usuario 40 LR
3 Muy alta Un usuario se registra en el sistema 40 LR
4 Alta El operador define el flujo y textos de un expediente 60 AR
5 Alta Etc 999 XX
493
Scrum: el marco
Pila de producto
Ejemplo de formato
Id Prioridad Mdulo Descripcin Est. Por

1 Muy alta Plataforma tecnolgica 30 JM
2 Muy alta Interfaz de usuario 40 LR
3 Muy alta Un usuario se registra en el sistema 40 LR
4 Alta Trastienda El operador define el flujo y textos de un expediente 60 JM
5 Alta Trastienda Etc 999. XX
494
Scrum: el marco
Pila de producto
Ejemplo de formato
Id Orden Est. Descripcin Criterio validacin Obs.

Se tiene el diagrama de la arquitectura, La arquitectura debe permitir
1 10 30 Plataforma tecnolgica
validado por xxx escalabilidad por clusterizacin de
Todas las pantallas de interfaz estn Debe estar interfaz para las
2 20 40 Prototipos interfaz usuario
dibujadas y se puede recorrer toda la func funcionalidades de la pila a fecha
Diagrama BB.DD. Realizado, validado por
3 30 40 Diseo de datos
xxx
El operador define el flujo y textos de Definir completamente un expediente con
4 40 60 un expediente la funcionalidad programada
5 50 999. Etc Etc
495
Scrum: el marco
Pila de producto
Ejemplo de formato
Id Mdulo Descripcin Est. Por

Crtico
1 Plataforma tecnolgica 30 AR
2 Cliente Interfaz de usuario 40 LR
3 Cliente Un usuario se registra en el sistema 40 LR
4 Trastienda El operador define el flujo y textos de un expediente 60 AR
5 Trastienda Etc 999. XX
Necesario
6 Cliente El usuario modifica su ficha personal 30 AR
7 Cliente El usuario consulta los expedientes asignados 15 LR
8 Cliente El usuario tramita un expediente 35 LR
496
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
Pila del sprint

Funcionalidades que se van a realizar
en el sprint
Comprometidas por el equipo
Asignadas
Estimadas
498
Scrum: el marco
Pila del sprint
499
Scrum: el marco
Incremento
Entregable
Terminada!
Implementada Probada Documentada
500
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
REVISIN
trabajo DEL SPRINT
PLANIFICACIN
DEL SPRINT Sprint
(15 30 das)
Incremento
502
Scrum: el marco
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
PRODUCT BACKLOG
PRODUCTO DESARROLLADO
INFORMACIN ENTORNO
OBJETIVO PLAN DEL

SPRINT
DEL
BACKLOG SPRINT
SPRINT
504
Scrum: el marco
Mximo: 1 da
Exposicin Resolucin
Product backlog Sprint backlog
505
Scrum: el marco
Seguimiento del sprint (stand up)
Reunin del equipo con duracin mxima de 15 minutos.

Todos los das en el mismo sitio y a la misma hora.
Se recomienda que sea la primera actividad del da.
Deben acudir todos los miembros del equipo.
Se recomienda estar de pie.
Moderada por el Scrum Manager o Team Leader.
Las tres preguntas

Qu trabajo has realizado desde la ltima reunin?
Qu tienes previsto para hoy?
Qu necesitas?
506
Scrum: el marco
Revisin del sprint
PRESENTACIN DEL EQUIPO AL PROPIETARIO DEL PRODUCTO

Y TODOS LOS IMPLICADOS (GALLINAS) DEL INCREMENTO
REALIZADO EN EL SPRINT
Duracin mxima: 4 horas.

Se muestra el producto realizado: NO
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.
507
Scrum: mtricas
Mtricas: fondos de escala
ORGANIZACIN PROYECTO DESARROLLO
Rendimiento Esfuerzo Densidad de fallos

Satisfaccin Coste Complejidad de diseo
clientes
Tamao Disponibilidad
Eficiencia

Desempeo

508
Scrum: mtricas
Mtricas: fondos de escala
ORGANIZACIN PROYECTO DESARROLLO
Rendimiento Esfuerzo Densidad de fallos

Satisfaccin Coste Complejidad de diseo
clientes
Tamao Disponibilidad
Eficiencia

Desempeo

509
Scrum: mtricas
Mtrica ?
VALOR APORTADO VALOR POR OMITIRLA

510
Scrum: mtricas
Magnitudes: velocidad trabajo - tiempo
Velocidad = Trabajo / Tiempo
511
Scrum: mtricas
Unidades de tiempo
Tiempo real
Sprint
512
Scrum: mtricas
Unidades de trabajo
Tiempo ideal
Puntos
513
Scrum: mtricas
Unidades de trabajo: tiempo ideal
Tiempo ideal
Cunto cuesta programar el En tiempo ideal, o
registro de un nuevo usuario? en tiempo real?
514
Scrum: mtricas
Cunto dura un partido de Baloncesto?
Tiempo ideal: 40 minutos

Tiempo real: > 2 horas Fotografa cc-by: SD
515 Dirk
Scrum: mtricas
Tiempo ideal
Sin interrupciones
Est disponible todo lo que se necesita
Estado mental ptimo
516
Scrum: mtricas
Puntos
Cantidad de trabajo considerando:
Dificultad
Tamao
Unidad relativa
Unidad propia del equipo / organizacin
517
Scrum: mtricas
cc-by: LizMarie
518
Scrum: mtricas
Estimacin de pquer: serie natural
0 1 2 3 5
0 1 2 3 5
0 1 2 3 5
6 7 ?
6 7 ? 7

6 ?
519
Scrum: mtricas
Estimacin de pquer: serie Fibonacci
0 1 2 3 5
0 1 2 3 5
0 1 2 3 5
8 13 21 ?
8 13 21 ?

8 13 21 ?
520
Scrum: mtricas
Prctica de estimacin de pquer
cc-by: LizMarie
521
Scrum: mtricas
Medicin del trabajo
La gestin gil NO determina el

grado de avance del proyecto
midiendo el trabajo realizado,
sino el pendiente de realizar
522
Scrum: mtricas
Medicin del trabajo
SCRUM MIDE EL TRABAJO PENDIENTE
A Para estimar
esfuerzo y
B
200
duracin de las
150
tareas
100
Seguir el
avance del
50
proyecto
7-feb
8-feb
1-feb
2-feb
3-feb
6-feb
523
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
TAREAS DE TAMAO PEQUEO
525
Scrum: mtricas
Unidades giles
Velocidad
Trabajo
Por
Sprint
Fotografa cc-by: fdecomite (Scrum acadmico)
526
Scrum: mtricas
Unidades giles
Velocidad
Trabajo por
unidad de
tiempo
Fotografa cc-by: Luis (Scrum flexible)
Argerich
527
Scrum: prcticas
Product Backlog
Id Historias Trabajo Criterio de validacin

1 Historia A 1.0 150 Lorem ipsum dolor sit amet
2 Historia B 1.0 250 consectetuer adipiscing elit
3 Historia C 1.0 250 Aliquam vehicula accumsan tortor
4 Historia D 1.0 300 Pellentesque turpis
5 Historia A 1.1 250 Phasellus purus orci
6 Historia D 1.1 350 penatibus et magnis dis parturient
7 Historia E 1.0 150 Quisque volutpat ante sit amet velit
8 Historia B 1.1 500 Cras iaculis pede eu tellus
9 Historia C 1.1 150 Vestibulum vel diam sed pede blandit
10 Historia E 1.1 200 Suspendisse aliquam felis et turpis
11 Historia F 1.0 TBD Nullam imperdiet lorem vitae justo
12 Historia A.1.2 TBD Suspendisse potenti. In nec nunc
13 Historia B 1.2 TBD Nam eros tellus, facilisis sed, pretium
14 Historia F 1.1 TBD Morbi arcu tellus, condimentum
528
Scrum: prcticas
Plan de producto: Grfico burn-up
Id Historias Trabajo Criterio de validacin

1 Historia A 1.0 150 Lorem ipsum dolor sit amet
Estimacin:
2 Historia B 1.0 250 consectetuer adipiscing elit 950 PUNTOS
3 Historia C 1.0 250 Aliquam vehicula accumsan tortor
4 Historia D 1.0 300 Pellentesque turpis Versin 1.0
5 Historia A 1.1 250 Phasellus purus orci
6 Historia D 1.1 350 penatibus et magnis dis parturient 1.700 PUNTOS
7 Historia E 1.0 150 Quisque volutpat ante sit amet velit Versin 1.1
8 Historia B 1.1 500 Cras iaculis pede eu tellus
9 Historia C 1.1 150 Vestibulum vel diam sed pede blandit2.550 PUNTOS
10 Historia E 1.1 200 Suspendisse aliquam felis et turpis Versin 1.2
11 Historia F 1.0 TBD Nullam imperdiet lorem vitae justo
12 Historia A.1.2 TBD Suspendisse potenti. In nec nunc
13 Historia B 1.2 TBD Nam eros tellus, facilisis sed, pretium
14 Historia F 1.1 TBD Morbi arcu tellus, condimentum
529
Scrum: prcticas
Equipo Sprint
Versin 1.2
Product Backlog en esfuerzo estimado
Versin 1.1
4 personas 20 das
laborables Versin 1.0
(1 mes)
Velocidad del equipo: 400 puntos
1 2 3 4 5 6 7 8
Sprints 1 - MAR 1 - ABR 1 - MAY 1 - JUN 1 - JUL 1 - AGO 1 - SEP
530
Scrum: prcticas

1 2 3 4 5 6 7 8
531
Scrum: prcticas

1 2 3 4 5 6 7 8
532
Scrum: prcticas

1 2 3 4 5 6 7 8
533
Scrum: prcticas

1 2 3 4 5 6 7 8
534
Scrum: prcticas

Versin 1.0
1 2 3 4 5 6 7 8
535
Scrum: prcticas

Versin 1.0
1 2 3 4 5 6 7 8
536
Scrum: prcticas
Versin 1.2
Versin 1.1
Versin 1.0
1 2 3 4 5 6 7 8
537
Scrum: prcticas
Evolucin del esfuerzo pendiente en la pila del sprint
538
Scrum: prcticas
Grfico de avance (burn down)

Esfuerzo pendiente
11
1
10
12
13
14
15
16
17
18
Das del Sprint
539
Scrum: prcticas
Se cumplimenta da a da
200
150
100
50
7-feb
8-feb
1-feb
2-feb
3-feb
6-feb
540
Scrum: prcticas
Indicador de progreso del sprint

Esfuerzo pendiente
3
2
10
11
12
13
14
15
16
17
18
Plan segn las estimaciones al inicio del sprint
541
Scrum: prcticas

Esfuerzo pendiente
3
2
10
11
12
13
14
15
16
17
18
Esfuerzo pendiente
542
Scrum: prcticas

Esfuerzo pendiente
3
2
10
11
12
13
14
15
16
17
18
543
Scrum: prcticas

Esfuerzo pendiente
3
2
10
11
12
13
14
15
16
17
18
544
Scrum: prcticas

Esfuerzo pendiente
3
2
10
11
12
13
14
15
16
17
18
545
Kanban
Conceptos kanban y lean engestin gil
1.0
cc-by Rool Paap
546
Kanban (Conceptos kanban y lean en gestin gil)
? SCRUM CMMI
KANBAN
XP TDD
LEAN
PMI
cc-by: Frdric Dupont
SCRUMBAN
547
PROPIETARIO DEL
SCRUM
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
PP
PP
Resolucin de dudas
E
cada requisito
Reunin diaria SM E
( )PP I
PROPIETARIODEL
PROPIETARIO DEL
PRODUCTO
PRODUCTO Objetivo del Sprint Revisin del trabajo;
resolucin de trabas
PP SM E
COMPONENTES
PRODUCT
BACKLOG
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
INC
SM PP E I
REUNIONES
PLANIFICACIN
DIARIA
REVISIN DEL
SPRINT
548
PROPIETARIO DEL
PRODUCTO
KANBAN
EQUIPO
SCRUM MASTER /
MANAGER
PP
PP
Resolucin de dudas
E
cada requisito
Reunin diaria SM E
( )PP I
PROPIETARIODEL
PROPIETARIO DEL
PRODUCTO
resolucin de trabas
PP SM E
COMPONENTES
PRODUCT
BACKLOG
SCRUM PRESCRIBE ROLES
PDP
SPRINT
BACKLOG
PDS
INCREMENTO KANBAN NO
INC
SM PP E I
REUNIONES
PLANIFICACIN
DIARIA
Kanban and Scrum making the most of both

REVISIN DEL Henrik kniberg & Mattias Skarin
SPRINT
549
PROPIETARIO DEL
KANBAN
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
PP
PP
Resolucin de dudas
E
cada requisito
Reunin diaria SM E
( )PP I
PROPIETARIODEL
PROPIETARIO DEL
PRODUCTO
resolucin de trabas
PP SM E
COMPONENTES
PRODUCT SCRUM TRABAJA CON ITERACIONES DE
TIEMPO FIJO
BACKLOG
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
INC
KANBAN TRABAJA CON CADENCIAS (SIMPLES,
MLTIPLES O DIRIGIDAS POR EVENTOS)
SM PP E I
REUNIONES
PLANIFICACIN
DIARIA

SPRINT
550
PROPIETARIO DEL
KANBAN
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
PP
PP
Resolucin de dudas
E
cada requisito
Reunin diaria SM E
( )PP I
PROPIETARIODEL
PROPIETARIO DEL
PRODUCTO
resolucin de trabas
PP SM E
COMPONENTES
PRODUCT SCRUM LIMITA EL WIP POR ITERACIN
BACKLOG
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
KANBAN LIMITA EL WIP POR ESTADO DEL
INC
FLUJO DEL TRABAJO
SM PP E I
REUNIONES
PLANIFICACIN
DIARIA

SPRINT
551
PROPIETARIO DEL
KANBAN
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
PP
PP
Resolucin de dudas
E
cada requisito
Reunin diaria SM E
( )PP I
PROPIETARIODEL
PROPIETARIO DEL
PRODUCTO
resolucin de trabas
PP SM E
COMPONENTES
PRODUCT LOS EQUIPOS DE SCRUM SON
MULTIDISCIPLINARES
BACKLOG
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
INC
EN KANBAN PUEDEN SER DE ESPECIALISTAS
SM PP E I
REUNIONES
PLANIFICACIN
DIARIA

SPRINT
552
PROPIETARIO DEL
KANBAN
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
PP
PP
Resolucin de dudas
E
cada requisito
Reunin diaria SM E
( )PP I
PROPIETARIODEL
PROPIETARIO DEL
PRODUCTO
resolucin de trabas
PP SM E
COMPONENTES
PRODUCT SCRUM NO PERMITE CAMBIAR TAREAS DEL
SPRINT
BACKLOG
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
INC
EN KANBAN LA TAREA PUEDE ALTERARSE
HASTA ENTRAR EN EL FLUJO
SM PP E I
REUNIONES
PLANIFICACIN
DIARIA

SPRINT
553
PROPIETARIO DEL
KANBAN
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
PP
PP
Resolucin de dudas
E
cada requisito
Reunin diaria SM E
( )PP I
PROPIETARIODEL
PROPIETARIO DEL
PRODUCTO
resolucin de trabas
PP SM E
COMPONENTES
PRODUCT EN SCRUM LA PILA DE PRODUCTO DEBE TENER
LA LONGITUD DE AL MENOS UN SPRINT
BACKLOG
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
INC
EN KANBAN SE DEBE ATENDER AL RITMO DE
ARRASTRE DE TAREAS
SM PP E I
REUNIONES
PLANIFICACIN
DIARIA

SPRINT
554
PROPIETARIO DEL
KANBAN
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
PP
PP
Resolucin de dudas
E
cada requisito
Reunin diaria SM E
( )PP I
PROPIETARIODEL
PROPIETARIO DEL
PRODUCTO
resolucin de trabas
PP SM E
COMPONENTES
PRODUCT EN SCRUM SE DEBEN ESTIMAR LAS HISTORIAS
Y LAS TAREAS Y CALCULAR LA VELOCIDAD
BACKLOG
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
INC
KANBAN NO MIDE TAREAS NI VELOCIDAD
SM PP E I
REUNIONES
PLANIFICACIN
DIARIA

SPRINT
555
PROPIETARIO DEL
KANBAN
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
PP
PP
Resolucin de dudas
E
cada requisito
Reunin diaria SM E
( )PP I
PROPIETARIODEL
PROPIETARIO DEL
PRODUCTO
resolucin de trabas
PP SM E
COMPONENTES
PRODUCT SCRUM NECESITA UNA PILA DE PRODUCTO
PRIORIZADA
BACKLOG
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
INC
EN KANBAN ES LA SIGUIENTE HISTORIA O
TAREA ARRASTRADA DESDE EL CLIENTE
SM PP E I
REUNIONES
PLANIFICACIN
DIARIA

SPRINT
556
PROPIETARIO DEL
KANBAN
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
PP
PP
Resolucin de dudas
E
cada requisito
Reunin diaria SM E
( )PP I
PROPIETARIODEL
PROPIETARIO DEL
PRODUCTO
resolucin de trabas
PP SM E
COMPONENTES
PRODUCT SCRUM PRESCRIBE REUNIONES DIARIAS
BACKLOG
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
KANBAN NO
INC
SM PP E I
REUNIONES
PLANIFICACIN
DIARIA

SPRINT
557
PROPIETARIO DEL
KANBAN
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
PP
PP
Resolucin de dudas
E
cada requisito
Reunin diaria SM E
( )PP I
PROPIETARIODEL
PROPIETARIO DEL
PRODUCTO
resolucin de trabas
PP SM E
COMPONENTES
PRODUCT SCRUM EMPLEA DIAGRAMAS BURNDOWN
BACKLOG
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
KANBAN NO
INC
SM PP E I
REUNIONES
PLANIFICACIN
DIARIA

SPRINT
558
PROPIETARIO DEL
KANBAN
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
PP
PP
Resolucin de dudas
E
cada requisito
Reunin diaria SM E
( )PP I
PROPIETARIODEL
PROPIETARIO DEL
PRODUCTO
resolucin de trabas
PP SM E
COMPONENTES
PRODUCT LOS TABLEROS SCRUM SE RESETEAN AL FINAL
DE CADA SPRINT
BACKLOG
PDP
SPRINT

BACKLOG
PDS
INCREMENTO
INC

SM PP E I
REUNIONES
PLANIFICACIN
DIARIA

SPRINT
559
PROPIETARIO DEL
KANBAN
PRODUCTO
EQUIPO
SCRUM MASTER /
MANAGER
PP
PP
Resolucin de dudas
E
cada requisito
Reunin diaria SM E
( )PP I
PROPIETARIODEL
PROPIETARIO DEL
PRODUCTO
resolucin de trabas
PP SM E
COMPONENTES
PRODUCT KANBAN Y SCRUM PERMITEN TRABAJAR EN
VARIOS PROYECTOS A LA VEZ
BACKLOG
PDP
SPRINT
BACKLOG
PDS
INCREMENTO
INC
AMBOS SON LEAN Y GILES
SM PP E I
REUNIONES
PLANIFICACIN ETC.. Presentacin del incremento,
DEL SPRINT
DIARIA

SPRINT
560
561
SCRUM CMMI
KANBAN
XP TDD
LEAN
PMI
SCRUMBAN
562
MAPA DE SITUACIN: GESTIN DE PROYECTOS

Estrategia Tctica
Prcticas
PREDICTIVA
PMBOK
GESTIN
INGENIERA
SECUENCIAL
Prcticas giles
INGENIERA
EVOLUTIVA
CONCURRENTE
GESTIN
Procesos
o
AGILIDAD
563
MAPA DE SITUACIN: GESTIN PREDICTIVA

Estrategia Tctica
Prcticas
PREDICTIVA
PMBOK
GESTIN
INGENIERA
SECUENCIAL
Prcticas giles
INGENIERA
EVOLUTIVA
CONCURRENTE
GESTIN
Procesos
o
AGILIDAD
564
MAPA DE SITUACIN: GESTIN EVOLUTIVA

Estrategia Tctica
Prcticas
PREDICTIVA
PMBOK
GESTIN
INGENIERA
SECUENCIAL
Prcticas giles
INGENIERA
EVOLUTIVA
CONCURRENTE
GESTIN
Procesos
o
AGILIDAD
565
MAPA DE SITUACIN: INGENIERA CONCURRENTE

Estrategia Tctica
Prcticas
PREDICTIVA
PMBOK
GESTIN
INGENIERA
SECUENCIAL
Prcticas giles
INGENIERA
EVOLUTIVA
CONCURRENTE
GESTIN
Procesos
o
AGILIDAD
566
MAPA DE SITUACIN: AGILIDAD

Estrategia Tctica
Prcticas
PREDICTIVA
PMBOK
GESTIN
INGENIERA
SECUENCIAL
Prcticas giles
INGENIERA
EVOLUTIVA
CONCURRENTE
GESTIN
Procesos
o
AGILIDAD
567
MAPA DE SITUACIN: AGILIDAD: PRCTICAS SCRUM

Estrategia Tctica
Prcticas
PREDICTIVA
PMBOK
GESTIN
INGENIERA
SECUENCIAL
Prcticas giles
INGENIERA
EVOLUTIVA
CONCURRENTE
GESTIN
Procesos
o
AGILIDAD
568
MAPA DE SITUACIN: AGILIDAD: PRCTICAS KANBAN

Estrategia Tctica
Prcticas
PREDICTIVA
PMBOK
GESTIN
INGENIERA
SECUENCIAL
Prcticas giles
INGENIERA
EVOLUTIVA
CONCURRENTE
GESTIN
Procesos
o
AGILIDAD
569
Artesanal
En cadena
Informacin y gestin
CMMI KANBAN
KANBAN
ANDON
Modelos de visual
Tcnicas
produccin Lean Prevencin de POKA YOKE
errores
Herramientas polivalentes
TDD
Predictivo
Modelos de gil Incremento iterativo

(Produccin basada en personas)
Gestin de Evolutivo
(Incremento: Sprint principio: time
boxing)
proyectos Ingeniera Incremento continuo
concurrente
(Produccin basada en procesos) (Incremento: Historia de usuario principio: flujo
lean)
570
VDEO
571
VDEO
572
PRINCIPIOS Kanban (Conceptos kanban y lean en gestin gil)
METODOLOGAS
XP
SCRU TDD
M PMI
CMMISCRUMBAN
573
Experta
Principios
Conocimiento tcito
GESTIN
Tcnica
Tcnicas
Conocimiento explcito
574
DE LA ARTESANA
A LA MANUFACTURA
LEAN 1.0
cc-by State Library of South Australia
575
PRCTICA: De la artesana a la manufactura lean
Fotografa cc-by: LizMarie
576
Los principales culpables de lean
Adam Smith (1723-1790) Frederick Taylor (1856 Henry Ford (1863 1947)
Divisin del trabajo 1915)
Produccin en cadena
Organizacin cientfica del
trabajo
USTED
EST
AQU
Kitchiro Toyoda Taichi Edwards Deming (1894 -

Ohno 1993)
Bsqueda continua de la
Produccin: just in time,
calidad
pull y sin desperdicio
Modelo Toyota o Lean
577
MAPA DE SITUACIN: MODELOS DE PRODUCCIN
Artesanal
Modelos de KANBAN
En cadena
produccin Informacin y gestin
visual ANDON
Tcnicas
Lean Prevencin de POKA YOKE
errores
Herramientas polivalentes
578
GESTIN PREDICTIVA / GESTIN EVOLUTIVA

Estrategia Tctica
Prcticas
PREDICTIVA
PMBOK
GESTIN
INGENIERA
SECUENCIAL
Prcticas giles
INGENIERA
EVOLUTIVA
CONCURRENTE
GESTIN
Procesos
Incremento
o
Iterativo
AGILIDAD
Incremental Incremento Fases solapadas Personas
continuo
579
PRCTICA: Agile Coins
580
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
581
PRCTICA: Para gestionar un DESARROLLO INCREMENTAL
Con un flujo continuo de trabajo Sin empaquetar tareas en

timeboxing (sprints)
Son apropiadas las tcnicas de gestin visual kanban para

evitar los cuellos de botella y los tiempos muertos.
Ajustndolas con criterios de flexibilidad a las circunstancias

de nuestro trabajo y equipo
Secuencial Polivalente
Trabajo Equipo
Libre Especialistas
582
PRCTICA: Agile Coins
583
CONTROL VISUAL
cc-by Truth About
584
EL ORIGEN DE KANBAN
Taiichi Ohnos
Los dos pilares del sistema de produccin de Toyota son just-

in-time y automatizacin humanizada o autonomatizacin
(autonomation). La herramienta que utilizamos para operar
con el sistema es kanban. Taiichi Ohnos
585
EL ORIGEN DE KANBAN
KANBAN
Tarjeta de seal
586
EJEMPLO: KANBAN DE MONTAJE
Tarjeta Kanban de montaje

de un Toyota Corolla
Se adhiere al auto en la
cadena de montaje.
Contiene indicaciones
legibles para humanos y
mquinas de todos los
detalles del vehculo.
587
SISTEMA DE CONTROL VISUAL KANBAN
Kanban de transporte
Kanban de produccin cc-by Gregory Melle
588
LA GESTIN VISUAL FAVORECE LA COMUNICACIN DIRECTA
TABLEROS KANBAN
Herramienta de gestin
visual
cc-by Rool Paap
Emplear etiquetas para registrar epics, historias o tareas, y

diferentes marcas o su posicin en el tablero para
representar su estado de desarrollo.
589
KANBAN: ES UN MODELO DE GESTIN?
Cmo es el modelo de
gestin Kanban?
cc-by-sa ImproveIt
cc-by Ivan Walsh
cc-by-sa ImproveIt
cc-by Gilgongo
cc-by heliomedeiros
590
KANBAN NO ES UN MODELO DE GESTIN
Cmo es el modelo de
gestin Kanban?
Un tablero kanban es cc-by-sa ImproveIt
una herramienta para

cc-by Ivan Walsh
GESTIN GIL
cc-by heliomedeiros
cc-by Gilgongo
cc-by-sa ImproveIt
591
cc-by-sa ImproveIt
Cul es el formato
correcto de un tablero
kanban?
cc-by Dennis Hamilton
cc-by Gregg cc-by alq666

cc-by-sa ImproveIt
592
Cul es el formato
cc-by-sa ImproveIt
correcto de un tablero
kanban? cc-by Dennis Hamilton
Depende del uso, informacin

que gestiona y preferencias del
equipo
FLEXIBILILDAD
cc-by Gregg
cc-by-sa ImproveIt
cc-by alq666
593
INFORMACIN CONTROL GESTIN VISUAL
cc-by-sa H.D.N cc-by Rool Paap
594
VDEO
595
Kanban para regular el
FLUJO DE AVANCE
CONTINUO
cc-by Randen Pederson
596
EJERCICIO
597
TEORA DE COLAS
W
Wq Ws
Nq NS
N
: Tasa media de entradas (n op / unidad Wq: Tiempo en la cola

tiempo)
Ws: Tiempo se servicio operacin
Nq: Operaciones en la cola W: Tiempo total en el sistema
Ns: Operaciones siendo servidas : Tasa media del servicio (n op / unidad
N: Operaciones en el sistema tiempo)
598
PARA AJUSTAR EL FLUJO DE UN TABLERO KANBAN
W
PENDIENTE EN CURSO HECHO
Loremsit Lorem Lorem Lorem Lorem

Lorem Lorem amet, Ipsum Ipsum Ipsum Lorem
Ipsums
Ipsum Ipsums consecutur dolor sit dolor sit Ipsum
uy lskd
dkd
Nq NS
N
Nq: WIP de la pila W: Lead time
Ns: WIP de la fase de : Ritmo de (carga)
ejecucin entrada
=
N: WIP del sistema : Ritmo de salida
599
SISTEMA ESTACIONARIO DE FLUJO CONTINUO
=1 =
Lorem < 1 Infrautilizado
= 1 Estacionario
Lorem
Lorem Lorem Ipsums
Ipsum
Ipsum Ipsums uy lskd
> 1 Saturado
dkd
600
ACTUANDO SOBRE Y/O
REA DE GESTIN REA DE GESTIN

PROPIETARO DEL PRODUCTO EQUIPO
Tcticas:
RGIMEN DE DISCIPLINA DE LA COLA WIP LEAD TIME
LLEGADAS
(Ritmo) (Priorizacin) (Ajuste del (Lean)

WIP)
601
EL PROPIETARIO DEL PRODUCTO

RGIMEN DE LLEGADAS AJUSTANDO EL RITMO DE DEMANDA A LA CAPACIDAD
DEL SISTEMA
Sin sobrepasar el WIP de entrada al sistema.
DISCIPLINA DE LA COLA PRIORIZANDO LOS TRABAJOS. CRITERIOS POSIBES:
? FIFO (First-In, First-Out) o FCFS (First-Come, First-Served). Las tareas se

desarrollan en el orden van llegando.
x LIFO (Last-In, First-Out) o LCFS Se hacen primero las ltimas tareas en
llegar.
x SIRO (Service In Random Order) Se atienden las tareas de forma
aleatoria.
?
SIFO (Shortest-in, First-out) o SJF (Shortest job first) Se de prioridad a
las tareas que necesitan menos tiempo.
! RR (Round Robin, o turno robado). Se reparte el tiempo de trabajo por
igual para atender a las tareas de la cola a la vez.
? PR. Segn la prioridad.
Con interrupcin. Al llegar una tarea de ms prioridad se interrumpe la
que est en curso
Sin interrupcin. Al terminar la tarea en curso se atiende a la de
mayor prioridad.
x Inapropiado para gestin de tareas ! Incrementa el lead time ? A evaluar por el propietario del producto
602
EL EQUIPO
ESTABLECIENDO LMITES WIP ADECUADOS ALA

WIP CAPACIDAD DEL SISTEMA
Establecer un WIP adecuado al tiempo de proceso aceptable por el cliente
1.- Tiempo de proceso del sistema (lead time) deseado por el
cliente?
2.- = capacidad por unidad de tiempo (velocidad o n de tareas en
ese lead time)
2.- WIP del sistema aconsejado > < 2
Ley de Little L = * W En un sistema en equilibrio = => L = * W =>

WIP ( )= Ritmo de salida * Lead time
WIP (2 ) = Ritmo de salida * Lead time *2
TCNICAS LEAN MEJORANDO EL TIEMPO DE PROCESO (LEAD TIME)
Prcticas Lean Software Development para la reduccin de desperdicio en

el proceso de desarrollo
603
LA ORGANIZACIN
DIMENSIONANDO EL SISTEMA ADECUADAMENTE

La situacin de saturacin ( > 1) es temporal o habitual?
NMERO DE SERVIDORES El incremento de personal en organizaciones de software debe ser parte del
plan de crecimiento de la organizacin. La incorporacin urgente como
! medida de contingencia para proyectos retrasados es contraproducente.
En proyectos TIC los equipos pequeos son ms productivos. Es
recomendable emplear estructuras organizativas fractales.
604
FORTALEZAS DE LA GESTIN VISUAL KANBAN
GESTIN CONTROL
Regula el flujo y la carga de trabajo / equipo

Facilita un flujo de trabajo que lleva los problemas a la superficie
Facilita el mantenimiento de un ritmo sostenido (evita la ley de Parkinson)
Desarrollo continuo
INFORMACIN VISUAL
Favorece la comunicacin directa.

Los problemas se detectan enseguida y no quedan ocultos.
Favorece una cultura de colaboracin y resolucin.
605
CONCEPTOS LEAN APLIABLES A PROYECTOS TIC

Ajuste a travs de los tres conceptos de la mejora continua kaizen
Muda: Desperdicio.
Muri: Tensin - Sobrecarga de trabajo que produce cuellos de botella.
Mura: Discrepancia - Variabilidad del flujo de trabajo.
Mudas habituales en proyectos TIC
Procedimientos, documentacin y papeleo innecesario que no aporta valor

Burocracia
al resultado
Sobreproduccin Desarrollar ms caractersticas de las necesarias
Multiproyecto Cambio de proyecto / interrupciones del flujo de trabajo
Esperas Tiempos de espera por falta de cadencia en el flujo de trabajo.
(Falsa solucin de las esperas). Encargar trabajo para ir avanzando algo no

Ir haciendo definido y no tener paradas a las personas.
Desajustes de
capacidad Personas de gran talento asignadas a tareas rutinarias y viceversa.
Errores Retrabajo por bugs.
606
EJERCICIO: DISEO DE TABLEROS KANBAN
607
Prctica 1
Informacin
Informacin en el rea de visual
Gestin visual
producto
Posibles tableros mostrar visualmente la siguiente informacin relativa al estado de desarrollo

del producto.
Posibles historias de usuario sugeridas que se encuentran en evaluacin sin determinar an si
se incorporarn al producto.
Historias de usuario aprobadas: se incorporarn al producto.
Historias de usuario ya valoradas y priorizadas previstas para programar.
Historias de usuario que se estn programando actualmente.
Historias de usuario ya programadas y que se pueden evaluar y ver en el servidor de pruebas.
Historias de usuario ya evaluadas pendiestes de desplegar.
Historias de usuario desplegadas en las dos ltimas versiones.
608
Prctica 2
Informacin
Desarrollo de producto visual
En incremento continuo Gestin visual
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
Informacin
Desarrollo de producto visual
En incremento iterativo Gestin visual
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 Kanban (Conceptos kanban y lean en gestin gil)
Equipo de operacin y Informacin

visual
mantenimiento Gestin visual
Posibles tableros para representar y guiar la gestin de trabajo de un equipo de operacin y

mantenimiento que refleje:
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
cc-by Rool Paap
612
VDEO: Gestin predictiva?

Vdeo: World Builder Bruce Braint
613
LAS CARACTERSTICAS DEL SOFTWARE
614
615
COSTE
616
COSTE
PROTOTIPADO

617
COSTE / BENEFICIO
PROTOTIPADO

618
MALEABILIDAD

619
TALENTO
Tiempos y mtodos Gestin del talento

Optimizacin de procesos Excelencia
Organizacin cientfica del trabajo Cultura y entorno
620
ECONOMA DE ESCALA
EFICIENCIA VALOR
621
CRITERIOS DE LA ESTRATEGIA PREDICTIVA / INDUSTRIAL
Gestin de Produccin
proyectos basada en
predictiva procesos
622
PRCTICA: LOS PROCESOS
cc-by: LizMarie
623
LOS PROCESOS COMO RESPONSABLES DEL RESUTADO

De a
Tcito Explcito
Externalizacin
624
LOS PROCESOS COMO RESPONSABLES DEL RESUTADO?

De a
Tcito Explcito
SAS
2
?
SAS
SAS
NO
g
Externalizacin
625
KNOW HOW
Capital Estructural Humano Empresa
Elementos conocimiento - valor Procesos Tecnologa Personas
Artesana
Ubicacin del
Tipos
de
industrias
Empresas del conocimiento
Empresas industriales
Conocimiento Conocimiento
explcito tcito
626
PROCESOS COMO RESPONSABLES DEL RESULTADO
627
ESCENARIO ACTUAL
VELOCIDAD
Fotografa cc-by:Amnemona
628
ESCENARIO ACTUAL
INCERTIDUMBRE

629
EJERCICIO: VELOCIDAD
630
VELOCIDAD
631
VELOCIDAD
632
VELOCIDAD
633
EJERCICIO: INCERTIDUMBRE
634
VELOCIDAD / INCERTIDUMBRE
635
THE NEW NEW PRODUCT DEVELOPMENT GAME
Muchas compaas han descubierto que

para mantenerse en el actual mercado
competitivo necesitan algo ms que los
conceptos bsicos de calidad elevada,
costes reducidos, diferenciacin.
Adems de esto tambin es necesario
velocidad y flexibilidad
Nonaka y Takeuchi, 1986
636
Gestin de la organizacin gil
EL ESCENARIO ACTUAL
Eficiencia y previsibilidad ya no son

las claves del xito.
1960 1985
Lanzamiento constante de novedades
Reduccin del tiempo de desarrollo
Cambios y mejoras rpidas
Componente innovador
637
DAMO PREVISIN Y CALIDAD CON PROCESOS
638
LO QUE NECESITA EL CLIENTE
639
VALOR RPIDO Y CONTINUO
640
VDEO: FLEXIBILIDAD
Vdeo: Club de los poetas muertos
642
FLEXIBILIDAD EN LAS PRCTICAS
PRINCIPIO GIL PRCTICAS GILES
Burn-down
Seguimiento prximo Kanban de tareas
(diario) Grfico de carrera

Fundamentalismo (RAE): Exigencia intransigente de

sometimiento a una doctrina o prctica establecida
643
FLEXIBILIDAD EN LAS PRCTICAS
PRINCIPIO GIL PRCTICAS GILES
Burn-down
Seguimiento prximo Kanban de tareas
(diario) Grfico de carrera

FLEXIBILIDAD
Fundamentalismo (RAE): Exigencia intransigente de
sometimiento a una doctrina o prctica establecida
644
AGILIDAD: GESTIN Y ALINEACIN DE LA ORGANIZACIN
PRODUCTO
PROYECTO
GERENCIA
645
XP
FDD
AD
XP AM
DSDM ASD
SCRUM
ASD
CRYSTAL
Lean

646
PRODUCTO
GERENCIA
647
GERENCIA
648
PRODUCTO
GERENCIA
649
PRODUCTO
GERENCIA
650
GERENCIA
PROCESOS
PRODUCCIN
651
REAS DE RESPONSABILIDAD
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
REAS DE RESPONSABILIDAD / ROLES SCRUM

Direccin Coherencia del modelo
Medios y formacin
Scrum
Mejora continua
Manager
Propietario Visin del producto

producto
Autoorganizacin
equipo
Tecnologa gil
653
IMPLANTACIN DE SCRUM BASADA EN RESPONSABILIDADES
Management
Medios y formacin
Procesos / calidad
Mejora continua
Ejecucin
Visin del producto
Auto-organizacin
Tecnologa gil
654

Direccin
Calidad RR.HH.
Oficina proyectos Comercial Programacin
655
Direccin
LA ASIGNACIN DE
RESPONSABILIDADES
SE ADAPTA A LA
Calidad RR.HH.
ORGANIZACIN
FLEXIBILIDAD / GLOBALIDAD
656
Direccin
Calidad RR.HH.
657
ROLES SCRUM BASADOS EN RESPONSABILIDADES: un ejemplo
Direccin

Medios y formacin
Calidad RR.HH.
Mejora continua

Autoorganizacion
Garanta de funcionamiento Visin del producto
Tecnologa gil
658
ADOPTAR PRCTICAS
MS O MENOS GILES
PREVISIBILIDAD AGILIDAD
NO ES EL OBJETIVO
659
TRABAJAR DE FORMA
MS O MENOS GIL
NO ES EL OBJETIVO
660
TRABAJAR DE FORMA
ADECUADA A LA
ORGANIZACIN
ES EL OBJETIVO
661
VDEO
Vdeo: Forgtek
662
Juan Palacio
Para consultar los usos autorizados de este trabajo o contactar con el autor:
http://www.safecreative.org/work/1401289956290
663

Cis PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Cis PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Compendio de Ingeniera del Software

Rev. 1.0 Mayo 2014

Prlogo Verificacin y validacin

Formacin de Ingeniera del Software como asignatura complementaria en programas de

Crisis del software

1950 1960 1970 1980 1990 1990 2000

Crisis del software

En 1962 se public el primer algoritmo para bsquedas binarias.

LA PRIMERA SOLUCIN A LA CRISIS DEL SOFTWARE

INGENIERA DEL SOFTWARE

Aplicacin del principio de calidad de Jurn empleado en la produccin

Aplicacin de procesos de planificacin, ejecucin y control para alcanzar un

Crisis del software

Proyectos para desarrollo de sistemas de software

Fracaso Problemtico xito

2009 24% 44% 32%

2004 19% 53% 29%

2000 23% 49% 28%

1998 28% 46% 26%

1995 40% 33% 27%

1994 31% 53% 16%

Fuente: Standish Group Survey,

Crisis del software

Proyectos para desarrollo de sistemas de software

Fracaso Problemtico xito

2009 24% 44% 32%

2004 19% 53% 29%

2000 23% 49% 28%

1998 28% 46% 26%

1995 40% 33% 27%

1994 31% 53% 16%

Fuente: Standish Group Survey,

Ingeniera del software

Establecimiento y uso de principios de ingeniera para obtener software

Fritz Baver, 1968 (conferencia NATO)

Disciplina para producir software de calidad desarrollado sobre las agendas y

S. Schach 1990, Software Engineering

(1) La aplicacin de mtodos sistemticos, disciplinados y cuantificables para el

Ingeniera del software

Ingeniera del software

Definirse a s misma: Cules son las reas de conocimiento que la comprenden?

Definir los procesos que intervienen en el desarrollo, mantenimiento y operacin

Definir criterios unificadores para las tareas de requisitos, pruebas, gestin de la

Los estndares son tiles porque:

Agrupan lo mejor y ms apropiado de las buenas prcticas y usos del desarrollo de

Ingeniera del software

Ingeniera del software

Ingeniera del software

IEEE Computer Society

IEEE Std. 830 Prcticas recomendadas para las especificaciones de software.

Ingeniera del software

Definirse a s misma: Cules son las reas de conocimiento que la comprenden?

SWEBOK: Software Engineering Body of knowledge

Definir los procesos que intervienen en el desarrollo, mantenimiento y operacin

ISO/IEC 12207: Procesos del ciclo de vida del software

Definir estndares menores para dibujar criterios unificadores en requisitos,

IEEE 830 - IEEE 1362 - ISO/IEC 14764

El proyecto SWEBOK (Software Engineering Body of Knowledge) comenz sus actividades de

El cuerpo de conocimiento identificado por el proyecto SWEBOK se ha configurado como el estudio

Ingeniera del software

Requisitos Gestin de la configuracin

ISO 12207: PROPSITO

Establecer un estndar para evitar una situacin de Torre de Babel en la gestin e