NDICE

PARTE I.- PLANIFICACIN DE PROYECTOS INFORMTICOS

Captulo 1: Introduccin....................................................................................5
1.1 La empresa y su entorno........................................................................... 6
1.2 La ingeniera del software....................................................................... 10
1.3 La planificacin y gestin en la ingeniera del software.................... 13

Captulo 2: Definiciones bsicas..................................................................... 17

2.1 Lo que es un proyecto.............................................................................. 19
2.2 Tipos de proyectos...................................................................................22
2.3 Los procesos de Ingeniera del Software............................................. 24
2.4 Organizacin del proyecto .....................................................................25
2.5 El director de proyecto: su perfil y su identidad................................. 27
2.6 Especificaciones del proyecto ............................................................... 31
El contenido de este libro no podr s e r reproducido, 2.7 El ciclo de vida de un producto informtico.........................................32
ni total ni pa rcialm e n te, sin el previo p e r m iso escrito del editor.
T o d o s lo s d e re c h o s reservad o s.
Captulo 3: Factores de dimensin................................................................. 37
U nive rsidad de A lc a l 3 .1 Esfuerzo total dedicado al software....................................................39
Servicio de P u b lic a c io n e s 3.2 Distribucin del esfuerzo......................................................................41
P la za de S a n D iego, s/n 3.3 Categoras de proyectos de ingeniera del software segn
28801 A lca l de H e n a re s
ww w .uah.es
sus dimensiones............................................................................... 43
3.4 Distribucin del tiempo a lo largo del ciclo de vida de un
IS B N : 9 7 8 -84 -8 138 -7 94 -0 sistema informtico...............................................................................45
D epsito L e ga l: M -5 62 51 -20 08
3.5 Estimacin de recursos..........................................................................46
Im p re si n y en cu a d e rn a cin : Im p ren ta de la U AH
Im p re so en E sp a a Captulo 4: Factores de productividad.........................................................51
4.1 Mtricas de productividad del software............................................. 51
4.2 Herramientas que mejoran la productividad......................................53
4.3 Los CASE ..............................................................................................54
4.4 Productividad segn el ciclo de vida...................................................56
4.5 Disponibilidad de recursos...................................................................59
4.6 La experiencia y el entrenamiento del equipo de desarrollo.......... 59
 P L A N IF IC A C I N Y F iST IO N D E S IS T E M A S
Captulo 5: Aspectos gerencialcs.....................................................................63
5.1 El anlisis previo y el control de la inversin................................... 63
5.2 Cundo un proyecto es satisfactorio?...............................................71
5.3 Los activos de la empresa.....................................................................74
5.4 La informacin como activo estratgico............................................ 75
5.5 Necesidades de elaborar proyectos para adecuar los
sistemas de informacin a las tomas de decisiones en un
mercando cambiante............................................................................. 76
Captulo 6: Definicin del problema y estrategias de solucin...............79
6.1 Objetivos a alcanzar.............................................................................. 80
6.2 Especificaciones del producto............................................................. 82
6.3 Los requerimientos de los interesados................................................84
6.4 Bsqueda de una estrategia de solucin y su desarrollo..................85
Captulo 7: Fases de un proyecto.................................................................... 93
7.1 Estrategia de la empresa y sistemas de informacin ...................... 94
7.2 Estudio de la conveniencia y viabilidad ........................................... 95
7.3 Estudio funcional del Sistema de Informacin y creacin de
prototipos............................................................................................... 96
7.4 Actividades de inicio del proyecto..................................................... 97
7.5 Actividades de desarrollo, seguimiento y control........................... 101
7.6 Actividades de finalizacin............................................................... 103
7.7 Operacin y mantenimiento............................................................... 103
Captulo 8: Hitos, documentos y revisiones...............................................107
8.1 Ordenar las etapas................................................................................107
8.2 Relacin de tareas................................................................................108
8.3 Dependencia entre tareas....................................................................109
8.4 Diagramas de Gantt............................................................................ 110
8.5 Los hitos y sus fechas lmite.............................................................. 113
8.6 Diagramas de carga.............................................. .............................. 115
8.7 La documentacin tcnica como herramienta de
seguimiento de la planificacin.................................................... 121
8.8 Revisiones y ajustes a la planificacin............................................. 121
Captulo 9: El mtodo de costes....................................................................123
9.1 Modelos empricos............................................................................... 124
9.2 Puntos funcin..................................................................................... 126
9.3 Distribucin porcentual del esfuerzo................................................133
9.4 Modelo COCOMO............................................................................. 134
9.5 Mtodo de estimacin de Putman..................................................... 162
N D IC E m
9.6 Herramientas automticas de estimacin......................................... 163
9.7 Discusin final.................................................................................... 166
Captulo 10: Planificacin del tiempo......................................................... 169
10.1 De los grficos de barras al anlisis de red.................................... 170
10.2 Descripcin del modelo grfico...................................................... 171
10.3 Reduccin del tiempo mediante la reestructuracin de la red. .. 177
10.4 El PERTyel CPM............................................................................ 183
10.5 Mtodo ROY...................................................................................... 195
10.6 Anlisis de las redes como herramienta bsica............................. 199
Captulo 11: Programacin de Recursos................................................... 205
11.1 Holguras de las actividades y planificacin de recursos:
Cmo utilizar las fluctuaciones totales, libres e
independientes en beneficio del proyecto?.................................... 205
11.2 Formalizacin de proyectos informticos..................................... 212
11.3 Planificacin del cash-flow..............................................................218
11.4 Retroalimentacin............................................................................ 219
Captulo 12: Anlisis del riesgo: Seguridad............................................. 223
12.1 Estndares internos, externos y a medida..................................... 224
12.2 Identificacin y control del riesgo..................................................227
12.3 Estrategias y planes de contingencia............................................. 234
Captulo 13: La comunicacin tcnica....................................................... 241
13.1 Fundamentos de la comunicacin tcnica.................................... 243
13.2 Comunicaciones orales y escritas...................................................244
13.3 Preparaciones de exposiciones orales y de materiales de
soporte ..............................................................................................245
13.4 La herramienta CASE y el software de planificacin como
medio de producir documentacin tcnica.................................... 246
13.5 Sistemas de WorkJIow...................................................................... 252
13.6 Sistemas de Groupware................................................................... 260
PARTE II. GESTIN DE PROYECTOS INFORMTICOS
Captulo 14: La gestin de configuraciones.............................................. 265
14.1 Concepto de gestin de configuraciones: Su papel en el
control de la evolucin del software............................................... 266
14.2 Mantenimiento de la integridad del producto...............................271
14.3 Normalizacin de la gestin de la configuracin........................ 279
14.4 Establecimiento de lneas maestras............................................... 282
iv P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S ________________________ _______ N D I C E ____________________________ v

14.5 Tareas de la gestin de la configuracin........................................286 A 1.6 Proceso de ejecucin.................................................................... 4 1 q

14.6 Mdulos e inlerfaces......................................................................... 306
14.7 Elementos de diseo......................................................................... 311
14.8 Plan de gestin de la configuracin del software.........................318
14.9 Herramientas de control de configuraciones................................ 320
14.10 Rentabilidad de la gestin de la configuracin...........................324
Captulo 15: La Garanta de C alidad......................................................... 329
15.1 Introduccin a la Garanta de Calidad del Software.................... 330
15.2 Factores de calidad del software..................................................... 333
15.3 Tcnicas de calidad del software.................................................... 336
15.4 Mtricas de calidad del software.................................................... 341
15.5 Estndares de calidad del software.................................................343
15.6 Plan de calidad del software............................................................ 345
15.7 Modelo de Madurez.......................................................................... 348
15.8 La documentacin en la gestin de calidad del software........... 354
A 1.7 Proceso de control.................................................................... 4 11
A 1.8 Proceso de cierre....................................................................... 4 ]2
A 1.9 Areas de conocimiento de la Gestin de Proyectos..................412
A 1.10 Versin 2 0 0 4 .......................................................................... 4 ]^
ANEXO II. Gestin de Provectos de la Administracin Pblica
Espaola (M ETRICA)......................................................................... ...
A2.1 Interfaz de Gestin de Proyectos de MTRICA Versin 3 .... 423
A2.2 Euromtodo............................................................................ 424
A2.3 Actividades de Inicio del Proyecto (GPI).................................. 425
A2.4 Actividades de Seguimiento y Control (GPS)...........................427
A2.5 Actividades de Finalizacin del Proyecto (GPF)..................... 435

Captulo 16: Organizacin y control de un proyecto.............................. 361

16.1 Estructura de los grupos de trabajo.................................................362
16.2 Estructura del proyecto.....................................................................364
16.3 Modelo de Madurez para la gestin del personal.........................367
16.4 Seguimiento y control....................................................................... 368

Captulo 17: Proyectos especiales de Ingeniera del Software..............371

17.1 Reingeniera del software.................................................................372
17.2 Repositorios........................................................................................376
17.3 Reingeniera de procesos de negocio............................................. 379
17.4 Reutilizacin del software................................................................381
17.5 Implantacin de paquetes software estndar................................ 386

Captulo 18: Auditoria Informtica............................................................ 391

18.1 Tipos de auditoria. Auditoria informtica.....................................391
18.2 Sistemas de control interno en tecnologas de la informacin ... 393
18.3 Organizacin y fases de la auditoria informtica.........................398
18.4 Clases de auditoria informtica.......................................................400

ANEXO I Project Management Body o f Knowledge (PM B O K )........403

A 1.1 Definiciones y conceptos.................................................................405
A 1.2 Fases y ciclo de vida........................................................................ 406
A 1.3 Procesos............................................................................................. 406
A 1.4 Proceso de iniciacin....................................................................... 408
A 1.5 Proceso de planificacin..................................................................408
P L A N IF IC A C I N Y B S T I N D E S IS T E M A S

PRLOGO

El grupo de trabajo denominado "ACM-IEEE-CS Joint Curriculum Task

Forc" ha elaborado una serie de recomendaciones acerca de las materias
troncales, especficamente informticas, que deberan estar presentes en todo
curriculum correspondientes a unos estudios universitarios de primer grado que
se deben de complementar con otras de carcter matemtico (lgebra, anlisis,
clculo, matemtica discreta, probabilidad y lgica matemtica), fsico,
prcticas de laboratorio y otras materias de especficas de acuerdo con los
diferentes contextos institucionales y objetivos pragmticos.

Manifiesta el comunicado que "el curriculum se debe de completar con

otras experiencias de tipo educacional que favorezcan el desarrollo de una
capacidad para el pensamiento crtico, la resolucin de problemas, mtodos de
investigacin y el desarrollo profesional. Estas experiencias adicionales
generalmente consisten en el trabajo en equipo, la comunicacin y la
familiarizacin con la profesin"'.

Este trabajo permiti establecer un punto de partida para situar el marco

concreto y analizada la opinin de algunas sociedades prestigiosas que
entienden que el desarrollo del software, y su utilizacin en el campo
profesional, se debe de entender dentro de un marco en el cual la Planificacin
y Gestin de los Sistemas Informticos debe de tener un peso importante como
medida de los aspectos gerenciales de las organizaciones. En este sentido es
preciso puntualizar otra serie de aspectos que permitan desarrollar y detallar el
contenido del presente libro.

En esta breve descripcin del contenido se apuntan los siguientes temas:

Planificacin de un proyecto de programacin. Comunicacin tcnica. Gestin
de configuraciones. Control de Calidad. Organizacin y administracin de un
proyecto. Estos temas expuestos nos conducen a la idea general de que el

1 ACM/IEED-CS Join Curriculum Task Force. Computer Curricula 1991. Ed. ACM Press, \ -,
1991.pp.78.
2 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S
objetivo que se persigue con la asignatura Planificacin y Gestin de Sistemas
Informticos est orientada hacia la asimilacin de conceptos informticos
tendente a su posterior utilizacin en el dimensionado, planificacin y
operacin de un proyecto informtico: El Desarrollo de Software de Calidad
como proyecto.
La necesidad de esta materia podemos encontrarla en el hecho de la
competitividad, la competencia ofrece al cliente mayores posibilidades de
eleccin y precios ms bajos. Por otra parte, la garanta que se ofrece al
consumidor de obtener mercancas y servicios de calidad a los mejores precios,
es que pueda contar con varios proveedores que compitan en el mismo
negocio. La competencia libre y abierta es la piedra angular en la que descansa
nuestro sistema de economa de mercado. Adems las empresas o instituciones
no siempre persiguen de una forma natural la competencia y el recorte de
precios, pero su principal misin es conseguir los mximos beneficios para sus
accionistas. La Informtica no se puede quedar fuera de este juego: los cambios
que se demandan del personal de proceso de datos son para mejorar la
competitividad y los resultados de la compaa, y tales cambios tambin
inciden en el propio departamento de informtica.
Para muchos la poltica de competencia es una idea abstracta, sin embargo,
los beneficios que nos reporta a todos son bien tangibles. Para demostrar esta
tesis basta con mirar la mala calidad de los servicios ofrecidos por los sistemas
de economa planificada. La competencia, obliga a los fabricantes, en nuestro
caso de software y hardware, a mantener los precios ms bajos posibles si no
quieren correr el riesgo d perder cotas de mercado. Adems, un sistema de
libre competencia sensibiliza a las empresas frente a las exigencias y deseos de
los clientes (las empresas con ciertos monopolios ofrecen al consumidor lo que
ellas quieren producir y no lo que ellos quieren que se produzca). La
competencia tambin es un agente dinamizador estimulando a las empresas y
organismos a invertir, investigar, innovar y fabricar mejores productos que sus
rivales.
Es un hecho comprobado que los profesionales de centros de proceso de
datos cuyas empresas se han visto obligadas a competir, estn ms capacitados
para hacer frente a sus competidores y se han cultivado ms en el manejo de las
nuevas tecnologas.
Pero la competitividad no est cifrada nicamente en bajar los precios,
sino adems, en hacer las cosas mejor que los dems: ofrecer garantas de
funcionamiento, tener los productos con unas tasas de mantenibilidad bajas,
ofrecer una buena documentacin tcnica. Cuando Michael Hammer acu el
PRLOGO 3
trmino reingeniera estaba posiblemente muy lejos de imaginar que en pocos
aos este concepto iba a dejar una huella indeleble en la mayor parte de los '
procesos de desarrollo informtico de empresas. La idea de Hammer se ha (
asentado fuertemente como sinnimo de procesos de adaptacin y
optimizacin de viejas aplicaciones. ,
La calidad del software y las nuevas metodologas junto con la necesidad
evidente de poseer una tecnologa suficientemente potente para adaptar los (
procesos rpidamente a las nuevas y crecientes necesidades de un mercado
cada vez ms competitivo, han popularizado la necesidad de la reingeniera de
la informtica y, tenemos que decir, que actualmente los resultados no estn a (
la altura de lo que se esperaba. Por el hecho de necesitar los resultados (
rpidamente no se han instalado de forma global procesos de reingeniera con ^
una metodologa adecuada en casi ninguna empresa; normalmente se ha
recurrido a este tipo de soluciones cuando el propio sistema necesita, de forma '
urgente, una reparacin, lo que hace que se haya producido un alto ndice de
fracasos en los proyectos emprendidos y no por ello se puede achacar toda la (
culpa a deficiencias intrnsecas de este tipo de procesos sino a la falta de unas <
buenas herramientas y metodologas suficientemente asentadas en la ,
organizacin de la empresa.
Por esta razn es por lo que el tipo de reingeniera que se est imponiendo f
actualmente en las empresas (sobre lodo en Espaa) es la reingeniera de r
procesos, en base a la cual se estudian, se planifican y se redefinen los flujos de
trabajo y metodologas internas de las empresas para conseguir maximizar la (
eficiencia e, indirectamente, los resultados econmicos. A partir de aqu se ^
desvela la importancia que est tomando el papel que juegan los departamentos
informticos en la toma de decisiones empresariales, los viejos centros de
proceso de datos se reestructuran y pasan a asumir un papel protagonista en la 1
gestin del cambio y en los procesos de planificacin estratgica de empresa. (
(
Por todo ello, en la lectura de este libro, nos fijamos unos objetivos (
especficos que se orientan a que el lector sea capaz de:
Estudiar la viabilidad y la conveniencia de desarrollar algn producto
informtico. 1
Planificar el desarrollo, con unos medios finitos, para lograr el mejor 1
resultado. (
Gestionar la realizacin de dicho producto controlando y evaluando los (
resultados producidos. (
Dimensionar un sistema informtico adecuado a unas necesidades (lo
que significa no despilfarrar los medios).
 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S
Medir cuales son las prestaciones que dicho sistema informtico le est
ofreciendo.
Detectar los posibles "cuellos de botella", si los hubiese, as como sus
causas.
Evaluar y determinar los mtodos alternativos o las modificaciones
oportunas para conseguir, si fuera posible, un modo de explotacin que
mejore el rendimiento del sistema.
En resumen, dirigir un Proyecto de Informtica de una envergadura
creciente, en funcin de la experiencia que se vaya adquiriendo y adecuar los
recursos a la consecucin de los fines, en las mejores condiciones posibles.
La organizacin de la obra se ha agrupado en captulos repartidos dentro
dos grandes mdulos:
Planificacin de Proyectos Informticos.
Gestin de Proyectos Informticos
Se entiende que la materia de PLANIFICACIN Y GESTIN DE
SISTEMAS debe girar entorno a estos dos grandes temas, para ello, dentro del
primer mdulo y despus de hacer una amplia introduccin a la planificacin,
se va a pasar a estudiar las "tcnicas de representacin" y la gestin de tales
proyectos. Finalmente nos ha parecido conveniente aadir dos anexos para
explicar dos de las metodologas de gestin de proyectos ms utilizadas en
nuestro entorno: PMBOK (Project Management Body O f Knowledge) y
METRICA (Gestin de Proyectos de la Administracin Pblica Espaola).
Los autores tratamos de poner en manos del estudiante una coleccin de
toda la tecnologa existente a fin de contribuir a ayudarle a fijar el vasto campo
de la Ingeniera del Software desde el punto de vista de la planificacin y
gestin de sistemas informticos.
CAPTULO 1
INTRODUCCIN
A lo largo de la historia de la Informtica, en el desarrollo y gestin profesional
de los sistemas de informacin se ha considerado de forma habitual que este
tipo de tecnologa era fruto del buen criterio del tcnico, que se entenda como
un artesano de la programacin. Este enfoque no es el que se pretende fomentar
en este libro, en el que se estudia la forma de aplicar un conjunto de mtodos,
tcnicas y herramientas en las diferentes fases del ciclo de vida de un proyecto
informtico. De hecho, se pondr especial nfasis en los aspectos de la
direccin de proyectos, las medidas de esfuerzo para su realizacin en las
mejores condiciones econmicas, el establecimiento de las tareas a realizar, la
estimacin de recursos necesarios, la planificacin, cmo mejor adecuacin de
los recursos a las tareas con una visin de futuro para evitar conflictos en la no
disponibilidad de recursos, la comunicacin tcnica, el control de calidad y de
costes, la documentacin del producto obtenido, y el mantenimiento, tanto del
producto como de la propia documentacin.
Debemos considerar que los contenidos de esta obra no son los de una
ciencia que explica fenmenos de la naturaleza o de la sociedad, sino ms bien
se han de entender en el sentido amplio de conocimiento sistemtico con base
terica que permite construir y manejar objetos tiles dentro de unos escenarios
con limitaciones econmicas, temporales y de aceptacin. As pues, la
planificacin de sistemas de informacin debe ser considerada una rama de la
ingeniera ms que una ciencia propiamente dicha. En cualquier caso, se ha
sealar que ste conjunto de fundamentos tericos y procesos de ingeniera
prctica conduce a la nueva visin de que la ingeniera puede aplicarse al
diseo y construccin de sistemas abstractos, aunque la afirmacin no adolezca
de detractores.
6 P L A N IF IC A C I N Y G E S T I N DE S IS T E M A S IN F O R M T IC O S
1.1 LA E M PR E SA Y SU E N T O R N O
El desarrollo de aplicaciones informticas se lleva a cabo en el contexto de una
organizacin de produccin de software. Por este motivo, antes de adentrarnos
en la descripcin de aspectos eminentemente tcnicos, es conveniente
detenerse a analizar el marco de referencia en el que se van a situar los
proyectos informticos, constituido fundamentalmente por una o varias
empresas en las que se llevan a cabo unos determinados procesos y un tipo de
relaciones internas que pueden afectar al desarrollo de este tipo de proyectos.
Una empresa podemos considerarla como una combinacin de factores
orientados a prestar un servicio u ofrecer un determinado producto,
normalmente, para conseguir un beneficio o resultado propio de su actividad.
Para lograr esto es necesario, en primer lugar, un negocio en el sentido de
cualquier actividad relacionada con la compra-venta o prestacin de servicios
que genere beneficio. Adems es necesario disponer, en trminos de economa
normales, de una sociedad mercantil entendida como una unidad jurdica que
regula la relacin que produce el patrimonio del cual son titulares al menos dos
personas. Tambin se necesita de una unidad tcnica vista como un conjunto de
procesos tecnolgicos por los que un determinado conjunto de factores van a
ser trasformados en una serie de productos o resultados, y que se entiende con
el nombre de explotacin. Adems suele ser necesario un establecimiento, en
forma de unidad espacial o fsica donde se localiza la actividad (puede ser una
planta, una factora software, unas oficinas, etc).
Grandes investigadores de la gestin empresarial han ayudado a precisar
los factores que intervienen en una empresa; as, Gutenberg, en Fundamentos
de la Economa de Empresa, establece dos grupos especficos de factores a
considerar: los elementales y los dispositivos. Los aspectos elementales de la
empresa estn formados por la materia prima, las factoras, los equipos, el
trabajo a realizar, en resumen todo aquello que se puede considerar como
activos materiales, que, por tanto se pueden ver, medir y contabilizar
fcilmente. Por otra parte estaran los factores dispositivos o pautas
intangibles de gestin de la empresa, formados por la direccin, la propia
planificacin o forma de hacer el trabajo, la organizacin de todo el negocio,
las patentes que pueda tener y el conocimiento y su gestin que puede
establecer elementos diferenciadores de una empresa respecto a otra.
En este contexto empresarial podemos decir que la planificacin es el
proceso de ordenamiento de los factores en funcin de los objetivos. As, segn
los factores que tratemos se obtendrn distintas visiones de la planificacin: si
C A P T U L O 1: IN T R O D U C C I N 7
utilizamos como punto de vista los factores productivos, obtendremos una
planificacin orientada a la productividad; si introducimos todos los factores
que componen el conjunto de la empresa con el objetivo de su posible
proyeccin en el tiempo, obtendremos datos de la planificacin estratgica; y
as sucesivamente.
Sin embargo, en la definicin anterior, hemos introducido el trmino
ordenacin en el sentido de organizacin, entendida como la bsqueda de las
estructuras humanas y tcnicas para ejecutar la planificacin, obteniendo el
mayor rendimiento posible desde una consideracin dinmica de la
organizacin empresarial. Segn Gutenberg, la empresa es una unidad que
dispone de unos factores de produccin determinados y que, a partir de la
decisin del hombre, se combinan entre s para alcanzar unos servicios o
productos que va a colocar en el mercado.
En este sentido, tenemos que considerar seriamente el entorno econmico-
social de la empresa, ya que la empresa est integrada por individuos,
organizados formal o informalmente, que desarrollan una serie de tareas
cumpliendo una funcin social y, la empresa, en su funcin global se presta a
dividir su funcionamiento en tareas especficas, de tal forma que se trate de
relacionar cada tarea con un individuo que la satisfaga.
Antiguamente la empresa buscaba una forma de realizar un producto,
organizar la produccin y, finalmente, investigar la forma de vender mejor ese
producto. En el caso especfico de una empresa de software, normalmente se
obtena un producto que, posteriormente se trataba de vender. Hoy da el
proceso es a la inversa: primero se investiga qu se puede vender, despus se
desarrolla el proyecto de produccin, posteriormente acudir a los suministros
o materias primas, y, finalmente llevar a cabo la produccin de lo que
vender.
Hemos visto una dimensin social de la empresa, pero para entender mejor
la planificacin de su produccin es necesario entender otra serie de
dimensiones como son:
La dimensin funcional, entendida como la actividad organizada y
alternativa al mercado con nimo de lucro
La dimensin tcnico-econmica, que se centra en el proceso de
trasformar productos. Es la actividad productiva de bienes y servicios.
La dimensin econmico-financiera, como unidad creadora de valor
aadido. Es la actividad econmica que crea valor y dinero.
8 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
La dimensin jurdico-mcrcantil, que junto con la comercial es la
actividad generadora de relaciones.
Otros aspectos de la dimensin social, entendida como otra actividad
compuesta por relaciones humanas y de poder que establecen un
complejo diseo de comunicaciones y de relacin entre las personas
que forman esa empresa
Tambin tenemos que comprender que existe una serie de factores que
condicionan la explotacin econmica, y que podemos clasificar en factores
independientes y dependientes. Entre los primeros se encuentra la
productividad que se obtiene por el mero hecho de poder modificar la prioridad
de los recursos, la economa en la gestin, el equilibrio financiero o la
experiencia de saber hacer las cosas bien. Como factores dependientes
podramos citar los costes de obtencin de las licencias de los sistemas
operativos, el precio de los suministros bsicos o la rigidez del mercado laboral
establecido por ciertos grupos de presin, los sistemas organizativos que
configuran el tipo de economa centralizada que condiciona la propia estructura
en cuanto a las posibles dependencias de la gestin o, incluso, la misma
realizacin de las actuaciones asignadas.
Al considerar los factores dependientes, debemos tener en cuenta que la
actividad empresarial forma parte de un sistema de economa de mercado
que condiciona fuertemente el desarrollo de la propia planificacin
empresarial. Los pilares bsicos de la economa de mercado son la
configuracin de un mercado con un mecanismo de regulacin que trata de
garantizar que las empresas funcionen con la misma eficiencia, es decir, que las
empresas tengan las mismas oportunidades de sobrevivir en ese mercado. La
primera consecuencia de ello es que el precio de los productos o servicios lo
impone el propio mercado y no las empresas que operan en l. La economa de
mercado trata de garantizar una poltica social necesaria para que no existan
personas y actividades marginadas del mecanismo del mercado, basada en los
principios de solidaridad y subsidiariedad, que van a imponer serias
restricciones, por ejemplo, en el calendario laboral del personal asignado a un
proyecto. Existen otra serie de factores que son necesarios en la economa de
mercado, como son una cierta estabilidad monetaria que permita la regulacin
de las operaciones por medio de un sistema financiero controlado por el
sistema poltico participado por el estado. Tambin se puede producir la
intervencin de los estados en la creacin de estructuras y tejido comercial,
para facilitar el desempeo de las funciones propias de la empresa y que
permitan reducir los costes externos. Otro factor dependiente sera la existencia
de un sistema educativo que contemplase la capacitacin de los individuos para
___ _______ C A P T U L O 1: IN T R O D U C C I N
que puedan realizar un aprendizaje continuo y la adecuacin permanente a su
puesto de trabajo con independencia del avance de las tecnologas.
Otro aspecto de inters a tener en cuenta en este captulo de introduccin
es la presentacin de la figura del empresario, como responsable de una
organizacin que desarrolla software. En este sentido, podramos enumerar
algunas de las capacidades bsicas que ha de reunir cualquier empresario:
Una persona que asume riesgos.
Aquel que cede el capital para iniciar la actividad empresarial.
Aquel que establece cmo se realiza la combinacin de factores dentro
de la empresa.
Aquel que plantea innovaciones dentro de la empresa.
Persona que fija objetivos a conseguir, establece los medios que
llevarn a conseguir esos objetivos y plantea las medidas econmicas
oportunas y ms favorables para ello.
Si tenemos en cuenta la consideracin de Gutenberg del empresario como
directivo, en tanto factor dispositivo, con funciones de direccin, planificacin
y organizacin, puede afirmarse que tambin ha de tener la capacidad de
adaptarse al entorno y a sus estructuras, de tal suerte que la empresa, como
conjunto de funcionalidades, debe imprimir a sus procesos y estructuras un
carcter dinmico frente a los cambios, que le permita incrementar la utilidad
de todos y cada uno de los grupos o factores que la componen: personal,
clientes, accionistas, la propia comunidad donde est implantada). En este
sentido, es necesario hacer una breve reflexin sobre la globalizacin de la
economa1 ya que el valor de los recursos de una empresa tiene que evaluarse
desde su dimensin mundial y en funcin de su utilizacin mundial, lo que nos
lleva a desarrollar nuevos diseos organizativos dentro de la actividad
empresarial, como pueden ser la movilidad rpida de las personas y de las
estructuras2 que permitan trabajar con estructuras ms flexibles, y poder crear
estructuras organizativas complejas para competir con ventaja en aspectos
globalizadores de la produccin. Esto supone crear una cultura empresarial
nueva que se oriente a los procesos y no a las funciones, con una coordinacin
permanente y estableciendo una divisin del trabajo que permita obtener, en
cada momento, productos de mayor calidad y en el menor tiempo posible.
1 Las causas de la Globalizacin de la economa se deben fundamentalmente a la eliminacin
de barreras polticas, aduaneras, financieras, culturales, etc.; as como a la descentralizacin
geogrfica y de estnictura de la propia empresa.
2 Esto se conoce como el aumento de la movilidadfunciona!.
10 P L A N IF IC A C IO N Y G E S T I N D E S IST E M A S IN F O R M T IC O S _________________________ C A P T U L O I: IN T R O D U C C I N

programacin que den un carcter sistemtico al desarrollo de software que

1.2 LA IN G E N IE R A D EL SO F T W A R E permita considerarlos como un trabajo de ingeniera. En la figura 1.1 se
muestra un ejemplo de estructuracin en etapas de un proyecto de ingeniera
Adems del marco econmico descrito, constituido por la empresa y su del software. Durante la Etapa de Anlisis se definen los requisitos o
entorno, el contexto tecnolgico en el que ha de entenderse la planificacin y requerimientos del sistema, que establecen lo qu tiene que hacer, es decir, su
gestin de proyectos de desarrollo de sistemas informticos es el de la funcionalidad. En la Etapa de Diseo se establece una estructura del software
Ingeniera del Software, ya que este tipo de sistemas implica normalmente la que se ajustar a los requerimientos formulados en la etapa anterior. La Etapa
generacin de un tipo de software con la suficiente complejidad como para de implementacin tiene por objetivo producir un sistema terminado: esta etapa
concebir su construccin segn un enfoque ingenien!. incluye la programacin del sistema y su implantacin. Finalmente, durante la
Etapa de mantenimiento se produce una sucesin de sistemas terminados, que
El origen de la ciencia conocida como Ingeniera del Software* suele perfeccionan, adaptan y corrigen las versiones base previas.
fijarse a finales de la dcada de los aos sesenta, cuando, despus de ms de
veinte aos de desarrollo artesanal del software, la Comisin de Ciencias de
la OTAN, en otoo de 1968, convoca a un grupo de medio centenar de
expertos con la intencin de trazar las lneas maestras para salir de la
denominada crisis de la programacin o crisis del software. El arte de la
programacin se encontraba, entonces, en una situacin en la que los fracasos
operativos cada, da eran ms frecuentes. Los expertos concentrados por la F ig u ra 1.1 M o d elo en eta p a s p a r a el d e sa rro llo de p ro y ecto s so ftw a re
OTAN no lograron definir un camino capaz de guiar la nave a buen puerto,
aunque acuaron un trmino para esa lejana meta: 'La Ingeniera del
Software.
De las definiciones anteriores se deduce que en la Ingeniera del Software
existen tres elementos clave que han de ser tenidos en consideracin por el
Una de las primeras definiciones de ingeniera del software se debe a Fritz
director de un proyecto para conseguir un control efectivo del mismo y para la
Bauer3, quien, en una de las primeras conferencias importantes dedicada a la
obtencin de sistemas de informacin productivos y de calidad; se trata de los
Ingeniera del Software, la define como <?/ establecimiento y uso de principios
mtodos, que definen una secuencia ordenada de acciones cuya realizacin
de ingeniera robustos, orientados a obtener software econmico que sea
permitir conseguir los objetivos establecidos en cada etapa del proyecto; los
fiable y funcione de manera eficiente sobre mquinas reales". Algunas
procedimientos para llevar a cabo los mtodos; y las herramientas que han de
definiciones posteriores, como la de Boehm, la entienden como la aplicacin
ofrecer el soporte que permita la aplicacin real de tales procedimientos.
prctica de! conocimiento cientfico en el diseo y la construccin de
programas de computadora la documentacin asociada requerida para
Pero la Ingeniera del Software sigue siendo una ciencia inmadura y la
desarrollarlos y mantenerlos. Posteriormente, Zelkovitz, Shaw y Gannon
mayor parte del software que se produce se realiza con tcnicas artesanales
(1978) afirmaron que la Ingeniera del Software es el estudio de los principios
similares, salvando la distancia, a los productos obtenidos por las manufacturas
y metodologas p ara desarrollo y mantenimiento de sistemas software.
de productos anteriores a la revolucin industrial donde no existan
Finalmente, en 1993, la asociacin IEEE Computer Society la define como /a
procedimientos normalizados de intercambiabilidad y s una fuerte labor
aplicacin de un enfoque sistemtico, disciplinado y cuantificable al
artesanal. De hecho, a medida que los proyectos de desarrollo de software
desarrollo, operacin y mantenimiento del software en su estndar 610.12.
crecen tanto en complejidad como en volumen, la productividad, medida como
nmero de programas por hora de trabajo disminuye. Se emplea poco tiempo
En cualquier caso, la opinin compartida por los diferentes autores en este
en tareas tales como disear, codificar y depurar productos, que es lo que cons
mbito es la necesidad de llevar a cabo actividades adicionales a la
tituye el trabajo real del desarrollo de software, y mucho en coordinar lo que se
est programando. As pues, no parece ser realista medir en programadores-
3 Nota tomada de P. Naur y B. Randcll, en "Software Engineering: A report on a Conference mes la cantidad de trabajo necesaria para desarrollar un proyecto de software.
sponsored by the NATO Science Comm itee, NATO, 1969.
 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Un proyecto que ocupa a una persona durante ocho meses es un proyecto de
ocho programador-mes. Pero quizs, no pueda terminarse en cuatro meses por
dos personas o, peor an, en dos meses por cuatro personas. La cada de
productividad a medida que el tamao del equipo se incrementa es tan
dramtica, que equipos de tamao medio o grande pueden no llegar a producir
absolutamente nada til (Sommerville en Software Engineering).
En muchos casos se puede atribuir la disminucin de la productividad a los
problemas de comunicacin entre los miembros del equipo. En este sentido, se
puede afirmar que cuantas ms personas involucradas, ser necesario utilizar
ms tiempo en la comunicacin entre los miembros del equipo; as, en un
equipo de tres personas hay tres canales de comunicacin entre esas personas,
pero en un equipo de cuatro hay seis canales de comunicacin. Siguiendo esta
progresin se puede entender que en equipos muy grandes, a pesar de las
estructuras jerrquicas que se decidan para la administracin del proyecto, las
vas de comunicacin crecen desorbitadamente en nmero, con lo que la
comunicacin entre los miembros del equipo se hace cada vez ms importante
y a la vez ms trabajosa.
Como el nmero de canales de comunicacin crece ms deprisa que el
nmero de personas involucradas, un equipo de desarrollo de tamao mediano
o grande emplea proporcionalmente ms tiempo coordinando (y menos tiempo
progresando) que un equipo pequeo. Como el tamao del equipo crece en
algunos puntos crticos del proyecto, todo el tiempo se emplea en
comunicacin entre miembros y en acomodar lo ya producido a las estructuras
recientemente acordadas, y no se deja tiempo para el progreso real.
En el pasado, las tareas de los programadores consistan exclusivamente en
codificar y depurar, sin dar importancia a disear el software antes de
desarrollarlo. En general, no se usaban modelos para asegurar que el resultado
final se ajustase al propsito inicial, o para definir una estructura de programa
prctica y mantenible.
De esta forma los cambios producidos por la adaptacin al Euro o la
problemtica del ao 2000 han hecho que una gran cantidad del software
antiguo existente haya sido imposible de modificar; y es que, cuando se
desarrollaron los grandes programas que an permanecen funcionando, fueron
pobremente estructurados y escasa o nulamente documentados, de tal suerte
que resultaba muy caro y, en algunos casos, imposible su mantenimiento. A
menudo, no se ajustaban a los requerimientos iniciales del usuario. Al poco de
la aparicin de la Ingeniera del Software, los ingenieros aprendieron a
desarrollar los grandes sistemas en una serie de etapas, cada una de las cuales
C A P T U L O I IN T R O D U C C I N
produce una lnea base o configuracin ele referencia que es tomada como
plataforma para las actividades de la siguiente etapa.
El mantenimiento del software puede entenderse como el proceso de
modificar un sistema o componente software despus de la entrega aI cliente o
usuario para corregir defectos, mejorar el rendimiento o atributos, adaptarlo a
un cambio de entorno o ampliar su funcionalidad [IEEE, 1993]. En este
contexto, una lnea base puede considerarse como un producto o especificacin
que ha sido formalmente aprobado por los miembros del proyecto de desarrollo
y slo podr cambiarse mediante procedimientos formales de control de
cambios. De una manera ms sencilla se puede tomar como una fotografa
aprobada del sistema en un momento dado de su configuracin.
1.3 LA P L A N IF IC A C I N Y G E ST I N E N LA IN G E N IE R A DEL
S O FTW A R E
La Ingeniera del software se cre como un intento para resolver los habituales
problemas que se plantean en las organizaciones dedicadas al desarrollo de
software o sistemas de informacin, entre los que se encuentran los siguientes:
La imposibilidad de satisfacer en unos plazos razonables las crecientes
necesidades marcadas por sus clientes, cuyas expectativas hacen que
cada da el desarrollo sea ms complejo.
Los altos costes de mantenimiento debido fundamentalmente la escasa
o nula documentacin de los sistemas.
La necesidad de terminar el producto, en muchos casos a cualquier
coste, en un periodo limitado de tiempo debido, sobre todo, a problemas
de competitividad.
Se trata, por tanto de llevar a cabo una produccin industrializada del
software para as mejorar la calidad total de los productos y disminuir los
costes de mantenimiento. Esto implica tambin la necesidad de plantear una
autntica ingeniera de procesos, estudiando, planificando y definiendo los
mtodos de trabajo y sus flujos para conseguir maximizar la eficiencia e,
indirectamente, los resultados econmicos.
Por todo ello, las actividades de gestin destinadas a la planificacin, el
seguimiento y control de los procesos y recursos, tanto humanos como
materiales, que intervienen en un proyecto software tambin han de
 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M A T IC O S __________________________________________ C A P T U L O I IN T R O D U C C I N ______ __________________________ 15

considerarse como actividades de la Ingeniera del Software, que debern actividades de ingeniera de proceso, encargadas de la planificacin y control
integrarse con las de desarrollo para conseguir conjuntamente la obtencin de de las anteriores. Sin pasar por alto, la conveniencia de que tal metodologa
un producto software de calidad, fcilmente mantenible y a un coste y en un incluso supere los lmites de un proyecto en particular, y contemple tambin la
tiempo razonables. definicin de los procesos de planificacin estratgica de las empresas que
permitan prever su evolucin tecnolgica a medio o largo plazo.
En la figura 1.2 se muestra la integracin de los dos tipos de actividades.
En el caso de las actividades de gestin, en primer lugar se realiza la
planificacin del proyecto, en la que se definen las condiciones de trabajo, los
recursos, las fechas y se estiman los costes. A continuacin comienza el
desarrollo segn el plan establecido y, en paralelo, las actividades de
seguimiento y control para vigilar el avance del proyecto.

0 a o
Planifie Seguimiento
acin => y Control

F ig u ra / .2 Integracin d e la s actividades de desarrollo

y d e g esti n en p ro y e c to s softw are

Esta forma sistemticas de trabajar exige el establecimiento de un conjunto

de mtodos, procedimientos, tareas, herramientas que hagan posible la
realizacin del proyecto segn las etapas y actividades previstas y faciliten su
control por parte del responsable del mismo.

Los objetivos se irn consiguiendo en tanto que todas las tcnicas se

apliquen en el marco de una metodologa que cubra, en la mayor medida
posible, todas las fases del ciclo de vida del proyecto. Aunque se puede
establecer una metodologa de aplicacin totalmente manual, es conveniente
que sta sea susceptible de ser automatizada, utilizando herramientas CASE
(Computer Aided Software Engineering) que faciliten la generacin de los
productos intermedios previstos (modelos, prototipos, etc.) y el control del
proyecto, y que permita la reutilizacin de elementos en futuros proyectos.

Para concluir podemos afirmar que en una metodologa de Ingeniera del

Software se deben considerar tanto actividades de ingeniera de producto,
relacionadas directamente con la secuencia de desarrollo del software; como
PL A N IFIC A C I N Y GESTIN DE S IS T E M A S INFORM TICOS

CAPITULO 2

DEFINICIONES BSICAS

La gestin de proyectos es una rama especializada en el campo de la gestin,

cuya evolucin ha servido para controlar y coordinar algunas de las complejas
actividades de la industria moderna.

Uno de los fenmenos que se pueden observar continuamente a nuestro

alrededor es el crecimiento de las cosas vivas, observacin que puede realizarse
en las plantas, en los animales, en las colonias o, en la poblacin. Tarde o
temprano el desarrollo tiene que depender del abastecimiento de los recursos
naturales en cantidades suficientes para que la poblacin pueda sustentarse. La
competitividad en el logro del alimento deber ser cada vez mayor al haber,
cada da, ms bocas que alimentar. Cuando los recursos son escasos solamente
pueden sobrevivir aquellos organismos que puedan adaptarse a la situacin y
no necesariamente son los ms fuertes los que sobreviven -recordemos los
grandes dinosaurios de otros tiempos, eran poderosos y capaces de arrollar a
los pequeos roedores, pero que no supieron adaptarse a unas condiciones
climticas adversas mientras que los la regla de la "ley del que se adapta" se
extender como norma en la evolucin de estas formas de vida que cada vez
ser ms especializada.

En los procesos industriales existe un cierto paralelismo con los

acontecimientos que suceden en el mundo de la naturaleza cuando comparamos
los efectos del crecimiento y de la evolucin. Las empresas nacen en un
ambiente de competencia que crea una demanda cada da ms acusada de los
recursos disponibles, es ms, su propio temperamento econmico la presenta
retos continuos que la obligan a adaptarse a esas necesidades cambiantes.
Algunas nuevas empresas surgirn con xito, mientras otras no podrn soportar
la presin ejercida por aquellas que han sido capaces de readaptarse a tiempo,
lo que las obligar a dejar su espacio teniendo que cerrar sus puertas y despedir
a todos sus empleados.
18 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Supongamos que nos encontramos en una empresa que se dedica a crcar
programas informticos de gestin de empresa, a prestar servicios en la
instalacin y adaptacin de tales programas a la vez que ofrece servicios de
consultara de sistemas y que cuenta con una plantilla de unos cincuenta
empleados. La produccin de esta empresa debera estar supervisada por un
director de produccin y as se asegurara que los pedidos de mejoras,
desarrollo e implantacin de los productos que vende no tardaran ms de una
cuantas semanas en estar totalmente disponibles o incluso instalados con la
satisfaccin total de los distintos clientes. El volumen de trabajo encomendado
a los distintos empleados tiene que programarse de tal modo que se asegure
una armona total para asegurar un uso efectivo de los recursos humanos que
deben de tener una perfecta dinmica de trabajo.
En un principio, esta empresa cuenta con un director de produccin
competente que, con conocimientos basados en la propia experiencia, hace que
la empresa funcione dando beneficios, los costes se calculan a tiempo vencido
y la duracin de los nuevos desarrollos se estiman en base a la experiencia
acumulada de trabajos similares ya que, al fin y al cabo, tenan una duracin
bastante corta. Pero con el paso del tiempo esta empresa est creciendo, sus
clientes estn demandando nuevos servicios. Ahora los pedidos son mayores
tanto en cantidad como en tiempo de desarrollo, aparecen nuevos factores:
algunos clientes necesitan que alguno de los productos desarrollados para ellos
se adelanten en un plazo considerable a pesar de que el nmero de horas a
emplear en este proceso sea muy elevado. Los programas desarrollados se han
vuelto tan especializados que no tienen validez fuera del mbito del cliente
concreto que encarga este determinado trabajo. La empresa que antes tomaba
un producto del almacn y le haca cuatro pequeos arreglos, ahora tiene que
disear sistemas especiales y adaptarlos a las necesidades del cliente, de tal
modo que las entregas que antes poda realizarlas en pocas semanas ahora
necesita varios meses en poder satisfacerlas.
Qu es lo que sucede en estos momentos? Simplemente que las tareas de
antes, casi rutinarias, han dado paso a complejos proyectos y los viejos
sistemas de control y produccin ya no son efectivos por s mismos.
Cualquier intento de planificacin en el trabajo tiene que considerar todas
las fases necesarias para que ste llegue a buen trmino. El conjunto de todas
las fases de un proyecto informtico desde que se concibe hasta que muere,
bien por desuso o por sustitucin, es lo que se llama ciclo de vida de un
producto o sistema informtico. Este tipo de definiciones, y el centrar los
distintos trminos, ser el objetivo claro de esta leccin que consideramos
bsica y fcil de entender.
C A P T U L O 2 D E F IN IC IO N E S B A S IC A S 19
2.1 LO Q U E ES UN PR O Y E C T O
Como en casi todas las disciplinas, la definicin de proyectos, depende del
punto de vista que se les d a los mismos. En este sentido, y dentro del
contexto de los proyectos industriales, podemos citar a Archibald que define
los proyectos como el conjunto de procesos requeridos para producir un
producto nuevo, un bien nuevo, un sistema nuevo, u otro resultado
especificado''. Otra definicin, en este caso dado por General Electric, define
un proyecto como una actividad claramente definida, con una implantacin
de duracin finita y con una meta a alcanzar bien especificada". En este
sentido podemos fortalecer estas definiciones diciendo que un proyecto es un
conjunto de actividades dirigidas a crear un futuro deseado.
La mayor parle de los Ingenieros de hoy da han dedicado bastantes horas
a disear, desarrollar o implementar sistemas y, en este sentido, han dedicado
horas en ayudar a sus empresas a superar el reto de la incorporacin de las
tecnologas de informacin as como en hacer cada da ms coherentes los
procesos de negocio de sus organizaciones con los sistemas de informacin de
que disponen.
La mayor parte de los Ingenieros de hoy da han dedicado bastantes horas
a disear, desarrollar o implementar sistemas y, en este sentido, han dedicado
horas en ayudar a sus empresas a superar el reto de la incorporacin de las
tecnologas de informacin as como en hacer cada da ms coherentes los
procesos de negocio de sus organizaciones con los sistemas de informacin de
que disponen.
Los procesos de negocio, como decimos, suelen ser la fuente de nuevos
proyectos. Es ms, la mayora de los proyectos se originan en el seno de las
empresas como resultado de sus nuevas exigencias para poner en sus
organizaciones nuevos productos o servicios con los que se quiere
comercializar.
Los proyectos en la empresa han evolucionado enormemente. En los aos
sesenta se pona un gran empeo en desarrollar productos que fuesen
fabricados a gran escala para lo cual se estudiaban los procesos que
optimizaran cada una de las tareas o fases de desarrollo del producto.
Posteriormente, en los aos setenta, se cambi el enfoque de los proyectos por
el concepto de calidad como elemento diferenciador entre los productos
20 P L A N IF IC A C I N V G E S T I N D E S IS T E M A S IN F O R M T IC O S
ofrecidos por las distintas empresas: Se luchaba por la calidad a la vez que por
la produccin en masa que haca el producto ms competitivo en un mercado
global.
En los aos siguientes las empresas enfocaban sus productos hacia la per
sonalizacin o variedad. Las empresas ponan a disposicin de sus clientes un
catlogo de productos lo mas variado posible como fuerza de ventas. Era
necesario haccr proyectos diferenciadores de la competencia para poder seguir
manteniendo el pulso de la produccin industrial.
ltimamente el mercado exige novedad. El cliente con capacidad econ
mica de comprar un producto desea algo tecnolgicamente novedoso, y los
equipos de diseo hacen productos enfocados en esta vertiente.
Pero desde los principios de la organizacin empresarial se ha visto que es
necesario introducir una cierta previsin de lo que suceder. As podemos
definir la previsin como la accin y efecto de ver con anterioridad o
conjeturar con ciertas seales lo que suceder. Es decir, hablamos de anticipar
el futuro en base a cierta informacin, ya que no se trata de tener una frmula
mgica que adivine el futuro.
En este sentido es necesario hacer una pausa y considerar cmo son los
proyectos que se realizan en las distintas fbricas u oficinas, y considerar las
diferencias que existen entre los proyectos y los sistemas de produccin.
Podemos establecer, siguiendo este razonamiento, tres categoras dentro de la
totalidad de los sistemas de produccin existentes en el mundo actual: por una
parte estara la categora de produccin en masa, por otra parte las factoras que
hacen produccin por lotes y, finalmente, aquellas industrias que realizan
proyectos normalmente no repetitivos, mejoras, adaptaciones.
Los sistemas que circundan la produccin en masa se disean para optimi
zar cada una de las fases o tareas con objeto de reducir costes, aumentar la
calidad y mejorar los procesos. As las fbricas tienen sus ingenieros del
departamento de mtodos y tiempos, o algn nombre similar, que estudian la
duracin de cada fase, los materiales que se emplean, sus utillajes, etc.
entendiendo que optimizando cada uno de estos elementos atmicos se mejora
la calidad del producto. La ventaja de este tipo de produccin es que obtiene
datos de la experiencia anterior y continuamente trabaja por la mejora continua.
Es normal que cada una de las fases est perfectamente informada por un
sistema de gestin que recoge estadsticas para ayudar a la toma de decisin de
las posibles debilidades y mejoras a introducir. Los datos se capturan de forma
C A P IT U L O 1: D E F IN IC IO N E S B S IC A S 21
automtica y se obtienen grandes resultados basados en la eficiencia de los
medios empleados.
Los sistemas de produccin por lotes son los ms frecuentes y son los que
se producen utilizando los mismos medios para producir bienes distintos a lo
largo del tiempo. Como ejemplo se puede considerar una empresa de tipo
taller de mecanizados que un da tiene un encargo de fabricar una cantidad
de piezas concretas y, algunas horas ms larde, otro tipo de productos
utilizando las mismas herramientas y el mismo personal. El aspecto ms
importante para la rentabilidad de este tipo de sistemas de produccin es la
flexibilidad. Cada ensayo sufrido valdr para incorporar una nueva experiencia
para el futuro. Los sistemas son adaptables y se reutiliza la tecnologa
aprendida en la fabricacin de cada producto.
En contraposicin a los sistemas anteriores, los proyectos informticos
normalmente son no repetbles, en el sentido de que su naturaleza suele ser
nica, y los medios para alcanzar ese bien futuro suelen ser nuevos cada vez, lo
que implica que exista una considerable expectacin sobre los pasos a seguir, y
que supone, por tanto, un cierto riesgo a sufrir.
Es necesario, en base a las consideraciones anteriores, establecer una dife
rencia clara entre lo que son los productos, los resultados del proyecto y el pro
yecto en s mismo: as podemos definir los productos como esos bienes futuros
a obtener, es decir, los bienes o servicios que la organizacin fabrica segn la
naturaleza de sus objetivos, y que para fabricarlos se necesita de los resultados
del proyecto. Estos resultados se definen por los objetivos mismos del proyecto
y suelen formar parte del conocimiento de las propias empresas por lo que,
normalmente, no se ceden a terceros.
En el caso concreto de los proyectos, debido a que son actividades inicia
das para obtener un bien futuro, no se puede asegurar que los planes y
estimaciones sean correctos, pero es posible ir formando una base de
conocimiento para aplicarla a futuros proyectos ms o menos afines.
En otras palabras, cuando hablamos del futuro que deseamos lo tenemos
que configurar desde el presente y, en el mejor de los casos, a lo ms que pode
mos aspirar es a hacer pronsticos en los resultados obtenidos hasta el
momento actual y en la buena medida efectuada sobre esos resultados.
Por otra parte, se habla de un conjunto de procesos o actividades..., es
decir, son ms de una, y cada una de ellas, puede tener intereses o prioridades
ajenos al proyecto que en casos concretos nos puede llevar a la falta de
 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M A TICOS
recursos disponibles en el momento en el que ms nos puedan interesar. Esta
consideracin es importante porque, como se ver a lo largo del libro, se
necesitan cualidades para poder controlar cada una de estas actividades.
Otro aspecto importante, sobre todo de la ltima definicin, es la palabra
dirigidas y tambin se hablar de forma detenida de lo que se entiende por
direccin desde el punto de vista de timn que controla el rumbo del
proyecto. Pero el director (o gestor) del proyecto necesita del poder de decisin
necesario para poder administrar un determinado marco de referencia.
Tambin ha surgido el trmino control, que en su momento
entenderemos que es la posibilidad de saber en cada momento la posicin
exacta en que nos encontramos en el desarrollo del proyecto. No es posible
separar la palabra gestin del trmino control debido a que no se puede gestio
nar algo con ciertas garantas de xito si no se controla.
2.2 T IP O S D E P R O Y E C T O S
Podemos clasificar los proyectos segn varias vertientes o aspectos:
Tcnicos y no tcnicos
Unipersonales y inultipersonales
Monodisciplinares y multidisciplinares
Monocontrato o multicontrato
Resultados: tangibles o intangibles
Rentabilidad econmica o rentabilidad social
Con fines claros: proyectos espaciales
Las caractersticas de cada tipo de proyecto nos pueden servir para estudiar
el entorno entendido como el conjunto de condiciones en las que se va a
realizar el proyecto. El entorno puede cambiar en funcin de otro tipo de
prioridades ajenas al propio proyecto. Una de las amenazas ms fuertes sobre
el proyecto es el contexto socio-econmico, por lo que tendremos que
formularnos preguntas del tipo Podemos cambiar el entorno del proyecto a
nuestra voluntad? Se modificar el proyecto si cambian las condiciones
extemas?.
Igualmente, en funcin del tipo de proyecto, tendremos que tener un cui
dado especial en la forma de controlar los gastos, que las disposiciones de
efectivo se realicen segn el presupuesto previamente establecido, las
C A P T U L O 2: D E F IN IC IO N E S B S IC A S 23
condiciones administrativas y su implicacin con los otros proyectos, o con
actividades coyunturales que puedan surgir.
Es necesario conocer de forma detallada las condiciones de contorno, en
particular las prioridades del proyecto y, a ser posible, tratar de tener un
calendario en el que se fijen los hitos ms importantes del mismo. Hay que
considerar la poltica de la propia compaa respecto a este Proyecto porque
puede definir la atencin que se puede esperar de sus directivos. En algunos
proyectos tendremos que marcar una importancia alta a la normativa legal que
exista para el desarrollo de proyectos concretos y as no tener que vulnerar la
ley o contradecirla por no conocerla.
Un nfasis especial tendremos que dar a las necesidades de comunicacio
nes que los entornos modernos demandan. En este sentido se debe de
considerar la posibilidad de disponer de herramientas de gestin automtica de
bases de conocimiento y mensajera para todo el grupo de desarrollo que, en
algunos casos, puede estar constituido por personas fsicamente distantes lo
que nos puede llevar a considerar la necesidad de infraestructura adicional,
como puede ser videoconferencias, correo electrnico, y, en general, la
disponibilidad de tejido industrial
Con este tipo de informacin la Direccin de la empresa aborda la decisin
de comenzar el proyecto. En el captulo quinto se desarrollan los aspectos
econmicos y algunos parmetros sobre el estudio de la rentabilidad.
Ejemplos de proyectos pueden ser:
La sustitucin de un sistema informtico en una empresa.
El traslado de un determinado departamento de una planta a otra.
La fabricacin de un nuevo electrodomstico en una fbrica de
lavadoras.
El desarrollo e implantacin de un nuevo Sistema de Informacin para
el departamento de ventas de una organizacin.
La migracin de un sistema informtico basado en terminar orientado a
carcter a consultas tipo web.
La implementacin de un sistema de e-businnes.
La contratacin de un sistema de soporte para una determinada planta
de fabricacin industrial.
El establecimiento de una serie de indicadores de captura automtica
que midan la evaluacin del desempeo del personal.
 PL A N IFIC A C I N Y GESTIN DE S IS T E M A S INFORM TICOS C A P T U L O 2: D EFIN IC IO N ES BSICAS 25
24

2.3 LOS PROCESOS I)E INGENIERA DEL SOFTWARE. PSl l

IrtiOo d tl P i n de
*SI 2
D c U i i< A y
3 PSl 7
0*finci*n efe Id
PSIO P S l*
S is t e flU i do del IM o rm acio n R e v is i n y
Afquilcturj
IftfOr m se ln PSl Kdevftnlc de A ce **
T*cn<?lgicd

Una vez fijados los aspectos generales vamos a tomar tierra' con los procesos T
de ingeniera del software entendidos como las etapas que debe satisfacer un PSl 4
PSl 6
D is e o i f / o d d o
ld n l^ i c c i& n d *
proyecto de informtica para llegar a su fin. En este sentido es necesario que el 0# S 't l e m a s d e
in fo rm a c i n

Director de Proyecto considere de forma detallada los flujos de trabajo que

existan en su organizacin, as como las metodologas internas de produccin PSl 6
* U i 0o 0e los
de
que pueden ser factores dependientes que le establecen un determinado marco loorm acin
elu ato
de maniobra y que, normalmente, deber cumplir.

En este sentido tiene capital importancia seguir las pautas de: Figura 2.1 Secuencia de actividades segn Mtrica V.3

La Planificacin del Proyecto.

La Comunicacin Tcnica
2A ORGANIZACIN DEL PROYECTO
La Gestin de Configuraciones
El Control de Calidad
Se pueden aplicar una variedad de estructuras para organizar el proyecto en
La Organizacin administrativa del proyecto
funcin del bien a producir, de la naturaleza del proyecto, del nivel de riesgo,
La Gestin del Centro de Proceso de Datos las posibilidades tcnicas del director o del equipo de desarrollo, etc.

Y en general todo tipo de procesos que tienen relevancia dentro de los

aspectos considerados por la profesin del informtico.
El Ministerio de Administraciones Pblicas, a travsr del Consejo Superior
de Informtica (CS1), ha publicado la Metodologa METRICA versin 3, en
uno de cuyos apartados lo dedica a la Planificacin de Sistemas de Informacin
segn nueve actividades concretas resumidas en los siguientes puntos (figura
2 .1):
Inicio del Plan de Sistemas de Informacin (PSl)
Definicin y organizacin del PSI
Estudio de la Informacin Relevante
Identificacin de Requisitos
Estudio de los Sistemas de Informacin actuales
Diseo del Modelo de Sistemas de Informacin
Definicin de la Arquitectura Tecnolgica
Definicin del Plan de Accin
Revisin y Aprobacin del PSI
La palabra "organizacin deriva de ordenar en el sentido de disear la
estructura o arquitectura con la que vamos a establecer las dependencias entre
individuos, departamentos, cosas... dentro del proyecto. Asignar las tareas ms
idneas para esas capacidades y el tiempo estimado para cumplir las tareas o
funciones.
Desde este punto de vista disponemos de cuatro aspectos bsicos: tareas
que se tienen que realizar, de individuos que forman parte del proyecto con sus
conocimientos, motivacin, capacidad, actividades..., de los recursos, que a su
vez pueden ser materiales o no, de los que disponemos para desarrollar el pro
yecto, y de las e stru c tu ra s form ales organizativas que van a marcar las reglas
del juego.
Los modelos organizativos clsicos se clasifican, en una primera visiru en
las siguientes categoras:
E / modelo lineal: En este tipo de modelo se da el principio de unidad de
mando y disciplina. Cada persona tiene un solo jefe al que dar cuentas.
La responsabilidad y relacin con los dems est claramente definido.
Son eficaces en control de tareas y tienen bajo coste de funcionamiento.
Rigidez de estructura y poca cultura dinmica. (Fayol y Weber).
 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
El modelo de Tcivlor: Trata de separar las actividades mentales de las
corporales. Desplazar la responsabilidad de la masa obrera al manager.
Trata de la especializacin de tareas (un obrero una tarea). Previsin
adecuada de jefes mediante el estudio del trabajo que se va a dirigir y
basado en un acuerdo entre obrero y empresario para definir
retribuciones conforme al trabajo realizado.
El modelo de Henry Ford: parte de la fabricacin en serie siendo ms
prctico que terico. Parecido al de Taylor pero hace descender el
nmero de controladores dejando esta labor a la propia cadena de
montaje.
En cuanto a la estructura organizativa, con independencia del tipo de orga
nizacin, se suele utilizar alguna de las siguientes:
Estructura funcional: Las tareas del proyecto, las funciones y las
actividades se clasifican en categoras diferenciadas entre s y se
ordenan en funcin del objetivo a cubrir por el proyecto.
Estructura de autoridad: Se establece una jerarqua entre el personal
determinando las responsabilidad de cada uno y sus controles.
Estructura de decisin: Cada persona, segn la autoridad que posee,
tiene la capacidad de adoptar una u otra decisin
En este apartado no podemos olvidar los principios organizativos clsicos
que hacen que el grupo de proyecto funcione debidamente:
Principio de objetivo: Cada componente del proyecto tiene que
contribuir a conseguir el objetivo fijado por dicho proyecto.
Principio de definicin: Es necesario especificar al mximo las tareas
que cada persona tiene que desempear y qu responsabilidades tiene
en ese sentido.
Principio de autoridad: Es necesario limitar el nmero de personas con
el que nos tenemos que relacionar. Limitar las relaciones entre personas
y funciones.
Principio de responsabilidad: La responsabilidad de cada directivo
abarca tambin la responsabilidad de los subordinados.
C A P T U L O 2: D E F IN IC IO N E S B S IC A S 27
Principio de continuidad: la reorganizacin es un proceso continuo.
2.5 EL D IR E C T O R DEL PROYECTO: SU P E R F IL Y SU
ID E N T ID A D
El Director de Proyecto debe de estar en lnea con el director de los Servicios
Informticos (o cargo similar dentro de la organizacin) y se le debe de otorgar
la suficiente autoridad para gestionar los conflictos que, desde su nivel hacia
abajo, puedan producirse dentro del proyecto. Igualmente debe de gozar de una
independencia suficiente como para poder analizar cada problema con
suficiente objetividad para mejor servicio de su organizacin.
Entre las cualidades que se deberan buscar para el Director del Proyecto
cabe destacar las siguientes:
Mente estructurada y lgica
Liderazgo y Aceptacin por el grupo de trabajo
Conocimiento del sector de la actividad del proyecto
Madurez
Formacin especfica en aspectos gerenciales (direccin por objetivos)
En concreto es necesario mantener un cierto equilibrio entre directivo y
tcnico. Es de considerar que el principal reto personal del director est en
encontrar ese difcil equilibrio entre sus funciones directivas -m uy importante-
y el papel tcnico. De hecho si aspira a un puesto superior dentro de su
organizacin debe de tener preparado un sucesor lo suficientemente preparado
para no tener problemas con la herencia acumulada ya que puede convertirse
en un arma de doble filo que se puede volver contra l mismo.
La direccin es tcnica, ciencia y artel. En este sentido es necesario, en las
empresas actuales, que los empresarios y directivos sean capaces de guiar a su
empresa u organizacin en un proceso de continua transformacin que, para
adaptarse a su entorno, necesitarn afrontar debidamente. Pero para poder guiar
o conducir a sus empresas, se necesitan de unas dotes de liderazgo para que su
personal confe en ellos y les tenga como referencia en el bien hacer las cosas.
Sin embargo las caractersticas de los lderes sueles ser distintas, sobre todo si
1 Arte: Conjunto de reglas o preceptos para conseguir hacer bien una cosa (Diccionario de la
Real Academia de la Lengua Espaola)
28 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S _________________________
contemplamos a hombres que han conducido la historia, como pueden ser
Ghandi, Stalin, Cario Magno, etc.
Si bien la nocin del liderazgo la tenemos asumida como el arte de dirigir,
conducir y proceder, nosotros la podemos centrar como la capacidad para
crear una visin convincente, trasformarla en accin y sostenerla. En este
sentido es necesario sealar algunos elementos del liderazgo, entre ellos:
La habilidad para utilizar el poder con efectividad y responsabilidad.
La capacidad para entender cuales son las motivaciones ms
importantes de sus seguidores.
La habilidad para saber conseguir que sus seguidores apliquen todo su
potencial para la consecucin de los objetivos.
La capacidad para crear un estilo propio conservando un ambiente que
favorezca el desempeo de sus esfuerzos para conseguir llegar a las
metas marcadas.
La mayora de los directivos tratan de ser lideres mediante algunos de los
sistemas clsicos, que cada uno de ellos en su ambiente concreto ha
demostrado su buen funcionamiento, y que son el estilo democrtico, el
autoritario y el del liberalismo. Sin embargo fue Rensis Likert en 1969 quien
sostena que el estilo participativo en la gestin era el que mejor resultado daba
en cuanto al rendimiento de las empresas. Criticado por sus contemporneos
que mantenan que Likert no tena datos que soportaran esta afirmacin, realiz
una encuesta evaluada por el personal a cargo de los directivos, que le condujo
a clasificar sus estilos de direccin hoy ampliamente aceptados y que son:
Gestin explotadora y autoritaria, con directivos autocrticos que no
confan en sus subordinados motivando con castigos donde la
comunicacin es totalmente descendente.
Gestin benvola y autoritaria de directivos que motivan,
generalmente, con premios. El tipo de informacin es descendente y,
cuando interesa a la direccin, ascendente.
Gestin consultiva. En este tipo de estilo la direccin confa
plenamente en sus empleados, se delega autoridad para los temas
tcnicos y los flujos de comunicacin son ascendentes y descendentes.
Gestin participativa. Los directivos promueven la participacin y
ofrecen recompensas econmicas. Todo el grupo se siente cercano y
toda la toma de decisiones se realiza a travs de procesos participativos
del grupo. En este estilo de gestin la informacin fluye de arriba
abajo, as como entre grupos y sus elementos y es el ms realista a la
hora de fijar sus metas.
C A P T U L O 2: D E F IN IC IO N E S B S IC A S 29
Es ms, Likert llega a proponer un quinto estilo que, segn l, surgir en el
luturo y que romper con la estructura piramidal de la autoridad.
Los cuatro estilos bsicos de direccin, se pueden observar desde la
personalidad del jefe, que estar condicionado por su experiencia, por la
responsabilidad de sus colaboradores y por la confianza mutua entre lodos
ellos2. Segn el tipo de direccin se desprendern cierto tipos de actitudes
entre las que caben distinguirse la actitud de apoyo que se corresponde con una
buena comunicacin entre el Director y los colaboradores que participan en el
proceso de las decisiones, hasta la actitud de rdenes que el director emite
sobre el subordinado con indicacin clara de qu debe hacer, en qu momento,
con qu medios, de qu forma, supervisndose su cumplimiento.
Existe, tambin, la teora del Ciclo Ininterrumpido que reconoce que el
estilo de liderazgo ms apropiado depende del lder, del equipo y de la
situacin ya que el seguimiento de un estilo u otro viene condicionado por los
respectivos grados de madurez de cada miembro del equipo. El lder puede
seguir un estilo u otro a lo largo del tiempo y en funcin del colaborador.
Para conocer el estilo de direccin de un jefe se suele emplear la tcnica
conocida como la rejilla gerencial en la que se representan, segn dos
dimensiones, la preocupacin por la produccin y la preocupacin por las
personas. En el eje de abscisas se representa la preocupacin por la produccin,
donde se incluyen las actitudes del jefe frente a los problemas de gestin de la
empresa, como pueden ser el cumplimiento de la normativa, la productividad
del puesto de trabajo, la calidad de los servicios prestados, la creatividad y la
seguridad en los procesos de la toma de decisiones. En el eje de ordenadas se
representa la preocupacin por las personas, esto es, el inters por la
motivacin, la toma de compromisos del grupo y la calidad de sus relaciones
internas.
En la figura 2.2, se representan los cuatro estilos extremos para ayudar a
comprender la rejilla gerencial.
2 Descrito ms ampliamente en MANAGEMENT OF ORGANIZATIONAL BEHAVIOR-
UTILIZING HUMAN RESOURCES. Prentice-IIall, 1981.
30, P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
preocupacin por la produccin
Figura 2.2 Rejilla gerencias de Likeri
El director de proyecto, adems debe de tener unas ciertas nociones sobre
motivacin que es conveniente tocar en la presente seccin, si bien su
desarrollo s reserva al captulo dieciocho, donde descubriremos la importancia
de saber qu es lo que hace que las personas trabajen para conseguir sus
objetivos; cuales son sus motivaciones y cmo podran aumentarse. Una de las
principales tareas del director ser motivar, es decir, detectar las necesidades
personales de sus empleados y encontrar el modo de satisfacerlas por medio de
su propia actividad en la empresa.
Antes de abandonar este captulo en el que hemos tratado ligeramente de
los estilos es conveniente hablar de dos filosofas de direccin:
La Direccin por Excepcin
La Direccin por Objetivos
La filosofa de la Direccin por Excepcin consiste, bsicamente, en
limitarse a recibir la informacin de las incidencias y de las circunstancias
excepcionales sin involucrar al personal colaborador en otras tareas
participativas. Por otra parte la Direccin por Objetivos, basado en un sistema
que supone que las personas se implican en su trabajo identificando las metas
comunes con la direccin, definiendo sus respectivas reas de responsabilidad
y evalundose en la consecucin de los resultados.
En el arte de dirigir proyectos, se definen una serie de cualidades que se
deben de disponer para poder controlarlos y que son:
C A P T U L O 2: D E F IN IC IO N E S B S IC A S 31
Disciplina
Concentracin
Paciencia
Preocupacin
Razn y humildad
Una serie de habilidades, entre ellas:
Liderazgo
Creatividad
Capacidad de integracin
Aficin al orden y al control
A pesar de tener todos los ingredientes para poder tener xito en los
proyectos es necesario entender que estos, normalmente, se desarrollan contra
las metas comunes de la organizacin (sobretodo si se realiza desde otra
organizacin contratada para este fin) y que existe una cierta iteracin entre el
hombre y el proyecto que hace, que frente a cualquier cambio del entorno,
entendido este como el conjunto de condiciones en las que se va a realizar el
proyecto, se puedan producir una serie de resultados no deseados e, incluso,
impredecibles, por lo que se deber tener en cuenta este tipo de coyunturas, en
especial el contexto socio-econmico que normalmente suele seres el ms
cambiable.
El entorno no siempre podemos controlarlo y, si cambian las condiciones
externas, el proyecto se modificar. Es ms, en momentos de conflicto,
tendremos que saber controlar los gastos y conocer lo que pasar con otros
proyectos.
2.6 E SP E C IF IC A C IO N E S DEL P R O Y E C T O
Cuando en una organizacin se plantea, o se descubre, una nueva necesidad
que se pretende resolver con un sistema informtico, ser necesario establecer
previamente un estudio de viabilidad donde se valore, en la medida en que se
pueda, el esfuerzo necesario para que el desarrollo del nuevo sistema pueda
llegar a construirse. En este sentido el director del proyecto deber ser capaz de
preparar un documento en el que se plasmen, de modo formal, los objetivos del
proyecto, as como las directrices generales de planificacin, estimacin y
gestin del proceso del proyecto.
En este documento se deber:
32 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 2: D E F IN IC IO N E S U S IC A S 33

Establecer el mbito y alcance del proyecto, o lo que es lo mismo,

definir los productos a obtener. Existen diferentes modelos de ciclo de vida que pueden aplicarse en
Establecer los criterios de terminacin del proyecto. funcin del tipo de sistema a desarrollar. As, el ciclo de vida denominado
Efectuar un balance del estado actual mediante la identificacin de los "vertical" sera adecuado para sistemas pequeos, con gran urgencia de
problemas existentes y de las necesidades futuras. desarrollo y una relativa corta esperanza de vida. El "ciclo evolutivo"
En algunos casos se puede disear un modelo que represente la contempla la posibilidad de desarrollar una primera versin bsica que se ir
situacin anterior. ampliando en versiones sucesivas. El "ciclo de software estndar", por su parte,
Concepcin de los objetivos y definicin de los requisitos a satisfacer. es adecuado cuando se trata de seleccionar y adaptar un paquete de software
existente.
Documentar los supuestos sobre los que se han producido las
estimaciones.
Sin duda, el modelo de ciclo de vida ms completo es el denominado
Estudio de la viabilidad de las diferentes alternativas de la construccin.
"clsico" o "en cascada" (waterfall model). Este ciclo establece una serie de
fases, al finalizar las cuales se obtiene una serie de productos (documentos,
Pasamos a comentar los beneficios de obtener este documento de
diagramas, programas) que permite evaluar lo realizado hasta ese momento y
objetivos: por una parte se debe de considerar que los proyectos tienen
continuar con la fase siguiente o modificar algunos aspectos de las fases
dificultades al arrancar y al terminar. Las dificultades de comienzo tienen una
anteriores (proceso de realimentacin). En la figura 2.3 se muestra un ejemplo
consecuencia clara en la realizacin del proyecto ya que, en funcin del
de modelo de este tipo, adaptado del propuesto por la metodologa MTRICA
desarrollo de las conversaciones iniciales y de la coyuntura en la que se haya
versin 3.
planteado la necesidad del proyecto, conducen a que los elementos de anlisis
previos hayan podido estar distorsionados y la informacin de partida, por lo
tanto, puede ser inconsistente.

P la n ificac i n listn
Por otra parte, los criterios de terminacin son bsicos para poder A N A L IS IS D EL S IS T E M A
establecer las responsabilidades finales en una actividad que siempre va a tener
que estar siendo mantenida. Este factor ser mucho ms importante en tanto A jilisis d e
que la necesidad de un proyecto nazca de una empresa cuya relacin con el R eq u isito s
del S is te m a
grupo de desarrollo sea, o no, ajena al mismo. Estos factores, o criterios de
terminacin, deben de ser discutidos por ambas partes y consensuados para T T T
E specificacin
Funcional del
que, finalmente, quede perfectamente escrito en el documento de alcance o S istem a _
especificaciones del proyecto.
.-s r s r x r r - - " D iseo
d el S istem a
Con este documento, tanto la direccin como el grupo de desarrollo, debe
de tener suficiente informacin como para saber en qu se estn C o n s tru c c i n
del
comprometiendo, y si pueden o no aceptar el proyecto, sus plazos y sus
S is te m a
clusulas sin incurrir en penalizaciones que pueden ser muy perjudiciales tanto
para el equipo de desarrollo como para la organizacin origen del proyecto. Im p lan tac i n
del
S istem a

2.7 E L C IC L O DE V ID A I)E U N P R O D U C T O IN F O R M T IC O

El ciclo de vida es el conjunto de fases por las que debe pasar un proyecto de Figura 2.3. Fases del ciclo de vida de un Sistema de Informacin
desarrollo de un sistema de informacin desde su concepcin inicial hasta que
el sistema deja de utilizarse o se transforma en otro.
 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
34
Aunque en la segunda parte de este texto se describen con detalle todas las
actividades a realizar en cada fase, a continuacin se indica someramente el
objetivo de cada una de ellas:
Planificacin Estratgica: No se considera estrictamente como una
fase del ciclo de vida, ya que su existencia es opcional (no es necesaria
si se desarrollas un sistema aislado), y no afecta a un slo sistema. Si
existe, su objetivo es adecuar los objetivos estratgicos de la
organizacin (de usuario) y la informacin necesaria para soportar
dichos grandes objetivos. Para tal labor se hace necesaria una
metodologa de planificacin de sistemas que abarque a toda la
organizacin y exija considerar una serie de conceptos que desbordan el
marco especfico de una Metodologa de Desarrollo de Sistemas, por lo
que no se tratar en este texto. No obstante, si se ha llevado a cabo, el
producto final que se habr generado, ser la definicin de los sistemas
de informacin que se deben desarrollar para satisfacer los objetivos
estratgicos de la organizacin. Por tanto, la parte de este documento
que haga referencia al sistema concreto que se vaya a desarrollar, puede
ser el punto de partida para la siguiente fase, la de Anlisis del Sistema.
Fase de Anlisis: El objetivo de esta fase es el estudio de las
necesidades de informacin que debe satisfacer el sistema a desarrollar,
elaborando una serie de especificaciones formales que describan la
funcionalidad del mismo y que permitan abordar con garantas la
siguiente fase (Diseo). Esta fase de Anlisis se puede estructurar en
dos sub-fases claramente diferenciadas, en las que se lleven a cabo tales
actividades:
o Anlisis de Requisitos del Sistema: Se trata de establecer el
alcance, los objetivos y requisitos del sistema, examinando las
posibles alternativas que podran solucionar las necesidades del
usuario (cliente) y recomendar una de ellas. Al final de esta sub-
fase se obtiene un documento denominado "Documento de
Requisitos del Sistema" (DRS).
o Especificacin Funcional del Sistema (conocida
tradicionalmente como "Anlisis Funcional"): Una vez aceptado
formalmente el documento anterior por las partes (organizacin
de desarrollo-organizacin de usuario), se elabora un conjunto
de especificaciones formales que describan la funcionalidad del
sistema, estableciendo los subsistemas en que se descompondr,
definiendo los datos que utilizar y las interfases de usuario.
C A P T U L O 2: IJH F IN IC IO N H S B A S IC A S 35
Tambin se planificarn las pruebas que deber superar el
sistema, se estimar la relacin coste/beneficio para comprobar
si interesa su construccin y se establecern los plazos de
entrega del sistema. Todo ello se recoge en dos documentos,
denominados "Documento de Especificacin Funcional del
Sistema" (DEFS) y "Documento de Pruebas del Sistema"
(DPS).
Fase de Diseo (conocida tradicionalmente como "Anlisis Orgnico"):
El objetivo de esta fase es obtener un conjunto de especificaciones que
contemplarn los aspectos fsicos del sistema, considerando las
caractersticas tecnolgicas del entorno especfico en el que se
implantar, que constituirn el punto de partida para la construccin del
sistema. Al final de esta fase se obtienen el "Documento de Diseo
Tcnico" (DDT) y el anterior "Documento de Pruebas del Sistema"
(DPS) con las ampliaciones relativas a la definicin del entorno de
pruebas.
Fase de Construccin: El propsito de esta fase es, a partir de las
especificaciones de diseo, la obtencin del sistema completamente
construido y probado, listo para ser implantado en la organizacin de
usuario. Tambin durante esta fase se desarrollar el conjunto de
procedimientos y se llevar a cabo la formacin necesaria que
permitir, tanto al personal del rea de usuario final como al personal
del rea de explotacin o proceso de datos (si existe), la utilizacin
ptima del sistema. Adems del software correspondiente, al final de
esta fase tambin se obtendrn los siguientes documentos:
"Documentacin Tcnica de Programacin" (DTP), "Manual de
Usuario" (MU), "Manual de Explotacin" (ME), "Documento de
Pruebas del Sistema" (DPS), ampliado con los informes de las pruebas
unitarias, de integracin y globales.
Fase de Implantacin: El objetivo de esta ltima fase es la puesta en
servicio del sistema construido y conseguir su aceptacin final por parte
de los usuarios del mismo, para lo cual se tratar de hacer ver a stos,
mediante demostraciones formales (pruebas de aceptacin), que el
sistema cumple todos los objetivos y requisitos para los que fue
desarrollado. En esta fase se incluye la ejecucin y el mantenimiento
del sistema, con lo que su duracin se prolongar hasta que el sistema
deje de utilizarse o sea sustituido por otro.
P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M TIC O S

CAPTULO 3

FACTORES DE DIMENSIN

El anlisis de los problemas a resolver y los medios a utilizar para realizar un

determinado sistema constituyen una de las fases fundamentales en el
desarrollo del estudio, pues es en ese momento cuando la toma de conciencia
del cambio previsto debe de ser asimilado por los usuarios del futuro servicio.
En este momento se debe de efectuar una valoracin estimada de los distintos
recursos que se deben de aplicar a la consecucin del citado proyecto.

En cualquier caso, para llevar a buen trmino un proyecto de desarrollo de

software, es necesario comprender el mbito del trabajo a realizar, los recursos
requeridos, las distintas tareas que se deben de ejecutar, el esfuerzo a emplear y
el calendario que debe de cumplirse. La planificacin del proyecto de software
es un primer paso en el proceso de la ingeniera del software y nos
proporcionar este conocimiento. Pero, al inicio de la planificacin, el director
se encuentra con un fuerte dilema: necesitara una estimacin slida de la
estimacin cuantitativa, pero conocer tales estimaciones son fruto de un
anlisis detallado que puede durar incluso meses, sin embargo las estimaciones
se necesitan "ya".

El objetivo de la planificacin del proyecto software -y la definicin de tal

proyecto est incluido en s mismo- es el de suministrar un rea de trabajo que
permita al director hacer razonadas estimaciones de recursos, costes y mtodos
necesarios para terminar el proyecto con los niveles de satisfaccin deseados.
Estas estimaciones se efectan sin un plazo de tiempo conveniente y debern
ajustarse a lo largo del desarrollo del mismo segn los progresos que se vayan
realizando.

Como se ha mencionado anteriormente, el objetivo e la planificacin se

alcanza a travs de un proceso de descubrimiento de informacin que lleve a
estimaciones razonables, pero no se puede emplear las mismas tcnicas y
mtodos para proyectos de un esfuerzo de unos centenares de horas/hombre o
de varios miles de horas/hombre.
3S P L A N IF IC A C I N Y G E S T I N DF. S IS T E M A S IN F O R M TIC OS
Una de las actividades necesarias para poder estimar en un primer anlisis
el esfuerzo es tratar de delimitar el mbito del software, para ello se valorarn
las funciones que deben de realizarse y el rendimiento que se espera de tales
funciones, este anlisis se verter en un documento que deber ser lo menos
ambiguo y lo ms claro posible para que lo entiendan los distintos directores a
los que afecte la materia. En este documento se deben delimitar los datos
cuantitativos que sean necesarios para definir el alcance, (por ejemplo se
delimitar el nmero mximo de usuarios que acceder de forma concurrente al
sistema, el tiempo mximo de respuesta, el tamao de cada uno de los ficheros,
etc.). Tambin se describirn las restricciones del tiempo de procesamiento, las
interfaces de usuario, la fiabilidad, etc.
El director del proyecto, con el informe anterior, tendr una primera
aproximacin para estimar el esfuerzo total para acometer el proyecto y, si este
documento ha sido cuidadosamente elaborado, tendr una descripcin de las
tareas a desarrollar con una primera documentacin que puede ser firmada para
fijar un primer marco de actuacin.
Con este documento podr hacer una estimacin razonada del esfuerzo a
realizar en cada una de las etapas del ciclo de vida del proyecto, es decir, que
tiempo estima que se ha de dedicar al anlisis funcional, cuanto al diseo,
cuanto al desarrollo, etc.
La segunda fase para efectuar una posible planificacin del proyecto es la
estimacin de los recursos que son necesarios para acometer el esfuerzo de
desarrollo de software anteriormente sealado: por una parte los recursos
mquina o herramientas necesarias para facilitar el desarrollo de las distintas
tareas y, por otra parte, las personas que utilizan esas mquinas y/o
herramientas. Cada recurso se debe especificar por cuatro caractersticas:
El recurso en s (su descripcin)
Disponibilidad en s
Las distintas fechas en las que se le requiere
La duracin a partir de cada fecha de comienzo
Las dos ltimas caractersticas son en s una tabla mltiple y, veremos ms
adelante, que tales fechas y duraciones son fluctuantes en un tiempo concreto
debiendo ser su disponibilidad -referida a esa fecha- lo ms pronto posible.
C A P IT U L O 3: F A C T O R E S D E D IM E N SI N 39
Se discutir en clase los factores que inciden en los recursos humanos
como pueden ser la motivacin, los calendarios laborales, las fiestas, la
formacin del personal, las distintas categoras, etc.
Por otra parte se valorarn especialmente los recursos de hardware,
haciendo referencia al propio ordenador como un potencial importante en la
informtica. Se considerarn tres aspectos bsicos en el ordenador durante la
planificacin del proyecto software: el sistema de desarrollo, la mquina
objetivo y otros elementos hardware del nuevo sistema.
Los recursos software los utilizaremos del mismo modo que se utilizan las
mquinas y utilizaremos software para construir nuevo software. En este
momento se debern mencionar tanto las herramientas actuales (herramientas
orientadas al cdigo, orientadas a la metodologa, orientadas a la construccin
de prototipos y generadoras de cdigo fuente) como futuras (sistemas expertos
para el proceso de lenguaje natural, ayudas colegiadas en la toma de decisiones
en el mismo proyecto, etc.).
3.1 E SF U E R Z O T O T A L D E D IC A D O A L SO FTW A R E
Como veremos a lo largo de este libro, las estimaciones de recursos, de plazos
y de la calidad esperada del producto suelen estar bastante distantes del
objetivo final del cliente o de la organizacin usuaria del sistema de
informacin. En general todo se traduce en precisar un equilibrio en el
tringulo del triple compromiso: Calidad, coste y calendario.
Figura 3.1 El tringulo del triple compromiso
Al inicio del proyecto es normal que se trabaje con una cierta
incertidumbre en cuanto a las estimaciones que se van aclarando conforme se
consumen las fases anteriores. Sin embargo es fundamental considerar el
40 ______________ P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S _________________________
equilibrio de compromiso entre los tres aspectos de gestin en la planificacin
de proyectos. De todas formas, cuando la calidad forma parte de la
organizacin, o se asume desde ciertos estndares, es mejor hablar de producto
desde el punto de vista de tamao, es decir, desde el nmero de cosas que se
espera que se realicen hasta la finalizacin del proyecto. En el producto se
incluyen todos los aspectos que intervienen en el software final, desde los
requisitos hasta los programas ejecutables pasando por todos los casos de
prueba, la documentacin del sistema y los criterios de usabilidad.
Es normal que el proyecto comience con cierta desidia, de tal suerte que el
esfuerzo total dedicado al proyecto sea poco relevante. En algunas ocasiones se
teme por los grandes riesgos que el estado cambiante de la tecnologa introduce
o por la incorporacin de cambios dentro del propio proyecto, sin embargo es
necesario hacer nfasis en que el coste que pueda resultar debido a la falta de
planificacin efectiva que hace que no se acometa el proyecto con toda la
fuerza productiva, puede ser muy alto si se quiere mantener el compromiso de
los plazos.
Cuando nuestros interlocutores nos ayudan a descubrir sus requisitos
tendremos que hacer una cierta estimacin entendida como una cierta
incertidumbre que pretender objetivizar el coste...La estimacin se basa en
emplear datos histricos bien definidos, precisos y exactos que nos llevar a un
modelo basado en experiencias que necesita de la habilidad de la persona que
la efecta para no tratar de subjetivizar las ideas de la parte contratista.
Los datos de referencia suelen ser los de la propia empresa que parecen
asemejar las circunstancias pero, se deben de considerar, los datos extemos
para hacer estimaciones comparativas.
Cuando se dispone de una cierta estimacin tendremos que hacer un
planteamiento al cliente de la organizacin usuaria para tratar de llegar al
compromiso sobre los vrtices del tringulo de tal suerte que, si no se puede
satisfacer alguno de los extremos de sus necesidades, seguramente el proyecto
no se podr desarrollar en esos parmetros. Nuestro trabajo como jefes de
proyecto ser facilitar alternativas a cada uno de los puntos para que el
equilibrio nuevamente se establezca.
Es muy importante en esta fase de la negociacin considerar el esfuerzo
total dedicado al software: en general todas las fases de la Planificacin y
Gestin de Sistemas de Informacin as como su desarrollo son esfuerzos de
software.
C A P T U L O 3: F A C T O R E S D E D IM E N S I N 41
3.2 DISTRIBUCIN DEL ESFUERZO
Antes de entrar en la parte tcnica de comprender cmo se lleva a buen fin los
procesos de planificacin y gestin de sistemas de informacin vamos a
fijarnos en una metodologa muy prxima, en nuestro caso a la Metodologa
Mtrica v.3 creada por el Consejo Superior de Informtica del Ministerio de
Administraciones Pblicas, que ofrece a las organizaciones un instrumento til
para la sistematizacin de las actividades que dan soporte al ciclo de vida del
software dentro de un marco, que como dice la propia metodologa, permite
alcanzar los siguientes objetivos:
Proporcionar o definir Sistemas de Informacin que ayuden a conseguir
los fines de la Organizacin mediante la definicin de un marco
estratgico para el desarrollo de los mismos.
Dotar a las Organizaciones de Productos Software que satisfagan las
necesidades de los usuarios dando una mayor importancia al anlisis de
requerimientos.
Mejorar la productividad de los departamentos de Sistemas y
tecnologas de la Informacin y las Comunicaciones, permitiendo una
mayor capacidad de adaptacin a los cambios y considerando la
reutilizacin en la medida de lo posible.
Facilitar la comunicacin y entendimiento entre los distintos
participantes en la produccin del software a lo largo del ciclo de vida
del proyecto, teniendo en cuenta su papel y responsabilidad, as como
las necesidades de todos y cada uno de ellos.
Facilitar la operacin, mantenimiento y uso de los productos software
obtenidos.
Mtrica V.3 tiene un enfoque orientado al proceso siguiendo la tendencia
de los estndares que se encaminan en este sentido por lo que se ha enmarcado
dentro de la norma ISO 12207 que se centra en la clasificacin y definicin de
los procesos de ciclo de vida.
Dentro de la metodologa Mtrica Versin 3, se estructura un apartado
importante bajo el epgrafe de Planificacin de Sistemas de Informacin, cuyo
enfoque, al no estar soportado por la norma ISO 12207, se ha determinado en
42 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
el estudio de los avances surgidos en esta rea de inters junto con las
presiones de la alta competitividad y la naturaleza de adaptacin al cambio a
los que estn sometidas la mayora de las Organizaciones. Este entorno fuerza
a que cada da se consideren con mayor nfasis el requerimiento de disponer de
sistemas de informacin muy flexibles para poder adaptarse a las exigencias
que demanda el mercado y con una rapidez de adaptacin hasta ahora casi
inimaginable.
En particular, dentro del apartado Planificacin de Sistemas de
Informacin, Mtrica v.3 establece una serie de actividades, que se describen el
la figura 3.2, para alcanzar un objetivo claro que es "la obtencin de un marco
de referencia para el desarrollo de sistemas de informacin que responda a los
objetivos estratgicos de la organizacin .
Este alineamiento de los Sistemas de Informacin con la estrategia de la
organizacin donde se implica directamente la alta direccin en la propuesta de
solucin va a presentar una serie de ventajas, como son:
Se crear una perspectiva ms horizontal de los procesos dentro de la
Organizacin donde los interesen generales tendrn una mayor
importancia en contra de cada uno de los intereses particulares que
podran desvirtuar los objetivos estratgicos y que obligar a un estudio
minucioso de los procesos.
La implicacin de alta direccin permitir disponer de los recursos
suficientes que permitir ofrecer resultados dentro del calendario
acordado.
La prioridad de los procesos se ver fortalecida por el apoyo de todos
los miembros participantes dentro de las lneas establecidas en el Plan
Estratgico
Con las ideas anteriores podemos lanzarnos a tratar de efectuar un primer
esbozo de lo que ser el proyecto, al menos en sus lmites, para poder efectuar
un clculo inicial del esfuerzo necesario para poder desarrollar eficientemente
el proyecto. De esta forma nos encontramos en disposicin de introducir el
trmino de Planificacin del Proyecto entendida como la ciencia que suministra
un escenario al director para poder efectuar estimaciones razonadas de los
recursos, poder efectuar un presupuesto de costes, obtener visibilidad para
determinar los mtodos necesarios a utilizar para terminar el proyecto y, en
resumen, poder disponer de todo lo anterior para realizar el proyecto con un
mximo de eficiencia.
C A P T U L O 3: F A C T O R E S D E D IM E N S I N 43
Hemos sealado en el captulo anterior la necesidad de poner lmites al
proyecto y, en particular, tenemos que delimitar el mbito del software en el
sentido de marcar claramente lo que se quiere que efecte el nuevo sistema y lo
que no se desea mecanizar en el proyecto actual ya que muchos proyectos 110 se
terminan, o se terminan fuera de plazo, por 110 saber cunto falta para que se
termine de desarrollar. E11 este sentido tenemos que manifestar que el proyecto
termina cuando se ven satisfechos todos y cada uno de los requisitos (software
o de cualquier otra ndole) del sistema.
Para efectuar la planificacin del proyecto se debera disponer de una serie
de datos cualitativos y cuantitativos en forma de requisitos (tiempo mximo de
transaccin, nmero de usuarios mximos, interfases grficas...) que
desgraciadamente no se conocern hasta una vez avanzada la planificacin, y
sin embargo, dentro de nuestra disciplina, tendremos que efectuar ms de
alguna planificacin tentativa antes de conocer el proyecto con a un nivel de
detalle suficiente. Tendremos que aventurarnos efectuando algunos tipos de
consideraciones sobre el tipo de proyecto que se quiere realizar y, en muchos
casos, fundamentalmente en fases tempranas de la planificacin, tendremos
que efectuar ensayos de distinto tipo de actuaciones para acometerlo.
Con el documento de requisitos (ms o menos detallado) y con la lista de
objetivos, as como con un posible calendario forzado, el director podr
estimar, en una primera fase, el esfuerzo a desarrollar en cada etapa. Con
posterioridad podr obtener una especificacin de los recursos que sern
necesarios para acometer el proyecto.
3.3 CATEGORAS DE PROYECTOS DE INGENIERA DEL
SOFTWARE SEGN SUS DIMENSIONES.
Antes de continuar con la especificacin de recursos vamos a ensayar una
clasificacin de los proyectos de ingeniera del software segn su dimensin.
Para ello vamos a considerar las necesidades de recursos segn el tipo de
problema a resolver.
Decamos, cuando habbamos del tringulo del proyecto, que las
dimensiones de todo proyecto son calendario, coste y cantidad de producto. La
dimensin del proyecto puede determinarse dentro de las variables de
complejidad, de riesgo, de calidad y de tamao, como veremos a continuacin.
44 P L A N IF IC A C I N Y G EST I N D E S IS T E M A S IN F O R M T IC O S
El factor complejidad puede ser tratado, a su vez, desde varios puntos de
vista: Por una parte podemos hablar de la complejidad de datos, de mtricas,
algortmica o de operaciones, ciclomtica y de la arquitectura en s. La
complejidad de datos normalmente expresa la dificultad, o sencillez, de un
determinado mdulo que se mide en funcin de los datos de entrada y de los
salida. En general la complejidad de los datos no se considera en el momento
de efectuar una clasificacin de los proyectos por categoras. Lo mismo ocurre
con la complejidad algortmica y la ciclomtica que trata de ver la complejidad
de la lgica de uno o varios programas. Otro caso es la complejidad de la
arquitectura del sistema y las relaciones de dependencia que se pretendan
establecer1 que definen un cierto acoplamiento que es importante a la hora de
valorar los proyectos.
La dimensin del producto visto desde la perspectiva del factor riesgo trata
de clasificar los proyectos segn la probabilidad de impacto en el negocio y las
consecuencias que de cumplirse el impacto se derivaran del sistema de
informacin que se desea crear frente a la organizacin. Considerar los riesgos
dentro de la fase de ejecucin del proyecto es muy importante ya que, de
satisfacerse el riesgo, posiblemente toda la planificacin del proyecto se vera
afectada por el propio impacto de una serie de amenazas en los puntos ms
vulnerables.
El factor calidad puede clasificar los proyectos segn el resultado en
cuanto al buen funcionamiento en el tiempo del sistema de informacin creado.
As no es lo mismo los requisitos de calidad que se establecen en la
construccin de un software comercial como en el software que gobierna una
planta nuclear donde, por ejemplo, un mal funcionamiento de algn
componente puede acarrear problemas de salud a los individuos. Normalmente
las mximas exigencias de calidad se demandan en software empotrado en
ciertos equipos electrnicos que, en caso de funcionamiento errneo o
indisponibilidad, pueden traer como consecuencia, la prdida de vidas
humanas.
La dimensin tamao es la mejor pauta para clasificar los distintos tipo de
proyectos dentro de una empresa que normalmente efecta trabajos ms o
menos parecidos dentro de las mismas prcticas ingenieriles. De esta forma es
posible hablar de proyectos grandes, medianos o pequeos, en funcin del
nmero o cantidad de funcionalidades previstas, del nmero de lneas de
programa fuente a producir, del tiempo de desarrollo y, en general, de la
cantidad de esfuerzo a invertir en el proyecto. Es de sealar que esta
1 Zhao J. On assessing the Complexity o f Software Architectures, Proccedings o f Lnteligent
Software Archileclure, ACM, pp. 163-167, Orlando, Florida, 1998.
C A P T U L O 3: F A C T O R E S D E D IM E N S I N 45
caracterstica suele ser con la que ms frecuentemente se clasifican los
proyectos a la vez que anticipamos que a mayores proyectos en tamao ms
probabilidad de no cumplir los plazos de entrega del proyecto.
3.4 DISTRIBUCIN DEL TIEMPO A LO LARGO DEL CICLO DE
VIDA DE UN SISTEMA INFORMTICO.
En los proyectos informticos se da el hecho de que la cantidad de recursos
puestos a disposicin del director no es constante a lo largo del tiempo. Suele
ser normal que las primeras fases de tanteos de bsqueda de solucin,
presupuestos iniciales no definitivos y valoracin del alcance, lo realice un
nmero muy reducido de personas. El objetivo fundamental de este reducido
equipo de personas ser tratar de fijar el proyecto y establecer, dentro de lo
posible, las lneas bsicas de actuacin. Como objetivos secundarios se
intentar recoger toda la informacin del cliente tratando de alcanzar las lneas
generales de sus necesidades para dar cumplimiento de ciertas consideraciones
comerciales entre las que se encuentra elaboracin de la posible oferta
econmica de servicios, las reglas que detallen la forma de facturar y se
ensayar, igualmente, a establecer los criterios de terminacin. En esta fase se
suele exigir, por parte del contratista, que se establezcan ciertos patrones de
calidad, de seguimiento y de seguimiento del proyecto a fin de garantizar el
perfecto desarrollo del mismo dentro de los patrones de seguridad de la
empresa.
En esta fase de conocimiento de las necesidades del cliente suelen tener
una importancia muy alta las gestiones comerciales y los acuerdos tcitos que
se alcancen. Es normal que se establezcan penalizaciones en caso de no
cumplimiento de alguna de las partes y que se contemplen todas las
especificaciones del contratista y se describa un primer documento con la
especificacin del producto haciendo un buen desglose del proyecto.
Una vez que el proyecto avanza y se cuenta con la aprobacin del cliente
trataremos de adecuar los objetivos estratgicos de la organizacin y la
informacin necesaria para soportar esos objetivos. El proceso anterior puede
ser un punto de partida para la Metodologa de Desarrollo de Sistemas. Con
esta informacin se intuye una posible luz de salida, se incorporar ms
gente a realizar labores de anlisis, que an constituir un grupo pequeo de
personas, cuyo espacio en el tiempo puede dilatarse pero que no supone el total
de las fuerzas del equipo del proyecto.
46 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
La duracin de esta fase es bastante ms medible que la anterior. El
director ya 110 tiene que someterse a un nmero alto de variables cuya respuesta
est en manos del cliente y, estudios realizados demuestran que los recursos
trabajan en el proyecto con ms continuidad.
En la fase de diseo arquitectnico el grupo es ms numeroso, aunque
todava es pequeo comparado con el personal que interviene en el diseo
detallado. Posteriormente se incorpora un nmero alto de personas y el
proyecto trabaja con un mximo de recursos que poco a poco se irn
reduciendo hasta la puesta en marcha del sistema y el posterior mantenimiento.
Es de sealar que la etapa inicial de mantenimiento puede requerir un
nmero elevado de personal, aunque este nmero deber disminuir en poco
tiempo, si no existen mejoras o adaptaciones importantes, permaneciendo
constante con tendencia a la disminucin a partir de un cierto momento.
Como se ver en el captulo noveno la distribucin de esfuerzos frente al
tiempo en el desarrollo de sistemas informticos sigue el modelo de la funcin
de Rayleight representada en la figura 3.2.
3.5 ESTIM ACIN DE RECURSOS
Una vez fijado el calendario y la cantidad de producto a desarrollar, y habiendo
efectuado un estudio sobre la viabilidad del proyecto, tenemos que fijarnos en
la estimacin de los recursos necesarios para poder efectuar el proyecto.
C A P T U L O 3: F A C T O R E S D E D IM E N S I N 47
Dentro de los recursos nos encontramos con dos tipos fundamentales de
recursos:
Recursos humanos
Recursos materiales
Dentro de los recursos humanos, nos ocupamos de las personas que
trabajan para nuestra organizacin y de la que necesitaremos tener informacin
sobre su formacin, su capacidad y su actitud frente al proyecto para poder
determinar el tipo de tareas que se les puede asignar de forma individual y
colectiva. Esta informacin se puede organizar en forma de fichas,
mecanizadas o no, sobre las que se tengan datos de la persona en s misma, de
su disponibilidad tanto general como particular para el proyecto, lo que llevara
a poder informar de las distintas fechas en las que se le requiere cada recurso
para cada proyecto concreto o, en su caso, la duracin a partir de cada fecha de
comienzo.
Existen muchos factores que inciden en los recursos humanos como
pueden ser la motivacin, la especializacin y entrenamiento, los posibles
calendarios y la normativa laboral vigente en cada entorno concreto que puede
establecer unas limitaciones que el director debe de conocer en cada momento.
As, las fiestas laborales locales o autonmicas se deben de considerar en la
planificacin de reuniones o en las cargas de trabajo de cada uno de los
individuos que forman el equipo del proyecto. Igualmente puede suceder con
las restricciones debidas a la indisponibilidad de los recursos por bajas
temporales, enfermedades o cualquier tipo de discontinuidad en el trabajo, lo
que nos forzar a considerar los tiempos perdidos por este tipo de situaciones.
Un factor importante en las restricciones de la planificacin puede deberse
a la existencia de diversas categoras laborales que obligarn, de hecho, a que
cada una de las personas del equipo de trabajo quiera desarrollar la tarea propia
de su categora, en algunas ocasiones sin ningn tipo de flexibilidad.
Cada da se tiene mayor conciencia de la independencia de algunos
recursos humanos para satisfacer las necesidades de implementacin de
soluciones y se considera la conveniencia de utilizar recursos propios o
recursos ajenos, sobre todo en algunos proyectos que, por su naturaleza, exijan
una mayor cantidad de personas durante plazos relativamente cortos de trabajo
con las ventajas que supone el hecho de contratarlos como miembros de otra
empresa.
48 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M A T IC O S C A P T U L O 3: F A C T O R E S D E D IM E N S I N 49

Entre los recursos materiales deberemos de considerar, fundamentalmente
el entorno de desarrollo y el ordenador objetivo que, con sus particularidades
de sistema operativo y bases de datos, puede no tener la misma configuracin
que las herramientas del banco de trabajo" donde se desarrolla el sistema de
informacin. En otros casos se consideran recursos algunos elementos
hardware que se integrar dentro del proyecto pero que su disponibilidad, por
diversas causas, no es inmediata.
Dentro de las posibilidades de utilizacin de algunos recursos que no
disponemos est la de alquilar horas de recurso material (normalmente
hardware) en alguna instalacin similar a la de la organizacin cliente donde,
de forma programada, se puedan probar los mdulos que se estn construyendo
y donde se pueda verificar el avance del proyecto.
Una importancia extraordinaria en la construccin de sistemas de
informacin modernos tienen las herramientas software con las que
construimos el nuevo sistema que, posiblemente, a lo largo de la fase de
construccin del sistema tengan que ser sustituidas por otras herramientas
futuras, lo que nos llevar a estimar esfuerzos de conversin y de formacin en
las nuevas versiones de software de base.
En general el proyecto se puede gobernar cuando existe informacin
compartida del mismo, de tal modo que todo el equipo, segn su
responsabilidad, tenga conocimiento de las tareas programadas y del estado de
las tareas realizadas, para lo cual son muy tiles los mtodos tcnicos que en
forma de normas y procedimientos, marcan la ruta a seguir en el avance del
mismo.
En los captulos ocho y diez volveremos sobre el uso de los recursos y la
estimacin de los costes con mtodos estadsticos; haremos estimacin de los
costes en funcin del tipo de recurso, la cantidad de recursos, de la duracin de
la actividad, todo ello con tcnicas de estudio fijando los escenarios ms
probables, ms pesimistas y ms optimistas. Todo ello, junto con el tratamiento
de los costes directos: precio, cantidad, eficiencia, duracin de la tarea,
oportunidad del momento, etc.., nos llevar a la asignacin al proyecto.

Otro punto interesante a la hora de asignar los recursos es la disponibilidad

de los mismos:

Los recursos son escasos

Los recursos no siempre estn disponibles
A veces no se puede conseguir un recurso a cualquier precio

Muchas veces la duracin ptima de la tarea, o su eficiencia, no depende

del nmero de recursos empleados como veremos en el captulo noveno. En
ese captulo estudiaremos que existe una relacin entre coste y duracin de
cada actividad y se ver que hay un nmero de elementos a dedicar en cada
fase del proyecto de forma que se optimice el binomio tiempo, coste.

El proyecto suele ser muy vulnerable ante una multitud de amenazas que
pueden hacer peligrar el desarrollo del mismo. En el caso de que una amenaza
impacte en una vulnerabilidad del proyecto tendramos una probabilidad de
riesgo en el proyecto por lo que el director tendr que considerar planes de
solucionar contingencias ante la ausencia repentina de recursos tratando de
que el tiempo se convierta en un recurso.
 (

<
50 PL A N IFIC A C I N Y G ESTI N DE SISTEM A S INFORMTICOS
(

CAPTULO 4

FACTORES DE PRODUCTIVIDAD

El objetivo fundamental de la presente unidad temtica es estudiar el conjunto

de mtricas que se utilizan habitualmente en cualquier disciplina de ingeniera (
y que, por tanto, en la planificacin de proyectos informticos deben de '
utilizarse. En particular nos ocuparemos de las mtricas de productividad como .
medidas del rendimiento de la construccin de software en funcin del
esfuerzo aplicado y estudiaremos cmo se puede mejoran la productividad en
base al empleo de herramientas que nos ayuden en la automatizacin de tareas.
<

Antes de continuar listaremos la tabla los factores que afectan a la

productividad en un proyecto informtico y que tendrn que tenerse en cuenta a /
la hora de disear mtricas y herramientas: ^

Factores humanos. Experiencia y tamao del equipo de desarrollo.

Factores del problema. Complejidad del sistema y cambios de
requisitos durante el desarrollo. ^
Factores del proceso. Tcnicas utilizadas (anlisis y diseo) y gestin. (
Factores del producto. Rendimiento y fiabilidad del sistema.
Factores de los recursos. Disponibilidad de recursos HW , SW para el (
desarrollo (

4.1 METRICAS DE PRODUCTIVIDAD DEL SOFTWARE. '

La medida es fundamental para cualquier actividad. Lord Kelvin dijo: "Cuando

puedes medir lo que estas diciendo , y expresarlo en nmeros , sabes algo sobre
ello; pero citando no puedes medirlo, cuando no puedes expresarlo con
nmeros, tu conocimiento es escaso e insatisfactorio: puede ser el principio del
conocimiento, pero en tus pensamientos, apenas ests avanzando hacia el '
escenario de la ciencia. Durante la dcada pasada se ha tomado al pie de la *
( ;

(
52 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M A T IC O S
letra esta afirmacin de Lord Kelvin pero lia trado algunos desencantos que
han suscitado una gran polmica.
Pero cuando tratamos de realizar un nuevo proyecto, normalmente
irrepetible, no valen de mucho los mtodos empricos sino ms bien el
conocimiento histrico. Preguntas del tipo Cmo se ha comportado mi equipo
de desarrollo en anteriores proyectos? Los datos anteriores cmo pueden ser
extrapolados ahora?
En la exposicin de la presente leccin se har una presentacin de las
distintas mtricas del software para entender en que puntos se ajustan mejor las
medidas de productividad. Pero debemos de considerar las razones la medida
del software: El software se mide para:
Indicar la cantidad de producto
Evaluar la productividad de la gente que desarrolla ese producto
Aseguramos los beneficios derivados de nuevos mtodos
Justificar la adecuacin de nuevas herramientas
Por ello se estudiarn las distintas mtricas del software y se catalogarn,
como en el mundo de la ingeniera, en dos grandes categoras: las medidas
directas (por ejemplo: la longitud de un programa en sentencias fuente) y las
medidas indirectas (por ejemplo: la calidad de tal programa fuente), las
medidas directas son fciles de obtener, al fin y al cabo es establecer un
convenio que ayude a identificar el "metro" a utilizar, pero las medidas
indirectas como la calidad, eficiencia y mantenibilidad son ms difciles de
obtener.
Dentro de nuestro mundo, y para asegurar el correcto empleo de los
trminos, se pueden clasificar las distintas mtricas en:
Mtricas orientadas al tamao
Mtricas orientadas a la funcin
Mtricas orientadas a la persona
La implantacin de mtricas genera beneficios para la empresa. Estos
beneficios pueden ser en la reduccin de costes, en la mejora de la
productividad, el incremento de las ventas motivada por la reduccin de los
ciclos de desarrollo. Tambin se obtienen beneficios derivados de la
satisfaccin del cliente que se sentir recompensado por un software de calidad
y que recomendar al equipo de desarrollo a otros colegas.
C A P T U L O 4: F A C T O R E S D E P R O D U C T IV ID A D 53
Frente a los objetivos del negocio podemos asegurar que la iniciacin de
programas de mtricas del software, proveer la asistencia de asegurar,
monitorizar e identificar acciones de mejora para alcanzar un conjunto de
objetivos de calidad y productividad de la compaa.
El programa de mtricas, a su vez, camina muy relacionado con el proceso
de desarrollo ya que las mtricas se definen para medir caractersticas
cuantitativas de rendimiento en determinados puntos del proceso.
Es importante considerar que el proceso de implantacin de mtricas
deber ser realimentado de tal suerte que los datos obtenidos de la medida
provean una gua para mejorar la identificacin de acciones a mejorar en el
proceso de desarrollo de sistemas de informacin1.
4.2 HERRAMIENTAS QUE MEJORAN LA PRODUCTIVIDAD.
La mayor parte de los conocimientos sobre el funcionamiento de una empresa,
y sobre la influencia de la informacin sobre ese funcionamiento, reside en la
mente de un nmero relativamente reducido de personas. Para intentar
conservar y explotar este conocimiento, a lo largo del tiempo, las
organizaciones han dedicado esfuerzos en construir modelos donde poder
efectuar un tratamiento documental de esa rica informacin. El objetivo de este
tipo de modelos es poder representar, en muchos casos de forma simblica, los
conocimientos de esas personas clave con la esperanza de que todo el personal
que interviene en los distintos procesos de negocio pueda usar, de una forma
fcil y completa, los conocimientos acumulados por esas personas.
A lo largo del tiempo se han concebido diversas metodologas para
construir estos modelos. Esas metodologas suelen consistir en una
combinacin de tcnicas de diagramas y textos explicativos. Los diagramas
representan visualmente las actividades comerciales y el uso que se hace de la
informacin en apoyo de las mismas. Los diagramas tambin describen
grficamente los atributos empleados en el diseo y desarrollo de sistemas.
Las tcnicas de diagramas emplean iconos para representar los distintos
componentes de las actividades empresariales: personal, recursos, datos, etc.
Cada icono de los diagramas suele llevar asociado un texto explicativo de su
1 Un buen libro para ampliar esta informacin es el de K.H. Mller y D.J. Paulish, Software
Metrics. A Practioners Guete to im proved Product D evelopm enl, IEEE Press, Chaptnan &
Hall, 1993.
54 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
propsito, su funcin en el marco de las actividades comerciales, su respaldo
informtico y su relacin con otros iconos. El texto explicativo contiene
informacin suficiente para deducir las caractersticas fundamentales del objeto
real representado por el icono.
Las metodologas de modelizacin permiten encauzar la elaboracin de
modelos representativos de las actividades empresariales y el desarrollo de
sistemas. Sin embargo, los modelos comerciales exigen frecuentemente
modificaciones como resultado de la evolucin del negocio. Si los modelos se
construyen a mano, esos cambios requieren considerables esfuerzos; en
consecuencia, los modelos trabajosamente elaborados a mano se vuelven
pronto obsoletos. Por otra parte, si se invierten grandes esfuerzos en la
construccin de un modelo manual, se tiende a no invertir ms trabajo en todo
lo que suponga modificarlo. La modelizacin representa simblicamente las
distintas facetas del negocio con vistas a su estudio y subsiguiente mejora,
antes de comprometerse formalmente en la elaboracin del modelo. El cambio,
por tanto, es inherente al modelado, de ah que haya que facilitarlo al mximo.
4.3 LOS CASE.
En la actualidad ya no se concibe el desarrollo de Sistemas de Informacin sin
utilizar herramientas de ayuda para automatizar gran parte de las tareas del
ciclo de vida. Esto ha dado lugar al nacimiento de la Ingeniera del software
Asistida por Ordenador o tecnologa C ASE (Computer Aided Software
Engineering), que consiste en una combinacin de metodologa de desarrollo
de sistemas (UML, OMT, SSADM, METRICA,...) y herramientas orientadas a
facilitar dicho desarrollo basado en esas metodologas concretas (Rational
Rose, Predict CASE, Excelerator, Designer 2000..).
La tecnologa CASE utiliza el ordenador como herramienta tanto para el
establecimiento de modelos descriptivos de las empresas que se van a
automatizar como para documentar el desarrollo de los Sistemas Informticos
implicados, desde el momento de su planificacin hasta su implantacin final.
En este sentido, dicha tecnologa permite resolver el conflicto existente entre el
dinamismo de la actividad empresarial y la dificultad que entraa el desarrollo
de nuevos Sistemas Informticos que se adapten a tal dinamismo.
La tecnologa CASE reemplaza el papel y el lpiz por el ordenador para
hacer del desarrollo del software un proceso ms productivo. El objetivo
fundamental de la CASE es proporcionar un conjunto de herramientas que
C A P T U L O 4: F A C T O R E S D li P R O D U C T IV ID A D 55
automaticen los trabajos de desarrollo y mantenimiento del software. Aunque
de esta forma se facilita la implantacin de soluciones, su principal aportacin
se refiere a las mejoras en la productividad y calidad en todos los aspectos del
desarrollo, abarcando todas las fases del ciclo de vida, permitiendo la
aplicacin real de las tcnicas recomendadas por la metodologa utilizada; algo
que de forma manual sera muy difcil de llevarse a cabo debido a la gran
cantidad de informacin, esquemas y documentacin que se debe generar.
Se han desarrollado herramientas CASE que automatizan muchas de las
metodologa conocidas empleadas para el modelado. Esas herramientas aplican
muchos de los principios de la CASE desde el momento en que aportan
tcnicas de diagramas acompaadas de textos explicativos. Muchos sistemas
CASE funcionan en ordenadores personales, requirindose un ratn para
manejar los de mayor orientacin grfica. Los mandatos se introducen
mediante mens o teclas de funcin estando reservada parte de la pantalla para
introducir la especificacin oportuna de los modelos.
Dentro de las metodologa ms grficas automatizadas a travs de los
sistemas CASE, algunos iconos cumplen varias funciones. El texto que
aparece tras los iconos explica que simbolizan estos en el marco de la faceta
comercial en fase de modelado.
Estos textos explicativos se introducen en la parte del sistema CASE
conocida como "diccionario" (algunos sistema CASE poseen gestores de bases
de datos incorporados que realizan esta funcin). El diccionario contiene
pantallas preformateadas asociadas a los distintos iconos, pantallas que
suministran una informacin muy valiosa acerca de los aspectos del negocio
simbolizados por los iconos. El diccionario contiene adems un directorio que
muestra las relaciones existentes entre determinados diagramas, iconos y textos
explicativos.
La mayora de las organizaciones se enfrentan a una crisis del software y
tienen, generalmente, una gran cantidad de proyectos esperando a ser
desarrollados. Es necesario, por tanto, resolver este grave problema,
obteniendo sistemas de mejor calidad y en menor tiempo.
Una importante parte del xito de la implantacin de la CASE es
determinar lo qu se debe hacer y cmo para resolver el problema planteado
dentro de la organizacin. Debido a que cada organizacin vive el problema
desde un punto de vista distinto, se deben determinar con detalle las
necesidades y las prioridades de la misma que se deben cubrir.
56 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
4.4 PRODUCTIVIDAD SEGN EL CICLO DE VIDA.
La utilizacin de un tipo u otro de ciclo de vida en un proyecto informtico
puede aumentar o disminuir considerablemente la productividad del proyecto.
Aunque la necesidad de un modelo de desarrollo o ciclo de vida hace tiempo
que est firmemente establecida todava hay muchos proyectos que no aplican
ningn modelo o utilizan modelos no adecuados. La eleccin del ciclo de vida
a utilizar es una tarea en la que hay que tener en cuenta factores del proceso,
del producto y del problema. La utilizacin de un ciclo de vida u otro nos
determina:
Las fases productivas de un proyecto.
Los objetivos de cada fase productiva.
Los productos obtenidos en cada una de estas fases as como sus
caractersticas.
Se han propuesto muchos ciclos de vida para el desarrollo del software,
pero estos son los ms representativos:
Aproximacin en cascada. Tcnica rgida, su filosofa es completar un
paso con un alto grado de exactitud, antes de empezar el siguiente.
Adecuado para el desarrollo de sistemas con especificaciones muy
elaboradas desde el principio. Los proyectos raras veces siguen el
modelo secuencial que se supone, pero si es aplicable a un proyecto, su
planificacin y su gestin son mucho ms fciles y no suele haber
desviaciones. En general presenta desventajas como:
o La versin operativa de los programas no est disponible hasta
que el proyecto est muy avanzado,
o No contempla iteraciones y paralelismos potenciales entre las
fases. Algunos integrantes del equipo han de esperar a otros
para completar tareas pendientes,
o Un error importante puede ser desastroso, si se descubre al final
del proceso.
o En muchas ocasiones no es posible disponer de unas
especificaciones correctas desde el primer momento, porque
puede ser difcil para el usuario establecer al inicio todos los
requisitos.
_________ C A P IT U L O 4 F A C T O R E S DI- P R O D U C T IV ID A D 57
Aproximacin por prototipo. Es habitual que en un proyecto software
no se identifiquen inicialmente los requisitos detallados de entrada,
procesamiento o salida. En casos as, lo habitual es construir un
prototipo. Esta aproximacin se enfoca a mejorar la efectividad del
proceso de desarrollo y 110 a mejorar la eficacia de ese proceso, ya que
la plena definicin del usuario es un proceso muy lento y al terminarlo
es cuando se empieza a desarrollar el producto (el prototipo no suele ser
reutilizable). Este enfoque es apropiado cuando:
o El cliente no tiene claro lo que quiere.
o Al cliente le gustara ver algo similar para poder hacerse una
idea de lo que obtendr.
Existen dos clases de prototipos:
o De INTERFACE. Usualmente un modelo de papel o sobre PC
en el que se muestran pantallas y listados.
o De COMPORTAMIENTO: Es posible ofrecer todos los mens
del sistema y simular dbilmente los procesos o cubrir funciones
que presentan ambigedades al cliente o a los informticos.
Aproximacin evolutiva. Similar a la de prototipos, intenta un sistema
flexible con una gran capacidad de expansin de tal forma que se van
obteniendo versiones del prototipo cada vez ms parecidas al sistema
final. El prototipo no se desecha, incluso los requisitos de fiabilidad y
rendimiento se implementan desde el principio. Mientras que en la
aproximacin por prototipos se asume que existe una serie de requisitos
que no estn claros para disear el prototipo, esta aproximacin se
disea en base a los requisitos que estn claros y se pretende descubrir*
los dems. Cada vez se desarrolla una nueva versin de todo el sistema.
Aproximacin incremental. Se comienza el desarrollo para satisfacer
una parte de los requisitos especificados. Se van aadiendo mas
requisitos en futuras versiones. Se logra una pronta disponibilidad
parcial del producto que, si bien es incompleto, puede ser utilizable y
satisfacer algunas necesidades de informacin. Se desarrolla cada vez
un nuevo sistema sin modificar el anterior aadiendo nuevas funciones.
Tiene una desventaja importante: los errores en los requisitos (o errores
de anlisis), si aparecen tarde, son graves, es decir, son difciles de
corregir.
58 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Aproximacin en espiral. Esta aproximacin, formalizada por Boehm
en 1985, nace para recoger lo mejor de la aproximacin convencional y
de la de prototipo aadindole el componente de anlisis de riesgo. Es
importante determinar en la fase inicial el nivel de riesgo que existe. Si
como consecuencia del anlisis de riesgo se observa que hay
incertidumbre sobre el problema entonces en la actividad de ingeniera
se aplicar la aproximacin prototipo cuyo beneficio es el de reducir la
incertidumbre. Un proyecto que utilice este ciclo de vida tendr una
estructura similar a la que muestra la figura 4.1.
Planificacin , Anlisis riesgos
F ig u ra 4.1 E vo lu ci n de un p ro y e c to u tiliza n d o un ciclo d e vid a en esp ira l
Aproximacin basada en transformaciones. Con la aparicin de las
herramientas CASE junto con los generadores de cdigo, el ciclo de
desarrollo software en cascada ha cambiado a un ciclo de vida basado
en transformaciones. La utilizacin de herramientas CASE afecta a
todas las fases del ciclo de vida del software. Este ciclo de vida se
puede considerar como una serie de transformaciones. Primero se
definen los requisitos del sistema, seguidamente existe un proceso de
transformacin que hace que la especificacin se convierta en un diseo
lgico del sistema. Posteriormente, este sufre otro proceso de
transformacin para lograr un diseo fsico, es decir que responda a la
tecnologa destino. Tiene una gran ventaja: la posibilidad de
comprobacin de errores en etapas iniciales del desarrollo junto con el
soporte de rastreabilidad de requisitos y de reusabilidad.
C A P T U L O 1: F A C T O R E S D E P R O D U C T IV ID A D 59
4.5 DISPONIBILIDAD DE RECURSOS.
Es importante considerar la disponibilidad de recursos. Los recursos no
siempre estn disponibles y, a veces, no se pueden conseguir nuevos recursos
en un intervalo prefijado de costes, estas consideraciones se desarrollarn a
continuacin para el perfecto entendimiento de este tipo de limitaciones.
Tambin es importante en la planificacin del proyecto, considerar, para
llegar mejor a la consecucin de los fines, la valoracin y experiencia del
equipo de desarrollo. Entre los principales problemas planteados por la crisis
del software, ninguno es ms inquietante que la relativa escasez de recursos
humanos capaces para desarrollar software con las nuevas herramientas que
surgen cada da y que mejoran la productividad dentro de las limitaciones del
presupuesto. Es relativamente fcil obtener buenos codificadores de algoritmos
concretos que pueden desarrollar pequeos sistemas completos, pero es difcil
encontrar un equipo de desarrollo que conozca las tcnicas de comunicacin a
fin de poder ser coordinado con otras personas para el desarrollo de tareas no
repetitivas.
Otro problema consiste en la asignacin efectiva de tareas a los recursos
mejor especializados. En un equipo de desarrollo de software es normal
encontrarse con afirmaciones como la siguiente: Fulanito hace mejor las
pantallas..., sin embargo la pericia del director deber saber asignar a cada
miembro del equipo las misiones que mejor cumplan los objetivos del
proyecto, y un objetivo del proyecto puede ser realizado con la incorporacin
de las habilidades concretas de cada miembro del equipo.
4.6 LA EXPERIENCIA Y EL ENTRENAMIENTO DEL EQUIPO DE
DESARROLLO.
Hay que considerar las distintas figuras que aparecen en el desarrollo de un
sistema de informacin de tipo mediano-grande: el director del proyecto, los
analistas funcionales, analistas orgnicos, programadores, tcnicos de sistemas,
documentalistas para el mantenimiento de la biblioteca software, operadores,
administradores de la base de datos, tcnicos en seguridad, etc. Cada uno de
ellos tendr una participacin ms o menos activa en funcin de la evolucin
del proyecto en s.
60 P L A N IF IC A C I N Y G E S T I N D I; S IS T E M A S IN F O R M T IC O S
Aunque depende en gran medida de la envergadura, complejidad y
caractersticas del sistema a desarrollar, puede establecerse de forma general
que en todo proyecto de desarrollo de un sistema estn implicados, por una
parte, personas pertenecientes a la organizacin usuaria o promotora del
proyecto, la que utilizar el sistema cuando ste se construya y, por otra, la
organizacin de desarrollo o empresa contratista a la que la primera encarga la
realizacin de tal sistema.
Puede ocurrir, no obstante, que se trate de un desarrollo interno de la
propia organizacin usuaria, a travs de su propio departamento de proceso de
datos (o departamento de informtica). En tal caso, la organizacin de
desarrollo se correspondera precisamente con este departamento.
Aunque no suele ser habitual su presencia en la mayora de los proyectos,
puede determinarse por parte de ambas organizaciones (de usuario y de
desarrollo), la contratacin de una tercera firma, especialista en auditoria
informtica e independiente de ambas, que intervenga en aquellos casos en los
que se hayan previsto procedimientos extraordinarios de control (auditorias).
El personal perteneciente a las anteriores organizaciones que interviene en
un proyecto determinado es el siguiente:
Comit de Direccin: Est constituido por los responsables de la
organizacin usuaria o promotora del proyecto y de la organizacin u
organizaciones encargadas de su desarrollo. Al frente de este comit se
encontrar el Director del Proyecto.
Director del Proyecto: Se trata de un directivo de alto nivel, con
amplia experiencia en planificacin y gestin de Sistemas de
Informacin, nombrado por acuerdo entre las organizaciones
implicadas. Normalmente se trata un directivo de la organizacin
encargada del desarrollo del sistema.
Comit de Garanta de Calidad: Est integrado por personal, con
conocimientos y experiencia en metodologas de desarrollo, del
departamento de informtica, si existe, de la organizacin usuaria o, en
caso contrario, de una organizacin externa, independiente de la que
desarrolla el sistema. Este comit se encargar de controlar la evolucin
del proyecto a travs del anlisis de los productos generados a lo largo
de las diferentes fases de desarrollo. En el caso de pertenecer a la
organizacin usuaria, el personal encargado de este control de calidad
C A P T U L O 4: F A C T O R E S D E P R O D U C T IV ID A D 61
deber ser independiente de aquel, de la misma organizacin, que
compone el equipo de desarrollo del sistema.
Equipo de Desarrollo: Est constituido por las personas que se van a
encargar directamente del desarrollo. Pertenecern a la organizacin
contratada para desarrollar el sistema; aunque si se trata de un
desarrollo interno, los miembros del equipo pertenecern a la propia
organizacin usuaria. Normalmente, si el desarrollo es externo
(empresa contratista) y la organizacin usuaria dispone de
Departamento de Informtica, algunas personas de tal departamento
pueden considerarse tambin del equipo, participando, por tanto, en el
desarrollo.
Al frente del Equipo de Desarrollo se sita el Jefe del Proyecto,
persona con amplios conocimientos informticos y experiencia en el
desarrollo de este tipo de sistemas. El resto de personal implicados en el
desarrollo sern:
Analistas: Personal con conocimiento de la metodologa de desarrollo a
utilizar y de las herramientas que permiten automatizar este desarrollo.
Se encarga del estudio de los requisitos, objetivos y funciones a realizar
por el sistema, documentando todos estos aspectos segn la
metodologa establecida.
Diseadores: Suele tratarse del propio analista anterior. Se encarga de
establecer la estructura del software y de los datos que constituyen el
sistema.
Programadores: Codificarn, mediante un lenguaje de programacin
concreto, los componentes software establecidos por los diseadores.
Tcnicos de Sistemas: Personal experto en software de base (sistemas
operativos, software de red,..) y equipos informticos, que ofrece apoyo
tcnico a lo largo del desarrollo.
Personal del Area de Explotacin: Se trata de personas del
departamento de informtica o proceso de datos de la organizacin
usuaria, con conocimientos sobre el entorno en el que se explotar el
sistema cuando se instale. Estas personas colaborarn con el equipo de
desarrollo, para concretar determinados aspectos relacionados
principalmente con la definicin del entorno tecnolgico del sistema
(equipos, software de base,..) y con la construccin de la base de datos
62 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S

que, con toda seguridad, utilizar el sistema. En este ltimo caso,

conviene destacar la conveniencia de la existencia de un Administrador
de tal Base de Datos, que ser una persona del rea de explotacin
experta en esta labor y que se responsabilizar de la seguridad,
confidencialidad y ajustes de dicha base de datos, mediante parmetros
extemos para asegurar el ptimo rendimiento, cuando el sistema CAPTULO 5
funcione en explotacin.
ASPECTOS GERENCIALES
Personal del Area de Usuario Final: Se trata de aquellas personas que
utilizarn el sistema normalmente, a las que habr que recurrir para
determinar con detalle las funciones que debe realizar el sistema.
En este captulo se realiza una visin de la situacin del director de proyecto
Personal del rea del Comit de Calidad: Formado por personas cuya dentro de la empresa en la cual presta sus servicios. Deber aprender el cmo y
misin ser someter el sistema a todo tipo de pruebas para garantizar el por qu de efectuar presupuestos, controlar los gastos y preparar informacin
que se han realizado todo tipo de controles y, por lo tanto, el producto estratgica para que la gerencia pueda tomar decisiones. Igualmente conocer
obtenido tiene la calidad deseada. Estos equipos de testeadores los criterios generales de la organizacin, el concepto de cultura de empresa y
normalmente se utilizarn, posteriormente, como formadores o los cambios a los que indiscutiblemente est sometida. Finalmente, se hace
consultores del producto final. hincapi, en comprender la necesidad de ajustar los sistemas de informacin a
esos cambios como mtodo organizativo de ser competitivos.

5.1 EL A N L ISIS PR EV IO Y EL C O N T R O L DE L A IN V ER SI N .

A la hora de enfrentarse con la decisin de realizar un proyecto nos

encontramos con el problema de la inversin, con el conveniente estudio de
viabilidad y otro anlisis de la rentabilidad del proyecto. En otras palabras: se
debe de considerar si las ideas del promotor del proyecto son viables, es decir,
si se puede alcanzar ese futuro deseable para la organizacin en un entorno
aceptable y con unas condiciones econmicas aceptables.

Los estudios de viabilidad1 suelen englobar todos los aspectos que se

consideren necesarios para que la alta direccin pueda tomar sus decisiones en
un ambiente de relativa seguridad dentro de la subjetividad profesional de los
promotores. En general, en el documento de Anlisis de la Viabilidad se
incluirn datos de:

Parte importante de este tema es que el lector adquiera una visin clara de la situacin del
director de proyecto dentro de la empresa en la cual presta sus servicios. Deber aprender el
cmo y el por qu de efectuar presupuestos, controlar los gastos y preparar informacin estra
tgica para que la gerencia pueda tomar decisiones.
64 P L A N IF IC A C I N Y G E S T I N D B S IS T E M A S IN F O R M T I C O S C A P T U L O 5. A S P E C T O S G E R E N C IA L B S 65

Estudios tcnicos sobre el estado del arte de la materia a proyectar Normalmente la inversin se realiza en trminos de capital entendido como
Estudios economtricos y comerciales sobre el universo en el que se un conjunto de derechos de propiedad que se pueden cambiar (invertir) por
implante, o comercialice, el producto a obtener otras propiedades: en nuestro caso se cambia dinero por un bien futuro que
Estudios financieros sobre la inversin necesaria, cadencia de pagos, puede ser, por ejemplo, un sistema de control de la produccin con el que se va
costes financieros y previsiones de venta. a obtener ms beneficios.
Estudios de recuperacin de la inversin y de rentabilidad.
En general se puede considerar que toda inversin en un determinado
Estudios sobre el efecto de no realizar el proyecto
proyecto viene dado por el trinomio formado por un desembolso inicial, un
rendimiento y una duracin.
Con los estudios anteriormente citados se procede a efectuar una
valoracin, o mejor an, un proceso de valoracin entendido como un
Formalicemos estos conceptos, y otros ms que nos servirn de apoyo,
proceso formal segn el cual se asignan unas magnitudes monetarias a
utilizando la notacin estndar3:
determinados procesos o hechos econmicos con objeto de hacerlos calculables
para un determinado fin. Es necesario que existan varias formas de datar el
Capital circulante: el que necesita todo negocio para afrontar su actividad
precio de un producto o de un servicio y si bien todos sabemos que el valor de
normal despus de realizar la inversin.
un bien depende de la necesidad humana que va a satisfacer podemos
establecer, bsicamente, dos mtodos a la hora de establecer el precio. De una
V alor residual: Valor del producto cuando se decide liquidarlo.
parte se puede utilizar un criterio que sea consecuente con los procesos de
pagos y cobros, considerando ciertas implicaciones con algunas funciones de
Periodos a contem plar (/;): Es el nmero de periodos que vamos a
los sistemas de escasez o de boyanta, a este sistema se les reconoce con los
contemplar desde que se efecta la primer inversin hasta que el producto deja
criterios pagatorios, como decimos, basados en una corriente real de pagos y
de ser un bien til o cuando de decide liquidarlo a cambio de cierto valor
cobros, es decir, estudiando el coste real del bien.
residual. Suele coincidir con los periodos durante los cuales el proyecto genera
flujos de caja.
Otro criterio es utilizar un sistema de tipo calculatorio, donde no existe la
corriente anterior de pagos y cobros, pero hay consumo de bienes que, hasta
V alor Esperado M onetario (VEM) Es el sumatorio de la renta que se
que se establece un mercado en el que se equilibre la oferta y la demanda,
espera obtener en cada alternativa4 multiplicada por la probabilidad de que esa
puede funcionar con un cierto nivel inflaccionista2.
renta se produzca.
Ya hemos utilizado una serie de conceptos que, si bien no han sido
rigurosamente definidos, de alguna forma estamos familiarizados con ellos: VEM = p r o b a b i l i d a d J x rentaesperada
Memos hablado de inversin y siempre que utilizamos este trmino nos
referimos a un cierto desembolso inicial que, normalmente, es econmico.
Siempre que se realiza una inversin esperamos un cierto rendimiento Rentabilidad prevista (RP): Es el cociente entre la diferencia del Valor
conocido como rentabilidad en un cierto tiempo. Pero cuando invertimos en un Esperado Monetario menos el Coste de la Inversin dividido por el Coste de la
determinado bien, por la naturaleza finita del dinero, renunciamos, de forma Inversin:
implcita, a obtener otro bien a satisfacer en el momento actual con ese tipo de
recursos. Se renuncia a un bien actual seguro pensando en que se obtendr una
rentabilidad futura incierta, lo cual conlleva un cierto estado de riesgo que
tendr que valorarse lo ms framente posible. 3 Gotlieb utiliza estos conceptos en su obra "Economics o f Computers, The Cost, Benefits,
Policies and Strategies", Prenlice-Hall, 1985.
4 En muchos libros de texto considera periodos como forma de simplificacin de las alternati
2 Vcase el libro Direccin de Proyectos Informticos: Una gua prctica del Jefe de Proyecto; vas, nuestra consideracin es que se deben de considerar distintas alternativas como una gene
dePlam Thu Quang y Jean-Jacques Gonim. Gestin 2000, 1994. ralizacin de los periodos considerados por otros autores.
66 PLANIFICACIN Y GESTIN DE SISTEMAS INFORMTICOS CAPTULO 5: ASPECTOS GERENCIALOS 67

Rr VEM-CI Para calcular el Valor Esperado Monetario ( VEM) de cada proyecto aplicaramos la
f rm u la y diramos:
CI
VEM(l) = 72 x 0,2 + 80 x 0,7 + 93 x 0,1 = 79,7 (

VEM (2) = 45 x 0,2 + 70 x 0,7 + 87 x 0,1 = 66,7

Supuesto prctico 5.1: Una compaa se encuentra en condiciones de realizar unas mejoras
en su sistema de informacin de dientes pudiendo tomar una de las siguientes alternativas:
VEM( 3) = 57 x 0,2 + 83 x 0,7 + 113 x 0,1 = 80,8
1.-Comprar un portal de venta electrnica que le supondra un coste total de la inversin de (
47 millones de pesetas y que, por otra parte ahorrara, entre mano de obra, alquiler de locales As ventos que el proyecto con mayor valor esperado meto es el tercero, pero
e infraestructura, una cantidad estimada de 80 millones de pesetas. I
calculemos la rentabilidad prevista para cada proyecto para decidir cual de ellos es el ms
interesante::
2.- Construir un sistema de ayuda a la distribucin de mercancas para facilitar la entrega de
(
las mismas a los clientes en el mercado japons. El coste de la inversin se estima en 35 79 7 - 4 7
millones de pesetas mientras que los resultados esperados, considerando la reduccin de los RP(\) = = 0,69 (
plazos de entrega que aumentaran las ventas, es de 70 millones de pesetas. 47

3.- Crear un sistema de gestin de cobros que permita flexibilizar las entregas gracias a un i
control puntual de la bondad financiera " de los clientes. Esto se puede realizar con una
inversin de 52 millones de pesetas y, como contrapartida, se obtendran unos beneficios,
incluyendo la menor cantidad de efectos que hasta el momento resultaban ser impagados, de
83 millones de pesetas. RP( 3) = 8 0 ,8 ~ 52 = 0,55
52
La direccin cree que las previsiones se han realizado basadas en unas hiptesis de estimacin
de probabilidad 0,7, pero cree posible que, debido a coyunturas econmicas adversas, podra O bservam os, que desde el p u n to de vista de rentabilidad el proyecto m s interesante
darse el caso desfavorable de que esto no suceda as (con una probabilidad de 0,2) de tal <
es el segundo de ellos.
form a que sus resultados comerciales fueses de 72, 45 y 57 millones de pesetas
respectivamente en cada proyecto. Igualmente, y por eliminacin, cree que el escenario podra
ser m uy favorable, con probabilidad 0. i, y los resultados respectivos de las tres opciones (
podran ser de 93, 87 v 113 millones de pesetas. En cualqttier caso cree que los costes de
implementacin siempre se mantendran fijos sea cualfuese el escenario. En el caso de haber considerado que los costes de producir el bien tambin
tuvieran un valor concreto en cada escenario de probabilidad tendramos que ^
Estimar, en base a la informacin facilitada qu proyecto es el ms aconsejable segn el valor
obtener un valor resultante del coste del proyecto efectuando su media
esperado monetario y la rentabilidad prevista.
ponderada.
Construiramos, con la ayuda de una hoja de clculo, una tabla con los datos aportados por el
proyecto Continuamos definiendo otros trminos de importancia en el control de
proyectos como puede ser el periodo de recuperacin de la inversin; aspecto
Hiptesis baja Hiptesis media Hiptesis aita importante para poder abordar un nuevo proyecto, para lo cual nos apoyaremos
Probabilidad Probabilidad Probabilidad en un segundo supuesto.
0,2 0,7 0,1 Coste
Portal de ventas 72 80 93 47
Ayuda distribucin 45 70 87 35 Supuesto prctico 5.2: La compaa descrita en el supuesto prctico 5.1
decide ampliar su estudio y saber cual es el tiempo de retorno de su inversin
Gestion de Cobros 57 83 113 52
como un nuevo parmetro para la toma de su decisin de qu tipo de proyecto
acometer con prioridad uno. Para ello indica que la inversin en cada uno de
los tres proyectos la realizar al principio del periodo (podran realizarse las
68 P L A N IF IC A C IO N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 5: A S P E C T O S G E R I-N C 1 A L E S 69

aportaciones de la inversin en varios periodos) y que los flu jo s de tesorera

de cada periodo so n los siguientes:
Para el p rim e r proyecto sern constantes en ocho aos a un im porte de 10
m illones de pesetas.
Para el segundo proyecto los beneficios sern igualmente fijo s y de un
im porte de siete m illones de pesetas durante diez aos.
En el tercer pro yecto se estim a que se producirn flu jo s p o sitivo s con la
cadencia de 2, 4, 7, 12, 15, 14, 13 y 12 millones de peseta s en cada ao
respectivo.
l a s a de referencia: Inters medio de mercado que se pagar por disponer
de unos fondos de los que se carece.
Inters prefijado: Es el inters negociado y que suponemos que se
mantendr fijo en la aplicacin del prstamo.
Periodo de R ecuperacin (Pay-back) es el tiempo necesario para
recuperar el capital depositado en la inversin com o hemos visto en el supuesto
anterior. Este valor nos indica la velocidad con que se recupera la inversin de
tal suerte que a valor ms bajo, con el resto de las condiciones constantes,
mejor ser econmicamente el proyecto.

O btendram os que, para el prim er proyecto, el tiempo de retorno sera del Cuando entra en juego la lasa de inflacin, el PB se obtiene en el momento
cociente de dividir la inversin entre el flu jo de tesorera p o r se r constante, es en el que se iguala la siguiente expresin:
decir:
f PT, =f 1,
PR(1) = 4 7 / 1 0 = 4 , 7 p o r lo tanto se recupera en el quinto ao de 7{\ + r ) h { \ +r)
explotacin.
siendo /, el valor de la inversin que se efecta en el periodo t5.
PR(2) = 3 5 / 7 5
Normalmente la restriccin del proyecto viene impuesta por una condicin
En el tercer caso se recupera en el ao sexto y a que ese ao el importe de
del tipo que el P B sea menor de x aos.
la inversin, que eran 52 millones, est horquillado entre una flu jo de
tesorera del quinto ao que no llega a cubrir los costes y un sexto ao en que
El PB se suele considerar de una nica inversin inicial y, en este caso, el
se supera la inversin. PB se obtiene de la frmula:

Q = 2 + 4 + 7 + 1 2+ 1 5 = 40 y PB JP 'T
y =i
Qi+, = 2 + 4 + 7 + 1 2 + 1 5 + 14 = 54 /=o (1 + r)

Con la inform acin obtenida hasta el m om ento podem os decir que los Si hubiera distintas inversiones anuales hasta el ao N , el PB sera mayor de
p rim ero s proyecto s son ms interesantes, fre n te al periodo de recuperacin, N y se calculara como:
que e l tercero.
PB f T 'T N T

/=o (l + ry ,=o (!+ /)'

Vamos a introducir algunos valores que tienen importancia trascendental

en los proyectos. Hablamos de los siguientes trminos:
Tasa de in flacin (/): Se define com o la medida del incremento continuo
en los precios de los bienes y servicios a travs del tiempo.
5 La igualdad anterior puede no darse nunca con valores de periodificacin discretos por lo que
se considerar, a efectos prcticos, el primer periodo en que el primer trmino (suma acumula
da de los flujos de tesorera) sean iguales o inmedatamente superiores al segundo trmino (in
versin soportada).
70 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 5. A S P E C TOS G P.KHNC IA I.KS 71

El segundo trmino es el valor actualizado de todas las inversiones que

igualaran, en el momento del periodo de retorno, al valor actualizado de lodos Tipos de rentabilidad econmica: rea! (considerando la inflaccin) y
los flujos de caja hasta el ao en que se cubre la inversin. monetaria (sin ella)

Flujos de Tesorera (FT)\ Son las entradas y salidas de caja en cada (I + m ) = (I + 0 (1 + 7 7 ? /,)
periodo, as FT es el flujo de caja del periodo n.

Valor Actual Neto ( VAN) de una inversin: representa el valor monetario Dentro de la documentacin que se suele acompaar al lanzamiento del
neto en un momento dado. Se calcula como la diferencia entre los flujos de proyecto es interesante conocer los conceptos de Perfil y de Portafolio.
tesorera actualizada a la tasa de inters prefijado y las inversiones actualizadas
a esa misma fecha. As un VAN positivo indica que la inversin en el proyecto Perfil: Es un estudio en el que se valoran todos los elementos que forman
es rentable o, al menos, es mejor que la tasa de referencia. parte de un proceso (componentes/elementos): calidad, precio, competencia,
coste, producto, diferenciacin, tiempo, etc... Con estos datos se establece una
Se calcula mediante la frmula: escala mtrica y en cada componente se asigna un valor con lo que
obtendremos el perfil del proceso.
Fe i,-'/- p ii i

Portafolio: Anlisis espacial en el que se relacionan diferentes conceptos:

( l + /')' w (l + '-)
evolucin del mercado, ventaja competitiva, ... Todo ello se evala en una
matriz finita de tal forma que en cada uno de los intervalos se establece la
En el clculo del VAN se debe de considerar al final del periodo (ao n) el
posicin de la empresa. Posteriormente se define la posicin de la empresa
valor residual del bien como si se tratara de un flujo de tesorera en ese ao.
segn su operatividad del futuro lo que nos facilita a encontrar la situacin
Realmente se debera de utilizar un Cash Flow Neto en los numeradores, as:
exacta de la empresa en cada momento.
Ingresos - gastos y costes financieros =
Beneficio de explotacin + amortizacin tcnica =
Beneficio bruto - impuestos =
5.2 C U N D O U N P R O Y E C T O ES S A T ISF A C T O R IO ?
Beneficio neto + amortizacin tcnica =
Cash Flow Bruto - amortizacin del crdito =
Una vez que el directivo posee el documento de valoracin inicial se planeara
Casli Flow Neto
la decisin de realizar el proyecto y, en este momento, debemos de considerar
cual es la mejor forma de alcanzar el xito en el desarrollo del proyecto, para
Tasa Interna de Rentabilidad (TIR) es el tipo de rentabilidad que anula el
ello vamos a estudiar cuales son los criterios desde distintos puntos de vista.
Van del final del periodo. O lo que es lo mismo: es la tasa que compensa todas
las inversiones con los flujos de tesorera esperados. Cuando un proyecto tiene
Para la alta direccin un proyecto ha resultado exitoso si se cumplen,
un TIR de un x% va a generar liquidez suficiente para remunerar al x% del
normalmente, los siguientes aspectos:
capital invertido en el proyecto adems de devolver el capital invertido.
Es un activo real
Se calcula mediante la frmula:
Se alcanzaron los objetivos
Se controlaron los costes
f FT, y i,
Estuvo bien dirigido y controlado
o (l + TRI)' ( l + TRI)'
Frente a la organizacin usuaria o los usuarios de la unidad de negocio, el
donde N es la duracin total de la inversin. sistema ser bueno si:
72 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Se comprendieron las necesidades
Permite el crecimiento
Se implementaron cambios vitales
El sistema resulta fcil de controlar
Trabaja como se esperaba
Frente al personal del equipo del proyecto hubo xito si se han satisfecho
sus necesidades personal, en concreto si:
Hubo comunicacin con los usuarios
Las especificaciones fueron revisadas y aprobadas
Se evaluaron los cambios
La direccin estuvo continuamente implicada
Aument nuestra experiencia y confianza
Frente a los que operan el sistema, o en casos de proyectos subcontratados,
frente a los que tendrn responsabilidad en el mantenimiento del mismo:
Est bien documentado
Es fcil de operar
Fue bien probado y no tiene sorpresas.
Tiene una excelente capacidad de recuperacin y, ante posibles cadas
del sistema, permite un rpido rearranque.
En general, como lneas maestras, toda la organizacin piensa que la
realizacin de un proyecto ha tenido xito si se ha realizado dentro de los
plazos previstos, dentro de los presupuestos establecidos y se ha obtenido un
producto de calidad que satisface a los usuarios.
No se debe despreciar la dimensin institucional del proyecto que
dependiendo del entorno de la empresa variarn los objetivos y dependiendo de
cmo definamos los objetivos obtendremos el xito o no.
Los objetivos que queremos obtener nos van a decir la orientacin que
deber darse a la utilizacin de recursos y el comportamiento del personal lo
que implicar hacer cierta investigacin de la eficiencia o combinacin de
factores que se debe de llevar a cabo para obtenerlos.
CAPT U LO 5: A S P E C T O S G ER E N C 1A I.F.S 73
Es de considerar que suele haber un conjunto de objetivos lo que conlleva
una serie de prioridades que nos obligarn al establecimiento de un plan o
programa de cumplimiento de objetivos.
Decamos, por otra parte, que el proyecto ha sido exitoso si ha cumplido los
presupuestos. El control de costes es fundamental porque:
Si no existe presupuesto se hace difcil la gestin del proyecto.
Si hay presupuesto pero la gestin es mala, tarde o temprano los
resultados sern malos.
Los costes de un sistema informtico son cada vez ms altos.
Las reas usuarias (o clientes) deben de soportar los costes.
La gestin debe iniciarse con una buena eleccin del presupuesto, y los
gastos e inversiones deben de justificarse en relacin con el "negocio". El
presupuesto debe abarcar todas las partidas para tener controlado todo el
Proyecto Informtico para saber puntualmente lo que estamos gastando
globalmente en los distintos conceptos.
Respecto a la filosofa de como se deben de realizar los presupuestos se
debe decir que no hay un mtodo nico, que se defienden varias teoras y que
se pueden combinar as, por ejemplo, se puede:
Partir de unas directrices (Top-down), basadas en porcentajes sobre
proyectos similares ms recientes.
Elaborar un borrador segn determinados criterios (Bottom-up
condicionado) justificando lo que exceda un determinado porcentaje de
las directrices.
Entre las partidas ms importantes a incluir en el presupuesto, cabe
destacar:
Costes totales de personal:
o Fijo o eventual.
o Formacin.
o Gastos derivados de seleccin y contratacin.
o Viajes y desplazamientos.
Tcnicos y servicios contratados:
o Consultores.
o Auditores.
o Administracin de Seguridad Informtica.
74 PLA N IFIC A CI N Y G ESTI N D E SISTEM A S INFORM TICOS C A PTU L O 5: A SPEC TO S GERHNCIALES 75

o Tcnicos de desarrollo, 5.3 LOS ACTIVOS DE LA EMPRESA

o Entrada de datos,
o Transportistas, mensajeros. Conocer los criterios generales de la organizacin, el concepto de cultura de
empresa y los cambios a los que indiscutiblemente est sometida6.
Equipos (ordenadores, perifricos, redes, terminales...):
o Alquiler. Un proyecto puede ser satisfactorio para los empleados que lo utilizan,
o Compra/amortizacin, frente a la operacin, etc., pero finalmente se ver que es satisfactorio si
o Mantenimiento. realmente constituye un activo importante para la empresa, considerndolo
como un elemento de posicionamiento en el mercado frente a la competencia.
Software (Bsico, paquetes, utilidades, herramientas...).
Se situar la gestin informtica como un activo ms de la empresa,
comparndolo con otros activos, se estudiarn propiedades comunes y
Comunicaciones:
caractersticas diferenciadoras con la idea de que el alumno asimile el concepto
o Voz
de "cultura de empresa".
o Datos

Instalaciones:
o Alquileres,
5.4 LA INFORMACIN COMO ACTIVO ESTRATGICO
o Gastos.
o Consumos (agua, electricidad,...)
El acceso a la informacin, en las empresas de hoy da, es una de las tareas ms
o Mobiliario
difciles de los directivos en sus diarios procesos de toma de decisiones. Hoy
da no es posible esperar de un empresario, que ya de por s necesita tener un
Suministros (papel, soportes magnticos, cintas entintadas,...) y
gran conocimiento sobre el funcionamiento de la empresa, del posicionamiento
servicios contratados:
de sus competidores frente a un mercado altamente cambiante, de la
o Consultores,
informacin que poseen sus tcnicos, de los gustos de sus clientes,.... Esto nos
o Auditores.
condice a que, para que algunas empresas puedan sobrevivir, necesitan
o Administracin de Seguridad Informtica,
incorporar lo que, en trminos generales, se conoce como las nuevas
o Tcnicos de desarrollo,
tecnologas de la informacin. Y esto por qu? Porque, hoy ms que nunca, la
o Entrada de datos,
informacin es un valor para la empresa, es un activo de prim er orden que
o Transportistas, mensajeros.
puede ser utilizado para crear riqueza, para obtener un mejor posicionamiento
en el mercado, o para poder utilizarlo como una baza de mejora frente a la
Oficinas de servicios.
competencia. En este sentido hacemos nfasis en el activo estratgico que
supone, no el hecho de tener mucha informacin, sino el poder utilizarla, de la
Impuestos. forma ms eficientemente posible, para que sea un verdadero conocimiento que
sirva como factor productivo de explotacin.
Seguros.
En este sentido podemos afirmar que una buena gestin en la informacin
Intereses (si hay partidas que financiar). que soporta una empresa a nivel globalizado, que pone la informacin en el
punto y en el momento en que sea preciso consultarla, que perm ite obtener un
mayor rendimiento en sus empleados al disponer de esa informacin puntual al

6 Grupp, B., "La cuestin del departamento de informtica". Hispano Europea, 1985.
76 P L A N IF IC A C I N Y G E S T I N DF. S IS T E M A S IN F O R M T IC O S _________________________ C A P T U L O 5. A S PE C T O S G E R F -N C IA L E S 77

momento, es un activo extraordinariamente importante como para que los
directivos la consideren como una de las responsabilidades de primer orden. Es
tal la importancia de este tipo de activo que el empresario o el director no
podr delegar este tipo de tareas en ningn caso. Es ms, existen sectores de
actividad, como pueden ser las empresas dedicadas a los sectores tursticos o
de seguros, donde el verdadero factor productivo es la buena gestin de sus
sistemas de informacin y en los que la inversin en este tipo de activos tendr
una influencia directamente relacionada con sus resultados de explotacin.
5.5 N E C E SID A D DE E L A B O R A R P R O Y E C T O S PA R A
A D E C U A R L O S SIST E M A S DE IN F O R M A C I N A L A S TO M A S
DE D E C IS IO N E S EN UN M E R C A D O C A M B IA N T E
dentro de la Direccin de Proyectos, su funcionamiento debe de ser como si el
"Proyecto" fuera una unidad diferente y, si fuera necesario, se creara un centro
de coste para la gestin en s.
Una consecuencia beneficiosa de la repercusin de costes es la necesidad
de dar buen servicio8 ya que un usuario que no obtiene un nivel de respuesta
aceptable, un servicio pobre, o cuyas peticiones no se tengan en cuenta,
protestar ante unos cargos que pueden considerar injustificados o excesivos
introduciendo nuevamente unos factores de productividad que ejercern
nuevamente una dinmica hacia el cambio correctivo y, finalmente, hacia la
mejora en el servicio.

Segn el planteamiento anterior en algunos casos ser necesario elaborar

proyectos en el que el orden de los ingredientes para fabricar servicios
cambie de valoracin: La gestin del conocimiento, entendida esta como la
gestin ms eficiente de sus sistemas informticos, que traten de obtener valor
adicional a toda la informacin que fluye por la empresa, incluso en datos no
estructurados, ser la materia prima, cada vez, y segn la empresa va
creciendo, ms inagotable. Los procesos de los tendrn mayor cabida en cuanto
que son la base de la toma de decisiones, y los procedimientos se irn
adecuando a que la informacin sea correcta, til, completa, pertinente y
disponible en tiempo real.

Otro argumento que se aporta, para comprender la necesidad de ajustar los

sistemas de informacin a esos cambios como mtodo organizativo, es el hecho
diferenciador de la competitividad: En la empresa hay que estar bien
posicionados, disponer de ms y ms informacin aunque solamente sea por la
necesidad de sobrevivir en un periodo de fuertes cambios que, nicamente se
podrn realizar, con un buen sistema de conocimientos.

Otro apartado importante que se debe considerar dentro de la unidad

temtica actual -aspectos gerenciales-, es la repercusin de costes7 que dar a
los directivos una visin global de la realidad de sus organizaciones. En este
sentido, si bien no puede imponerlo el Director del Proyecto por ser decisin de
la Alta Direccin, es necesario y tiene ms ventajas que inconvenientes sobre
todo a la hora de tener una valoracin en la toma de decisiones. El general, y
s Se puede obtener ms informacin del artculo de Joan M. Amat Salas el control empresarial
7 En este sentido se puede consultar la obra de Romeo Baroggi "I costi dell'elaborazione elei- mediante la contabilidad de gestin publicado en Cuadernos de Management, suplemento n.
ironica dei dati", Franco Angeli Editore, Milano 1978. 338 de Nueva Empresa. 16-30 de septiembre de 1990.
P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S

CAPTULO 6

DEFINICIN DEL PROBLEMA Y

ESTRATEGIAS DE SOLUCIN

La definicin de los requerimientos es una descripcin abstracta de los

servicios que se espera que se construyan y aporten al sistema para que realice
las funciones que el usuario espera del mismo. Debe consistir slo en sealar el
comportamiento externo del sistema sin que, en ningn caso, entre a definir
elementos internos o caractersticas. Estos requerimientos deben de ser
formalizados por escrito en un lenguaje natural que pueda ser entendido por
cualquier persona conocedora de la empresa pero sin conocimientos bsicos de
informtica. Los requerimientos se clasifican en dos categoras:
Requerimientos funcionales y requerimientos no funcionales.

La funcin y el rendimiento deben de ser evaluados a la vez y este binomio

puede dar una resultante de tal magnitud que pudiera ser que la diferencia en el
esfuerzo de desarrollo sea muy importante en distintos escenarios de fiabilidad.

Por otra parte, el software interacciona con otros elementos del sistema
informtico. El planificador debe de considerar la naturaleza y la complejidad
de cada interfaz para determinar cualquier efecto en los recursos, costes y
mtodos de desarrollo. La descripcin de los interfases, considerados como
hardware, software y personas que lo utilizan, deben de estar perfectamente
documentados.

Una vez que se dispone de un exhaustivo anlisis de requerimientos

pasaremos a disear un modelo que ser construido ms adelante. El proceso
de diseo combina intuicin y mtodos que cambian continuamente conforme
aparecen nuevas experiencias y un ms amplio conocimiento (obsrvese que
hablamos de diseo de software y no de programacin o escritura de cdigo
conceptos abandonados desde hace casi dos dcadas).
80 P L A N IF IC A C I N Y G E S T IO N D E S IS T E M A S IN F O R M T IC O S
6.1 OBJETIVOS A ALCANZAR.
En un principio el proyecto ha nacido como una idea que trata de obtener un
bien futuro y que, de alguna forma, ha sido presentado a la alta direccin para
solicitar su posible aprobacin pero que an se mantiene en la fase de lo que
podramos denominar fase conceptual. Los ejemplos que podramos citar de
proyectos que no pasan de esta etapa son numerosos; los tcnicos que se han
afanado en el proyecto, y no ven continuidad a algo que para ellos parece
trivial, les posiciona en un punto de incomodidad que debe de entenderse como
las posibles dudas que actan en la mente del empresario o del cliente que tiene
que financiar la operacin y que, sin lugar a duda, estar forzado a correr un
cierto riesgo.
Es esta la mejor solucin al problema?Es el momento adecuado? Para
poder despejar este tipo de dudas ser necesario obtener ms conocimiento
sobre el proyecto en s: Ser necesario efectuar una definicin formal de las
necesidades de la organizacin para poder estudiar el mejor proyecto de una
posible gama de soluciones.
Para poder llevar este estudio por vas controladas efectuaremos un primer
anlisis sobre el estudio del problema a detalle para lo cual comenzaremos por
describir una serie de necesidades identificadas que quedarn documentadas en
un informe que todos los miembros implicados conocern, discutirn y
manejarn como punto de partida para nuevos avances del proyecto.
Como decamos anteriormente del estudio del informe de necesidades
identificadas se pasar a ensayar un borrador de objetivos del proyecto que
mediante una serie de reuniones peridicas en las que se busque la solucin
ms adecuada y en la que cada parte establecer sus necesidades se intentar
llegar a un informe de objetivos que nuevamente ser cuestionado, atendiendo
en especial a las recomendaciones tcnicas y al posible plan de implantacin
definido por la direccin de la empresa hasta conseguir un documento de
objetivos terminado que servir, a su vez de revisin, hasta conseguir su total
aprobacin por las partes implicadas.
En la fase de revisin del documento de objetivos, el director del proyecto,
ir creando una lista de puntos de control de las reuniones sucesivas: En
especial mantendr registros vivos, de una reunin a otra, de los puntos que
puedan suponer un riesgo especial del proyecto e ir perfilando un posible plan
de actuacin que continuamente se ir perfilando hasta conseguir una
definicin lo suficientemente clara como para iniciar otra fase del proyecto. En
C A P T U L O 6: D E F IN IC I N D E L P R O B L E M A Y E S T R A T E G IA S D E S O L U C I N SI
especial, el director de proyecto, en la fase de revisin del documento de
objetivos se tendr muy en cuenta los siguientes aspectos:
mbito
Factibilidad tcnica
Los recursos a emplear
Las responsabilidades de cada participante
Las Directrices generales de la compaa
Los factores de productividad
Los criterios de terminacin
Con el anlisis de cada uno de los puntos anteriores se debe de llegar a
tener dispuesto el documento listo para la firma en el cual se deben de haber
despejado las incgnitas que hacen que el proyecto sea creble y dnde se
pueda evaluar claramente el riesgo que se correr con el proyecto en cuestin
en cado de seguir adelante y en el caso de no seguir.
En cada una de las fases o reuniones que se hayan ido produciendo hasta
afinar el documento de objetivos, el director del proyecto habr ido
actualizando la lista de control del riesgo y el plan de actuacin a la vez que ir
eliminando la lista de control de revisin de objetivos.
El documento de objetivos deber tener una lista de objetivos de proyecto
claros. Estos objetivos son muy importantes porque, como hemos visto en el
captulo anterior, uno de los factores del xito del proyecto est vinculado al
grado de cumplimiento de los mismos. Si cada objetivo de proyecto es claro se
puede medir sin lugar a confusin que beneficiara al director de proyecto poco
eficiente que tratar de buscar excusas para justificar su ineptitud. Por lo tanto
se debern evitar objetivos con doble interpretacin o con interpretacin muy
generalista del tipo se podr consultar la informacin con agregacin de
cualquier dato de la compaa. En este sentido debemos considerar que los
objetivos deben de ser:
Cuantificables, lo que conlleva que sean controlables.
Realistas, alcanzables.
Omnipresentes a lo largo del proyecto: tienen que constituir las lneas
maestras de referencia.
Jerarquizables entre s.
Deberan de ser, en medida de lo posible, independientes del entorno.
Permanentes mientras no se decida el cambio, es decir, no son
modificables sin una justificacin slida.
82 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Por otra parte debemos de considerar distintos puntos de vista para
establecer los objetivos, en este sentido puede ayudarnos una clasificacin de
los objetivos desde el punto de vista de los logros que se quieren realizar. As
podemos tener:
Objetivos ligados a la configuracin del producto final (evolucin,
versiones, capacidad para dar lugar a una familia de productos...)
Objetivos ligados a la calidad del producto y su homologacin
(ventajas y desventajas competitivas, normas de calidad a conseguir...)
Objetivos ligados a la produccin a alcanzar (rendimiento, tiempo,
mano de obra, consumo...)
Objetivos ligados a plazos de construccin y explotacin (plazos de
entrega final y parciales, periodo de paso a explotacin y de
garanta...)Objetivos ligados a coste de inversin (plazos y mxima
inversin...)Objetivos ligados a rentabilidad (ingresos esperados,
margen, beneficio...)
6.2 ESPECIFICACIONES DEL PRODUCTO.
El informe de objetivos a alcanzar nos permitir, nuevamente, abordar las
especificaciones concretas del producto. A partir de este momento el director
de proyecto se centrar en estudiar el alcance tcnico del proyecto con toda
frialdad, establecer las limitaciones y las especificaciones del producto a
obtener segn las necesidades que el usuario manifiesta as como la bsqueda
de la solucin ms adecuada.
Aunque pudiera parecer que este tema pudiera ser repeticin de alguno
estudiado en algn curso anterior de Ingeniera del Software, hemos credo
necesario incluirlo porque el enfoque puede variar segn se trate de resolver el
problema en el momento puntual o que se trate de planificarlo para resolverlo
posteriormente sin tener, en este momento, ni los medios ni los recursos
suficientes para "afinar" en la solucin.
Los tpicos que se presentan como parte del alcance del software son
varios, por una parte la declaracin del alcance del software debe de estar
delimitada, por lo tanto los datos cuantitativos han de ser descritos y las
funciones de mitigacin (algoritmos complejos que deben de ser
implementados) debidamente explicadas.
C A P T U L O 6: D E F IN IC I N D E L P R O B L E M A Y ESTR A T E G IA S D E S O L U C I N 83
La definicin de los requerimientos es una descripcin abstracta de los
servicios que se espera que se construyan y aporten al sistema para que realice
las funciones que el usuario espera del mismo. Debe de consistir slo en
sealar el comportamiento externo del sistema sin que, en ningn caso, entre a
definir elementos internos o caractersticas. Estos requerimientos deben de ser
formalizados por escrito en un lenguaje natural que pueda ser entendido por
cualquier persona conocedora de la empresa pero sin conocimientos bsicos de
informtica. Los requerimientos se clasifican en dos categoras:
Requerimientos funcionales y requerimientos no funcionales.
En esta fase se debe de evaluar tanto la funcin como el rendimiento:
ambos factores deben de ser evaluados a la vez y este binomio puede dar una
resultante de tal magnitud que pudiera ser que la diferencia en el esfuerzo de
desarrollo sea muy importante en distintos escenarios de fiabilidad por lo que
ser necesario establecer criterios para conducir el proyecto dentro de un marco
de resultados predecible.
Tenemos que considerar, igualmente, que el software interacciona con
otros elementos del sistema informtico. El planificador debe de considerar la
naturaleza y la complejidad de cada interfaz para determinar cualquier efecto
en los recursos, costes y mtodos de desarrollo. La descripcin de las
interfaces, consideradas, como hardware y software, hacen que las personas
que lo utilizan estn perfectamente documentadas.
Una vez que se dispone de un exhaustivo anlisis de requerimientos
pasaremos a disear un modelo que ser construido ms adelante. El proceso
de diseo combina intuicin y mtodos que cambian continuamente conforme
aparecen nuevas experiencias y un ms amplio conocimiento (obsrvese que
hablamos de diseo de software y no de programacin o escritura de cdigo
conceptos abandonados desde hace casi dos dcadas).
Las especificaciones de producto deben incluir, adems de la lista de
resultados esperados del proyecto, unas fechas de cumplimiento especficas,
tanto para la finalizacin del proyecto como para los hitos intermedios, ciertos
criterios de calidad especficos que deben cumplir los resultados y los lmites
de costo entre los que se debe de posicionar el proyecto.
84 P L A N IF IC A C I N Y G E S TIN D E S IS T E M A S IN F O R M T IC O S
6.3 LOS REQUERIM IENTOS DE LOS INTERESADOS.
Para que los objetivos resulten eficaces, es importante que todos los
participantes del proyecto estn oficialmente de acuerdo con ellos. A menudo,
el administrador del proyecto crea un documento de objetivos que se convierte
en una parte permanente del proyecto.
Pero es muy importante a la hora de la realizacin del proyecto saber si se
va a contratar total o parcialmente porque determinar unos criterios que en
algunos casos debern imponerse, como pueden ser aspectos metodolgicos de
auditoria y control o la importancia de los riesgos por posibles indefiniciones
de los objetivos o productos que alterarn directamente la cuenta de
explotacin del propio producto. Igualmente es importante saber si se va a
aplicar al proyecto un equipo de control y en caso afirmativo tendremos que
conocer la intensidad del mismo. En este sentido tendremos que considerar la
dedicacin a la direccin de un proyecto o las direcciones parciales o
compartidas de proyectos con la problemtica que acompaa a estas
situaciones.
En la sociedad actual la administracin pblica es un motor muy
importante dentro del desarrollo de proyectos por lo que haremos una reflexin
importante sobre la forma de presentar los proyectos a peticin de los
organismos oficiales. Es importante considerar que todos los aspectos que
vamos a desarrollar a continuacin sobre los concursos y contratos pueden
servir, igualmente, para la empresa privada.
Vamos a efectuar un repaso breve de las actividades que mueven los
concursos desde el punto de vista de sus lneas maestras:
La Propiedad tiene que preparar una peticin de oferta o Pliego de
Condiciones.
El contratista debe de evaluar la decisin de ofertar.
En caso de interesarle ofertar deber prepara su oferta.
La propiedad tendr que evaluar las diferentes ofertas que reciba.
El contratista y el contratante negociarn los trminos de la
adjudicacin.
Para poder realizar las fases anteriores con cierto nivel de xito ser
necesario establecer unos criterios a considerar al preparar una peticin de
ofertas:
Claridad en la redaccin para que el contratista que se elija no tenga
ambigedades o mal entendidos en cuanto a calidad, plazos y precio.
__________ C A P T U L O 6. D E F IN IC IO N D E L P R O B L E M A Y E S T R A TE G IA S D E S O L U C I N 85
Se facilitarn instrucciones de la forma de presentacin de las ofertas
buscando una uniformidad para que podamos deducir las capacidades
de cada contratista.
Se incorporar la lista de requisitos as como los condicionantes
detectados en la fase de decisin de realizar el proyecto.
Se pueden pedir pruebas y cruces de datos para asegurarnos de la
veracidad de la informacin aportada por los contratistas.
6.4 BSQUEDA DE UNA ESTRATEGIA DE SOLUCIN Y SU
DESARROLLO.
Para llevar a buen trmino los directores de proyectos tratan de cumplir los
objetivos generales acordados con sus "clientes, en general tratar de obtener
el producto deseado, dentro de un plazo de ejecucin pactado y dentro de los
costos establecidos. El objetivo quedar definido como una funcin de estos
tres aspectos:
Objetivo = f ( t,c ,e )
Es decir que el objetivo final depender del coste del producto, del tiempo
de desarrollo y de las especificaciones pedidas al proyecto.
Para que el proyecto tenga validez con independencia del momento en el
que se comience se suele expresar el tiempo en unidades relativas a la fecha de
lanzamiento del proyecto aunque esta fecha puede estar ligada a un calendario
real con fechas lmite de cumplimiento concretas. En este sentido hablamos de
fechas como das, semanas, meses entendidos como datos de calendario y no
como medidas de esfuerzo.
El coste normalmente lo especificaremos en euros aunque se puede medir
en cualquier tipo de unidades monetarias. En algunos casos el coste se mide en
dedicacin del personal al proyecto, as tiene sentido hablar de trminos como
hombres-mes, tantos das de analista, etc. En estos casos se sobreentiende que
se habla de una dedicacin de ornada normal siendo la empresa, o el propio
director de proyecto, quien asumir la responsabilidad de aplicar el criterio de
conversin a la unidad monetaria concreta.
Las especificaciones se expresan en forma de lista lo ms detallada posible
para evitar falsas interpretaciones que puedan provocar errores o ciertos niveles
8< P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
de crisis en el desarrollo del proyecto. En este apartado se incluyen todo tipo de
esfuerzos que se han de dedicar para desarrollar el producto, la documentacin
tcnica asociada, las exigencias de calidad impuestas y, si as se ha pactado, la
puesta en marcha o arranque inicial del sistema.
Es importante entender que, al ser el objetivo funcin de estas tres
variables, cualquier cambio en los objetivos se ver afectado por, al menos, una
de las variables que logran el vector resultante. Y si se quiere modificar alguna
de las variables para lograr el proyecto en alguna cuota, esto se producir a
base de modificar alguna de las otras variables.
F ig u ra 6. / E l vecto r o b je tiv o de un p ro y e c to
Para poder efectuar la oferta deberemos de considerar una serie puntos
entre los que se encuentran:
Estudio del Pliego de Condiciones y los requisitos all recogidos
haciendo hincapi en los trabajos o servicios a prestar por terceros.
Considerar los beneficios y los riegos que se asumen si se adjudica la
contratacin.
Estudiar la disponibilidad de recursos para poder atender los
compromisos derivados de la oferta o si se pueden aumentar (los
recursos son limitados!)
Estudiar si es soportable el esfuerzo financiero a satisfacer.
Estudiar la repetibilidad del contrato y si se pueden estandarizar los
procedimientos enriqueciendo la experiencia de la empresa.
Anlisis DAFO (debilidades, amenazas, fortalezas y oportunidades) que
nos ayuden a tomar la decisin de ofertar.
C A P T U L O 6: D E F IN IC I N D E L P R O B L E M A Y E S T R A T E G IA S D E S O L U C IO N 87
Para tratar de efectuar la oferta, la empresa contratista deber fijar una
persona responsable de prepara la oferta que ser la encargada de estudiar los
grados de libertad del cliente expresados en el Pliego de Condiciones. As
mismo descompondr el Pliego en hitos, fases y tareas (lo que compone en s el
anlisis de la oferta). En algunos casos deber negociar la asignacin de las
fases a las distintas reas de la empresa para que estimen el trabajo que debern
realizar y ofrecer datos de valoracin de cada fase y valorar econmicamente
las tareas de integracin de las fases considerando los esfuerzos de
coordinacin. Con este estudio tendr que obtener el precio del coste del
producto y de los plazos de realizacin remitiendo al demandante los puntos no
incluidos.
Suele ayudar a prepara la oferta el conocimiento de la importancia
estratgica de la empresa en el contrato a obtener as como la investigacin de
la situacin de los competidores frente al contrato en curso. Igualmente es muy
importante dedicar algn tiempo a estudiar los criterios de evaluacin de la
oferta por parte de la empresa contratante porque nos dar conocimiento de
cmo seremos evaluados lo que puede permitirnos seguir un guin similar al
que seguirn con nosotros.
En algunos casos, sobre todo en funcin de los lmites de la oferta, ser
necesario el sometimiento de la oferta al departamento jurdico para que
estudie posibles trampas en los modelos de contratos o en la redaccin.
Como gua del contenido de la oferta debemos de considerar algunos
factores clave como es el dejar claro que cumplimos cada uno de los requisitos
de la oferta o indicar, en su caso, los puntos que no se cumplen. Una tcnica
utilizada frecuentemente por los contratistas es transcribir el alcance del
proyecto o suministro para que quede constancia de que se cumple lo
establecido indicando las divergencias ya que muchos pliegos de condiciones
estn esperando que el contratista ofrezca nuevas ideas o puntos de vista sobre
la solucin del proyecto.
Tambin se realizar una planificacin inicial del proyecto haciendo
constar los hitos que se deben de cumplir, las fechas de referencia y los
recursos que se habrn de emplear. En esta planificacin se desglosan las
caractersticas de los productos aportados, su homologacin, las condiciones de
funcionamiento y sus garantas. En muchos casos se agradece el hecho de
incluir estudios distintos a los pedidos indicando claramente las ventajas que
tendra la propiedad si siguiera estos procedimientos o recomendaciones.
88 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
En el caso de que el concurso sea presentado por las administraciones
pblicas y que nos interese concursar tendremos que presentar una serie de
documentos que legalmente se demanden generalmente segn marca la Ley de
Contratos del Estado. Los documentos que normalmente se demandan para
presentarse a concursar son los siguientes:
Carta de acompaamiento de la oferta firmada por alguna persona
responsable (poder notarial, bastanteo, etc.).
Justificante de existencia de la Sociedad y de que puede realizar la
actividad demandada.
Compromiso de adherirse a lo indicado en la oferta en concreto suele
exigirse un compromiso firmado de mantener secreto de la tecnologa
que se ceda, del estado de la tecnologa, etc.
Justificantes de estar al corriente de determinados impuestos y tasas
cuando el contratante es la Administracin.
Aval que garantice que el ofertante no se retirar en caso de ganar la
oferta hasta formar el contrato que se suele elevar al doble en ese
momento para garantizar que termina la obra.
En algunos casos se exige compromiso de no poder ofrecer trabajo a
personas de la empresa propietaria del contrato durante cierto tiempo
(esta opcin a veces es recproca).
Domicilio legal....
Normalmente, en sobre aparte si se trata de la administracin pblica, se
presentan los documentos de tipo tcnico del concurso entre los que se suelen
incluir:
Datos econmicos de la compaa y currculum de las personas que van
a participar en el proyecto
Descripcin de realizaciones similares efectuadas anteriormente
indicando compaa y fecha.
Alcance de la prestacin de servicios indicando los criterios para la
finalizacin del trabajo as como la documentacin final
Declaracin de conformidad con el pliego de prescripciones tcnicas de
contrato, o, en su caso, las alegaciones que se consideren convenientes.
Planificacin del trabajo y garanta de calidad, as como las medidas de
control que estima prudentes.
Justificacin de tener recursos suficientes para poder aplicar en el caso
de que sean necesarios.
Justificantes de estar registrados, como empresa, en alguna
organizacin de calidad.
_________________ C A P T U L O 6 D E F IN IC I N D E L P R O B L E M A Y E S T R A T E G IA S D E S O L U C I N 89
Penalizaciones por incumplimiento de las fechas lmites (menos
frecuente los premios por terminar antes de una fecha prevista)
Frmulas para solucionar cualquier tipo de incidencia dentro de los
plazos establecidos por causa ajena a proveedor o contratista o frmulas
de arbitrio en caso de litigio entre las partes antes de acudir a los
tribunales si no figura en el Pliego de Condiciones.
En un tercer sobre se presentan los documentos de tipo econmico, entre
los que se encuentran:
Alcance global de la oferta
Descomposicin en precios unitarios por si se emplean mayor magnitud
de cifras poder regularizar segn un patrn establecido.
Calendario de finalizaciones parciales y de cobros.
Una vez terminado el plazo de presentacin se procede a la fase de
evaluacin de las ofertas en donde se realizar, primeramente, una
comprobacin de que cada ofertante cumple los requisitos legales para poder
ser contratados. A continuacin se cede la documentacin tcnica a los
evaluadores para que analicen las posibilidades de cada una de las empresas,
estudiando su estructura, su potencia y su organizacin. Igualmente se
efectuar un anlisis de la calidad que se estime van a cumplir cada una de las
empresas ofertantes efectundose una valoracin del riesgo que se corre por
elegir una empresa u otra en funcin de una de una mtrica establecida basada
en factores y pesos para clasificar las ofertas segn una determinada
valoracin. Tambin se valorarn, siguiendo la misma regla, los aspectos
tcnicos a establecindose el detalle de cada uno de los puntos de valoracin.
-4
Finalmente se elabora un informe de valoracin donde quede muy claro los
criterios tomados y en el que se propone un orden de adjudicacin,
normalmente con una puntuacin ponderada, y una lista de empresas excluidas
con su justificacin.
Ser, finalmente, la direccin de la empresa u organismo o una comisin
formada por la misma, la que, bajo un posible nombre como Mesa de
Contratacin estudiar los aspectos tcnicos mostrados en el informe de
valoracin anterior que junto al precio del producto o servicio de cada empresa
les servir de base para la posible adjudicacin.
En algunos casos, ms en la empresa privada que en la pblica, se
comienza una fase de negociacin de la oferta que se suele delegar a personas
del sector comercial con plenos poderes, grandes cualidades de la venta y
90 P L A N IF IC A C I N V G E S T I N D E S IS T E M A S IN F O R M T IC O S
conocedores de tcnicas de cierre de ofertas. Adems, es importante, que
conozcan la importancia estratgica de la empresa en el contrato a obtener, los
criterios de evaluacin y la situacin de los competidores frente al contrato en
curso
En caso de resultar exitosa la oferta, o en caso de que la alta direccin
decida la realizacin del proyecto, se celebrar una reunin de lanzamiento del
proyecto que sirve para establecer las ideas generales respecto a los objetivos a
alcanzar, los requisitos contractuales en configuracin, calidad, plazos y costos,
es estudio de la organizacin existente as como de los recursos con los que se
cuenta. En esta misma reunin se puede prefijar el director del proyecto y los
puntos de inspeccin a realizar quedando todo debidamente soportado por una
documentacin apropiada.
En esta reunin de lanzamiento o en otra inmediata posterior, se
considerar la existencia de unos contratos claros en los que se fijen las
obligaciones de todas las empresas presentes en el Proyecto, el establecimiento
de interlocutores nicos, tanto por parte de los contratistas como de los
proveedores, junto con el compromiso de establecer, por ambas partes, una
organizacin adecuada con personal suficiente para realizar el proyecto y los
protocolos de recepcin del producto el da que se finalice.
A partir de la reunin de lanzamiento entramos en la fase de construccin.
Es fundamental en esta fase aplicar lo proyectado por el departamento de
ingeniera y no modificar nada que no sea accidental, y de hacerlo, consultar
con ingeniera, respetando el equilibrio entre coste, tiempo y calidad. La
incidencia econmica debida a los cambios en esta fase es muy importante y
podemos reflejarla en el siguiente grfico:
F ig u ra 6.2 In cid en cia econm ica d e b id a a los ca m b io s
Otros aspectos a considerar en la fase de construccin:
C A P TU LO 6: D E F IN IC I N D E L P R O B L E M A Y E S T R A T E G IA S D E S O L U C I N 91
La definicin de interlocutores nicos tanto por parte de los contratistas
como de los proveedores.
El establecimiento por ambas partes de una organizacin adecuada con
personal suficiente para realizar el proyecto.
La existencia de unos contratos claros en los que se fijen las
obligaciones de todas las empresas presentes en el Proyecto.
En cuanto al momento de la entrega se puede considerar la entrega con un
protocolo provisional en el que el proyecto se acepta casi finalizado a falta de
subsanar algunos detalles a satisfacer en un tiempo prudencial o un protocolo
definitivo que se limita a dejar constancia de que la lista anterior ha sido
finalizada a satisfaccin. En ambos casos se fija la entrega del producto que a
su vez puede ser parcial o total, o con un sistema de datos funcionando, lo que
supone que se efecte en caliente o en fro, es decir, sin carga de datos.
Igualmente es necesario considerar en el arranque la seguridad lo que nos har
considerar nuevamente que se han cumplido las especificaciones del proyecto
y, de forma particularmente importante, se estudiar el hecho de no influir en la
produccin en curso. Es necesario, ya que a lo largo del tiempo ha supuesto
mucho dao a la industria informtica, no aceptar la finalizacin del proyecto
mientras no se tengan los manuales o normas de funcionamiento.
En algunas situaciones, en el proceso de arranque, ser necesario estudiar la
posibilidad de recurrir a grupos de apoyo para que puedan ayudar en las fases
iniciales de la explotacin del proyecto ya que, es muy posible que se necesiten
trabajos de formacin o entrenamiento del personal que se ocupar de la
ejecucin del proyecto. La formacin se podr realizar bien en instalaciones
similares, con soporte de hipermedia, con simuladores o simplemente siendo
conducidos por otro personal experto en la propia instalacin donde los
operadores estn vigilados por el personal ajeno hasta que demuestren un
dominio de las tcnicas empleadas en el nuevo proyecto.
En general los procesos de trasferencia de tecnologa no son muy triviales
y exigen de un tiempo normalmente infravalorado y pueden ser el motivo de
fracaso de un proyecto en su ltima fase: en la implantacin. Otro aspecto
importante a considerar en estos momentos ser la posibilidad de que se tengan
que volver a revisar los requerimientos porque no cumplan los rendimientos
mnimos exigidos y que no han podido probarse con anterioridad. Es
fundamental en esta fase aplicar lo proyectado por el departamento de
ingeniera y no modificar nada que no sea accidental, y de hacerlo, consultar
con ingeniera.
92 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S

Finalmente no debe de olvidarse de la preparacin de la garanta exigida lo

que supondr evaluar unos esfuerzos para cumplir el compromiso durante el
tiempo de vida del contrato, lo que restar capacidad de recursos para otros
fines posteriores.

CAPTULO 7

FASES DEL PROYECTO

Para gestionar adecuadamente un proyecto, liemos visto que se debe partir de

una definicin de objetivos formalmente aprobada que permita esquematizar la
aplicacin a realizar, su alcance y sus funciones. Posteriormente se debern
definir qu productos se lian de obtener y con qu directrices para que quede
bien claro cuales son los criterios de terminacin del proyecto.

Una vez estudiada la aplicacin y su alcance, y teniendo muy claros los

criterios de finalizacin, procederemos a estimar el coste del esfuerzo en
resolver el problema, labor que realizaremos en el captulo nueve. Las
siguientes funciones a realizar sern establecer responsabilidades entre los
miembros del grupo de trabajo y equipo de desarrollo y llegar a establecer
puntos de control o hitos, labor que se desarrolla en la leccin siguiente.

Dentro de la visin general que se pretende mostrar en el presente captulo,

adelantaremos las funciones de la programacin del tiempo y de los recursos
que se desarrollarn en el captulo dcimo y undcimo respectivamente.

Posteriormente se expondrn las necesidades de incorporar estndares,

bien de la propia organizacin o de las tendencias generales del sector, as
como las especificaciones de seguridad y su control.

No se terminar la presente unidad sin avanzar las necesidades de describir

la composicin de la organizacin requerida, las tcnicas de productividad que
han de emplearse, en qu van a consistir los procesos de seguimiento, cmo se
va a institucionalizar el control de cambios y la gestin de configuraciones,
cmo se deben de realizar los informes de situacin as como describir el
impacto que pude producir todo lo anterior en nuevos proyectos.
94 P L A N IF IC A C I N Y G K S T I N D E S IS T E M A S IN F O R M T IC O S
7.1 ESTRATEGIA DE LA EMPRESA Y SISTEM AS DE
INFORMACIN
La estrategia de la empresa y los sistemas de informacin nacen como
consecuencia de una simbiosis de ambos procesos. La empresa recibe pedidos
de sus clientes, lo que puede suponer un comienzo de un sistema de
informacin, estos documentos son procesados para satisfacer dichos pedidos
convirtiendo un documento en otro, en el caso actual en un albarn de entrega,
mas la entrega fsica del producto. La estrategia de la empresa, a nivel
esquemtico, puede ser la consecucin de sus beneficios debidos a satisfacer
pedidos de clientes pero, entre tanto, se deben de comprobar una serie de
estados dentro de la empresa. Es decir, la estrategia de la empresa y la situacin
fsica puntual de la misma obligar a que mediante un cierto sistema de
informacin se comprueben, por ejemplo, al menos dos situaciones: Si el
cliente tiene crdito y si tenemos disponibilidad de producto en nuestro
almacn.
Para saber si el cliente tiene crdito tendremos que saber si ha pagado los
compromisos anteriores, lo que supone tener que acceder a documentos
contables en los que analizar dicha situacin. Este proceso se puede realizar de
forma manual o de forma automtica y, en el segundo de los casos, este
proceso puede ser mucho ms eficiente si los pedidos de los clientes son muy
numerosos lo que supondr que la estrategia de la empresa frente al riesgo de
cobros de clientes exigir un sistema de informacin concreto soportado por las
tecnologas de la informacin.
En cuanto a la disponibilidad de stock podra suceder muchas cosas: la
empresa tiene stock suficiente para poder servir el pedido con lo que se deber
rebajas el stock contable en las cantidades de producto pedido para mantener la
igualdad entre el stock fsico y el stock contable. Si, como consecuencia de la
entrega de un pedido, se rebaja una cantidad establecida como stock de
seguridad se deber de iniciar otro proceso de compra de nuevos productos
para satisfacer la demanda de los clientes, se debern informar, al menos, de las
condiciones de entrega y de pago, y se le deber asignar una ubicacin en el
almacn. Si no existe producto suficiente se deber decidir si se retiene el
pedido hasta una posible fecha de acopio o, en algunos casos, hasta saber la
fecha de aprovisionamiento en funcin de la disponibilidad frente a otros
pedidos de otros clientes que solicitaron el producto con anterioridad.
Al final, esperamos que estas simples transacciones nos sirvan para
comprender como los sistemas de informacin son los encargados de coordinar
C A P T U L O 7: F A SE S D E U N P R O Y E C T O 95
los flujos y registros de informacin necesarios para llevar a cabo las funciones
de cada empresa en consecuencia a sus propias estrategias de negocio.
Cada empresa puede tener sus propias estrategias de negocio, es decir, sus
propias formas de hacer negocio que le servir para diferenciarse de las
dems y as obtener su margen de explotacin. En algunos casos la estrategia
de negocio puede ser asegurar los cobros de los clientes al mximo posible,
otra estrategia puede ser tener ajustadas las existencias de almacn al mnimo
necesario aunque en algunos casos no pueda suministrar productos de forma
inmediata, en otros casos todo lo contrario. Lo que si es claro es que la
mecanizacin de los sistemas de informacin mediante las tecnologas actuales
es una fuente de proyectos que se debe considerar como de alta necesidad.
7.2 ESTUDIO DE LA CONVENIENCIA Y VIABILIDAD.
Sin embargo, no todo sistema de informacin deber ser realizado con las
tecnologas de la informacin modernas. Ser necesario en cada caso buscar la
mxima eficiencia y considerar que en algunos casos ser ms rentable utilizar
medios manuales que medios automticos, sobre todo si estos medios no se van
a utilizar muchas veces, o, en otras palabras, si no va a producir una reduccin
posterior en los costos que justifique la inversin del nuevo proyecto.
La justificacin de la viabilidad en utilizar tecnologas de la informacin
en aquellos casos en los que es difcil la justificacin puramente contable se
suele dar desde el punto de vista del control y del proceso de toma de las
decisiones. En este sentido se debe considerar el coste del no control o de no
poder utilizar las TIs para obtener exactitud en los importes econmicos
globales de la empresa y, en particular, de la cadena de valor creada.
El margen de explotacin de las empresas viene dado por la correcta
utilizacin de los recursos utilizados para llevar a cabo sus labores propias y de
los que debemos considerar dos tipos fundamentales de actividades: Las de
lnea que son las que tienen relacin directa con la creacin de la cadena de
valor, como pueden ser los procesos de fabricacin o prestacin de servicios, y
las de soporte que son las tareas en las que se apoyan las anteriores para
compartir informacin, coordinarse y no tener que crear estructuras paralelas
para cada tipo de negocio.
Las actividades de soporte se denominan infraestructura de la empresa y,
como consecuencia del punto anterior, todas las actividades de lnea necesitan
96 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
de una infraestructura que d soporte a informacin distribuida y a funciones
de apoyo. El problema para justificar esta infraestructura, que realmente son
los sistemas de informacin, es saber que dimensin se la debe de asignar para
cumplir las estrategias de negocio de forma eficiente; es decir, obteniendo el
mximo de resultados con el menor coste posible1.
Este binomio se puede trasladar al estudio de la conveniencia y la
viabilidad de la utilizacin de las tecnologas de la informacin para dar
soporte a algn proceso de negocio: Es conveniente realizarlo? Se puede
realizar? Existe alguna alternativa que pueda resultar ms eficiente? Al fin y
al cabo son preguntas que tendremos que formularnos en cada una de las
posibles mecanizaciones
7.3 ESTUDIO FUNCIONAL DEL SISTEMA DE INFORMACIN Y
CREACIN DE PROTOTIPOS
En las pginas siguientes se va a estudiar el desarrollo como proyecto, lo que
supondr la utilizacin de un mtodo y una organizacin concreta. Antes de
continuar, se van a establecer una serie de aspectos clave en relacin con el
equipo de desarrollo, con la organizacin y direccin de la empresa y con el
director del proyecto y los usuarios.
En cuanto al equipo de desarrollo hay que tener en cuenta los siguientes
aspectos:
- Justificacin del tema: Es necesario que todos los integrantes del
equipo de desarrollo sepan para qu estn efectuando ese trabajo y poder
sentirse motivados y partcipes del proyecto.
- Participacin del usuario: La opinin del usuario es muy interesante
para el diseo total del sistema y tiene varios beneficios: por una parte aportar
ideas y experiencia que pueden ser importantes para facilitar el uso cotidiano
de la nueva herramienta que se est diseando, y por otra parte, al haber
participado en el anlisis, sentir el nuevo sistema de informacin como algo
propio, sabr en cada momento el por qu de cada decisin y trasmitir
confianza al resto de la organizacin.
' Vase el captulo 5o para conocer la forma de realizar anlisis de rentabilidad
C A P T U L O 7: F A SE S DE U N P R O Y E C T O 97
- Construccin por fases: De todo el sistema a desarrollar se obtendrn
una serie de hitos con sus prioridades y prerrequisitos concretos que, con la
ayuda de un planificador de proyectos, se optimizarn para reducir el tiempo de
desarrollo y el coste logrndose una planificacin previa que sucesivamente se
ir refmando en funcin del cumplimiento de los puntos de control que el
director del proyecto establezca.
Control de cambios: Es inevitable, por muchos controles que se hayan
incorporado, que surjan cambios en la planificacin o, incluso, en las funciones
a desarrollar. Estos cambios pueden alterar considerablemente el proyecto por
pequeos que parezcan, por ello, es necesario tener un buen control de los
cambios y efectuar una revisin de la planificacin cada vez que surja alguno.
- Inspeccin de lo realizado: Cada fase que se vaya realizando es
necesario probarla totalmente para darla definitivamente como buena. Una
planificacin en la que se vayan incorporando funciones realizadas sin un
correcto control de finalizacin conlleva unas sorpresas aadidas que harn
fracasar la programacin en las ltimas etapas de la entrega que son,
precisamente, cuando menos tiempo de respuesta quedar.
- Proceso disciplinado: Es frecuente que algunas funciones preparadas
en alguna fase anterior, tengan que ser modificadas en el futuro para que
cumpla algn nuevo requisito, y que, a partir de este cambio, no funcione en
las versiones anteriores bien por falta de recompilacin o porque sea necesario
incorporar algn cambio a lo ya realizado. Esto exigir una poltica
disciplinada de control de cambios para que estos problemas tengan unos
efectos mnimos a lo largo del proyecto.
- Sistemas de rcalimentacin. Es frecuente que el proyecto actual tenga
que convivir con un proceso ya existente aun cuando el segundo no est
mecanizado. En estos casos siempre se deben prever un sistema de
funcionamiento para el caso de que al incorporar el nuevo sistema y se tenga
que suspender por cualquier causa, siga funcionando el sistema anterior
mientras se corrigen los fallos del nuevo.
7.4 ACTIVIDADES DE INICIO DEL PROYECTO
En esta primera fase de la realizacin de un proyecto la mayor parte de las
actividades est relacionada con la gestin. Como actividades de gestin
iniciales del proyecto tenemos dos tareas fundamentales:
9S P L A N IF IC A C IO N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
1. ESTIMACIN: El objetivo de esta actividad es conocer el tamao
aproximado del software a desarrollar y establecer el coste, la duracin
y los recursos necesarios para conseguir desarrollarlo. Para la
realizacin de esta tarea podemos utilizar varias tcnicas de estimacin,
que veremos en captulos posteriores de este libro. De forma resumida
estas tcnicas son:
Empricas: Basadas en la experiencia y en la opinin de expertos.
Estadsticas: Se calculan utilizando propiedades del software a
desarrollar, es decir: Esfuerzo=funcin(propiedades del software a
desarrollar). Pueden ser de dos tipos:
o Lineales: Cuando la funcin es lineal (por ejemplo: f(x)=5x).
Son poco eficaces y alejadas de la realidad compleja del
sistema.
o No lineales: Cuando la funcin de esfuerzo es exponencial.
Son las tcnicas ms realistas. Algunas son: COCOMO,
SLIM, PUNTOS FUNCION, MARK II.
2. PLANIFICACIN: El objetivo es definir y preparar las condiciones de
trabajo, estableciendo recursos, fechas y costes para lograr los objetivos
que se persiguen con el proyecto. Algunas importantes tcnicas de
planificacin (que veremos detalladamente en este libro) son:
PER I' (Program Evaluation al Review Technique)
DIAGRAMA DE GANTT
WBS (WORK BREAKDOWN STRUCTURE)
Otra tarea fundamental al inicio del proyecto es determinar los estndares
y metodologas a utilizar para el desarrollo del mismo. Existen metodologas
propias de gestin de proyectos, que ya se ha debido utilizar para las tareas de
estimacin y planificacin, y de las cuales presentamos y explicamos dos en el
Anexo 1 (Project Management Body Of Knowledge-PMBOK) y Anexo 2
(Gestin de Proyectos de la Administracin Pblica Espaola-METRICA).
Pero para el desarrollo de un proyecto informtico existen estndares, ciclos de
vida y metodologas especficas, cuya eleccin condicionar la vida del
proyecto. Veremos estos conceptos brevemente.
Segn el IEEE Computer Dictionary Ciclo de vida del software es el
marco de referencia que contiene los procesos, actividades y tareas
C A P T U L O 7: F A SE S D E U N P R O Y E C T O 99
involucrados en el desarrollo, operacin y mantenimiento de un producto
software, abarcando la vida del sistema desde la definicin de los requisitos
hasta la finalizacin de su uso. Segn el tipo y caractersticas del sistema
software a desarrollar debemos elegir el tipo de ciclo de vida ms adecuado.
Algunos de estos son:
El ciclo de vida ms tradicional es el denominado en cascada. En l
cada fase solo empieza cuando termina la anterior, no contempla
iteraciones ni paralelismos potenciales entre fases, por lo que debe
aplicarse a sistemas sencillos y con una clara definicin inicial de
requisitos.
El ciclo de vida basado en prototipos utiliza un prototipo (puede ser
un programa que mplementa parte de la funcionalidad de la
aplicacin, el diseo de pantallas e informes, etc.) para que sea
evaluado por el cliente hasta que de su aprobacin, y entonces, se
comienza a construir la verdadera aplicacin desechando el
prototipo. Se debe utilizar en aquellas aplicaciones en las que el
cliente no tiene claro los objetivos a cumplir.
El ciclo de vida incremental es de tipo evolutivo, se desarrolla
mediante incrementos o versiones intermedias, en cada una de las
cuales se aade una nueva funcionalidad de la aplicacin hasta llegar
a la versin final con la funcionalidad completa. Es muy til en
aplicaciones modulares donde los requisitos no estn muy bien
definidos.
El ciclo de vida en espiral es una evolucin del ciclo de vida en
cascada, en el que antes de pasar de una fase a otra se debe planificar
las fases siguientes, determinar objetivos y restricciones (riesgos) y
evaluar alternativas. Se debe aplicar en vez del ciclo de vida en
cascada para aplicaciones complejas, con riesgos o no definidas.
Los ciclos de vida de agrupamiento y ciclo de vida fuente estn
especialmente indicados para aplicaciones orientadas a objetos.
Hay otros estndares a utilizar durante el desarrollo del proyecto, relativos
a seguridad, calidad, accesibilidad, configuracin, etc. Pero, en este captulo
dedicado a las fases del proyecto informtico, es importante comentar el
estndar de procesos. Estos estndares definen los procesos y tareas a
desarrollar y sus objetivos y actividades. Uno de los ms extendidos es el ISO
12.207 definido en 1996 con el nombre Software Life-Cycle Processes
100 PL A N IFIC A C I N Y GESTIN D E SIST E M A S IN FO RM TICO S
( www.iso.ch). Ha sido traducido en Espaa y es norma UNE de AENOR
(www.acnor.es). Este estndar define 17 procesos agrupados en tres categoras:
principales, organizacionales y de apoyo.
Los estndares de procesos no establecen el orden y la relacin entre
procesos ni las tcnicas ni mtodos para llevarlos a cabo. Aqu entran las
denominadas metodologas de ingeniera del software o de desarrollo del
software. En la fase de definicin de cualquier proyecto software hay que
establecer y difundir la metodologa a utilizar. Estas metodologas son un
conjunto integrado de tcnicas y mtodos que permiten obtener de forma
homognea y abierta cada una de las actividades del ciclo de vida del software.
La metodologa establece:
como dividir el proyecto en etapas,
que trabajos se llevan a cabo en cada etapa,
que productos se salida se producen en cada etapa,
que tcnicas se utilizan en cada etapa,
que restricciones se aplican (de tiempo, coste, objetivos, etc.),
como se integran las actividades de gestin y control.
Existen muchas metodologas ampliamente extendidas, aunque tambin
hay muchas empresas que desarrollan su propia metodologa o adaptan alguna
ya existente. Entre las ms utilizadas podemos distinguir entre aquellas
oficiales, patrocinadas por gobiernos, como:
Mtrica (Espaa);
Merise (Francia);
SSADM (Reino Unido),
y las no oficiales, desarrolladas por universidades, empresas, expertos, etc.
Por ejemplo:
YOURDON;
UN1FIED PROCESS (Roumbaugh, Booch, Jacobson).
CA PTU LO 7: FASES D E UN PRO Y ECTO 101
7.5 ACTIVIDADES DE DESARROLLO, SEGUIMIENTO Y
CONTROL
Dentro de las actividades propias de la fase de desarrollo, podemos distinguir
(siguiendo la ISO 12. 207) los siguientes procesos:
Proceso de adquisicin, que consiste en realizar las actividades de la
organizacin que adquiere un sistema o producto software, que
incluye la peticin de propuestas y el seguimiento del suministro.
Proceso de suministro, en el que se realizan las actividades de la
organizacin que proporciona un sistema o producto software, como
definir requisitos y comunicacin con el cliente y facilitar la entrega
del producto.
Proceso de desarrollo, que engloba las actividades de la organizacin
que define y desarrolla un sistema o producto software. Este proceso
se divide en las siguientes actividades:.
o Anlisis de requisitos del sistema,
o Diseo de la arquitectura del sistema,
o Anlisis de los requisitos del software,
o Diseo de la arquitectura del software,
o Diseo detallado del software,
o Codificacin del software y pruebas,
o Integracin del software,
o Prueba de cualificacin del software,
o Integracin de sistemas,
o Prueba de cualificacin del sistema,
o Ayuda a la aceptacin.
Proceso de documentacin, en el que se realizan las actividades para
registrar la informacin producida por cada proceso del ciclo de
vida.
Procesos de verificacin, validacin y revisin conjunta, en los que
se determina si el sistema cumple con los requisitos y el uso previsto,
evaluando junto con el futuro utilizador el estado y funcionamiento
del producto desde un punto de vista tcnico y gestiona!.
102 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Proceso de auditoria en el que se determina el grado en que se
cumplen los requisitos, planes y contrato, a peticin de alguna de las
partes.
Proceso de infraestructura para establecer y mantener la
infraestructura necesaria a los otros procesos (hardware, software,
herramientas, tcnicas, estndares, etc.).
Proceso de formacin para proporcionar y mantener un personal
formado, estableciendo perfiles y habilidades y programando
formacin adecuada y/o contratando personal.
En cuanto a las actividades propias de gestin a llevar a cabo durante la
fase de desarrollo, podemos denominarlas de Seguimiento y Control. Su
objetivo es vigilar la correcta evolucin de las actividades establecidas por la
planificacin. Algunas actividades de seguimiento y control son las siguientes:
Asignacin de trabajo a los miembros del equipo.
Gestin de incidencias (por ejemplo: retrasos, fallos del hardware,
bajas laborales, etc.)
Gestin de cambios en los requisitos: Por su gravedad, es el ltimo
recurso al que hay que recurrir para resolver un problema.
Actualizacin de la planificacin (replanificacin, si es necesario).
Gestin de la configuracin: Esta actividad puede ser considerada
fuera de las propias del seguimiento y control, segn el estndar ISO
12207, la importancia de esta actividad exige que exista un proceso
especfico de gestin de configuracin adems de un proceso de
gestin. Su objetivo es mantener la integridad de los productos que
se obtienen a lo largo de un proyecto, garantizando que no se
realizan cambios incontrolados y que todos los participantes en el
desarrollo del software disponen de la versin adecuada de los
productos que manejan. Dada su importancia tendr un captulo
especial en este libro.
C A P T U L O 7: F A S E S DE UN P R O Y E C T O 103
7.6 ACTIVIDADES DE FINALIZACION
Dentro de estas actividades estn las propias de desarrollo, que se encuadran en
el proceso de implantacin o puesta en produccin y las de gestin.
Detallaremos cada una de ellas.
La fase final dentro de la realizacin del proyecto corresponde a la
implantacin y aceptacin del sistema. El objetivo de esta fase es la entrega y
aceptacin del sistema en su totalidad y el paso a produccin del mismo. Para
ello se debe revisar la estrategia de implantacin que se haba previsto en la
planificacin inicial del proyecto. Las actividades previas al inicio de la
produccin comprenden la preparacin de la infraestructura, la instalacin de
los componentes, la definicin del futuro mantenimiento la formacin y del
futuro responsable, la definicin de los servicios de operacin y al cliente, la
estrategia de transicin del sistema antiguo al nuevo (si es necesario) y la
migracin o carga de datos (si es necesario).
Apartado especial, de gran importancia en esta fase, son las pruebas de
implantacin y aceptacin. Las primeras deben controlar aspectos tales como
las comunicaciones, la gestin del volumen real de datos en produccin, los
tiempos de respuesta, seguridad, interfaces, etc. Respecto a las pruebas de
aceptacin, estas se realizan por y para los usuarios. Tienen como objetivo
validar formalmente que el sistema se ajusta a sus necesidades.
En cuanto a las actividades de gestin su objetivo es dar por concluido el
proyecto (una vez aceptado por el usuario). Podemos destacar, dentro de las
actividades de finalizacin del proyecto, las siguientes:
Registrar (archivar) toda la informacin (documentacin), de forma
accesible para futuros proyectos.
Realizar el balance final del proyecto. Es importante detallar y
discutir con todo el equipo de proyecto: las desviaciones, los
problemas, y las soluciones tomadas.
7.7 OPERACIN Y MANTENIMIENTO
Estas fases corresponden al trabajo a realizar una vez finalizado el proyecto
software, suelen incluirse en un proyecto separado de outsourcing y/o
mantenimiento, o en proyectos concretos para modificaciones y/o ampliaciones
del sistema.
104 P L A N IF IC A C I N Y G E S T I N l)H S IS T E M A S IN F O R M T IC O S C A P T U L O 7: FA SE S D E UN P R O Y E C T O 105

1990 60-70% Huff (1990)

La fase de operacin comprende las actividades de utilizacin del producto
software y soporte operativo a los usuarios. Especficamente debe: Aos 80 60% Pressman (1993)
1988 60-70% Port (1988)
Identificar y mitigar los riesgos operacionales (cancelaciones de
programas, fallos de red, etc.). 1980-1984 55% Pigoski (1997)
Operar con el software de acuerdo a los procedimientos 1984 65-75% McKee (1984)
documentados durante el proyecto (manual de explotacin).
1981 >50% Lientz & Swanson (1981)
Proporcionar soporte para resolver problemas de utilizacin y
peticiones de usuarios relativas a obtencin de listados, ejecucin de 1979 67% Zelkow'itz el al. (1979)
programas opcionales, etc.
1976 60% Lientz y Swanson (1980)
Proporcionar seguridad de que las capacidades del software (y del
sistema) son adecuadas para resolver las necesidades del usuario. Aos 70 34-40% Pressman (1993)
Identificar las necesidades de servicio en cuanto a recursos y
horarios. F ig u ra 7 .1 T abla tem poral d e p ro p o rci n d el co ste d e m a n ten im ien to respecto al
total.
Valorar la satisfaccin del cliente con el producto y el servicio.

La fase de mantenimiento consiste en obtener nuevas versiones del sistema
a partir de las peticiones que los usuarios realizan con motivo de un problema
detectado en el sistema o por la necesidad de una mejora del mismo. De forma
resumida, mantenimiento es el proceso de cambio de un sistema despus de
haberlo entregado.
Las tareas a realizar en la fase de mantenimiento se inician con la
recepcin de una peticin de mantenimiento. Es fundamental llevar un registro
de dichas peticiones para su control y posterior anlisis que obtenga datos
estadsticos de las peticiones recibidas y tratadas, el tiempo empleado, los
mdulos o subsistemas afectados, etc.

Las tareas de mantenimiento son las ltimas dentro del ciclo de vida del En el momento de registrar una peticin debemos establecer el tipo de
software, pero no las menos importantes. De hecho el mantenimiento del mantenimiento que se trata, entre los siguientes tipos:
software se ha convertido en la principal actividad en cuanto a recursos
necesarios y coste. Estadsticamente podemos decir que el coste de Correctivo. Cambios que corrigen errores del producto.
mantenimiento de un producto software a lo largo de toda su vida til supone Evolutivo. Cambios para cubrir nuevas necesidades del usuario o
ms del doble de los costes de desarrollo. El coste relativo del mantenimiento expansiones del sistema.
respecto al total del coste del software representa actualmente ms del 90% del Adaptativo. Cambios que afectan al entorno del sistema, como
total. La siguiente tabla nos ilustra segn estudios de diversos autores, en comunicaciones, hardware, gestor de bases de datos, etc.
distintos aos, como va aumentando a lo largo del tiempo. Perfectivo. Cambios que mejoran la calidad interna del sistema,
como reestructuracin del cdigo, optimizacin del rendimiento, etc.
ANO PROPORCION DEL AUTOR
COSTE DE
En contra de lo que podra parecer no es el mantenimiento correctivo el de
MANTENIMIENTO
mayor actividad, sino que la mayor parte del mantenimiento es del tipo
2000 >90% Erlikh (2000) evolutivo. El siguiente grfico muestra como se distribuye el esfuerzo total de
1993 75% Eastwood (1993) mantenimiento entre los distintos tipos.

1990 >90% Moad (1990)

1990 80% Frazer (1992)
106 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S

Perfectivo
5%
Correctivo
17%

Adaptativo Evolutivo CAPTULO 8 (

18% ^ ^ 81118^ 60%

F ig u ra 7.2 D istribucin d el e sfu erzo d e m antenim iento.

HITOS, DOCUMENTOS Y REVISIONES {

Siguiendo con las actividades de la fase de mantenimiento, despus de

registrada la peticin e identificado el tipo de mantenimiento y su origen, se
A partir de este momento trataremos de afinar la estimacin en los costos del (
determina el responsable de atenderla. Tras un estudio inicial se puede decidir
proyecto ya que esta actividad ofrece una base adecuada para un perfecto
no atender la pocin, en cuyo caso se notifica al usuario y se cierra la peticin.
control de gestin. Idealmente, estas previsiones presupuestarias, tienen que ,
Si la peticin sigue adelante se estudia la viabilidad y el alcance de la
basarse en unas especificaciones de producto perfectamente definidas. El grado
modificacin, analizando alternativas de solucin y eligiendo la ms adecuada.
de precisin conseguido en la estimacin conseguida determinar el elemento
Resultado del estudio anterior es la determinacin del plazo y la urgencia de la
riesgo tomado en las decisiones sobre los precios, as como la efectividad de
peticin. subsiguientes presupuestos sobre los costos de elaboracin del software y <
programacin de recursos. (
La definicin de la solucin incluye el estudio del impacto de esta en los
sistemas de informacin o mdulos afectados y la valoracin del esfuerzo y i
Tras esta introduccin, en la presente unidad temtica, nos proponemos el
coste necesario para la implementacin. A partir de aqui las tareas del proceso objetivo de definir y establecer la relacin de tareas y los hitos, entendidos
de desarrollo son las mismas que las de cualquier proyecto software: anlisis,
como una serie de actividades concluidas en unas fechas que deben de 1
diseo, construccin e implantacin. cumplirse, as como la documentacin tcnica que se ha debido generar. Por
otra parte el alumno deber comprender las tcnicas y documentacin de las
Por ltimo, y antes de la aceptacin del usuario es preciso establecer un
revisiones como elemento de control del avance del proyecto. (
plan de pruebas de regresin que asegure la integridad del sistema de
informacin afectado. Las pruebas de regresin tratan de eliminar el llamado
efecto onda, es decir, que los cambios realizados no introduzcan un
comportamiento errneo o no deseado en otros componentes no modificados.
8.1 ORDENAR LAS ETAPAS.
Esto significa que es necesario probar, no solo la modificacin realizada de
forma aislada, sino el sistema integrado con la nueva versin, verificando la
Tal vez se esperara en este momento un intento sobre la estimacin de costos,
correccin completa de todo el sistema, no solo de la parte directamente
pero antes de poder desarrollar esa actividad deberemos desarrollar una lista de
modificada.
todos los productos individuales. El objetivo en esta etapa es establecer la
clasificacin ms lgica de todos los trabajos que puedan preverse
La mejor forma de establecer una buena funcin de mantenimiento,
pretendiendo no producir omisiones.
efectiva y comprometida, pasa por el registro de forma disciplinada de las
peticiones, los cambios realizados y su documentacin que repercutir
Naturalmente, y segn crece la complejidad del proyecto, nadie puede
directamente en la calidad del sistema y en su mantenimiento futuro.
pensar que esta lista de trabajos la puede desarrollar el director del proyecto de
forma individual, sino que ser fruto de varias sesiones de trabajo con un grupo
que este formado por representantes de los distintos departamentos y que
provoquen intercambio de puntos de vista.
108 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Una vez comprometidos todos los expertos de las distintas reas afectadas
se podr comenzar a disear un eficiente plan de trabajo, para ello, un mtodo
consiste en establecer plazos de entrega parciales, al anlisis de estos plazos de
entrega parciales surgirn nuevos trabajos a realizar y as trabajando en espiral
se podr llegar a completar esas fases, al mismo tiempo se pueden ir plasmando
en un primer esbozo de red sin atender al grado de control que se realizar
posteriormente.
En primer lugar deberemos establecer la forma de ordenar las fases
fundamentales del proyecto para lo cual, el director del proyecto, deber prever
cualquier tipo de actividad que le facilite la correcta ejecucin del proyecto en
s, de esta forma crear tareas y las subtareas que las conforman con criterios
de orden en el tiempo para lo cual se ayudar por alguna de las metodologas
existentes en la empresa o en la comunidad cientfica.
Una fuente de ordenacin de las fases fundamentales puede ser la lista de
etapas que a nivel global se han de recorrer pues nos servir para establecer los
hitos1 del proyecto con sus posibles fechas tpe de ejecucin.
8.2 RELACIN DE TAREAS
Una vez que se han obtenido las fases fundamentales, para acometer el trabajo
de planificacin del proyecto, tendremos que obtener las tareas del proyecto,
entendiendo que una fase est formada por varias tareas. La forma de obtener
la lista de tareas puede ser de forma analtica, que son las formas conocidas en
ingeniera como de arriba abajo, o por tcnicas guiadas por fines que son las
ms utilizadas en las metodologas de construccin de sistemas, en el caso de
informtica. En cualquier caso lo que tendremos que contestarnos a preguntas
del tipo qu hay que hacer para establecer las fases necesarias para poder llegar
a realizar el proyecto. En este nivel trataremos de descomponer el proyecto en
tantas fases como niveles de control deseemos implementar y, a ser, posible, de
tal forma que cada fase corresponda a labores realizadas por el mnimo nmero
de personas posibles.
1 Real Diccionario de a Lengua Espaola: Del latn /id u s (fijo). Como sustantivo: Firme, Jijo.
Tambin se define como blanco o pimo adonde se dirige la vista o puntera para acertar el
tiro". En nuestro caso los Hitos son tareas a las que no se les asigna un plazo concreto pero que
marcan puntos de inters en el desarrollo dei proyecto.
C A P T U L O 8 H IT O S . D O C U M E N T O S Y R E V IS IO N E S 109
De momento no nos ocupamos con preguntas del tipo quin tiene que
hacerlo? Ya que es esta actividad la abordaremos ms tarde junto a un
establecimiento de niveles y cuentas para poder responder de los costes.
Es necesario que las tareas sean totalmente claras en cuanto a saber cuando
termina de tal forma que si en algn caso no se tiene idea clara de cuando
terminar se deber descomponer en tareas concretas mucho ms claras. En el
caso de obtener alguna tarea de duracin muy larga deberemos volver a
descomponerla en varias tareas ms cortas cuya finalizacin pueda ser
controlada temporalmente.
Existen algunas tareas que se pueden clasificar como recurrentes y que
algunas herramientas de ayuda a la gestin de proyectos nos ayudarn a crear y
a controlar con un mnimo esfuerzo por lo que tendremos que identificarlas
para que, por su repeticin, nos descargue de tareas de definicin en cada
momento de utilizarlas.
8.3 DEPENDENCIA ENTRE TAREAS
Una vez relacionadas las tareas nos queda determinar las dependencias entre
ellas. Estas dependencias nos guiarn en su ordenacin y planificacin. En la
tarea de identificar y documentar dependencias debemos distinguir cinco clases
diferentes:
Restricciones. Son los factores que limitan las opciones del equipo de
desarrollo y viene impuestas por el cliente o la direccin de la empresa
desarrolladora. Ejemplos de este tipo de dependencias puede ser el
lenguaje de desarrollo, el entorno hardware, el personal que formar el
equipo de trabajo, las fechas de entrega definidas por el cliente, el
calendario laboral, etc.
Supuestos. Son las decisiones que se toman en el momento de planificar
pero de las que no estamos totalmente seguros. Constituyen
suposiciones que estn directamente relacionadas con el riego del
proyecto y tiene una probabilidad de no cumplirse durante el desarrollo
del proyecto tal y como se definieron durante la planificacin. Ejemplos
de supuestos pueden ser la disponibilidad de un usuario experto durante
el desarrollo del proyecto, la disponibilidad de un ordenador en casa del
cliente, la disponibilidad constante del servidor de desarrollo (no habr
averas ni cortes de mantenimiento), la estabilidad del personal
110 P L A N IF IC A C I N Y G E S TI N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 8: H IT O S . D O C U M E N T O S Y R E V IS IO N E S 111

disponible, la 110 modificacin de la versin del software de base utilizar; las tareas se representan con una longitud proporcional a su duracin
durante el desarrollo, etc. mediante barras horizontales.

f;* CA Super P/ofc el - 1DESAROI S>

Dependencias obligatorias. Son las dependencias debidas a la propia rciifii tHr Vft Sffectu' rra-;h p>:\Aa VVrtaru _ |g } .,]
P5 \3 1 @ 3 1* 1+1
naturaleza del proyecto, normalmente debidas a aspectos tcnicos y no o t m a t f i:|C a b c .s r .r e s/A signaco ncs - J
?. /f it iw w
|? | R [tF I f l Icblc]

m 1.Oa
m i
j fjjjr | Mu [ Ak I fjfU
a decisiones de personas. Ejemplo de este tipo de dependencias pueden <%. M -
ser antes de probar un programa hay que tener su codificacin, antes de K x rr .r/i j
I-.
disear la estructura fsica de los datos hay que realizar el modelo E l*-: I7*-

L-r
lgico con el usuario, etc. ' i
J
{JC , i
; i ral

Dependencias discrecionales. Son las dependencias definidas pro el

r
15)
HurU-.
FHKt-4 Pktfony
equipo de proyecto. AI determinar estas dependencias se debe ser Mia

cuidadoso y no ponernos nosotros mismos condiciones que puedan HtK-taA'Mi'irads 'C .

( :
peijudicar el desarrollo del proyecto. Ejemplos de estas dependencias V :~i.

pueden ser la obligatoriedad de cumplimiento y uso de ciertas mtricas, to

normas o estndares, las limitaciones en el uso de personal que es Gim i

necesario para otras actividades de la empresa, el establecimiento de E .M|

una determinada secuencia de trabajo o la eleccin de un ciclo de vida E <ii<* ixrxrs!

tenrrri

por que ser ms fcil de controlar, etc. iT"' AA *!?

1 | Cretonadsnuitiisa i ' ~f ~' " |

F ig u ra 8.1 D iagram a d e G an tt o b ten id o con ayuda de S u p e rP ro je c t de CA.

Dependencias externas. Son las dependencias impuestas desde el
exterior debidas a otras empresas participantes que suministran
hardware o software o a otros proyectos con los que tenemos relacin.
Ejemplos de este tipo de dependencias pueden ser la necesidad del
hardware de explotacin para hacer las pruebas y que este no haya sido
todava suministrado, la rapidez de respuesta de empresas de soporte
ante averas o consultas, la existencia de un proyecto de modificacin
de una aplicacin con la que nuestro proyecto est desarrollando un
interfaz de comunicacin, la existencia de un proyecto de sustitucin
del actual sistema de gestin de base de datos que utilizamos en nuestro
proyecto.
8.4 DIAG RAM AS DE G ANTT
Como en el caso de las fases, nuevamente tendremos que ordenar las tareas, y
entre todas las tcnicas conocidas en planificacin de proyectos, la ms
conocida y utilizada es la utilizacin de los diagramas de Gantt (vase la figura
8. 1 ), cuadro de doble entrada donde el eje de abscisas representa el tiempo
desde el inicio del proyecto y las ordenadas representan las tareas o recursos a
En un principio no nos preocuparemos mucho de la duracin de las tareas,
de sus fechas de comienzo y final ni de los recursos asignados a las mismas: lo
importante es describir el mayor nmero de tareas, asignarlas a cada fase y
tener una lista con todas ellas. Una vez obtenida la lista de tareas las
ordenaremos jerrquicamente quedando el orden como fases, tareas y
subtareas.
Un primer anlisis de este posible diagrama de Gantt nos servir para
estimar el nmero de recursos a utilizar en la planificacin y gestin de los
proyectos que podamos realizar entendiendo que esta tcnica, a no ser que se
realice con ayuda de un ordenador, nicamente sirve en proyectos pequeos o
que comprometen un pequeo nmero de tareas.
Seguidamente tendremos que decidir en qu condiciones se puede realizar
cada una de las tareas; es decir, si dependen o no de tareas predecesoras. El
control de las tareas que influyen sobre otras es importante porque impone una
serie de restricciones al programa de planificacin del proyecto. En este sentido
tenemos que definir qu tareas son predecesoras de otras y cules son
sucesoras de las mismas. Esta restriccin servir para que cuando se produzcan
situaciones de conflicto, porque algunas actividades se retrasen ms all de lo
112 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
establecido, el director pueda tener un soporte para su toma de decisiones a
implementar para tratar de atajar la desviacin.
El tipo de informacin que necesita el gestor del proyecto puntualmente
ser del tipo En qu afecta el retraso? Qu sucede si esta tarea finaliza antes
de lo que inicialmente estaba planificado? Si tal tarea se retrasa en cunto se
retrasa todo el proyecto? Cmo afectar econmicamente al desarrollo?.
Como puede adivinarse el nmero de controles a establecer en la ejecucin del
proyecto puede desbordamos si no sigue una tcnica apropiada y es necesario
informar correctamente de los condicionantes de cada tarea para poder
adelantarnos a la multitud de cuestiones que necesitaremos responder para que
el efecto de un incidente no altere, o altere de forma mnima, la ejecucin del
proyecto.
Las relaciones entre tareas se definen a travs de vnculos. Estos vnculos
nos permiten definir en qu condiciones puede comenzar una tarea respecto a
otra; por ejemplo, no podremos probar un mdulo de programa mientras ste
no est compilado. En este sentido una tarea que est vinculada a otra anterior
se denomina sucesora y la primera, respecto a la segunda, sucesora. Con estos
vnculos definimos que una tarea no puede comenzar si la predecesora no ha
finalizado quedando el concepto anterior o posterior relegado a otro nivel. Es
decir el orden de ejecucin de algunas tareas no tendr necesariamente nada
que ver con el orden definido por los niveles de vinculacin.
Hemos empleado el trmino finalizado como momento en el que puede
comenzar la tarea sucesora para un mejor entendimiento del tema, sin embargo
el orden de vinculacin puede ser de los siguientes tipos:
Final a comienzo
Comienzo a comienzo
Final a final
Comienzo a fin
El primer caso de los anteriores es el ms normal y marca que la actividad
sucesora podr comenzar cuando de haya finalizado la actividad predecesora;
por ejemplo para instalar el sistema operativo de un ordenador es necesario que
previamente se disponga del ordenador. En los diagramas de Gantt, este tipo de
vnculos se representan por una flecha que tiene por origen el final de la barra
de la tarea precedente, y como destino el principio de la tarea sucesora.
Es posible que varias actividades puedan comenzar al mismo tiempo o con
un intervalo mnimo entre ellas. Lo importante es que conceptualmente se
C A P T U L O S H IT O S . D O C U M E N T O S Y R E V IS IO N E S 113
tenga claro que la segunda de ellas 110 puede comenzar hasta que comience la
precedente. Un ejemplo podra ser el hecho de poder cargar programas en una
mquina a partir del momento en que se activen las lneas de comunicaciones.
Se representa por una flecha que parte del inicio de la tarea precedente hacia el
inicio de la sucesora.
Los vnculos definidos de final a final se establecen cuando se quiere
indicar que una tarea precedente no puede finalizar antes que la sucesora. Por
ejemplo, no se puede realizar la entrega de un mdulo software sin que el
cliente formalmente lo recepcione. La representacin grfica en el diagrama de
Gantt se realiza con una flecha que parte del final de la barra de la tarea
predecesora y que finaliza al final de la barra de la tarea sucesora.
Finalmente, el caso de vnculo de comienzo a final depende el final de la
predecesora con el comienzo de la sucesora. La representacin grfica, en este
caso, consiste en fijar el inicio de la flecha al principio de la barra de la tarea
predecesora, y el final de la flecha al final de la barra de la tarea sucesora.
Una vez definidos todos los vnculos podemos obtener un diagrama de
Gantt que nos orientar en una planificacin inicial de las tareas a realizar an
no sometido a las restricciones de los recursos a emplear.
8.5 LOS HITOS Y SUS FECHAS LMITE.
Con la descomposicin del proyecto en fases con su duracin de trabajo
deberemos ver si esta primera estimacin es suficiente para lo cual marcaremos
sobre el diagrama los hitos que deben de cumplirse en cada fecha de tal forma
que se podamos considerar, en al caso de no disponer de tiempo suficiente, que
tareas se debern acortar a base de dedicar mayor nmero de recursos. Esta
labor nos permitir establecer un primer paralelismo de tareas para poder
acortar la duracin del proyecto. An no sabemos cundo debe de efectuarse
cada una de las tareas, hemos establecido los prerrequisitos en forma de
vnculos y, ahora, debemos estudiar el calendario del proyecto.
Los hitos los introduciremos como tareas de duracin nula, pero al fin y al
cabo se debern considerar como una tarea ms con algunas consideraciones
respecto a cundo debe de comenzar o terminar. En el fondo lo que vamos a
imponer es una nueva serie de restricciones al proyecto para que el programa
que se utilice nos ayude a tomar decisiones ya que, al final, los proyectos se
plantean, o bien para terminar en una fecha dada o para comenzar a partir de

114 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
una fecha concreta, y esto condiciona los recursos ya que se pueden programar
para finalizar lo ms tarde posible dentro del tiempo del proyecto.
En este sentido definiremos una serie de delimitadores que nos ayudarn a
encuadrar el proyecto dentro de un calendario concreto:
LMPI: La tarea debe comenzar "lo ms pronto posible"
LMTP: La tarea debe comenzar "lo ms tarde posible"
Empezar en: El inicio de la tarea es fijo Empezar Antes: El inicio de la
tarea se programa LMPP y puede retrasarse por precedencia o por
nivelacin slo hasta la fecha de inicio obligado.
Empezar despus: La tarea se retrasa hasta la fecha obligada de inicio,
aunque tambin se puede retrasar despus por precedencia o nivelacin.
Es til en tareas en las que se conoce la fecha mnima de inicio
permitida.
Empezar antes de: La tarea se retrasa hasta la fecha obligada de inicio,
aunque tambin se puede retrasar despus por precedencia o nivelacin.
Es til en tareas en las que se conoce la fecha mnima de inicio
permitida.
Acabar en: El final de la tarea es fijo; debe terminar necesariamente en
la fecha de fin obligado, y no puede sufrir retrasos posteriores por
precedencias o nivelacin.
Acabar antes: La tarea comienza LMPP y puede sufrir retrasos por
precedencia o nivelacin slo hasta que su final alcance la fecha de Fin
Obligado.
Acabar despus: La tarea se retrasa hasta que su final concuerde con la
fecha lmite obligada.
Trabajar entre: La tarea se retrasa hasta la fecha obligada de inicio, y
se puede retrasar posteriormente por precedencia o nivelacin, pero
slo hasta que su final alcance la fecha de Fin Obligado.
De momento no hemos asignado recursos a cada tarea del proyecto. Esto
lo efectuaremos en el captulo once donde obtendremos una planificacin
detallada del tiempo y del coste
Mas adelante estudiaremos otras tcnicas de anlisis
optimizar la planificacin del tiempo, pero, an utilizando
conviene presentar el grfico de Gantt obtenido con otros
facilidad de interpretacin entre todo el personal comprometido
(
C A P IT U L O S: H IT O S . D O C U M E N T O S Y R E V IS IO N E S
Es necesario tener en cuenta que la mayor parte de las herramientas
informticas de ayuda a la gestin de proyectos, facilitan informacin relevante
sobre las desviaciones que pueden producirse en el desarrollo del calendario
del proyecto, y que, gracias a su fuerte potencia de clculo, permite estimar
objetivos rpidamente en el sentido de solucionar respuestas a preguntas de la
forma qu pasa si...?
8.6 DIAGRAM AS DE CARGA.
Partiendo del diagrama de Gantt es posible obtener una representacin grfica
del uso de un determinado recurso en un proyecto. Este tipo de representacin
se denomina diagrama de carga del recurso. Es muy til para:
Comunicar a los participantes el uso de un recurso compartido que
puede ser crtico, como el administrador de las bases de datos o el
usuario experto.
Verificar que se utiliza de forma equilibrada a lo largo del tiempo.
Verificar que no se utiliza ms de lo posible, es decir su carga sea
superior a sus horas de dedicacin al proyecto o vaya ms all del
momento en que termina su dedicacin al proyecto.
Ejemplo 1: A partir del siguiente diagrama de Gantt que refleja el
tipo de recurso y la cantidad necesaria en cada actividad
(A=Analista; P=Programador) se desea ver la asignacin de
programadores a1proyecto:
de redes para
otras tcnicas,
medios por su
en el proyecto.
116 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
En primer lugar se deben seleccionar aquellas tareas que utilicen el
recurso a estudiar. En nuestro ejemplo estn marcadas con una P.
A continuacin obtenemos el diagrama de carga de la necesidad del
recurso en el tiempo. Para ello sumamos por periodos la cantidad de
recursos que necesita cada tarea que debe desarrollarse en ese periodo.
En este diagrama el eje horizontal representa el tiempo, en este caso
meses, y el eje vertical representa la necesidad del recurso, en este
caso el nmero de programadores, aunque tambin es muy habitual
representar las horas o das de dedicacin del recurso.
Ejemplo 2: Se decide iniciar un proyecto de desarrollo de un sistema
software integrado en otros sistemas existentes y se detallan las
actividades iniciales del proyecto que sern llevadas acabo por el jefe
de proyecto, un analista encargado de definir los requisitos y otro de
la especificacin del proyecto. Se pide un diagrama detallado de las
actividades y la carga de los recursos para las actividades definidas.
Las actividades iniciales detalladas son las siguientes:
1. Se dedicar la primera semana a la firm a del contrato. El cliente
nos indica que solo estar disponible los lunes y los jueves. Esta
actividad se dividir en las siguientes tareas:
1.1. Reunin con el cliente (2 horas). Todo el equipo se rene con el
diente, para aclarar necesidades generales y concretar algo ms sus
objetivos.
1.2. Redaccin del contrato (7 horas). Todo el equipo escribe el
contrato aportando ideas obtenidas de la tarea anterior.
1.3. Revisin del contrato (2 horas). Todo el equipo revisa el contrato
escrito en la tarea anterior.
1.4. Aprobacin del contrato (2 horas). Todo el equipo presenta el
C A P T U L O 8: H IT O S , D O C U M E N T O S Y R E V IS IO N E S 117
contrato al cliente y se firm a definitivamente.
2. Las dos semanas siguientes se dedicarn al anlisis y especificacin
de requisitos. Esta actividad se dividir en las siguientes tareas:
2.1. Anlisis de requisitos con el cliente (2 horas). Todo el equipo
junto con el cliente comienza a analizar y valorar el sistema en
general y se prof undiza en algunos aspectos.
2.2. Reunin del equipo con miembros de otros proyectos
relacionados (4 horas). Despus de la tarea anterior, pero en distinto
da se lleva a cabo una reunin con los otros proyectos relacionados
para acordar ciertos aspectos comunes y de interaccin. Para esta
reunin interviene de nuevo todo el equipo, as como tambin
representantes de los otros proyectos.
2.3. Especificacin base de datos (11 horas aprox.). Para llevar a
cabo la tarea de la especificacin de la base de datos, se volvi a
reunir todo el grupo para decidir cual podra ser el mejor diseo para
ella.
2.4. Reunin del equipo con miembros de otros proyectos
relacionados sobre la base de datos (4 horas) A la vez que se realiza
la tarea anterior, se desarrolla esta otra tarea en el 2 o da de la tarea
anterior para corregir los posibles errores e intentar llegar a un
acuerdo sobre aspectos coincidentes y compartidos de a base de
datos. Interviene todo el equipo y miembros de los otros proyectos.
2.5. Especificacin protocolo de comunicaciones (4 horas aprox.)
Durante esta fa se todo el equipo trata el tema del protocolo de
comunicaciones.
2.6. Reunin del equipo con miembros de otros proyectos
relacionados sobre el protocolo de comunicaciones (5 horas). Se
vuelve a reunir todo el equipo con miembros de os dems proyectos,
para decidir aspectos comunes del protocolo especificado en la tarea
anterior.
2.7. Integracin interna de requisitos y especificaciones (aprox. 40
horas). Para llegar a la conclusin de este documento intervienen el
analista encargado de los requisitos (aprox. 15 horas) y el analista
responsable de la especificacin (25 horas aprox.).
2.8. Finalizacin de definicin del nuevo sistema (requisitos y
especificaciones (2 horas aprox.). Una vez que el documento est
finalizado, todo el equipo lo revisa.
El primer paso en la resolucin de este ejercicio es el diseo del
diagrama de Gantt de las actividades detalladas teniendo en cuenta lo
 (
(
P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 8: H IT O S . D O C U M E N T O S Y R E V IS IO N E S

siguiente: corresponde a la tarea 2.7 en la que participa el analista de requisitos

Suponemos que el horario laborar del personal es 8 horas durante 7 horas y de la especificacin durante 8 horas.
diarias.
Las actividades de las dos primeras semanas se pueden A continuacin se detallarn los diagramas de carga correspondientes
planificar con cierta libertad ya que su duracin es menor que a cada una de las personas que participan en las tareas anteriores:
el tiempo del que disponemos.
Podemos dejar un tiempo de holgura entre las actividades 1.1 y Analista de requisitos:
1.2 que podran comenzar una inmediatamente despus que la
otra. De esta forma consideramos posibles retrasos en la I
reunin inicial con el cliente ( 1 . 1 ).
- ...
La disponibilidad del cliente (lunes y jueves) nos condiciona
las actividades 1.1 y 1.4.
.....
La actividad 2.2 no puede empezar el mismo da de la
actividad 2.1 (posiblemente el cliente este en lugar distinto al
de trabajo del resto de proyectos).
La tarea 2.3 debe llevarse a cabo durante dos das, ya que el
segundo de ellos debe simultanearse con la tarea 2.4.
semana 1 semana 2 semana 3

1 2+4 3+2 2 2 4 7 4+4 4 s 8 7 2

1.3

Analista de la especificacin:
1.4
......
2.1
2.2
2.3 ............
....... ;..... - ... . . . .. . .
.........
2.4

2.5
- ...- .........
2.6 --- 1 .....-
2.7

2.8 i

semana 1 semana 2 semana 3

2+4 3+2 2 2 4 7 4+4 4 5 8+8 8+7 8 1+2

semana 1 semana 2 semana 3

2+4 3+2 2 2 4 7 4+4 4 5 8 8 8 1+2

Debajo de cada uno de los das que forman el eje temporal del
diagrama de Gantt se han detallado las horas de dedicacin de cada
da, separando si son de tareas distintas o de personas distintas. Por
ejemplo debajo del primer da de la primera semana aparece 2+4, que
corresponde 2 horas a la tarea 1.1 y 4 a la tarea 1.2. Tambin vemos
que debajo del tercer da de la tercera semana aparece 8+7 que
120 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O K: H IT O S . D O C U M E N T O S Y R E V IS IO N E S 121

Jefe de proyecto:
j
8 j
?
?
7 i
i 8.7 LA DOCUM ENTACIN TCNICA COMO HERRAMIENTA
6 !
DE SEGUIM IENTO DE LA PLANIFICACIN.
5

4 An siendo pronto para efectuar un seguimiento del proyecto conviene

3
preguntarnos acerca del cmo y a quin se ha debe de informar ya que una
actividad importante ser documentar todos los resultados obtenidos como
2
herramienta para el posterior control del proyecto. En este sentido es necesario
1
utilizar la planificacin no solamente para estimar coses y duracin, sino como
semana 1 semana 2 semana 3 herramienta viva de trabajo para controlar el desarrollo del proyecto. Si el
2+4 3+2 2 2 4 7 4+4 4 5 2 proyecto se est controlando efectivamente, se debern tener puntos de revisin
donde se observarn las posibles desviaciones entre lo previsto y lo realizado;
Cliente: en el caso de que hayan surgido desviaciones podemos volver a replantear el
diagrama para tratar de acercar el trabajo realizado al objetivo en un
a
determinado plazo, a su vez en las propias revisiones podemos ir desarrollando
7
la documentacin tcnica y administrativa para tener controlados tanto el
6 desarrollo del proyecto como los costes y duracin de los recursos empleados.
5
A nivel planificacin deberemos documentar cada una de las tareas con
;
datos adicionales a la duracin, la vinculacin con otras tareas, ya veremos que
tambin se documentar con los recursos empleados, pero adems deberemos
5
definirla con toda su extensin para poder disponer de un repositorio comn
1 para todo el proyecto. Muchos programas de gestin de proyectos nos permiten
semana 1 semana 2 semana 3 introducir texto libre, o incluso incrustar objetos como documentos Word o
2 2 2
Excel, dentro de los campos de notas de cada tarea pudiendo servir el propio
planificador como programa de gestin de la documentacin. La informacin
Delegados de otros proyectos: que aparece asociada a cada tarea se podr ir completando segn avanza el
propio proyecto.
6
7

5 8.8 REVISIONES Y AJUSTES A LA PLANIFICACIN.

4
Como consecuencia de la planificacin inicial se pueden producir conflictos
3
entre actividades. Puede suceder, por ejemplo, que una restriccin definida
2 ........... sobre una actividad haga que no se pueda satisfacer alguna otra; o incluso que
1 la cadencia de tareas haga que no se pueda cumplir un determinado hito que es
semana 1 semana 2 semana 3 fundamental para el logro del proyecto. En caso de que se produzcan estos
4 4 4 5 1+2
tipos de conflicto el director deber de analizar si su estrategia de solucin es
posible o si se ha confundido en la inclusin de restricciones.
122 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
En primer lugar deberamos pensarnos si una cierta limitacin establecida
es necesaria o, simplemente, es una conveniencia para mejor ejecucin del
proyecto. Si fuera as, y tiene conflictos con otras tareas (al fin y al cabo el liito
es una tarea) deber eliminar esa limitacin estudiando los cambios a
incorporaren la planificacin para que el proyecto se realice totalmente. Este
tipo de trabajos nos permitir ajustar la planificacin de una forma efectiva.
Otra solucin, si es que es posible, ser eliminar las fechas de terminacin
o la tarea a desarrollar en una fecha concreta para ensayar una estrategia de
solucin que sea efectiva para resolver el conflicto.
Volveremos a tratar este tipo de temas despus de asignar los recursos ya
que muchos conflictos se solucionan aadiendo mayor cantidad de recursos y
as acortar las tareas.
Los ajustes a la planificacin sern constantes y actuarn en forma de
espiral hasta lograr la mejor planificacin del proyecto.
CAPTULO 9
EL MTODO DE COSTES
En colaboracin con el Dr. Jos Javier Martnez Herraiz
Una vez fijado el escenario de las actividades necesarias para efectuar un
primer esbozo de la planificacin cronolgica del proyecto es el momento de
valorarlas. En la presente leccin el alumno aprender a utilizar una serie de
modelos para estimar el coste del proyecto tanto en tiempo como en dinero.
Cualquier tarea pasada por alto inadvertidamente durante el periodo de
estimacin, dar como resultado un menosprecio del proyecto en su totalidad,
este hecho, a su vez podra comprometer la planificacin del factor tiempo y de
los recursos que se deben utilizar y, lo que es peor, habr que pagar un trabajo
omitido, no en base al presupuesto, sino en base a los beneficios esperados.
Toda empresa con experiencia en la ejecucin de proyectos software debe
de elaborar unas listas de comprobacin para cotejar con las listas de trabajo
del propio proyecto para salvaguardar omisiones. Repetimos que cualquier
detalle pasado por alto en la fase del estudio del esfuerzo a aplicar puede tener
consecuencias importantes, no slo en la dimensin temporal del proyecto, sino
en la calidad del producto a obtener o en el calendario del propio proyecto.
Existen muchos estudios sobre las tcnicas de estimacin de costes, el
objetivo de la presente leccin no es presentar al alumno una descripcin de
todas y cada una de ellas, pero si de las ms utilizadas, por eso presentamos la
tcnica de los puntos funcin de Albrecht (IBM), el COCOMO (Constructive
Cos Method) de Boehm y la estimacin de Putman.
El ms utilizado es el de los puntos funcin de Albrecht cuya originalidad
proviene de estimar los costes en funcin de la complejidad de los aspectos
extemos, o funciones, del propio programa. Por otra parte est bastante
extendido el mtodo COCOMO de Boehm que se describe en su libro
"Software Engineering E c o n o m a s, y presenta una tcnica del modelo a tres
1 El ttulo del libro donde Boehm nos facilita un mejor conocimiento de su pretensin.
124 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
niveles segn la complejidad de los proyectos aportando herramientas para
controlar el coste, no slo del diseo y desarrollo del sistema, sino que cubre
todos los aspectos en la estimacin de todo el proyecto a lo largo de su ciclo de
vida, excepto el estudio de viabilidad, puesta en marcha y mantenimiento.
9.1 M O D E L O S EM PR IC O S
Una vez asentados sus conocimientos sobre las fases en que se divide un
proyecto software desde las perspectivas de los distintos paradigmas de la
Ingeniera del Software se considera, en lneas generales, que todo proceso de
desarrollo de software est compuesto por tres fases genricas que son:
definicin, desarrollo y mantenimiento, y en todos ellos tenemos que
considerar los modelos de estimacin de costes, que si bien en Informtica 110
son relativamente novedosos, ya que los primeros esbozos en estudiar este
problema comenzaron hace poco ms de dos dcadas, la implantacin real en
la industria no se ha realizado de forma masiva hasta que se ha dado el hecho
de que el software se ha convertido en el factor mas costoso de un sistema de
informacin; es ms: la desviacin producida por los costes de software en el
desarrollo de un proyecto tena poca incidencia en el coste total, cosa que no
ocurre hoy da ya que un error de estimacin del tiempo de desarrollo puede
colocar el proyecto entre el beneficio y la prdida econmica.
Los modelos de estimacin tienen aplicacin dentro de la fase de
definicin de un sistema software. En esta fase lo que se define es el qu, es
decir, se intenta identificar en ella qu informacin va a ser procesada, qu
funcin y rendimiento se desea, qu interfaces han de establecerse, qu
ligaduras de diseo existen y, por ltimo, qu criterios de validacin se
requieren para definir un sistema correcto.
Dentro de la mayor parte de las organizaciones, la estimacin de costes de
un sistema software est basada en experiencias pasadas. Los datos histricos
se usan para identificar los factores de coste y determinar la importancia
relativa de los diversos factores dentro de la organizacin. Lo anteriormente
expuesto implica que los datos de coste y productividad de los proyectos
actuales deben de ser centralizados y almacenados para su empleo posterior. La
estimacin de costes puede llevarse a cabo de forma jerrquica hacia abajo
(Top-Down) o jerrquica hacia arriba (Bottom-Up).
La estimacin jerrquica hacia abajo se enfoca primero a los costes a nivel
del sistema, adems de los costes del manejo de la configuracin, del control
C A P T U L O 9: E L M T O D O D E C O S T E S 125
de calidad, de la integracin del sistema, del entrenamiento y de la
documentacin. Los costes del personal relacionado se estiman mediante el
examen del coste de proyectos anteriores que resulten similares.
En la estimacin jerrquica hacia arriba, primero se estima el coste del
desarrollo de cada mdulo o subsistema, tales costes se integran para obtener
un coste total. La tcnica puede fallar al no considerar los costes del manejo de
la configuracin o del control de calidad, pero tiene la ventaja de enfocarse
directamente a los costes del sistema.
Podemos establecer una clasificacin de los llamados modelos empricos
de estimacin de costes basados en la experiencia:
Juicio de experto. E11 esta categora un experto o grupo de expertos
estudia las especificaciones y hace su estimacin (jerrquica hacia
arriba o hacia abajo) en base a sus conocimientos previos. Cuando hay
un nico experto se denomina juicio experto puro y la empresa corre el
riesgo de confiar una tarea tan importante a una nica persona. Si
desaparece el experto se deja de estimar. Si es un grupo de expertos el
que estima se suele utilizar el mtodo Delphi o juicio experto. Este
mtodo consiste en que el grupo se rene para dar sus opiniones sobre
la estimacin. Las conclusiones individuales se envan al coordinador
del grupo que las compara entre s. Si los resultados son parecidos la
estimacin se da por buena, si no es as cada estimador recibe
informacin sobre su estimacin, y las ajenas pero de forma annima.
Cada uno revisa su propia estimacin y la enva de nuevo al
coordinador. Se repite el proceso hasta que la estimacin converge de
forma razonable. Es posible realizar nuevas reuniones del grupo si el
coordinador lo considera oportuno segn la divergencia de las
estimaciones recibidas Tiene la ventaja de que las estimaciones de un
grupo suelen ser mejores que las individuales y que el experto nico no
se convierte en un recurso crtico imprescindible.
Analoga. Consiste en comparar las especificaciones de un proyecto,
con las de otros proyectos similares segn el tamao, complejidad,
nmero y tipo de usuarios y otros factores como sistemas operativos,
hardware, personal, etc.
Distribucin de la utilizacin de los recursos durante el ciclo de vida.
Este mtodo solo se puede aplicar cuando el proyecto ya ha comenzado
y se ha desarrollado alguna de sus fases. Usualmente las organizaciones
tienen una estructura de costes similar entre las distintas fases del ciclo
126 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
de vida (especificaciones, anlisis, diseo, construccin, prueba e
implantacin) de sus proyectos. Si en un proyecto ya hemos realizado
algunas fases, es de esperar que los costes se distribuyan de manera
proporcional en las fases siguientes.
Existen otros mtodos de estimacin emprica menos utilizados pero que a
veces se utilizan como soporte o en combinacin con otros. Entre ellos estn
Mtodo basado exclusivamente en los recursos. En la estimacin
consiste en ver de cuanto personal disponemos para el proyecto y
durante cuanto tiempo se dispone de l. Estos sern los recursos a
utilizar. Se basa en la siguiente premisa El trabajo se expande hasta
consumir todos los recursos disponibles (Ley de Parkinson).
Mtodo basado exclusivamente en el mercado. Parte de que lo ms
importante es conseguir el contrato. El precio se fija en funcin de lo
que creemos que esta dispuesto a pagar el cliente. La estimacin de
costes del proyecto ser el precio a pagar por el cliente menos los
beneficios econmicos que se desea obtener.
9.2 PUNTOS FUNCIN
Las Mtricas Orientadas a la Funcin se basan en estimar no el nmero de
lneas fuente del programa (LDC) sino su "funcionalidad". Estas mtricas,
propuestas inicialmente por Albretch en 1979 y 1983, intentan buscar un factor
de productividad del software mediante el mtodo denominado de anlisis de
los puntos funcin2. Los puntos de funcin se obtienen como consecuencia de
haber estudiado distintos proyectos de software y haber aplicado sobre ellos
una mtrica basada en la complejidad y el tamao de la funcin realizada.
La medida del punto funcin se ha aplicado con xito en sistemas no
empotrados y concretamente en sistemas comerciales y puede no ser relevante
en otros sistemas de ingeniera.
Las mtricas orientadas al tamao son bastante polmicas y no estn
aceptadas universalmente como el mejor mtodo para medir la productividad
en el desarrollo del software ya que el nmero de lneas de cdigo escrito no
parece una buena medida. Sus defensores dicen que esta medida es fcil de
2 El trmino en ingls es Function Point Anlisis (PFA).
C A P T U L O 9: EL M T O D O D E C O S T E S 127
aplicar y que puede ser calculada fcilmente en base a la experiencia y que
existe una gran cantidad de informacin basada en las LDC. Sus detractores
dicen que las LDC dependen del lenguaje de programacin, que perjudica a los
programas ms cortos pero mejor diseados y que su utilizacin requiere un
nivel de detalle que puede ser difcil de conseguir.
El anlisis de los puntos funcin se basa en establecer relaciones entre los
componentes bsicos de cada tarea y el esfuerzo requerido en desarrollarlos. El
procedimiento a seguir para calcular los puntos funcin consiste en ir
rellenando los datos de una serie de tabla, basada en la experiencia, en las que
se introducen algunos datos respecto a variables del proyecto como pudieran
ser el nmero de entradas, el nmero de salidas, la cantidad de ficheros que
trata la aplicacin, el tamao de los ficheros en nmero de campos, la cantidad
de consultas que se pretenden efectuar, etc. Cada uno de estos valores se
clasifica en tres categoras respecto a la complejidad que puede ser alta, media
o baja. Igualmente se establece una segunda dimensin en cuanto al tamao de
cada elemento, clasificndolos en pequeo, medio y grande. En ambas
clasificaciones siempre ser ms importante seguir criterios de consistencia
sobre criterios de precisin; es decir deber imperar el mtodo de clasificar en
grandes grupos todos los elementos de la configuracin.
Caso prctico: Creacin de una tabla para medir los puntos
funcin asociados al esfuerzo necesario para definir y documentar
los ficheros maestros y los grupos principales de datos del usuario:
Factor de tamao:
Pequeo: menos de 15 campos por registro
Medio: entre 15 y 50 campos por registro
Grande: ms de 50 datos por registro.
Esta clasificacin por tamao del registro en cuanto al nmero
de campos no debe confundirse con los datos que realmente tendr
el fichero en explotacin que se considerarn como aspectos
relacionados con el rendimiento que definiremos en la siguiente
clasificacin. EL orden actual define esfuerzos de creacin y
documentacin de registros, o tupias de bases de datos, desde el
punto de vista de su intensin, o esquema, y no de su extensin.
Factor de complejidad
Sencilla: un solo tipo de registro sin problemas de
rendimiento
128 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Normal: intermedia
Alta: varios tipos de registros y consideraciones de
rendimiento
Con el orden anterior tendremos un primer grupo, que
clasificaremos corno de complejidad sencilla, es el que se
aglutinar todo el esfuerzo para definir ficheros planos, es decir,
formados por un tipo de registro nico, y que no tiene problemas ni
de espacio, por ser pequeo el nmero de registros, ni de
volatilidad, por lo que no hay que hacer consideraciones
importantes en el rendimiento cuando sea accedido. Tendremos un
segundo grupo (complejidad normal), es similar al anterior pero
con un tamao de registros amplio, por lo que se debe de empezar a
considerar problemas en el rendimiento. Y, finalmente, un tercer
grupo que estara formado por los ficheros que deben de ser
estudiados cuidadosamente bien por que tengan varios tipos de
registros, porque sean muy voltiles, porque sean muy grandes o
porque se estime que deben de satisfacer una condiciones
especiales de rendimiento.
Una vez definidas las medidas a aplicar introducimos en
nmero de puntos que cuesta realizar cada funcin concreta
segn su tamao y su complejidad. Supongamos que nuestra
compaa dispone de alguna de ellas y tiene los valores sealados
en la figura siguiente (matriz de estimacin de pesos en el diseo
de ficheros).
Complejidad
Baja Media Alta
Tamao Pequeo 10 15 22
Medio 19 23 34
Grande 27 34 45
Para calcular el esfuerzo en disear y documentar los ficheros de nuestro
proyecto se estimar el nmero de ficheros segn el tamao y complejidad
concreta y se sumarn el nmero de puntos que cada fichero tiene segn dicha
tabla, as al final sabremos que el esfuerzo en disear y documentar los ficheros
es de a: puntos funcin que lo denominaremos xPF.
C A P T U L O 9: EL M T O D O D li C O S T E S 129
Esta misma labor se realizar para cada una de las tareas a satisfacer en
cada fase, se analizar el esfuerzo requerido en el anlisis del sistema, en la
determinacin de los requerimientos, en el diseo lgico del producto, en la
codificacin, en las pruebas de integridad y en la implementacin de tal forma
que al final tenemos el esfuerzo total en nmero de puntos.
Cuntas tablas de puntos funcin tendramos que utilizar para obtener la
estimacin? Depende del nivel de detalle y de la consistencia de la
organizacin que crea el software. De entrada se debera partir de pocos
modelos: es decir, se puede partir de una estimacin para ficheros o almacenes
de datos, de pantallas de entrada o consulta de datos, de los informes que se
producirn y de los tipos de procesos. Sobre estos modelos se incluirn todos
los esfuerzos adicionales no contemplados de tal manera que la suma total de
puntos funcin satisfaga la totalidad del esfuerzo.
Estudios posteriores al modelo de los puntos funcin incorporaron unos
parmetros de ajuste de toda la estimacin anterior a las caractersticas propias
de cada uno de los sistemas concretos a construir atendiendo a su complejidad.
Estos pueden ser, por ejemplo:
Requisitos especiales en comunicaciones de datos
Valoracin del rendimiento global del sistema
Frecuencia de transacciones
Requisitos de operacin o de usuario final
Complejidad en los procesos internos
Facilidad de mantenimiento
instalacin en varias localizaciones distintas
Incorporacin de funciones distribuidas
Entrada de datos interactiva
Existencia de procesos de actualizacin on-line
Coexistencia de mdulos con otros sistemas
Otros aspectos a valorar
La formula para obtener el nmero de puntos funcin corregido es la
siguiente:
. 0,7 x F C ,.
PF = Lo, 65 + --------- ----------J X PF
bxii
130 P L A N IF IC A C I N Y G E S T I N D E SIS T E M A S IN F O R M T IC O S C A P IT U L O 9: E L M E T O D O D E C O S T E S

Donde b es el valor mximo del peso dado a los parmetros de ajuste que, por
tanto, tendrn un peso entre 0 y b\ FC es el valor asignado a cada uno de los n Pantalla de ay uda: Clasif como salida: MEDIA
factores de ajuste, y n es el nmero de factores de ajuste. Clasif como entrada: SIMPLE

As, si, por ejemplo, tuviramos un proyecto de 2.304 puntos funcin y Consideremos que la organizacin que realiza la estimacin utiliza
queremos aplicarle doce factores globales de ajustes con un valor mximo de los siguientes datos base en la aplicacin de! mtodo de puntos de
ocho puntos para cada factor de complejidad cuando se considera complejidad funcin:
muy alta para cada uno de ellos, cuatro puntos en el caso medio y cero en el
caso de mnima complejidad, obtendremos un abanico de posibilidades que Simple Media Compleja Total
irn desde 1.497,6 puntos funcin ajustados hasta 3.110,4 en funcin de los Cantidad X Peso Cantidad X Peso Cantidad X Peso
pesos dados a cada uno de los factores individuales de ajuste. Entradas X3 X4 X6
Salidas X4 X5 X7
Consultas X3 X4 X6
Ejemplo: Calcular los puntos de funcin de una aplicacin si se Fich.Intcr. X7 X 10 X 15
establecen as siguientes funciones y clasificacin de las mismas. Fich.Exter. X5 X7 X 10
Suponer que los factores de complejidad a utilizar son tres: Total puntos de funcin sin ajustar
posibilidad de mxima facilidad de cambios, entrada de datos
totalmente on-line y lgica de proceso interno de media complejidad: Las entradas de la tabla anterior tienen el siguiente significado
Entradas. Son todos aquellos procesos que hacen llegar
Archivos lgicos internos: datos a la aplicacin desde el exterior, desde un usuario u
Registro Productos: Clasificacin: SIMPLE otra aplicacin.
Registro Proveedores: Clasificacin: MEDIA Salidas. Son todos aquellos procesos que hacen legar
Registro Pedidos: Clasificacin: SIMPLE datos desde a aplicacin hacia el exterior, a un usuario o
a otra aplicacin.
Archivos de interfase externa
Consultas. Son todos aquellos procesos que estn
Histrico Pedidos: Clasificacin: SIMPLE
formados por una combinacin de entradas y salidas,
Contraseas: Clasificacin: SIMPLE
produciendo una consulta a los datos. La complejidad de
la consulta viene dada por la mayor entre la entrada y la
Entradas
salida.
Alta de Productos: Clasif: SIMPLE
Ficheros internos. Es un grupo de datos relacionados, tal
Modificacin Productos: Clasif: SIMPLE
como los percibe el usuario y que son mantenidos por la
Eliminacin Productos: Clasif: SIMPLE
aplicacin.
Ficheros Externos. Es un grupo de datos relacionados, tal
Salidas
como los percibe el usuario, referenciados por la
Listados por Productos: Clasif: MEDIA
aplicacin y que son mantenidos p o r otra aplicacin.
Listados por Proveedores: Clasif: MEDIA
A los factores de ajuste se les da una puntuacin de 0 (bajo) a 5
Consultas
(alto).
Consulta Productos: Clasif como salida: SIMPLE
Clasif como entrada: SIMPLE
Consulta Proveedores: Clasif como salida: SIMPLE
____________ ___________C lasif como entrada: MEDIA____________

.1
132 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 9: E L M T O D O D E C O S T E S 133

Existen otras medidas posteriores debidas a Symons en 1991 y a otros

En funcin de los datos anteriores y contando las funciones de la autores que tratan de seguir ajustando la estimacin a la realidad de los
aplicacin el clculo de puntos de funcin sin ajustar sera el proyectos desde el enfoque funcional.
siguiente:
Dependiendo del nmero de factores de complejidad que se vayan
introduciendo se les da un peso mximo a cada uno de ellos para que el valor
Simple Media Compleja Total resultante no se desve del valor absoluto en ms de un 35%, as, por ejemplo si
Cantidad x Peso Cantidad x Peso Cantidad x Peso se les diera un valor entre 0 y 10 a cada factor de complejidad y fueses doce los
Entradas x3 0 x4 0 x6 factores de complejidad distintos
Salidas x4 x7 10
Consultas x3 x4 x 6
Fich. Inter. x7 x 10 x 15 24
Fich.Exter. x5 0 x7 x 10 10 9.3 D IST R IB U C I N P O R C E N T U A L D E L ESFU ER ZO
Total puntos de funcin sin ajustar 64
Un mtodo empleado por muchas compaas es el basado en la distribucin
Los puntos de funcin ajustados se calcularan dando un valor de porcentual del trabajo que se emplea en organizaciones donde el tipo de
5(mximo) a posibilidad de facilidad de cambios y entrada de datos proyectos software que realizan son muy homogneos y se basa en tener
on-line y de 3(medio) a la complejidad de la lgica de proceso interno. estadsticas muy actualizadas de los tiempos medios en satisfacer cada una de
Aplicando la frmula: las fases del proyecto.

PFA = (0,65+((0,7x(5+5+3))/(5x3)))x64 = (0,65+((0,7xl3)/15))x64 =
(0,65+0,60)x64 = 80
Los factores de ajuste, e incluso la forma de asignar los pesos de los
puntos funcin, pueden ser responsabilidad de cada una de las empresas, sin
embargo, en 1984, el International Function Point Users Group3, emiti un
primer documento oficial para intentar normalizar el uso de los mismos valores
en la comunidad de desarrolladores de proyectos que se ha ido actualizando a
lo largo del tiempo.
Posteriormente Jones, en su libro Programming Productivity propone
una equivalencia entre puntos funcin y lneas de cdigo fuente producidas
segn cada lenguaje de programacin empleado; de esta forma se puede
estimar, por ejemplo, que cada punto funcin oficial equivale a 91 lneas de
cdigo fuente en Cobol ANSI. En este sentido se puede llegar a establecer una
equivalencia entre puntos funcin y lneas de cdigo fuente pudindose, por
tanto, estimar el esfuerzo en ambas medidas.
En nuestro caso, y segn experiencias anteriores, se sabe que la media de
nuestros ltimos trabajos ha supuesto que la fase de diseo supone un
porcentaje del tiempo total invertido en cada proyecto con independencia del
tamao, y cada una de las fases se distribuye segn el porcentaje expuesto. Con
estos criterios se puede estimar, por medio de la extrapolacin, la duracin total
del proyecto cuando se ha ejecutado alguna de sus partes.
Este mtodo tiene serios inconvenientes, sobre todo cuando los proyectos
no son del mismo tamao, ya que no es normal que se disponga de tablas
adecuadas para cada tipo de proyecto suficientemente actualizadas. No
obstante se utiliza bastante como control de validez del mtodo de los Puntos
Funcin de Albretch, sobretodo cuando se comparan los porcentajes de ambos
mtodos, ya que nos puede ayudar a estudiar dnde se producen las mayores
desviaciones por si se trata de errores de clculo o si se han omitido alguna de
las fases.
Para efectuar esta comparacin se tabulan sobre una hoja de clculo los
resultados de cada fase del ciclo de vida y se decide estudiar a detalle aquellos
hitos que tengan una desviacin superior al 15%.

3 En la URL: wAvw.untug.org se puede obtener info rm aci n adicional

1
134 P L A N IF IC A C I N Y G E S T I N D B S IS T E M A S IN F O R M T IC O S C A P T U L O 9: E L M T O D O D E C O S T E S 135

Una posible tabla de comprobacin de los esfuerzos necesarios para la procesos establecidos en la mayor parte de las metodologas de desarrollos de
construccin de software, obtenida por mtodos estadsticos, de una compaa sistemas informticos clsicas. Las fases que cubre el modelo de Boehm son
podra ser la siguiente: todas las descritas en el ciclo de vida de productos software con la excepcin
del estudio de la viabilidad y el anlisis de requerimientos, los cuales se
estiman como un apartado cuantitativo del software de desarrollo. Sin embargo
FASE Esfuerzo
si se incluyen todos los costes incurridos en cada fase
FASE DE 20%
DISEO
Definicin de requisitas 8%
COCOMO es el modelo emprico para la estimacin de los costes de
Orientacin 4,6% produccin de software ms utilizado por los equipos de desarrollo de sistemas
Definicin de requisitos 3,4%
informticos de tamao grande, sin embargo, se deben tener en cuenta los
Diseo del sistema 12%
Diseo externo 7% propios comentarios de Boehm sobre COCOMO y por extensin sobre todos
Diseo interno y 5% los modelos: "Hoy en da, un modelo de estimacin de costes est bien
planificacin
Diseo interno 4% realizado si puede eslimar los costes de desarrollo de software dentro del 20%
de los costes reales, del 70% del tiempo y en su propio cam po (o sea dentro de
Planif. de la 1%
implantacin los tipos de proyectos en los que ha sido calibrado). Esto no es tan preciso
FASE DE 80% como quisiramos, pero es lo suficientemente preciso para proporcionar una
IMPLANTACIN
Desarrollo de programas 69%
buena ayuda en el anlisis econmico de la ingeniera del software y en la
Diseo en detalle y 11% toma de decisiones
orientacin
Orientacin 2%
Diseo en detalle 9% Boehm considera que la funcin de distribucin de Rayleight, definida
Codificacin 12%
como:
Pruebas de unidades 22%
Integracin y pruebas de 14%
K -ttt
subsistemas E s fuerzo = r t e ~
Pruebas y demostracin 12%
del sistema
Documentacin de usuario 19%
donde tj es el momento en el que se introduce un esfuerzo mximo, es un
F ig u r a 9.1 E je m p lo d e lista d e c o m p r o b a c i n d e l e s fu e rz o estimador exacto para los requisitos de personal para el ciclo de vida del
desarrollo (desde el diseo arquitectnico hasta las pruebas del sistema siempre
que usemos la porcin de curva entre 0,3td y 1,7 tj ).

La representacin grfica de la funcin de distribucin de Rayleight se

9.4 M O D ELO CO C O M O 4 muestra en la figura 9.2.

El COCOMO es un modelo de costes, descrito por Barry W. Boehm en 1981

de tipo algortmico que proporciona estimaciones directas tanto de la duracin
como del esfuerzo que est basado en la cantidad de lneas de cdigo fuente
escritas en la totalidad del proyecto5. Se trata de un modelo de estimacin
emprico que est basado en el paradigma del ciclo de vida clsico o modelo en
cascada. Boehm se basa para el desarrollo de su modelo en los diagramas de

4 Constructive COst MOdel

5 Se emplea la notacin LDC para hacer referencia a las lneas de cdigo o su traduccin en
ingls DSI, D elivered Source Instructions. En proyectos grandes se emplea el multiplcador K
para hacer referencia a riiiles de lneas de cdigo fuente.
136 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Antes de abordar el modelo propiamente dicho, es preciso enumerar una
serie de definiciones y consideraciones en las que se basa Boehm para el
desarrollo del modelo, como son:
El clculo del coste primario est basado en el nmero de instrucciones
fuentes desarrolladas en el proyecto sin incluir las lneas de
comentarios, pruebas, documentacin, etc., a no ser que se escriban con
un fin expreso y cuidado.
El periodo de desarrollo cubierto por el modelo comienza al iniciarse la
fase de diseo y termina al finalizar la fase de integracin y prueba. El
coste y calendario de otras fases se estiman por separado.
El modelo cubre nicamente las actividades indicadas dentro del equipo
de desarrollo de actividades o procesos del ciclo de vida. Por ello,
incluye el esfuerzo de organizacin y documentacin, pero excluye
algunos esfuerzos tales como la planificacin de la instalacin, esfuerzo
de conversin, etc.
Las soluciones se expresan en criterios de la forma hombres-mes
refirindose a 152 horas de tiempo de trabajo al mes desarrollado por
las personas del equipo de desarrollo. Este factor se ha calculado
teniendo en cuenta la experiencia en los distintos proyectos
desarrollados y considerando el tiempo de vacaciones.
El modelo considera que el proyecto es bien dirigido tanto por el
desarrollador del mismo como por el cliente, existiendo por ello muy
pocos tiempos perdidos en el anlisis de requerimientos del producto.
C A P T U L O 9: E l. M T O D O D E C O S T E S 137
Considera que la especificacin de requerimientos no tiene cambios
sustanciales despus de la fase de planificacin y requerimientos del
producto.
El modelo avanzado considera que la influencia de los factores
conductores de coste del software dependen de cada fase. Los otros
modelos slo hacen diferencias entre la etapa de desarrollo y la etapa de
mantenimiento.
El coste de cada fase incluye lodos los costes incurridos durante la fase.
Los costes de actualizacin del plan de integracin y prueba y la
aceptacin completa de los planes de prueba estn incluidos en la fase
de diseo detallado.
Para que se cumplan los criterios de estimacin del ciclo de vida del
desarrollo de software es necesario resaltar las siguientes caractersticas:
Se debe de prestar especial cuidado a la definicin y validacin de
la especificacin de los requerimientos software por un grupo de
personas relativamente pequeo con anterioridad a la entrada en la
fase de diseo.
Posteriormente se debe de someter la definicin y validacin del
diseo del sistema software a un grupo de personas algo ms grande
como actividad anterior a la entrada en la fase de diseo detallado y
de la codificacin.
El diseo detallado, la codificacin y las pruebas de unidades sern
desarrollados por un grupo grande de programadores trabajando en
paralelo, y siguiendo una lnea base slida que suponga un
desarrollo incremental de la planificacin.
La integracin y prueba de cada incremento en el sistema est
basada en una gran cantidad de planificacin de pruebas tempranas
y en la eliminacin de casi todas las unidades defectuosas por
medio de cuidadosos y completos recorridos de las unidades
desarrolladas.
Una parte importante del esfuerzo de documentacin (por ejemplo
los borradores de los manuales de usuario) se desarrollarn en fases
138 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
tempranas para proporcionar a los usuarios (y desarrolladores)
informacin acerca de la naturaleza operacional del producto.
A raz de lo expuesto, se puede deducir que la cantidad de personal
requerido para el desarrollo de un proyecto no es constante. Generalmente, la
planificacin y el anlisis lo realiza un grupo pequeo de personas, el diseo
arquitectnico un grupo mayor, aunque como hemos indicado, todava es
pequeo comparado con el personal que interviene en el diseo detallado, que
es un grupo ms numeroso generalmente. As mismo, la etapa inicial de
mantenimiento puede requerir un nmero elevado de personal, aunque este
nmero deber disminuir en poco tiempo, si no existen mejoras o adaptaciones
importantes, permaneciendo el nmero de personal asignado a esta etapa
pequeo y constante.
Por ello, Boehm considera que la curva de distribucin de Rayleigh es un
estimador razonablemente exacto de los requisitos de personal para el ciclo de
vida de desarrollo, desde el diseo arquitectnico hasta las pruebas del sistema,
siempre y cuando se use la porcin de la curva entre 0.3td y 1.7td. Esta
informacin la justifica Boehm en base a estudios anteriores de Norden (1970)
y Putnam (1978), que indican que el rea total bajo la curva Rayleigh es similar
o igual al esfuerzo requerido para el desarrollo del proyecto. Por ello, si se
representa el esfuerzo de desarrollo frente al tiempo se obtiene la curva de
Rayleigh de la Figura 9.3. Donde td es el tiempo correspondiente al valor
mximo del esfuerzo en la curva Rayleigh y K es el esfuerzo total desarrollado,
el cual es igual al rea bajo la curva.
Para ajustar mejor sus estimaciones Boehm creo tres escenarios de
estimacin clasificando su modelo de forma jerrquica y en base a la
complejidad y cantidad de informacin utilizada en la estimacin; a los que
denomin modelos COCOMO que son:
Modelo bsico
Modelo intermedio
Modelo avanzado
El modelo bsico es un modelo esttico, evaluado de forma nica y que
calcula el esfuerzo y el coste de desarrollo del software en funcin del tamao
del programa expresado en lneas de cdigo estimadas (DSI o LDC).
El modelo intermedio calcula el esfuerzo de desarrollo en funcin del
tamao del programa y un conjunto de guas de coste que incluyen una
C A P T U L O 9: E L M T O D O D E C O S T E S 139
evaluacin subjetiva tanto del producto, como del hardware, del personal y de
los atributos del proyecto.
El modelo avanzado incorpora todas las caractersticas de la versin
intermedia con una evaluacin del impacto de las guas de coste en cada fase
(anlisis, diseo, etc.) del proceso de ingeniera del software.
Igualmente, Boehm distingue tres tipos de modos de desarrollo en base a
las caractersticas del producto software, para cada uno de los modelos
anteriormente definidos:
Modo orgnico
Modo semiacoplado
Modo empotrado
El modo orgnico se emplea en proyectos relativamente pequeos y
sencillos en los que pequeos equipos de trabajo, con buena experiencia en la
aplicacin, trabajan en un conjunto poco rgido de requerimientos y en un
entorno casi familiar. Esto permite que mucha de la gente del proyecto pueda,
fcilmente, contribuir al desarrollo del mismo en las primeras etapas sin
generar muchas canales de comunicacin y muchos requerimientos de
bsqueda de informacin, ya que todo el entorno es bastante conocido por el
equipo de desarrollo. En los proyectos en modo orgnico es relativamente
sencillo reunir los requerimientos e interfaces de especificacin del software y
ponerlos a disposicin del equipo de desarrollo.
Otros factores caractersticos de los proyectos software en modo orgnico
son la existencia de un entorno de desarrollo generalmente estable, con muy
pocos desarrollos asociados a nuevo hardw'are y procedimientos operacionales
y con mnimas necesidades de innovaciones en la arquitectura del proceso de
datos y algoritmos. Adems existe un premio relativamente pequeo al
completar ms pronto el proyecto y medidas de los proyectos relativamente
pequeas. Muy pocos proyectos en modo orgnico desarrollan productos con
ms de 50 KLDC de software nuevo. Estos factores contribuyen a la alta
productividad de estos proyectos.
El principal factor que distingue al modo empotrado es la necesidad de
operar dentro de una serie de restricciones. El producto debe operar dentro de
unas restricciones rgidas de hardware, software y procedimientos
operacionales, tales como, por ejemplo, en un sistema de regulacin de trfico
areo. Debido a estas restricciones, los cambios posteriores que se tengan que
producir tienen un coste bastante grande. Generalmente, los proyectos en modo
140 PLANIFICACIN Y GESTIN DE SISTEMAS INFORMTICOS CAPTULO 9: EL MTODO DB COSTES 141

empotrado una vez desarrollados no tienen la opcin de hacer cambios en las

especificaciones de requerimientos y de interfaces. Por ello, estas etapas o
MODOS COCOMO
fases tienen que ser estudiadas y fijadas muy minuciosamente, pues cualquier CARACTERSTICAS
cambio de ellas supondra muchos cambios en el sistema, con el respectivo
incremento de sus costes. Orgnico Semiacoplado Empotrado

Experiencia en trabajar con EXTENSO CONSIDERABLE MODERADO

En los proyectos en modo empotrado se utiliza bastante tiempo en las Sistemas Software relacionados
primeras etapas. La estrategia a seguir es la de, una vez terminada la fase de Entendimiento organizacional de COMPLETO CONSIDERABLE GENERAL
los objetivos del producto
diseo, utilizar un gran nmero de programadores trabajando en paralelo para Necesidad de confonvudad del BASICO CONSIDERABLE TOTAL
desarrollar las etapas de diseo detallado, codificacin y prueba unidad. De software con los requerimientos
preestablecidos
otra manera el proyecto podra tardar mucho ms en completarse y ello no sera Necesidad de conformidad del BASICO CONSIDERABLE TOTAL
aconsejable porque el producto tendra que absorber muchos ms cambios y el software con las especificaciones
del interfase externo
producto podra ser acabado fuera de fecha. Desarrollo concurrente de nuevo ALGUNO MODERADO EXTENSO
hardware asociado y
El desarrollo de software en los modos semiacoplados representa una procedimientos operacionales
Necesidad de innovacin de MINIMA ALGUNA CONSIDERABLE
etapa intermedia entre el modo orgnico y el modo empotrado. Un proyecto arquitecturas de proceso de datos
software en modo semiacoplado debe ser intermedio en tamao y complejidad, y algoritmos
Premio por una finalizacin BAJO MEDIO ALTO
en el que equipos de trabajo con una mezcla promedio de gente experimentada temprana
e inexperimentada deben satisfacer requerimientos poco y medio rgidos. Con Rango de medidas de producto < 50 KDSl < 300 KDSl CUALQUIERA
Ejemplos Sistemas operativos Muchos sistemas de Grandes sistemas de
respecto a la conformacin de las especificaciones funcionales y a las Modelos cientficos procesamiento de procesamiento de
interfaces, un tpico proyecto en modo semiacoplado podra ser un sistema de transacciones transacciones
complejas
procesamiento de transacciones con algunas interfaces muy rgidas (p.e. con un Modelos gestin Control de produccin Sistemas operativos
terminal hardware o con requerimientos de manejo de auditorias) y algunas de inventarios grandes Rrandes
interfaces muy flexibles (p.e. con la naturaleza y formato de los mensajes de Intercambios simples Sistemas operativos y Mandatos de control
bases de datos nuevas complejos
pantalla y con los informes producidos). Esta flexibilidad parcial explica la
denominacin del trmino semiacoplado. La medida de estos proyectos es Figura 9.3 caracterizacin de los m odos de desarrollo
generalmente inferior a 300 KLDC. Una consecuencia de utilizar la estrategia Finalmente se establece un criterio para clasificar los proyectos en cuanto
de semiaclopamiento es que se retrasan los picos altos en la curva de personal, al factor tamao, de esta forma los proyectos quedaran clasificados, segn este
produciendo un consumo mayor del esfuerzo comparado con proyectos en aspecto, de la siguiente forma:
modo orgnico trabajando en calendarios de desarrollo similares.
FACTOR TAMAO LINEAS DE CODIGO FUENTE
En la figura 9.3 se resumen las caractersticas que distinguen a los distintos Pequeos Menores de 2000 LDCs
modos de desarrollo de software que considera el modelo COCOMO. Intermedios Entre 2000 y 8000 LDCs
Medios entre 8000 y 32.000 LDCs
Grandes entre 32.000 y 128.000 LDCs
Muy grandes entre 128.000 y 512.000 LDCs
Figura 9.4 Caracterizacin segn el fa c to r de tamao

Las ecuaciones de estimacin del esfuerzo para el COCOMO bsico y las

restantes ecuaciones de estimacin de los modelos COCOMO se obtienen por
medio del anlisis cuidadoso y minucioso de un muestreo de datos de
142 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 9: EL M T O D O D E C O S T E S 143

proyectos software. La tabla de la Figura 9.5 anterior resume la naturaleza de la La ventaja principal de estas bases de datos COCOMO es que todas las
base de datos COCOMO. entradas que se producen en ella son cuidadosa y consistentemente definidas
con respecto ai manejo de instrucciones fuentes deliberadas, estimaciones de
T am a o d e la m u e s tra P ro d u ctiv id ad (I.D C /M M J desarrollo, hombres-mes y otros datos parecidos.

B ase d e D a to s C o m p le ta 63 2 0 -1250 Una vez expuestas las lneas bsicas y generalidades del modelo de Boehm
para los tres tipos de modelos y, dentro de ellos, para cada uno de los modos de
M O D O : O rg n ic o 23 8 2 -1250 desarrollo podemos analizar las caractersticas particulares y las ecuaciones
S em i-ac o p la d o 12 4 1-583 utilizadas en las estimaciones.
E m potrado 28 2 0-667

Para el Modelo COCOMO bsico, el esfuerzo necesario medido en meses-

Tipo: N e g o cio s (g e s ti n ) 7 55-862
C ontrol 10 2 0-304 hombre (MM) estimados para el desarrollo del software, que incluye las fases
M aq u in a-h u m an a 13 28-336 del ciclo de vida consideradas en las definiciones y presunciones que Boehm
C ie n tfico s 17 4 7-1 2 5 0
S oporte 8 87-583 efecta para el desarrollo del modelo, y el tiempo de desarrollo de calendario
S istem as 8 2 8-667 (TDEV) se obtendra aplicando las siguientes frmulas:

A o d esa rro llo : 1 9 6 4 -6 9 3 113-775

1970-74 14 20-485 MODO . ESFUERZO CALENDARIO
1975-79 46 4 1 -1 2 5 0

Orgnico MM= 2.4 (KDSI)1'0 TDEV= 2,5(MM)0S

T ip o d e C o m p u ta d o ra : 31 2 8 -1250
M axi 7 114-583 Semiacoplado MM= 3.0 (KDSI)112 TDEV= 2,5 (M M )0 JS
M idi 21 20-723
M ini 4 41-3 7 9
M icro Empotrado MM= 3.6 (KDSI)1'-0 TDEV= 2,5 (MM)0

L en g u a jes de
P rogram acin: 24 28-883 F igura 9.6 E cu a cio n es de esfuerzo y tiem p o en C O C O M O b sic o
FORTRA N 5 55-862
COBOL 5 45-583
JO V IA L 4 9 3 -1250
PL/I 2 336-5 6 0 El modelo bsico es bueno por su facilidad y rapidez para la estimacin a
P A SC A L i 124-300 groso modo de los costes del software objeto. Pero su exactitud est muy
O tro s H O L 20 20-667
E n sam b lad o r
limitada debido a que ignora factores como las diferencias en las restricciones
en el hardware, la calidad del personal, la experiencia del mismo y el uso de
F igura 9.5 N a tu r a le za dela B ase d e D a to s C O C O M O original tcnicas modernas, adems de otros atributos del proyecto objeto de estudio
que tendrn una influencia significativa en la estimacin del coste.

Como se puede observar la distribucin de proyectos en la base de datos
del ejemplo no es totalmente representativa de la variedad actual de proyectos
software (p.e. no hay bastantes puntos de datos de proyectos en lenguaje CO
BOL) o de los probablemente futuros proyectos software, no hay bastantes
puntos de datos de desarrollos para microprocesadores). Sin embargo, posee al
menos algn punto representativo de todos los sectores principales del mundo
del software.
Una vez estimado el esfuerzo y calendario de desarrollo de un producto
desde el punto de vista del modelo bsico, pueden obtenerse otros datos sobre
el proyecto como pueden ser la productividad y el nmero de personal medio
que trabaja a tiempo completo, al cual Boehm ha denominado FSP6. Los
valores pertenecientes a estos datos se muestran en la Tabla 9.8 en la que
aparecen los tres modos de desarrollo del COCOMO bsico para las distintas
medidas estndares de productos.

6 Full-time-equivalent Sofware Personal.

(
<
144 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 9; E L M T O D O D E C O S T E S 145
( --------------------------------------------------------------------------------------------------------------------------------------------------

/ El calendario, estimado como una funcin de la medida del

(Pequeo) (In terni ed) (M edio) (G rande) (Muy
2 KDSI 8 KDSI 32 KDSI 128 KDSI grande) producto, es parecido o el mismo para los tres modos de desarrollo.
< MODO
512 Para proyectos software que requieren la misma cantidad de tiempo
(
KDSI de desarrollo, los proyectos en modo empotrado necesitarn mayor
f
ESFUERZO (MM) esfuerzo que el resto de los modos de desarrollo.
Orgnico 5.0 21.3 91.0 392.0 N.C.
<
Scm acoplado 6.5 31.0 146.0 687.0 3250.0
La tabulacin de las estimaciones de COCOMO bsico para medidas
( Empotrado 8.3 44,0 230 1216.0 6420.0 estndares de productos se ha representado en la Tabla 9.8.
(
PRODUCTIVIDAD (DSV/M M ) M E D ID A S ; (P e q u e o ) (In te rm e d io ) (M e d io ) (G ra n d e )
f j . 2 KDSl S KDSI 32 K D S I 128 K D S I

352
Orgnico 400 376 219 327 N.C. E s f u e r z o to ta l ( M M ) ? 5.0 213 91 39 2
Seiniacoplado 308 258 139 186 158 P la n ific a c i n y re q u e rim ie n to s ! 0.3 1.3 ;.0 24
D is e o del p ro d u c to ; 0 ,8 3,4 15 63
( Empotrado 241 182 105 80
D is e o d e ta lla d o 1,3 5,3 22 90
C o d ific a c i n y p ru e b a unidad 2,1 8,5 34 141
(
C ALENDARIO (TDEV) In te g ra c i n y p ru e b a s ! 0 .8 4,1 20 98
(

C a l e n d a r l o t o t a l (m e s e s ) > 4 ,6 8,0 ,0 24
Orgnico 4,6 8.0 14,0 24,0 N.C.
P la n ific a c i n y re q u e rim ie n to s 1 0 V5 0,9 1,7 3,1
Semiacoplado 4,8 8,3 14.0 24,0 42,0 D is e o del p ro d u c to | 0 ,9 1,5 2 .7 4 ,6
Empotrado 4,9 8.4 14,0 24,0 41,0 P ro g ra m a ci n j 2 .9 4,7 7.7 12,2
s In te g ra c i n y p ru e b a \ 0.8 1.8 3 ,6 7,2

PERSONAL P e r s o u a l m e d io ( F S P ) j
MEDIO P la n ific a c i n y re q u e rim ie n to s j 0,< 1,4 2 ,9 8 ,0
(FSP) D is e o del p ro d u c to \ 0 ,9 2,3 5 .6 14
P ro g ra m a c i n 1 1.2 2 ,9 7,3 19
( I n te g ra c i n y p ru e b a { 1,0 2,3 5 .6 14
Orgnico 1.1 2,7 6.5 16.0 N.C.
Semiacoplado 1.4 3,7 10,0 29,0 77.0
( Empotrado 1.7 5,2 16,0 51,0 157,0 M E D I A D E L P R O Y E C T O (F S P ) 1 M 2.7 6.5 16

% d e m ed ia del p ro y e c to i
P la n ific a c i n y re q u e rim ie n to s \ 60 % 55% 50% 46%
D is e n o d el p ro d u c to - 84 84 84 84
Tabla 9.7: Detalle de las tabulacin de distintos proyectos COCOMO bsico P ro g ra m a ci n ! 108 110 113 116
In te g ra c i n y p ru e b a : 89 87 85 83

( P R O D U C T I V I D A D (D S 1 /M M ) I 4 0 0 ___________ 3 7 6 _________ 3 5 2 ___________3 2 7

, Si se representa el esfuerzo estimado frente a la medida del producto, y el
calendario estimado frente al esfuerzo de desarrollo, pueden hacerse las
siguientes observaciones: Tabla 9.8 Perfil de un proyecto bsico en modo orgnico

Otra forma de presentar la misma informacin particularizada al modo

' Para productos software de la misma medida, el esfuerzo estimado
orgnico es segn se muestra en la Tabla 9.9 donde, adems de researse el
es considerablemente mayor y la productividad estimada es
valor total para el desarrollo del proyecto de cada uno de los datos, se detalla
( considerablemente menor para el modo empotrado.
tambin el valor para cada una de las fases que componen el proyecto. Por
tanto, al observar la citada tabulacin se puede comenzar a tener una medida
Para productos grandes, la disminucin en la productividad es relativa de cmo se comporta cada uno de los datos obtenidos para las
( mayor en el modo empotrado. diferentes fases y proyectos, y como vara la magnitud de estos efectos cuando
(
se avanza de pequea a gran escala.
146 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 9: E L M T O D O D E C O S T E S 147

As, de la observacin se deduce que si se considera que se est D I S T R IB U C IO N D E L E S F U E R Z O TAM AO DEL PRO D U CTO
desarrollando un producto que es a veces ms grande que otro (p.e. 32 KDSI (K D S I )
MODO FA SES S Y M G E
frente 8 KDSI), la productividad en el producto de 32 KDSI ser del orden de 2 S 32 128 512
un 94% del valor de la productividad del producto de 8 KDSI. Este
O rg n ic o % P la n ific . y re q u e rim ie n to s 6 6 6 6
decrecimiento en la productividad para proyectos grandes se denomina, en D is e o d e l p ro d u c to 16 16 16 16
trminos econmicos, una deseconoma de escala. Las razones de esta P ro g ra m a c i n 68 65 62 59
In te g ra c i n y p ru e b a 16 19 22 25
disminucin, teniendo en cuenta que la productividad es igual a las lneas de
cdigo totales del proyecto dividido por el esfuerzo de desarrollo, son las S e m i-a c o p la d o % P la n ific . y re q u e rim ie n to s 7 ? 7 7 7
D is e o d el p ro d u c to 17 17 17 17 17
siguientes: P ro g ra m a c i n 64 61 58 55 52
In te g ra c i n y p ru e b a 19 22 25 28 31

Se requiere mayor esfuerzo en el diseo del producto para poder E m p o tra d o % P la n ific. y re q u e rim ie n to s 8 8 8 8 8
desarrollar un nivel de especificacin ms completo ya que se requieren D iserto de) p ro d u c to 18 1 18 18 18
P ro g ra m a c i n 60 57 54 51 48
actividades que desarrollan en paralelo por un nmero de In te g ra c i n y p iu e b a 22 25 25 31 34
programadores que es ms grande.
D IS T R IB U C IO N D E L C A L E N D A R IO KDSI
O rg n ic o % P la n ific . y re q u erim ien to s 10 11 12 13
Una consecuencia de lo anterior es que se necesitar mayor esfuerzo D is e o d el p ro d u c to 19 19 19 19
P ro g ra m a c i n 63 59 55 51
para verificar y validar los requerimientos y especificaciones de diseo. In te g r a c i n y p ru e b a 18 22 26 30

S e m i-a c o p la d o % P la n ific . y re q u e rim ie n to s 16 18 20 22 24

An con especificaciones completas, los programadores en un proyecto D is e o d e l p ro d u c to 24 25 26 27 28
grande gastan bastante tiempo en la comunicacin y resolucin de P ro g ra m a c i n 56 52 48 44 40
In te g ra c i n y p ru e b a 20 23 26 29 32
caractersticas de interfaces.
E m p o tra d o % P la n ific . y re q u e rim ie n to s 24 28 32 36 40
D is e o d e l p ro d u c to 30 32 34 36 38
Lgicamente en proyectos grandes se requiere mayor esfuerzo para la P ro g ra m a c i n 48 44 40 36 32
In te g ra c i n y p ru e b a
integracin de las unidades que componen el proyecto. 22 24 26 28 30

Las pruebas para la validacin y verificacin del producto software son
ms extensas.
Y como ltimo dato, el que se produzca esta disminucin de la
productividad, se debe a que en proyectos grandes se produce un
aumento en el esfuerzo requerido para la organizacin del proyecto.
Tabla 9.9 Distribucin p o r fa ses del esfuerzo y del calendario
Cualquiera de las tablas descritas anteriormente pueden utilizarse
directamente para calcular la distribucin de los valores del esfuerzo y
calendario para los tres modos de desarrollo, para cada una de las fases que los
componen y para diferentes tamaos. Hay que tener en cuenta que el
porcentaje de distribucin para productos de medidas no tabulados se obtiene
por interpolacin en dicha tabla.

Un apartado importante a considerar dentro del modelo COCOMO bsico

es el esfuerzo de mantenimiento anual de un producto software. Este esfuerzo
se calcula por separado, considerando como mantenimiento del software el
proceso de modificacin del software operacional existente y manteniendo
siempre sus funciones principales intactas. Esta definicin incluye los
siguientes tipos de actividades dentro de la categora de mantenimiento:
148 P L A N IF IC A C I N Y G E S T I N DL S IS T E M A S IN F O R M T IC O S
Rediseo y redesarrollo de pequeas porciones de cdigo de un
producto software existente.
Diseo y desarrollo de pequeas interfaces para paquetes software que
requieren algn rediseo (de menos del 20 %) del producto software
existente.
Modificacin de cdigo, documentacin o estructura de la base de datos
del producto software.
Igualmente, la definicin excluye los esfuerzos dedicados a:
Rediseo y redesarrollo de ms del 50% del producto.
Diseo y desarrollo de interfaces que requieran un rediseo superior al
20 %.
Operaciones en los sistemas de proceso de datos, entradas de datos y
modificaciones de valores en la base de datos.
De todo esto, se puede deducir que el mantenimiento del software puede
clasificarse en dos categoras principales:
Actualizacin del software, cuyo resultado es un cambio de las
especificaciones funcionales para el producto software.
Reparacin de software, que deja las especificaciones funcionales
intactas y a su vez puede ser correctivo, adaptativo o de
perfeccionamiento.
En la prctica, COCOMO bsico calcula el esfuerzo de mantenimiento en
funcin del trmino denominado ACT (Animal Change Trafic o Trfico Anual
de Cambio) que es la fraccin de instrucciones fuentes del producto software
que cambian durante un ao o sufren modificaciones o aadidos.
Por ello, la ecuacin COCOMO para estimar el esfuerzo de mantenimiento
anual bsico (MM)am viene dada en funcin del esfuerzo de desarrollo
estimado:
{ M M) a m = K x ( AC T) x {MM) d
El coeficiente de correccin K suele emplearse un valor prximo a la
unidad.
C A P T U L O 9: EL M T O D O D E C O S T E S 149
El personal full-time en los doce meses del ao para el mantenimiento ser
(FSP) y vendr dado por la expresin:
\ h, [2
Ejemplo: Vamos a calcular el esfuerzo para el mantenimiento de
un producto software de 32 KLC, al cual se le aaden 4000 lneas
de cdigo nuevas y se modifican 2400 lneas de cdigo en el primer
ao de mantenimiento.
Obtendramos los siguientes valores:
A C T = (4000 + 2400)/(32000) = 0 .2 0
(M M) am= (0.2) (91) =18 MM
(FSP), = (18)/( 12) = 1 .5 FSP
Lo que nos ha permitido conocer el valor del FSP para llevar a
cabo el mantenimiento y poder ofertarlo con ciertas garantas.
Hasta el momento se han detallado las tcnicas bsicas para estimar el
esfuerzo total, coste y calendario que son necesarias para desarrollar y
mantener un producto software y su distribucin en las distintas fases del
proyecto. Para completar esta informacin, es necesario calcular qu cantidad
de esfuerzo es distribuido entre las principales actividades en que se divide el
ciclo de vida de un producto software como son: diseo, programacin,
planificacin de las pruebas, etc.
Como se puede observar segn el modo de desarrollo del producto que se
considere se obtiene una distribucin distinta de las actividades en las
diferentes fases para el modo empotrado, modo semiacoplado o modo
orgnico. Para explicar la tabla 9.10 nos centraremos en la columna ms a la
izquierda, la cual informa que en un proyecto de 2 KDSI, el 8% del esfuerzo
total se necesitara para completar la fase de planificacin y requerimientos, el
50% (o el 4% del proyecto total) se necesitara para desempear la tarea o
actividad del anlisis de requerimientos, estando sta compuesta por: anlisis
del sistema existente, determinacin de necesidades de usuario, integracin,
documentacin, etc. Otro 12% del 8% total (o el 1% del proyecto total) se
utilizara para ejecutar las tareas de diseo del producto durante la fase de
150 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
planificacin y requerimientos como puede ser: la investigacin de la
arquitectura bsica del producto hardware-software, etc. Y as, se irn
deduciendo tareas en cada una de las actividades que forman parte de esta fase
de planificacin y requerimientos. En la siguiente columna de la tabla se
observa que la distribucin de actividades es distinta para un proyecto
intermedio de 8 KDSI que para el pequeo de 2 KDSI, teniendo el resto de la
tabla una interpretacin similar.
Ejemplo: Se ha considerado oportuno, para familiarizarse con el
uso de estas tablas desarrollar un ejemplo. Para ello se calcular la
distribucin de actividades para la fase de diseo del producto de
un proyecto, cuyo tamao es muy grande (512 KDSI) en modo
empotrado.
Lo primero que se debe hacer es calcular su esfuerzo y calendario
total para el desarrollo del proyecto. Para ello, se consulta la Tabla
9.9, observndose que el esfuerzo de desarrollo para un proyecto de
512 KDSI en modo empotrado es de 6420 MM y el calendario es
de 41 meses. A continuacin, se consulta la Tabla 9.10, en la que se
distribuye este esfuerzo en fases observndose que la fase de diseo
del producto consume un 18% del esfuerzo total y un 38% del
calendario total, pudiendo as calcularse el esfuerzo y el calendario
necesario para el desarrollo de dicha fase de diseo, obtenindose
los valores de:
M M = 6420 hombres-mes * 0.18 = 1156 hombres-mes
T D E V- 41 meses * 0.38 = 15.6 meses
Estos valores conducen a una medida de FSP de 74 personas
trabajando durante la fase de diseo del producto. La consulta de la
Tabla 9.8 permitir conocer adems las tareas que estn
desempeando estas personas.
Utilizando la columna a la derecha de la columna de diseo del
producto, se observa que un 10% de las 74 personas realizan
funciones de anlisis de requerimientos, el 42% de las 74 personas
realizan funciones de diseo, etc. Si estos datos se expresan en
funcin del nmero de personas que se encuentran realizando cada
una de las actividades, se obtendr:
Anlisis de requerimientos = 7FSP________ __________ _
C A P T U L O 9: E L M T O D O D E C O S T E S
Diseo del producto =31FSP
Programacin = 10FSP
Planificacin de las pruebas = 6FSP
Verificacin y validacin = 7 FSP
Trabajos de oficina = 5FSP
Control de calidad = 2FSP
Desarrollo de manuales = 5FSP
Si se desea tener ms informacin acerca de las tareas que realiza,
en concreto, este personal en cada una de las actividades que
componen cada una de las fases en que COCOMO divide el
esfuerzo de desarrollo de un proyecto software, se consultar la
Tabla 9.9, en la que estn descritas dichas tareas.
Una consecuencia del anlisis de datos de los resultados COCOMO es la
naturaleza de la distribucin por actividades, as se puede determinar que:
La distribucin del tiempo por actividades es funcin del tamao del
proyecto y del modo
Los porcentajes de los esfuerzos de planificacin son independientes
del tamao del producto
Los tiempos de diseo y pruebas aumentan proporcionalmente con el
tamao
Los tiempos de programacin disminuyen con una proporcin inversa
al tamao del producto y a su modo.
A pesar de la cantidad de informacin que nos facilita este mtodo de
estimacin se sabe que existen algunas limitaciones del modelo COCOMO
bsico ya que no se acomoda de forma secuencial al desarrollo incremental del
proyecto. La estimacin del esfuerzo se desarrolla razonablemente bien, pero
los clculos de calendarios se deben hacer de forma diferente.
Otra de las limitaciones del modelo COCOMO bsico es la estimacin del
personal medio en cada fase. Existen discontinuidades en los niveles de
personal en los lmites entre las fases, que siguiendo el modelo deberan ser
planas y mantenerse constantes. Un ejemplo de estas discontinuidades se puede
observar en la actividad de programacin durante la fase de integracin y
prueba (Tabla 9.8), en la que al comienzo de la misma existe una gran cantidad
de personal desarrollando tareas de integracin, mientras que al final de la fase
este nmero disminuye considerablemente.
152 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Sin embargo, la principal limitacin de COCOMO bsico es que no
incorpora los efectos de algunos modificadores de coste del software, tales
como: restricciones del hardware, factores que afectan al personal, atributos
ambientales, etc., los cuales sern incorporados en el modelo COCOMO
intermedio donde el esfuerzo se mide en funcin del tamao del programa y a
un conjunto de "guas de coste logrndose un sistema bastante mas fino que
el anterior pero su complejidad puede hacer que no sea necesario emplearlo si
no se necesita una estimacin mas fiable.
Las ecuaciones de estimacin en un modelo COCOMO intermedio se
muestran en la Tabla 9.10.
MODO ESFUERZO CALENDARIO
Orgnico MM= 3.2 (KDSI)1'05 TDEV= 2,5(MM)"JS
Semi-acoplado MM= 3.0 (KDSI)1 12 TDEV= 2,5 (M M )1135
Empotrado MM= 2.8 (KDSI)1'20 TDEV= 2,5 (MM),JJ
T a b la 9.10 E cu a cio n es de esfuerzo y tiem po en C O C O M O interm edio
Una estimacin del esfuerzo de desarrollo del software en el modelo
COCOMO intermedio comienza por generar una estimacin del esfuerzo
nominal, usando para ello ecuaciones de escala de los distintos modos como se
realizaba en el COCOMO bsico. Esta estimacin nominal est entonces
preparada para aplicar un multiplicador del esfuerzo determinado por la clase
de proyecto que se est considerando con respecto a los quince modificadores
de coste.
En la Tabla 9.10 se representan las ecuaciones del esfuerzo nominal y el
calendario de desarrollo estimados para el COCOMO intermedio en los tres
modos de desarrollo considerados. En estas ecuaciones se observa que la escala
de factores (exponentes) para el modelo intermedio y para los tres modos de
desarrollo son los mismos que para el modelo bsico, pero los coeficientes son
distintos. Esta diferencia se justifica en base a que se considera que el efecto
que produce el multiplicador del esfuerzo no es el mismo para los tres modos
de desarrollo. Si se hubieran utilizado los mismos coeficientes del modelo
bsico, los valores obtenidos para el esfuerzo estimado en el modo empotrado
hubieran sido demasiado altos, mientras que en el modo orgnico hubieran sido
demasiado bajos.
C A P T U L O ): EL M T O D O D E C O S T E S 153
Hay muchos factores candidatos a considerar en el desarrollo de un mejor
modelo para la estimacin de costes de un proyecto software y que constituyen
los denominados "Multiplicadores de esfuerzo en el modelo COCOMO
intermedio. Los pioneros en el estudio de este tipo de multiplicadores fueron
tcnicos de System Development Corporation que consideraron a mitad de
aos sesenta que haba ciento cuatro factores diferentes, todos ellos
encaminados a determinar el coste de desarrollo del software. Consideraron
factores tales como: tipo de aplicacin, nmero de tipos de entradas y salidas,
porcentaje de entradas y salidas, instrucciones matemticas o de control en el
programa, experiencia media de analistas y programadores, configuracin del
ordenador, uso del lenguaje de programacin, etc. Estudios posteriores, tales
como los de Walston-Felix en 1977, encontraron factores adicionales que
tambin influan en el coste del software, tales como: la complejidad del flujo
del programa, la presencia de restricciones en la seguridad, el uso de tcnicas
de programacin estructurada, inspecciones, desarrollo top-down, y otros. Para
reducir este gran nmero de factores a un nmero manejable que se pueda usar
en una estimacin de costes de desarrollo de software prctica, se someten los
factores a dos criterios de seleccin:
Relevancia general, en este caso se eliminan los factores que
tienen relevancia solamente en relativamente pequeas porciones
de situaciones especficas.
Independencia, en este caso se eliminan los factores que estn
fuertemente relacionados con la medida del producto y al mismo
tiempo se tiende a englobar en factores simples a aquellos que
produzcan un efecto similar para las estimaciones, como ocurre
en el caso del uso de la programacin estructurada, inspecciones
que se produzcan, y factores parecidos, los cuales se engloban en
uno simple que se denomina: uso de prcticas modernas de
programacin.
Como resultado de aplicar dichos criterios se obtuvieron 15 factores o
atributos modificadores del coste que son los usados en el modelo COCOMO
intermedio y se agrupan dentro de cuatro categoras, las cuales define Boehm
como:
Atributos del producto software
Atributos del ordenador
Atributos del personal
Atributos del proyecto.
154 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 9: E L M T O D O D E C O S T E S 155

MODIFICADORES DEL COSTE DE Muy Bajo Nomin Alto Muy Extra

DESARROLLO 1. Se desarrolla un prototipo o modelo de demostracin de
bajo al alto alto
ATRIBUTOS DEL PRODUCTO viabilidad de un lenguaje natural o sistema de entrada de voz. Este
RELY Confabilidad requerida del software 0.75 0.88 1.00 1.15 1.40 tipo de sistemas requieren de un nivel bajo de confabilidad, ya que
DATA Tamao de la Base de Datos 0.94 1.00 1.08 1.16 no es un sistema orientado a la produccin. Observando la Tabla
CPLX Complejidad del producto 0.70 0.85 1.00 1,15 1,30 1.65 9.11 y 9.12, la estimacin del esfuerzo ajustado para un producto
ATRIBUTOS DEL ORDENADOR de esta naturaleza es:
TIME Restricciones del tiempo de ejecucin 1.00 1.11 1.30 1.66
STOR Restric. en almacenamiento principal 1.00 1.06 1.21 1.56
VIRT Volatilidad de la mquina virtual 0.87 1.30
(146A/M)(0.75) = 1 1 0 hombres-mes
1.00 1.15
TURN Tiempo de respuesta del ordenador 0,87 1.00 1.07 1.15
AT RIBUTOS DEL PERSONAL
ACAP Capacidad de los analistas 1.46 1.19 1.00 0.86 0.71 2. Se desarrolla un modelo de planificacin a gran escala o un
AEXP Experiencia en la aplicacin 1.29 1.13 1.00 0.91 0.82 modelo de planificacin climatolgica. Estos tipos de productos
PCAP Capacidad de los programadores 1.42 1.17 1.00 0.86 0.70 requieren una confabilidad relativamente baja, porque su impacto
VEXP Experiencia en uso de memoria virtual 1.21 1.10 1.00 0.90
operacional es a gran escala y muchos de sus fallos se pueden
LEXP Experiencia en leng. de programacin 1.14 1.07 1.00 0.95
ATRIBUTOS DEL PROYECTO producir a bajo nivel, siendo las prdidas fcilmente recuperables
MODP Uso de prcticas modernas de pro. 1.24 1.10 1.00 0,91 0.82 para los usuarios. La estimacin del esfuerzo se obtendr de la
TOOL Uso de herramientas software 1.24 1.10 1.00 0,91 0.83 forma:
SCF.D Calendario requerido para el desarrollo 1.23 1.08 1.00 1.04 1.10
(146AA)(0.88) = 128 liombres-mes
T a b la 9.11 M o d ific a d o re s d e c o s te d e d esa rro llo

3. Se desarrolla un sistema de manejo de informacin o un sistema

de control de inventario. Estos sistemas son representativos de la
clase de software con requerimientos de confabilidad nominal, en
Ejemplo de manejo de las tablas: ellos el efecto de un fallo no es trivial, pero generalmente es
recuperable sin una extrema complicacin. Por ello, el ajuste se
Consideraremos un software a estimar de 32KDS1 en modo considera nominal y el esfuerzo estimado ser:
semiacoplado con una serie de requisitos de confabilidad,
acudimos a la tabla y observamos que: (146MA)(1.00)= 146 hombres-mes

MM=3,0 (32)1,12 = 146 meses-hombre

4. Se desarrolla un sistema del tipo de autorizacin de crditos en el
TDE F=2,5( 146)0,35= 14,3 0 meses campo de la banca o sistema de distribucin elctrico. Estos
sistemas requieren una alta confabilidad, pues un fallo en tales
Se acude a las distintas tablas para estudiar los coeficientes sistemas puede producir prdidas financieras o inconvenientes
modificadores de esfuerzo. Dependiendo de la influencia del nivel humanos masivos, siendo el esfuerzo ajustado:
de confabilidad requerido (RELY) de los distintos tipos de
proyectos que se deseen desarrollar, as en los dos ejemplos se (146MA4)(1.15) = 168 hombres-mes
tendra:
156 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 9: E L M T O D O D E C O S T E S 157

5. El ltimo caso en la escala a considerar, sera el desarrollo un Atributos delpersonal:

sistema del tipo de control y mando militar o un sistema de control Capacidad de los analistas = 1 ,1 9
de un reactor nuclear que exige un requerimiento muy alto de Experiencia de la aplicacin = 1,29
confiabilidad del software, pues un fallo en el sistema podra Capacidad de los programadores = 1
ocasionar la prdida de vidas humanas, por ello el esfuerzo Experiencia en el S.O. utilizado = 1 ,1 0
ajustado vendr dado por: Experiencia en el lenguaje de programacin = 1
Atributos delproyecto:
(146A/A/)(1.40) = 204 hombres-mes Utilizacin de tcnicas actualizadas de
programacin = 1
Utilizacin de herramientas software = 0,91
Requisitos de planificacin = 1
Todos estos factores multiplicativos dan un factor total de 1,08

Ejemplo 1. Estimacin de recursos de una pequea aplicacin 4. Se realizan los clculos de esfuerzo nominal.
utilizando el COCOMO intermedio:
MM = 3,2 x 1,527I,0S = 5 personas/mes
1. Se analiza el entorno de desarrollo.
Se elige el modo orgnico debido a: Aplicando el factor:
Entorno de desarrollo estable
Mnimas necesidades de introducir algoritmos MM = 1,08 x 5 = 5,4 personas/mes
innovadores
Tamao del proyecto pequeo 5. Se calcula el tiempo estimado.

2. Se estima el nmero de lneas a desarrollar. TE = 2,5 x 5,4 o38 = 4,75 meses

Detalle de lneas estimadas de la aplicacin:
I lneas de ficheros = 58 6. Se calcula el personal medio.
Lneas de pantallas = 198
Lneas de programas = 1280 PM = 5,4 / 4,75 = 1,14 personas
Total lneas = 1527

3. Se define el valor de los factores multiplicativos.

Atributos del producto:
Restricciones en cuanto a fiabilidad del software = Ejemplo 2. Estimacin de recursos por fases del ciclo de vida
0,88 utilizando el COCOMO intermedio:
Tamao de la base de datos = 0,94
Complejidad del producto = 0,85 1. Se analiza el entorno de desarrollo.
Atributos del computador: Se elige el modo orgnico debido a:
Restricciones de tiempo de ejecucin = 1 Entorno de desarrollo estable
Restricciones de memora virtual = 1 Pocos requisitos
Volatilidad mquina virtual = 1 Tamao del proyecto pequeo
__________ Tiempo de respuesta del computador = 1___________
158 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN J-'O R M T IC O S C A P T U L O 9: E l. M T O D O DE C O S T E S 159

2. Se eslima el nmero de lineas a desarrollar. 7. Se calcula el personal medio.

Destalle de lneas estimadas de la aplicacin por mdulos: Total del proyecto:
Mdulo de Compras = 600
Mdulo de Ventas = 800 PM = 16,3 / 7,22 = 2,26 personas
Mdulo de Almacn = 1000
Mdulo de Contabilidad = 600 Por fases:
Total lneas = 3000 Planif. y requerimien. 1 / 0,72 = 1,39 1,5 personas
Diseo 2.6 / 1,37 = 1,9 ~ 2 personas
3. Se define el valor de los factores multiplicativos. Programacin 11,1 / 4,55 = 2,44 2,5 personas
Tiempo de respuesta (TURN) Alto 1,15 Integracin y prueba 2.6 / 1,3 = 2 personas
Experiencia (AEXP) Alto 1,06
Uso de herramientas software (TOOL) Bajo 1,13 8. Se obtiene una tabla temporal de planificacin del proyecto.
Tamao de la base de datos (DATA) Bajo 1,17 Considerando las personas y el tiempo necesario para cada fase se
Otros aspectos Nominal 1,00 puede establecer el siguiente diagrama:
Todos estos factores multiplicativos dan un factor total de 1,61
mes 1 m es 2 mes 3 m es 4 m es 5 m es 6 mes 7 m es 8
4. Se realizan tos clculos de esfuerzo nominal.
Planif. y requerimien. l,5 p

MM = 3,2 x 3 1,05 = 10,14 personas/mes Diseo 2 P-

Programacin 2,5 p.
Aplicando el factor:
Integracin y pruebas 2p.

M M = 1,61 x 10,14 = 16,3 personas/mes

5. Se realizan los clculos por fases.

Aplicando los porcentajes de la tabla 9.10: Las razones por las cuales se necesitan ms hombres-mes para desarrollar
Planif. y requerimien. 0,06 x 16,3 = 1 personas/mes un producto software con altos requerimientos de confiabildad o fiabilidad son
Diseo 0,16 x 16,3 = 2,6 personas/mes analizados en profundidad en el modelo detallado o avanzado.
Programacin 0,68 x 16,3 = 11,1 personas/mes
Integracin y prueba 0,16 x 16,3 = 2,6 personas/mes Para este modelo semiacoplado de COCOMO, la estimacin ajustada del
esfuerzo del mantenimiento corresponder a modificar el valor de la constante
6. Se calcula el tiempo estimado. de ajuste por alguno de los mostrados en la tabla siguiente dependiendo del
Total del proyecto: grado de preparacin del proyecto para su mantenimiento, trmino conocido
como factor de mantenibilidad del producto.
TE = 2,5 x 16,3o38 = 7,22 meses

Por fases:
Planif. y requerimien. 0,10 x 7,22 = 0,72 meses
Diseo 0,19 x 7,22 = 1,37 meses
Programacin 0,63 x 7,22 = 4,55 meses
Integracin y prueba 0,18 x 7,22 = 1,3 meses
160 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 9: E L M T O D O D E C O S T E S 161

T am a o del p ro d u e lo (K D S I) M u y B ajo B aio Neunmal A lio M u y A lio

2 1.25 1.12 100 0.90 0.S1
Muy bajo Bajo Nominal Alto Muy Alto 8 1.30 1.14 1.00 0.8S 0 .7 7
35 1,15 1,00 0,98 0,97 32 1.35 1.16 1.00 0.86 0 74
128 1.40 1.18 1.00 0.85 0 .7 2
512 1.45 1.20 1.00 0.84 0 .7 0
T abla 9.12 V a lo res d e m ultiplicador R E L Y p a r a esfuerzos de m a n ten im ien to
Tabla 9.13 V alores d e l m u ltip lica d o r M O D P p a r a el esfuerzo de m a n ten im ien to
Los modificadores del esfuerzo en el modelo COCOMO intermedio
pueden aplicarse a la etapa de mantenimiento igual que a la etapa de desarrollo.
Muchos de los atributos modificadores de coste se consideran que son los Con respecto al atributo MODP, es preciso considerar que el liso de
mismos para la etapa de mantenimiento que para la de desarrollo. Las prcticas modernas de programacin como pueden ser la programacin
caractersticas de cada etapa determinan el valor a considerar de estos atributos, estructurada, diseo y desarrollo top-down, libreras de programas de soporte,
pudiendo ser diferentes, o las mismas, las caractersticas de la etapa de etc., durante el desarrollo (y mantenimiento) tienen un doble efecto en el nivel
desarrollo y mantenimiento, y por tanto, tomar diferentes, o los mismos, requerido de mantenimiento del software: El mayor uso de prcticas modernas
valores estos atributos. de programacin aumenta el ahorro en el esfuerzo de mantenimiento, el mayor
uso de prcticas modernas de programacin facilita el mantener grandes
Uno de los factores modificadores del coste que se considera en el productos con la misma eficiencia que los productos pequeos.
desarrollo: el calendario requerido para el desarrollo del producto, SCED
(Required Development Schedule), no tiene influencia en la etapa de El modelo COCOMO avanzado permite introducir modificadores a nivel
mantenimiento, considerndose, por tanto, para esta etapa con un valor subsistema, sistema y mdulo a la vez que efecta una estimacin jerrquica
nominal. del modelo del software. En este sentido se consideran una coleccin de
Dos de los factores modificadores de coste RELY (Required Software modificadores de los esfuerzos que completan los del COCOMO intermedio.
Reability); es decir: la confiabilidad requerida del software y MODP ( Use o f
Modern Programming Practices); es decir: el uso de prcticas modernas de El modelo COCOMO intermedio representa un modelo altamente efectivo
programacin, tienen diferentes valores de sus multiplicadores debido a para muchos de los propsitos de las estimaciones de costes del software. No
diferencias en sus impactos relativos en el desarrollo y en el mantenimiento. Si obstante tiene principalmente dos limitaciones que se significan, sobre todo, en
se asume que la clasificacin del atributo RELY es la misma para el desarrollo las estimaciones detalladas de los costes para proyectos software grandes:
que para el mantenimiento, en ese caso no se podra esperar desarrollar Las estimaciones de la distribucin del esfuerzo por fases es inexacta.
software con baja confiabilidad (muchos fallos) y esperar operarlo con pocos Es un modelo que resulta incomodo para usarlo en un producto con
fallos (alta confiabilidad) durante el mantenimiento. En la tabla de la figura muchos componentes.
superior se muestran los valores del multiplicador RELY para el esfuerzo de
mantenimiento en el modelo intermedio. F-I modelo COCOMO detallado o avanzado permite eliminar las
limitaciones del modelo intermedio por dos vas principalmente:
En la tabla siguiente se muestra como a mayor confiabilidad, se requiere
menor esfuerzo para mantener el nivel requerido y, por tanto, a menor 1. En el modelo intermedio el esfuerzo de distribucin por fases es
confiabilidad requerida mayor ser el esfuerzo necesario para el mantenimiento determinado slo por la medida del producto software a
del producto. desarrollar. En la prctica, factores tales como la confiabilidad
requerida del software, experiencia en aplicaciones del personal,
etc., afectan a unas fases ms que a otras. El modelo detallado
proporciona una medida de la sensibilidad en cada una de las
fases de los factores multiplicadores para cada uno de los
atributos modificadores de coste, usando dichos multiplicadores
para determinar la cantidad de esfuerzo requerido para
completar cada fase.
162 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 9: EL M T O D O D E C O S T E S 163

Algunos valores tpicos de C* pueden ser Ck =2000 en entornos de

2. En el modelo COCOMO intermedio se efecta una separacin desarrollo tpicos o C* = 8000 en un buen entorno de desarrollo con buena
de la clasificacin de los modificadores de coste que pudieran metodologa y herramientas.
ser provistos para los diferentes componentes del producto. Este El valor del esfuerzo se puede despejar de la ecuacin anterior resultando,
proceso puede ser muy tedioso e innecesariamente repetitivo. la ecuacin de la forma:

El modelo detallado resuelve este problema proporcionando tres jerarquas K=L3 / (Ck3* h f)
de niveles del producto, siendo stas:

Nivel modular, se consideran los efectos que tienden a variar con la

profundizacin en el nivel modular. 9.6 HERRAMIENTAS AUTOM TICAS DE ESTIMACIN

Nivel de subsistema, se consideran los efectos que varan menos Una vez estudiados los distintos modelos empricos de estimacin de costos
frecuentemente; es decir, varan de la misma manera para todos los vamos a sealar como est el estado del arte en la implementacin en
mdulos que componen un subsistema. programas de usuario:

Nivel de sistema, se consideran efectos tales como la medida total

del producto, que afectan a todo el sistema globalmente. Existe un producto, denominado comercialmente ESTIMAOS, que utiliza
un modelo basado en los puntos funcin de Albretch mejorado que permiten al
planificador ajustarse a distintos factores de personal a la vez que permite
llevar varios proyectos en paralelo7.
9.5 M TODO DE ESTIM ACIN DE PUTMAN
El programa COSTAR es una aplicacin directa del modelo COCOMO
descrito por el Dr. Barry Boehm en su libro Software Engineering Economics
El modelo de estimacin de Putman es un modelo multivariable dinmico que
en sus tres modos, y es, seguramente el mas empleado en la industria, permite
asume una distribucin especfica del esfuerzo a lo largo del ciclo de vida de
obtener informacin estimada del esfuerzo del desarrollo del sistema, de los
un proyecto de desarrollo software. Las curvas mostradas en la figura toman la
costes y del personal necesario.
forma clsica descrita por Lord Rayleight en el ao 1978 y los datos empricos
fueron recogidos por Norden.
De este programa existen numerosas versiones, tanto para UNIX, MS-
DOS y Windows; que la compaa Sunsets actualiza constantemente.
La funcin es de la forma:

l = c > k 1/3 x ( 4/3

donde Ck es una constante de estado de la tecnologa y refleja las restricciones

directas que frenan el progreso del programador, K es el esfuerzo necesario
medido en personas-hombre durante todo el ciclo de vida, K es el esfuerzo total
del desarrollo en personas-ao y td es el tiempo de desarrollo en aos y L el
nmero de miles de lneas fuente del proyecto.

7 En la pgina web hlln://sunsci.usc.cdi)/research/COCOMOII/indcx.htinl se puede encontrar

informacin adicional gratuita y una referencia de programas de downloads.
164 PLANIFICACIN Y GESTIN DE SISTEMAS INFORMTICOS CAPTULO 9: EL MTODO DE COSTES 165

-<g|>
REPORT COMPONENT ESTIMATE OflTRBflSE ULE ESOCancel data entry Kl .^-Hel
Est imate/ID:NoName Standard Component/IO:NoName
Database/ID:C0C0M0_87 1.00 Process Model Component of:
-Personnel- -Computer- -User Defined- -Model-
flCRP: nominal T IME:* noninal USR1:undefined Oetailed Model
flEHP: nominal S TOR: noninal USR2:undefined
PCflP: nominal T URN: nominal USR3:undefined -Mode-
VEKP: nominal V HVH: nominal Organic
LEKP:* nominal V MVT: nominal -Cost/SN-
RQCOST:* * 0
Product- -Project- PDCOST:* $ 0 -Maintenance-
:* nominal HODP: nominal DDCOST: $ 0 PRCT :* 0/.
: nominal TOOL: nominal CTCOST:* $ 0
: nominal SCED: nominal ITCOST:* $ 0 -Size-
: nominal SECU:* nominal HNCOST:* $ 0 DSI: 2000
-------- Development Summary (PD*DD+CT+IT) ---- Current ----
Duration (Months) 5.1 Total DSI DSI 2000
Productivity (DSI/SM) 301.9 Total Staff-Months S-Months 6.6
Unit Cost ($/DSI) 0.00 Total Cost (K$) Cost 0.0
--------------------------------- Costar Demo ---
IIIOME=comand line F i l l in nn 11) for the Current CoNDonentl

1 i Iin i l l 111
jjg...I
v. V
.|@1... Hait.
f
.
,
llK B A s ' ^ i*
.
|i XI %

Figura 9.14 Aspecto del program a CO STAR para MS-DOS. Figura 9.15 Aspecto de Costar II

Algunos avances sobre el modelo se pueden ver aplicados en el programa
COSTAR II, que es una ampliacin del programa anterior que soporta una
mayor cantidad de modelos de estimacin, incluido el modelo C-OCOMO II,
Para facilitar la planificacin del proyecto, en esta versin del programa,
Costar II facialita el supuesto de anlisis de la forma qu pasara si? Adems
de comparar distintos planes de proyectos. La riqueza de informes y grficos
hacen que Costar II sea, actualmente, la estrella de los programas de
estimacin de esfuerzos.
Otro producto interesante es el SL1M, basado en el modelo de Putnam que
permite obtener unos estudios de programacin lineal, la simulacin estadstica
y los diagramas PERT en el mismo paquete.
Muchas instituciones y casa comerciales tienen herramientas en la red,
alguna de ellas accesible va w'eb, como puede ser el caso de la NASA, vase la
referencia httn://www.isc.nasa.aov/bu2/COCQMO.htinl. que presenta el
aspecto de la figura 9.16.

La versin de evaluacin permite estimar proyectos de hasta 5000 lneas
de cdigo fuente y permite efectuar supuestos sobre la duracin partiendo de
personal dedicado al proyecto y su inversa, es decir, qu personal se debe de
dedicar en cada una de las fases de desarrollo para satisfacer un calendario
previsto segn unas especificaciones dadas.
En la versin evaluada (6.0) se ofrecen numerosas posibilidades de
intercambiar la informacin con otros programas de Windows, pudindose
obtener informacin grfica para insertar o adjuntar dentro de herramientas
ofimticas como puede ser Microsoft Word.
Todos estos productos, hoy da disponibles en computadoras personales,
permiten calibrar el entorno local de desarrollo y crear un modelo de
informacin del software desarrollado mediante sus caractersticas bsicas, los
atributos de personal y las consideraciones del entorno.
Si en su organizacin no se dispone de software de estimacin de
proyectos, se pueden buscar sitios de la red que disponga de software que
est ms o menos calibrado a nuestro entorno de desarrollo y a los usos y
costumbres del grupo de trabajo concertadas en forma de metodologas.
166 PLANIFICACIN Y GESTIN DE SISTEMAS INFORMTICOS CAPTULO 9: EL MTODO DE COSTES 167

BTIIBBHIHWff -IOI x|
i i Arthvo E<<Ko v?r FavpR'tt Ayu*fa
..............o El modelo de Barry W. Boehm proporciona una base firme para
4-Atjis * * IPavCTito* 9 h ^ * id
>1 ^>lf <J jviftijos >J; desarrollar una estimacin de costes en un sistema software, debido a su
'tflgicwtis Use ityourownri<L- Tlitietool*rewitteniu JiviSciipla x / i * i t o v r $ t with -iJ adaptabilidad a los distintos sistemas, a su fcil aplicacin y a la consideracin
;)a-s&<ViiI It'vou hve lioubl viewinc fu asme llt't*- iri-tnsiih the rWii.Oillv
fiiSitl.fJSAim.- ! por parte del modelo de la influencia de los factores ms importantes del
desarrollo de software.
Inputs
, Development j.
Aunque existen otros modelos de estimacin de costes, como el modelo
I>cbvered Source Instructions (thousands) (KDSI) -jl :i . J SLIM de Putnam, el modelo SDC (System Developmenf Corporation) de
'Developmfot Mode j Organic * : . p Nelson, etc., se ha desarrollado el estudio ms profundo del modelo COCOMO
Average- Cost Rate (tPM) yioooo debido a que es uno de los ms completos de los existentes, adems de uno de
Maintenance
los ms utilizados por las organizaciones para la estimacin de costes en la
jFJDSI added (annual) P ............. 1
produccin de grandes sistemas informticos.
IKDSI modified (annual) I |
Average Cost Rate ||OIXIO |

Reco'c | = ; ! - - . .

:
i1 ................ 5 i .r 1
?*] r ; $ ItferiHt
i*w cioj & j IfcpcspSd: ...||4r]CoMo... B jiX J **

Figura 9.16 Pgina COCOMO de la Nasa.

9.7 DISCUSIN FINAL

La estimacin es una tarea difcil y errtica en la Ingeniera del Software que se

fundamenta en medir experiencias pasadas. De todos los modelos de
estimacin resulta ser COCOMO el ms universalmente aceptado si bien hay
que hacer hincapi en que cualquier mtodo de estimacin se debe de ajustar a
la organizacin. Por ello, podemos decir que: una estimacin de costes es slo
tan buena como nuestra capacidad de extrapolar al futuro las experiencias
pasadas.

Una norma de buena costumbre que se suele utilizar en muchas ocasiones

es la de comparar los resultados de ambas estimaciones en busca de
desviaciones superiores al 15% para poder analizar las diferencias entre los
componentes y as decidir si la planificacin ha sido correcta..

Debido a que la mayor parte de las estimaciones de costes estn

desarrolladas en funcin del nmero estimado de instrucciones del producto
final, la estimacin de costes del producto no ser superior a nuestra capacidad
de estimar el nmero de instrucciones finales existentes en l.
P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S

CAPTULO 10

PLANIFICACIN DEL TIEMPO

El objetivo fundamental del presente captulo es aprender a obtener el camino

crtico y las holguras posibles asociadas a cada tarea para optimizar la
planificacin del proyecto de software mediante el estudio de una red.

Antes de elaborar nuestro comentario vamos a aclarar la palabra

"direccin". Cuando leemos la palabra "management" en lenguaje anglosajn y
la queremos traducir como "director" perdemos algo de semntica en la
conversin ya que no slo se refieren a la direccin de la empresa sino que se
extiende a toda ella. La diferencia est en que los distintos niveles de direccin
tienen distintos niveles de autoridad y responsabilidad.

Podemos decir que entendemos por direccin cualquier rgano ejecutivo

de la empresa que rena las siguientes condiciones:

debe de conocer el objetivo de su trabajo;

debe organizar los recursos disponibles para lograr el objetivo elegido
por medio de un plan de realizacin;
si cambian las condiciones del plan, debe de controlar y modificar el
plan.

Por lo tanto se deduce que un director debe de tomar decisiones que, a su

vez, van acompaadas de la incertidumbre, sobretodo si el proyecto o plan no
tiene precedente, es ms, incluso cuando se realizan procesos repetitivos, la
direccin suele encontrarse con problemas que debe de solucionar.

El objetivo fundamental del presente captulo es aprender a obtener el

camino crtico y las holguras posibles asociadas a cada tarea para optimizar la
planificacin del proyecto de software mediante el estudio de una red.
170 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
10.1 DE LOS GRFICOS DE BARRAS AL ANLISIS DE RED.
El sistema de los grficos de Gantt se ha empleado de forma eficiente en los
procesos industriales con excelentes resultados pero en sistemas grandes se han
utilizado otras tcnicas de mayor relevancia para resolver la estrategia de solu
cin del da a da.
Es formativo conocer algo de lo que sucedi cuando la Marina de EEUU
comenz en la construccin del submarino nuclear Polaris entendi que
adems de superar los problemas tcnicos y cientficos necesitaba vencer
problemas de coordinacin. Tena 250 contratistas directos y ms de 9.000
subcontratistas por lo que plante el problema de obtener un mtodo de
planificacin para desarrollar el proyecto eficazmente en coste y tiempo.
En colaboracin con las casa BOOZ, Alien y Hamilton, se iniciaron los
conceptos bsicos del sistema PERT (Project Evaluation and Review
Techniqu) que, finalmente, concluyeron con un ahorro de dos aos en una
planificacin inicial de Gantt de cinco aos, consiguiendo, por tanto, un ahorro
en la planificacin de costes importantes.
En 1957 la casa Du Pont, que tena necesidad de controlar el
mantenimiento de sus factoras, desarroll un sistema para mejorar el mtodo
de planificacin y programacin de programas de construccin que se basara
no solamente en reducir los costes como en PERT, sino adems reduccin del
tiempo de desarrollo. Como consecuencia de sus estudi se cre la tcnica
CPM (Critical Path Meihod).
Por tanto PERT y CPM son sistemas especialmente diseados para asistir a
la direccin en esas tareas donde la incertidumbre pudiera comprometer su
eficacia, ya que estos mtodos le ofrecen una planificacin detallada, con las
responsabilidades designadas, y la programacin mejor estimada y con ms
probabilidad de cumplimiento.
El factor tiempo adquiere cada vez mayor importancia en las empresas de
software porque puede inducir a ciertas penalizaciones tanto a nivel estratgico
como a nivel comercial, lo que se traduce a penalizaciones de costes. Dando la
vuelta al concepto anterior, podemos presuponer que se obtiene una economa
indirecta mejorando los mtodos para la planificacin, programacin y control
de proyectos: las tcnicas de CPM y PERT son productos del progreso
cientfico para controlar el cmo se pueden producir ms unidades.
C A P T U L O 10: P L A N IF IC A C I N D E L T IE M P O 171
La aplicacin del PERT se concentra en las tareas en que hay
incertidumbre en cuanto a tiempos de terminacin, sin embargo CPM es ms
potente cuando se supone que las experiencias pasadas nos dan una idea clara
de la duracin de cada fase pero que hay incertidumbre frente a los costes ya
que lo importante en esta segunda tcnica es el coste total mnimo.
Las ventajas que estas tcnicas nos ofrecen es poder ofrecer a la direccin
la siguiente informacin:
Qu trabajos se deben realizar primero y cundo se han de efectuar las
diferentes inversiones?
Qu trabajos hay y cuantos sern requeridos en cada momento?
Cul es la situacin de un proyecto concreto frente a la duracin y al
coste?
Cules son las tareas crticas tales que si se retrasa alguna de ellas se
retrasa todo el proyecto?
Cules son las tareas no crticas y con que margen estn programadas
para que no sean crticas?
Cmo se pueden introducir correcciones a un proyecto que est
sufriendo demoras?Cul es la planificacin y programacin de un
proyecto con coste total mnimo y duracin ptima?
Los mtodos de PERT y CPM separan el proceso de planificacin del
proceso de programacin, este es el punto de diferencia con el mtodo de
GANTT en el que se realiza la planificacin y la programacin al mismo
tiempo.
Los clculos de los tiempos lmite pueden ser muy tiles para la
planificacin del proyecto software. Un descuido en el diseo de una funcin
puede retrasar el posterior desarrollo de otras funciones. Rigss en 1981
describe tiempos importantes que pueden discernir entre la red PERT y la
CPM.
10.2 DESCRIPCIN DEL MODELO GRFICO.
Las tcnicas de representacin grfica de proyectos se basan en la utilizacin
de flechas donde las tareas o actividades considerando que una actividad puede
tener una o varias tareas con lo que la tarea es la unidad mnima de ejecucin a
la hora de planificar y controlar el proyecto. Las tareas se representan por
flechas que tienen dos partes: la flecha en s que representa la ejecucin del
172 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 10: P L A N IF IC A C I N D E L T IE M P O 173

trabajo, que normalmente se representa de derecha a izquierda y los sucesos,

que son los acontecimientos del proyecto y se representan por pequeos
crculos al principio y al final de la flecha correspondiendo al suceso inicial y
final, respectivamente. En este sentido los sucesos no consumen esfuerzo ni
emplean recursos sirviendo nicamente como puntos de control del momento
de inicio de la actividad y del momento de terminacin. Las flechas no tienen
significado de escala, es decir, su longitud no est relacionada con el tiempo,
con el esfuerzo ni con el costo ya que nicamente representa que se ejecuta una
tarea entre dos sucesos.

O ------5------- <D
Figura 10.1 Representacin de actividades y sucesos
Todas las actividades se deben de representar en el modelo que formar la
red de actividades y sucesos considerando los siguientes puntos:
Se pueden crear actividades ficticias para solucionar algn tipo de
problema que pueda generarse considerando que este tipo de actividades
ficticias no consumen ni tiempo, ni recursos; este sera el caso del ejemplo de
la Figura 10.4 donde la tarea F puede comenzar una vez finalizadas las tareas
A, B y C pudiendo comenzar las tareas D y E cuando hayan terminado las
tareas A y B.

Todas las actividades estarn perfectamente definidas en cuanto a las

condiciones de inicio y finalizacin.
Las actividades pueden ser dependientes de otras anteriores mediante
relaciones de precedencia lineal.
Algunas tareas podrn comenzar cuando finalicen ms de una tarea, lo
que se denomina relacin de precedencia convergente.
En algunos casos ser necesario finalizar alguna tarea para que puedan
comenzar otras varias, lo que se denomina relacin de precedencia
divergente.
Se pueden dar combinaciones de todos los sistemas anteriores.

En algunos casos se puede necesitar la representacin grfica de un

proyecto en el que varias actividades pueden comenzar a partir de un suceso y
que su terminacin sea necesaria para comenzar el suceso siguiente. En estos
casos la nica forma de representa el diagrama es utilizando flechas curvas
como se representa en el siguiente diagrama:

Figura 10.2 Relaciones de precedencia convergentes


174 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
En algunas ocasiones, dependiendo del control a posteriori que se necesite
del proyecto, se pueden crear actividades ficticias al final de cada actividad real
cuando en un suceso converja ms de una tarea real. Estas actividades no
consumen recursos pero indican una relacin de precedencia. En estas
situaciones, y siguiendo con el ejemplo anterior, puede interesarnos la
conversin de la Figura 10.5 en la Figura 10.6.
Figura 10.6 Creacin de actividades ficticias para afinar el control del proyecto
Con todo ello se pueden crear un sistema que se debe enumerar mediante
el empleo de nmeros naturales para los sucesos con una numeracin
ascendente de izquierda a derecha. La forma de leer el grafo es: A precede a B ,
a C y a D; B, C. y D preceden a E. Pero cuando el proyecto es muy numeroso se
recurre a su representacin mediante una tabla de precedencias, en nuestro
caso:
Actividad Actividades Precedentes
A <
B A
C A
D A
E B, C y D
Figura 10.7 Tabla de relacin de precedencia
<
___________________________________C A P T U L O 10: P L A N IF IC A C I N D E L T IE M P O __________________________ 175
En otros casos se recurre a una matriz de encadenamientos que consiste en
colocar, en forma de tabla, todas las actividades del proyecto tanto en las filas '
como en las columnas y marcar con un 1 las situaciones en las que la
interseccin de cada fila con cada columna cumplan la relacin de precedencia,
es decir, aquellos casos en los que para poder comenzar la ejecucin de una (
tarea sea necesario haber completado la inmediatamente anterior, el resto de los
casos se marca con 0 .
(
Tanto de la tabla de relacin de precedencia como de la matriz de (
precedencias se puede obtener el grafo asociado segn el algoritmo de f
Denioucron 1 que parte de la matriz de encadenamientos descrita anteriormente i
y al que se van aadiendo columnas con los valores, para la primera columna
que denotaremos 1*, la suma algebraica de los elementos de cada fila. A partir
de esa columna se observan las posibles celdas con valor 0 restndose al valor
anterior la suma de valores de las columnas correspondientes a dichos valores ^
cero y creando la columna 2*. Cuando una celda obtiene el valor 0 se marcar ^
con un aspa (x) el resto de valores para las nuevas columnas creadas hacia la <
derecha. Se repite el paso anterior, columna a columna, hasta que la nueva
columna creada no tenga ningn valor superior a cero. La posicin de la ,
columna donde se encuentren ceros se marca, en una fila creada en la parte
inferior de la tabla con las filas en las que se encuentren dichos ceros, esto
significa que en ese nivel existe un suceso con ese o esos nmeros concretos.
Los niveles son descendentes siendo el primer nivel el de la celda de la parte f
inferior derecha de la tabla ampliada. (
i
El algoritmo puede resultar algo complejo pero se aclara bastante su
comprensin con la ayuda de un ejemplo ilustrativo, por ello vamos a
considerar la matriz de encadenamiento de la Tabla 10.8 de la cual vamos a
obtener su grafo asociado: (
(
<
(
<
1 El algoritmo de Denicucron nos facilita el nmero de niveles del grafo y qu sucesos se en- : '
cuentran en cada nivel siendo responsabilidad del jefe de proyecto representar el alcance de las (
actividades mediante las flechas correspondientes. / <
176 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 10: P L A N IF IC A C I N D E L T IE M P O 177

Actividad siguiente
1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1* 2* 3* 4* 5* 6* 7* 8* (.)*
1 [o r 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 / 1 1 1 I I 1 I 0
2 0 0 1 0 0 1 0 0 0 0 2 2 2 2 2 1 I 0 X
2 0 0 1 0 0 1 ___
0 0 0 0
3 0 0 0 1 0 0 0 0 0 0 I i 1 1 0 X X X X
3 |o "0 *o' 1 0 0 0 0 o 4 0 0 0 0 1 0 0 0 0 0 1 i 1 0 X X X X X
4 0 0 0 0 1 0 0 0 0 0 5 0 0 0 0 0 0
0 0 1 0 1 i 0 X X X X X X
5 (* 'o 0 0 0 0 0 0 ~f 0 6 0 0 0 0 0 1
0 0 0 0 ! i 1 1 1 i 0 X X
6 0 0 0 0 0 0 1 0 0 0 7 0 0 0 0 0 0 0 1 0 0 1 i I 1 1 0 X X X
7 fo 0 0 0 0 0 0 1 0 0 8 0 0 0 1 0 0 0 0 1 0 2 2 1 1 0 X X X X
9 0 0 0 0 0 0 0 0 0 1 1 0 X X X X X X X
8 0 0 0 1 0 0 0 0 1 0
T ~ 10 0 0 0 0 0 0 0 0 0 0 0 X X X X X X X X
9 jo 'o ~0 "o" " 0 0 0 suceso 10 9 5 4 3.S 7 6 2 1
T a b la 10.8 M a triz d e e n c a d e n a m ie n to nivel IX VIII V il VI V IV III II I

Vamos a aplicar el algoritmo de Demeucron para lo cual ampliaremos la matriz El grafo asociado ser:
de encadenamiento en varias columnas nuevas al final de la tabla que
4 5
denominaremos 1*, 2*, 3*, hasta un mximo de 10*, nmero de columna que
en el caso ms desfavorable posible tendremos que utilizar.

A la tabla as formada le aadimos una fila en la parte inferior que nos

servir para efectuar el recuento de los sucesos. Igualmente podemos incluir 6 7 8
otra columna debajo, igual que la anterior, para efectuar el recuento de los
T abla 1 0 .9 G r a fo a so c ia d o a a m a triz d e e n c a d e n a m ie n to a n te r io r
niveles para mayor comodidad.

Calculamos la columna 1* como suma algebraica de las columnas

anteriores y resulta tener un cero en la fila 10 que marcamos en la casilla
inferior de la fila de sucesos. Para obtener la columna 2* restamos de la 10.3 RED UCCI N DEL T IEM PO M EDIANTE LA
columna anterior la columna correspondiente al cero encontrado, en nuestro R EESTR U C TU R A C IO N DE LA RED.
caso la 10 , obtenindose los valores desarrollados en la tabla en letra cursiva.
As sucesivamente hasta agotar los valores significativos de cada columna Hasta el momento hemos completado las tareas de planificacin, nicamente
nueva creada que, si todo se ha desarrollado sin problemas, corresponder con sabemos que tareas se pueden comenzar cuando otras han finalizado, con lo
el nodo inicial del grafo. cual sabemos que tareas, de tener recursos suficientes, podramos realizar de
forma simultnea. El paso siguiente ser calcular la duracin de cada tarea que,
a su vez, podr calcularse por mtodos estadsticos o por mtodos
deterministas.

En primer lugar vamos a considerar mtodos deterministas, es decir,

considerar duraciones exactas de cada una de las tareas para simplificar el
problema. Al fin y al cabo se trata de determinar la duracin t (i,j) de cada una
de las tareas y determinar la duracin lo ms pronto posible en el que puede
comenzar y terminar cada actividad, a estos tiempos los denominaremos t (i) y
 t

178 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M A T IC O S C A P T U L O 10: P L A N IF IC A C I N D E L T IE M P O 179

/ Q) respectivamente. De igual forma se debern calcular los tiempos lo ms

tarde posible en que pueden iniciar y terminar cada una de las tareas sin Otra medida importante es la holgura libre4, que representa la holgura
retrasar el proyecto, a estos valores los denotaremos t*(i) y t*(j)2. Un mtodo disponible despus de realizar la actividad si todas las actividades del proyecto
para calcular los tiempos lo ms tarde posible es elegir el resultado mnimo han comenzado en su tiempo lo ms pronto posible. Su clculo se realiza con <
entre las diferencias de los sucesos posteriores y las duraciones de las tareas ayuda de la siguiente frmula: (
que soportan. Es decir:
/ / ,/ = t * (j) - l( i) - / (i,j) '

t*(i) = min [ t*(j) - t (i, j )] para i = 1 , 2 ,....

En todos los proyectos existen tareas que se pueden retrasar sin que la
duracin total del proyecto se vea alterada. Este tipo de tareas se denominan
flexib les mientras que otras sern inflexibles o crticas en el sentido de que
cualquier retraso en su cumplimiento pondr en peligro la duracin total del
proyecto. El anlisis del momento en el que se pueden ejecutar las tareas
flexibles nos ayudar a recortar la duracin del proyecto para ello vamos a
conocer el significado del camino crtico.
El camino crtico es la sucesin de tareas crticas del proyecto y constituye
el camino de duracin ms larga de todo el proyecto. El camino crtico
comienza siempre en el suceso inicial y termina en el suceso final pudiendo
haber ms de un camino crtico.
Un trmino relacionado con el camino crtico es de holgura, para ello
definimos la holgura de un suceso como la diferencia entre los tiempos lo ms
tarde posible y lo ms pronto posible de ese suceso, la denominaremos Hi y su
valor, en unidades de tiempo, es:
Hi = t*(j) - t(j)
La holgura de una actividad3 vendr dada por la frmula:
H j = t*(j) - t ( j ) - t (i,j)
siendo t*(j) el tiempo lo ms tarde posible del suceso final para terminar la
actividad, t (j) es el tiempo lo ms pronto posible del suceso inicial de la
actividad y t (i,j) la duracin de dicha actividad. Representa el tiempo mximo
que se puede retrasar una actividad sin aumentar la duracin del proyecto. Con
todo esto podemos volver a definir el camino crtico como la cadena formada
por las actividades cuyas holguras sean cero desde el principio al final del
proyecto.
La holgura flotante independiente es el tiempo que resulta de restar al '
tiempo lo ms pronto posible del suceso final el tiempo lo ms tarde posible del '
suceso inicial menos la duracin de la tarea. Su frmula es:
U J = > (!) ~ I *(i) ~ t (i,.j) (
Tambin se define, como consecuencia del ajuste de la red de flechas, la
holgura programada que tiene por objeto la distribucin de todo el tiempo de
holgura total segn criterios econmicos o de cualquier otra ndole.
Ejemplo: Se quiere instalar un ordenador con su correspondiente red de
rea local en una empresa y se conocen las tareas y los tiempos normales de
cada una de las actividades segn se describe en la Tabla 10.10 sobre la cual
hemos indicado el coste de cada actividad y la relacin de precedencia entre las
distintas actividades. Vamos a estudiar su duracin mediante el clculo de su
camino crtico. <
En primer lugar creamos la red de diagramas de flechas partiendo del
suceso inicial al que denominamos con el nmero uno. Sobre cada arco
marcamos la actividad y marcamos, igualmente, la duracin de la actividad
para tener una representacin grfica de los acontecimientos. ^
r
<
(
(
r

2 En algunas obras se denominan tiempo EARLY y tiempo LAST (

3 Tambin denominada Flotante total por otros autores. 4 O Flotante libre
(
(
180 PLA N IFIC A C I N Y GESTIN DE SISTE M A S IN FO RM TICO S C A PT U L O 10: PLANIFICACIN DEL TIEM PO

ACTIVIDAD Dur. Coste Prcd. ACTIVIDAD Tiempo Tiempo Holgura

A: Seleccionar la ubicacin del servidor 1 10 ms bajo ms alto
TAR Nodo Nodo Duraci lnici Fina] lnici Final Total Libre Independ
B: Acondicionamiento de la cd elctrica con UPS 4 20 A
EA Inicial Final on 0 0 ente
C: Instalacin del ordenador y S.O. 3 25 B i i tQJ) td ) *0) t*(i) t*(i) Hi " ./ Hu*
D: Crear usuarios y perfiles de acceso 2 50 G A 1 2 1 0 0 1 0 0 0
E: Instalacin cables de la red de dalos 2 60 A B 2 3 4 I 5 1 5 0 0 0
F: Configuracin de routers 1 30 E C 3 4 3 5 8 5 8 0 0 0
G: Configuracin de adaptadores de red 1 10 F L) 4 5 2 8 3 8 10 0 0 0
H: Optimizar funcionamiento de la red 1 10 G E 2 6 2 1 5 3 5 2 2 2
I: Comprobar segundad del S.O. 1 30 D F 6 7 1 3 6 5 6 2 2 2
J: Instalacin del Software de Gestin 1 10 I.II G 7 8 1 4 7 6 7 2 2 2
Tabla 10. JO T abla de actividades y re la c i n de p re ce d en cia H 8 9 1 5 10 9 10 4 4 4
I 5 9 1 10 11 10 11 0 0 0
J 9 10 1 11 12 11 12 0 0 0
Creamos una actividad ficticia entre los sucesos 8 y 4 para un mejor
control del proyecto y marcamos con un trazo ms grueso el camino crtico F igura 10.12 T a b la de apoyo p a ra e l c lca lo de las holguras
(figura 10.11). La suma de los tiempos de las actividades que sigue el camino
crtico es la duracin del proyecto; en nuestro caso 12 das. El coste total del Siguiendo con este ejem plo vamos a estudiar la forma de acortar el
proyecto es la suma aritmtica del coste de cada tarea; en nuestro caso 255 proyecto sabiendo que algunas tareas se pueden acortar en base a incluir ms
unidades monetarias. recursos con el coste extra mostrado en la tabla 10.13.

ACTIVIDAD Dur. Durac. Coste

inimm sxtra
a
A: Seleccionar la ubicacin del servidor 1
B: Acondicionamiento de la red elctrica conUPS 4 2 50
C: Instalacin del ordenador y S.O. 3 2 30
D: Crear usuarios y perfiles de acceso 2 1 15
Vam os a calcular las holguras del proyecto, para ello ampliaremos la tabla E: Instalacin cables de la red de datos 2 1 20
inicial con siete columnas que nos servirn de soporte para el clculo de las F: Configuracin de routers 1
distintos tiempos. G: Configuracin de adaptadores de red 1
H: Optimizar funcionamiento de la red 1 0,5 10
I: Comprobar seguridad del S.O. 1 0,5 5
J: Instalacin del Software de Gestin 1 0,5 10

T abla 10.13 T abla de a c tivid a d es con co stes e x tr a s i se a co rta n las d u ra c io n es

El procedimiento a seguir para acortar ia duracin de un proyecto

considerando un coste mnim o es un m todo por tanteo que consiste en
determinar todos los cam inos crticos a travs de la red, eligiendo las
 P L A N IF IC A C I N V G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 10: P L A N IF IC A C I N D H L T IE M P O 183

actividades con el mnimo coste por unidad de tiempo c(i, j) , reduciendo esta
actividad hasta que alcance su lmite tope de duracin o hasta que aparezca 10.4 El PERT Y EL CPM.
otro camino crtico. As paso a paso hasta llegar a un camino crtico en la que
todas las actividades tengan una duracin tope. Como se habr desprendido de la lectura de los apartados anteriores estamos
partiendo de unos datos exactos en el sentido de que suponemos conocer con
En el caso del ejemplo se alcanzar el tiempo tope reduciendo, en primer total certeza en la que cada tarea finalizar. Esto en los proyectos reales no es
lugar, la duracin de alguna de las actividades B, C, D o /, de ellas reducir la as sino que tendremos que basar nuestra estimacin en una serie de
que me resulte menos costosa, en nuestro caso la /; con esto he acortado la suposiciones que, en algunos casos, podremos basar en datos estadsticos. El
duracin del proyecto en media jornada a cambio de pagar cinco unidades anlisis de redes de tiempos basadas en el sistema PERT necesita disponer de
monetarias. El camino crtico sigue siendo el mismo y, como no puedo reducir datos adicionales para efectuar su clculo basado en la duracin de cada
ms la actividad I, la decisin estar en recudir alguna de las actividades B, C o actividad en cuanto a tres fechas:
D; en nuestro caso elijo la D por ser la ms econmica, con ello llevo una
reduccin de jornada y media a un precio de 20 unidades monetarias. La Fecha ms probable
siguiente eleccin sera reducir B en dos jornadas a cambio de pagar 50 Fecha ms optimista
unidades con lo que la reduccin total del plazo es de tres jomadas y media. Fecha ms pesimista
Finalmente, por el momento, reduzco C que es la actividad ms cara en media
jornada, con lo que el proyecto se ha rebajado, en duracin, en cuatro das Se entiende por fech a ms probable (ni) aquella cuya ejecucin en el
teniendo dos caminos crticos. tiempo es la normal y cuya estimacin est basada en la repeticin continua de
actividades similares en las mismas condiciones de trabajo.
A continuacin podemos rebajar la actividad J e n media jornada por ser la
ms econmica con lo que la reduccin es de cuatro jornadas y media La fe c h a ms optimista (a) sera aquella en la que la duracin de la tarea se
continuando con dos caminos crticos. An se puede reducir C en media realizara si todo marcha en condiciones ptimas, es decir, sino se produce
jornada con lo que tendr que reducir media de E con un coste de 10 con lo que ningn tipo de improviso que pueda retrasar la tarea.
el proyecto ha quedado de la siguiente forma:
La fe c h a ms pesim ista (b) sera la duracin de aquella actividad que se
Actividad Duracin Coste extra realiza en contra de todo tipo de circunstancias normales que puedan suceder5.
A 1 0
B 2 50
C 2 30 Una vez que se hayan facilitado estas tres fechas obtendremos la
D 1 15 estimacin de la inedia de la actividad como:
E 2 0 ^ a + 4m + b
F 1 0
G 1 0
I) 1 0
I 0,5 5 La funcin de distribucin de la duracin de las tareas suele estimarse
J 0,5 10
TOTAL 7,5 110 mediante la funcin Beta, cuya distribucin de la variable aleatoria t
comprendida en el intervalo [a, b] es
Tabla 10.14 Tabla de actividades con costes extra y duracin optimizada

Es decir, se puede recortar el tiempo de ejecucin del proyecto hasta en

cuatro das y medio.

5 Se deben desestimar condiciones muy extremas que pueden hacer que la duracin de una
tarca sea infinita.
184 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P IT U L O 10: P L A N IF IC A C I N D E L T IE M P O 185

/ ( / ) = 0 ,/ < a
C -C
c ( i j ) = -------------T
------.
A0 = - D(,j)-d(i,j)
( b - a ) a***'p(a + U<p + l)
f(t) = 0,b<t

y que en el sistema PERT se selecciona

CC = 2 H-

(p = 2 - 4

cuando la moda es mayor que (a + b) / 2 .

O se elige
a =2~4l
(p = 2 +

en otro caso. Figura 10.15 Relacin normal entre la duracin y el coste directo de una actividad

El valor de la varianza viene expresado por la frmula: Con esta nueva variable CPM estudia el proyecto tanto desde el punto de
vista de duracin ptima como de coste mnimo. El procedimiento para la
programacin con CPM consiste en partir de lo que se considera todo normal
en programacin temporal con lo que, despus de los ajustes iniciales, el coste
total suele ser mnimo y la duracin la ms larga.
Es importante resaltar que el valor ms probable ni, en la funcin de
distribucin Beta no se corresponde con el valor de la mediana, que
normalmente quedar a la izquierda de la fecha ms probable, por la asimetra Ejemplo 1
de dicha funcin de distribucin.
Representar de forma grfica, mediante el mtodo PERT, la siguiente tabla de*
Una vez obtenidos los valores Z), el mtodo PERT reduce el caso relacin entre actividades:
probabilstico a determinstico por el hecho de utilizar la media de las Actividad Actividad
Actividad
duraciones de todas las tareas como media del proyecto con la consiguiente Precedente Siguiente
simplificacin matemtica del problema al que se le puede aplicar la teora A CJO
mostrada en el apartado anterior. B - E,FtG
C A E
D A E,F
La programacin por CPM introduce la variable de costes que pueden
E B,CJD H
sufrir modificaciones por su alargamiento o acortamiento segn ciertas F BJD H
funciones de distribucin. De esta forma a una duracin tope de cada tarea del G B I
proyecto d (ij) se le asigna un coste tope CY, a una duracin normal, D (ij),iin H E,F I
coste normal Cv y a una duracin mnima un coste mnimo. El valor de los I H,G -
costes entre los tiempos normal y tope se suele calcular por interpolacin lineal
entre ambos extremos, as el incremento de coste
186 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 10: P L A N IF IC A C I N D E L T IE M P O 187

La duracin de cada actividad la proporciona la tabla: En un nodo intermedio es el mnimo de los valores calculados para cada uno de
sus nodos antecesores. El valor calculado para cada uno es su fecha ms tarda
Actividad Optimo Psim o P robable Calculado menos el tiempo de la actividad que los conecta.
A 2 2 2 2
B 4 16 7 8 -Por ltimo la holgura.
1 9 2 3
En cada nodo es la diferencia entre la fecha ms tarda y la ms temprana.
C
D 1 10 4 4
D eterminar el camino crtico:
E 7 15 9 10
F 2 14 8 8 El camino crtico es el que determina la duracin del proyecto y esta formado
G 4 18 8 9 por el conjunto de nodos que determinan el camino ms largo.
H 2 3 2 2 Estos nodos tienen como caracterstica que su holgura total es cero y se les
I 6 10 9 8 llamaran sucesos crticos.

Vamos a tener en cuenta las normas de representacin siguientes: Obtencin del grajo:

Representacin de un nodo:

OT = Ocurrencia temprana Early, aqu se indica el momento o punto en

el tiempo donde se puede dar el evento.
OL = Ocurrencia tarda o mas lejana, Last, aqu se indica el momento o
punto en el tiempo mas tardo en que puede ocurrir el evento.
Ht = Holgura Total de que se dispone para la ocurrencia del evento.
# = El nmero asignado a cada nodo que el numero de identificacin del
suceso.

Clculo de los tiempos de los nodos:
-Primero calcular las fechas ms tempranas.
En el nodo inicial es 1.
En un nodo intermedio es el mximo de los valores calculados para cada uno
de sus nodos predecesores. El valor calculado para cada uno es su fecha ms
temprana ms el tiempo de la actividad que los conecta.
-Despus calcular las fechas ms tardas.
En el nodo final es la misma que la ms temprana.__________________________
Para obtener las ocurrencias ms lejanas y ms tempranas hemos tenido que
aplicar el clculo de valores mnimos y mximos. Por ejemplo la ocurrencia
ms temprana del suceso 5 se calcula como el mximo de 9 (ocurrencia ms
temprana del suceso 3 + tiempo de la actividad F l) y 7 (ocurrencia ms
temprana del suceso 2 + tiempo de la actividad D). Otro ejemplo, la ocurrencia
ms tarda del suceso 2 se calcula como el mnimo de 6 (ocurrencia ms tarda
del suceso 4 - tiempo de la actividad C) y 5 (ocurrencia ms tarda del suceso 5
- tiempo de la actividad D).
Camino crtico:

Lo componen las actividades B, E, H e I._______ ___________________________

188 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 10: P L A N IF IC A C I N D E L T IE M P O 18 )

Despus se pondr la cabecera Camino y su nmero y, bajando, se definen

Ejemplo 2 los posibles caminos del proyecto (uno por fila), escribiendo la actividad en su
columna correspondiente si forma parte del camino. Se aaden ms filas, una
Dada la siguiente tabla de actividades, su duracin y relaciones de precedencia, por camino, indicando con un uno cuando la actividad correspondiente
obtener una representacin grfica sencilla sin tiempos y calcular el camino intervenga en el camino y con un cero cuando no.
crtico mediante una tabla. En las mismas filas de cada camino y a continuacin de la ltima columna que
tendr la ltima actividad del proyecto, se calcula la duracin del camino,
Actividad Predecesora Duracin
correspondiente a dicha fila, sumando los resultados de multiplicar los valores
A - 10
de la fila (sucesin de unos y ceros) por la fila de los tiempos de las
B - 50
actividades.
C B 20
D A
Se determina la suma mayor, que representar la duracin del proyecto, y las
15
E C 5
actividades que forman el camino crtico vendrn dadas por aquellas
F B
actividades del camino crtico que tengan un uno.
20
G C 40 Actividad A B C D E F G H I J
H G ,F 30
Duracin 10 50 20 15 5 20 40 30 10 25
1 D,E 10
J l.H 25 N odo inicial 1 1 3 2 5 3 5 6 4 7

Grfico sin tiempos: N odo final 2 3 5 4 '4 6 6 7 7 8

Cam ino 1 A D I J
D
Cam ino 2 B C E I J

C am ino 3 B C G H J

C am ino 4 B F H J

C am ino 1 1 0 0 1 0 0 0 0 1 1 60

Cam ino 2 0 1 1 0 1 0 0 0 1 1 110

Cam ino 3 0 1 1 0 0 0 1 1 0 1 165

Cam ino 4 0 1 0 0 0 1 0 1 0 1 125

Para cada uno de los cuatro caminos calculamos su duracin, sumando la

Metodologa de construccin de la tabla: duracin de las actividades en las que aparezca un 1 :

Se construye una tabla donde se muestran cada una de las actividades del 10+15+10+25 = 60
proyecto. Existir en cada fila una columna de cabecera y el resto de datos. 50+20+5+10+25 = 110
A continuacin, en la fila siguiente, la palabra Duracin y la duracin de 50+20+40+30+25 = 165
cada actividad. 50+20+30+25 = 125
En las tres filas siguientes de la tabla, se definen el Nodo Inicial (el nodo de
comienzo de cada actividad) y el Nodo Final (el nodo de terminacin de cada El camino crtico es el tercero y est formado por las actividades: B, C, G, H y
actividad). _____________________________________________ J.
 (

190 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 10 P L A N IF IC A C I N D E L T IE M P O 191 f

El camino crtico ser (nodos): 1-2-6-7-8-4-5-9-10

Ejemplo 3 El proyecto tarda un tiempo total de 13 das.

Veamos un diagrama que nos muestra la construccin de un arco: Supongamos que podemos disminuir ciertas actividades en un periodo de
tiempo con un coste adicional, como muestra la tabla:

Coste
ACTIVIDAD Das
F.Ytffl
A: Lugar de emplazamiento 1
B: Hoyo cimientos B 4 2 40
C: Cimientos hormign B 3 2 20
D: Colocar plinto 2 1 10
E: Hoyo cimientos A 2 1 20
F: Cimiento hormign A
G: Preparar ton e A
H: Colocar tone A 1/2 10
Tenemos una tabla con sus actividades y duracin: I: Colocar torre B 1/2 10
Di as
J: Colocar el arco 1/2 10
ACTIVIDAD
A: Lugar de emplazamiento i
B: Hoyo cimientos B 4
C: Cimientos hormign B 3 Aplicando estas disminuciones de tiempo conseguimos un ahorro de 5 das,
D: Colocar plinto 2 realizndose el proyecto en 8 das, con un coste adicional de 120. Podemos
E: Hoyo cimientos A 2 verlo en la siguiente representacin:
F: Cimiento hormign A 1
G: Preparar torre A 1
H: Colocar torre A 1
I: Colocar torre B 1
J: Colocar el arco 1

Representamos la tabla mediante un grafo:

En este caso hemos ahorrado tiempo fuera del camino crtico aumentando el
coste, a veces, esto no compensa. En este ejemplo la actividad I puede tardar
192 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 10: P L A N IF IC A C I N 13l.il.T IE M P O 193

un da o medio, es indiferente, ya que en el nodo 9 el valor temporal ser 6,5 o A 6.-Estudio de ofertas y adjudicacin concurso (10 das).
7, segn el caso, siempre menor que 7,5 que es el tiempo por el camino crtico. A7.-Estudio de viabilidad (30 das).
Lo mismo ocurre con la actividad E que puede tardar uno o dos das, valores A 8 .-Formacin del personal (60 das).
que en el nodo 4 son indiferentes ya que el tiempo del camino crtico es 6 . A9.-Instalacin del equipo (5 das).
A 10.-Plazo de entrega del equipo seleccionado (40 das).
Obtenemos el siguiente grfico optimizado, en el que, sin cambiar el camino A l 1.-Preparacin cuaderno de especificaciones de H/S (10 das).
crtico disminuimos el tiempo total 5 das (tiempo del proyecto 8 das) con un A12.-Preparacin de la infraestructura necesaria para albergar el C.P.D.
coste de 90. (68 das).
A13.-Preparacin del Manual de Produccin (8 das).
A14.-Preparacin del Manual de Usuario (6 das).
A15.-Pruebas globales (10 das).
A16.-Seleccin de personal (10 das).

Vamos a disear el diagrama Pert correspondiente a dicho proyecto, teniendo

en cuenta el orden lgico de las actividades: pueden realizarse en paralelo las
tareas relativas a la preparacin del personal, del H/S y de la infraestructura;
tambin se realizarn en paralelo las aplicaciones de Nmina y Contabilidad y
posteriormente los manuales de usuario y de produccin. El sistema no puede
arrancar hasta que todo esto est terminado. Consideramos que las actividades
que se realizan en paralelo no tiene por que terminar en el mismo momento,
por lo que se puede usar las actividades ficticias necesarias. Vamos a calcular y
mostrar en el diagrama la holgura de cada actividad.

Ejemplo 4

Una empresa de consultora ha recibido el encargo, por parte de la empresa EF,

de acometer la creacin de su Centro de Proceso de Datos, necesitando
inicialmente solamente las aplicaciones de Nmina y. Contabilidad, teniendo en
cuenta la total ausencia de mecanizacin existente en la actualidad. La
consultora prepara un proyecto que incluye las siguientes actividades,
ordenadas alfabticamente:

Al.-Arranque del Sistema (duracin 2 das).

A2.-Convocatoria concurso pblico para adquisicin de H/S (5 das).
A3.-Diseo, anlisis, codificacin y pruebas unitarias de la aplicacin de
Contabilidad en el propio centro (210 das).
A4.-Diseo, anlisis, codificacin y pruebas unitarias de la aplicacin de
Nmina en el propio centro (190 das).
A5.-Diseo de la organizacin del C.P.D. (5 das)._____________________
194 PL A N IF IC A C I N ' Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Camino crtico: A7, A5, A 12, A9, A3, A 15, A 13, A 1
Analicemos el siguiente supuesto: Si la empresa se ha comprometido a
finalizar segn el plazo obtenido con el mtodo Pert y sabiendo que en el
contrato de realizacin de este proyecto existen clusulas de penalizacin (300
/da) y de premio (800 /da) y que es posible aumentar o disminuir ciertas
actividades segn la tabla adjunta (hasta un mximo de un 50% de la duracin
total de la actividad), debera la empresa retrasar o adelantar la fecha de
finalizacin del proyecto modificando el tiempo de alguna de las actividades de
la tabla?.
A ctividad A lio n o d e c o ste por lard ar un da m s C oste a d icio n a l por
m enos
A3 60 149
A8 120 100
\n 80 100 e
A 14 30 70
Podemos disminuir la actividad A 12 en tres das, ya que los caminos paralelos
tienen esa holgura. No podemos disminuirla ms, porque el camino paralelo de
la rama de A l 1 no tiene posibilidad de disminucin, aunque si la tenga el de la
A 8 (no interesa disminuir en este porque tiene holgura). El coste mayor de esta
accin es 3*100 = 300 . Por otro lado podemos disminuir la actividad A3 en
20 das que es la holgura de su actividad paralela. El coste de esta accin es
20*149 = 2.980 . No merece la pena disminuir la actividad A 14 porque no
forma parte del camino crtico. El coste total es 300+2.980 = 3.280 y como
tenemos un premio de 800 /da, la disminucin de coste conseguida con esta
opcin es (800*23)-3.280 = 18.400-3.2800 = 15.120 . Adems, podemos
ahorrar retrasando las actividades no crticas con holgura sin retrasar el
proyecto (en esta nueva situacin solo la A14) y aumentar as el beneficio:
2*30 = 60 . Como conclusin: entregando el proyecto 23 das antes de lo
previsto y suprimiendo las holguras tendramos un beneficio de 15.120+60 =
15.180 e.
Si consideramos la opcin de retrasar el proyecto, vemos que la penalizacin
son 300 /da que en ningn caso supera el ahorro de coste por disminuir un
da cualquier actividad del camino crtico. Incluso considerando el ahorro de
suprimir las holguras posibles (A 8 y A14) nunca conseguiramos un beneficio
como el del prrafo anterior.
C A P T U L O 10: P L A N IF IC A C I N D EL T IE M P O 195
10.5 M TODO ROY.
Es otro modelo matemtico de planificacin desarrollado por el matemtico
Bernard Roy en Francia, se le conoce tambin como el mtodo de los
potenciales o MPM.
Se diferencia del PERT/CPM bsicamente en dos aspectos:
Forma de construccin de la representacin grfica. Los nodos o
vrtices del grafo representan a las actividades, mientras que en
la rd a r un da
PERT/CPM representaban sucesos, y los arcos o flechas tan solo las
relaciones entre ellas, mientras que en PERT/CPM eran las actividades
propiamente dichas. Al representarse las actividades en los nodos no es
necesario la utilizacin de actividades ficticias, aunque se creen por
facilidad de comprensin dos actividades: de inicio y de fin, que sern
en todos los diagramas Roy las actividades de partida y finalizacin. La
forma de representar las actividades son cuadrados como muestra la
siguiente figura:
1: Cdigo.de Actividad
2: Tiempo mnimo de comienzo
3: Tiempo mximo de comienzo
4: Duracin de la actividad
Figura 10.16 Forma de representacin de una actividad en Roy
Tipo de relaciones que se pueden manejar entre actividades. Permite
relaciones Fin-Comienzo (para empezar la siguiente hay que terminar la
anterior) y Comienzo-Comienzo (para empezar la siguiente hay que
empezar la anterior, pero no es necesario haberla terminado) mientras
PERT/CPM solo relaciones Fin-Comienzo. Para representar las
relaciones de dependencia entre actividades, se utilizan los arcos del
grafo, sobre los que se inscribe la duracin de la actividad precedente,
permitiendo incluir el concepto de demora, el cual indica cuanto tiempo
despus de que termine (relacin Fin-Comienzo) o empiece (relacin
Comienzo-Comienzo) una actividad debe empezar la siguiente. Las
figuras 10.17 y 10.18 muestran ejemplos de cada uno de los dos tipos
de relacin y el uso de la demora. En las relaciones Fin-Comienzo se
debe colocar sobre el arco un valor equivalente a la duracin ms el
retardo o demora. En las relaciones Comienzo-Comienzo se debe
196 P L A N IF IC A C I N Y G E S T I N D E S I S T E M A S IN F O R M T I C O S C A P T U L O 10 P L A N IF IC A C I N D E L T IE M P O 197

colocar sobre el arco un valor equivalente al retardo o demora, siempre

y cuando el retraso sea menor que la duracin de la actividad PERT/CPWI Roy
predecesora. Si no fuese as estaramos ante una relacin Fin-Comienzo
(habra terminado la anterior, ya que el retardo es mayor que su
duracin, cuando empieza la siguiente).

Figura 10.17 Demora en lina relacin Fin-Comienzo

En esta figura la actividad B no puede comenzar hasta que pasen D

unidades de tiempo despus de terminar la actividad A.

A H
^ T
Figura 10.18 Demora en una relacin Comienzo-Comienzo o - ^ o
En esta figura la actividad B no puede comenzar hasta que pasen D
unidades de tiempo despus de empezar la actividad A, es decir, la actividad A
Figura 10.19 Representacin de las mismas relaciones entre actividades segn
debe comenzar D unidades de tiempo antes que la actividad B.
PERT/CPM y Roy
La figura 10.19 muestra algunos ejemplos de cmo se representan las
En un grafo del mtodo Roy para obtener los tiempos mnimos y mximos
mismas relaciones de precedencia entre actividades segn los mtodos
de com ienzo, la holgura y el camino crtico, seguimos bsicamente los mismos
PERT/CPM y Roy.
pasos que en el PERT/CPM:

Se comienza por asignar una actividad de inicio con un tiempo mnimo

de comienzo de 0 y una duracin 0. A continuacin se van dibujando
las restantes actividades con sus correspondientes dependencias hasta
llegar a la ltima o ltimas, que terminarn en una actividad de fin, con
duracin cero.

Los tiempos mnimos de com ienzo de la actividad i es el mayor de las

sumas del tiempo mnimos de las actividades precedentes ms el valor
de la flecha que le llega de cada actividad precedente. Se calculan todos
los tiempos m nim os hasta llegar a la actividad de fin, cuyo tiempo
mnimo indica el tiempo mnimo necesario para realizar el proyecto.
108_____________________ P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S _________________________ C A P T U L O 10: P L A N IF IC A C I N D E L TIEM PO

Para calcular el tiempo mximo, se parte de la actividad de fin, en la A ll holgura 3

que se pone el tiempo mximo, que ser igual al tiempo mnimo A2 holgura 3
previamente calculado. Se prosigue con el clculo de los tiempos A6 holgura 3
mximos del resto de actividades, siendo este para la actividad / el A10 holgura 3
menor de los valores obtenidos, para cada actividad que nace de la A4 holgura 20
actividad /, restando del tiempo mximo de la actividad siguiente el A14 holgura 2
valor del arco correspondiente que nace en la actividad /.
El camino crtico es A7, A5, A12, A9, A3, A15, A13, Al
La holgura de cada actividad se calcula mediante la diferencia entre sus
tiempos mximo y mnimo. El camino crtico viene indicado por
aquellas actividades que tienen holgura total nula.

10,6 ANLISIS DE LAS REDES COMO HERRAM IENTA

BASICA.

Recordemos que la curva de coste directo de una actividad se puede

reducir a una recta de la forma:

(' = b(i, j) - c(i, j) t(i, j) [ 10 . 1 ]

siendo c(i, j ) el coste por unidad de tiempo o inclina-in de la recta de

aproximacin.

La duracin de la actividad es t(i,j) y vara dentro de las duraciones D(i, j)

y d(i,j), es decir:

0 < d(i,j) < t(i,j) < D(i, j) [10.2]

El coste directo P(l) es la suma de todos los costes directos individuales

con los t(i, j) bien determinados

IU) = 'Z 'lH iJ ) - c ( i j ) t ( i , j ) [10.3]

>,j

El problema que se plantea aqu es minimizar la ecuacin anterior [10.3]

condicionada a la ecuacin [ 10 .2 ] y considerando las siguientes restricciones:

t(J)<t(j)-t() [10.4]
(0) = 0, t(n) = / [10.5]

donde t (j) y t(i) son los tiempos lo ms pronto posible de terminar y comenzar
para el suceso (i, j) de una actividad determinada; t(n) es el tiempo lo mas
200 PLANIFICACIN Y GESTIN D E SISTEM A S INFORMTICOS CAPTULO 10: PLANIFICACIN DEL TIEMPO 201

pronto posible de terminar el ltimo suceso de la red con un proyecto de n+I y as nuestro problema se limita a resolver la programacin lineal
sucesos, como (())-() el tiempo en el ltimo suceso es / paramtrica. Para ello, en primer lugar generalizamos el problema a solucionar:
Se trata de encontrar el mximo de
La dificultad est en cmo encontrar un conjunto de t(ij) de la red con el
m axZ = a0lX , + tf02A \ + ... + c/0A'
coste directo total mnimo, para cada posible valor de /
donde
Vamos a replantear el problema en forma de programacin lineal
aliX ] + al2X 2+... + a]uX <ai0
paramtrica:
Partimos de unas condiciones fijas: Ct2^ \ j + Ojj X j + --- + OyltX tf C2Q

l ( i j ) < D(iJ) amX l + am2X 2 +... + amnX u < oinrO

- t ( i j ) < -d(i,j)
con
y de unas condiciones paramtricas:
^ , > 0 , ^ 2 > 0 ,.. ., X > 0

2 > (/j)< / El primer paso para resolver el problema es convertir el sistema de m

inecuaciones en un sistema de m ecuaciones aadiendo unas variables
y y y
*2 it + P ^ i r + 2 w + w

complementaria:

de esta forma sistema de inecuaciones anterior se trasforma en:

axxX x+ an X 2 + . + aUtX a + X l}^ = alQ

m ili /(/) = J ^ [ b ( i j ) - c ( i , j ) l ( i , j ) ] ^ 22 ^ 2 + ***+ a 2 n ^n + ^ n+2 = **20

donde Ri indica el camino que conduce a una determinada duracin del

proyecto 1, con una funcin objetivo:
Pero minimizar la funcin anterior es lo mismo que maximizar [c(it j), t
as podemos escribirlo como: o lo que es lo mismo:

p (o = YJ aXJ + = ,0; para i = 1,2, m

pero el primer trmino de la ecuacin es una constante, por tanto el problema

de encontrar el coste mnimo de P(l) es igual a maximizar la funcin: Ajustando trminos y ordenando se obtiene:

m a x^ciiJX iJ)
con las restricciones siguientes:

t ( i j ) +l ( i ) - t ( j ) < 0
-/(O ) + / ( ) < /

-l(iJ)< -d(J)
202 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 10 P L A N IF IC A C I N D E L T IE M P O 203

YM+,l >
""0 1, r I-,2 >
0 ,... 1Y,,4,
> 0V
X+i = ,o + 'Y ja l, x ,
/=!
Con esto la funcin a maximizar se convierte en: Restando las variables complementarias Y, Y2>... Y n los primeros trminos
de cada inecuacin, quedan convertidas en ecuaciones:

+ 21^ll+2 + + ml^Ji+M ~ Y = 01

tna x Z = a00 + J ] a (lX l ^ir+1 + 22^1+2 + + m2^ n+w ~ Y2 = a02

1=1
A esta funcin primal la aadimos unas nuevas variables
lU,K,*l + a 2,y,2 ~ a0
Ym+1 1 Yn+2 Yn+/M
que, de forma simplificada, se puede escribir como:
y obtenem os una funcin dual de la primera de forma que los trminos m
constantes de la primal sean los coeficientes de la dual y viceversa.
~ Yi = ao J - l a0Y

Los coeficientes de las variables de las condiciones restrictivas del dual se

obtienen por la trasposicin de la matriz de los coeficientes de las condiciones y la funcin objetivo es:
del primal, cambiando la direccin de las inecuaciones y minimizando la
funcin objetivo de la dual.
m
min W = a 00 + a Kt( con aM = 0
7=1
min W = a 10rt + alYtl +... + am0Ytm
con estas ecuaciones del primal, y las dual, podemos formar un cuadro
o de forma sim plificada simtrico que se resuelve mediante el algoritmo del simplex :

j=i
- y , - r 2 - y
- f j

00 0. 02 0 0
con sus condiciones restrictivas: j = Z o

K . i 10 u 12 % 1
a uKnl + 2 . ^ 2 + - + S 01 20 21 22 2 .,
y 2 J = * , . 2

12^11+1 + 22 Kn 2 + + m2^im a02

n * ,o ,1 '2 J , = X n+l
a \nY+l +Cl2nY,,+2 + + a m,X,*m ^ 0

Y m a i i , , /,, = X+m
que puede sim plificarse como:
m f r e x , * 2 ^ 7 x .

w = con J = L2 ,...,h
7=1

y con la condicin de que

204 P L A N IF IC A C I N Y G E S T I N B E S IS T E M A S IN F O R M T IC O S

Como puede apreciarse la dificultad del mtodo hace que para estimaciones
prcticas sea necesario el empleo de herramientas informticas de ayuda al
clculo de las redes CPM.

CAPTULO 11

PROGRAMACIN DE RECURSOS

En la presente unidad temtica se estudiarn las tcnicas de anlisis de red para

la aplicacin prctica de planificacin de proyectos informticos a la vez que se
efectuar un estudio sobre las fluctuaciones. Se incidir en la definicin de
herramientas para representar la descomposicin en funciones de un proyecto,
los entregables y sus responsables. Se efectuar la planificacin del cash-flow y
se estudiarn las caractersticas fundamentales de la retroalimentacin en la
programacin y planificacin de proyectos.

11.1 HOLGURAS DE LA ACTIVIDAD Y PLANIFICACIN DE

RECURSOS: CMO UTILIZAR LAS FLUCTUACIONES
TOTALES, LIBRES E INDEPENDIENTES, EN BENEFICIO DEL
PROYECTO?

A veces, la utilidad del estudio de las holguras y fluctuaciones las actividades

de un proyecto resultan difciles de comprender y mucho ms difcil de
entender su utilidad en la vida real de los proyectos informticos debido a que
durante el proceso de ejecucin del proyecto nos encontraremos con la
verdadera dificultad de lograr los recursos necesarios de forma puntual por los
problemas que se van a presentar en el da a da.

En la planificacin de recursos se encuentra una de las aplicaciones de

fluctuaciones ms prcticas y por eso resulta conveniente que nos centremos en
este tipo de problemas de una forma detallada.

El problema normal en la ejecucin de los proyectos es debido a que se ha

partido, normalmente, de una planificacin excesivamente optimista debido a
que suele existir un plazo ya comprometido con el cliente o con la propia
organizacin que no puede ser alterado porque la organizacin no tiene
posibilidad de efectuar cambios sobre esos calendarios o porque, como
206 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
organizacin productora, 110 queremos contrariar a nuestro cliente. En muchas
ocasiones se subestima el proyecto porque inicialmente parece apetitoso por la
cantidad de dinero que se puede obtener del mismo sin efectuar ms
investigacin sobre las posibilidades del mismo que el beneficio generado
directamente para cada uno de los participantes. Muchas veces sucede que un
proyecto comienza con una estimacin realista, tanto en plazos, costos y
objetivos, pero se ve afectada por unos cambios que se van sumando a las
prestaciones totales del sistema y que no permiten que se efecte una nueva
planificacin porque, alguien, los considera de poca importancia. En otros
casos es el propio equipo del proyecto que valora errneamente el proyecto
bien por falta de experiencia o bien porque desea obtener una contraprestacin
adicional.
Con todo esto, a partir de una planificacin muy optimista, que no realista,
obtendremos una serie de consecuencias que se manifestarn si se quiere seguir
esa planificacin: En primer lugar deberemos de citar que el primer sistema
resentido de esta excesiva planificacin optimista es la calidad del propio
producto y su propia planificacin. El hecho de tener unos hitos errneos har
que las revisiones y controles formales no se efecten a tiempo con el
consiguiente retraso y las posibles vistas gordas en tales procesos con tal de
garantizar el cumplimiento del tiempo. Esta falta de control en las etapas
tempranas del desarrollo para tratar de ajustarse a esos tiempos de finalizacin
de tareas hace que en las pruebas finales se pierda mucho ms tiempo que el
que se hubiera perdido en la prueba de cada mdulo, su integracin y la
adaptacin al usuario aunque nicamente sea en retocar los manuales de
usuario1. Los retrasos que se producen por el hecho de tratar de apretar en la
planificacin pueden llegar a ser tan importantes como el ciento por ciento del
tiempo2 y hasta tres veces en el coste del producto.
La fuente de los problemas est en que los recursos necesarios para
realizar el trabajo no siempre estn disponibles y, en muchos casos, no estn
debidamente controlados. Por ello, antes de asignar los recursos a las tareas
debemos efectuar una serie de preguntas relativas al grado de importancia de
efectuar un control y garantizar su disponibilidad. Efectuar el control
exhaustivo puede ser interesante en algunos desarrollos en los que los recursos
deben de estar fuertemente utilizados y no se pueden permitir tiempos perdidos
en la entrega del trabajo lo que nos llevar, nuevamente, a definir el grado de
1 Scott H. Costello comenta en su artculo "Software engineering under dadiine pressure",
A C M S ig so /t Software Engineering Notes, octubre 1994, p. 15-19, los efectos perniciosos de la
presin de la planificacin sobre las buenas formas de los mtodos de la ingeniera del software
y el desvio real que se produce cuando se quiere garantizar la calidad del producto.
2 Standish Group, 1994
C A P T U L O I I : P R O G R A M A C I N DE R E C U R S O S 207
detalle en que se deben de definir las tareas y el tiempo empleado en tal
definicin. En cuanto a garantizar la disponibilidad del recurso es importante
conocer las responsabilidades relativas a la realizacin del trabajo en el sentido
de poder obtener respuesta a la exigencia en caso de no haberse desarrollado el
trabajo que, a su vez, por regla general, es que los recursos no estaban en el
momento en que se necesitan. Todo ello nos hace preguntamos por tres
cuestiones: Tipo de recursos a emplear, su calendario de utilizacin y la forma
de conseguir esos recursos con garantas.
En cuanto al tipo de recursos que necesitamos podemos considerar dos
tipos de recursos: recursos materiales y recursos humanos o de trabajo. Los
recursos materiales estn formados por todo aquello que supone una
infraestructura fsica para poder desarrollar el proyecto; es decir, las mquinas,
lneas de comunicaciones, entornos software, consumibles, documentacin y
todo aquello que se estime necesario para lograr el objetivo del proyecto con
exclusin de las personas. Los recursos humanos (o de trabajo) son las
personas que controlan las mquinas y desarrollan las labores de trabajo
humanas necesarias, y que complementan a los recursos materiales, en la
realizacin del proyecto.
E 11 principio tenemos creada la lista de objetivos del proyecto y tambin
las tareas que deben de cumplirse, junto a sus relaciones de dependencia, para
poder satisfacer el proyecto. Ahora tenemos que buscar los mejores recursos
para satisfacer cada una de las tareas. Tendremos que responder preguntas
como disponemos del personal adecuado para realizar cada una de las
tareas?Tendremos que subcontratar tales actividades?Podemos emplear a
personas polivalentes que puedan realizar fases de trabajo distintas?Es
necesario adquirir licencias del entorno de desarrollo concreto?Es necesario
reservar tiempos de mquina en explotacin para realizar las pruebas?Puede el
departamento cliente formar parte de las pruebas durante los das que el
calendario nos indique?Cul es el calendario de trabajo la empresa y hasta
dnde se pueden exigir el cumplimiento de horas extraordinarias si ello fuese
necesario?Se ha previsto que nuestro proyecto puede necesitar recursos que
otro proyecto de mayor importancia absorba en contra nuestra?Se ha previsto
la cantidad de consumibles necesarios para el proyecto? Y una larga lista de
preguntas que la experiencia e intuicin del director de proyecto deber de
desarrollar.
Puede suceder que de la lista de preguntas anterior, o de la ampliada por su
propia organizacin, encuentre algunas preguntas de las que no tenga respuesta
posible; en tal caso revise su plan y no deje cuestiones para el futuro, hable con
208 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
sus jefes y trate de afinar las respuestas porque en algunos casos las preguntas
sin respuesta se deben a una planificacin no realista o confusa.
Con las respuestas apropiadas decidimos quien, que y cuanto tiempo de
calendario vamos a asignar para satisfacer cada una de las tareas considerando
el mejor rendimiento de las personas y de las mquinas. Es decir, salvo que se
quiera otra cosa, se tratar de emplear a las personas concretas en aquellos
trabajos que realizan de una forma ms eficiente.
Tambin es necesario considerar que en la mayora de los proyectos
informticos, la relacin entre recursos humanos y recursos materiales suele
tener una relacin muy estrecha ya que de nada servira obtener ms puestos de
trabajo para desarrollar con una determinada herramienta si finalmente no
tendremos ocasin de tener esa misma cantidad de desabolladores o a la
inversa: Puede no ser necesario utilizar una cantidad de programadores para
satisfacer las tareas de codificacin si el nmero de terminales disponibles no
puede ser superior o si no se pueden introducir ms puestos de trabajo por falta
de espacio, por ejemplo.
Una vez afinados los recursos que deseamos incorporar para realizar las
tareas del proyecto nos puede convenir agrupar recursos por tipologas. Es
decir, que puede interesarnos crear grupos de recursos de tipo programadores,
por ejemplo, para que la herramienta de planificacin de proyectos tenga
mayor libertad a la hora de sugerir mejoras en la planificacin. La asignacin
de recursos a las tareas de tipo trabajo, recordemos que son las realizadas por
recursos humanos, conviene asignarlas por duracin como regla general, con lo
que se utilizarn unidades de tiempo, como pueden ser das, horas, etc. Los
recursos materiales, por otra parte, se suelen emplear con medidas tipo
cantidad como pueden ser veinte licencias del producto de bases de datos o
cuarenta cartuchos de toner para las impresoras.
Con esta informacin comenzaremos a asignar recursos sobre las tareas
teniendo en cuanta que no podemos cargar tareas con trabajos superiores al
tiempo mximo establecido tratando de nivelar la carga de trabajo de forma
uniforme durante el mayor tiempo posible del equipo y de forma equilibrada
entre los mismos. El efecto que se produce por el hecho de asignar recursos
que generalmente son escasos para realizar una serie de actividades mucho
mayor que los recursos disponible es que el cronograma del proyecto se
retrasa. Con esto el director de proyecto tendr que enfrentarse al problema de
conseguir nuevos recursos o contratar la ejecucin de ciertas actividades en el
exterior. En el caso de tener que obtener nuevos recursos de trabajo del
mercado exterior se tendr que tener en cuenta que, normalmente, el pago
C A P T U L O I I : P R O G R A M A C I N D E R E C U R S O S 20)
realizado por trabajo satisfecho suele ser a precio ajustado mensual que es
distinto al pago por horas que se puede subcontratar con alguna empresa lo que
nos obligar a efectuar ajustes y consideraciones de rentabilidad que
consideraremos en el apartado siguiente.
Una tarea importante del gestor es conocer cual es la disponibilidad de
cada recurso tanto en cuanto a fechas topes como en el calendario individual de
cada uno de los miembros de los grupos de produccin ya que los
compromisos particulares de cada uno de los trabajadores forman un conjunto
de restricciones que se debe conocer lo ms pronto posible y, as, el director del
proyecto no comprometer recursos en fechas que no podr asumir. En este
sentido es muy importante disponer de un calendario de cada uno de los
miembros del grupo recursos de trabajo que se vea influido por el horario
general de la empresa y del turno especfico del tipo de recurso. En este sentido
recomendamos que se parta de un calendario base de la empresa sobre el que se
marcan las jomadas de trabajo y del que se excluyen todo tipo de fiestas,
vacaciones y puentes que puedan producirse. A partir de este calendario base
de crean, inicialmente mediante una copia, los calendarios de cada recurso con
sus horarios de trabajo dentro de los das previstos de actividad. Posteriormente
se copia el calendario del recurso en tanto calendarios individualizados para
cada uno de los recursos concretos que tengamos disponible. Finalmente, sobre
cada uno de los calendarios concretos de cada recurso anotaremos las
incidencias concretas que se vayan produciendo facilitndose enormemente la
gestin de avisos de incidencia y su posible resolucin.
Todo este trasiego de copias de calendarios las herramientas informticas
modernas nos facilitan su gestin no realizando copias fsicas en s sino
asociaciones de estructuras de datos haciendo que un cambio efectuado sobre
el calendario base tenga una repercusin instantnea en los calendarios de
turno, de grupo de recursos y de recurso particular sin que sea necesario
efectuar ningn tipo de copia. Un ejemplo del aspecto de la herramienta Project
2000 para este tipo de gestin de calendarios puede verse en la Figura 11.2. En
este caso se puede asociar un calendario de la empresa, del cual se hereda un
calendario, por ejemplo, para cada tumo, y de cada turno, si fuera necesario, un
calendario para cada recurso concreto.
210 PLANIFICACIN Y GESTIN DE SISTEMAS INFORMTICOS CAPTULO 11: PROGRAMACIN DE RECURSOS 211

I p t i J & l - - - -al]-*]
Archivo Edicin Vet In se rta r Form ato fcjsiram ient Proyecto V e n ta re J lli;
'M icrosoft Project - Desarrollo te softw are . ' S i # a ! - m % i'>r? i j g r g
_________ _________________________________ O ^ jES 3

; 4' ' + ** fcjosttdi - J ' -i ' i

j Archivo ditln *er Insertar Formato tjerrarrnto proyecto Ventana ? jgJ*i H H S ! IP^ ~ : lodasi*? taiea? - Ss j

\ D B m ? T ir 5 ^ j S% |#<Ef|i v" <5 I a w G).| .............. ........

j 4* $ + fctostiai I Anal ' 8 |[h S ||g = I Todas la; taeas - 7 * | -& .1 m m sm 7' Jrjxj
TcTE]3l"i'iT :abril 201
Pra: jEstTdai (Catendano dd proyecto) jjj
(Jomhgo
J
T*
j:
Establecer el periodo laborable para las fechas seleccionadas *
lo
i Nombre de larea I Ow(03 ene W
. . 1 . . . uHm Im j j |v{s Id
10 ene 00
i j
i 11 ene *00 24 ene t ; 3l.*r> !
To ^l Im Im- j~Tv"sT : l [m [m] n [ \ o l m Q
Leyenda: Seleccionar las fecha;-: Establecer echas selecciorad
f l i S g - ! ........ 1 abril 2002
conw:
1-1 Ambito ! ! Laborabte -I
L i MM J V S 0 f* FTdetrwnada5
M i 2 ; Cetenrmr el nMo ctel ptoye< -.Administracin
Administracin !I ! No labrate i 2 e ? 4 6 r Periodo Q0 laborable
3 : AiiTiiAf a tos pioctft^cre i
4 [hsthir lecurso? pielmrwes -,Jefe de proyecto I i......_ Heras laborables
$ 9 10 11 12 13 14 J r PetoiolabcraWenopredft.

i ;__ i medfcada* Desde: Hasta:

p j
5 i Afunzw lecursos piiropsfcs ^Jefe dc;proyecto i$ 1$ 17 18 19 20 21 $:00 M:W
6 i aitiM o cctT*>l?1<tdo 06.01 I En este estendano:
7 i 1*1 Anlisis y requisitos del softv ' i V i Mdfcaclneo aun
22 25 24 25 26 27 26 11S:00
" "i Feafczai anliti; riereceskUKk nalistd
: dia de la semana
semai 29 30
-.Analista j 1 i ' . j " Mc^fcaciones a 28
9 j Bonados las esp-wmcaoxi
i .Jr.. un da concreto
i S
io " Oesri ollar presupuesto preiin -,Jee de proyecto ' _d
Revisar b t especificaciones <1 ,Jcfe de proyecto;Analista
Ijsip jl 12 1 rcoiporar los comentarios a la i|ist
j . Jefe de proyecto
lo
Deswiotti lot Ueir.r.os y lechi
_1_3J Ayuda Muevo... Opciones... ? Aceptar Carcelai P5
paSgjl 14 Obtener probaciones para co oj),Adminlstr4cin;Jei
15 I Alanzar los recursos recesar } , Jefe d&proycct
g l
~ 6 ~ ] Anlisis canpHado 26/01
-i7J B Diseo *
18 j Especiticacicoes prethnnares q ^ A n ^ sta
LJ
s " 9 _ ] DesairoUar eipecitcac Iones c*
"2 0 'i DesairoNar pic4oti|x> basado If ..................... ~ F Tt Rwi. STjoesH faT
21 Revisar esoeciricaciores de ti
L J 2i Lil J Figura 11.2 Aspecto de ta Gestion de Calendario de M icrosoft Project 2000.
[Listo T |Pa T | W yU 5 ! U'JM jW

Figura 11.1 Diagramas de Gantt facilitados por Microsoft Project 2000 El d irecto r del proyecto tam bin ten d r que enfrentarse con problem as
referentes al acopio de sum inistros, de alquiler de m aquinaria, la gestin de
contratar tales m edios, la form acin en el uso de las nuevas tecnologas y un
largo etctera de asuntos que, en p rin cip io parecen triviales, pero que el
Se pu ed en indicar, en cada uno de los niveles, los das laborales, los director de proyecto debe saber gestionar con todo tipo de detalles.
festivos y los das no laborables as com o introducir el horario, por defecto, de
la jo m a d a laboral. T am b in se pueden c re a r, com o se ha indicado, todo tipo de Con todos los p lazos y todos los recursos asignados al proyecto
calendarios a p artir del calendario que v isu alizam o s en pantalla. obtendrem os un inform e de gestin q u e deberem os contrastar con el resto de
com paeros que dirigen otros proyectos para ver si tenem os conflictos con
proyectos ajenos, o para saber los riesgos que incorporam os, tanto si no
cum plim os los hitos del proyecto n o so tro s o com o si no lo cum plen otros
sectores cuya responsabilidad pueda p o n e r en peligro el proyecto propio.

F inalm ente el director de proyecto tendr una program acin en la que

conocer, por estim acin, el tiem po d e ejecucin de cada fase, las tareas a
satisfacer en cada m om ento, el cum plim iento de los hitos y la duracin total del
proyecto.
212 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN FO R M T IC O S C A P T U L O 11: P R O G R A M A C I N DI! R H C IR S O S 213

Ejemplo de WBS

11.2 F O R M A L IZ A C IO N DE P R O Y E C T O S IN F O R M A T IC O S Representacin grfica:

Es importante la fonnalizacin de la estructura del proyecto, para permitir un

mayor entendimiento del resultado a obtener y una mejor definicin de cada
mdulo o fase del proyecto. Para conseguir esta fonnalizacin existen varias
tcnicas que permiten representar la descomposicin en funciones de un
proyecto, los entregables y los responsables.

WBS (Work Breakdown Structure) se utiliza para representar la

estructura de descomposicin de trabajos. Es un esquema que muestra un
proyecto subdividido en unidades de trabajo jerrquicas: actividades,
subactividades, etc. y, en l, nicamente se representan las tareas o trabajos en
estructura de rbol. Ilustra como cada pieza del proyecto contribuye al todo en
trminos de desempeo, responsabilidad, presupuesto y programacin.

Segn el tipo de proyecto podemos utilizar diferentes criterios de

estructuracin del WBS: elementos del producto final que resulta del proyecto Representacin en lista:
(mdulos software, software de base,...), reas funcionales (ventas,
facturacin,...) o fases del proyecto (anlisis, construccin,...). A la hora de 0.Proyecto Almacn.
elaborar la estructura del WBS hay que decidir un nmero razonable de 1 .Estudio viabilidad.
actividades en cada nivel, teniendo en cuenta que el nivel ms bajo debe 1 . 1 .Estudio aplicaciones actuales.
corresponder a la planificacin detallada y cumplir las siguientes condiciones: 1 .2 .Estudio necesidades.
2.Anlisis.
Son tareas discretas que tienen resultados finales tangibles. 2 . 1 .Anlisis de datos.
Debe tener un resultado o entregable: especificacin, dibujo, forma, 2.2. Anlisis de procesos.
reporte, etc. Estos entregables deben proporcionar los materiales 3.Diseo.
necesarios para la siguiente etapa y pueden referirse a objetivos del 3.1.Diseo de datos.
producto a obtener o a la propia gestin del proyecto. 3.2.Diseo de procesos.
Debe definir el trabajo a realizar, la unidad organizativa responsable y 4.Codificacin.
los requerimientos de recursos y plazos. 4.1.Codificacin rutinas.
Sirve como punto focal alrededor del cual el proyecto se administra. 4.2.Codificacin programas.
Es considerado el nivel de integracin ms importante. 5. Pruebas
Debe facilitar medidas de desempeo y control del progreso. 5.1.Pruebas unitarias.
5.2.Pruebas de ensamblaje.
 (

214 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P IT U L O I I : P R O G R A M A C I N D E R E C U R S O S

Ejemplo de ficha de tarea:

Especificacin de tarea
Nmero: 5.2.
Nombre: Diseo base de datos
Descripcin: Se diseara la base de datos a partir del
modelo entidad/relacin obtenido en la
tarea de anlisis 2.4

Esfuerzo Estimado: 2 semanas/hombre

Entregablcs: Diagrama de tablas de la base de datos

Como podemos apreciar en el ejemplo la numeracin de cada componente

del WBS facilita la localizacin de estos en los distintos niveles del WBS. Los Podemos establecer una relacin entre WBS y PBS creando un diagrama en el
nodos de la estructura en rbol se leen como: es un componente de ... o que los rectngulos del WBS son acciones y las elipses del PBS son productos
forma parte de . .. En el ejemplo anterior Diseo Programas es un o estados. Una accin transforma un estado en otro estado. Se representa con la
componente de Disear Aplicacin. estructura de la siguiente figura:

Es til seguir unas recomendaciones mnimas en la construccin de la

estructura de rbol del WBS:
Nombrar y numerar el nodo inicial.
Poner en tomo a 7/2 componentes en cada nivel.
Nombrar y numerar los componentes coherentemente con los nodos Figura 11.3 Relacin WBS/PBS.
anteriores.
Terminar en el ltimo nivel (hojas del rbol) con tareas que cumplan las
condiciones vistas anteriormente.
OBS (Organization Breakdown Structure) es el formalismo asociado a
quin hace que, tambin se llama Matriz de Asignacin de
Responsabilidades. Se representa en forma de una tabla y permite asegurar que
PBS (Product Breakdown Structure) permite definir el objetivo del
para cada elemento terminal hay, al menos, un responsable de terminacin. Es
proyecto as como los subobjetivos del mismo. Tambin se representa en forma
la estructura que muestra los responsables y/o participantes de los diferentes
de rbol. Mientras que el WBS se refiere acciones a realizar, si lo que se
componentes del WBS, por lo que a menudo su estructura es anloga a este
pretende es representar los resultados o productos a obtener hay que acudir a
ltimo.
esta otra representacin: el PBS.
Podemos tener tres tipos de representaciones de OBS3:

1 Los ejemplos presentados proceden de (Sanchis, 2002)

21 6 P L A N IF IC A C I N Y G E S T I N DI3 S IS TE M A S IN F O R M T IC O S C A P T U L O I I : P R O G R A M A C I N D E R E C U R S O S 217

Simple. Muestra mediante una tabla que persona u organizacin

participa en que tarea.
Con cargas de trabajo. Tiene el mismo diseo que el OBS simple, pero Ejemplo de OBS con carga de trabajo (Sanchis, 2002)
aade en cada casilla de la tabla el tiempo estimado necesario a emplear
en cada tarea por cada recurso. IN T E R V IN IE N T E S
A B C C IA X Y Z TO TALES
Con roles. Tiene el mismo diseo que el OBS simple, pero aade en
D E F . S IS T E M A 100 100
cada casilla de la tabla el tipo de actividad a desarrollar por cada
REAL. SS1 300 300
recurso en cada tarea. Cada jefe de proyecto puede establecer los roles
DEF. S S 2 50 150

O
O
ms convenientes segn el tipo de proyecto, pero de forma genrica
D E F . C21 100 75 175
podemos definir los siguientes:
o Produccin (P): cuando una carga de trabajo y una intensidad
determina la obtencin de un producto final. En terminologa de
gestin de proyectos son los recursos, INT. S S 2 25 125 150

o Responsabilidad (R): Un participante es responsable de un WBS REAL. SS3 100 100

cuando determina las condiciones en que pueda ser obtenido el INT. S IS T E M A 200 100 100 250 650

producto final del elemento de trabajo o tarea. El responsable TO TALES TA TB TC TXYZ TP |

determina cuando un trabajo est terminado,

o Aprobacin (A): Un participante aprueba un trabajo cuando fija
el resultado del mismo de forma que toda modificacin
posterior deber ser autorizada por l.
o Certificacin (C): Validacin, al menos parcial, de un elemento Ejemplo de OBS con roles (Sanchis, 2002)
de WBS.
o Soporte (S): Un recurso acta como soporte de un elemento I N T E R V IN IE N T E S
WBS cuando debe estar disponible durante la duracin del A B C C IA X Y Z
trabajo. DEF. S IS T E M A RvP

R E A L . S S1 P
DEF. S S 2 A R
Ejemplo de OBS simple (Sanchis, 2002) D E F . C21 R y P S
INTE =!VINIENTES
A B C D Ca J Ca k
Def. sistema X
IN T. S S 2 C P
Real. s s t 1 X
REAL. SS3 A
Real. sst. 2 X X
Real. sst. 3 X INT. S I S T E M A A y P P P P

Se denomina Red Lgica a la relacin que se establece con las tareas

Int. sst. n-m X X X X
especificadas en el WBS, sus relaciones de dependencia puestas en relieve en
Int sistema X X X X X X PBS y las indicaciones de recursos en OBS.
218 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
11.3 PLANIFICACIN DEL CASH-FLOW.
Pero el trabajo no termina en conocer el calendario del proyecto sino que
adems necesitar informar del coste del proyecto tanto a nivel total como a
nivel de calendario. Necesitar conocer cuales son los pagos que se debern
producir en los prximos das as como considerar otros pagos que tenga
comprometidos con anterioridad.
Un aspecto muy importante en la Planificacin y Gestin de Sistemas
Informticos y en particular en el desarrollo de Proyectos, es la programacin
del Cash Flow de tal forma que adems de interesar el coste total del proyecto
es necesario un calendario de pagos para prever la disponibilidad de dinero en
los momentos en que sea necesario.
Una de las tcnicas utilizadas para la previsin del Cash Flow es el
Discoimted Cash Flow DCF (flujo de efectivo descontado), esta tcnica
permite considerar todas las salidas de capital y las "entradas" o beneficios,
separando cada una de las cantidades segn la demora de su valor financiero
actual frente al valor que tendr en el futuro.
En cualquier caso lo interesante de este tema frente a la planificacin de
proyectos es considerar que al Director del Proyecto se le puede pedir que
ajuste la previsin del proyecto a unas pautas de financiacin previamente
establecidas segn una cierta cadencia para que ambas programaciones sean
dependientes en el tiempo. Para poder efectuar un anlisis de los costes, el
Director del Proyecto deber asignar el coste de cada recurso segn su
tipologa determinada as como la fecha prevista de pago. En particular, por
cada recurso, de deber controlar la forma de pago que puede oscilar entre un
pago total por adelantado, unos desembolsos parciales segn avanza la obra y
un pago al final de la obra, todo ello con una posible dilatacin en el tiempo y
combinaciones de las anteriores formas de pago.
Algunos recursos debern ser pagados por cantidades fijas mensuales con
independencia del tiempo de trabajo til en el proyecto o de su cuota de
utilizacin lo que hace que el Director de Proyecto tenga que adaptar su
planificacin para hacer que el trabajo sea lo ms eficiente posible. Tambin
puede suceder que algunos recursos tengan pendiente de aplicacin algn tipo
de subida futura prevista a partir de una fecha que deberemos de controlar
debidamente; incluso es frecuente que algunos recursos tengan unos costes
fijos que son independientes del uso de tal recurso. En cualquier caso
deberemos llevar informacin suficientemente detallada en cada uno de los
C A P T U L O 11: P R O G R A M A C I N D E R E C U R S O S 219
recursos o en las tareas afectadas segn convenga en el plan de gestin de
proyectos especfico de cada empresa.
Los informes de gestin de la planificacin nos ayudarn a considerar los
resultados de la planificacin desde el punto de vista financiero y,
posiblemente, nos obligarn a efectuar muchas modificaciones antes de
disponer de un proyecto que pueda ser aprobado y que sirva de referencia para
todo su desarrollo.
11.4 RETROALIM ENTACIN
Los planes de ajustan y se retroaliinentan para conseguir una estabilidad o para
ajustarlos a la realidad cambiante de cada entorno de proyecto, siendo
conveniente efectuar estos ajustes en base a las incidencias que se vayan
produciendo.
Como cuestin partcula de las herramientas de gestin de proyectos,
como SuperProject de CA o Microsoft Project, es de sealar que los programas
informticos suelen trabajar con tres ficheros inicialmente independientes y
que son las tareas, los recursos con sus calendarios de disponibilidad y las
asignaciones de recursos a tareas concretas; esto nos lleva a las tres
dimensiones del planificador: trabajo, capacidad y duracin. El trabajo define
todo lo que debe de realizarse, la capacidad nos indica el porcentaje de
disponibilidad frente a su ocupacin y nos lleva control de los gastos
ocasionados y la duracin nos estar informando de la carga til de cada uno de
los recursos en particular.
En algunos casos necesitaremos efectuar la planificacin al revs, es decir,
habiendo incumplido alguno de los plazos por retrasos del personal o por la
incorporacin de nuevas funcionalidades, podemos preguntarnos: qu
recursos necesitamos para en una fecha determinada desarrollar un plan de
contencin de la situacin y volver a la situacin programada? Este tipo de
cuestiones, debido fundamentalmente a las restricciones de cada recurso
nicamente podr solucionarse asignando recursos genricos como pudieran
ser verificadores de programa.
A la hora de ajustar el proyecto, fundamentalmente por medio de
retroalimentaciones, se puede asignar perfiles de la forma de operar de los
recursos segn los diversos modelos que proponen las herramientas
220 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O I I : P R O G R A M A C I N D E R E C U R S O S 221

informticas. En este sentido Microsoft Project propone los siguientes perfiles Programacin detallada con hitos, asignacin de tareas, gestin de
de aplicacin de proyectos en general: costos y previsin de pagos.

Uniforme. El trabajo se reparte de forma uniforme durante el calendario Con todo ello, una vez firmado obtendremos una lnea base del proyecto.
del recurso
Decreciente: Al principio se aplica ms trabajo y luego la actividad
decae
Creciente: Poco a apoco se va aumentando el trabajo sobre cada tarea
siendo al final de la misma cuando se concentra el esfuerzo.
Pico inicial: Similar al creciente pero distribuido como un pico inicial
de trabajo.
Pico final: El inverso al anterior.
Dos picos: Al principio de la actividad se produce un pico de trabajo.
Campana: El trabajo se concentra fundamentalmente en el centro de la
actividad.

El proceso de asignacin de recursos y la comprobacin de tareas, sus

prioridades y dependencias continuar de forma recursiva hasta lograr una
planificacin suficientemente aceptable que despus de comprobar su bondad
mediante el anlisis de tareas y de sus asignaciones, as como las
correspondientes sobreutilizaciones. Una vez solucionados los conflictos
iniciales mediante una redistribucin manual podremos llevar el proyecto para
su firma.

El proyecto para su firma deber incluir, entre otros, todos los documentos
iniciales de objetivos a cumplir y los parmetros generales del alcance, plazos
previstos y costes totales a los que se acompaarn todo tipo de documentos de
texto que se dispongan y que hagan referencia al proyecto en si.

En particular se adjuntarn los siguientes documentos:

Estimaciones de costes y escenarios de simulacin iniciales

Todo tipo de contratos con terceros, compromisos de servicio y
garantas estipuladas.
Organigrama del proyecto con los documentos en los que se haga
referencia a la certificacin del personal y adaptacin al trabajo a
desarrollar.
Polticas de gestin del proyecto y de la gestin de cambios y versiones
Todo tipo de documentos de marketing, folletos, presentaciones y
mejoras que se desean incorporar.
222 P L A N IF IC A C I N Y G E S T I N DE S IS T E M A S IN F O R M T IC O S

CAPTULO 12

ANLISIS DEL RIESGO: SEGURIDAD

En colaboracin con el Dr. Jos Javier Martnez Herraiz

El objetivo de la presente leccin es doble: por una parte se pretende llamar la

atencin del futuro profesional de la informtica de gestin, hoy estudiante de
esta asignatura, sobre la importancia de mantener y utilizar mtodos estndares
como garanta de consecucin de los objetivos, por otra parte, se trata de que el
alumno conozca las tcnicas de planificacin de estrategias de seguridad.

Una de las metas de la gestin de proyectos es controlar el desarrollo de

sistemas, pero es en informtica donde se producen los proyectos de ms alto
riesgo de sufrir cancelaciones y tiempos de ejecucin superiores a los previstos,
esto generalmente es debido a que se ponen a construir software de un modo un
tanto despreocupado y sin seguir unas reglas o mtodos bien internos o
externos. Un desarrollo de software basado en una conocida normativa hace
avanzar el proyecto de una forma ms segura que otro cuyo resultado debe de
ser coordinado explcitamente por los distintos grupos de trabajo, de ah la
necesidad de utilizar unos estndares en todo el ciclo de vida.

Por otra parte ser necesario garantizar a lo largo del desarrollo la

adecuacin del proyecto a las necesidades del usuario para lo cual, en alguno
de los casos, puede ser conveniente que se construyan prototipos donde los
requerimientos puedan ser aplicados efectivamente. La construccin de estos
prototipos necesitan de una serie de recursos que se deben de planificar
adecuadamente ya que estos modelos son en s mismos tareas de produccin
del software.

Afortunadamente existen herramientas de 4GL en el mercado capaces de

generar prototipos a partir de la representacin de los requerimientos en un
lenguaje formal, estos prototipos generados automticamente pueden conducir
a una nueva retroalimentacin para modificar o ampliar el conjunto de
requerimientos.
224 P L A N IF IC A C I N Y G E S T I N DE S IS T E M A S IN F O R M T IC O S
En la presente leccin se efectuar, adems, un recorrido por las
especificaciones de seguridad que pueden condicionar notablemente las
primeras planificaciones.
12.1 ESTNDARES EXTERNOS, INTERNOS Y A MEDIDA
Para mejor comprender el presente captulo vamos a definir una serie de
conceptos como son:
Fiabilidad del software: la probabilidad de operacin libre de fallos de
un programa de computadora en un entorno determinado y durante un tiempo
especificado
En este sentido podemos definir los fallos como cualquier falta de
concordancia con los requisitos del software. En este sentido tenemos que
considerar la naturaleza de los fallos ya que tienen un amplio abanico de
posibilidades: de leves a graves, desconcertantes o catastrficos, de correccin
inmediata con pequeo esfuerzo a un gran esfuerzo. Adems la correccin de
un fallo puede producir nuevos fallos.
La mayora de los modelos de fiabilidad relativos al hardware son debidos
al desajuste que a fallos de diseo o al desgaste de los componentes fsicos y
no nos sirven como idea de clasificar los fallos del software donde ocurre lo
contrario.
Se suelen aplicar una serie de medidas de fiabilidad y de disponibilidad, la
forma ms sencilla de medida es el tiempo medio entre fallos definido como la
suma del tiempo medio de fallo ms el tiempo medio de reparacin de ese
fallo:
TMEF=TMDF+TMDR
siendo TMEF el tiempo medio entre fallos, TMDF el tiempo desde la
correccin del fallo inmediatamente anterior y TMDR el tiempo de reparacin
del fallo.
Otra medida utilizada en la industria de la informtica y de los Sistemas de
Informacin desde el punto de vista software es el nmero de defectos por
miles de lneas de cdigo fuente que, si bien es una medida bastante precisa,
suele ser bastante desconcertante para el personal no especialista.
C A P T U L O 12: A N L IS IS D E L R IE S G O : S E G U R ID A D 225
La disponibilidad de un sistema de define como el cociente entre el tiempo
medio entre fallos y la suma del tiempo medio entre fallos y el tiempo de
reparacin, todo ello multiplicado por 100 para hablar de porcentajes.
Disponibilidad = 100* TMDF /(TMDF+ TMDR)
Conviene recordad los modelos de fiabilidad del software que tratan de
medir, o de hacer una prediccin de la fiabilidad en funcin del tiempo de
calendario o en funcin del tiempo de CPU, el comportamiento del sistema
frente a fallos. En especial es de considerar el modelo de diseminacin que
mide el poder de la deteccin de errores mediante procesos estocsticos. Se
pueden estudiar casos como:
La validez predictiva
Capacidad del modelo
Calidad de las suposiciones
Aplicabilidad
Simplicidad
Seguridad del software
Los modelos de fiabilidad son actividades de garanta de calidad del
software que se centra en la identificacin y evaluacin de riesgos potenciales
que pueden producir un impacto negativo en el software y hacer que falle el
sistema completo.
El anlisis del rbol de fallos es un modelo grfico para determinar los
estados del sistema peligrosos: ejemplos de rboles de fallos se pueden seguir
muy bien desde los sistemas de tiempo real y los modelos de suceso-accin. Un^
modelo que se adapta a este problema y sobre el que se pueden representar la
situacin real es mediante Redes de Petri.
Se puede establecer una valoracin intrnseca de cada activo 1 susceptible
de riesgo en el equipo de desarrollo y sus sistemas para lo cual se puede
considerar tanto su valor de uso corno el valor de cambio, dependiendo de la
situacin particular de cada activo. El tipo de valoracin puede ser
directamente una valoracin intrnseca, para aquellos activos que tienen
sustitucin estndar sin problemas de operatividad, y que se considerar,
obviamente, su valor de cambio; tambin puede tratarse de un activo
1 Cualquier elemento de la configuracin del proyecto, ya sea software, documentacin, ele
mento de anlisis se puede considerar como activos del grupo de desarrollo o de la empresa
propietaria.
22 6 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 12: A N L IS IS P C I , R IE S G O : S E G U R ID A D 227

desarrollado en el interior de la organizacin, como puede ser una aplicacin

propia con posibilidades de fallo dentro de su mbito de aplicacin; en estos
casos consideraremos su valor de uso, ya que producir daos y perjuicios en
las funcionalidades de la organizacin con la consecuente prdida de
credibilidad.
Tambin debemos de considerar la valoracin del estado de seguridad de
los activos y, en particular, respecto a sus estados de autenticacin,
confidencialidad, integridad y disponibilidad.
Las mtricas de valoracin intrnsecas de los activos pueden ser:
12.2 IDENTIFICACION Y CONTROL DEL RIESGO
Una implementacin de una metodologa basada en el clculo de riesgos
se efecta en el modelo MAGERIT (http://wvvw.csi.map.es/csi/pg5m20.htm)
donde el sistema de informacin se estudia desde tres puntos de vista para
analizar sus debilidades, fortalezas, riesgos y amenazas, y a partir de este
estudio establecer planes de accin correctoras de los riesgos potenciales que
se encuentren:

Valor de desarrollo, o valor de cambio.

Valor del servicio suministrado. M odelo de M A G E R IT
Valor estratgico o poltico.
Valor penal de la aplicacin.
Otro tipo de valoracin, no incluida en los valores anteriores.

Por otra parte podemos establecer una serie de mtricas para valorar el Submodelo de Ele Submodelo de Even Submodelo de Pro (
estado de seguridad de los activos. mentos tos cesos
Autenticacin: Seis Entidades Bsicas
Tres Tipos Principales
o Bajo, si se puede reemplazar fcilmente por problemas de Cuatro Etapas Tipificadas
autenticacin Activos
o Normal, si se puede reemplazar a coste medio Amenazas
Planificacin
o Alto (difcil y costosamente reconstruible) Vulnerabilidades (
Esttico Anlisis de Riesgos
Confidencialidad: Impactos
Dinmico organizativo Gestin de Riesgos
o Bajo, si se puede reemplazar fcilmente por problemas de Riesgos
Dinmico fsico Seleccin de Salvaguar
confidencialidad Salvaguardas
das
o Normal, si se puede reemplazar a coste medio
o Alto (difcil y costosamente reconstruible) (
F ig u ra 12.1 E structura de b lo q u es d e l m o d elo M A G E R IT
Integridad:
o Bajo, si se puede reemplazar fcilmente
o Normal, si se puede reemplazar a coste medio El submodelo de elementos esta formado por todos los activos de los
o Alto (difcil y costosamente reconstruible) Sistemas de Informacin de la empresa propietaria junto con las amenazas que
o Crtico, si no puede volver a obtenerse puedan producirse sobre los activos, las vulnerabilidades que pueden tener los
Disponibilidad. activos frente a las amenazas, el valor del impacto que puede tener el hecho de
o Menos de una hora. que se produzcan esas condiciones y el riesgo que se est corriendo junto con
o Hasta un da laborable las medidas correctoras que podamos tener previstas.
o Hasta una semana
o Ms de una semana (
228 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 12: A N L IS IS D EL R IESG O : S E G U R ID A D 22 9

Conviene tener en cuenta que estos ltimos criterios conceden al activo un Otro aspecto importante en el anlisis de riesgos es el estudio de las
valor ms prximo al significado del impacto causado en los casos de vulnerabilidades. La vulnerabilidad de un activo es la potencialidad o
materializacin de cualquiera de las amenazas posibles que al verdadero valor posibilidad de ocurrencia de la materializacin de una amenaza sobre dicho
de adquisicin o desarrollo del propio activo. Este enfoque viene motivado activo. Las vulnerabilidades varan por la aplicacin de medidas correctivas
porque se considera que numerosos activos presentan una vulnerabilidad muy sobre tales amenazan en las fases correctivas o como consecuencia de aplicar
alta (vulnerabilidad = I 100%) a ciertos sucesos; si adems el defecto salvaguardias.
produce una disfuncionalidad completa en el activo (degradacin = 100 %) se
obtiene una situacin de impacto pleno en la que el riesgo alcanza el valor de Mtricas de Vulnerabilidad
impacto producido en el momento de materializacin de la amenaza.
Se consideran amenazas a los eventos que pueden desencadenar un Periodo medio ente ocurrencia Rscala subjetiva Tasa anual
incidente en la organizacin, daos materiales o prdidas inmateriales en sus A diario Muy frecuente 100
Mensualmente Frecuente 10
activos. Las amenazas en la profesin informtica estn caracterizadas por
Una vez al ao Normal 1
errores y accidentes si bien podemos tener otro tipo de amenazas debidas a un Cada varios aos Poco frecuente 1/10
planteamiento deficiente del proyecto, a las debidas a errores en el proceso de
adaptacin de algn mdulo que anteriormente era correcto o las amenazas Figura i 2.2 Ejemplo de mtricas de Vulnerabilidad segn el modelo MAGERIT
causadas por objetos empotrados cada da ms difciles de prever.
Los tipos de vulnerabilidades los podramos clasificar en:
Conforme se vaya progresando en el desarrollo del proyecto, las amenazas
analizadas anteriormente variarn en cantidad y posiblemente de clase, ya que, Vulnerabilidad intrnseca del activo respecto al tipo de amenaza que
por ejemplo, como consecuencia de la utilizacin de herramientas como las depende de las dos entidades, activo y amenaza.
indicadas en ASI2000 pueden aparecer amenazas no presentes con Vulnerabilidad efectiva que es la resultante de aplicar las salvaguardas.
anterioridad.
De hecho, la progresin de la vulnerabilidad durante el desarrollo sistemas
En el momento del desarrollo de los sistemas de informacin se pueden de informacin es el resultado del aplicar las funciones y mecanismos de
dar, como ejemplos, las siguientes amenazas: salvaguarda especficos para reducir la vulnerabilidad efectiva.
Fallo de equipos hardware causado por componentes software.
Fallo en las comunicaciones: centralitas, bridges, routers, etc. La mtrica de la vulnerabilidad consiste en considerar la distancia entre la
Avera de climatizacin que impiden el correcto funcionamiento de los amenaza y su materializacin sobre el activo. De esta forma para la
sistemas. vulnerabilidad se utiliza la mtrica [0 , 1 ] donde la cota 0 implica que la*
Cortes de suministro elctrico o malfuncionamiento en las unidades de amenaza no afecta al activo y la cota 1 es la certeza de que se va a producir el
alimentacin ininterrumpida (SAIs). fallo por una amenaza concreta.
Errores causados por funcionamiento invlido de aplicaciones.
Indisponibilidad lgica causada por no poder arrancar u operar La vulnerabilidad, como propiedad de la relacin activo-amenaza da lugar
correctamente el sistema por causas de actualizacin en el sistema a una casustica extremadamente variada y muy compleja que se puede resumir
operativo o en las herramientas de desarrollo. en una coleccin de factores valorados y relacionados con las vulnerabilidades
Inadecuacin de monitorizacin por problemas colaterales en el debidas a las causas ms importantes como instrumento de ayuda al proceso de
componente que monitoriza. valoracin de la vulnerabilidad.
Corrupcin de la informacin por tratamiento defectuoso de la misma
por parte de las distintas aplicaciones. Estos factores se pueden evaluar respecto a la vulnerabilidad siguiendo la
Prdida de informacin o no poder recuperarla de forma eficiente. siguientes escala: CI = Cierto, M F = Muy Frecuente, F = Frecuente, FN =
Frecuencia Normal, y PF= Poco Frecuente.
230 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 12: A N L IS IS D E L R IE S G O : S E G U R ID A D 231

Otro aspecto importante es el estudio de los impactos. Un impacto en un
activo es la consecuencia sobre ste de la materializacin de una amenaza. En
este sentido podemos considerar varios tipos de impactos:
Impactos con consecuencias cualitativas funcionales
o Deterioro del Subestado de Integridad (SI)
o Deterioro del Subestado de Disponibilidad (SD)
Impactos con consecuencias cuantitativas:
o Prdidas de valor econmico
o Prdidas indirectas
o Prdidas econmicas relativas a responsabilidad legal
Impactos con consecuencias cualitativas orgnicas.
valores calculados de riesgo 3 se debern tomar acciones para continuar con las
etapas siguientes del proyecto.
En este sentido es importante considerar los siguientes puntos:
El riesgo calculado intrnseco se define o calcula antes de aplicar
salvaguardas.
El riesgo calculado residual se considera como el que se da tras la
aplicacin de salvaguardas dispuestas en un escenario de simulacin o
en el mundo real.
El umbral de riesgo es un valor establecido como base para decidir por
comparacin si el Riesgo calculado es asumible o aceptable.

La caracterstica ms destacable del impacto es la presencia del impacto En la figura 12.3 se establece un modelo de riesgo en funcin del impacto
pleno (impacto = 100 %) cuando la materializacin de una amenaza produzca y la vunerabilidad.
un disfuncionalidad completa en el activo. Este tipo de impactos puede
traducirse en una interrupcin no controlada de los procesos, tanto informticos Im p a c to R e s (jo
como de control sobre el medio fsico, con consecuencias en multitud de M uy alto Alio M uy alto M u y alto M u y alto
procesos y de forma simultnea. Alto M edio Alto M u y alto M u y alto

Medio Bajo Medio Alto M u y alto

Desde el punto de vista de las consecuencias directas se pueden dar los
Bajo M uy bajo Bajo M edio A lto
atributos de gravedad intrnseca del resultado y el agravante o atenuante
M uy bajo M uy bajo M uy bajo B ajo M edio
circunstancial. Cualquiera de ellos modificar alguno de los subestados A-C-I-
D2. Poco fre c u e n te Norm al F re cu e n te M u y frec u e n te
Vulnerabilidad
Desde el punto de vista de las consecuencias indirectas se pueden dar Figura 12.3 Modelo de valoracin del riesgo segn MAGERJT
como atributos:

Conforme se vaya progresando en la adaptacin de los diferentes activos,

El aspecto cuantitativo de la consecuencia provocada, sea material (por
la vulnerabilidad y el posible impacto irn progresivamente disminuyendo y
ejemplo una prdida monetaria para la reposicin) o inmaterial
por lo tanto, el riesgo, que es un indicador que va ligado al par de valores
(prdidas como datos, programas, documentacin o procedimientos) o
calculados de la vulnerabilidad y el impacto, variar en consecuencia.
El aspecto cualitativo (por ejemplo, prdidas de fondo de comercio,
Dependiendo de los valores calculados de riesgo se debern tomar
prdidas o dao de vidas, situacin embarazosa poltico-administrativa,
decisiones que permitan continuar con las etapas siguientes del subproyecto de
atentados a la intimidad personal).
control del riesgo. Esta decisin puede tomarse por comparacin explcita del
Con esto, finalmente, llegamos a definir el riesgo como la posibilidad de
riesgo calculado con un nivel prefijado de riesgo (umbral de riesgo).
que se produzca un impacto determinado en un Activo, en un Dominio o en
Si el proyecto tiene como objetivo la realizacin de un Anlisis y Gestin
toda la Organizacin. En este sentido es importante estudiar que los riesgos
de Riesgos inicial y genrico, la tcnica de clculo del riesgo se orienta a una
variarn en funcin de la fase del proyecto de tal forma que dependiendo de los
discriminacin dicotmica -en dos bloques- de los riesgos. En esta aplicacin
genrica tambin se tienen pocos elementos para discriminar las

5 Esta decisin puede tomarse por comparacin explcita del riesgo calculado con un nivel
2 ACID: Autenticacin, Confidencialidad, Integridad y Disponibilidad. prefijado de riesgo (umbral de riesgo).
232 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Vulnerabilidades y los Impactos en gran nmero de niveles, por lo que puede
ser no slo suficiente, sino adems lgico, reducir la matriz anterior por
ejemplo a los 3 niveles Bajo, Medio y Alto, como indican los recuadros
anteriores.
En el caso ms sencillo, la Vulnerabilidad se ha podido equiparar a una
frecuencia (por ejemplo, de fallos de un componente), y el impacto tambin se
ha podido estimar como un valor monetario de reposicin (de ese componente).
Entonces, el riesgo calculado se puede considerar como el impacto acumulado
durante un perodo, por ejemplo un ao. El Riesgo ser as el coste de las
reposiciones del componente durante el ao y se podr comparar, bien con un
umbral determinado, bien con el coste tambin anual de las salvaguardas para
reducirlo. As, si el componente falla cada mes como media y su reposicin
cuesta 100.000 pesetas, el riesgo anual ser simplemente la composicin de
ambas cantidades, o sea 1 .200.000 pesetas.
Por otra parte definimos la funcin o servicio de salvaguarda como la
accin que reduce el riesgo. Un ejemplo de una funcin de salvaguarda puede
ser el establecimiento de un plan de contingencia que deber ser probado segn
los siguientes procesos:
Validar la estrategia de continuidad.
Desarrollar y documentar planes de prueba de contingencias.
Establecer equipos de prueba y adquirir recursos necesarios para
pruebas
Preparar y ejecutar pruebas
Validar la capacidad del plan de contingencias.
Ensayar el plan de contingencia con el equipo de recuperacin
Actualizar el plan de continuidad a partir de las experiencias tenidas en
las pruebas
Actualizar los planes y procedimientos de desastres
En el desarrollo de sistemas de informacin de un cierto nivel, las
salvaguardas que se aplicarn tendrn, adems de los objetivos fundamentales
de reducir la vulnerabilidad y el impacto a travs de sus cualidades preventivas
y curativas, las caractersticas de:
Crear el entorno adecuado para facilitar la eficiente realizacin del
proceso de conversin de las aplicaciones.
Dar informacin sobre las estrategias y herramientas que de deben
utilizar.
Facilitar el desarrollo de los planes de contingencia necesarios.
C A P T U L O 12: A N L IS IS D E L R IE S G O S E G U R ID A D 233
Al definir una relacin entre un activo y una amenaza debida a posibles
elementos deberemos establecer, para ese par activo amenaza, un conjunto de
funciones de salvaguarda. Cada funcin de salvaguarda incorpora un conjunto
de mecanismos de salvaguarda que se debern aplicar para hacer frente a la
amenaza.
El tercer submodelo de la metodologa MAGERIT es el de procesos que
comprende las cuatro etapas representadas en la figura 12.4 y que describimos
a continuacin:
Figura 12.4 Submodelo de Procesos
Planificacin del Proyecto de Riesgos. Como consideraciones iniciales
para arrancar el proyecto de Anlisis y Gestin de Riesgos (AGR), se
estudia la oportunidad de realizarlo, se definen los objetivos que ha de
cumplir y el mbito que abarcar, planificando los medios materiales y
humanos para su realizacin e inicializando el propio lanzamiento del
proyecto.
A nlisis de Riesgos. Se identifican y valoran las diversas entidades,
obteniendo una evaluacin del riesgo, as como una estimacin del
umbral de riesgo deseable.
Gestin de riesgos. Se identifican las funciones y servicios de
salvaguarda reductores del riesgo, seleccionando los que son aceptables
en funcin de las salvaguardas existentes y las restricciones, tras
simular diversas combinaciones.
Seleccin de salvaguardas. Se prepara e! plan de implantacin de los
mecanismos de salvaguarda elegidos y los procedimientos de
234 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M TIC OS
seguimiento para la implantacin. Se recopilan los documentos del
Anlisis y Gestin de Riesgos (AGR), para obtener los documentos
finales del proyecto y realizar las presentaciones de resultados a
diversos niveles.
Como resumen podemos fijar que el contenido de las actividades ser:
Recogida de informacin.
Situacin genera! del sistema.
Identificacin y agrupacin de A divos.
Identificacin y evaluacin de Amenazas.
Identificacin y estimacin de Vulnerabilidades.
Identificacin y valoracin de Impactos.
Evaluacin del Riesgo.
12.3 ESTRATEGIAS Y PLANES DE CONTINGENCIA
En la proyeccin del riesgo se busca hacer una medicin de los riesgos en
funcin de su probabilidad de ocurrencia y del coste o consecuencias de que
ocurra. El objetivo ltimo es establecer un Plan de Reduccin, Supervisin y
Gestin del Riego (RSGR).
El primer paso para conseguir el RSGR es desarrollar una tabla de riesgos
donde hacer la proyeccin de los riesgos. Los pasos generales de su
construccin seran:
Hacer una lista de todos los riesgos posibles, incluidos los ms remotos.
Categorizar cada riego, indicando el tipo de riesgo que es: de producto,
de proyecto o de negocio. Cada organizacin puede incluir las
categoras que considere oportunas segn sus propias caractersticas.
Determinar la probabilidad de ocurrencia de cada riesgo
(vulnerabilidad), ya sea mediante una estimacin en forma objetiva o
subjetiva o haciendo una valoracin promedio de todas las estimaciones
individuales.
Valorar el impacto de cada riesgo y establecer una categora de impacto
para cada uno. Una posible clasificacin de categoras sera:
Catastrfico
Serio
- Tolerable
C A P T U L O 12: A N L IS IS l)F L R IE S G O : S E G U R ID A D 235
Despreciable
Realizar una ordenacin de la tabla obtenida en funcin de la
probabilidad y el impacto, quedando en la parte superior las de mayor
probabilidad y mayor impacto.
Establecer una lnea de corte a partir de la cual determinar que riesgos
sern de verdadero control y atencin.
Una vez completada la tabla de riesgos podremos establecer para cada uno
estrategias y planes de contingencia que nos determinaran nuestro Plan de
Reduccin, Supervisin y Gestin del Riego:
Estrategia de prevencin. Sera aquella dirigida a reducir la
probabilidad de que ocurra el riesgo.
Estrategia de minimizacin. Sera aquella dirigida a reducir el impacto
del riesgo si este ocurre.
Plan de contingencia. Sera el conjunto de acciones planificadas para
ser ejecutadas en el momento de la ocurrencia real del riesgo.
Ejemplo:
Se presenta a continuacin un ejemplo de tabla de riesgos de un
proyecto de desarrollo de software para un cliente. Veremos dos
tablas, la primera corresponde a la identificacin del riesgo,
tipologa, vulnerabilidad e impacto. La segunda contiene para cada
riesgo identificado su estrategia de prevencin, estrategia de
minimizacin y plan de contingencia.
Hay que tener en cuenta que tanto el riesgo identificado como su
vulnerabilidad e impacto se definen para un entorno determinado,
formado por la empresa de desarrollo, el diente, el personal, el
mercado, el momento econmico y tecnolgico, etc. E l mismo
desarrollo puede contemplar riesgos distintos en definicin y
caractersticas para un cliente u otro o si se desarrolla en un entorno
tecnolgico u otro, etc.
Los riesgos estn ordenados por vulnerabilidad del riego (de mu)> alta
a muy baja) y dentro de esto por impacto (de tolerable a catastrfico).
Se deber tener en cuenta los riesgos ms frecuentes (hasta
probabilidad media) sea cual sea su impacto (aunque se pueden
despreciar aquellos de impacto tolerable) y los riegos con
probabilidad baja o muy bajo con impacto serio o catastrfico.
236 P L A N IF IC A C I N Y G E S T I N D ti S IS T E M A S IN F O R M T IC O S C A P T U L O 12: A N L IS IS D E L R IE S G O : S E G U R I D A D 237

de lenguaje
R ie sgo Tipo Probab. Efecto
Cambio de requisitos Proyecto M uy alta Serio Trabajo en grupo. Reparto
Elevado
Cambio del personal Proyecto Alta Tolerable Divisin del Establecer equitativo del
nmero de
Limitaciones impuestas por el proyecto en coordinador y trabajo. Reajustes
miembros en
Producto Media Serio subproyectos buena y control del jefe
lenguaje el equipo
comunicacin de proyecto
Elevado nmero de miembros Mantener
Proyecto Alta Tolerable Acuerdos con
en el equipo motivado y
empresas Sustitucin
Baja del personal Proyecto Media Serio contento al
Baja del subcontratistas. rpida. Reajustar
personal.
Falta de motivacin Proyecto Media Serio personal No tener una roles si es
Prevencin de
nica persona necesario
Retraso en la entrega del Media accidentes e
Proyecto Serio por rol
producto final incidencias
Buena
Retraso de la aceptacin del Media
Proyecto Serio comunicacin y Seguimiento del
cliente Reajuste de roles.
Falta de liderazgo. Buena personal
Cambio de
Salida inesperada al mercado motivacin poltica de potencialmente
Negocio Baja Serio personal
de un producto equivalente retribuciones y inmotivado
mritos
Personal poco cualificado Proyecto Baja Serio
Buena Crisis del
Abandono del cliente Proyecto M uy baja Catastrfico Retraso en la planificacin y proyecto (trabajar Renegociar con el
Cambio en la tecnologa Producto M uy baja Serio entrega del seguimiento y ms horas, cliente el plazo de
producto final control del reajustar la entrega
No se cumple el contrato Negocio Baja Serio
proyecto planificacin)
Mala eleccin de la tecnologa Proyecto M uy Baja Serio Comunicacin
constante con el
Retraso de la cliente, buena Presencia del Renegociar con el
Estrategia de Estrategia de Plan de aceptacin planificacin del jefe de proyecto. cliente el plazo de
R iesgo
prevencin minim izacin contingencia del cliente trabajo de prueba Reajuste de roles entrega
Entrevista y personal
detallada con el cualificado
cliente por Volver a la etapa Mercado Analizar nuestro
Diseo flexible. Salida
personal de anlisis de especializado o producto en
Consensuar con inesperada al Estar al dia de la
Cambio de cualificado para requisitos, cautivo. Producto comparacin con
el cliente mercado de situacin del
requisitos establecer los modificarlos y competitivo en el competidor
soluciones poco un producto mercado
requisitos. revisar la cuanto a precio para encontrar
impactantes equivalente
Establecer planificacin y/o calidad puntos fuertes
prioridades en los Establecer planes
requisitos Compartir de formacin
Cumplir la Personal Buena poltica de conocimientos y especficos que
No tener una
Cambio del planificacin. poco formacin y experiencias. no retrasen el
nica persona Reajustar roles
personal Realizar un buen cualificado seleccin Solicitar ayuda proyecto. Nuevo
por rol
trabajo en equipo. de expertos personal y
Formacin Usar otras reajuste de roles
Limitaciones
exhaustiva del Establecer herramientas Comunicacin. Presencia del Buscar nuevos
impuestas
lenguaje antes de alternativas en el complementarias. Abandono Mantener los jefe de proyecto. clientes. Estudiar
por el
empezar el diseo Cambiar el del cliente plazos de entrega Buena la posibilidad de
lenguaje
diseo diseo. Cambiar y la calidad presentacin del abandonar el
23 8 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 12: A N L IS IS D E L R IE S G O : S E G U R ID A D 239

producto y el proyecto Deteccin del resto de componentes afectados: Por propagacin dentro
proyecto de las aplicaciones, de los elementos anteriormente identificados.
Estar al dia
Usar tecnologas
Cambio en la tecnolgicamente. Cambiar el diseo
consolidadas y
tecnologa Soluciones y la codificacin
estndares
verstiles
Crisis del
Redactar el
proyecto. Centrar
No se contrato
esfuerzos en Renegociar el
cumple el asegurando
puntos contrato
contrato compromisos
importantes del
factibles
contrato
Documentarse.
Mala Realizar una Personal experto. Cambiar la
eleccin de seleccin Adecuacin del tecnologa.
P ro p ag ac i n
la tecnologa cuidadosa de la diseo. Replan ificar
tecnologa Figura 2.5 El anlisis del Impacto

Es preciso contemplar las contingencias de tipo tcnico y los impactos que

Una vez estudiados los riesgos del proyecto se puede crean una lista
puedan tener en la organizacin y en el entorno con que se relaciona. Los
adicional de requerimientos diciendo lo que NO debe de suceder.
planes de contingencia deben comprender, por tanto, las acciones organizativas
y tcnicas necesarias para garantizar la continuidad de la actividad de la
organizacin, con el fin de:
I.imitar al mximo la necesidad de tomar decisiones durante el perodo
de recuperacin. As, una buena planificacin permite evitar la toma de
decisiones en momentos en que cualquier actuacin errnea puede
agravar los problemas iniciales.
Recuperar los servicios imprescindibles en el menor tiempo posible
reduciendo al mximo su impacto econmico, estratgico y poltico.
Por ejemplo, debe preverse el funcionamiento del sistema de
informacin transitoriamente degradado.

El Anlisis de Impacto de los cambios en las aplicaciones se realizar por

propagacin de los campos inicialmente calificados de forma segura como
fechas y de los detectados progresivamente a lo largo del proceso, tanto de
forma automtica como de forma manual, en cuatro pasos consecutivos:

Deteccin automtica: Realizada en base a:

Analizadores sintcticos de cdigo (P. ej. : fechas del sistema)
Exploradores o filtros lgicos (P. ej.: campos que siguen una
nomenclatura estndar, o que tienen un formato determinado)
Deteccin manual: Rutinas de validacin de fechas del sistema, fechas
e importes en Bases de Datos y copy s, etc.
240 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S

CAPTULO 13

LA COMUNICACIN TCNICA
En colaboracin con el Dr. Josc Ramn Hilera Gonzlez

El objetivo de esta unidad es describir la informacin que debe de ser

producida durante la planificacin del proyecto y su gestin. Al mismo tiempo
se estudiar el fundamento de la comunicacin tcnica y se darn algunas
indicaciones para escribir documentacin efectiva y describir herramientas
usadas en los procesos de documentacin.

En cualquier desarrollo software el porcentaje del costo en producir

documentacin frente al total del desarrollo aumenta en funcin del tamao del
proyecto. Los directores de proyecto deben de tener una consideracin especial
a este producto ya que:

Debe de actuar como un medio de documentacin entre los miembros

del grupo de desarrollo.

Un factor decisivo para alcanzar el xito en el desarrollo de un producto

es seguir una estrategia eficiente en los procesos de comunicacin
tcnica.

Debe de constituir un fondo actualizado para ser utilizado

posteriormente en las tareas de mantenimiento.

Debe proveer informacin sobre las previsiones y desarrollos de las

distintas fases de la vida del proyecto.

Es el responsable de establecer los canales de comunicacin entre los

miembros del grupo.

Alguno de estos documentos debe de servir como ayuda a los usuarios

y administradores del sistema
242 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 13: l.A C O M U N IC A C I N T C N IC A 243

La documentacin se clasificar en dos grupos: a documentacin de los 13.1 FUNDAMENTOS DE LA COMUNICACIN TCNICA.
procesos y a documentacin de los productos, entre los primeros se
encuentran los planes, estimaciones, listas de tareas, anexos, informes de Gran cantidad del tiempo la dedicamos a la comunicacin. La comunicacin
evolucin del proyecto, documentos de trabajo, etc. Entre el segundo grupo se intenta trasmitir informacin o conocimientos por lo que tenemos que
encuentra la documentacin de usuario y la documentacin del sistema. diferenciar ambos trminos. En la comunicacin lo que se necesita es un
conocimiento que compartir y, por lo tanto, se deben de establecer las
Las metodologas de desarrollo de sistemas informticos y los estndares condiciones necesarias para que este proceso pueda ser realizado; en concreto,
relacionados con la gestin de la calidad suelen establecer los diferentes dentro de la materia que nos ocupa, ser necesario que las personas
documentos, de las dos categoras indicadas, que han de generarse a lo largo de involucradas en la comunicacin tengan algo que comunicar y que quieran
los proyectos. Por ejemplo, en el caso del estndar ISO 12207, algunos de los hacerlo.
documentos previstos son los siguientes:
La comunicacin se puede realizar de muchas formas: comunicacin oral,
Contrato del proyecto escrita, viendo anuncios, escribiendo, etc pero es la comunicacin oral la que,
Documento de requisitos de momento, nos ocupa la mayor parte del tiempo de la actividad de
Especificaciones funcionales comunicacin. En la gestin de proyectos informticos necesitaremos disponer
Manual de usuario de un conocimiento completo y pertinente sino que, adems, tenemos que
Manual de explotacin buscar los cauces para compartirlos de la forma ms eficiente posible.
Manual de procedimiento
Manual de calidad Para que exista una verdadera comunicacin se necesita de un emisor de
Informes de pruebas conocimientos, un mensaje que se quiera trasmitir, y, al menos, uno o varios
Informes de problemas receptores disponibles que sean capaces de entender lo que se trasmite. En
Informes de codificacin todos los canales de comunicacin se genera un ruido que hace que el mensaje
Informes de estado no llegue con toda la claridad a los receptores por lo que es necesario, si
Informes de verificacin pretendemos una comunicacin efectiva, buscar un segundo canal de respuesta
Informes de validacin que nos confirme que la emisin se ha producido con integridad y que el
Informes de auditora receptor ha comprendido el mensaje: se trata del conocido feedback que tanto
Informes de mtricas apreciamos en todo tipo de mensajes.
Material de formacin
Plan de desarrollo
Plan de mantenimiento
Plan de migracin Canal de trasmisin
Plan de gestin de configuracin
Plan de gestin del riesgo Emisor A ------------------
\ Canal de retomo

Una correcta y exhaustiva documentacin redundar, en definitiva, en una

mejor calidad del sistema final y facilitar su mantenimiento en el futuro. En el Figura 13.1 Canales de informacin en la comunicacin
captulo 15 (Garanta de la Calidad) se describirn con detalle las actividades
de la gestin de la documentacin en los proyectos y su relacin con la garanta
de la calidad. Como gestores de un proyecto informtico tenemos que compartir la
informacin entre todos los miembros del grupo facilitando su bsqueda y
recuperacin desde el puesto de trabajo y en el momento en que sea necesaria
con un mnimo de esfuerzos para la persona del grupo que la necesite.
244 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
En trminos genricos tenemos muchos medios tanto para captar
informacin como para difundirla: las reuniones, las visitas de inspeccin, la
documentacin existente, las criticas recibidas, las recomendaciones y un largo
espectro de posibilidades que nos permitirn acercarnos a ese conocimiento del
proyecto que tendremos que cuidar para lograr una mayor productividad del
grupo de desarrollo.
13.2 C O M U N IC A C IO N E S O R A LES Y ESCRITAS.
Decamos que la mayor parte de la comunicacin entre personas es la
comunicacin oral si bien en los proyectos de desarrollo tcnico se est
transitando hacia una comunicacin escrita. Cada da se introduce mayor nivel
de soporte documental para que las peticiones de informacin se realicen de
una forma sistemtica y disciplinada para que el tiempo, que tiene una
capacidad finita, se nos convierta en un aliado y no en una fuente de gastos.
Una fuente de informacin tcnica en las empresas que quieren desarrollar
proyectos es las reuniones. Una reunin tcnica formal nos ayudar a asentar
conocimientos y a que la comunicacin de las metas sean fuertemente
confirmadas. En las reuniones, adems de intercambiarse mensajes orales y
escritos, los asistentes intercambian mensajes complementarios, a travs de
gestos y expresiones, que nos ayudarn a sentar las bases del proyecto, sus
objetivos y la importancia que el mismo tiene para la empresa y otro tipo de
informacin de importancia para el grupo.
Las reuniones deben de prepararse con antelacin haciendo que los
participantes planifiquen las preguntas y reflexionen sobre las actividades
realizadas frente a las actividades previstas. Segn se trate de reuniones de
trabajo o reuniones informativas se debern tener en cuenta una serie de pautas
para lograr los objetivos que se persiguen. As en una reunin de trabajo, donde
lo que se persigue es la bsqueda de soluciones a problemas concretos, el
moderador deber mantener una postura de neutralidad y, si as hiciera falta,
animara a los miembros del grupo a manifestar sus ideas y posibles
soluciones. Sin embargo en la reunin informativa el que preside tomar un
alto protagonismo ya que el objetivo ser facilitar informacin a los dems
miembros de la reunin salvo que el objetivo sea precisamente el contrario:
recibir informacin del grupo.
C A P T U L O 13: L A C O M U N IC A C I N T C N IC A 245
En cualquier caso las reuniones se gestionan siendo el moderador el que
deber establecer el marco de la reunin, el orden del da, estudiar y repartir
la documentacin que sea necesaria y convocar a los asistentes 1 en un lugar
determinado y a una hora prefijada. La convocatoria deber ser formal y por
escrito donde se especifique el asunto a tratar, el lugar y la hora, el orden del
da, la duracin prevista de la reunin y la lista de personas convocadas con
indicacin de sus cargos o funciones. Por otra parte se deber preparar la sala
de la reunin en funcin del nmero de asistentes y con los materiales
necesarios (proyector, folios, lapiceros, etc) para que no se produzcan
situaciones que no permitan avanzar el desarrollo de la reunin con una normal
cadencia.
Una vez comenzada la reunin, tratando de ajustarse a la fecha de inicio
prevista, ni el moderador ni el grupo de trabajo deberas ser molestados desde
el exterior salvo por temas importantes que se realizaran a travs de una
secretaria o persona auxiliar. No hay nada peor en una reunin que el sonido de
los telfonos mviles que hacen que muchas personas tengan que perder un
tiempo muy valioso.
Durante la reunin el moderador ser la persona que dar juego a la
reunin: repartir documentacin, fijar la informacin que el grupo a
elaborado, tomar nota de los acuerdos y tratar de que todos los miembros del
grupo de la reunin respeten los tumos de palabra. Igualmente intentar centrar
la reunin si algn miembro o grupo de participantes se sale del tema general
de la reunin o si trata de tener alguna reunin paralela.
Cuando finaliza la reunin realizar un informe, que distribuir entre los
miembros para lograr su aprobacin y, si as se especifica, lo elevar al
conocimiento de sus superiores.
13.3 PREPARAC IO N ES DE EXPOSICIONES O R A L E S Y DE
M ATERIALES DE SO PO RTE.
La importancia de preparar las exposiciones al grupo de la reunin, o incluso
en las entrevistas personales, adquiere cada da una mayor importancia por el
hecho de tratar de asegurar un perfecto conocimiento de toda la informacin
que el grupo debe de conocer. Pero las personas de las empresas, normalmente
estn muy ocupadas, y no se les puede facilitar toda la informacin disponible
sobre un tema sino que ser necesario que conozcan los aspectos ms
1 Tal vez con la aprobacin de sus superiores
246 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
importantes y que tengan referencias del lugar dnde se pueden ampliar los
aspectos especficos del tema en cuestin.
En este sentido es necesario insistir en la forma de elaborar exposiciones
orales, los materiales de soporte y, sobre todo, saber emplear con cierto rigor
los elementos de comunicacin como pueden ser los sistemas hipermediales
considerando el objetivo final de la exposicin: explicaren un breve espacio de
tiempo, las ideas fundamentales del trabajo cuya documentacin es excesiva y
su lectura, por tanto, nos ocupara varias horas.
Las personas estn muy ocupadas pero el director del proyecto necesita
que sus superiores, o la empresa cliente, perciba una informacin que es de
mucha importancia para el desarrollo del proyecto como pueden ser el Plan de
Trabajo, informacin para la ayuda en la decisin de invertir en un proyecto,
presentacin de ofertas con matices importantes que se quieren resaltar.
Para que la presentacin sea exitosa se deben de cumplir una serie de
premisas que se reflejan en los siguientes apartados:
Estudio de la estructuracin de la presentacin
Preparacin del material de apoyo
Estudio de la exposicin
13.4 LA HERRAM IENTA CASE Y EL SOFTWARE DE
PLANIFICACIN COMO MEDIO DE PRODUCIR
DOCUM ENTACIN TCNICA.
Dentro del entorno de las herramientas de construccin de sistemas de
informacin modernas e, incluso, en los planificadores de proyectos, se
proveen servicios de seguimiento de procesos de gestin documental que
facilitan todo tipo de comunicacin tcnica entre los elementos del grupo.
El trmino gestin documentaI suele utilizarse para hacer referencia al
control automatizado de documentos electrnicos a travs de su ciclo de vida
completo en una organizacin, desde su creacin inicial hasta su archivado
final. Si, como afirman algunos autores, el 90% de la informacin de una
organizacin reside en documentos (segn Cleveland en 1995), resulta evidente
suponer que el aumento de la eficiencia en su gestin d lugar al consiguiente
incremento de competitividad de la organizacin. Tal objetivo no es, sin
embargo, posible sin unas herramientas informticas adecuadas que
genricamente reciben el nombre de Sistemas de Gestin de Bases de Datos
C A P T U L O 13: LA C O M U N IC A C I N T C N IC A 247
Documentales (SGBDD), o Sistemas de Gestin Documental (SGD) o, en
ingles. Document Management Systems (DMS), que, entre otros, ofrecen
mecanismos para la identificacin, almacenamiento, seguimiento, recuperacin
y presentacin de los documentos.
Aunque tradicionalmente estos sistemas han asumido exclusivamente
funciones propias de gestin administrativa como las mencionadas, existe una
tendencia a la integracin en los ms recientes SGD de tales funciones con las
de edicin que, hasta ahora, eran competencia de los populares procesadores de
texto. Se puede decir, por tanto, que un SGD es un sistema que permite la
automatizacin, la creacin, el mantenimiento y la consulta de fuentes de
informacin constituidas por documentos y, por lo tanto, sirve para explotar el
conocimiento que contienen los documentos con el fin de ponerlo al alcance de
los usuarios del sistema, definicin de Codina en 1994.
Los SGDs se utilizan en el seno de organizaciones pblicas o privadas, con
el objetivo de controlar e incrementar la eficiencia del finjo de documentos que
soportan sus negocios o actividades. Entre los posibles beneficios que se
pueden obtener mediante esta automatizacin de la gestin documental podran
considerarse los siguientes:
El aprovechamiento del capital intelectual de la organizacin, ya que el
conocimiento se crea una sola vez y es reutilizado muchas veces.
La gestin del flujo de trabajo, mediante el control del flujo de
informacin a travs de todas las fases de un proceso de trabajo.
Se favorece un trabajo en equipo ms efectivo acelerando actividades
crticas para la organizacin (por ejemplo, las actividades de
coordinacin o la notificacin de incidencias).
Al disponer de la documentacin de forma inmediata, se puede mejorar
el proceso de produccin (si existe) y el servicio al cliente.
Permite una rpida respuesta a eventos o imprevistos que puedan surgir.
Pero para que el conocimiento se comunique es necesario considerar que
existe una base de conocimientos que cada da se va enriqueciendo como en el
caso particular de organizacin de las bibliotecas. Antes de decidir implantar
un sistema de este tipo en una de ellas, habra que plantearse una serie de
interrogantes acerca de si se pretende que los documentos sean el fin ltimo de
la organizacin o un medio para alcanzar un fin (por ejemplo, la obtencin de
2+8 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
beneficios), si se desea poder ofrecer a los usuarios la posibilidad de consultar
documentos virtuales, si el sistema va a gestionar tambin los documentos
administrativos de la biblioteca o slo los documentos depositados en ella, cul
es el perfil de los clientes/usuarios de los fondos documentales, etc.
En los siguientes apartados se analizarn las funciones que debe incorporar
un SGD para que sea de utilidad a las organizaciones, destacando una
tendencia de gran actualidad que ya ha repercutido en estos sistemas, como es
la necesidad de incorporar servicios que faciliten la cooperacin en grupos de
trabajo.
Los sistemas de Gestin Documentales, SGDs, son sistemas informticos
que estn compuesto de unos elementos fsicos (el hardware) que constituyen
la infraestructura del sistema y otros lgicos (el software) que proveen los
servicios necesarios para gestionar un documento en una organizacin desde su
nacimiento hasta su muerte. Estos componentes son los siguientes:
Infraestructura.
Servicios de autor.
Servicios de almacenamiento y bsqueda.
Servicios de biblioteca.
Servicios de presentacin y distribucin.
Servicios de trabajo coiporativo {groupware).
Aunque existen productos comerciales que ofrecen algunos de estos
servicios por separado, la tendencia actual es su integracin en una nica
herramienta que combine las tradicionales funciones de almacenamiento y
bsqueda con otras facilidades para la elaboracin de los documentos, para su
control, su presentacin y su utilizacin compartida por los integrantes de
diferentes grupos de trabajo. En este sentido la herramienta de gestin de
proyectos Project 2000 de Microsoft incluye un servicio, denominado Central
Project, que establece un marco de relaciones de trabajo en grupo entre los
miembros del equipo de desarrollo basado en la suite de Office, tambin de
Microsoft.
Nuestro objetivo no es describir como se desarrolla documentacin para la
comunicacin tcnica entre el grupo ni con la herramienta de planificacin ni
con las CASEs, sino establecer una visin general de los aportes que la
industria de las tecnologas de la informacin ofrecen para la planificacin y
gestin de sistemas informticos; por ello, a continuacin se describirn
brevemente los servicios, dedicando especial atencin, en el siguiente apartado,
a las facilidades para el trabajo corporativo (groupware), que han sido
C A P T U L O 13: LA C O M U N IC A C I N T C N IC A 249
incorporadas ahora que la tecnologa de redes de computadoras, especialmente
Internet e Intranet, permite una perfecta comunicacin entre los posibles
integrantes de grupos de trabajo.
La infraestructura necesaria para disponer de un servicio de groupware
est formada normalmente por el hardware, junto con el software de base, y las
lneas de comunicacin. En este sentido se entiende que la infraestructura
sobre la que se va a trabajar es algo ms que el ordenador y el programa: se
habla, adems, del acceso a todos los recursos que pudieran existir a travs de
la red que estar integrada por las computadoras, tanto los que utilizan los
usuarios (clientes del sistema), como la o las computadoras que centralizan las
bases de datos documentales (servidores).
Sobre esta infraestructura se pueden montar una serie de servicios para
optimizar la comunicacin. Tales servicios son:
Los servicios de autor
Los servicios de almacenamiento
Servicios de bsqueda
Servicios de biblioteca
Servicios de presentacin y distribucin
Los servicios de autor son un conjunto de herramientas (de autor
entendido como usuario final) para permitir la creacin de los documentos que
sern gestionados y que debe poder manejar formatos de documentos creados
por otras aplicaciones. Estas herramientas pueden ser desde procesadores de
texto convencionales hasta editores de hipertexto o hipermedia que permitan la
inclusin de componentes multimedia en los documentos (imgenes,
secuencias de vdeo, sonido) y enlaces para facilitar la navegacin por su
contenido. En este sentido, los SGD incorporan, por ejemplo, procesadores del
lenguaje HTML (Hyper Text Markup Lenguage) utilizado en Internet para la
elaboracin de documentos hipermedia.
El ncleo que subyace a todo SGD lo constituyen los servicios de
almacenamiento, en concreto un gestor de base de datos tradicionalmente
relacional, aunque en la actualidad se tiende hacia la orientacin a objetos
como paradigma de almacenamiento (ver Martnez, 1996), considerando un
documento compuesto por objetos de informacin (fotos, captulos, secciones,
etc.) que adems incluye informacin sobre cmo los objetos deben
ensamblarse. Esto, adems, puede permitir el presentar despus a los usuarios
documentos virtuales diferentes, adaptando el ensamblaje de las partes a las
caractersticas de cada usuario. En definitiva, de lo que se trata es de
250 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
evolucionar desde el clsico almacenamiento esttico de los documentos hacia
un almacenamiento que permita su composicin en el mismo momento en el
que van a ser utilizados por los usuarios.
En cualquier caso, para facilitar las tareas de bsqueda que se describen en
el siguiente apartado, muchos fabricantes prefieren utilizar como servicio de
almacenamiento bases de datos mixtas, denominadas ORDMS: Object
Relational Database Management Systems, que utilizan una base de datos
relacional para localizar a los objetos de informacin documental situados en
otra base de datos orientada a objetos (ODMS: Object Database Management
System).
Junto con los servicios de almacenamiento de los documentos, un SGD
debe proporcionar servicios de bsqueda en esos documentos. Esto suele
hacerse mediante ndices, que no son sino bases de datos con indicadores o
localizadores que sealan el lugar dnde se almacenan los documentos. As, las
bsquedas que solicitan los usuarios se realizan en la base de datos ndice en
lugar de hacerlo directamente sobre los documentos. En algunos casos, el
motor o mecanismo de bsqueda es desarrollado por el propio fabricante del
sistema de gestin documental, mientras que en otras ocasiones se utilizan los
de otras firmas.
El tema de los ndices es importarte porque afecta a la velocidad de las
consultas o bsquedas y a la calidad de los resultados obtenidos: si realmente el
usuario encuentra lo que le interesa. Algunos mtodos de indizacin
(tratamiento de los ndices) son los siguientes:
Mtodo de texto completo (Full Text): Gestiona una lista de todas las
palabras significativas de cada documento, emparejando cada palabra
con localizadores que referencian a todos los documentos en los cuales
aparecen.
Mtodo de las palabras clave: La lista de palabras significativas se
reduce a las consideradas como clave.
Mtodo de las palabras clave y relaciones: Complementa al anterior
creando adems relaciones entre ciertas palabras en el ndice
(sinnimos). Por ejemplo, si el usuario busca documentos a partir de la
palabra viajar, el sistema de bsqueda la podra relacionar con
palabras como avin, hotel, etc.
Mtodo de palabras derivadas: Se busca una palabra y otras con su
misma raz. Por ejemplo, a partir de conducir se buscara tambin
Conductor, conducido, etc.
C A P T U L O 13: LA C O M U N IC A C I N T C N IC A 251
Utilizacin de descriptores: Son trminos extrados de lenguajes
documentales, tales como listas de autoridades, encabezamientos de
materias o tesauros, que permite la recuperacin de documentos a partir
de palabras que no estn presentes en el documento original.
Conexiones de hipertexto o hipermedia: Este caso, en realidad, se
tratara de una bsqueda manual, ya que es el usuario el que navega
por el interior de los documentos a travs de las conexiones semnticas
que ofrecen los enlaces de este tipo.
ndices permutados: Permite la seleccin de palabras clave dentro o
fuera del contexto (KWIC/KWOC: Key Word In/Out Context).
Otras funciones que incluyen los SGD actuales son las de gestin de
biblioteca. Suele utilizarse este trmino para referirse a los mecanismos de
control de los documentos: de quin utiliza los documentos y qu documentos.
Esto puede hacerse mediante funciones de:
Retencin y destruccin de documentos, estableciendo el tiempo de
mantenimiento de un documento y asegurando que su destruccin
afecte a todas sus versiones.
Control de versiones, por ejemplo, para evitar que una nueva versin de
un documento sea reemplazada por una anterior.
Seguimiento de uso, para lo cual se puede guardar informacin
histrica asociada a cada documento, como quin trabaj con un
documento y cundo, el nmero de versiones que existen de l, y quin
cre las diferentes versiones.
Controles de acceso, que aseguren que slo los usuarios autorizados
puedan obtener los documentos, estableciendo, por ejemplo, diferentes
niveles de seguridad por usuario o por grupos de usuarios.
Replicaciones, para permitir guardar copias de documentos en cualquier
lugar de la red en la que est inmerso el SGD (por ejemplo, discos fijos,
cintas, discos pticos, etc.).
Los servicios de presentacin y distribucin que debe ofrecer un SGD son
los que establecen la forma en que se proporciona la informacin documental a
los usuarios. En este sentido un SGD debera permitir la distribucin de la
informacin en diferentes formatos, como pginas Web en Internet, CD-ROM
o impreso en papel. Actualmente est creciendo en importancia y popularidad
el concepto de impresin bajo demanda, donde un documento de una base de
datos documental pblica se puede imprimir cuando lo demande el usuario que
previamente habr abonado el coste correspondiente (por ejemplo, en Internet
para obtener ejemplares de publicaciones oficiales o revistas).
252 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Tambin es posible la utilizacin de visual izadores o herramientas capaces
de presentar al usuario cualquier documento en su estructura y formato
original, sin necesidad de adquirir las aplicaciones con las que fueron
elaborados. Por ejemplo, para ver" un documento escrito con WordPerfect 110
sera necesario disponer de este procesador de texto.
13.5 SISTEMAS DE W ORKFLOW
En un informe del Consejo Superior de Informtica (CSI, 1996) se define
como sistema de flujo de Trabajo o workflow aquel que permite definir,
ejecutar y gestionar procesos y tareas (unidades de trabajo) en base a unas
reglas.
Los sistemas de Gestin de Flujos son herramientas que permiten ayudar a las
mejoras de las condiciones de negocios: normalmente un grupo de empleados
colaboran sobre un conjunto de objetos para producir una serie de resultados
especficos.
Existen dos vertientes de workflow, los workjlows orientado a documentos
y los workjlows orientados a grupos de trabajo. En el caso de utilizar los
sistemas de workflow como herramientas de seguimiento de proyectos
informticos o como herramientas de ayuda al desarrollo efectuado por un
grupo de trabajo nos pueden servir las dos vertientes que se encuentran
desarrolladas ya que se pueden aplicar las caractersticas ms importantes de
estos sistemas, que van desde el enrutamiento de la informacin hasta los
interfases para el intercambio de la misma factores que ayudan a confeccionar
la documentacin tcnica.
El workflow permite manipular la informacin para incrementar la rapidez
de las bsquedas en sistemas documentales, actuar sobre ella y redirigirla hacia
los puntos demandantes de la misma de forma instantnea, consiguiendo una
alta productividad, mejor servicio al cliente, menores costes de operacin,
mejora en las satisfacciones del trabajo y mayor informacin en la toma de
decisiones.
La incorporacin de este tipo de herramientas permite la implantacin
racional del desarrollo de una compaa en dos niveles:
Los procesos de negocio
La integracin global de la ofimtica corporativa
C A P T U L O 13: LA C O M U N IC A C I N T C N IC A 253
En los procesos de negocio porque el sistema va marcando el camino por
donde deben de circular los flujos de comunicacin entre departamentos desde
los pedidos de los clientes hasta la prestacin del servicio con todo el sistema
de seguimiento integrado adjunto.
Frente a la integracin global de la ofimtica corporativa entendida como
todos los procesos de oficina porque integra todo tipo de lo que se denomina
los sistemas estratgicos.
Los denominados sistemas estratgicos, aplicaciones que agilizan la
realizacin de tareas en un entorno de trabajo colectivo, se caracterizan por
considerar las comunicaciones y los documentos como elementos
fundamentales, y por contribuir de forma decisiva a la automatizacin de los
procesos que tienen lugar en las organizaciones. Pero lo ms destacado, no
obstante, es que cada vez son ms las empresas y colectivos a quienes los
sistemas estratgicos han reportado un significativo aumento de los beneficios
procedentes de su inversin.
No son pocas las diferencias que separan a los sistemas estratgicos de
otras generaciones de aplicaciones que los precedieron, tales como los sistemas
operacionales y las aplicaciones para el aumento de la productividad personal:
aquellos se caracterizaban por su capacidad de procesamiento de transacciones,
el control centralizado y la automatizacin de tareas internas (nminas, libro
mayor, etc.); stas, por centrarse en la resolucin de tareas individuales tales
como la redaccin de una circular o la elaboracin de un presupuesto.
Mientras que los sistemas operacionales pueden ofrecer un informe sobre
los resultados de las transacciones ya procesadas, los estratgicos estn
orientados hacia el futuro en tanto que facilitan a las personas la toma de
decisiones y el cumplimiento de sus objetivos empresariales. De esta forma, un
sistema estratgico ofrece al usuario la posibilidad de explotar bancos de datos
para, por ejemplo, obtener informacin sobre clientes, mantener un
seguimiento de la competencia, conseguir noticias sobre productos o seguir la
evolucin de un ciclo de ventas. A todo ello se suma el hecho de que, mediante
un sistema estratgico, es posible acometer un proceso empresarial en su
totalidad, desde su concepcin inicial hasta su culminacin, siguiendo paso a
paso su evolucin y notificando a quien corresponda las incidencias que se
vayan produciendo.
Las empresas que se sirven de sistemas estratgicos cuentan con una
valiosa memoria empresarial en la que quedan almacenados, para su posterior
254 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
reutilizacin y consulta, todo su patrimonio documental, experiencia,
actividades y conocimiento del negocio.
El radio de accin de los sistemas estratgicos carece de lmites:
aplicaciones para la gestin de ventas y cuentas, aplicaciones para el desarrollo
de productos o aplicaciones de atencin al cliente.
La novedad no radica en las tareas en s, sino en el hecho de que la
introduccin de sistemas estratgicos mejora sustancialmente la calidad de la
informacin utilizada en estos procesos, reduce drsticamente el tiempo de
ejecucin de estos, y facilita el acceso a dicha informacin y su intercambio a
todos los componentes de un equipo de trabajo. Pero los mencionados no son
los nicos aspectos que diferencian a los sistemas estratgicos de sus
predecesores.
La incorporacin de sistemas de workflow facilitan la mecanizacin de una
serie de problemas actuales que requieren solucin como pueden ser la
proliferacin de:
Criterios cambiantes
Integracin de sistemas
Nuevas tecnologas, nuevos estndares
Seguimiento de expedientes en entornos administrativos.
Tendramos que considerar las implicaciones que conlleva la implantacin
del workflow a nivel operativa (se pretende que los miembros de los grupos de
desarrollo trabajen en entornos mas compactos, mas operativos y con mayor
informacin) y a nivel organizacin (se necesita una revisin de la situacin
real).
Dentro del mbito de los sistemas de workflow se definen una serie de
trminos de vital importancia para la definicin de los propios flujos de trabajo
que se describen a continuacin:
Competencia: Condicin que define la capacidad de un sujeto para
realizar una tarea. Las competencias pueden ser establecidas en un
proceso reglamentado o atribuidas en un momento concreto por el
sujeto jerrquicamente superior. Puede ser permanente o temporal y
puede ser ejercida por delegacin.
Datos: Valores que identifican todos los atributos de los procesos y
tareas especficas.
C A P T U L O 13 LA C O M U N IC A C I N T C N IC A 255
Diccionario de tipos: Repositorio en el que se almacenan para su
reutilizacin los procesos-tipo, las tareas-tipo, los estados, el conjunto
de sujetos con sus competencias y las reglas-tipo.
Estados: Tipos de situacin en los que puede encontrase una tarea:
ejecutada, en ejecucin, en espera, cancelada....
Flujo: Relacin, definida por reglas, entre las tareas de un proceso.
Objetos: Informacin asociada a las tareas almacenadas sobre cualquier
soporte fsico (no est asociado a la OO).
Plazo: Condicin en la que debe de cumplirse una operacin concreta:
Fecha concreta, fecha lmite, espacio de tiempo, fecha recurrente.
Prioridad: Escala que determina la preferencia de ejecucin de una
tarea frente a otras o de un proceso frente a otro.
Proceso: Conjunto de tareas ordenadas, por tiempo o por unas
condiciones contenidas en unas reglas, que son ejecutadas bien por los
sujetos competentes o de una forma automatizada (por autorizacin
expresa del sujeto competente). Un proceso puede tener subprocesos
hasta su descomposicin en tareas. Cada una de las ocurrencias de un
proceso se denomina proceso especfico (en algunos casos particulares,
expedientes, problema o caso).
Proceso abierto o no reglamentado: Proceso en el que los sujetos con
competencia o autorizados pueden ordenar tareas, procesos
completamente definidos, asignar reglas e incluso integrar tarcas
automatizadas de forma dinmica. Las citadas tareas, procesos y
reglas debern de estar catalogadas en los correspondientes
diccionarios.
Proceso reglamentado: Proceso en el que toda la secuencia de tareas o
subprocesos, la asignacin de reglas y la correspondiente integracin de
tareas automatizadas tiene un flujograma predeterminado.
Proceso semireglamentado: Proceso reglamentado en el que se prevn
excepciones que pueden alterarlo dinmicamente a voluntad de sujetos
competentes o autorizados para ello.
256 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Procesos-tipo: Procesos reglamentados que pueden ser reutilizados en
procesos abiertos o semirreglamentados en la fase de diseo. Deber de
estar en el diccionario.
Regla: conjunto de condiciones que regula el encadenamiento de las
tareas.
Regla-tipo: Reglas establecidas que pueden ser reutilizadas por los
sujetos competentes en la fase de diseo. Deben de pertenecer al
diccionario.
Sujeto: Usuario o grupo de usuarios que tiene la competencia para
realizar una tarea. Un usuario, segn los procesos, puede tener
atribuidas las competencias de distintos sujetos.
Tarea: Unidad mnima de trabajo que, combinada con otras tareas,
constituye un proceso. Las tareas pueden ser manuales, automatizadas o
semiautomatizadas.
Tareas automatizadas: Tareas-tipo que el sistema pone a disposicin'
de sujetos para que sean realizadas por ejecucin de una regla.
Tareas semiautomatizadas: Tareas-tipo que el sistema pone a
disposicin de los sujetos competentes para que sean realizadas a
peticin expresa y manual.
Tareas-tipo: Tareas que pueden ser reutilizadas por los sujetos
competentes en la fase de diseo. Deben de pertenecer al diccionario.
Tambin es importante citar, al menos, algunos procesos fundamentales de
la tecnologa de Gestin de Flujos:
Routing
Distribucin
Priorizacin
Registro de historia
Reporting
Instancias o casos
Grupos y Roles
Reglas y condiciones
C A P T U L O 13- 1,A C O M U N IC A C I N T C N IC A 257
Notificacin y firmas
A la hora de implementar en la puesta en marcha de un sistema de
workflow se debe de considerar los siguientes aspectos:
Cantidad de programacin necesaria para su puesta en marcha
Incorporacin de tecnologa Cliente/Servidor
Sistemas Abiertos
Capacidad de Personalizacin
Tecnologa Asociada
Tecnologa de Bases de Datos Relacional
Tipos de procesos que admite:
o Reglamentados
o Semi-reglamentados
o Abiertos
Imposicin de teoras particulares
Existen muchas herramientas para implementar un sistema de workjlow en.
los entornos corporativos, con este tipo de herramientas se logra la mxima
integracin de los sistemas informticos distribuidos en ios trabajos
colaborativos hasta englobar el concepto genrico de la organizacin
corporativa del trabajo que se logra con los sistemas de groupware que
trataremos en el siguiente apartado. En este tipo de entornos se aportan una
serie de ventajas como es el hecho de que se pueden tratar los procesos
conjuntos; la informacin no est limitada al mbito de cada departamento,
seccin o aplicacin, y, por lo tanto, la informacin de la empresa puede ser
ms coherente e integrada.
La solucin a los problemas planteados suele comenzar por la
informatizacin del tratamiento de los documentos relacionados con los
procesos. La gestin documental se puede encargar de gestionar, mediante
informtica, los documentos de nuestra empresa a nivel corporativo.
Actualmente se tratan los documentos abriendo grandes posibilidades para la
gestin de procesos de negocios. Las ventajas de procesar la Gestin
Documental son muy claras: seguridad, accesibilidad, ahorro en sistemas de
archivo, distribucin y copias...
Entendemos por proceso de negocio la combinacin de actividades,
dirigidas a un cliente y distribuidas en el tiempo, en las que intervienen
distintas personas de la empresa. La organizacin de la empresa suele estar
enfocada a la gestin de funciones y no a la gestin de procesos. Existe la
258 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
organizacin funcional que persigue la eficiencia de los trabajadores pero no
existe la orgnica horizontal" que persigue la eficacia de los procesos. El
workflow se puede aplicar por muy diversos criterios permitiendo que los
procesos estn informticamente documentados para su posterior recuperacin
y tratamiento eficiente de contenidos.
El enfoque del ciclo de vida completo de solucin WorkFIow estara
formado por las siguientes fases:
Anlisis y diseo: donde se estudian los procesos y se configura el
entorno de solucin
Creacin e Integracin del sistema: en los que se desarrollan los
procedimientos automatizados y se integra la solucin.
Implantacin, con el objetivo de minimizar el impacto del sistema,
haciendo que los usuarios lo utilicen corno propio.
Administracin, donde se aplican unas tcnicas para asegurar que todo
funciona correctamente.
Para efectuar el anlisis de implantacin de un sistema de workflow se
suelen seguir las siguientes tareas:
Se determinan las fronteras de la aplicacin, las iteraciones con otros
sistemas, el impacto que causar en la organizacin...
Se determinan los subsistemas funcionales:
o Subsistema de usuarios: grupos, autorizaciones, roles...
o Subsistema de puestos: condiciones de cada puesto y
herramientas del puesto
o Subsistema de timing: cundo se hacen las tareas y cuanto
tiempo cuestan.
o Subsistema de enrutamiento: a quin y por donde se envan los
datos...
o Subsistema de agenda: atiende al conjunto de tareas asignadas a
cada usuario, informando a cada usuario y administradores de
cada tarea a realizar,
o Subsistema de excepciones: si algo falla pasa control al
administrador.
o Subsistema de seguimiento: controla el estado de los
expedientes,
o Subsistema de Seguridad:
La Integracin del Sistema con los subsistemas fsicos
C A P T U L O 13: L A C O M U N IC A C I N T C N IC A 259
Subsistema de Gestin Documental: Control de versiones. Archivo,
Rplicas, Clasificaciones, Indexacin, Bsqueda, Distribucin,
Informes, etc.
Subsistema de Gestin de Imgenes
Subsistema de bsquedas especializadas de texto
Subsistema de Bases de Datos
Plataforma del sistema:
Servicios generales del sistema:
o correo electrnico
o faxes
o integrador de servicios de comunicaciones
Soporte a la heterogeneidad:
Soporte a nivel de desarrollo de aplicaciones a nivel C/S
Integracin con aplicaciones a medida existente o futuras
Para el desarrollo se deber realizar en el entorno de la plataforma
(normalmente heterogneo, y deber atender a las especificaciones definidas
por el anlisis. Es normal que la empresa tenga la necesidad de tener que
utilizar varios entornos de desarrollo por lo que es frecuente que casi siempre
hay que buscar APIs integradores de los sistemas. El desarrollo se puede guiar
por metodologas apropiadas.
La fase ms crtica se sufre en el momento de la implementacin donde se
trata de conseguir que los usuarios del sistema lo acepten como propio y lo
utilicen adecuadamente, minimizando el impacto negativo que pueda tener.
Para poder efectuar esta transicin con cierto xito es necesario una
preparacin o entrenamiento que debe de estar presente en todo ciclo de vida
del sistema y que consiste en la implementacin, migracin y formacin de un
sistema normal, y, adems, debe de contar con las actividades de difusin y
seguimiento de la utilizacin del sistema en base a indicadores previamente
determinados.
Como check-list para la implantacin de una metodologa del sistema de
workflow podemos citar los siguientes hitos:
Identificar el mbito y finalidad del Proyecto
No automatizar procesos errneos
Desarrollar un plan de proyecto detallado
Hacer la documentacin lo primero
Entender a la audiencia, su problemtica
No sobrecargar a los usuarios
260 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Ofrecer soportes on-line
Preparar Plan de contingencia
13.6 SISTEM AS DE GROUPWARE
De forma general, se puede decir que groupware es el software que
permite trabajar en grupo. Existen otros trminos que hacen referencia a la
misma idea que suelen considerase como sinnimos de groupware. Algunos de
ellos son: CSCIV (Computer Supported Cooperative Work)2, OIS (Office
Information System), Shareware, o simplemente Software para el trabajo
corporativo.
Aunque es un trmino que hace poco tiempo que ha comenzado a ser
utilizado, fue propuesto a principios de esta dcada, siendo Ellis (1991) quin
lo public por primera vez en un artculo titulado Groupware: Some Issues
and experiences, donde se identificaba con los sistemas basados en
computador que sirven de soporte a grupos de personas implicadas en una tarea
u objetivo comn que proporciona una interfaz para trabajar en un entorno
compartido.
En este sentido se analizaron los tipos de procesos de grupo que podan ser
soportados con la herramienta establecindose la siguiente clasificacin.
Colaboraciones individuales:
o Caractersticas de la comunicacin humana
o Patrones de trabajo individual
o Diseo de interfases para sistemas de soporte de grupo
Contexto Organizacioual:
o Representacin del conocimiento organizacional
o Diseo organizacional
o Consideraciones de administracin
Procesos de diseo de trabajos en grupo:
o La participacin de los usuarios
o Gestin de prototipos y test de usabilidad
o Procedimientos de diseo de trabajo en grupo
Dinmica de grupos:
o Procesos de colaboracin
2 En 1984 Irene Greiff (M1T) y Paul Cashman (DEC) definieron CSCW a un conjunto de
sistemas que estaban desarrollando y que incluir texto, voz, imgenes 3' video, con el objetivo
de incrementar la productividad personal consiguiendo al mximo la participacin de usuarios
C A P T U L O 13 LA C O M U N IC A C I N T C N IC A 26 1
o Rendimiento de grupo
o La conducta del grupo
En general se estudiaron una serie de procesos del grupo y la aportacin de
la tecnologa de los sistemas de informacin para utilizarla a favor de la mayor
eficiencia de las relaciones en mbitos de trabajo como:
Sistemas de correo electrnico
Sistemas de conferencias por ordenador
Sistemas de flujo de trabajo
Sistemas de calendario
Sistemas de archivos compartidos
Sistemas de coautor
Sistemas de pantalla compartida
Paquetes de soporte integrados en grupo
Sistemas de soporte de decisin de grupo
Sistemas avanzados de reunin
Herramientas de manejo y desarrollo de equipos.
Con esta visin general se han dado varias definiciones de lo que es el
groupware afinada por el profesor Sagrado, en 1996, como las herramientas
con las que las personas puedan trabajar juntas en un marco colectivo de
comunicacin, colaboracin y coordinacin.
Segn esta ltima definicin, el groupware debe proporcionar funciones
de comunicacin, colaboracin y coordinacin entre los integrantes de un
grupo de trabajo. El soporte tecnolgico de estas funciones lo constituyen las
aplicaciones informticas de mensajera electrnica, las bases de datos
compartidas y los sistemas de flujo de trabajo (workflow) respectivamente:
La mensajera o comunicacin electrnica est basada en correo
electrnico: El correo electrnico constituye el almacn y el medio de
transporte e intercambio de documentos electrnicos entre los integrantes de un
grupo de trabajo, garantizando la comunicacin o transmisin del conocimiento
de forma interpersonal. Sin embargo el fin del correo electrnico no es
disponer de unas bases de conocimiento del grupo para facilitar la
colaboracin.
La colaboracin es posible mediante la utilizacin de bases de datos
compartidas que facilitan el entendimiento comn y resultan fundamentales en
la comprensin de conceptos y asuntos claves en un entorno de trabajo. Se trata
262 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
de almacenes de documentos pblicos (normas, elementos de debate,
opiniones, etc.) que, en definitiva, permiten recoger el conocimiento y la
experiencia de los miembros de un grupo, as como la creacin de foros de
discusin dentro del grupo. El paradigma actual de colaboracin lo constituye
la red Internet, a travs de la cual un documento puede ponerse a disposicin
de millones de personas en todo el mundo para su consulta.
La tercera parte del groupware est formada por las funcin de
coordinacin es la que integra la comunicacin y la colaboracin en una
infraestructura global que permite la automatizacin de los flujos de trabajo en
el seno de un grupo. Lo que se pretende, en definitiva, al incorporar esta
funcionalidad al groupware es permitir a las organizaciones tener control e
incrementar la eficiencia de los flujos de documentos que soportan sus
negocios o actividades.
Aunque existen herramientas que utilizan por separado cada uno de estos
modelos tecnolgicos, la potencia de una herramienta de groupware radica en
su capacidad para integrar en un entorno dinmico y transparente la
comunicacin, la colaboracin y la coordinacin (fig. 13.2):
F ig u ra 3 .2 F unciones y tecn o lo g a s im plicadas e n el
tra b a jo corporativo (Sagredo, 1996).
La integracin de correo electrnico y bases de datos compartidas permite
incluir en los mensajes que se enven enlaces a documentos incluidos en bases
de datos compartidas, para que el destinatario pueda recibirlos cuando proceda
a la lectura de su mensaje. Por ejemplo, un mensaje de buenos das al director
C A P T U L O 13 LA C O M U N IC A C I N T C N IC A 263
de una empresa puede adjuntar las pginas electrnicas (almacenadas en
Internet) de los peridicos del da con informacin de inters para l. En
nuestro caso, la finalizacin de una tarea definida por el programa de gestin
de proyectos enviada va correo electrnico con el formato apropiado servir
para notificar el progreso del esfuerzo al superior jerrquico y para actualizar la
base de datos del proyecto donde, automticamente, quedar reflejado el
progreso, las fechas de finalizacin, las notas sobre las posibles incidencias y,
por ejemplo, los costes asociados a esa tarea
Mediante la integracin de correo electrnico con el workflow permite que
la automatizacin del flujo de trabajo basada en el encaminamiento de
documentos sirva al software de gestin de proyecto para que automticamente
desencadene una orden de trabajo de satisfacer los esfuerzos para realizar la
siguiente tarea dentro del proyecto aprobado.
Gracias a la integracin de bases de datos compartidas y los workflow los
participantes en un flujo de trabajo pueden consultar una base de datos
compartida de seguimiento para comprobar el estado de determinados
documentos. En estos sistemas es importante poder efectuar consultas al
control de versiones donde se permite la elaboracin explcita de versiones de
documentos a partir del original, facilitando el seguimiento de las
modificaciones realizadas por varios usuarios sobre el mismo documento,
incluso de forma simultnea. Tambin los usuarios pueden incorporar a un
documento original comentarios y sugerencias particulares.
Especial mencin merecen los mecanismos de replicacin soportados por
Notes que, entre otras funciones, permiten a los usuarios copiar documentos
desde el computador que contiene la base de datos documental (servidor) a un
computador porttil (cliente) para poder trabajar con dichos documentos sin
necesidad de tener abierta una conexin remota todo el tiempo. Solamente
cuando el usuario desee actualizar la base de datos con los cambios
introducidos por l o simplemente comprobar si algn otro usuario ha realizado
modificaciones en el documento original, deber volver a conectarse al
servidor y establecer un proceso denominado de replicacin bidireccional, que
garantiza que todos los integrantes de un grupo de trabajo localizados en
distintas zonas geogrficas compartan la misma informacin en todo momento.
Otra facilidad que se demanda para poder tener la informacin disponible
en el lugar y momento en que se demande es la inclusin de conversin de
documentos de texto a hmtl y viceversa, es decir, poder incluir en nuestra base
de conocimientos los documentos obtenidos de Internet como pginas Web
elaboradas con el lenguaje html.
264 P L A N IF IC A C I N Y G E S T I N DK S IS T E M A S IN F O R M T IC O S
Antes de terminar este captulo referido a la comunicacin tcnica es
interesante hacer algunas reflexiones sobre los sistemas estratgicos
definidos en el apartado anterior:
Los sistemas estratgicos han sido diseados para el "grupo de trabajo
ampliado". Bien poco han heredado los equipos de trabajo de hoy da del
carcter esttico de quienes colaboraban entre las cuatro paredes de una oficina
o departamento. En la actualidad, su naturaleza es bien distinta y mucho menos
homognea. Un sistema estratgico trasciende de las barreras organizativas
internas para llegar hasta departamentos dispares, hasta tal punto que su radio
de accin abarca tambin a quienes mantienen un contacto espordico con el
resto del grupo. En ocasiones, el alcance de los sistemas estratgicos traspasa
tambin los muros de una empresa para ponerla en contacto con sus
proveedores, clientes y socios en un proceso empresarial unificado.
Los sistemas estratgicos utilizan un modelo distinto de comunicacin.
Los sistemas estratgicos dependen en gran medida de la capacidad que tengan
sus usuarios para enviar mensajes y compartir informacin almacenada en un
sistema de gestin documental de fcil acceso.
Los sistemas estratgicos utilizan un modelo de gestin de la informacin
nico. Dichos sistemas gestionan datos semiestructurados de diversa
procedencia y presentacin. Como parece lgico pensar, difcilmente podran
utilizarse los mtodos convencionales de almacenamiento y recuperacin de la
informacin de una base de datos relacional para almacenar, clasificar y
gestionar unos documentos tan heterogneos. La base de datos de un sistema
estratgico gestiona las relaciones que emparentan a los documentos mediante
vistas jerrquicas indexadas, enlaces hipertextuales entre documentos y
"contenedores" de objetos.
CAPTULO 14
LA GESTIN DE CONFIGURACIONES
El objetivo del presente punto es describir la gestin de configuraciones, una
actividad que es crtica en la gestin y mantenimiento de sistemas grandes. Se
establecern las lneas maestras a considerar en la gestin de configuraciones y
se estudiarn los problemas tpicos que se suelen presentar. Finalmente se
establecer la estructura suficiente para estudiar la incidencia que pueden tener
los cambios a efectuar dentro de la planificacin y gestin de sistemas, como
influyen en la planificacin, cmo deben de ser controlados y como, en
proyectos de elevada magnitud, conviene que se planifique, como tareas aparte,
un grupo de personas cuya responsabilidad sea el control de dichos cambios.
A medida que progresa el proceso de Ingeniera del Software, el nmero
de elementos de configuracin del software (ECS), bien sean programas,
fuente, documentos de textos de texto con documentacin sobre los
requerimientos, pruebas, etc. crece rpidamente. Cada especificacin del
sistema produce un Plan de Proyecto del Software y una Especificacin de
Requerimientos del Software y, a su vez, estos documentos producen unos
nuevos documentos de creacin de jerarqua de informacin. Si cada ECS
produjera simplemente otra ECS no habra mayor problema pero
desgraciadamente interviene otro factor el cambio y aparecer por cualquier
motivo en cualquier momento, de hecho Bersoff en 1980, lo seala como la
Primera Ley de la Ingeniera de Sistemas diciendo: "sin importar en qu
momento del ciclo de vida del sistema nos encontramos, el sistem a cambiar y
el deseo de cambiarlo persistir a lo largo de todo el ciclo de vida".
Llevando el trmino de Elemento de Configuracin de software a su
ltimo extremo, se puede considerar una ECS a cada seccin individual de una
gran especificacin o cada caso de prueba de un conjunto de pruebas. Tal vez
sea ms realista considerar los ECS como un documento o un conjunto de
casos de prueba o un componente de programa especificado.
266 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M A T IC O S
Por otra parte la Gestin de Configuraciones Software (GCS) es responsa
ble de la identificacin de los ECS individuales y de las distintas versiones del
software, de las auditorias, de la generacin de la informacin de todos los
cambios realizados.
Cualquier discusin de la GCS plantea una serie de complejas cuestiones
del tipo:
Cmo se identifican en una organizacin las diferentes versiones
existentes de un programa de forma que se pueda modificar con
eficiencia?
Cmo controla la organizacin los cambios antes y despus de que el
software es enviado al cliente?
Quin tiene la responsabilidad de aplicar las distintas prioridades a los
cambios que han de resolverse?
Cmo podemos asegurar que los cambios se
correctamente?
Qu mecanismo se usa para informar al resto de la organizacin de los
cambios que se han producido?
Estas y otras preguntas nos llevan a la definicin de cinco tareas
importantes en la gestin de configuraciones del sistema: La identificacin, el
control de los cambios, el control de versiones, las auditorias de
configuraciones y la generacin de informacin.
14.1 CONCEPTO DE GESTION DE CONFIGURACIONES: SU
PAPEL EN EL CONTROL DE LA EVOLUCION DEL
SOFTW ARE.
La cantidad de cdigo instalada en los diversos dispositivos hardware se est
duplicando, segn Wayt Gibbs (1994), cada dos aos, esto est haciendo que,
por el crecimiento de los proyectos de desarrollo de software, cada vez sea ms
compleja la tarea de gestin de los mismos. Cada vez hay ms elementos a
tener en cuenta y con relaciones entre ellos cada vez ms complejas. El
crecimiento de la complejidad de gestin de un gran proyecto es tan grande que
C A P T U L O M: LA G E S T I N D E C O N F IG U R A C IO N E S 267
puede llegar a amenazar el progreso del propio proyecto (Mack-Crane en
1989).
Para superar estos obstculos Victor R. Basili contribuy a fundar el
Laboratorio de Ingeniera de la Programacin, con el fin de asentar la
programacin sobre cimientos matemticos y cientficos ms firmes. En este
sentido se han desarrollado tcnicas que aumentan en gran medida la eficacia
en el diseo e implementacin del software, aunque, a la vez, han
incrementado, desde el punto de vista de gestin de configuracin del software,
la complejidad de los proyectos.
En los grandes proyectos no slo hay que tener en cuenta su propia
complejidad sino, adems, segn Lago en 1995, la debida a las nuevas
relaciones y los nuevos elementos introducidos por las tcnicas de desarrollo
aplicadas.
El objetivo primordial de la Gestin de Configuracin del Software (en
adelante GCS) es proponer soluciones con el fin de conseguir que un proyecto
han realizado crezca de manera ordenada de forma que, a lo largo de su ciclo de vida, su
gestin sea manejable. Es, por tanto, el conjunto de tcnicas y actividades
desarrolladas para gestionar los cambios a lo largo del ciclo de vida de una
aplicacin, de cara a garantizar la calidad del software y la optimizacin de su
desarrollo y mantenimiento (IEEE 1042 de 1987). Cuando estas tcnicas se
aplican al desarrollo y mantenimiento del software, incrementan la calidad del
producto, reducen el costo del ciclo de vida, evitan la duplicacin de esfuerzos
y mejoran las funciones de gestin en el proceso de desarrollo y produccin.
Para satisfacer estas necesidades, y desde el punto de vista cientfico,
podemos afirmar que la GCS debe de proporcionar la metodologa adecuada
para la realizacin de software ajustndose a las necesidades de otras
metodologas de ingeniera de software. Todo esto significa mejorar los
controles y medidas de calidad, financiacin, y planificacin en el tiempo. As
mismo, significa estandarizar mtodos para evitar la duplicacin de esfuerzos y
permitir el fcil intercambio de informacin. En principio parece que se carga
con ms burocracia a los programadores, pero en realidad es todo lo contrario.
La aplicacin de GCS elimina, o facilita, muchas de las tareas aburridas que los
programadores ya realizan en el entorno de desarrollo de sistemas software,
permitindoles dedicar su esfuerzo al problema intelectual de disear y
construir, su verdadero trabajo. El GCS puede llevar a la automatizacin de las
funciones de organizacin, registro de la informacin y permitir, al equipo de
gestin, dedicarse a lo que realmente cuenta.
268 PL A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Los procesos para la mejor gestin de un proyecto de desarrollo de
soware, an apoyndose en metodologas efectivas como las descritas en las
normativas internacionales, puede ser muy laboriosa (Reichenberger, 1995).
Para apoyar esta tarea, se utilizan estructuras de informacin que clarifican las
relaciones entre las distintas entidades a gestionar. La aplicacin del lgebra de
retculos para la clasificacin de conceptos es, en este sentido, muy eficaz,
como se estudia en el captulo tercero.
La Gestin de Configuraciones del Software es "una disciplina aplicada a
a direccin, vigilancia tcnica v administrativa de la identificacin y
documentacin de las caractersticas de un elemento de configuracin, el
control de los cambios de estas caractersticas, el registro e informe del
proceso del cambio y del estado de la realizacin, asi como la verificacin de!
cumplimiento de requerimientos especficos'^.
Los pioneros en aplicacin de GCS fueron las grandes compaas de
software y los equipos muy especializados con contratos en el rea de defensa
y aeroespacial. Los procedimientos que se utilizaron tendan a la complejidad,
lo que lo ha hecho inapropiados para muchos proyectos (aquellos de pequeo
tamao), sin embargo, muchas de las ideas fundamentales son directamente
aplicables a proyectos de todo tipo, mejorndolas y adaptndolas a las distintas
metodologas de trabajo.
Una de las primeras implementaciones de herramientas para ayudar a
gestionar la Gestin de Configuraciones (en ingls Configura! ions
Management) fue a mediados de los setenta con UNIX y su PWB
{Programmers Work Bench) que contiene el SCCS (source code control
system) orientado a la gestin de configuraciones en formatos textuales. El
lenguaje ADA (principio de los ochenta) no olvid disponer de un componente
de Gestin de Configuraciones dentro de sus IPSE (lntegrated Project Support
Environment). Posteriormente han aparecido en algunos de los denominados
entornos de programacin (por ejemplo en EPIQS)
La forma ms simple de justificar la necesidad de la GCS se encuentra en
las situaciones que de forma cotidiana abordan el propio desarrollo del
software en sus distintos entornos de produccin. Preguntas como Cundo
estar listo determinado programa?Cundo se puede corregir el error? Qu
versin est actualmente en uso? Cunto costar esta expansin? Qu
componentes estn involucrados y cunto costar este cambio?.
1 Definicin del IEEE Standard Glossary of Software Engmeering, edicin de 1990.
C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 269
A este tipo de cuestiones nicamente se puede contestar de forma
razonable cuando existe algn tipo de control de la configuracin pudiendo
afinar en las respuestas en funcin de la informacin de la que dispongamos en
cada momento. En este sentido el Instituto de Ingeniera del Software
Carnegie Mellon public en 1991 un documento titulado "State-of-the-Art in
Environment Support fo r C M cuyo objetivo era hacer comprender la
importancia que tiene el papel de la gestin de configuracin dentro de un
proyecto. En el mismo se muestran resultados de una encuesta simple que
muestra como se estn usando los proyectos de Gestin de Configuraciones
poniendo en manifiesto que para poder contestar a las preguntas anteriores ser
necesario tener previstas una serie de funciones en el proceso de Gestin de
Configuraciones que resumimos en el siguiente esquema:
La Identificacin de la Configuracin especfica:
o Componentes del producto software con su identificacin y sus
atributos.
o Recopilacin de estos componentes frente a sus requerimientos.
La Gestin de archivo y proceso de peticiones de cambio.
o Verificacin de sus consecuencias tcnicas.
o Decisin de su aceptacin, demora o rechazo.
o Creacin de rdenes de realizacin en caso de aceptacin.
Inspeccin de la Configuracin comprobando los cambios
o Nmero total las peticiones de CR se han desarrollado
o Registro de cundo se han modificado todos los componentes
afectados
o Informacin de cundo se ha producido un cambio no
planificado
Registro del estado de las configuraciones bases y prerrequisitos
El trmino gestin de configuracin fue originalmente aplicado a los
controles de desarrollo y produccin de hardware y, posteriormente, al
problema del mantenimiento. En este sentido, Jones afirma en 1994 que todos
los proyectos tienden a experimentar un cambio mensual del 1 % y cuanto ms
largo sea un proyecto ms cambiar su producto una vez finalizado.
Durante la breve historia de los sistemas software la falta de metodologa
de control ha conducido a muchos y muy publicitados costossimos desastres
(Gibbs en 1994), y es en respuesta a esto por lo que la GCS se ha desarrollado.
Muchas de las tcnicas han sido tomadas de las experiencias en hardware,
270 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
donde una historia ms larga ha permitido establecer buenos mtodos de
trabajo. Otras han sido producto de las especiales caractersticas de los sistemas
software. Muchas son en realidad buenas prcticas de trabajo que
programadores individuales aplican a su propio trabajo. Un programador
profesional normalmente aplica muchas de estas tcnicas a su trabajo cotidiano
sin pensar en ello. Por ejemplo, nombra programas dejando huella de los
cambios que ha hecho, guarda las versiones antiguas, y comprueba la precisin
de su trabajo en puntos predefinidos. Despus, estas tcnicas han sido
extendidas y formalizadas para trabajar con proyectos complejos, que implican
a un gran nmero de personas.
Un concepto muy vinculado a la GCS es el de lneas base (baseline): una
lnea base es una referencia en el desarrollo del software que quedar marcada
por el envo del documento de configuracin del software y la aprobacin de
ECS (Elementos de Configuracin del Software) obtenida mediante una
revisin tcnica formal.
Una lista de configuracin es un conjunto de ECSs identificadas por un
nombre, una versin y, opcionalmente, por unos atributos entre los que se
encuentran la asignacin de la versin del producto. Es de destacar que,
normalmente, la versin tiene una estructura jerrquica.
Las listas de configuracin pueden estar congeladas entre dos lneas
bsicas. Es ms, la tcnica que se utiliza es tratar de congelar la lista de
configuracin como si se tratara de hacer una fotografa de la configuracin,
tratando de que no salga ningn componente movido.
Como todo desarrollo es un paso entre dos estados congelados, el trabajo a
realizar se descompone en paquetes de trabajo que se entrega al equipo de GCS
quien devolver el paquete una vez completado, documentado y probado.
En general, el responsable de desarrollo, define, planifica y controla como
se realiza la GCS definiendo quin realiza esta funcin. En este sentido, y para
garantizar la calidad del producto, el responsable de desarrollo realiza las
siguientes tareas:
Identificacin de objetos de la configuracin del software
Control de versiones
Control de cambios
Auditoria de la configuracin
Informes de estado
Observacin de estndares
C A P T U L O 14: L A G E S T I N D E C O N F IG U R A C IO N E S 271
Identificacin de objetos en la configuracin del software
Analizando este problema Babich en 1986 habla del arte de coordinar el
desarrollo del software para minimizar la confusin que se produce en las
distintas fases del ciclo de vida del software, simplificando, controlando y
organizando las modificaciones que se sufren en el software que construye un
equipo de programacin pero esos son slo los sntomas que observamos no las
causas que lo producen.
14.2 M ANTENIMIENTO DE LA INTEGRIDAD DEL
PRODUCTO.
En el inicio de los tiempos de la programacin, las tareas de los programadores
consistan exclusivamente en codificar y depurar, sin dar importancia a disear
algo antes de desarrollarlo. En general, no se usaban modelos de programa para
asegurar que el resultado final se ajustase al propsito inicial, o para definir una
estructura de programa prctica y mantenible.
De esta forma los cambios producidos posteriormente, como han podido
ser por la adaptacin al Euro o la problemtica del ao 2000, han hecho que
mucho viejo software sea infranqueable. Con el tiempo, cuando se acometieron
por primera vez grandes programas, y se construyeron con aquellos mtodos,
resultaron pobremente estructurados. As, resultaban muy caros y, en algunos
casos, imposibles de mantener. A menudo, no se ajustaban a los requerimientos
iniciales del usuario. Con el paso del tiempo, los ingenieros aprendieron a
desarrollar los grandes sistemas en series de etapas, cada una de las cuales
produce una lnea base o configuracin de referencia que es tomada como
plataforma para las actividades de la siguiente etapa.
Segn la terminologa ANSI-IEEE el mantenimiento del software se
define como el Proceso de modificar un sistema o componente software
despus de Ia entrega al cliente o usuario para corregir defectos, mejorar el
rendimiento o atributos, adaptarlo a un cambio de entorno o ampliar su
funcionalidad'. Una lnea base puede tomarse como un producto o
especificacin que ha sido formalmente aprobado por los miembros del
proyecto de desarrollo y puede cambiarse slo mediante procedimientos
formales de control de cambios. De una manera ms sencilla se puede tomar
como una fotografa aprobada del sistema en un punto dado de su
configuracin.
272 P L A N IF IC A C I N Y G E S T I N D E SIS TE M A S IN F O R M T IC O S C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 273

El modelo de cascada es efectivo cuando el control de cambios sea muy

riguroso. Una lnea base no debe ser cambiada sin un cuidadoso estudio de las
consecuencias del cambio. Este modelo est muy ampliamente aceptado, pero
para algunos casos es necesario encontrar otros modelos, ya que en este
modelo los cambios son aceptables pero altamente indeseables. Por esto se han
estudiado modelos alternativos.

Desarrollo evolutivo. Con este modelo se desarrolla un sistema que

Figura 14.1 Modelo de desarrollo de etapas sucesivas.
despus se modifica progresivamente hasta que se ajusta a los requerimientos
del usuario. Este modelo es recomendado para sistemas altamente innovadores
en los que es difcil formular requerimientos detallados y es difcil evaluar la
correccin del resultado. El problema con este modelo es que es bastante
parecido a simplemente codificar y depurar. Es fcil que se llegue al mismo
tipo de problemas a que se lleg con la falta de modelos.

Un ejemplo simple puede ser el propio modelo de etapas del ciclo de vida
del soware: La etapa de anlisis de requerimientos, en la que se produce una
lnea base que establece lo que el sistema tiene que hacer. La etapa de diseo
en la que su lnea base define una estructura que se ajusta a los requerimientos.
La etapa de implementacin, que tiene por objetivo producir un sistema
terminado y la etapa de mantenimiento, que produce una sucesin de sistemas
terminados, que perfeccionan, adaptan y corrigen las lneas base previas.

Segn este modelo, la lnea base producida por cada etapa es la base para
las actividades de la siguiente etapa. Cada lnea base antes de la
implementacin del sistema es una abstraccin en la que se ignoran algunas
propiedades. Cuanto ms temprana, en la lnea de desarrollo por etapas, se
defina una lnea base, ms abstracto es el modelo que refleja. Cada etapa puede
considerarse como el proceso de transformacin de un modelo abstracto del
sistema a uno menos abstracto.

Una mejora respecto del mtodo anterior de slo codificar y depurar es el
modelo de etapas sucesivas que reconoce la necesidad de disear antes de
construir. Sin embargo, cada etapa no puede comenzar hasta que la anterior ha
terminado, y una vez terminada, la lnea base producida no se puede cambiar.
No es esto lo que ocurre en la realidad. Habitualmente, como reconoce Bersoff
en 1980, los requerimientos cambian mientras se est diseando, la imple-
mentacin revela errores de diseo o se encuentran mtodos ms eficaces de
conseguir los objetivos marcados. La manera de solucionarlo es retirar las
partes inadecuadas de cada etapa y reajustarla sobre la marcha volviendo al
paso anterior si as fuera necesario lo que constituye el modelo en cascada.
Control del cambio
Figura 14.2 Modelo de desarrollo en cascada.
Prototipos. El modelo de prototipos requiere construir el sistema varias
veces. Todas las implementaciones excepto la ltima son prototipos. Para
Brokks (1975), el propsito es establecer detalladamente los requerimientos o
investigar la factibilidad de una estrategia de implementacin a partir de un
primer sistema que, normalmente, es desechable.
274 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Desarrollo incremental. El desarrollo incrementa! divide el sistema en
partes que se producen en sucesin. Cada incremento del sistema tiene su
propio ciclo de vida y puede solapar en el tiempo a los otros incrementos. Este
mtodo permite terminar rpidamente una parte del sistema e influenciar el
desarrollo de posteriores incrementos.
cascada desarrollo evolutivo prototipos desarrollo incremental
(R=requerimentos, D=diseo, Iim plantacin)
Figura 14.3 Modelos de desarrollo de proyectos.
Como veamos en la definicin de ANSI/IEEE, la historia de los sistemas
software no termina cuando su desarrollo se termina y se entrega al usuario. De
hecho, el ciclo de vida de un producto software no termina hasta que deja de
utilizarse. El sistema debe ser mantenido y no necesariamente por los mismos
que lo desarrollaron. Esta es una actividad que consume an ms recursos que
el desarrollo, ya que los programas de computadora siempre estn cambiando
(ver figura 14.4). Hay que solucionar errores, aadir mejoras y llevar a cabo
optimizaciones. No solo hay que cambiar la versin actual, sino tambin la
versin del ao pasado (que todava est siendo usada) y la versin del ao que
viene (que ya casi funciona). Adems de los problemas que conlleva la
realizacin de cambios para solucionar los errores, el hecho mismo del cambio
ya conlleva problemas adicionales.
C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 275
P ru e b a s P fu e b a s
m nrtnlnro; d o in te g ra c i n
C digo
M a n te n im ie n to
Figura 14.4 Distribucin del coste del ciclo de vida.
Las cuatro actividades en las que se puede encuadrar el mantenimiento de
sistemas software son: Mantenimiento Correctivo, formado por los cambios
que se introducen para corregir los errores que no se detectaron durante el
desarrollo del sistema. El M antenimiento Adaptativo, compuesto por los
cambios que se hacen necesarios para acomodar el sistema a los cambios del
entorno en el que el sistema opera. E! Mantenimiento Perfectivo que est
formado por los cambios pedidos por el usuario que mejoran el sistema pero
que no cambian su funcionalidad bsica2. Y el Mantenimiento Preventivo que
los forman aquellos cambios orientados a conseguir que los tipos de manteni
miento anteriores se hagan ms fcilmente.
El mantenimiento correctivo se produce debido a que no es razonable
asumir que las pruebas de software hayan puesto de manifiesto todos
los errores latentes de un gran sistema de software. Durante el uso de
cualquier gran programa se encontrarn errores, siendo informado el
equipo de desarrollo. El proceso que incluye el diagnstico y la
correccin de uno o ms errores se denomina mantenimiento correctivo.
El mantenimiento adaptativo se produce, fundamentalmente, debido al
rpido cambio inherente a todo aspecto de la informtica. Se anuncian
nuevas generaciones de hardware en ciclos de tiempo cada vez ms
cortos; regularmente aparecen nuevos sistemas operativos o nuevas
versiones de los antiguos; y frecuentemente se mejoran o modifican los
equipos perifricos y otros elementos del sistema. Por otro lado, la vida
til del software de aplicacin puede fcilmente sobrepasar los diez
aos, hacindose obsoleto para el entorno del sistema para el que fue
2 Gorla en 1991 subdivide a su vez este mantenimiento en mantenimiento de ampliacin y el
mantenimiento que mejora la eficiencia de ejecucin.
2 76 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
originalmente desarrollado. Por tanto, el mantenimiento adaptativo es
tan necesario como corriente.
El mantenimiento perfectivo se produce cuando el paquete tiene xito.
A medida que se usa el software, se reciben de los usuarios
recomendaciones sobre nuevas posibilidades, sobre modificacin de
funciones ya existentes y sobre mejoras en general. Para satisfacer estas
peticiones, se lleva a cabo el mantenimiento perfectivo. Esta actividad
suma la mayor cantidad de esfuerzo empleado en el mantenimiento del
software.
En cuanto al mantenimiento preventivo, se da cuando se cambia el
software para facilitar una futura facilidad de mantenimiento o
fiabilidad, o para proporcionar una base mejor para futuras actuaciones.
Se adecan las estructuras a nuevas metodologas que mejoran la
capacidad del sistema de ser cambiado. Esta es una actividad
relativamente rara en el mundo del desarrollo de software ya que
supone un importante cambio de mentalidad en la alta direccin de la
empresa.
Entre los muchos problemas clsicos asociados con el mantenimiento de
software se encuentran los siguientes:
No existe una documentacin apropiada o est mal preparada. Un
primer paso es el reconocimiento de que el software debe ser
documentado, pero para que la documentacin sea de algn valor debe
ser comprensible y consistente con el cdigo fuente. Esto es, variar a
medida que los programas varan, y en el mismo sentido.
La mayora del software no ha sido diseado previendo el cambio. A
menos que el diseo prevea el cambio mediante conceptos tales como
independencia funcional o clases de objetos, las modificaciones del
software sern difciles y propensas a errores.
A menudo es excepcionalmente difcil comprender un programa
ajeno. Si slo existe el cdigo indocumentado, es de esperar que
aparezcan serios problemas.
Ese personaje ajeno a menudo no se encuentra alrededor para poder
explicarse. La movilidad de los profesionales del software es
actualmente muy grande. No podemos esperar una explicacin personal
C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 277
del software por la persona que lo ha desarrollado una vez que se
requiere el mantenimiento.
El mantenimiento no se ve como un trabajo atractivo. Muchas de las
causas de esto vienen dadas por el alto nivel de frustracin asociado con
el trabajo de mantenimiento.
La mayora de los problemas asociados con el mantenimiento del software
se deben a las deficiencias de la forma en que el software ha sido definido y
desarrollado. Aqu aparece el clsico sndrome del pague ahora o pague
despus". La falta de control y disciplina en las primeras fases del desarrollo de
software casi siempre se traducen en problemas a la hora del mantenimiento.
La esencia del mantenimiento es la modificacin del software actualmente
existente. Sin embargo, la modificacin es siempre peligrosa.
Desgraciadamente cada vez que se introduce un cambio en un complejo
procedimiento lgico, la posibilidad de error aumenta. La documentacin del
diseo y una cuidadosa prueba de regresin ayudan a eliminar los errores, pero
seguirn apareciendo efectos secundarios del mantenimiento. La obligacin del
jefe de proyecto, en este sentido, ser asegurar la integridad del producto
entendido como una forma de garanta de calidad como podremos comprobar
en los siguientes apartados.
Normalmente nos comunicamos con la mquina mediante cdigo fuente
de un lenguaje de programacin y las posibilidades de efectos secundarios
abundan. Aunque cada modificacin de cdigo potencialmente puede inducir a
error, los siguientes cambios tienen mayor probabilidad de inducir a error que
otros:
Un subprograma que es eliminado o cambiado.
Eliminacin o modificacin de una sentencia de etiqueta.
Eliminacin o modificacin de un identificado!-.
Cambios para mejorar el rendimiento en ejecucin.
Modificacin de apertura o cierre de archivos.
Modificacin de operadores lgicos.
Traduccin de cambios del diseo en importantes cambios sobre el
cdigo.
Cambios sobre las pruebas de lmites.
Los efectos secundarios sobre el cdigo van desde los insulsos errores que
se detectan y remedian durante las pruebas de regresin, hasta los problemas
27 8 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
graves que pueden hacer que falle todo el sistema. El hecho es que durante el
mantenimiento, a menudo se hacen cambios sobre determinados elementos de
una estructura de dalos o sobre la propia estructura de datos. Cuando cambian
los datos, el diseo del software puede no cuadrar con los datos y aparecer
errores. Los efectos secundarios sobre los datos tambin aparecen como
resultado de las modificaciones sobre la estructura de informacin de software.
Los siguientes cambios en los datos a menudo producen efectos
secundarios:
Redefinicin de constantes locales o globales.
Redefinicin de formatos de registros.
Aumento o disminucin del tamao de arrays o de otras estructuras de
datos.
Modificacin de datos globales.
Reinicializacin de indicadores de control o de punteros.
Reorganizacin de argumentos de E/S o de subprogramas.
Los efectos secundarios sobre los datos se pueden limitar, segn
Mogilensky (1994) mediante una profunda documentacin del diseo que
describa las estructuras de datos y d una referencia cruzada que asocie los
elementos de datos, los registros, los archivos y otras estructuras a los mdulos
software.
Tambin sobre la documentacin pueden aparecer efectos secundarios
cuando no se reflejan los cambios del cdigo fuente en la documentacin del
diseo y en los manuales orientados al usuario. Pasa a menudo que la
documentacin se deja para el ltimo momento. Al final, por problemas de
plazos de entrega, la documentacin no es un fiel reflejo de la realidad de un
sistema.
Siempre que se haga un cambio sobre el flujo de datos, sobre la
arquitectura del diseo, sobre los procedimientos (mdulos) o sobre cualquier
otra caracterstica asociada, se debe actualizar la documentacin tcnica de
soporte. La documentacin de diseo que no refleje el estado actual del
software es peor incluso que la ausencia total de documentacin. Cuando un
examen inocente de la documentacin tcnica lleva a una determinacin
incorrecta de las caractersticas del software, se darn efectos secundarios en
los consiguientes esfuerzos de mantenimiento.
Para el usuario, el software slo es tan bueno como lo sea la
documentacin (tanto escrita como interactiva) que describe su uso. Al fin y al
C A P T U L O l-t: LA G E S T I N DE C O N F IG U R A C IO N E S 27 9
cabo, lo que un usuario ve de un sistema es en gran parte la documentacin. Si
no se reflejan los cambios del software ejecutable en la documentacin de
usuario, los efectos secundarios estn garantizados. Por ejemplo, los cambios
de formato en la entrada interactiva, si no estn adecuadamente documentados,
pueden producir problemas significativos. Tambin los mensajes de error no
documentados pueden causar gran confusin; tablas, ndices o texto no
actualizados pueden llevar al usuario a la frustracin y la insatisfaccin.
Los efectos secundarios sobre la documentacin se pueden reducir
substancialmente si se revisa la configuracin entera antes de lanzar una nueva
versin del software. De hecho algunas peticiones de mantenimiento pueden no
requerir cambios en el diseo del software o en el cdigo, sino indican falta de
claridad en la documentacin de usuario. En tales casos, el esfuerzo de
mantenimiento se centrar en la documentacin.
14.3 NORM ALIZACION DE LA GESTION DE LA
CONFIGURACION.
Antes de seguir estudiando la Gestin de Configuraciones vamos a pararnos a
efectuar unas consideraciones sobre la importancia de la normalizacin en los
procesos de la Ingeniera del Software: En general la normalizacin es una
actividad colectiva encaminada a establecer soluciones repetitivas. Las normas
son documentos tcnicos con la caracterstica de contener especificaciones
tcnicas de aplicacin voluntaria y que son elaboradas por consenso de las
partes interesadas: fabricantes, administraciones, usuarios y consumidores,
centros de investigacin y laboratorios, asociaciones y colegios profesionales y
agentes sociales. Entre las caractersticas a destacar podemos considerar que
estn basadas en los resultados de la experiencia y el desarrollo tecnolgico,
que son aprobados por un organismo de normalizacin reconocido y el hecho
de estar disponibles al pblico.
Las normas ofrecen un lenguaje en comn de comunicacin entre las
empresas, la Administracin, los usuarios y los consumidores; establecen un
equilibrio socioeconmico entre los distintos agentes que participan en las
transacciones comerciales, base de cualquier economa de mercado, y son un
patrn necesario de confianza entre el cliente y el proveedor.
Para Sanll y Stoll, en 1995, la normalizacin ofrece serias ventajas tanto a
nivel fabricantes como a nivel consumidores y administracin. Para los
fabricantes permite, entre otras cosas, racionalizar variedades y tipos de
280 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
productos, permitiendo una mejora en la gestin y en el diseo. Para los
consumidores es conveniente porque establece niveles de calidad y seguridad
de los productos y servicios. Las ventajas para la administracin
fundamentalmente residen en que establecen polticas de calidad.
Existe una gran cantidad de organismos normalizadores de los cuales
vamos a sealar aquellos de mayor relevancia dentro del campo de Ingeniera
del Software que tienen algn tipo de vinculacin con la Gestin de
Configuraciones, entre las que cabe destacar las siguientes:
IEEE. Institute o f Electrical and Electronics Engineers. Asociacin
internacional ampliamente reconocida en la generacin de estndares.
ISO. International Organization for Standardization. Es la organizacin
que desarrolla un mayor nmero de estndares mundialmente,
principalmente estndares tcnicos.
NASA. National Aeronautics and Space Administration. Organizacin
de desarrollo de proyectos espaciales, para cuyo soporte genera normas
ampliamente difundidas.
DoD. Department o f Defense o f USA. Organizacin militar
estadounidense que genera y divulga importantes normas para su
funcionamiento.
De las normas anteriores hemos realizado una recopilacin de algunas de
ellas, de amplia utilizacin profesional en la Gestin de Configuraciones
Software, a fin de evaluarlas y elaborar una serie de directivas y documentos
esquemticos dirigidos a una rpida y cmoda puesta en prctica de sus
contenidos.
IEEE Std 828-1990, IEEE Standard for Software Configuration
Management Plans, American National Standards Institute, 1990.
IEEE Std 1042-1987, IEEE Guide to Software Configuration
Management, American National Standards Institute, 1987.
NASA Sfiv DID 04, Software Configuration Management Plan Data
Item Description, National Aeronautics and Space Administration,
Version 3.0, October 15, 1986.
C A P T U L O 14: L A G E S T I N DK C O N F IG U R A C IO N E S 281
NASA D-GL-II, Software Configuration Management for Project
Managers, National Aeronautics and Space Administration. Versin
0.2. March, 1987.
DoD-STD-2167A, Military Standard for Defense System Software
Development, Department o f Defense, June 4, 1985.
DoD DI-MCCR-80030A, Data Item Description for the Software
Development Plan, Department o f Defense, June 1986.
DoD M1L-STD-973, Military Standard for Configuration Management,
Department o f Defense.
DoD MIL-STD-483A, Configuration Management Practices for
Systems, Equipment, Munitions, and Computer Programs.
Como consecuencia de toda la normativa estudiada, as como los artculos
y documentos tcnicos tratados, se confirma que la gestin de configuracin de
software es un trmino que cubre un conjunto de tcnicas, que cuando se
aplican al desarrollo y mantenimiento de software, incrementan la calidad del
producto, reducen el costo de mantenimiento durante el ciclo de vida, y
mejoran las funciones de gestin para el proceso de desarrollo y produccin.
Segn las normas expuestas el propsito de la GCS es proporcionar la
metodologa para la realizacin de software ajustndose a las necesidades de
otras metodologas de ingeniera de software. Esto significa mejorar los
controles y medidas de calidad, financiacin y planificacin en el tiempo3.
Tambin significa estandarizar mtodos para evitar la duplicacin de esfuerzos,
y permitir el fcil intercambio de informacin. En principio parece ms
burocracia sobre los programadores, pero en realidad es justo lo contrario. La
aplicacin de GCS elimina o facilita muchas de las tareas aburridas que los
programadores ya realizan en el entorno de desarrollo de sistemas software,
permitindoles dedicar su esfuerzo al problema intelectual de disear y
construir, que es su verdadero trabajo, aplicando controles para garantizar que
el proyecto est trascurriendo dentro de sus dominios de definicin. Puede
llevar a la automatizacin de las funciones de organizacin, registro de
informacin (cosas que las mquinas hacen muy bien y los humanos muy mal)
3 W. Gibbs, en su artculo Soflware's Chronies Crisis, publicado por la Scientific American en
septiembre de 1994 (y traducido a la filial espaola Investigacin y Ciencia en la misma fecha),
describe algunos proyectos software plagados de cambios de requerimientos cuya gestin puso
en peligro la realizacin de los mismos.
2 82 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
y permitir al equipo de gestin dedicarse a lo que realmente importa. Los tres
principales conjuntos de controles a los que normalmente se aplica son:
Tcnico: La necesidad de proporcionar ciertas funciones que implican
el conocimiento de ciertas restricciones tcnicas.
Financiero: La necesidad de mantener ciertos presupuestos financieros
y de plazos de entrega para el proceso de desarrollo, y producir al final
un sistema con algunas restricciones de precio.
Calidad: Asegurar que la calidad del desarrollo satisface las
necesidades del usuario y permitir un proceso de produccin y
mantenimiento eficiente.
Durante mucho tiempo estos controles se han considerado separados, pero
en realidad interaccionan. Por ejemplo, se pueden reducir los costos financieros
bajando los requerimientos tcnicos o reduciendo la calidad (y por tanto
posiblemente, aumentando los costos de produccin y de mantenimiento). En
muchos sistemas software que funcionan correctamente, ya existen mtodos de
control operativos. El propsito de GCS no es sustituir alguno de ellos, ni
aadir ningn control nuevo, sino proporcionar una metodologa simple que
ayude a la operacin de esos controles, coordinarlos, y evitar o reducir la
sobrecarga de los gestores de proyecto.
14.4 ESTABLECIM IENTO I)E LNEAS MAESTRAS.
La base fundamental de la GCS es la lnea base o configuracin de referencia:
Un hito en el proceso de imple mentacin de un producto, contra el que se
puede medir el progreso, y que forma una base para futuras actividades. Puesto
que es una base para el progreso futuro, debe ser tan firme como se pueda
conseguir. De aqu la necesidad de congelar las especificaciones y versiones
del sistema en ciertas etapas. No obstante, como la naturaleza del desarrollo es
impredecible, y los desabolladores son humanos, puede aparecer la necesidad
de alterar esa base firme en posteriores etapas. Cada cambio debe hacerse slo
despus de considerar las posibles consecuencias, y una vez hecho, hay que
distribuirlo a todas las personas responsables implicadas. El sistema que
controla estas operaciones se llama normalmente control de cambios, y se ha
utilizado durante aos en el desarrollo y produccin de hardware. Es muy
importante que el sistema de control de cambios no sea demasiado burocrtico,
C A P T U L O H : L A G E S T I N DE C O N F IG U R A C IO N E S 283
en particular, la espera para la aprobacin de un cambio no debe ser un cuello
de botella.
Incluso despus del desarrollo, un sistema software no permanece estable:
se encuentran errores que hay que arreglar, hay peticiones de mejoras, etc.
Durante este periodo, que normalmente es mucho ms largo que el tiempo de
desarrollo, los responsables del sistema tienen que estar cambiando cosas, y
para las que no cambian, es peor, ya que la memoria se desvanece. En estas
circunstancias, si las incidencias no mucho mayores que errores se registran,
los cambios estn controlados, todos los cambios estn registrados y se hacen
hackups, la documentacin se mantiene coherente con el estado actual del
software. En el caso de cambios mayores, el trabajo se puede considerar como
volver a desarrollar, y la metodologa de desarrollo es igualmente aplicable.
Uno de los problemas de trabajar con software es que no hay entidades
mensurables suficientemente aceptadas que se puedan usar para observar el
progreso o la calidad entre la concepcin inicial y el resultado final del
proyecto. De hecho aunque se pueda probar la existencia de un sistema final,
su calidad o la medida en que se ajusta a las especificaciones iniciales es difcil
de demostrar, y en algunos sistemas, imposible de demostrar de manera
concluyente.
A lo largo de los aos se han diseado muchas tcnicas para aproximarse a
la mensurabilidad del software. Uno de las ms importantes es el concepto de
lneas base o configuracin de referencia.
Una lnea base es un punto base o de referencia en el esquema de trabajo
de desarrollo del proyecto cuya consecucin puede ser demostrada
objetivamente. Tiene tres funcionalidades que debe dar:
Punto de progreso mensurable
Rase para el posterior control y desarrollo
Punto de medida para evaluar la calidad y el grado de ajuste a las
especificaciones antes de que se termine todo el sistema.
Para conseguir estos propsitos, cada lnea base debe marcar un paso
definido en el progreso desde las especificaciones iniciales hasta la aparicin
del sistema deseado, ya concluido, y an despus, ya que debe servir para la
posterior evolucin del sistema ya en servicio.
De cara a conseguir que cada lnea base d una plataforma slida sobre la
que seguir construyendo, el final de una fase de desarrollo y el principio de la
284 P L A N IF IC A C IO N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
siguiente, viene determinado por la aceptacin de la lnea base. La forma en
que se acepta cada lnea base vara en cada fase del desarrollo, pero los
criterios de aceptacin deben ser los mismos en lodos los casos: la nueva lnea
base debe ajustarse a las restricciones impuestas por las lneas bases previas, y
las siguientes lneas base, con el sistema final que implican, deben ser
alcanzables.
La aceptacin de una lnea base implica que el cdigo o la documentacin
aprobados se pueden congelar para formar una plataforma slida para las
prximas operaciones. Sin embargo, puesto que las actividades humanas no
son nunca perfectas, debe existir la posibilidad de introducir modificaciones en
las especificaciones. Un sistema de gestin de software debe tener en cuenta
esta posibilidad, pero debe tambin asegurarse de que los cambios se hacen con
la misma cantidad de investigacin de las consecuencias, y con el mismo nivel
de autorizacin que tena la aprobacin original de la lnea base.
En la prctica, se establecen una serie de lneas base para permitir un flujo
ordenado del trabajo de desarrollo. Normalmente se establecen cuatro lneas
base en cada proyecto: funcional, de asignacin, de configuracin de desarrollo
y de producto.
La lnea base funcional es la documentacin inicialmente aprobada que
describe las caractersticas funcionales del sistema, y la verificacin requerida
para demostrar el logro de esas caractersticas funcionales. Esta es la lnea base
inicial que se establece en un proyecto y, normalmente, consiste en las
especificaciones del sistema, un documento que define las caractersticas de lo
que todo el software tiene que hacer. El trmino funcional se usa porque esta
lnea base describe las funciones que el sistema, actuando como un todo, tiene
que cumplir. La lnea base funcional es una parte del acuerdo formal entre el
usuario y el desarrollador. Normalmente se establece en el momento de la
adjudicacin del contrato. Partiendo de esta lnea base, en posteriores esfuerzos
de diseo, se divide el sistema en los distintos elementos software que lo
configuran.
La lnea base de asignacin es la documentacin inicialmente aprobada
que describe:
Las caractersticas funcionales y de interfaz de los elementos
designados desde los elementos de configuracin de alto nivel.
Los requerimientos de interfaz de los elementos que se interrelacionan.
Las restricciones de diseo.
C A P T U L O 14 LA G E S T I N D E C O N F IG U R A C IO N E S 285
Las verificaciones requeridas para demostrar el logro de las
caractersticas funcionales y de interfaz que se especificaron.
Esta lnea base consiste en dos tipos distintos de documentos:
Especificaciones de los elementos mismos. Estas especificaciones
describen cada uno de los requerimientos esenciales (funcin, diseo,
restricciones y atributos) de los elementos de configuracin de
software. Una especificacin por cada elemento.
Documentos de requerimientos de interfaz. Son en la prctica las
especificaciones de requerimientos de interfaz, que identifican las
interfaces entre los elementos de configuracin. Recopilando todos los
requerimientos de interfaz en un solo documento se evita la confusin y
la duplicacin de tener esta informacin en cada elemento de
configuracin.
Los elementos individuales que componen una lnea base de asignacin se
establecen normalmente a lo largo de sucesivas revisiones de las
especificaciones de cada uno de los elementos de configuracin. Desde un
punto de vista de gestin de configuracin lo ms importante es que estas
revisiones se hagan de una manera controlada y responsable.
La lnea base de configuracin del desarrollo est formada por el software
que proporcionan los responsables del desarrollo y la documentacin tcnica
asociada, que define el entorno de un elemento bajo desarrollo. Est bajo el
control de configuracin del responsable del desarrollo y describe la configu
racin de software en cada etapa de diseo, codificacin y pruebas. Est
establecida para facilitar el control de las actividades internas de desarrollo.
Normalmente estas lneas bases se establecen de manera incremental. Cada
elemento se incluye en la lnea base cuando es revisado con otros. La razn es
que se hace mucho esfuerzo en las revisiones de elementos, y esto se refleja en
los acuerdos conseguidos con otras partes del equipo de desarrollo. La lnea
base de configuracin de desarrollo se establece normalmente con los
documentos de diseo de alto nivel, en el momento de las revisiones
preliminares de diseo. Los documentos de diseo de detalle se procesan de la
misma manera: y los elementos fuente, objeto y ejecutables se aaden despus
del trmino de sus respectivas fases de pruebas.
La lnea base de producto es la documentacin inicialmente aprobada que
describe las caractersticas funcionales de los elementos de configuracin, las
2 86 PL A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S ______________________________C A P T U L O 14: L A G E S T I N D E C O N F IG U R A C IO N E S ___________________287

caractersticas de interoperabilidad, las caractersticas funcionales Cmo podemos dar soporte para trabajos en cadenas de desarrollo
seleccionadas para sealar las pruebas de aceptacin en produccin. Incluye el paralelo?
cdigo software, un medio de almacenamiento masivo junto con el resto de
elementos (documentacin, herramientas software, etc.) de cara a asegurar que Qu mecanismos se utilizan para avisar a los otros de los cambios
el cdigo puede ser reproducido y mantenido. Esta lnea base se establece que se han realizado?
cuando se completan las pruebas de aceptacin del sistema. Reemplaza el resto
de lneas base, y normalmente se entrega al cliente de una manera formal. Estas cuestiones nos llevan a la definicin de cinco tareas que debe realizar
un sistema de gestin de la configuracin, que estudiaremos en detalle a
continuacin:

14.5 TAREAS DE LA GESTION DE LA CONFIGURACIN. Identificacin de objetos de la configuracin del software

Control de cambios
La Calidad del Software es una disciplina minoritaria, sobre todo en el
Control de versiones
momento en que aparece el cambio. Las demandas de los usuarios se debern
Auditoria de la configuracin
convertir en peticiones de cambio implementadas en el sistema de Informacin,
Informes de estado
pero, en general, un proyecto de software debe gestionar una amplia variedad
de elementos software. Pero a la palabra software se debe dar en algunos casos
un concepto muy abierto. Se puede considerar como elemento software a
Identificacin de objetos de la configuracin del software
cualquier cosa que pueda ser almacenada en un soporte magntico, como
cintas, discos, disquetes, etc. Esta amplia interpretacin es necesaria y
Entre otras funciones la GCS es responsable de la identificacin de los
deseable, y comprende cdigo fuente, objeto, programas ejecutables,
Elementos de Configuracin de Software (ECS) individuales y de las distintas
documentacin, planes y datos de prueba. No slo son importantes los
versiones del software, de las auditorias de la configuracin del software para
elementos que componen un proyecto, sino que lo son an ms las relaciones
asegurar que se desarrollan adecuadamente y de la generacin de informes
entre ellos. Y es precisamente ah donde reside la complejidad de la gestin de
sobre los cambios realizados en la configuracin.
los sistemas de software. Para superar los obstculos de la complejidad
inherente a los sistemas se han ido desarrollando tcnicas que permiten
En su primer proceso, la identificacin de los ECS es una tarea de gestin
superarlos, pero que, a su vez, aaden nuevas complejidades de gestin que
de configuraciones del software que asegura una disposicin de nombres
hay que tener en cuenta.
significativos y consistentes para todos los elementos de configuracin del
software. El trmino disposicin de nombres se refiere a un esquema de
Cmo identifican y gestionan las muchas versiones existentes de
identificacin que proporciona la siguiente informacin:
un programa (y su documentacin) de forma que se puedan
introducir cambios efectivamente?
Tipo de ECS (p. ej., documento, programa, prueba).
Nombre del elemento de configuracin.
Cmo controla la organizacin los cambios antes y despus de que
Identificacin del proyecto o del producto.
el software se distribuya al cliente?
Nmero de versin.
Quin tiene la responsabilidad de aprobar y asignar prioridades a
Esta informacin puede ir codificada y localizada en un nico cdigo de
los cambios?
identificacin de ECS o puede ser referenciada como parte de informacin
separada.
Cmo podemos asegurar que los cambios se han llevado a cabo
adecuadamente?
288 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
La identificacin de configuracin proporciona los medios para aislar los
elementos que constituyen un sistema como base para el control. La funcin
normal demandada es la de establecer un agente bibliotecario encargado de
controlar los movimientos de los archivos, mantenerlos en su lugar
correspondiente y almacenar y organizar documentos importantes desde el
punto de vista de su posible recuperacin en cualquier punto de su ciclo de
vida.
Hay tres aspectos que se deben tener en cuenta: primero, dividir el sistema
en un nmero de partes conocidas y gestionables; segundo, estas partes deben
estar inequvocamente nombradas; y tercero, puesto que las partes cambian a lo
largo del tiempo, las versiones deben identificarse perfectamente. El primer
aspecto est encuadrado en el proceso de especificacin, anlisis y diseo, las
otras dos, requieren la aplicacin de rigurosos estndares.
Es obviamente necesario que un sistema completo tenga una nica
identificacin y, por lo tanto, se pueda distinguir entre las distintas versiones
del sistema que puedan existir. Cada versin puede haber seguido varios pasos
hasta la versin final, o alternativas ajustadas a distintos clientes en distintos
lugares. Puesto que es lgicamente necesario, es imprescindible que stos
tengan identificadores nicos, siendo lo ms comn identificarlos por los
nmeros de versin.
Los diferentes tipos de software tienen diferentes tipos de requerimientos
de identificacin (y control). Por tanto, uno de los pasos en la identificacin
debe incluir la definicin de categoras de software. Una posible categorizacin
del software puede ser la que sigue:
El producto software
Los componentes de un producto firm w are
Software externo
Informacin de gestin
Software de apoyo al producto
El producto software (categora I). El software ha de ser desarrollado
como producto final, o como parte de un producto final. Para algunas
organizaciones es aqu donde el proceso termina. Para otras esto es slo la cima
de un iceberg, y hay que definir ms categoras.
Los componentes de un producto firnnvare (categora II). Este es el
software que se desarrolla para integrarlo en un producto final firmware. Un
punto de vista es tratarlo como si de software normal se tratase. Otro punto de
C A P T U L O 14 LA G E S T I N D E C O N F IG U R A C IO N E S
vista es que puesto que es software diseado para integrarlo en un dispositivo
hardware, debe ser tratado de una manera distinta y separada para evitar
equvocos.
Software externo (categora III). Este es el software que ya existe y que
viene proporcionado y mantenido por un vendedor. Esta categora incluye
sistemas operativos, sistemas gestores de bases de datos relacinales,
herramientas de gestin de configuracin, etc.; esto es, todo el software que se
compra para apoyar el desarrollo de las otras categoras.
Documentos de gestin (categora IV). Este software es el desarrollado
para apoyar la aceptacin formal de las categoras I, II, y III. Incluye
manejadores de pruebas, datos de pruebas, todo el software que rodea la
ejecucin de las pruebas de aceptacin, as como los programas de anlisis
usados por el equipo de pruebas para reducir los datos de pruebas y tener
resultados significativos. En muchos casos no se consideran necesarias las
pruebas sobre la categora III. Esto se debe a que el propio vendedor es el que
se ocupa de las pruebas de aceptacin de sus productos.
Software de apoyo al producto (categora V). Es software que se desarrolla
para apoyar el proceso formal de produccin de las categoras I, II y IV, pero
se identifica formalmente como un producto. Suele incluir herramientas de
comprobacin de estndares, y los ficheros de comandos usados para compilar,
enlazar y cargar el software de las categoras I y II.
La identificacin tambin incluye la tarea de designar las
responsabilidades de la propia identificacin. Normalmente para las categoras
que son objeto de desarrollo esa responsabilidad recae sobre quin, despus,
tiene la responsabilidad del desarrollo y del mantenimiento.
En cuanto a la forma de denominar a cada elemento de la configuracin se
recomienda utilizar nombres que definan algn tipo de codificacin
altoparlante de tal forma que sugiera el tipo de elemento al que se refiere
bien con vinculacin al proyecto, bien con vinculacin al desarrollo, o ambas
incluidas (en este sentido podramos denominar como ASI003 al tercer
documento de Anlisis de Sistemas de Informacin definido en Mtrica v.3).
La identificacin del proyecto y de la versin se puede realizar con la
misma estrategia anterior, por ejemplo anteponiendo el identificador CONTA
al proyecto de contabilidad, y posponiendo el nmero de versin o variante al
final del nombre del elemento separado con un guin (por ejemplo el elemento
290 ____________________ P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
CONTA.ASI2. l:003-v3.2 liara referencia al tercer documento de anlisis de
requisitos del proyecto CONTA en su versin 3.2).
Es importante considerar que los elementos de la configuracin se
encuentran ligados unos a otros bien por los recursos4 que necesitan o por el
nivel de realizacin (por ejemplo un programa objeto depende de su programa
fuente y del compilador que se haya empleado) y que en su totalidad se puede
definir una red de dependencias entre elementos de la configuracin. En este
sentido surgirn interrelaciones entre objetos: habr objetos bsicos y objetos
compuestos o agregados y la identificacin del objeto de configuracin
tambin debe considerar las relaciones entre los objetos implicados: se crea una
jerarqua de ECSs.
Control de cambios
El control de cambios es la tarea ms importante de la gestin de
configuraciones del sistema ya que unos cambios incontrolados pueden llevar
un gran sistema informtico al caos, por lo tanto, se mostrarn al alumno, la
necesaria coordinacin del equipo de desarrollo antes de proceder a efectuar un
cambio en el sistema.
Debemos de tener siempre en cuanta que para que un cambio sea estudiado
se deber solicitar un documento "Formulario de peticin de cambio" en el que
se detalla el cambio solicitado; este documento ser completado por el equipo
responsable para evaluar su alcance, tanto en costo econmico como en
esfuerzo, y se valorar el riesgo que puede producir con otras aplicaciones.
Cuando el cambio haya sido estudiado se efectuar la planificacin para su
incorporacin para lo cual se documentar la fecha prevista de terminacin as
como su implementacin y validacin.
En sistemas grandes es necesaria la coordinacin y supervisin del "grupo
de control de cambios" quien estimar los componentes afectados, la prioridad
de la ejecucin, etc.
Cuando el cambio es totalmente aceptado se convierte en una lnea de base
y se entregar a los desarrolladores como una orden ms de produccin pero
siempre dentro del control de cambios a nivel de proyecto.
4 Los recursos son entidades que proporciona, procesa, referencia o son requeridas por el objeto
(C H O I).
_________________ C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 291
En el entorno de desarrollo de software los elementos tienen
necesariamente que ser cambiados. En un mundo ideal, una vez que un
elemento est completamente aprobado no es necesario cambiarlo. En el
mundo real se necesitan nuevas versiones por muy variadas razones:
Los requerimientos del sistema cambian. El mercado para un producto
cambia o los requerimientos para un sistema ya acordados cambian.
Los lmites entre elementos en la jerarqua de diseo cambian. La
interfaz que se relaciona con un elemento cambia y tiene que ser
renegociada. Esto supone cambios en las especificaciones, y por lo
tanto en la implementacin, y nuevas pruebas.
Las especificaciones de un elemento estn incompletas o se interpretan
errneamente. La codificacin de software a menudo implica tomar
decisiones sobre lo que las especificaciones quieren decir realmente.
Se encuentra un error no detectado durante las revisiones del elemento.
No hay mecanismos de revisin totalmente seguros. Siempre se puede
colar un error a travs del control ms riguroso.
El entorno de software cambia para incluir nuevas caractersticas o para
satisfacer alguna necesidad. Por ejemplo se puede cambiar un
compilador para que sea menos tolerante con las desviaciones sobre las
caractersticas estndar de un lenguaje.
En un gran esfuerzo de desarrollo de software, el cambio incontrolado
lleva rpidamente al caos. El control de cambios, la tarea GCS ms importante,
proporciona un mecanismo para el control de los cambios. El proceso de
control de cambios est ilustrado esquemticamente en la figura 14.5.
292 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Figura 14.5 El proceso de Gestin de Cambios.
Se obtiene una peticin de cam bio y se evala para calcular el esfuerzo
tcnico, los posibles efectos secundarios, el impacto global sobre otras
funciones del sistema y los costes estimados. Los resultados de la evaluacin se
presentan como un informe de cambios a la autoridad de cambios (ACC)5, una
persona o grupo de personas que toman la decisin final sobre la necesidad y
prioridad del cambio. Para cada cambio aprobado se genera una orden de
5 Jones comenta en su libro "Assessment and Control o f Software Risk" que los grupos de
control de cambio, entendidos como la autoridad que los aprueba, son efectivos frente a los
cambios de requerimientos en grandes proyectos.
C A P T U L O 14: L A G E S T I N D E C O N F IG U R A C IO N E S 293
cam bio de ingeniera (OCI). La OC1 describe el cambio a realizar, las res
tricciones que se deben respetar y los criterios de revisin y auditoria.
Puede que este nivel de burocracia se considere excesivo, y sin embargo
esta sensacin no est justificada. Sin la proteccin adecuada, el control de
cambios puede progresar muy lentamente y crear un papeleo innecesario.
Antes de que un ECS se convierta en una lnea base, slo es necesario
aplicar un control de cambios informal. El que haya desarrollado el ECS en
cuestin podr hacer cualquier cambio justificado por el proyecto y por los
requerimientos tcnicos (siempre que los cambios no impacten en otros
requerimientos del sistema ms amplios que queden fuera del mbito de trabajo
del encargado del desarrollo). Una vez que el ECS ha pasado la revisin
tcnica formal y ha sido aprobado, se crea una lnea base.
Una vez que el ECS se convierte en una lnea base, aparece el control de
cam bios a nivel proyecto. Ahora, para hacer un cambio, el encargado del
desarrollo debe recibir la aprobacin del gestor del proyecto (si el cambio es
local) o de la ACC (si el cambio impacta en otros ECS). En algunos casos se
dispensa de generar formalmente las peticiones de cambio, los informes de
cambio y las OCI. Sin embargo hay que evaluar la realizacin de cada cambio
y seguir la pista y revisar todos los cambios.
Cuando se distribuye el producto software a los clientes, se instituye el
control de cambios formal.
La autoridad de control de cambios (ACC) juega un papel activo en el
segundo y tercer nivel de control. Dependiendo del tamao y de las
caractersticas del proyecto de software, la ACC puede estar compuesta por una
-el gestor del proyecto- o varias personas6. El papel de la ACC es el de tener
una visin general, es decir, evaluar el impacto del cambio fuera del ECS en
cuestin.
Para mucha gente un sistema de control de cambios sugiere una increble
cantidad de burocracia que distrae e inhibe a los programadores de su
verdadero trabajo. El control no tiene por qu ser as. Puede ser sensible al
contexto en que se aplica y, a la vez, aplicar el justo grado de restricciones
sobre lo que se puede y no se puede hacer.
6 En la obra de Boddie titulada "Crunch Mode: Building Effective Systems on a Tight Schedule
se comentan casos muy interesantes relacionados con los grupos que ostentan la autoridad del
cambio.
294 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M A T IC O S
Se puede construir otro agente con las funciones de vigilante, encargado
de asegurar que los archivos sean accedidos nicamente por las personas que
tengan una determinada autorizacin.
Es verdad que el control de cambios requiere que se haga algo ms que
codificar: Precisa que se trabaje de una manera responsable y disciplinada que
contribuya a la consecucin de los objetivos del equipo. Un poco de burocracia
es, sin embargo, un precio pequeo para conseguir los beneficios que el control
de cambios asegura:
Hay un procedimiento bien definido para la peticin de un cambio y la
realizacin de dicho cambio si finalmente se aprueba.
La realizacin de un cambio aprobado se puede planificar teniendo en
cuenta su importancia, su impacto y los recursos que necesita.
En principio, el cambio de un elemento no tiene efectos secundarios
adversos inesperados.
El estado de aprobacin de una peticin de cambio, y del elemento al
que se refiere, queda siempre documentado.
En la figura 14.6 se describe de manera muy sencilla el ciclo de vida de
una versin de un elemento software.
D esarrollo Revisin
Figura 14.6 Ciclo de vida de una versin de un elemento.
Mientras el estado de un elemento software es en desarrollo se puede
cambiar libremente. Cuando se da por terminado el trabajo pasa a revisin, y el
elemento inmediatamente queda congelado. A partir de ese momento nadie
puede cambiar ese elemento congelado excepto a travs del control de cambios
con una nueva versin. Cuando el elemento est bajo revisin es
responsabilidad de la autoridad de revisin aprobarlo a rechazarlo si no se
ajusta al propsito inicial.
El estado de un elemento derivado es el mismo que el del elemento fuente
desde el que est construido. Si un elemento derivado se construye a partir de
varios elementos fuente su estado es el del elemento de menor aprobacin de
C A P T U L O 14: L A G E S T I N D E C O N F IG U R A C IO N E S 295
sus fuentes. Por un principio similar el estado de un elemento compuesto es el
del elemento componente de menor aprobacin. No tiene sentido poner bajo
revisin un elemento que no est congelado. De la misma manera, no tiene
sentido aprobar una configuracin que contiene elementos que no han sido
aprobados.
Control de versiones
Otro paradigma de la gestin de configuraciones consiste en la necesidad
de mantener dos o ms versiones de una aplicacin por necesidades de la
organizacin. El problema de la precisin para mantener los cambios en ambas
versiones origina la necesidad de un control de versiones.
El trmino versin se debe de explicar como una instancia de un sistema
que difiere de otra instancia en una serie de cualidades. Sera normal considerar
que no tiene sentido mantener dos versiones simultneas por lo que vamos a
ilustrar algn ejemplo en el que se evidencia la necesidad de mantener ambas
versiones: Existe una versin de Microsoft Word 6.0 en Windows y otra en
DOS, lo mismo ocurre con FoxBase, que adems tiene versiones en Unix y
para Mac, y con muchos otros productos existentes en el mercado. Su
fabricante considera importante mantener en el mercado, de forma simultnea,
todas las versiones del producto y necesita controlar los cambios, ya que
alguna de las rutinas internas del producto sern comunes y otras no.
Una de las funciones del planificador, junto con la alta direccin, es
decidir cuando sale cada una de las versiones del producto a fin de que el
A probado
esfuerzo est racionalmente equilibrado. Por otra parte pueden convivir varias
versiones, sobre la misma plataforma, operativas por razones de exigencias
tcnicas o por el propio mercado (hoy da se mantiene de forma simultnea el
dBASE III Plus de MSDOS, el dBASE IV 2.0, en MSDOS y UNIX, y el
dBASE versin 5 tanto para MS-DOS como para Windows) lo que obliga al
director del proyecto a mantener un rbol de versiones y de configuraciones
que obliga a controlar.
Durante el desarrollo de un elemento software es necesario, a veces,
despus de considerar un elemento completamente terminado o pendiente de
ciertas revisiones (se dice entonces que dicho elemento est congelado, y por
lo tanto ya no puede ser modificado) corregir errores, aadir nueva
funcionalidad, adaptarlo a nuevos entornos, etc. Cada una de estas revisiones
puede producir una nueva versin del elemento que sustituye a la anterior. Sin
embargo, los elementos que han quedado obsoletos deben ser conservados
296 PLANIFICACIN Y GESTIN DE SISTEMAS INFORMTICOS CAPTULO M LA GESTIN DE CONFIGURACIONES 297

porque hay configuraciones en servicio que hacen uso de ellos. Si en una de
estas versiones obsoletas de un sistema que an est en servicio ocurre un error
no detectado hasta el momento, hay que ser capaz de reconstruir el error, sin
necesidad de desplazarse hasta el domicilio del cliente que lo detect, para
investigar el error y descubrir las implicaciones sobre otros elementos del
sistema y sobre las versiones posteriores del elemento y del sistema. Tambin
puede ocurrir que una nueva versin resulte no ser mejor, a pesar de todo, que
la versin a la que sustituye porque no se ajusta estrictamente a las necesidades
del usuario o porque contiene ms errores.
variaciones para varios sistemas operativos. Los diferentes sistemas
operativos proporcionan los mismos servicios de distinta manera.
Variacin para pruebas y depuracin. A menudo se hacen variaciones
para satisfacer las necesidades particulares de los programadores que
desarrollan o mantienen un mdulo. Una variacin de un mdulo puede
incluir volcados de datos y rastreos (traces ), que ayudan a la
depuracin, pero que no se incluyen en lo que efectivamente se manda
al cliente.

Versiones congeladas versin de traba o Variacin de los requerimientos del usuario. Hay muchos programas
que son utilizados por muchos y muy distintos clientes. Si un sistema
de nminas se ha de utilizar en pases distintos, entonces debe
comunicarse con los usuarios en los distintos idiomas nacionales. El
sistema debe ser capaz tambin de tener en cuenta las distintas
Figura 14.7 Sucesivas versiones de un mismo elemento. legislaciones laborales y fiscales de cada pas (ejemplo en la figura
14.8).
Habitualmente la secuencia de revisiones se referencia con un nombre del
elemento seguido de un nmero incremental que refleja el orden en que han
sido creadas.

As pues, suele existir para cada elemento una secuencia de revisiones que
se suceden a lo largo del tiempo, para las que es imprescindible saber el orden
de precedencia cronolgica que guardan y tambin las modificaciones que
introduce cada una de ellas, para poder seguir su evolucin.

Las variaciones de un elemento cumplen la misma funcin que el original,

para situaciones ligeramente distintas y son, por lo tanto, partes alternativas e Las variantes de un elemento pueden ser temporales o permanentes. Las
intercambiables. Una configuracin de un sistema incluye tpicamente una ms usuales son estas ltimas. Una variante temporal es aquella que desde su
nica variacin de un elemento dado. AI contrario que las revisiones, las nacimiento est destinada a fundirse con otra variante. La Figura 14.9 muestra
nuevas variaciones no sustituyen a las viejas. Habitualmente las variaciones no un caso tpico:
se numeran como ocurre con las revisiones, sino que se nombran, ya que no
tiene sentido un orden lineal entre ellas. El nombre de las variaciones suele
reflejar su propsito, no el orden en el que fueron creadas.

Se pueden considerar tres clases de motivos distintos para crear

variaciones:

Variacin deI entorno. Se debe iinplementar el sistema de manera que

use los recursos proporcionados por las plataformas en las que se
ejecuta. Las variaciones de plataforma se deben ajustar a variaciones Figura 14.9 Secuencia de revisiones con variantes temporales.
del sistema. Para maximizar su mercado un sistema debe tener
29S P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 299

Los elementos 1, 2, 3, 4, 5 y 6 son versiones en el sentido ya mostrado

anteriormente. Cuando la versin 3 del elemento estaba en desarrollo, se
V e rs i n 2
descubri un fallo en la versin 2, que estaba en uso en un cliente. La solucin
al problema se necesita urgentemente y no puede esperar hasta que la versin 3
sea aprobada. Para solucionar el problema se crea una variante que se D
3
suministra inmediatamente al cliente. Hay ahora dos versiones del elemento: la
B
versin variante. 1, que contiene el arreglo urgente a la versin 2, y la versin 3,
4
que contiene las mejoras planificadas de la versin 2 , pero no el arreglo E
urgente. Una vez aprobados los cambios que se hagan en la versin 3, han de
hacerse tambin en variante. 1, con lo que se crean la versin 4 y variante.2. A V /
medida que pasa el tiempo las dos variantes van divergiendo cada vez ms, con
lo que se hace cada vez ms difcil la tarea de fundirlas finalmente. Esta Figura 14.10 Configuraciones con elem entos coincidentes.
situacin incmoda y peligrosa, se soluciona fundiendo las dos variantes en un
slo elemento: la versin 5. Tambin en los elementos compuestos es necesario hacer revisiones. Hay
sin embargo significativas diferencias en cmo se gestionan, ya que las
Situaciones como esta son bastante frecuentes. Durante el desarrollo de versiones de elementos compuestos se definen por las versiones de cada uno de
software, si dos ingenieros necesitan revisar el mismo elemento al mismo sus componentes. La Figura 14.11 muestra como la documentacin de usuario
tiempo, cada uno crea una variante temporal; estas dos variantes son al final contiene cinco elementos; un manual tcnico, una gua de usuario, un manual
fundidas en una sola. Se pueden usar variantes para explorar caminos de referencia, un manual de instalacin y unas recomendaciones de ajuste
alternativos de diseo o de implementacin, en este caso, fundir las variantes (tunning) del sistema.
equivale a aceptar la elegida y descartar las otras. Cuanto ms tiempo existan
variantes temporales, ms divergirn de la lnea principal, y ms difcil ser
fundirlas finalmente. Las variantes temporales deben evitarse en la medida de
lo posible, y cuando no se puedan evitar, deben fundirse lo ms rpidamente
posible.

La diferencia entre un elemento y una configuracin no es que las

configuraciones son elementos compuestos de otros elementos. Su contenido
en una aproximacin muy intuitiva, es precisamente la lista de sus Figura 14.11 Partes de la documentacin de usuario.
componentes. Las configuraciones pueden hacer referencia a todo un sistema o
a un pequeo grupo de elementos con una funcionalidad total concreta, y que Cada uno de estos elementos existe como un conj unto de versiones que se
no llega a la categora de subsistema. relacionan entre s para formar a su vez las distintas versiones de la
documentacin de usuario. La siguiente Figura (14.12) muestra las relaciones
En el caso ms general, se incluyen en una configuracin todo tipo de entre todos los elementos.
elementos; desde documentacin hasta mdulos ejecutables y estructuras de
datos. Estos elementos son seleccionados a travs de toda la organizacin para
satisfacer un objetivo concreto y diferente del de las otras configuraciones. El
objetivo distinto a satisfacer puede ser incluir una nueva funcionalidad que
aporta un mdulo en concreto, en cuyo caso no diferir apenas de alguna otra
configuracin, o adaptarse a un nuevo sistema operativo (ejemplo en la figura
14.10).
300 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
1 .
3 5
Hp Qp
Figura 14.12 Versiones de la documentacin de usuario.
La versin 2 de la documentacin de usuario comprende la versin 2 de la
gua, la versin 6 del manual de referencia y la versin 3 del manual de
instalacin. Despus de la versin 3, se necesitan variantes de la
documentacin para UNIX y para VMS, que en realidad slo afectan al manual
de instalacin.
Hay que hacer notar que una nueva versin de un elemento compuesto no
significa necesariamente nuevas versiones de todos sus componentes. Este es el
caso de la versin 2 de la documentacin de usuario, que contiene dos
elementos que no han sido modificados desde la versin anterior, la versin 2
de la gua y la versin 3 del manual de instalacin. Tampoco una nueva versin
de un elemento es necesariamente incluida en una nueva versin del elemento
compuesto, como es el caso de la versin 3 de la gua y la versin 4 del manual
de instalacin, que no han sido nunca incluidos en ninguna versin de la
documentacin.
Una distincin importante entre los elementos es si unos han sido
derivados de otros mediante una herramienta o si son construidos
manualmente. Un elemento que se construye por un proceso automtico desde
otro elemento se llama elemento derivado. El que se construye manualmente
sin partir de otro se llama fuente. Ejemplos de elementos derivados son los
mdulos objeto, que se derivan del cdigo fuente usando un compilador, y los
C A P T U L O U : L A G E S T I N D E C O N F IG U R A C IO N E S 301
programas ejecutables, que se derivan desde objetos usando un "linkador". En
i la Figura 14.13 se muestran ocho elementos de los cuales slo los de la lnea
3 inferior son fuentes.
Figura 14.13 Elementos derivados y fuentes.
Existen herramientas en el mercado para el control de configuraciones
cuando existe software que depende de una versiones s y de otras no, este
software en forma de herramienta est pensado para los desarrolladores y
asegura la consistencia con el cdigo comn en todas las versiones del
producto, es decir, asegura la fase de considerar el software que es diferente en
cada versin y la fase de construccin de dichas versiones.
Los sistemas ms populares para controlar estas situaciones son el SCCS
(Source Code Control System) debido a Rochkind en 1975 en su primera
versin y desarrollado originalmente para IBM-370 aunque en la actualidad se
puede encontrar en cualquier UNIX. Otra herramienta popular es el MAKE
debido a Feldman en 1979 que permite el mantenimiento de versiones en modo
arbolescente.
Dentro de los avances del control de versiones se han creado lenguajes de
interrelacin de mdulos (LIMs) que permiten construir automticamente
cualquier versin del sistema siempre y cuando se hayan definido las
relaciones pertinentes, tales como:
Dependencia: Cualquier otro tipo de relaciones entre ECS,
fundamentalmente en la documentacin y requisitos.
Derivacin: A partir de qu ECS se ha originado otro elemento.
302 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S ______________________________C A P T U L O 1-1 LA G E S T I N DE C O N F IG U R A C IO N E S _______ ________ 303_

Equivalencia: Cuando un determinado ECS est almacenado en lugares
diferentes, pero todas las copias corresponden al mismo elemento.
Composicin: Cuando un ECS est compuesto de otros ECS.
Variante: Modificaciones sobre un determinado ECS que no cambian
su funcionalidad.
consistencia con otros ECS, las omisiones o los posibles efectos secundarios.
Se debe llevar a cabo una revisin tcnica formal para cualquier cambio que no
sea trivial.
Una auditoria de configuracin del software complementa la revisin
tcnica formal al comprobar caractersticas que no tiene en cuenta la revisin.
La auditoria se plantea las siguientes cuestiones:

Sucesin: En la historia de cambios sobre un ECS desde una revisin a Se ha hecho el cambio especificado en la OCI? Se han
otra. incorporado modificaciones adicionales?

Igualmente se pueden crear grafos de evolucin (Gustavsson en 1989) para Se ha llevado a cabo una revisin tcnica formal para
cualquier objeto. Puede ser muy til definir un grafo de evolucin para cada comprobar la correccin tcnica?
ECS. Este grafo describe la historia de cambios de un objeto y su transicin de
unas versiones a otras (ver figura 14.14). Se han seguido adecuadamente los estndares de ingeniera del
software?
Objeto 2.0 Objeto 2.1

Objeto 1.0 Objeto 1.1

/ Se han remarcado los cambios en el ECS? Se han especificado
la fecha del cambio y el autor del cambio? Refleja la
\, Objeto 3.0 identificacin del ECS los cambios?

F igura 14.14 G rafo d e evolucin de ECS. Se han seguido procedimientos de GCS para sealar el cambio,
registrarlo y divulgarlo?

Existen herramientas informticas para ayudar en la tarea de Se han actualizado adecuadamente todos los ECS
identificacin. En algunos casos se disea una herramienta para mantener las relacionados?
copias mas recientes y en otras herramientas se restan versiones para llegar a
la versin deseada. En algunos casos, las cuestiones de auditoria se incluyen en la revisin
tcnica formal. Sin embargo, cuando la GCS es una actividad formal, la
auditoria de la GCS se lleva a cabo independientemente del grupo de garanta
Auditoria de la configuracin de calidad.

La identificacin y el control de cambios ayudan al equipo de desarrollo de Hay tres tipos distintos de auditorias que se pueden hacer:
software a mantener un orden sobre los cambios, que de otro modo llevaran a
una situacin catica y sin salida. Sin embargo, incluso el mecanismo ms Auditoria funcional de configuracin. El propsito de una auditoria de
conecto de control de cambios vigila, rastrea e informa los cambios hasta que este tipo es validar que el desarrollo de un elemento de configuracin se
se ha generado la OCI. Cmo podemos asegurar que los cambios se han ha completado satisfactoriamente, y que el elemento a conseguido las
realizado correctamente? La respuesta es doble: 1) revisiones tcnicas caractersticas funcionales y de rendimiento especificadas.
formales, y 2 ) auditorias de configuracin del software. Normalmente se hacen despus del ciclo de desarrollo, una vez
completadas las pruebas de los elementos desarrollados.
Las revisiones tcnicas formales se centran en la correccin tcnica del
ECS que ha sido modificado. Los revisores evalan el ECS para determinar la
304 P L A N IF IC A C I N Y G E S T I N DF. S IS T K M A S IN F O R M A T IC O S
Auditoria fsica de configuracin. La auditoria fsica de configuracin
es un examen tcnico del elemento de configuracin designado para
verificar que el elemento de configuracin ha sido construido conforme
a la documentacin que lo define.
Auditoria de proceso. Estas auditorias son para determinar que el
proceso de gestin de configuracin establecido en una organizacin se
sigue fielmente y averiguar que nuevas necesidades se tienen que
satisfacer.
Informes de estado
La generacin de informes de estado de la configuracin (a veces
denominada contabilidad de estado) es una tarea de GCS que responde a las
siguientes preguntas:
Qu pas?
Quin lo hizo?
Cundo pas?
Qu ms se vio afectado?
Puede entenderse como un agente historiador encargado de registrar
todas las actividades que se hayan realizado en los distintos archivos.
En la figura 14.15 se ilustra el flujo de informacin del proceso de
generacin de informes de estado de configuracin (GIEC).
Figura 14.15 Proceso de generacin de informes
C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 305
Cada vez que se asigna una nueva identificacin a un ECS (o una
identificacin actualizada) se genera una nueva entrada a la GIEC. Cada vez
que la ACC aprueba un cambio (cuando se expide una OCI) se genera una
entrada a la GIEC. Cada vez que se lleva a cabo una auditoria de
configuracin, los resultados aparecen como parte de una tarea de GIEC. La
salida de la GIEC se puede situar en una base de datos interactiva, de forma
que los encargados del desarrollo y del mantenimiento del software puedan
acceder a la informacin de cambios por categoras clave. Adems, se genera
un informe regularmente con la intencin de mantener a los gestores y a los
profesionales al tanto de los cambios importantes.
La generacin de informes de estado de la configuracin juega un papel
vital en el desarrollo de software. Cuando aparece involucrada mucha gente es
muy fcil que se d el sndrome monacal de que la mano izquierda no sepa lo
que hace la mano derecha. Puede que dos programadores intenten modificar el
mismo ECS con intenciones distintas y conllictivas. Un equipo de desarrollo
puede gastar meses de esfuerzo construyendo un software a partir de unas
especificaciones obsoletas. Puede que la persona que descubra los serios
efectos secundarios de un cambio propuesto no est enterada de que el cambio
se est realizando. La GIEC ayuda a eliminar esos problemas mejorando la
comunicacin entre todas las personas involucradas.
Tendramos que entender que una de las funciones ms importantes que
debe proporcionar el Sistema de Gestin de Configuraciones es mantener
seguros todos los documentos de origen, de tal forma que debe de ser como
mantener un registro de todos los documentos de una biblioteca sobre los que
se provean las siguientes facilidades:
Impedir la eliminacin accidental de la informacin.
Organizar todos los documentos segn una cierta jerarqua.
Proteger y desproteger archivos.
Permitir que varios usuarios puedan compartir la misma informacin.
Desarrollar aplicaciones distribuidas en sistemas operativos
heterogneos.
Trabajar con cdigo, tanto modular como orientado a objetos.
306 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
14.6 M D U L O S E IN TE R FA C ES.
Una vez conocidos los problemas que plantea el mantenimiento del software y
a la luz de la normativa y prcticas de uso existentes en la comunidad cientfica
y profesional, pasamos a analizar algunas de las tcnicas ms dominantes.
De la lectura de la bibliografa, por ejemplo Software Configuraron
Management de Berlack, y de la intuicin de la experiencia, se deduce que un
equipo de desarrollo trabaja mejor cuando todos los miembros tienen un
conocimiento suficientemente amplio del trabajo de los otros. Desa
fortunadamente, la intuicin no es a veces la mejor gua. De hecho, para
muchos aspectos del desarrollo de software el mnimo conocimiento lleva al
mximo progreso.
Supongamos que un programa de gestin de almacn tiene que hacer muy
frecuentes accesos a una base de datos que contiene la informacin que
necesita. La base de datos tiene unas funciones especiales de acceso
desarrolladas por una persona distinta a la que desarroll el primer programa.
Puesto que una parte importante del tiempo de proceso se usa en las funciones
de acceso a la base de datos, se acuerda no utilizar las rutinas de acceso y
acceder directamente a los campos que necesita en la base de datos, para lo que
el programador de las rutinas proporciona toda la informacin referente a la
base de datos al programador del programa de gestin de almacn. Cada vez
que hay un cambio en la estructura de la base, no solo hay que cambiar las
rutinas de acceso, sino que tambin hay que cambiar el programa de gestin de
almacn. Esta situacin puede ser mantenible si slo ocurre en unos pocos
casos y estn bien coordinados. En el momento en que empieza a ocurrir con
frecuencia se hace inevitable que en algn cambio de la estructura de la base de
datos, alguien no se entere, o que se le olvide cambiar su programa.
Inevitablemente ocurren errores. Para Choi y Scacchi este es el tpico problema
de doble mantenimiento.
El conocimiento de la estructura de la base de datos est presente en ms
de un sitio (las rutinas de acceso propias, y cada uno de los programas que
acceden directamente). Cuando uno se cambia, han de cambiarse todos. La
divergencia, y por tanto el error, es inevitable7. El problema es que los
programas de gestin saben demasiado de la estructura de la base de datos.
Deberan llamar a las funciones propias de la base de datos, y no acceder
directamente. El conocimiento de la estructura de la base de datos debera estar
en un solo sitio, las rutinas de acceso que le son propias.
7 Este tipo de problemas los examina Paul Carroll en su artculo "Creating new software iras
agonizing ta sk fo r m itch kaporfirm", publicado en The Wall Street Journal (11/5/1990).
C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 307
Sobre un caso ms general, no siempre es tan fcil, ni conviene, separar
funciones tan claramente como en el caso anterior. Entonces se construyen
mdulos que constan de dos partes diferenciadas:
La interfaz, que es la parte del elemento que es visible a los otros
elementos. Especifica precisamente las caractersticas del elemento que
los otros elementos necesitan conocer. Est escrupulosamente prohibido
describir en esta parte aspectos que no conciernen a los otros elementos.
El cuerpo del elemento, que no es visible a los otros. Todas las
decisiones sobre como conseguir el propsito del elemento, estn
ocultas al resto en esta parte. El cuerpo de un elemento se puede
cambiar libremente siempre y cuando se mantenga consistente con su
interfaz.
Dividir un elemento en interfaz y cuerpo permite restringir todas las
dependencias de un elemento a las dependencias de su interfaz. Es la interfaz la
que hace las llamadas a otros mdulos, y es nicamente ah, donde se crean las
dependencias (ejemplo en figura 14.16).
O tros in terfa ce s y cuerp os Interfaz
Otros in te rfa c e s
cuerpo
Figura 14.16 Dependencias entre mdulos divididos en cuerpo e interfaz.
Como ya se vio, la interfaz puede ser un archivo distinto o integrarse en el
mismo que el cuerpo del elemento. La decisin depender del tamao y la
complejidad de la interfaz. La interfaz de un gran subsistema est normalmente
separada del proceso porque es una parte muy importante y merece la pena
gestionarla por separado. No cambia tan a menudo como el elemento que
forma el cuerpo del subsistema, pero cuando lo hace afecta a otros subsistemas.
Por otro lado, la interfaz de un procedimiento que ordena una matriz de enteros
es muy pequea; probablemente es mejor incluirlo en el mismo archivo del
cuerpo que mantener los dos archivos distintos relacionados entre s.
Las interfaces se definen en la fase de diseo de manera que se puedan
intercambiar las versiones de un elemento. El diseo comienza con todo el
proyecto visto como una sola entidad. Sus interfaces lo son con el mundo
exterior y se les llama requerimientos funcionales. Los requerimientos
funcionales definen lo que el software debe hacer.
30 8 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IM F O R M A T IC O S
El primer trabajo de los diseadores es descomponer el total en un grupo
de mdulos y disear las interfaces entre mdulos. Cada mdulo se disea
entonces rompindolo en submdulos. El proceso contina recursivamente
hasta que los submdulos son tan pequeos que su implementation es obvia,
para lo cual se pueden seguir las indicaciones de Pamas y Wirth sobre las
tcnicas de refinamiento que aumentan la independencia modular; en ese
momento el diseo est completo.
En cada iteracin, el diseador se enfrenta a la tarea de decidir de qu
forma cada mdulo va a hacer su trabajo. El diseador lo consigue
especificando los submdulos componentes: Qu son?, Qu propsito
persiguen?, Cmo interaccionan para conseguir el objetivo de todo el
mdulo?. Una vez identificados los submdulos, el diseador prosigue con la
siguiente iteracin.
El diseo de un mdulo se puede expresar con un dibujo como el de la
figura 14.17. El diseo empieza con una caja que representa el mdulo, lneas
salientes que representan las interfaces que debe encontrar. La caja est vaca
mostrando que la impleinentacin no est diseada.
Mdulo
Figura 14.17 Mdulo sin su estructura diseada.
El diseo de la implementacin se expresa entonces (figura 14.18) con
cajas ms pequeas que representan submdulos. Las lneas que los unen
representan las dependencias entre submdulos.
Figura 14.18 Mdulo con su estructura diseada.
C A P T U L O 14: L A G E S T I N DE C O N F IG U R A C IO N E S 30 9
Como el proceso de diseo es recursivo, los submdulos se disean de
manera similar, comenzando con sus interfaces y desarrollando su
implementacin.
Un gran proyecto de desarrollo de software tiene que mantener una
jerarqua de interfaces que refleja la descomposicin del software. El nivel ms
alto es la interfaz de requerimientos funcionales, que refleja lo que el producto
software completo debe hacer. Los siguientes niveles son interfaces entre
mdulos, seguido de los interfaces entre submdulos, y as hasta el final.
La descomposicin de software en mdulos y submdulos se refleja
frecuentemente en la organizacin del proyecto en equipos y subequipos. El
nivel de descomposicin es suficiente cuando el mdulo ms pequeo es
enteramente responsabilidad de una sola persona, que es responsable de
muchos submdulos.
Las interfaces entre mdulos se pueden dividir en dos tipos bsicos:
interfaces de llamada e interfaces de datos:
Una interfaz de llamada permite a un mdulo invocar a una rutina en
otro mdulo. Existe entre el mdulo que define la subrutina (el
llamado) y el mdulo que contiene la llamada a la subrutina (el
llamador) una relacin de dependencia. El llamado proporciona un
servicio al llamador, por ejemplo un clculo, un salvado o retorno de
datos.
Una interfaz de datos describe datos que son accedidos por ms de un
mdulo. Si slo un mdulo referencia los datos, entonces la definicin
es parte de la implementacin del mdulo. Una interfaz de datos
describe datos compartidos, variables globales estructuras de datos,
ficheros en disco o cinta, as como entradas y salida extemas.
Se incluye en la interfaz de datos el nombre, tipo y significado de los
datos. Tambin se incluye el momento y las circunstancias bajo las que se
cambian los datos, incluyendo la inicializacin.
La distincin entre interfaces de datos y de llamada es frecuentemente
artificial. En las modernas tcnicas de programacin, la estructuras de datos
estn adecuadamente aisladas en mdulos cuya funcin es proporcionar acceso
a los datos a otros mdulos. La organizacin fsica de una base de datos est
oculta en el cuerpo de un mdulo que presta servicios de acceso al resto a
travs de su interfaz.
310 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 14: LA G E S T I N D ti C O N F IG U R A C IO N E S 311

probabilidad de error. As las cosas, cuantos menos mdulos involucrados en

El propsito de las interfaces es mostrar cmo los mdulos, construidos
por programadores individuales, trabajan todos juntos para formar un producto
software completo. El control de las interfaces es la clave para conseguir
comunicacin satisfactoria entre todos los programadores, y por tanto, entre
todos los mdulos que son su responsabilidad. Una parte muy importante del
trabajo de los gestores de un producto software es asegurar una jerarqua de
interfaces bien estructurada, estable y continuada. Tanto es as que se puede
considerar la definicin de una interfaz como la redaccin de un contrato, que
como tal debe ser preciso, completo, acordado, visible y cambiado bajo es
trictos controles.
Una interfaz debe ser explcitamente acordada por todo aquel que tenga un
inters legtimo en ella, incluyendo tanto a los responsables de desarrollar y
mantener el cuerpo del mdulo, como a los usuarios de la interfaz. Una vez
acordada, la interfaz debe ser guardada de forma segura y visible. Como todo
el software, las interfaces deben cambiarse algunas veces. Cuando esto ocurre,
los cambios deben negociarse y acordarse por todos los que dependen en
alguna medida de la interfaz, incluyendo a los responsables de la versin de la
interfaz que va a ser reemplazada. La transicin a una nueva versin de una
interfaz debe gestionarse muy cuidadosamente para asegurarse de que las
diferentes partes del sistema no estn usando una versin incompatible.
Las violaciones de las relaciones entre interfaces son la principal causa de
gasto de tiempo y esfuerzo en la fase de pruebas e integracin. Se gasta ms
tiempo y dinero arreglando este tipo de violaciones que desarrollando nuevo
software.
un cambio mejor. Es por esta razn que los mdulos se disean muy pequeos.
Es mucho mejor tener una multitud de pequeos acuerdos (interfaces) en
distintos y aislados asuntos que tener inuy pocas interfaces que cubren todo. En
casos extremos, tener pocas interfaces puede llegar a ser inaceptable por
ineficaz.
Por ejemplo, en la figura 14.19 hay una sola interfaz que gestiona todas las
relaciones entre el mdulo 1 y el mdulo 2. Hay slo dos responsables de las
interfaces; el interfaz lo usan varios submdulos en cada mdulo. Si se
encuentra un error en este interfaz, o por alguna razn hay que modificarlo,
entonces pueden verse afectados los submdulos A, B y D en el mdulo 1 y los
submdulos E y G en el mdulo 2.
- E
M d u lo 1 M dulo 2
Figura 14.19 Dos mdulos conectados por una sola interfaz.
Si la interfaz se rompe en tres relaciones independientes ms pequeas,
entonces un cambio en cada interfaz supone un slo submdulo en cada
mdulo que puede verse afectado (figura 14.20).

Para minimizar las violaciones, cada miembro del equipo tiene la

responsabilidad de proteger las interfaces de las actividades que puedan poner
en peligro su compatibilidad. Pero a pesar de todas las precauciones,
inevitablemente se producen errores. Entonces, una vez detectados, hay que
poner en contacto a todos los implicados en esa interfaz para decidir si ese
Mdulo 1 M d ulo 2
error se debe a la mala interpretacin del acuerdo tomado en la definicin, o si
por el contrario se trata de una ambigedad en la declaracin. Si es el ltimo
caso, se ha de llegar nuevamente a un acuerdo aceptado por todas las partes Figura 14.20 Dos mdulos conectados por tres interfaces independientes.
implicadas, y cambiar la interfaz.

Cada vez que una interfaz cambia, todos los mdulos dependientes deben
ser revisados para asegurar que son compatibles con el cambio. Cuantos ms 14.7 E L E M E N T O S D E D ISEO.
mdulos implicados, ms personas implicadas, y por tanto mayor es la
312 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 14: LA G E S T I N DE C O N F IG U R A C IO N E S 313

Algunas veces es til considerar el sistema entero como una unidad, por
ejemplo cuando se va a enviar al cliente. Otras veces es apropiado considerar
un simple procedimiento como una unidad, por ejemplo cuando un
programador tiene que reformar un procedimiento independientemente del
resto del sistema. Los elementos forman una jerarqua en la que un elemento
compuesto consiste simplemente en unas listas de elementos componentes. En
alguno de estos casos ese considera que es una configuracin de un sistema o
de un subsistema.
muchos elementos distintos. Para poder planear y gestionar un proyecto
se debe partir en paquetes de trabajo cada vez ms pequeos de manera
que la estructura de la jerarqua del sistema y la del equipo de trabajo
vaya paralela.
En la figura 14.21 se muestra parte de una jerarqua de elementos de un
sistema de gestin de base de datos (SGBD).

El principio gua es estructurar el soware de manera que sea fcil de

cambiar. En un sistema pobremente estructurado, hacer un pequeo cambio
funcional requiere correcciones en muchos y muy variadas partes del sistema.
Por tanto, el mantenimiento de un sistema as estructurado, se hace lento y
trabajoso, con posibilidad de introducir muchos nuevos errores. Por el
contrario, un cambio en un sistema bien estructurado requiere correcciones a
slo unos pocos elementos, que estn relacionados con los otros de manera
adecuada.

Es imposible desarrollar y mantener el sistema software ms sencillo sin

dividirlo en elementos ms simples y manejables. La descomposicin de
elementos satisface cuatro objetivos:

Gestin de a complejidad. Partir un sistema complejo en componentes

ms pequeos y simples permite comprender y manejar cada uno de
estos componentes mejor que el sistema completo.
Producir un sistema mantenible. Una vez que un elemento software se
ha desarrollado inevitablemente hay que cambiarlo: correccin de
errores, cambios para adaptarse a modificaciones en el entorno, nuevos
requerimientos del usuario. La jerarqua de elementos debe estar
estructurada de manera que los cambios funcionales del sistema
impliquen cambios en una sola parte de la jerarqua. Si cambios
pequeos implican modificaciones en elementos diversos y distribuidos
de la jerarqua, entonces el sistema ser muy difcil de mantener.
ReutiHzar elementos. Siempre que sea posible los elementos se
construyen en bloques para que otras partes del sistema hagan uso de
esos bloques y as ahorrar esfuerzo.
Dividir el trabajo. Cerca de la cspide de la jerarqua los elementos son
responsabilidad de grandes equipos. En la base de la jerarqua los
elementos son responsabilidad de personas individuales, que lo son de
Figura 4.21 Estructura de un sistema de gestin de base de datos.
Los elementos de nivel ms bajo en la jerarqua son elementos del sistema
software. Los elementos compuestos como la documentacin de usuario y los
mtodos de acceso a ficheros no son ms que la suma de sus componentes.
Cada elemento aparece una sola vez en la jerarqua. Esto no significa que
un elemento en una parte de la jerarqua no pueda hacer uso de un elemento en
otra parte de la jerarqua. Los elementos en el sistema de consultas de la Figura
14.21, usan elementos del sistema de acceso a ficheros. Sin embargo esta
relacin entre elementos es bastante diferente de la relacin parle d e que
define la jerarqua. No hay que confundirla con la estructura de mdulos que
describe cmo los mdulos de un sistema llaman a otros mdulos.
No todos los elementos se ajustan a una jerarqua estricta. Muchas
configuraciones cortan a travs de la jerarqua de elementos seleccionando o
rechazando elementos de cara a lograr un determinado propsito. Por ejemplo,
el sistema de gestin de base de datos de la Figura 14.21 puede configurarse
314 P L A N IF IC A C I N Y G E S T I N D E S IS T IiM A S IN F O R M T IC O S
para incluir elementos que son apropiados para trabajar en Unix o en cualquier
otro sistema operativo.
Los elementos que son parte estrictamente de la jerarqua se llaman
elementos de diseo. Un elemento de configuracin no es en general un
elemento de diseo.
Debe existir un limite de cunto se ha de descomponer un sistema. En
lneas generales, un software que puede ser til modificarlo
independientemente del resto, debe ser considerado como un elemento. Si no
hay suficiente descomposicin, puede ocurrir, que para un pequeo cambio se
tenga que hacer una nueva versin de un elemento muy grande, o que no sea
posible seleccionar diferentes combinaciones de elementos para construir
diferentes configuraciones. Sin embargo, si el sistema est descompuesto en
elementos demasiado pequeos se hace innecesariamente complicada la
gestin. Hay pues que llegar a un compromiso en el grado de descomposicin
del sistema.
A la hora de hacer un cambio, es necesario evaluar el impacto que tendr
la implementacin de dicho cambio antes de acometer su diseo. Hay que
identificar y gestionar las mltiples versiones que un cambio genera. Los
cambios son difciles de gestionar porque los elementos dependen unos de
otros. Un cambio aparentemente menor a un elemento se puede propagar a los
elementos que dependen de l directa o indirectamente, de manera que al final,
hay que hacer cambios a lo largo de todo el sistema.
Formalmente, un elemento X es dependiente de otro elemento Y si cuando
ocurre un cambio en Y, se requiere un cambio en X para que X permanezca
correcto; si X requiere una versin compatible de Y para que X cumpla sus
propsitos entonces X es dependiente de Y. Si X no es dependiente de Y,
entonces Y puede cambiarse arbitrariamente sin afectar a la correccin de X.
Las dependencias surgen entre distintos tipos de elementos:
La implementacin de un elemento es dependiente de sus
especificaciones. Un cambio a las especificaciones probablemente
requerir cambiar la implementacin. Las especificaciones 110 dependen
de su implementacin, ya que la correccin de las especificaciones se
evala independientemente de su posterior implementacin.
Un elemento derivado es dependiente de su elemento fuente en el
sentido posible ms fuerte. Por ejemplo un programa compilado
C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 315
depende del cdigo fuente. Un cambio a un elemento fuente requiere
nuevas versiones de elementos que se derivan de l. Por definicin, un
elemento derivado 110 se puede cambiar directamente. La dependencia
de un elemento con los elementos desde los que ha sido derivado se
llama dependencia de construccin.
Cada vez que un elemento de cdigo llama a otro, el elemento que
llama es dependiente del que es amado. Si un programa A llama a otro
programa B, entonces A es dependiente de B, y no puede cambiarse sin
tener en cuenta las necesidades de B; pero no viceversa.
La documentacin de usuario y el cdigo de un sistema son
dependientes el uno del otro. Estos dos elementos se han de mantener
en paralelo; ninguno de ellos se puede evaluar ni cambiar sin el otro.
Los elementos derivados no deben confundirse con elementos binarios. Un
elemento de texto puede ser derivado, por ejemplo el cdigo C producido por
un preprocesador de C++. Inversamente, un elemento binario no tiene que ser
necesariamente un elemento derivado, por ejemplo, un procesador de textos
normalmente incluye bytes de control que describen el formato del texto, pero
a pesar de todo, es un elemento fuente.
Algunas veces no es obvio si un elemento es derivado o no. Es el caso de
un proyecto que tiene un formato estndar de cdigo fuente definido por una
plantilla. Para escribir un nuevo programa, un ingeniero primero copia la
plantilla y despus rellena los blancos. Este elemento es actualizado
manualmente y debe ser por lo tanto tratado como un elemento fuente. Sin
embargo se construye inicialmente copiando una plantilla, que no se puede
volver a crear por un proceso automtico.
De una misma fuente pueden nacer muchos elementos derivados.
Dependiendo de las instrucciones que se marcan a la herramienta que lo
construye, y de la herramienta que lo hace, pueden salir elementos
sustancialmente diferentes. Un caso tpico es la compilacin del mismo
programa para distintos requerimientos de entorno tales como sistemas
operativos, requerimientos de memoria, etc. (ejemplo en figura 14.22).
316 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Tambin se da el caso de elementos fuente que tienen lneas de cdigo
orientadas a distintos entornos. Las lneas dirigidas a un determinado entorno
se agrupan a lo largo del listado bajo marcas que el compilador entiende, y que
en funcin de los argumentos que se le pasen atiende o no. As se pueden
conseguir mdulos ejecutables con funcionalidades distintas partiendo de un
mismo fichero fuente.
El depurado tradicional incluye un anlisis de lo que el programa debera
hacer segn las especificaciones, lo que hace realmente al ejecutarlo y el
listado del cdigo. Pero muchas veces una manera ms rpida de encontrar el
error no es el anlisis del programa mismo, sino analizar las variaciones que ha
sufrido, esto es, analizar la historia del programa. Tras la historia de un
elemento se pueden esconder multitud de errores que no lo son en si mismo,
sino que lo son en funcin de la coordinacin con el resto de elementos.
Tambin se pueden detectar ms fcilmente los errores en el propio programa,
ya que si se puede relacionar el momento en que empez a dar problemas con
el momento de la implementacin de un cambio, nos proporciona una pista
muy clara de en que parte del cdigo est el error.
Si se es capaz de relacionar el inicio de los problemas con algn cambio en
alguna parte del sistema, la labor de anlisis no ya slo del elemento en
cuestin, sino de su relacin con el resto de elementos, incluso con los que
aparentemente no la tiene, se hace mucho ms directa.
Una manera sencilla de mantener la historia de un elemento es incluir la
informacin conveniente en la cabecera del elemento. As los elementos irn
C A P T U L O 14: L A G E S T IO N D E C O N F IG U R A C IO N E S 317
evolucionando, y la historia de ese cambio queda reflejado en la secuencia de
pequeos comentarios que los distintos programadores responsables de los
cambios incluyen uno detrs de otro en las primeras lneas del fichero.
Mantener la historia de un elemento es positivo para los ficheros fuentes,
como parece ms intuitivo, pero para los elementos derivados es igualmente
positivo, o incluso ms, ya que en este tipo de elementos no es fcil el anlisis
de sus caractersticas. A la vez, por su propia definicin de elemento derivado
impiden a los programadores que la informacin de su evolucin se pueda
escribir manualmente en los propios elementos.
La informacin interesante de cara a mantener la historia de un elemento
derivado es en principio toda, pero puesto que esto es materialmente imposible
un buen conjunto es el siguiente:
La fecha y la hora y la persona responsable
Una identificacin de la herramienta con la que se cre, como por
ejemplo qu Hnkadov o qu compilador.
Una identificacin de los datos que son entrada de la herramienta; por
ejemplo, el fichero fuente que se introduce a un compilador.
Las opciones y argumentos que se dan a la herramienta para conseguir
el objetivo deseado, y cul es ste; por ejemplo las opciones de
compilacin.
La razn por la que un argumento, dato u opcin se introduce en la
herramienta.
Mantener la historia de un elemento es tambin til para mejorar el
rendimiento de un entorno de desarrollo. Por ejemplo, en algunas instalaciones
se manejan innumerables elementos de un mismo proyecto. Esto genera
problemas de espacio en disco para la identificacin de componentes de las
distintas configuraciones. As, los elementos ms antiguos, o que menos uso
tienen, se eliminan fsicamente de los soportes de almacenamiento masivo.
Pero esto no significa que se pierdan, puesto que aunque sean de versiones muy
antiguas pueden ser requeridos en cualquier momento para reproducir un error
de una instalacin que utiliza una versin muy atrasada del producto. Para
reproducir el entorno se toman los ficheros fuente y se vuelve a compilar y
linkar siguiendo las instrucciones que marca la historia de cada elemento en
31 8 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
cuanto a cmo hacerlo y con qu herramienta, ya que es imprescindible que la
herramienta requerida est an disponible.
Por otro lado, no es econmicamente rentable recompilar enteramente un
proyecto en un proceso que puede durar horas de tiempo de un ordenador. Hay
pues que llegar a un compromiso entre el espacio de almacenamiento ocupado
y el tiempo de ordenador ocupado en la reconstruccin.
Esta misma tcnica de borrado selectivo con reproductibilidad se utiliza
tambin con los archivos fuente. Para ahorrar espacio de almacenamiento se
tienen siempre disponibles las ltimas versiones del elemento. Las anteriores se
reconstruyen restando las diferencias, llamadas deltas, convenientemente
almacenadas con su nmero de secuencia, el responsable, la fecha y el motivo
del cambio.
14.8 PLAN DE GESTION DE LA CONFIGURACIN DEL
SOFTW ARE.
Segn Mtrica V3 en su interfaz de gestin de configuracin el objetivo de esta
actividad es definir el Plan de Gestin de Configuracin para los requisitos de
configuracin establecidos y especificar el entorno tecnolgico de soporte a la
gestin de configuracin. Los aspectos que debe contemplar el plan son:
Identificacin de todos los productos que deben ser controlados, su
clasificacin y relaciones entre ellos, as como el criterio o norma de
identificacin.
Ubicacin y localizacin de los productos.
Definicin del mbito y alcance del control de la configuracin,
describiendo los procesos incluidos en l.
Definicin de las reglas de versionado de los productos y los criterios
de actuacin para cada caso, teniendo en cuenta el motivo por el cual se
realiza el cambio de versin.
Definicin del ciclo de estados para cada tipo de producto y los criterios
de trazabilidad entre los mismos.
Descripcin de funciones y responsabilidades.
C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 319
Identificacin de la informacin necesaria de control para auditoria.
El IEEE Std. 828-1998, por otra parte, establece los contenidos mnimos
que deben aparecer en el Plan de Gestin de la Configuracin Software. Dicho
plan puede ser un documento aislado o formar parte de otro documento (por
ejemplo, el plan del proyecto o el plan de calidad). Este estndar est elaborado
segn el siguiente contenido:
1. Introduccin. Este punto proporciona una visin simplificada del plan y
especifica:
1.1 Propsito: necesidad del plan y su audiencia.
1.2 Alcance: campo de aplicacin y limitaciones.
1.3 Definicin de trminos clave utilizados en el plan.
1.4 Referencias: estndares, procedimientos y documentos relacionados.
2. Gestin de la GCS. En este punto se asignan responsabilidades para cada
actividad de la gestin de configuracin. En detalle:
2.1 Organizacin: unidades organizativas relacionadas y relaciones entre
ellas y externas.
2.2 Responsabilidades GCS: asignacin de actividades a cada unidad
organizativa.
2.3 Polticas, directivas y procedimientos aplicables: restricciones externas
al plan que hay que considerar.
3. Actividades de la GCS. En este punto se detallan las funciones y tareas
requeridas por el plan, que son:
3.1 Identificacin de la configuracin, dividida en tres tareas, establece
tcnicas y herramientas de identificacin, manipulacin y libreras:
3.1.1 Identificacin de ECSs.
3.1.2 Nombrado de ECSs.
3.1.3 Adquisicin de ECSs.
3.2 Control de la configuracin, define procedimientos, documentacin y
niveles de autoridad para la gestin del cambio de lneas base, con las
siguientes tareas:
3.2.1 Peticin de cambios.
3.2.2 Evaluacin de cambios.
3.2.3 Aprobacin o desaprobacin de cambios.
320 P L A N IF IC A C I N Y G E S T I N D E S IS T EM A S IN F O R M T IC O S
3.2.4 Implementacin de cambios.
3.3 Contabilidad de estado de configuracin: registra e informa del estado
de los ECSs.
3.4 Auditorias y revisiones de la configuracin: determina si los ECSs
pueden convertirse en lneas base.
3.5 Control de interfaz: coordinan los cambios de ECSs con cambios a
elementos extemos al plan.
3.6 Control de la subcontratacin/compra: controla los requisitos,
revisiones y copyrights de los ECSs que provienen del exterior.
4. Planificaciones de la GCS. Establece la coordinacin y secuencias de todos
los eventos que tengan que ver con la gestin de la configuracin.
5. Recursos de la GCS. Identifica el personal, formacin, equipo, tcnicas y
herramientas software necesarias para la implementacin de las actividades del
plan.
6. Mantenimiento del plan de GCS. Identifica actividades y responsables del
cumplimiento y evolucin del plan.
14.9 HERRAM IENTAS DE CONTROL DE CONFIGURACIONES.
Es habitual que las herramientas ms conocidas de control de configuraciones
trabajen controlando los documentos del proyecto de una manera
individualizada omitiendo las relaciones que existen entre los mismos. Esta
omisin de relaciones se acenta en los momentos actuales donde, gracias a la
documentacin hipertexto o mediante tablas de asignacin de propiedades
comunes entre documentos, se pueden establecer los elementos de la
configuracin comunes a un proyecto que pueden, a su vez, ser miembros
activos de otros proyectos totalmente diferentes. As, y a modo de ejemplo,
podemos observar como actualmente, dentro del entorno Windows, es normal
que una aplicacin para cierto sistema de informacin, est compuesta de
varios ficheros ejecutables que necesitan una o varias bibliotecas de cdigo
enlazable dinmicamente que normalmente son utilizadas por otras
aplicaciones dentro del mismo ordenador. Es mas, gracias a la implementacin
de las teoras de la programacin orientada a objetos es normal que se
administren tanto el contenido de cualquier fichero individual, como libreras
de clases y las relaciones entre componentes.
C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 321
Sera deseable, por tanto, combinar las funciones de gestin de proyectos
junto con las tareas de desarrollo y el control de todo tipo de ficheros
relacionados con el proyecto de una forma nica; enfocando el problema hacia
el control de colecciones de cdigo fuente, cdigo objeto derivado,
herramientas de derivacin, planes de prueba, aceptaciones y revisiones del
SQA, documentacin de todo tipo e incluso navegacin entre documentos.
Las herramientas para el soporte a la Gestin de Configuraciones se
encuentran en estado de desarrollo alto si bien cada una de ellas enfatiza sobre
algn aspecto en particular dentro del ciclo de vida. El informe del SEI del ao
1991 donde se esquematiz el estado del arte de aquella poca nos sirve de
punto de referencia, junto con el anlisis de la evolucin de las distintas
herramientas mejoradas en sus versiones ms recientes con el paso del tiempo,
a fin de entender las funcionalidades que se esperan de un sistema de Gestin
de Configuraciones8.
As, por ejemplo, RCS (Revisin Control System) es un frec software9 para
la gestin de versiones de ficheros. RCS permite un conjunto de funciones que
ayudan en la gestin de los ficheros que estn continuamente cambiando.
Permite el almacenamiento, recuperacin, registro, identificacin y mezcla de
diferentes versiones de ficheros de texto cuyo contenido sea modificado
frecuentemente, como ficheros de cdigo fuente, documentacin, ficheros de
especificaciones, pginas html, etc.
Las principales funciones que realiza la aplicacin RCS son las siguientes:
Almacenamiento y recuperacin de mltiples versiones de ficheros de
programas y de texto. Todas las versiones de un documento se
almacenan en un nico fichero. Para la recuperacin de una versin
determinada se tienen que indicar una serie de datos como: versin,
fecha, autor, estado o clave de revisin simblica.
8 lin este sentido no olvidamos la obra de Buckley: "Implemcnting Configuration
Manageinenl", donde estudia enfoques de Gestin de Configuraciones para todos los elementos
del sistema (hardware, software y firmware) con algunos detallados tratamientos en sus
actividades principales.
9 RCS (Revisin Control System) es una herramienta con licencia GNU GENERAL PUBLIC
LICENSE por la Free Software Foundation. Inc. Esta herramienta puede ser obtenida en el
directorio oficial de distribucin de RCS ftp://ftp.cs.purduc.cdii/pub/RCS/, que contiene las
ltimas versiones, documentacin, as como distintas versiones para distintas plataformas,
unix, dos,...
32 2 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Mantenimiento de un historial de cambios. Cada vez que se realiza una
revisin, RCS almacena automticamente el autor, fecha y hora,
adems de una descripcin de los cambios realizada por el autor cuando
se registra la nueva versin.
Resolucin de conflictos de acceso. Cuando dos o ms usuarios desean
modificar la misma versin, la aplicacin RCS alerta a los
programadores y previene una modificacin incompatible con otra.
Organizacin de las distintas versiones en estructura de rbol. Esto
permite mantener abiertas (modificndose) varias lneas de desarrollo
simultneamente. Cada lnea estara representada por una rama del
rbol.
Permite unir varias versiones: Si las versiones afectan a la misma parte
de cdigo, RCS alerta sobre tal circunstancia.
Se pueden marcar determinadas versiones de diferentes documentos
con nombres (claves) simblicos, lo que permite referenciar al conjunto
completo de todas ellas como una configuracin.
Se identifica automticamente cada revisin con: nombre, nmero de
revisin, hora de la revisin, autor, etc. La identificacin hace simple
determinar que revisiones de que mdulos concuerdan con una
configuracin determinada.
Minimiza el espacio necesario en disco para el almacenamiento de
todas las versiones. RCS necesita poco espacio extra para las versiones
(slo almacena las diferencias entre las versiones en forma de deltas,
cambios elementales entre ficheros de texto) de forma que slo se
almacena de forma completa la ltima revisin.
RCS mantiene un completo historial de cambios. As, una persona
puede encontrar que le sucedi a un mdulo fcil y rpidamente, sin
tener que comparar las listas de cdigo y sin tener que preguntar a sus
compaeros.
RCS realiza la grabacin automtica de propietarios.
RCS almacena todos los cambios automticamente.
C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 323
RCS garantiza la continuidad del proyecto.
Provee un alto nivel de visibilidad de la gestin. As, es fcil seguir el
estado de un proyecto software porque provee un completo historial de
cambios y graba quin hizo qu, cuando y a qu versin de qu mdulo.
RCS es totalmente compatible con las herramientas existentes de
desarrollo de software. RCS no obstaculiza, su interfaz al sistema de
ficheros es tal que todas las herramientas software existentes pueden ser
usadas como antes.
El interfaz bsico de usuario de RCS es simple. Para su manejo basta
con dos comandos. Las facetas ms sofisticadas han sido llevadas hacia
avanzados entornos de desarrollo software.
RCS simplifica la distribucin software si los clientes mantienen
cdigos tambin con RCS. Esta tcnica asegura una identificacin
adecuada de versiones y configuraciones, y el seguimiento de las
modificaciones de los clientes.
Otras herramientas, Jasmine, por ejemplo10, funcionan en base a una
descripcin textual y as se modela el inventario de los componentes del
sistema, la estructura, la configuracin, la forma de construir la aplicacin, las
pruebas... La definicin textual, en forma de lenguaje de control de
configuraciones, involucrar relaciones, dependencias, prioridades en la
construccin y reglas de verificacin; permitiendo el uso de tmplales o
esqueletos previamente construidos para facilitar la descripcin del sistema
completo.
Otro ejemplo puede ser la forma de funcionamiento de Rational que, como
muestra Feiler en 1988, se enfoca principalmente hacia el trabajo por
subsistemas entendidos como interfaces ms implementaciones; los
componentes son invisibles una vez que se ha efectuado la exportacin del
subsistema. Permite recompilaciones entre subsistemas.
Otras herramientas, como por ejemplo DSEE, hacen hincapi en el pool de
objetos derivados para ser compartidos. Introduce el concepto de BCT (Bound
Configuraron Thread) donde se almacenan todos los detalles asociados con
cada objeto, desde versiones de fuentes, herramientas, descripciones, fechas,
10 Vease el artculo de Marzullo de 1986 titulado Jasm ine: A Software System M odelling Fa-
cility", donde se anuncian sus funcionalidades.
324 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
personas involucradas, comentarios... El usuario indica las propiedades de
derivacin deseadas y OSEE usa, de forma automtica, un objeto que debe de
existir.
CCC (Softool, 1987), por ejemplo, separa fases y responsabilidades
modelando las tareas, las transiciones y generando, finalmente, un data flow.
Un protocolo de actuaciones aprueba las transiciones entre estados y el ciclo de
vida queda almacenado va actividades en los diferentes estados de la
configuracin.
LIFESPAN es un verdadero ayudante para generar modelos de procesos
para realizar los cambios, para ello cuenta con una coleccin configurable de
formularios en lnea como los de Informes del Rendimiento del Software,
Diseo de Cambios y el Informe del Estado del software. Tambin cuenta con
una batera de herramientas para el control de tareas, roles y estados; entre los
que convendra destacar el Anlisis del Impacto del Cambio, Personas
afectadas por el Cambio, Descripcin y modelos de la aprobacin de los
cambios,...
14.10 RENTABILIDAD DE LA GESTIN
CONFIGURACION.
Del anlisis de las herramientas destacamos a continuacin aquellos aspectos
que ms nos han llamado la atencin en cuanto a rentabilidad inmediata de la
aplicacin de Gestin de Configuraciones:
Regeneraciones de componentes.
El grupo de desarrollo necesita que la herramienta integrada de Gestin de
Configuraciones permita regenerar, de una forma ordenada y segura, cualquier
versin anterior de una aplicacin en cualquier nivel de desarrollo. De esta
forma puede explorarse un error descubierto en una cierta versin para
asegurarse si afecta o no a cualquier otra versin en explotacin.
Con este tipo de caractersticas un desarrollador que se encuentra
trabajando en una aplicacin sobre una cierta configuracin al da de la fecha,
al que se le informa de un error usando otra versin de la misma aplicacin,
puede conocer las diferentes versiones de los componentes incluidos en aquella
versin y actuar sobre el componente concreto, dejando que el sistema trabaje
C A P T U L O 14- LA G E S T I N DE C O N F IG U R A C IO N E S 325
por l en la localizacin de todos y cada uno de los componentes. Adems, la
interfaz grfica le deber mostrar el grafo de las distintas versiones a partir de
la realizacin de ese bug en todo tipo de configuracin.
Para restaurar los ficheros puede ayudarse de las funciones estndar de
cualquier sistema de Gestin de Configuraciones, que puede completar con un
sistema automtico de reparto de carga si estamos tratando sistemas
distribuidos.
Mantenimiento de cdigo reutilizable.
El mantenimiento del cdigo reutilizable es una de las actividades en las
que las organizaciones empiezan a invertir ei tiempo de los miembros de
desarrollo. Se trata de seguir la poltica de desarrollar las aplicaciones en torno
a un cdigo principal que se utiliza repetidamente en otras muchas
aplicaciones.
Cada da las empresas de desarrollo miran su software como un activo a
proteger, activo o actividad productiva que debe de estar continuamente
gestionado y que puede ser reusado para obtener un mayor nivel de beneficios.
DE LA Esto hace necesario entender que la reutilizacin de los distintos mdulos sea
una actividad fuertemente conectada con las herramientas de mantenimiento
automatizado del software.
Para Adams y otros, las herramientas automticas pueden ayudar a
mantener el software con una alta calidad, muy rpidamente y con un bajo
coste, siempre que la mentalidad de los directivos acepte la necesidad de
herramientas potentes en este sentido, siendo necesario el control de las ver
siones generadas por estos componentes reutilizados porque estos mdulos
evolucionan a lo largo del tiempo, bien porque se solucionen algunos errores o
bien porque se adaptan a nuevas necesidades. Si bien los beneficios que aporta
la estructura de cdigo reutilizable es clara, la gestin de estos objetos es
tediosa si no se dispone de una herramienta integrada en el entorno de trabajo
que nos ayude en el trabajo de saber que versin de estos componentes tiene
incorporada cada versin de la aplicacin.
El entorno debe efectuar la labor de agente para ayudar al desarrollador a
propagar los cambios a todas las ubicaciones adecuadas11 y, bajo la supervisin
11 Vase la obra de Whitgift: Methods and Tools for Software Configuraron Management,
donde se aporta informacin, en su momento novedosa, en aspectos de integracin de 'la GG il
la base de datos del proyecto donde se aplican las herramientas CASE.
3 26 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
de los responsables, obtener nuevas versiones, tanto de cdigo fuente como
ejecutable, de las aplicaciones construidas con estos objetos.
Para que esto sea posible la herramienta deber almacenar en su
repositorio una sola copia de cada versin de un componente reutilizable ms
una referencia a cada aplicacin que utilice este componente concreto. De esta
forma, mientras que un grupo de desarrollo congela una versin para someterla
a pruebas o evitar errores, otro grupo puede seguir efectuando el
mantenimiento sobre este cdigo reutilizable.
Apuntando a este tipo de componentes, la empresa puede implementar
procesos de reingeniera en Ingeniera del Software, entendida como el proceso
de examinar un sistema de software existente y/o modificarlo con la ayuda de
herramientas automticas para:
Prever su futura mantenibilidad
Actualizar su tecnologa
Prolongar su esperanza de vida
Incrementar la productividad del mantenimiento
Los tipos de reingeniera que se pueden realizar para lograr la
competitividad y alcanzar un mayor grado de madurez en la industria
informtica son:
Anlisis: Procesos que estudian un sistema con el objetivo de
comprender su funcionamiento y comportamiento y, as, poder extraer
informacin para la reingeniera o para medir su calidad.
Reestructuracin: Es el proceso que se encarga de cambiar la forma del
software sin alterar su funcionamiento. El objetivo primario es hacer los
programas ms fciles de entender.
Ingeniera inversa: Son procesos de anlisis de sistemas para construir
una descripcin de sus componentes y sus relaciones. El objetivo de la
ingeniera inversa es documentar el sistema y descubrir la informacin
de diseo con el nimo de facilitar la comprensin del programa.
Migracin: Proceso de conversin de un sistema software desde un
lenguaje a otro, adaptndolo a otro sistema operativo o actualizando su
tecnologa.
C A P T U L O 14: LA G E S T I N DE C O N F IG U R A C IO N E S 327
Generacin de versiones especificas para clientes.
Otro tipo de problemas importantes son las necesidades que tienen
determinadas organizaciones para satisfacer los requisitos de los clientes que
exigen pequeas variaciones a los programas generales para satisfacer
necesidades especficas de sus procesos de negocio.
La forma de trabajar tpica hasta el momento es tener diferentes libreras
de trabajo, una por cliente, y efectuar las modificaciones necesarias en cada
una de las distintas libreras de trabajo. Con el empleo de una herramienta de
gestin de versiones de elementos reutilizables se pueden crear proyectos
diferentes, pero indicando que parte de los archivos son compartidos y cuales
son especficos, de modo que un componente comn se pueda modificar de
forma automtica para todos los clientes en sus diferentes versiones.
Distribucin automtica del software.
La configuracin de la informtica de empresa actual es totalmente
distribuida; son pocos los terminales que an no han sido sustituidos por
potentes estaciones de trabajo. Las arquitectura cliente/servidor han ido
haciendo que la configuracin del hardware se desarrolle de una forma en que
los diferentes componentes compiten para ofrecer un mejor servicio a las
organizaciones.
Sin embargo todos conocemos fracasos en la implementacin de este tipo
de tecnologas por la falta de control de lo que sucede en cada uno de los nodos
de las redes ofimticas, entendiendo por "suceder" el conocimiento de las
versiones de programas que estn rodando en cada una de las estaciones.
Rawling, en este sentido, enfatiza el hecho de los desarrollos de software en un
entorno de red.
Es normal que en entornos distribuidos no se conozca al detalle que
software est rodando, desde que fecha y si se ha actualizado correctamente la
versin de sus componentes en las fechas prefijadas. Esto nos conduce a
replantear la necesidad de que la propia herramienta de gestin de
configuraciones tenga que soportar las labores de llevar un inventario de todos
los nodos, sus caractersticas y la topologa de la red, para satisfacer preguntas
como qu objetos hay que distribuir a cada nodo, qu versiones, en qu
momento y con qu medios.
328 PL A N IF IC A C I N Y G E S T I N DK S IS T E M A S N F O R M T IC O S
Los beneficios que se encuentran con la inclusin de estas caractersticas
en la herramienta de GCS son segn Ros (1994):
Distribucin controlada del software. Lo que supone la transmisin
perfectamente controlada de los distintos componentes a travs de la
red, con la inclusin del apropiado acuse de recibo tanto del transporte
como de su instalacin o actualizacin.
Mejora de la calidad al asegurar el cumplimiento de los estndares de
suministro del software en sus diferentes versiones.
Mejora de los sistemas de seguridad al poder detectar, con la propia
automatizacin, el software intruso, gracias a una gestin de control a
travs de una lista, del software autorizado.
Mtodos de optimizacin de la gestin de la distribucin en grandes
sistemas, al permitir incluir tasas de transferencia de informacin
relativas al trfico normal de gestin y disear una distribucin del
software en cascada para reducir la carga de la red.
Resumiendo, podemos enumerar una serie de factores que sera necesario
automatizar desde la propia herramienta de Gestin de la Configuracin como
son: la Gestin del Inventario software y hardware, la entrega del software a
distribuir, la gestin de la propia distribucin y actualizacin del software con
acuses de recibo, la gestin de licencias, el registro de los distintos
acontecimientos que puedan suceder y la posible auditoria.
Administracin de informacin hipcrniedia cambiante.
En este sentido Stan Magee y Leonard Tripp12 en 1999 presentan una gua
de estndares y especificaciones para el diseo de software en WEB.
Por otra parte el ISOC ha propuesto un estndar (RFC2215) donde
pretende establecer unos parmetros generales para la caracterizacin de
elementos integrados en los servicios de red.
12 Leonard L. Tripps, graduado en Matemticas y doctor por la Universidad Brigham Young,
actualmente es el presidente de la IEEE Computer Society.
CAPTULO 15
LA GARANTA DE CALIDAD
En colaboracin con el Dr. Jos Ramn Hilera Gonzlez
El objetivo de este captulo es describir los procesos necesarios para que el
director del proyecto pueda medir y garantizar la calidad del software
producido como una labor ms en su gestin del proyecto.
La garanta de calidad del software (o SQA, Software Quality Assurance)
es una actividad de proteccin que se aplica en todo el proceso de ingeniera
del software. Corresponde a muchos en la organizacin, a los ingenieros de
software, a los gestores de proyecto, clientes, comerciantes, personas del grupo
de desarrollo, pero la responsabilidad de la gestin de proyectos exige el
control y garanta de la calidad del software desde el punto de vista tcnico y
del cliente.
La planificacin de la calidad es una actividad presente en todas las
organizaciones de software, que establece y desarrolla los objetivos y
requisitos de la calidad y su aplicacin (ISO 8402). Asimismo, es necesario que
la direccin exprese formalmente una poltica de calidad que abarque todas las
directrices y objetivos de la empresa relativos a la calidad. Todas estas,
funciones estn encuadradas en la gestin de calidad (UNE 66-001).
A lo largo del tema veremos en detalle el concepto de calidad, su
evolucin histrica y algunos trminos relacionados, como control de calidad,
garanta de calidad, gestin de calidad y sistemas de gestin de calidad.
Determinaremos los factores que influyen en la calidad del software y tcnicas
asociadas a la calidad del software: revisiones, validaciones, verificaciones y
pruebas. Estudiaremos las mtricas de la calidad del software, las normas y
estndares existentes y los contenidos del plan de calidad del software.
Veremos, despus, el modelo CMM (Capacity Madurity Model) para el control
del grado de madurez de las organizaciones en el desarrollo del software. Por
ltimo entraremos en un tema, que est cobrando una gran relevancia: el papel
de la documentacin en la calidad del software como elemento integrador.
33 0 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
15.1 INTRODUCCION A LA GARANTIA DE CALIDAD DEL
SOFTWARE
Conviene sealar que antes del siglo XX la garanta de calidad era
responsabilidad nica del fabricante del producto, siendo una labor artesanal
con un control individual de cada tarea. Aparece el concepto de calidad
moderno en el ao 1918 con las primeras cadenas de montaje (Ford) y ms
adelante se introduce el trmino de garanta de calidad en los laboratorios Bell,
extendindose por todo el mundo con gran rapidez. Hoy da el control de
calidad y su garanta es una actividad esencial en cualquier empresa que trata
de vender sus productos y quiere mantenerse en el mercado.
La ISO 8402 define la calidad como conjunto de propiedades y de
caractersticas de un producto o servicio, que le confieren aptitud para
satisfacer una necesidades explcitas o implcitas.
La garanta de calidad del software (QA o Quality Assurance) es un
trmino que se refiere a la verificacin y validacin de cada fase del ciclo de
vida del proyecto software, de hecho en muchos organismos ambas actividades
se confunden. La garanta de calidad del software actualmente se entiende
como parte de la metodologa de desarrollo (sirva de ejemplo la metodologa
espaola METRICA versin 3) que se aplica a lo largo de todo el proyecto y
engloba las revisiones tcnicas formales, las estrategias de prueba multiescala,
el control de la documentacin del software, procedimientos de ajuste a
estndares y mecanismos de medida y de informacin.
Histricamente la gestin de calidad ha ido alcanzando gran protagonismo. La
siguiente figura (15.1) nos muestra su evolucin.
/ /
C a lid a d [y Mejora continua
Calidad tota
/ de calidad en distintos aspectos de una organizacin: gestin de proyectos,
Garanta Q) P rev e n ir fallos
de calidad
C ontroles I Q) Detectar fallos
de calidad
T ie m p o
Figura 15. Evolucin histrica de a calidad del software.
C A P T U L O 15: LA G A R A N T A D E C A L ID A D 331
Hasta los aos 80 podemos hablar de la existencia de controles de calidad,
que consisten en un conjunto de tcnicas y actividades operativas que verifican
si el producto o servicio cumple con los requisitos de calidad exigidos (UNE
66-001). Estos controles de calidad se dirigan a impedir que un producto
defectuoso llegara al cliente y/o a proporcionar un servicio aceptable, dentro de
un entorno poco competitivo y de produccin. Bsicamente se utilizaban
tcnicas de control estadsticas.
Alrededor de los aos 80 comienza a extenderse, principalmente en Japn,
el concepto de calidad total, no solo hay que detectar los fallos, lo importante
es prevenirlos, que no aparezcan. La garanta de calidad se considera un valor
aadido dentro de un entorno de mercado cada vez ms competitivo. Se
desarrollan los conceptos de planificacin y mtricas de calidad y la
responsabilidad y seguimiento de la calidad se extiende a toda la organizacin.
Se definen los primeros modelos de calidad, normas y estndares (que vienen
ampliamente utilizados), comienzan a realizarse auditorias de calidad y a
formarse profesionales especficos, se extiende la concesin de premios a la
calidad. Se define la garanta de calidad como un conjunto de acciones
planificadas y sistemticas necesarias para proporcionar la seguridad de que un
producto o servicio satisfar los requisitos dados sobre calidad.
Actualmente se asume como imprescindible la calidad total y la garanta
de calidad de los productos. Estos trminos forman parte de una nueva cultura
empresarial y un nuevo estilo, proporcionan una ventaja competitiva en el
mercado y un gran impacto estratgico. Pero, no solamente son conocidos en el
mbito empresarial, si no que salen a la calle y forman parte del vocabulario
habitual de clientes, trabajadores y consumidores. Se establecen parmetros de
mejora contina: planificacin, fijacin de objetivos, coordinacin, formacin
y adaptacin de toda la organizacin. Como veremos posteriormente en este
tema, la mejora continua es el objetivo de una organizacin madura, tal como
establece el CMM (Capacity Madurity Model) que nace para evaluar el nivel
recursos humanos, etc. y guiar a las organizaciones en la mejora de su calidad
global.
Las definiciones precisas ayudarn a comprender algunos trminos que a
primera vista pueden resultar vagos o ambiguos en el entorno software. As, la
calidad del software la define Roger S. Pressman como la "concordancia con
los requerimientos funcionales y de rendimiento explcitamente establecidos,
con los estndares de desarrollo explcitamente documentados y las
caractersticas implcitas que se espera de todo software desarrollado
332 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 15: L.A G A R A N T A D E C A L ID A D 333

profesionalmenle". Segn la definicin anterior los fundamentos con los que se 8402). Estos sistemas deben estar suficientemente respaldados por la
mide la calidad son los requerimientos del sistema y la no concordancia entre alta direccin y tener el alcance suficiente, en medios y recursos, para
estos puntos es una deficiencia de calidad, por eso las actuales metodologas de conseguir los objetivos de calidad. Actualmente, es muy comn ligar
desarrollo de sistemas insisten en la garanta de calidad desde los primeros estos sistemas a las clusulas contractuales o vinculantes en la
requerimientos funcionales. Esta definicin, adems, enfatiza dos puntos: los valoracin de la calidad. Los sistemas de gestin de calidad
estndares definen un conjunto de criterios de desarrollo y que existen habitualmente incluyen:
requerimientos implcitos que no se mencionan como, por ejemplo, el deseo de
que un programa sea fcil de mantener y de depurar. 1..Enfoque de gestin de calidad.
2. Tecnologas de IS (mtodos y herramientas).
Segn el estndar IEEE 610-1990 la calidad del software es el grado con 3. Revisiones Tcnicas Formales durante el proceso de software.
el que un sistema, componente o proceso cumple los requerimientos 4. Estrategia de pruebas.
especificados y las necesidades o expectativas del cliente o usuario. El grado 5. Control de la documentacin del software y de cambios.
de la calidad del software alcanzado actualmente no es el ptimo, de hecho, las 6. Procedimientos que aseguren un ajuste a los estndares de
organizaciones desarrolladoras de software, plantean problemas muy comunes, Sistemas de Informacin.
como la falta de planificacin, la desorganizacin, la primaca del parche a lo 7. Mecanismos de medicin y generacin de informes.
hecho ayer sobre como mejorar mi trabajo de hoy, el trabajo personal y
artesanal, la falta de una ngenierizacin de la produccin de software, etc. De
hecho hay porcentajes muy elevados de proyectos software que no cumplen
con los requisitos deseados (en torno al 90% de los sistemas utilizados) o que 15.2 FACTORES DE CALIDAD DEL SOFTWARE
no se entregan o fracasan (alrededor del 30% del los sistemas desarrollados).
Conviene sealar los factores que determinan la calidad del software, trminos
Para resolver estos problemas surge la Ingeniera del Software con nueva introducidos por McCall en su libro Factors in Software Quality, donde
fuerza incorporando a los procesos del ciclo de vida del software la gestin de ofrece el significado de cada uno de ellos:
la calidad y a las tcnicas y herramientas a utilizar durante el proceso los
sistemas de calidad del software: Correccin /.Hace lo que se peda en los requisitos?
Fiabilidad Se ejecuta sin fallos todo el tiempo?
La gestin de calidad determina y aplica la poltica de la calidad, los Eficiencia Se ejecuta en ptimas condiciones de
objetivos y las responsabilidades utilizando la planificacin de la uso de tiempo y recursos?
calidad, el control de la calidad, la garanta de calidad y la mejora de la Integridad Es seguro? Puede acceder personal no
calidad. Es responsabilidad de todos los niveles ejecutivos, pero debe autorizado?
estar guiada por la alta direccin. Su realizacin involucra a todos los Facilidad de uso Puede ser utilizado fcilmente y posee
miembros de la organizacin y debe tener en cuenta tambin criterios documentacin de uso?
de rentabilidad. Flexibilidad Es fcil modificarlo?
Facilidad de prueba Se puede probar en todas sus
El aseguramiento de la calidad es el conjunto de acciones planificadas y posibilidades?
sistemticas que son necesarias para proporcionar la confianza Facilidad de mantenimiento Sus caractersticas permiten adaptarse
adecuada de que un producto o servicio satisfaga los requisitos dados fcilmente a los cambios (comprensin,
sobre calidad (UNE). modularidad, etc.)? Es fcil detectar y
corregir un error?
Los sistemas de gestin de la calidad incluyen una estructura de la Portabilidad Es posible usarlo en otro entorno?
organizacin, de responsabilidades, procedimientos, procesos y Reusabilidad Se puede reutilizar alguno de sus
recursos que se establece para llevar a cabo la gestin de calidad (ISO componentes?
334 P L A N IF IC A C I N Y G E S T I N DE SIS T E M A S IN F O R M T IC O S C A P T U L O 15: L A G A R A N T A D E C A L ID A D 335

Facilidad de interoperacin. Tiene capacidad para relacionarse
fcilmente con otros sistemas?
McCall, en su estudio de estos factores, se centra en tres aspectos
importantes de un producto software y agrupa los factores en tomo a ellos:
Caractersticas operativas, corresponde a los cinco primeros factores.
Capacidad de soportar los cambios, corresponde a los tres factores
siguientes.
Adaptabilidad a nuevos entornos, corresponde a los tres ltimos
factores.
Por otra parte, Pressman da ms importancia a las mtricas de calidad, a la
forma de asegurar que se cumplen los factores, y los clasifica en dos grandes
grupos:
La fiabilidad se calcula midiendo la frecuencia de los fallos y su
importancia, la bondad de los resultados obtenidos, el tiempo medio
entre fallos, la posibilidad de recuperarse a los fallos y la facilidad de
predecir los resultados del software.
Tanto el modelo de McCall como el de Grady, presentan adems mtricas
precisas que permiten cuantificar cada uno de los factores presentados.
Existen muchos otros estudios de factores que influyen en la calidad del
software y se actualizan constantemente en funcin de las tcnicas y
metodologas que aparecen. La figura 15.2 muestra el resultado del estudio
realizado por el Grupo de Trabajo sobre Calidad del Software de la Asociacin
de Tcnicos de Informtica (ATI), que divide los factores en dos grandes
grupos: operativos y de adaptabilidad, desarrollando, adems, las
caractersticas de cada no de los factores.

Factores que pueden ser medidos directamente.

Factores que solo pueden ser medidos indirectamente.

Otra lista de factores de calidad es la desarrollada por Grady y Caswell en Factores Operativos
su libro Software Metrics: Establishing a Company-Wide Program. Los
factores y sus atributos correspondientes son los siguientes: |Inteqridad| |Exactitu| jlnteroperabilidadl |VerJci

La funcionalidad es funcin de las caractersticas y posibilidades del -/Auditoria .. Completitud -M odularidad No deficiencia
software, las funciones que proporciona y la seguridad de todo el -Segu rid ad -Consistencia -Conformidad -Tolerancia a fallos
sistema. - Visin Global -Trazabilidad Disponibilidad
Amigabilidad

El rendimiento se obtiene midiendo la velocidad de proceso, el tiempo Operabilidad

de respuesta, el consumo de recursos y el rendimiento total de

IVerificabilidadl |Eficiencio|
procesamiento.
-Simplicidad -Comportamiento en el tiempo
La facilidad de uso se obtiene considerando los factores humanos, el Modularidad Comportamiento con recursos
aspecto global, la consistencia y la documentacin. -Legibilidad
. Trazabilidad
La capacidad de soporte es funcin de la facilidad de mantenimiento Testeabilidad
del software, entendido como posibilidad de ampliacin
(extensibilidad), adaptabilidad y facilidad con la que se pueden
localizar y corregir los errores, adems, intervienen la facilidad de
prueba, la compatibilidad, la posibilidad de configuracin, y la facilidad
de instalacin y operacin.
336 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 15: l.A G A R A N T A D E C A L ID A D 337

desarrollo de cada actividad, controles intermedios y procesos de prueba. Por

Factores de Adaptabilidad otro lado, la validacin del software, al estar relacionada con el uso que hacen
de l los usuarios plantea formas distintas de ver la calidad, est ms
1 I l 1 relacionada con aspectos de comunicacin que tcnicos y es ms difcil de
lUsabilidadl |Mantenimiento| |Reusabilidad| |Ampliabilidad|
medir. Como solucin a este problema se extiende el uso de prototipos, pruebas
U tilidad -C on sisten cia - Madurez de usuario durante el desarrollo (no solo en la implantacin) y uso en
-F a cilid a d de uso -Legibilid ad -Generalidad
condiciones reales del software.
_ Facilidad de aprendizaje -Concisin
- Am igabilidad -E sta b ilid a d La gestin de calidad es ms til si comienza a realizarse en las etapas ms
Operabilidad tempranas del ciclo de vida de software. Cuanto antes se detecte un error es
ms fcil de corregir y por lo mismo el coste de correccin ser menor. La
|Expansibitidad| |Portcbilidadl figura 15.3 muestra una comparacin de los costes de desarrollo del software
en funcin de los errores encontrados (fuente 'Ingeniera del Software: Un
-L egib ilid ad Adaptabilidad
enfoque prctico de Pressman).
-G r a d o de ascendencia Conform idad

Concisin -In sta n c ia b ilid a d

Remplazabilidad

Figura 5.2 Detalle de los factores que influyen en la calidad de! software.
Con revisiones tempranas

Fase en la que se Nmero de errores Coste de Correccin Total

encontro el errror encontrados por error
15.3 TEC N IC A S DE CALIDAD DEL SOFTW ARE
Durante el diseo 22 1.5 33

Antes de la prueba 36 6.5 234

Segn Presuman no es necesario ser un experto en control de calidad para
Durante la prueba 15 15.0 315
darse cuenta que uno de los aspectos fundamentales de la calidad del software
son los errores que aparecen en tiempo de explotacin. Podemos identificar Tras la implantacin 3 67.0 201

fcilmente dos aspectos en el software, por un lado la solucin software o el Total 783
producto y, por otro lado, al uso que se haga del software o la satisfaccin de
las necesidades del usuario del software. Estos dos conceptos se han
Sin revisiones tempranas
consignado como la dualidad Verificacin y Validacin. La verificacin se
Fase en la que se Numero de errores Coste de Correccin Total
refiere al conjunto de actividades que aseguran que el software describe encontro el errror encontrados por error
correctamente lo operacin que realiza. La validacin se refiere a un conjunto Antes de la prueba 22 6.5 143
de actividades que aseguran que el software construido se ajusta a los
Durante la pnieba 82 15.0 1.230
requerimientos del cliente. Boehm lo establece de la siguiente forma:
Tras la implantacin 12 67.0 804
Verificacin Estamos construyendo el producto correctamente? Total 2.177

Validacin______Estamos construyendo el producto correcto?_____

Para Pressman la verificacin sirve para analizar las actividades que
componen el proceso completo del ciclo de vida del software desde la
perspectiva de su calidad organizativa. Las actividades de inherentes a la
verificacin las podemos concretar a travs de criterios de correccin del
Figura 75.3 Comparacin de costes de desarrollo del software.
Un mecanismo bsico para la realizacin de pruebas tempranas son las
revisiones tcnicas. Hay dos motivos bsicos para una revisin tcnica:
33S P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
El trabajo tcnico necesita ser revisado.
Hay errores que son percibidos ms fcilmente por otras personas que
por los creadores.
Las revisiones tcnicas deben ser realizadas por los propios
desarrolladores del software y por personas externas a ese proceso. Por un lado,
el propio desarrollador conocer muy bien el software realizado, donde
encontr ms dificultades, que parte del software es ms novedosa, pero puede
estar condicionado por la entrega del software y su propio punto de vista. Por
otro lado, una persona externa al desarrollo ser ms imparcial, tendr criterios
diferentes y no estar influida por las soluciones tcnicas adoptadas,
dirigindose ms al resultado final y el cumplimiento de requisitos.
Las revisiones tcnicas proporcionan dos ventajas, adems de la deteccin
temprana de errores:
Sealar que hay es posible mejorar.
Conseguir un trabajo tcnico ms homogneo.
La finalidad de una revisin tcnica es encontrar errores, puede parecer
una contradiccin, pero una revisin tcnica tiene xito si se encuentran errores
en el software, el no encontrarlos no significa que no estn.
Las Revisiones Tcnicas Formales (RTF) se diferencian de las revisiones
tcnicas informales (que se deben llevar a cabo constantemente, ya que sin
tales revisiones la programacin y comprensin de un proyecto seran
imposibles) en:
Obtencin de un informe escrito del estado del producto revisado.
Participacin activa y abierta de todos los componentes del grupo de
revisin.
Total responsabilidad de todos los participantes en la calidad de la
revisin.
Los objetivos que deben cubrir las RTF son los siguientes:
Descubrir errores en la funcin, la lgica o la implementacin.
Comprobar que el software bajo revisin cumple los requisitos
previstos.
Garantizar que el software cumple los estndares.
Proporcionar uniformidad en el software.
C A P T U L O 15: L A G A R A N T A D E C A L ID A D 339
Facilitar la gestin de proyectos.
Las RTF reducen sustancialmente el coste del software y tienen un gran
valor educativo para los participantes. Adems sirven para comunicar la
informacin tcnica entre todo el grupo de proyecto y fomentan la seguridad y
la continuidad.
El proceso a seguir en un RTF contiene los siguientes pasos:
1. El desarrollador informa al jefe de proyecto la terminacin del
producto.
2. El jefe de proyecto contacta al jefe de revisin o el responsable de
calidad.
3. Revisores y jefe de revisin revisan el producto.
4. La reunin de revisin es llevada a cabo por el jefe de revisin, los
revisores y el desarrollador.
5. Al final todos los participantes deben decidir si:
1. Aceptan el producto sin posteriores modificaciones.
2. Rechazan el producto por errores.
3. Aceptan el producto provisionalmente.
6 . Una vez tomada una decisin deben emitir un informe firmando.
La prueba de programas es una parte fundamental de las revisiones del
software. Un programa puede tener un nmero muy elevado de caminos
diferentes por donde puede seguir y se necesitaran muchos aos para probarlos
todos. Para intentar paliar este problema nacen los mtodos de casos de prueba.
Podemos dividir estos mtodos en dos tipos:
Pruebas de caja blanca. Su fin es asegurar que todas las sentencias y
todas las condiciones se han ejecutado al menos una vez. Son pruebas
estructurales. Ejemplo de este tipo de pruebas son la prueba del camino
bsico y la prueba de bucles.
Pruebas de caja negra. Su fin es asegurar que las funciones del software
son operativas, que la entrada se acepta de forma adecuada y que se
produce una salida correcta, as como que la integridad de los datos se
mantiene. Son pruebas funcionales. Ejemplo de este tipo de pruebas son
el mtodo de la particin equivalente y el anlisis de los valores lmites.
340 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Excepto para programas pequeos, el software no deberan probarse como
un nico elemento. Los sistemas medianos/grandes se construyen a partir de
sistemas ms pequeos que se dividen en mdulos con distintas funciones y
procesos. Esta divisin continua hasta llegar a los programas, documentos y
estructuras de datos. Por lo tanto, el proceso de prueba debera trabajar por
etapas, llevando a cabo pruebas a distintos niveles. Mtrica V3 define los
siguientes tipos de pruebas, a llevar a cabo en distintos perodos del ciclo de
vida del software:
Pruebas Unitarias. Las pruebas unitarias tienen como objetivo verificar
la funcionalidad y estructura de cada componente individualmente una
vez que ha sido codificado.
Pruebas de Integracin. El objetivo de estas pruebas es verificar el
correcto ensamblaje entre los distintos componentes una vez que han
sido probados unitariamente con el fin de comprobar que interactan
correctamente a travs de sus interfaces, tanto internas como externas,
cubren la funcionalidad establecida y se ajustan a los requisitos no
funcionales especificados en las verificaciones correspondientes.
Pruebas del Sistema. Las pruebas del sistema tienen como objetivo
comprobar la integracin del sistema de informacin globalmente,
verificando el funcionamiento correcto de las interfaces entre los
distintos subsistemas que lo componen y con el resto de sistemas de
informacin con los que se comunica.
Pruebas de Implantacin. El objetivo de las pruebas de implantacin es
comprobar el funcionamiento correcto del sistema integrado de
hardware y software en el entorno de operacin, y permitir al usuario
que, desde el punto de vista de operacin, realice la aceptacin del
sistema una vez instalado en su entorno real y en base al cumplimiento
de los requisitos no funcionales especificados.
Pruebas de Aceptacin. El objetivo de las pruebas de aceptacin es
validar que un sistema cumple con el funcionamiento esperado y
permitir al usuario de dicho sistema que determine su aceptacin, desde
el punto de vista de su funcionalidad y rendimiento.
Pruebas de Regresin. Estas pruebas se utilizan en la fase de
mantenimiento o si se realizan cambios durante el desarrollo. El
objetivo de las pruebas de regresin es eliminar el efecto onda, es decir,
comprobar que los cambios sobre un componente de un sistema de
informacin, no introducen un comportamiento no deseado o errores
adicionales en otros componentes no modificados.
C A P T U L O 15: L A G A R A N T A D E C A L ID A D 341
15.4 M TRICAS DE CALIDAD DEL SOFTWARE
Cada uno de los factores de calidad del software, ya descritos, puede ser
evaluado mediante un conjunto de mtricas basadas en la observacin del
software. Para cada criterio McCall propuso una serie de mtricas, aunque,
muchas de ellas tienen un carcter subjetivo. Las mtricas pueden ser una
simple lista de comprobacin de ciertas caractersticas asociadas a cada factor
de calidad. Me Cali propuso un esquema de graduacin mediante una escala
que va de cero (bajo) a 10 (alto) para puntuar cada caracterstica y obtener un
valor para cada factor. Modelos parecidos al de McCall proponen la norma
IEEE 1061 y la norma ISO 9126.
Segn Fenton (1997) una mtrica es una asignacin de un valor a un
atributo de una entidad de software, ya sea un producto o un proceso. En
todos los casos las mtricas representan medidas indirectas de la calidad, ya
que miden posibles manifestaciones extemas de esa calidad y muchas veces
son mediciones subjetivas.
Bsicamente tenemos mtricas basadas en el texto del cdigo y mtricas
basadas en la estructura de control del cdigo. Un ejemplo de las primeras son
las que toman como indicar de tamao las lneas de cdigo, como indicar de
documentacin las lneas de comentarios, etc. Las mtricas basadas en la
estructura del cdigo de control pueden basarse en la arquitectura del sistema,
llamadas entre mdulos, etc. o, tambin, en la estructura interna de cada
mdulo utilizando el grafo e control.
Una actividad muy importante de la gestin de calidad del software se
centra en la identificacin y evaluacin (medicin) de los riesgos potenciales
que pueden producir un impacto negativo en el software y hacer que falle. En
este entorno distinguimos dos conceptos:
Fiabilidad del software. Se define como la probabilidad de operacin
libre de fallos de un programa de computadora en un entorno
determinado y durante un tiempo especificado. La fiabilidad utiliza
funciones para determinar la probabilidad de que ocurra un fallo en el
software, pero la ocurrencia de un fallo no tiene por qu llevar asociado
un accidente.
342 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M TICOS C A P T U L O 15: L A G A R A N T A D E C A L ID A D

( )
La seguridad del software examina de que forma los fallos producen 1) Si este sistema fa lla tina vez a la semana y p o r dicho fallo no est operativo
condiciones que pueden llevar a accidentes. El anlisis del rbol de durante 3 horas (tiempo de solucin del problema), calculamos:
fallos es un modelo grfico para determinar los estados del sistema ( ,
peligrosos que pueden conducir a accidentes. Una vez estudiados los Tiempo medio entre fallos: <
riesgos se debe crean una lista adicional de requerimientos diciendo lo 90 = 87 (horas funcionando hasta un fallo) + 3 (horas de resolucin del fallo) (
que NO debe de suceder para garantizar la seguridad del sistema. Existe
otra disciplina que puede llevarnos a error que es la seguridad entendida Disponibilidad:
como privacidad y proteccin de la informacin. 96 65% = 100 * (87 / 90)

Debemos establecer, antes de continuar, la definicin de fallo. Qu es un 2) Si falla dos veces a Ici semana con los mismos tiempos, calculamos:
fallo?: Un fallo es cualquier falta de concordancia con los requisitos del ( ,
software. Cmo son los fallos?: Los fallos tienen un amplio abanico de Tiempo medio entre fallos: ( , \
posibilidades: de leves a graves, desconcertantes o catastrficos, de correccin 45 = 42 (horas funcionando hasta un fallo + 3 (horas de resolucin del fallo) < . )I
inmediata con pequeo esfuerzo o con necesidad de mucho tiempo y un gran
esfuerzo. Hay que tener en cuenta, adems, que la correccin de un fallo puede Disponibilidad:
producir nuevos fallos con bastante probabilidad. 93 35% - 100 * (42 /4 5 )________________________________

Una forma de medir los fallos del software son los modelos de fiabilidad
del software. La mayora de los modelos de fiabilidad relativos al hardware son
debidos al desajuste que a fallos de diseo o al desgaste de los componentes
fsicos y no sirven para el software donde ocurre lo contrario. Los modelos de
fiabilidad del software predicen la fiabilidad en funcin del tiempo de
calendario o en funcin del tiempo de CPU. Una sencilla medida es el tiempo
medio entre fallos que es la suma del tiempo medio de fallo ms el tiempo
medio de reparacin de ese fallo:
TMEF=TMDF+TMDR
Por ltimo sealar que algunas mtricas de calidad se basan en el coste de (
calidad, que es aquel que se deriva de las actividades relacionadas con la (
calidad. De este coste forman parte los costes preventivos (establecimiento y (
seguimiento del plan de calidad, formacin, medios, etc.), de evaluacin
(revisiones, inspecciones, pruebas, etc.) y de fallos (anlisis de errores y
reparacin, litigios con el cliente, soporte on-line, etc.). Dentro del coste de !
calidad debido a fallos, es importante analizar y distinguir el coste debido a '
fallos antes de la implantacin y posteriores a la implantacin, cuando el <
producto est funcionando en el cliente.

Con el mismo criterio podernos definir la disponibilidad del software como (

funcin del tiempo medio entre fallos y el tiempo total (calendario o CPU). 15.5 EST N D A R E S DE CALIDAD D EL SO FTW A R E <
i
100*TMDF /(TMDF+TMDR) La evolucin de la economa en estos ltimos aos se ha desarrollado ,
ampliando los mbitos de competencia entre las empresas. Las certificaciones
Ejemplo y acreditaciones de calidad se hacen imprescindibles en este contexto,
controlando que empresas cumplen con el nivel de calidad que dicen ofrecer.
Vamos a calcular el tiempo medio entre fallos y la disponibilidad para un
ejemplo de funcionamiento de un sistema. El uso de la serie de Normas Internacionales ISO 9000 (en Espaa UNE (
66900) abarca a casi 100 pases y comprende las siguientes normas: (
Supongamos que un sistema funciona 5 das a la semana, 18 horas cada da, i
tendr un tiempo de funcionamiento de 90 horas semanales (18*5). ISO 9000 (UNE 66-900). Normas para la gestin y el aseguramiento de ^
la calidad
(
(
(
344 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
ISO 9001 (une 66-901). Sistemas de calidad. Modelo para el
aseguramiento de la calidad en el diseo, desarrollo, produccin,
instalacin y servicio post-venta.
ISO 9002 (UNE 66-902). Sistemas de calidad. Modelo para el
aseguramiento de la calidad en la produccin y la instalacin.
ISO 9003 (UNE 66-903). Sistemas de calidad. Modelo para el
aseguramiento de la calidad en la inspeccin y los ensayos finales.
ISO 9004 (UNE 66-904). Gestin de la calidad y elementos de un
sistema de calidad.
Dentro de la ISO 9000 hay que destacar su tercera parte que afecta
directamente a la calidad del software. Es la ISO 9000-3: Gua para la
aplicacin de la norma ISO 9001 al desarrollo, suministro y mantenimiento del
software. Esta norma crea un marco de referencia a la calidad del software
estableciendo criterios sobre las responsabilidades de la direccin del cliente y
del suministrador, la elaboracin y mantenimiento de un plan de calidad
integrado durante todo el ciclo de vida del software, la realizacin de auditorias
internas y la elaboracin y mantenimiento de acciones correctoras.
La ISO 9000-3 establece los criterios a seguir en las siguientes actividades
del ciclo de vida del software:
Revisin de contratos.
Especificacin de requisitos del cliente.
Planificacin del desarrollo.
Definicin del plan de calidad.
Diseo e implementacin.
Pruebas de validacin.
Aceptacin.
Entrega e instalacin.
Mantenimiento.
Adems establece criterios a seguir en las siguientes actividades de apoyo
del ciclo de vida del software:
Gestin de la configuracin.
Control de la documentacin
Registros de calidad.
C A P T U L O 15: L A G A R A N T A D E C A L ID A D 345
Medicin de la calidad de! producto y del proceso.
Reglas, prcticas y acuerdos para aplicar la norma ISO 9000.
Herramientas y tcnicas para hacer efectiva la norma en la gestin y el
desarrollo.
Garanta de las compras.
Productos software suministrado por el cliente.
Necesidades de formacin respecto a calidad.
La norma ISO 9000-3 hace referencia, adems de las ya mencionadas, a
las siguientes:
ISO 2382/1. Trminos fundamentales del tratamiento de datos.
ISO 8402. Vocabulario de calidad.
ISO 10011-1. Reglas para las auditorias de sistemas de calidad.
Dentro del entorno espaol, debemos citar las siguientes leyes que afectan
a la calidad del software:
Ley de Regulacin del Tratamiento Automtico de Datos de carcter
personal (LORTAD 5/92).
Ley de Proteccin Jurdica de Programas de Ordenador (16/93).
Ley de Ordenacin de las Telecomunicaciones (LOT 31 /87).
15.6 PLAN DE CALIDAD DEL SOFTWARE
El estndar IEEE 730-2002 describe la preparacin y contenidos del Plan de'
Calidad del Software. Este plan debe servir de gua a las actividades de los
sistemas de gestin de calidad el software en todas las fases de su ciclo de vida.
El Plan de Calidad del Software es un documento que recoge las formas de
operar los recursos y la secuencia de actividades ligadas a la calidad que se
refieren a un determinado producto, servicio, contrato o proyecto. Este plan lo
desarrolla el equipo de gestin de calidad del software.
El equipo de gestin do calidad del software estar formado por los
desarrolladores que llevan a cabo tareas tcnicas, los responsables de la gestin
de los proyectos software y por personal tcnico especializado en calidad del
software que ayudar a definir y medir la calidad. Este equipo, adems de
establecer el Plan de Calidad, participar en el desarrollo de la descripcin del
proceso de calidad dentro del proyecto software, revisar que las actividades
346 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
definidas en el proceso se realizan y que las desviaciones, de haberlas, se
documenten y gestionen segn el proceso predefinido, auditar los resultados
del proceso y registrar y comunicar sus conclusiones, coordinar los cambios
y definir las mtricas de la calidad del software a utilizar, verificando sus
resultados.
Como ya hemos dicho el estndar IEEE 730-2002 proporciona la
estructura de la documentacin del Plan de Calidad de una organizacin de
software. Este estndar est elaborado segn el siguiente contenido:
1. Propsito. Este punto proporciona una visin simplificada del plan.
2. Documentos de referencia. En este punto se determinan estndares,
procedimientos y documentos relacionados.
3. Gestin. En este punto se asignan responsabilidades para cada actividad de
la gestin de calidad, estructura organizativa y responsabilidad del plan. En
detalle:
3.1 Organizacin.
3.2 Tareas.
3.3 Roles y responsabilidades.
3.4 Recursos estimados de garanta de calidad.
4. Documentacin. En este punto se describe la documentacin que se va a
generar en el proceso y, para cada documento, se indica el objetivo del
documento, la plantilla, norma y/o estndar que se usa para elaborar el
documento y el contenido mnimo que debe tener dicho documento. En detalle:
4.1 Propsito.
4.2 Requisitos mnimos de documentacin.
4.3 Otra documentacin.
5. Estndares, prcticas, convenciones y mtricas. En este punto se hace
referencia a los estndares de documentacin, de diseo, de prueba, etc. y se
describe para cada propiedad de calidad identificada, las mtricas que se
utilizarn para medir dicha propiedad de calidad. En detalle:
5.1 Propsito
5.2 Contenido
C A P T U L O 15: LA G A R A N T A DE C A L ID A D 347
6 . Revisiones del software. En esta seccin se definen los tipos de revisiones,
sus objetivos y mecanismos. En detalle:
6.1 Propsito
6.2 Requisitos mnimos
6.3 Otras revisiones y auditorias
7. Pruebas. En este punto se identifican y detallan las pruebas no incluidas en el
plan de verificacin y validacin.
8 . Informe de errores y acciones correctoras. En este punto se indica como se
reportarn los problemas encontrados y se har su seguimiento.
9. Herramientas, tcnicas y metodologas. En este punto se describen las
herramientas, tcnicas y metodologas utilizadas como soporte del proceso de
calidad.
10. Control de medios. En este punto se define la gestin del medio fsico de
cada producto software.
11. Control de proveedor. En este punto se define el control de calidad del
softw'are proporcionado por proveedores externos.
12. Coleccin de registros, mantenimiento y conservacin. En este punto se
define el histrico de documentacin de cada proceso.
13. Formacin. En este punto se determina la formacin necesaria del equipo
involucrado en la gestin de calidad.
14. Gestin del riesgo. En este punto Se indican los mtodos a utilizar para
identificar y controlar los riesgos identificados en el proyecto y las actividades
a realizar para cumplir este objetivo.
15. Glosario. En este punto se incluye un diccionario de trminos y
abreviaturas utilizadas.
16. Procedimiento de cambio e historial del plan de calidad. En este punto se
establece el procedimiento de modificacin del plan y sus versiones.
348 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
15 .7 MODELOS DE M ADUREZ
Los denominados modelos de madurez sirven para comparar nuestra
organizacin con la competencia y decidir si queremos avanzar o por el
contrario detenernos en cierto nivel de madurez. La madurez de un proceso es
un indicador de la capacidad para construir un software de calidad. En
concreto, existen 5 niveles de madurez, estos son:
Modelos de Madurez Genricos
Nivel 0: No existente. La organizacin no reconoce que existe un problema.
Nivel i: Inicial. La organizacin reconoce la existencia de un problema que
necesita ser tratado, pero se dan soluciones a medida y desorganizadas. La
empresa no dispone de procesos y controles definidos. Las tcnicas y
herramientas que se emplean para el desarrollo del software carecen de
integracin entre ellas y/o nicamente se emplean en alguna fase del ciclo de
vida. No hay control de la Gestin del Proyecto de una forma efectiva.
Nivel 2: Repetible. Se establecen procedimientos que siguen el personal, pero
no hay una formacin y comunicacin adecuada. La empresa tiene medios
estandarizados facilitando procesos repetibles. El problema de este tipo de
organizaciones es que introducir cualquier cambio tiene un alto grado de riesgo
al fracaso ya que no sirven los datos estadsticos de otros proyectos si se
cambia el tipo de sistema a desarrollar o si se introducen nuevas herramientas o
mtodos por afectar al proceso.
Nivel 3: Definido. Los procedimientos se estandarizan, se establece un
mecanismo de comunicacin, se forma y entrena al personal, aunque los
procedimientos no son complejos y no se detectan los posibles errores. Estas
empresas disponen de una metodologa de desarrollo de software que describe
las actividades tcnicas y de gestin requeridas para la adecuada ejecucin del
proceso.
Nivel 4: Gestionado. Se puede medir que los procedimientos se cumplan y
tomar acciones correctoras si existieran errores. Continua mejora de los
procedimientos. El proceso es medido y controlado cuantitativamente y est
implementado en toda la organizacin. La organizacin marca objetivos de
calidad cuantitativos. Estas medidas sirven para evaluar los procesos y
productos de los proyectos y, por tanto, la calidad del software es predecible
(alta calidad).
__________________________________ C A P T U L O 15: l.A G A R A N T A D E C A L I D A D _______ ____________ 349
Nivel 5: Optimizado. Los procedimientos estandarizados se convierten en las
mejores prcticas posibles que se adaptan rpidamente a los cambios internos e
externos de la organizacin. Existe una evolucin continua en la optimizacin
del proceso. Se proporcionan medios para estimar debilidades y reforzar el
proceso activamente. Se analizan los defectos y lo aprendido se aprovecha en
otros proyectos. Se mejora por avances incrementales y por la utilizacin de
nuevas tecnologas y mtodos.
El Modelo de Madurez (www.sei.cmu.edu/cmm) o CMM (Capability
Maturity Model) se ha convertido en un estndar para las organizaciones, que
les permite medir e incorporar mayores niveles de eficiencia en sus procesos de
desarrollo y mantenimiento del software a travs de las mejores prcticas del
mercado. Los procesos de produccin del software deben convertirse procesos
disciplinados y aceptados por todos. Esto es lo que mide CMM. Pero CMM no
es solo una lista de comprobacin, no es solo evaluacin sino tambin mejora
de procesos.
Como se ve en la figura 15.4 CMM utiliza los niveles de madurez
explicados anteriormente y establece las condiciones de paso de un nivel a otro
en una organizacin.
EN OPTIMIZACION
Control del proceso
GESTIONADO
- .Medicin del proceso
DEFINIDO
Definicin del proceso
REPETIBLE
Control bsico de gestin
INICIAL
Figura 15.4 Niveles de madurez del CMM.
El propsito de CMM es guiar a las organizaciones de software en la
seleccin de estrategias de mejora determinando la madurez del proceso actual
e identificando los puntos importantes sobre los que trabajar para aumentar la
madurez (mejora) del proceso y, por tanto, la calidad del producto obtenido.
Segn Mark C. Paulk del Software Engineering Institute (Camegy Mellon
350 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 15: LA G A R A N T A DE C A LID A D 351

University) CMM es una aplicacin de sentido comn de los conceptos de
gestin de procesos y mejora de la calidad al desarrollo y mantenimiento del
software.
Podemos distinguir una organizacin de software inmadura por las
siguientes caractersticas:
Los procesos se improvisan.
Los procesos establecidos no se siguen.
Poco dispuesta al cambio.
Se centra en resolver crisis inmediatas.
La programacin y el presupuesto de los proyectos se exceden
generalmente.
No hay bases para juzgar la calidad del producto y problemas en el
proceso.
Si hay plazos rgidos, se sacrifican funcionalidad y calidad del producto
para satisfacer el plan.
Cuando los proyectos est fuera de plan, las revisiones o pruebas se
recortan o eliminan.
Por otra parte, una organizacin madura, o con un nivel de madurez
considerable, tendr las caractersticas siguientes:
Se controlan la calidad de los productos y la satisfaccin del cliente.
Se realizan anlisis cuantitativo sobre el producto y el proceso.
Los presupuestos y programaciones se basan en datos histricos
(reales).
Normalmente se cumplen las estimaciones.
Se desarrollan habilidades para gestionar el desarrollo de software y los
procesos de mantenimiento.
El proceso se comunica de forma precisa a los trabajadores y nuevos
empleados.
Los procesos se actualizan y se controlan las mejoras.
Los roles y responsabilidades estn claras.
El CMM se centra en tres aspectos, que son los que influyen en el producto
software: las personas, la tecnologa y el proceso; y en cuatro conceptos base
que ayudan a la organizacin a comprender y adaptarse al nuevo
planteamiento:
Es posible distinguir etapas de distinta madurez en el proceso;
Hay cosas que deben ser aplicadas antes que otras para mejorar la
madurez del proceso;
La madurez disminuir, a menos que se mantenga, es decir, conservar
el mismo nivel de madurez requiere un esfuerzo permanente.
La evaluacin de una organizacin como adecuada a un nivel de CMM se
basa en los niveles de madurez descritos, en las reas claves de la organizacin
y, para cada una de ellas, sus caractersticas y sus prcticas comunes, segn
muestra la figura 15.5.
indican Capacidad
del proceso
alcanzan
se aplican /implementacin oN
Vlnsttucionallzaciri
describen Infraestructura
o actividades
Figura 15.5 Proceso de evaluacin del CMM.
Segn Gartner, CMM puede aportar un 10 por ciento de ahorro en costes
de produccin, un 145 por ciento de mejora en las desviaciones de plazo de los
proyectos o un 15 por ciento de reduccin de errores en el producto terminado.
No obstante, pocas compaas pequeas o medianas se han embarcado en
proyectos de CMM. Segn la consultora Profit Gestin Informtica solo 1.300
entidades a escala mundial se encuentran certificadas en algn nivel de CMM.
Las figuras siguientes, 15.6 y 15.7, muestran respectivamente los porcentajes
de participacin de las organizaciones de software geogrficamente en los
procesos de certificacin de CMM y los resultados obtenidos por niveles
(fuente SEI).

La evolucin lleva tiempo;

35 2 P L A N IF IC A C I N Y G E S T I N DE S IS T E M A S IN F O R M T IC O S C A P T U L O 15: LA G A R A N T A DF. C A L ID A D 353

C an ad y
El nuevo modelo CMMI ofrece un marco comn para todas las disciplinas
Sudam rica y agrega una nueva forma de representacin adems de la conocida
2% representacin por niveles. La nueva forma de representacin se llama
Asia y
Continua y est orientada a medir la mejora en los procesos de manera
Pacifico Sur
3 1%
individual en vez de hacerlo de manera conjunta como la representacin por
niveles.
Europa
A sia y 5 6% Dentro de esta nueva generacin de modelos, el sucesor directo del CMM
Pacfico original es el denominado CMMI-SW. Este modelo presenta una mayor
Norte cobertura con respecto a las reas de proceso, y agrega el concepto de
10% representacin continua. Los nombres de algunos niveles establecidos por
CMMI cambian respecto a los del modelo CMM; ahora el nivel 2.Repetible
Figura 15.6 Participacin el los procesos de certificacin CM M en el ano ha pasado a denominarse 2.Gestionado'; y el nivel 4.Gestionado se
2000. denomina 4. Cuantitativamente gestionado.

El SEI (Software Engineering Instlate) ha publicado recomendaciones

para pasar fcilmente de CMM a CMMI, y ha previsto que las empresas de
Nivel 4
software que haban adoptado CMM, tengan implantado CMMI en 2005.
Adems, en paralelo con el desarrollo de CMMI, el SEI ha elaborado un
mtodo para la evaluacin formal del modelo denominado SCAMPI (Mtodo
de evaluacin Estndar de CMMI para la Mejora de Procesos, en ingls
Standard CMMI Appraisal M ethodfor Process Improvement).

En relacin con CMM y CMMI, es conveniente resaltar que en el mbito

Nivel 1 europeo tambin se han generado recomendaciones para mejorar la madurez de
51%
la capacidad del proceso software de las organizaciones. As, en 1998 se
Figura 15.7 Porcentajes de niveles de certificacin CMM alcanzados en el ao public la norma ISO 15504, conocida como SPICE (Software Process
2000 . Improvement and Capability Determination) que, como CMM, tambin
establece niveles de capacidad del proceso; estos niveles se asemejan a los de
CMM, y se denominan:
El estndar CMM ha evolucionado hacia un nuevo modelo denominado
CMMI1 (Capability Maturity Model Integration), publicado en 2002, que trata Nivel 0: No Realizado
de integrar el CMM con otros modelos similares establecidos para otras Nivel I: Realizado informalmente
disciplinas diferentes de la ingeniera del software (el CMM original suele Nivel 2: Planificado y Seguido
denominarse tambin SW-CMM), como son la ingeniera de sistemas (SE- Nivel 3: Bien Definido
CMM: System Engineering CMM), el desarrollo integrado de productos (IPD- Nivel 4: Controlado
CMM: Integrated Product Development CMM), la adquisicin de productos - Nivel 5: Mejorando Continuamente
software (SA-CMM: Software Adquisition), o la gestin de personal (P-CMM:
People CMM). Existen herramientas de ayuda para la implantacin de los modelos de
madurez anteriores. En el caso de CMM o CMMI, algunas de las que permiten
efectuar evaluaciones de acuerdo con estos modelos son: CMM-Quest, IME

1 La especificacin completa de C M M I se encuentra en la direccin mvw.sci.cmu.edu/cmm i.

354 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 15: L A G A R A N T A D E C A L ID A D 355

Toolkit, y Appraisal Wizard. La ltima tambin ofrece soporte para el mtodo

SCAMPI. Varias organizaciones de normalizacin, como ISO o ANSI3, han
establecido la necesidad de tratar la gestin documental como un proceso ms
de los que componen el ciclo de vida del software, encargado de documentar
15.8 LA D O C U M E N TA C IO N EN LA G E ST IO N DE C ALID A D los resultados obtenidos en el resto.
D EL SO F T W A R E .2

Segn dicen los expertos en el rea de la Ingeniera del Software (vase la obra Solicitud de propuestas
Plan de gestin config
de Sommerville), a lo largo de la historia, el mantenimiento del software se ha Adquisicin
^ w
D
iorrador del contrato identificacin versiones G e s t i n d e
dificultado mucho como consecuencia de la deficiente documentacin del ^ W C o n fig u r a c i n
Inform es de estado
diseo. Por tanto, realizar una documentacin tcnica de calidad sobre el
proceso y el software obtenido ser tan importante como la propia calidad de
Propuesta
0 ^ W

c
M anual de procedimiento s
este software. Suministro Contrato ^
^ fe W C a lid a d
M anual de calidad

Por lo cual, se requiere mejorar los aspectos relativos a la gestin

documental y de la gestin de configuracin en los proyectos de desarrollo.
Estndares u ^ p.

Informe de verificacin

Para mejorar la gestin documental existen algunas propuestas, aunque son

Requisitos
m ^
^
informe de validacin
fe,
W V e rific a c i n

e
Especificaciones ^ fe,
p
pocas, sobre el tratamiento documental en la Ingeniera del Software. Estas V a lid a c i n

propuestas, empiezan ahora a ser consideradas por las organizaciones que M anual de usuario Informe de auditoria

desean mejorar la calidad de los productos desarrollados, y competir en un

Desarrollo
anual de explotacin nn ------------------------------ A u d ito ria

mercado dominado, en la actualidad, por la exigencia a las organizaciones del Doc.resolucin problemas

cumplimiento de estndares de calidad que permitan confiar en los resultados

nformes de pruebas

Cuadernos de carga
t R e s o lu c i n de
p r o b le m a s
de los proyectos de software.
Plan d e desarrollo a Plan de gestin proyecto
El inters por la calidad ha sido un hecho constante en toda la historia de la
evolucin de la ingeniera del software. A finales de los aos ochenta este
etodologia desarrollo
c 4------------------------------
Plan de gestin del riesgo G e s t i n
nformacin de errores

^ W1
inters experiment un gran auge como consecuencia de la aparicin de la |Operaci~ 1 Definicin infraestructura
normativa internacional de calidad industrial propuesta por ISO. Con la llegada an de mantenimiento
w
^
^
fe
W In fr a e s t r u c

de la serie ISO 9000 en 1987, todos los sectores industriales sufrieron una
revolucin en sus procesos de trabajo a travs de los sistemas de calidad
iforme d e problemas O Informes d e mtricas sw
tu ra

basados en estas normas. El desarrollo y el mantenimiento de software no Manteni

forme de codificacin

riterios evaluac.modif
n <. ------------------------------ M e jo ra

quedaron al margen de esta poderosa corriente, si bien, debido a la peculiar miento Material de formacin

naturaleza del software, requiri la creacin de una norma especfica de Plan de migracin <. ------------------------------ F o r m a c i n |

aplicacin, la ISO 9000-3. Con la aparicin de esta norma, llegaron las
auditorias de sistemas de calidad, las certificaciones, etc. ISO 9001, considera
una adecuada documentacin lo fundamental para garantizar la calidad.
La documentacin en los proyectos software es de suma importancia, esta
importancia se pone de manifiesto por tratarse del elemento integrador de los
diferentes aspectos de un proyecto software (segn Ayer y Patrinnostro).
Plan retirada software
Figura 15.8 Procesos y algunos de los documentos implicados en el ciclo de
vida de! software segn ISO.
En la figura 15.8 se muestran los procesos y algunos documentos
implicados en el ciclo de vida del software segn ISO en su norma 12007, para

2 Parte de esta seccin es un resumen de nuestro trabajo: "SfV Documentation as an 3 Vanse referencias bibliogrficas en de la normas ISO 12207 (1996), ISO 9126 (1991) e ISO
E ngineering Process", publicado en la revista del ACM SIGSoft, Software Engineering Notes. 9001 (2000) para obtener informacin ms detallada.
356 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P TU LO 15: LA G A R A N T A D E C A L ID A D 357

poder ver mejor la complejidad y la importancia de la documentacin en los

proyectos de software.

Si observamos la figura, podemos apreciar el protagonismo que tiene la

documentacin en todos los mbitos de un proyecto. Tambin se puede
apreciar que es la ms descuidada por las organizaciones dedicadas al
desarrollo de software.

Dos organizaciones de normalizacin, ISO y ANSI han establecido la

conveniencia de considerar un proceso de documentacin diferente del resto de
procesos del ciclo de vida del software, y lo descomponen en una serie de
actividades que consideran necesarias para llevarlo a cabo.

Las recomendaciones de ISO y ANSI establecen que el proceso de

documentacin sea un proceso de ingeniera, durante el cual se realice la
planificacin, diseo, produccin y mantenimiento de los documentos
necesarios para el desarrollo del software.

Dada la importancia de la documentacin se considera, actualmente, un
nuevo aspecto en la ingeniera del software: la ingeniera de la documentacin
del software. Por ingeniera se entiende el conjunto de mtodos, tcnicas y
herramientas para el diseo, construccin y utilizacin de productos diversos,
tambin la produccin de la documentacin, que contiene la informacin
necesaria para el mantenimiento de un proyecto de desarrollo de software,
debera abordarse como si de un proceso de ingeniera se tratara; realizando, en
primer lugar, un anlisis riguroso de las necesidades documentales para,
posteriormente, proceder a la definicin y diseo de los documentos
identificados; despus a su construccin, posteriormente a la preparacin para
su recuperacin y, finalmente, a su explotacin en el seno de la organizacin.
En este sentido, las tcnicas documentales, se ajustan a normativa
internacional como Z39.58-1992, estndar ISO de 1992, como lenguaje comn
para la recuperacin de la informacin en lnea.
La Ingeniera de la Documentacin de! Software se debe fundamentar en
una metodologa de desarrollo de documentos que establezca, por una parte, el
ciclo de vida compuesto por las fases y etapas que constituyen el proceso
documental y, por otra parte, el conjunto de tcnicas que debern aplicarse en
cada una de las actividades del ciclo de vida.
En la figura siguiente (figura 15.9) se muestra el ciclo de vida establecido
para los documentos, basado en las recomendaciones de ISO y ANSI.
Figura 5.9. Fases de! ciclo de vida de a documentacin del software.
Las cinco fases del ciclo de vida, a su vez, se dividen en una serie de
etapas durante las cuales se deberan llevar a cabo las tareas que, de forma
conjunta, garanticen un completo tratamiento de los diferentes aspectos de
gestin de los documentos implicados en un proyecto. El objetivo de cada una
de estas fases es el siguiente:
Planificado de la documentacin: El objetivo de esta fase es el estudio de las
necesidades de documentacin del proyecto de software que se vaya a
desarrollar, elaborando un Plan de Documentacin que establezca, entre '
otros, el tipo de documentos a elaborar, la tecnologa que se utilizar y la
secuencia de operaciones para la produccin y distribucin de los documentos,
y para la construccin del lenguaje documental que se utilizar durante su
indizacin. Este plan ser el punto de partida de la siguiente fase, la de diseo.
La secuencia de actividades a realizar durante la fase de planificacin es la
siguiente:
1) Identificar las necesidades de documentacin;
2) Definir los documentos y sus relaciones;
3) Establecer la organizacin documental;
4) Elaborar el Plan de produccin y distribucin de documentos;
5) Elaborar el Plan de construccin del lenguaje documental;
6) Estudiar diferentes alternativas tecnolgicas.
358 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 15: L A G A R A N T A D E C A L ID A D 359

identificando los trminos de indizacin que facilitarn su localizacin para

Diseo de Ia documentacin: Una vez establecido en el plan anterior el modo consultarlo o modificarlo. La secuencia de actividades a realizar durante la fase
en que se llevar a cabo el proceso de documentacin, se procede a la de indizacin es la siguiente:
descripcin, en forma de diferentes modelos conceptuales, de todos los
aspectos necesarios para la produccin de cada uno de los documentos, desde I) Examinar los documentos;
los relativos a su estructura interna, hasta los referentes a las caractersticas de 2) Identificar los conceptos de los documentos;
su presentacin a la audiencia, pasando por otro tipo de especificaciones, por 3) Seleccionar los trminos de indizacin;
ejemplo, de tipo hipermedial. Tambin ser objeto de esta fase la revisin del 4) Establecer hiper-enlaces (indizacin asociativa);
Plan de Documentacin, ahora que se dispone de una informacin ms 5) Validar los ndices producidos.
detallada sobre los documentos a producir. La secuencia de actividades a
realizar durante la fase de diseo es la siguiente: Explotacin y mantenimientos de la documentacin: Esta ltima fase de la
metodologa contempla la utilizacin de cada documento para explotar su
7) Disear la estructura de los documentos; contenido durante la realizacin de determinadas actividades de desarrollo de
8) Disear el comportamiento dinmico de los documentos4; software5. Para ello, se llevar a cabo una difusin, o puesta a disposicin del
9) Incorporar aspectos hipermediales en el diseo; personal que la necesite, de la informacin contenida en ellos. Tambin se
10) Disear la presentacin de los documentos; deben contemplar las actividades relacionadas con la introduccin controlada
11) Revisar el plan de produccin y distribucin de documentos. de modificaciones en los documentos y con su destruccin por obsoletos, o su
almacenamiento en un archivo para formar parte del patrimonio documental de
Produccin de la documentacin: El objetivo de esta fase es la generacin de la organizacin. La secuencia de actividades a realizar durante esta ltima fase
los diferentes documentos segn el diseo anterior. Cada documento ser es la siguiente:
elaborado con la informacin producida durante una o varias actividades del
ciclo de vida del software y servir de punto de partida para otras actividades 1) Difundir y explotar los documentos;
del proyecto. Durante esta fase, en base al contenido que se registre en cada 2) Realizar el mantenimiento de los documentos;
documento, tambin se construir el lenguaje documental que ser utilizado en 3) Archivar o eliminar documentos.
la siguiente para la indizacin de los documentos. La secuencia de actividades
a realizar durante la fase de produccin es la siguiente:

1) Preparar el entorno de produccin;

2) Producir y revisar los documentos;
3) Construir el lenguaje documental;
4) Liberar (publicar) los documentos.

Indizacin de la documentacin: Para facilitar el trabajo del personal implicado

en el desarrollo de software, que constantemente necesitar consultar
documentos elaborados anteriormente en el seno del proyecto (por ejemplo, un
programador consultar los documentos de diseo, un diseador los de anlisis,
etc.), se incluye esta fase en la metodologa, con el propsito de llevar a cabo
un anlisis del contenido de cada uno de los documentos producidos,

4 Ver el artculo "Generacin de Autmatas para el Control del Comportamiento Dinmico de

los Documentos Partiendo de sus Diagramas de Estado" publicado en las actas de las III 5 Michael J.D. Sutton, en su monografa "Documenl Management for the Enterprise", ofrece un
Jomadas Nacionales de Informacin y Documentacin Empresarial INDOEM'96. excelente material para la planificacin, construccin y mantenimiento rpido de sistemas
automticos de gestin de documentacin.
360 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S

CAPTULO 16

ORGANIZACION Y CONTROL DE UN
PROYECTO

Al llegar a este apartado el lector ya estar suficientemente familiarizado con el

mundo de los proyectos informticos y es ahora cuando va a aprender otros
aspectos de esta apasionante actividad: La organizacin del grupo de trabajo,
su estructura, el liderazgo y otros aspectos como la seleccin de recursos y la
asignacin de los mismos a las diferentes tareas son aspectos de gran
importancia.

La planificacin constante es la funcin principal de todo directivo y en

especial en los sistemas informticos:

por los continuos cambios;

por la dependencia del resto de la empresa;
por la importancia de las repercusiones en otros sectores;
por las graves consecuencias de ja ausencia de planificacin.

La planificacin es un proceso cclico y continuo, que comprende no slo

la elaboracin peridica de planes sino tambin su revisin peridica y
evaluacin. Pero es, sin ningn lugar a duda, la designacin del equipo humano
quien ms directamente puede incidir en el xito del proyecto y en especial su
Director. El Director debe de poseer, adems de un amplio y demostrado
conocimiento tcnico, una capacidad para asegurar unas relaciones humanas
adecuadas que permita que los dems miembros del equipo de trabajo se
sientan motivados.

En este captulo trataremos de:

Describir distintos tipos de participantes y la estructura de los grupos de

trabajo.
362 P L A N IF IC A C I N Y G E S T I N DE S IS T F ,M A S IN F O R M T IC O S
Describir la estructura del proyecto y cual es la estructura ms adecuada
para cada tipo de problema.
Introducir el Modelo de Madurez (CMM) para la gestin del personal.
Definir las actividades de seguimiento y control de proyectos
16.1 ESTRUCTURA DE LOS GRUPOS DE TRABAJO
El estudio, anlisis, desarrollo y mantenimiento del software y, en general, de
sistemas de informacin, en definitiva, las tareas que forman parte de un
proyecto informtico, no suelen realizarse de forma individual. Se ha pasado a
la gestin de la informacin de forma manual o con desarrollos artesanales a la
ingeniera de sistemas y la ingeniera del software. El trabajo de los
componentes de un proyecto informtico tiene una gran parte de trabajo en
equipo. Algunos autores llegan a considerar que la media de tiempo dedicado a
la interaccin con otras personas es del cincuenta por ciento del tiempo total de
trabajo en un proyecto informtico.
Por tanto, teniendo en cuenta la importancia del trabajo en equipo en los
proyectos informticos, el gestor de proyecto tiene, como tarea fundamental,
crear equipos que funcionen y crear buenas relaciones de comunicacin entre
ellos, con otros equipos y con l mismo. Para establecer los equipos de trabajo
eficientes debemos tener en cuenta la cantidad y tipologa de sus miembros, el
tipo de estructura del propio equipo y el entorno donde va a desarrollar su
trabajo.
Respecto a la cantidad y tipologa de sus miembros, dentro de un equipo
de trabajo tendremos el jefe de equipo, profesionales informticos de distintas
reas, usuarios/clientes e, incluso, consultores o profesionales externos. En
principio, el jefe de proyecto debe establecer unas reglas de comunicacin muy
claras entre los distintos tipos de miembros del equipo y procurar que el
personal directamente seleccionado por l tenga caractersticas personales
adecuadas a las tareas que deben desempear dentro del equipo. Caractersticas
como experiencia den el dominio de aplicacin, adaptabilidad y capacidad de
comunicacin son muy importantes. Tambin dentro del mismo equipo se
deberan compensar personalidades orientadas a la tarca y a la relacin. El
nmero ptimo de miembros de un equipo puede variar en cada caso, pero hay
que tener muy claro que el rendimiento de un equipo es inversamente
proporcional a la cantidad de comunicacin que se deba entablar entre sus
C A P T U L O 16: O R G A N IZ A C I N Y C O N T R O L D E UN PR O Y E C T O 363
miembros. Por tanto, el nmero de miembros de un equipo debera estar entre 3
y 8 personas. En caso de necesidad de quipos con mayor nmero de miembros,
sera bueno establecer equipos pequeos, cada uno con un coordinador, y un
equipo de coordinadores responsable de la comunicacin entre equipos.
Es muy importante y decisiva la figura del jefe de proyecto, sus
caractersticas personales, sus habilidades y su capacidad de liderazgo. Este
asunto ya ha sido tratado ampliamente en el captulo 2 .
Respecto a la estructura del equipo, podemos decirla para cada proyecto,
pero en general hay definidas varias estructuras estndar, sus ventajas y sus
inconvenientes. Es responsabilidad del gestor de proyectos utilizar la ms
adecuada en cada caso. Entre estas estructuras podemos distinguir:
Equipos centralizados. A cada miembro del equipo, el jefe de proyecto
le asigna tareas individuales y desconoce las tareas asignadas a los otros
miembros del equipo. La comunicacin se realiza, siempre
directamente con el jefe de proyecto, al que, cada miembro, tiene que
responder del desarrollo sus tareas asignadas. Los miembros del equipo
no participan de decisiones ni planificacin del trabajo. El problema de
este tipo de equipos es la falta de motivacin de sus miembros, al no
sentirse partcipes de un grupo y el riesgo de autoritarismo dentro del
equipo. La figura 16.1 muestra la estructura de comunicacin en este
tipo de equipos:
Jefe de proyecto
F ig u ra 6.1 E q u ip o s centralizados.
Equipos descentralizados. Se asignan tareas a cada miembro del equipo,
pero todos cooperan conjuntamente para el buen desarrollo de las
mismas. La asignacin de tareas y la comunicacin se realiza
 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
conjuntamente por todos sus miembros. Cada equipo elige un portavoz
que se encarga de la comunicacin con los portavoces de los otros
equipos y con el jefe de proyecto. El problema de este tipo de equipos
es la cantidad de tiempo que se debe dedicar a la comunicacin entre
los componentes y con equipos externos y el riesgo de toma de
decisiones lentas y difciles (al ser compartidas a igualdad de
condiciones) y, en algunos casos, ligeras o poco meditadas por falta de
responsabilidad individual. La figura 16.2 muestra la estructura de
comunicacin en este tipo de equipos:
Jefe de proyecto
Portavoz d e equipo ----------------------------- Portavoz de equipo
F ig u r a 6 .2 E q u ip o s d escen tra liza d o s.
Equipos jerrquicos. A cada miembro del equipo, el jefe de equipo le
asigna tareas individuales y se le informa de las tareas asignadas a los
otros miembros del equipo. La comunicacin se realiza, siempre con el
jefe de equipo al que, cada miembro, tiene que responder del desarrollo
sus tareas asignadas. Los miembros del equipo no participan de
decisiones ni planificacin del trabajo, aunque reciben informacin de
la situacin global del jefe de equipo. La comunicacin con el jefe de
proyecto se realiza solamente a travs del jefe de equipo. Este tipo de
equipos es una mezcla de los otros dos tipos, el jefe de equipo debe ser
responsable de motivar a sus miembros y de hacerlos sentirse un equipo
compartiendo xitos y problemas. La figura 16.3 muestra la estructura
de comunicacin en este tipo de equipos:
C A P T U L O 16: O R G A N IZ A C IO N Y C O N T R O L D E U N P R O Y E C T O 365
Jefe de proyecto
Jefe de equipo Jefe de equipo
F ig u ra 16.3 E q u ip o s je r r q u ic o s .
Por ltimo, el entorno donde el equipo va a desarrollar su trabajo es muy
importante, la necesidad de confort fsico de cada miembro es fundamental
para su trabajo individual: luz, espacio fsico, posibilidad de personalizacin
del entorno, etc. Tambin es importante la relacin fsica entre los miembros
del equipo de forma que facilite la comunicacin, todos los miembros deberan
estar cercanos fsicamente y disponer de un lugar cerrado para sus reuniones
informales. El tiempo que los miembros del equipo vayan a estar juntos afecta
al funcionamiento del equipo, ya que deben tener tiempo para la reflexin y el
trabajo individual, pero deben sentirse arropados por su grupo y bien
informados. Otro aspecto a considerar com o entorno de trabajo, son lask
condiciones laborales de los miembros, sueldo, recompensas, horarios,
categoras, condiciones laborales, en general, que si son muy dispares para
trabajos similares pueden provocar malestar, problemas e, incluso, provocar el
fracaso del proyecto.
16.2 ESTRUCTURA DEL PROYECTO
Adems de los modelos de estructura interna de trabajo (equipos) descritos
anteriormente se deben definir las siguientes estructuras organizativas del
proyecto completo dentro de una organizacin superior:
36 6 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Organizacin Funcional: Se trata de lina organizacin jerarquizada con
grupos o departamentos especializados en realizar trabajos sobre temas
concretos. A su vez cada uno de estos departamentos se divide en
secciones que gestionan cada una de las reas de negocio concretas de
que dispone la organizacin.
Matriz organizativa de dependencias: En este tipo de organizaciones
suele existir una doble dependencia funcional y otra dependencia
orgnica que facilita el desarrollo de los proyectos al no tener que
pasar la informacin por las jerarquas existentes para los asuntos
concretos de proyectos en ejecucin. La flexibilidad es la caracterstica
de este tipo de organizaciones.
Grupo de proyecto: En este tipo de organizacin se libera al personal de
otras actividades, para dedicarse a tiempo completo al proyecto durante
su ciclo de vida, y que ser supervisado por el director del proyecto o
algn responsable funcional del mismo.
Organizacin por proyectos: Organizacin que se da en empresas que
apuestan por varios proyectos simultneos y que cada uno de ellos
comporta riesgos importantes. Este tipo de organizacin trata de
configurar pequeas unidades de negocio de tal suerte que cada jefe de
proyecto responde de su propia gestin.
Organizacin por staff: Este tipo de organizacin combina la
organizacin clsica lineal y la funcional. Consiste en que los directivos
disponen de un grupo de asesores (Staff) que no tienen autoridad
directa sobre ningn empleado, slo sobre su grupo de trabajo, siendo
su labor de apoyo tcnico a todo nivel de direccin. Con este tipo de
organizacin se pretende lograr una especializacin y un apoyo
logstico. Se pueden establecer tantos staffs como niveles jerrquicos se
tengan en la organizacin. Es de considerar que se han encontrado
problemas o conflictos entre la autoridad tcnica y la autoridad formal
que en algunas organizaciones han tenido repercusiones importantes.
Por otra parte, los observadores indican una excesiva burocratizacin
debido, sobre todo, a que se refuerza la jerarqua, lo que les hace lentos
a la hora de responder a cambios planteados y haciendo que, en general,
los costes de mantener este tipo de organizacin sean bastante elevados.
Organizacin por comit: en este tipo de organizacin las decisiones se
toman en grupo de forma colegiada entre las personas que forman los
comits que desarrollan determinar funciones concretas dentro de la
C A P T U L O 16: O R G A N IZ A C I N Y C O N T R O L D E U N P R O Y E C T O 367
empresa pero que, a su vez, no forman la totalidad de la organizacin.
Se les atribuye la posibilidad mayor de afrontar problemas sobre todo
porque sus decisiones, debido sobre todo a su forma de elaboracin,
tienen una gran aceptacin entre el grupo de directivos de la empresa,
adems la toma de decisiones suelen ser menos subjetivas por su forma
colegiada. A pesar de este tipo de ventajas tambin presenta algunos
tipos de problemas, debidos fundamentalmente a la prdida de tiempos
en la toma de las decisiones, la excesiva evasin de responsabilidades
y, en muchos casos, se observa la existencia de grupos dominantes que
tratan de imponer su opinin en contra del resto y que hace que, por
tener que llegar a una conclusin, puesta en comn, no se llega a tener
la decisin ptima.
16.3 MODELO DE MADUREZ PARA LA GESTIN DEL PERSONAL
El Modelo de Madurez (CMM) que ya vimos como una medida de la buena
gestin de proyectos software, se ha revisado para aplicarlo como un marco
para la gestin del personal involucrado en el desarrollo software.
Este modelo define las reas clave para una buena gestin del personal,
incluyendo en ellas la forma de reclutamiento y seleccin, la gestin del
rendimiento individual y de grupos, el diseo de la organizacin de los
recursos, la formacin y la contribucin al desarrollo de la carrera profesional,
una buena poltica de retribuciones y el fomento del espritu de equipo.
El modelo consta de cinco etapas:
Inicial. Gestin mnima del personal.
Gestionado. Se establecen polticas y responsables de la gestin y el
desarrollo del personal.
Definido. Se utilizan polticas de personal que vayan de acuerdo con los
objetivos estratgicos.
Predecible. Se establecen mtricas de calidad para la los recursos y sus
competencias.
Optimizado. Se basa en la mejora continua del personal y de la
capacidad organizativa de la direccin.
368 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 16: O R G A N IZ A C I N Y C O N T R O L D E U N P R O Y E C T O

La figura 16.4 muestra grficamente la relacin entre las etapas descritas. Para realizar las actividades de seguimiento contamos con los datos que
genera el proyecto: los entregables de cada tarea, el resultado de las revisiones,
inspecciones y controles de calidad, algunos de ellos con participacin del
N iv e l 5 - O p tim iz a d o cliente, los documento de planificacin de tareas (PERT, CPM, etc.) y de

t Esfuerzo para la mejora coutiuua d e la com petencia

del personal y de la capacidad organizativa

N iv el 4 - G e s tio n a d o

La calidad de la capacidad y la com petencia del

personal se controlan cuantitativam ente
estimacin de esfuerzo (COCOMO; Puntos de funcin, etc.), los vales de
justificacin de horas trabajadas para cada actividad de cada miembro del
equipo de proyecto y la declaracin de utilizacin de recursos materiales en
cada actividad.

Como vemos, disponemos de dos tipos de informacin:

la planificada, de la que disponemos de la versin inicial y de las

e N iv e l 3 - D e fin id o versiones siguientes por replanificaciones realizadas durante el
Estndares sobre com petencias, p u esto s de proyecto;
trabajo y trabajo en grupo

la real, resultado de los flujos de caja, los entregables y la utilizacin de

N iv e l 2 - R e p e t ib lc recursos.
N
E xistencia
xistenci de polticas d e direccin y
desarrollo del personal Las actividades de seguimiento del proyecto nos conducen a conocer las
diferencias entre la situacin real y la esperada (la situacin esperada es aquella
que, de cumplirse, nos conducira al xito del proyecto). Evidentemente un
buen gestor de proyectos no debe solamente conocer estas diferencias sino que
F ig u ra 16.4 E l p e r so n a l en el M o d elo de M adurez (CM M ). debe actuar en consecuencia para corregirlas o, al menos, minimizarlas. El
conjunto de acciones de gestin que realiza el jefe de proyecto a paliar las
-Inicial diferencias entre los resultados esperados y los obtenidos se conocen como
actividades de control.

16.4 SEGUIMIENTO Y CONTROL
Como decamos en la introduccin del captulo, la planificacin de proyectos
es un proceso cclico y continuo, que comprende no slo la elaboracin
peridica de planes sino tambin su revisin peridica y evaluacin. Esta
actividad se denomina seguimiento y control de proyectos.
El seguimiento de un proyecto se realiza analizando la situacin real del
proyecto para comprobar que los costes no sean mayores que los esperados en
cada fase del proyecto, que no existan retrasos en ninguna actividad,
especialmente las crticas y que se cumplan las condiciones de calidad
definidas con el cliente, es decir, que no se dejen de verificar las condiciones
bsicas acordadas (tres vrtices del tringulo de triple compromiso, visto en el
captulo tercero).
La Real Academia Espaola de la Lengua define control como
regulacin, manual o automtica, sobre un sistema, es decir, es un proceso
que utiliza recursos manuales y automticos para conseguir que el proyecto se
realice de forma ordenada y segn lo previsto.
Para un buen control de proyectos, al principio del proyecto se deben
definir estndares que midan la productividad y la calidad de los resultados, se
deben establecer los puntos mnimos y deseables donde obtener informes de
progreso y los entregables que sern objetos de seguimiento. Durante el
proyecto se debe recoger la informacin antes definida y compararla con la
planificacin inicial y los ajustes posteriores realizados en posibles
replanificaciones. Se definir, para cada estndar y punto de control
establecido, los niveles de cumplimiento y las desviaciones. El ltimo paso
37 0 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
ser la decisin y ejecuciones de las acciones pertinentes para corregir las
desviaciones y la documentacin de las mismas.
Las acciones a tomar para corregir las desviaciones pueden incidir sobre la
utilizacin de recursos y modificar la planificacin establecida, procurando que
no afecten a la calidad, el plazo de entrega y el coste del proyecto. Si alguno de
estos tres parmetros debe ser obligatoriamente modificado, es necesario llegar
a un consenso con el cliente y en algunos casos aplicar clusulas especiales del
contrato, corno penalizaciones.
Cuando las desviaciones don tan grandes o tan importantes que peligra el
xito del proyecto hablamos de crisis del proyecto. En estos casos las acciones
de controla a tomar pueden ser drsticas, pero siempre definidas en el tiempo.
No es posible intentar resolver una crisis dando un plazo de tiempo
indeterminado. Si la crisis dura ms de un tiempo limitado (puede ser un mes,
pero depende del tiempo total del proyecto) sera conveniente estudiar de
nuevo la viabilidad del proyecto.
Las acciones correctivas que se pueden tomar en una crisis pasan por la
comunicacin oficial de la crisis a todo el equipo, explicando la situacin,
posibles causas y las acciones a tomar. Una vez informado oficialmente todo el
equipo es ms fcil contar con su colaboracin. La mayora de las acciones
correctivas tiene que ver con la gestin de recursos, nueva contratacin,
aumento de horas de trabajo del personal existente, reasignacin de puestos,
establecimiento de prioridades en las tareas, etc. Una vez resuelta la crisis, en
un plazo mximo establecido, la situacin debe volver a la normalidad,
asignado de nuevo recursos y prioridades.
Siempre se debe establecer un seguimiento y control especial en las
ltimas fases del proyecto, ya es conocido el hecho de que la mayora de los
proyectos avanzan con normalidad hasta completar el 90%, mientras que el
10% restante se detiene y llega a ser hasta un 40% del nuevo total en coste y en
tiempo.
Es muy importante para el buen desarrollo del proyecto que las acciones
de seguimiento y control se realicen sobre las actividades del proyecto, no
sobre el personal del proyecto. Hay que controlar lo que se hace no al que lo
hace. Es importante difundir la informacin entre el personal y hacerle
partcipe del xito o fracaso del proyecto, estableciendo el punto justo entre
recompensa y disciplina.
CAPTULO 17
PROYECTOS ESPECIALES DE INGENIERA
DEL SOFTWARE
Este apartado, casi final, pretende acercar al lector a algunos proyectos
informticos especiales por su importancia. Esta importancia puede estar dada
por varios factores, como pueden ser:
La cantidad de proyectos de este tipo que se llevan a cabo;
Su larga duracin y/o alto coste;
Su importancia estratgica dentro de los Sistemas de Informacin
Empresarial;
Su novedad o actualidad;
Las importantes ventajas que aportan a los Sistemas de Informacin;
K
Trataremos tres tipos de proyectos, que hemos denominado especiales, lo
largo de este tema. En primer lugar hablaremos de los proyectos de
reingeniera del software y de ingeniera inversa como solucin para el
mantenimiento del software y mejora de los sistemas informticos,
detenindonos en un tipo particular de reingeniera, no de software, sino de
procesos, situndola como paso previo a la implantacin o actualizacin de un
sistema de informacin. Tambin hablaremos de los repositorios como centro
de operaciones de los procesos de reingeniera.
A continuacin, haremos referencia a los proyectos de reutilizacin de
software, concepto cada vez ms amplio y que empieza a formar parte, como
un nuevo tipo de gestin, de todos los proyectos informticos. Sobre este tema
es importante recordar su conexin con la orientacin a objetos, las libreras
software y el concepto ingenieril de la gestin del ciclo de vida del software.
Por ltimo, hablaremos de un tipo de proyecto cada vez ms frecuente en
organizaciones de muy diversas clases: la implantacin de paquetes estndar.
Cada vez ms, frente al software a medida, se utilizan paquetes de software
37 2 P L A N IF IC A C IO N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
comerciales que resuelven los problemas de informacin de las empresas de
forma organizada, segura y fiable. Sus ventajas e inconvenientes, as como, su
proceso de implantacin y adaptacin a cada cliente, sern tratados en este
tema.
Resumiendo, en este captulo trataremos de:
Describir el concepto y la utilizacin de la Reingeniera del Software y
la Ingeniera Inversa.
Definir los repositorios como elemento central en la reingeniera.
Introducir la Reingeniera de Procesos en el contexto de los proyectos
informticos.
Definir la reutilizacin del software y sus ventajas.
Explicar los proyectos de adaptacin e instalacin de paquetes software
estndar.
17.1 REINGENIERA DEL SOFTWARE.
Vamos a ver como la reingeniera puede ser utilizada para solucionar
problemas de mantenimiento del software y la migracin de nuevas a viejas
tecnologas.
Pero a dnde llega realmente la reingeniera del software? Tal vez
tengamos que explicar los problemas que se han presentado en algunas
organizaciones que tenan un antiguo ordenador y unas viejas aplicaciones que
han tenido que migrar y que no eran dominadas por casi nadie en la
organizacin y, adems no estaban suficientemente documentadas, sin embargo
funcionaba!. La reingeniera del software supone el examen y alteracin de un
sistema software para reconstruirlo de una forma nueva. Es una actividad
fuertemente conectada con las herramientas de mantenimiento automatizado
del software.
La reingeniera supone la aplicacin de un proceso de ingeniera inversa y
otro de ingeniera directa del software para reconstruirlo. Podemos ver este
esquema en la figura 17.1.
C A P T U L O 17: P R O Y E C T O S E S P E C IA L E S DI; IN G E N IE R IA D E L S O F T W A R E 373
F ig u ra 7.1 P roceso de re in g en iera d e l softw are
La ingeniera inversa del software permite recuperar el diseo de una
aplicacin (modelos de la arquitectura del software, modelos de datos y
modelos de interfaces de usuario) a partir de su cdigo fuente. Las actuales
herramientas de ingeniera inversa, adems de funcionar en modo grfico,
permiten, una vez que han analizado y comprendido el viejo cdigo, utilizarlo
en una nueva plataforma o en un proyecto posterior. Pero, adems, documentan
el cdigo para que los analistas tengan una idea de lo que ese software
realmente ejecuta.
Uno de los trucos de la ingeniera inversa es asegurar que el nuevo cdigo
nunca ms se volver tan enigmtico como el original, cuando el nuevo cdigo
se tiene en un estado "comprensible" es conveniente asegurarse de que hace lo
que debe y no esconde viejas funciones viciadas del pasado, alguna de las
herramientas obliga a que el cdigo resultante este encajado en alguna de las
mtricas disponibles y que no pueda salirse de ella como garanta de calidad.
Podemos definir tambin la ingeniera inversa avanzada como la
recuperacin del anlisis (requisitos, modelos funcionales, entrevistas, etc.) a
partir del cdigo fuente. Como podemos deducir se denomina avanzada porque
va ms all de la ingeniera inversa, que solo recupera el diseo.
Como hemos visto, la reingeniera en Ingeniera del Software es el proceso
de examinar un sistema de software existente con el fin de modificarlo con la
ayuda de herramientas automticas para:
Prever su futura mantenibilidad
Actualizar su tecnologa
Prolongar su esperanza de vida
Incrementar la productividad del mantenimiento
374 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 17: P R O Y E C T O S E S P E C IA L E S D E IN G E N IE R IA D E L S O F T W A R E 375

Desde este punto de vista existen varios tipos de reingeniera, segn la Reestructuracin del cdigo del programa: violacin de estndares,
parte del ciclo de vida que se quiera mejorar. En este sentido podemos cdigo no estructurado, documentacin pobre, nombres de variables de
encontrar software para la reingeniera segn los siguientes tipos: pobre significado, lgica compleja.

Anlisis: procesos que estudian un sistema con el objetivo de Reestructuracin de los datos: organizacin de datos frgil, nombre de
comprender su funcionamiento y comportamiento y as poder extraer registros mal definidos, definicin de datos no estndar, ausencia de
informacin para la reingeniera o para medir su calidad. diccionario de datos.

Reestructuracin: Es el proceso que se encarga de cambiar la forma del Ingeniera inversa, migracin: viejas tecnologas, viejos lenguajes o
software sin alterar su funcionamiento. El objetivo primario es hacer los versiones o sistemas de gestin de bases de datos, emulaciones,
programas ms fciles de entender. Los mantenimientos tienden a ausencia de especificaciones de diseo.
corromper la estructura del software. La reestructuracin lo hace ms
comprensible, simplificando las condiciones, formatendolo para Sustitucin total o parcial: eleccin pobre de algoritmos, funcionalidad
hacerlo ms legible, eliminando saltos incondicionales, agrupando en incorrecta o incompleta, inseguridad y/o desconfianza, defectos en el
forma de mdulos distintas partes del software relacionadas para diseo de bases de datos.
simplificar interfaces entre mdulos, etc.
Para cubrir todo este campo de actuacin tan amplio y que adems cada
Ingeniera inversa: Son procesos de anlisis de sistemas para reconstruir vez est siendo ms utilizado se han desarrollado distintas herramientas.
una descripcin de sus componentes y sus relaciones. El objetivo de la Vamos a clasificarlas en funcin de su utilidad. Distinguimos los siguientes
ingeniera inversa es documentar el sistema y descubrir la informacin tipos de herramientas para la reingeniera:
de diseo con el nimo de facilitar la comprensin del programa. La
funcionalidad del sistema no cambia. Programas analizadores: traceadores de lgica y de datos y
referenciadores en cruz.
Migracin: proceso de convertir un sistema software desde un lenguaje
a otro, adaptndolo a otro sistema operativo o actualizando su Programas mtricos: monitorizadores normalizados, analizadores de
tecnologa. Puede ser necesario debido a la escasez de personal calidad, comprobadores de complejidad.
cualificado a la modificacin del software de soporte o de la plataforma
hardware o a cambios en la estrategia de la organizacin. Programas para la reestructuracin: reestructuradores de procesos
lgicos, estandarizadores de nombres lgicos y de definiciones,
Reingeniera de datos. Consiste en analizar y reorganizar las estructuras reformateadores/mejoradores de presentacin.
de datos y/o los valores de los datos. Este proceso es necesario cuando
existe una degradacin en la base de datos (igual que ocurre con los Ingeniera inversa: ingeniera inversa de datos, ingeniera inversa de la
programas, las estructuras de datos tambin se corrompen con el lgica de procesos.
mantenimiento), cuando el volumen de datos es inmanejable y se debe
generar un histrico o cuando un software errneo ha introducido Programas Comprobadores: generadores de datos, testeadores de
valores incorrectos. procesos: algebraicos o estadsticos, depuradores, comparadores.

Veremos ahora algunos ejemplos del tipo de actuacin recomendada en el Traductores/Conversores: traductores de lenguajes.
mbito de la reingeniera segn el problema que encontramos en el software:
Manejadores de cambios o de configuracin: manejadores del control
de cambios, controladores de libreras, constructores de sistemas.
376 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Herramientas para la re-documentacin: referenciadores cruzados,
impresin de procesos (pretty printer), generadores de diagramas.
17.2. REPOSITORIOS.
Las tecnologas CASE han emergido como el eje de las tecnologas dominantes
en la construccin del software en el nuevo milenio. Las organizaciones que
basan su produccin de software en estas tecnologas garantizan su
competitividad y tal vez su futuro ya que, a largo plazo, esta eleccin es
econmicamente buena y no tiene elevados riesgos.
Dentro de estas herramientas CASE es importante el concepto de
repositorio, entendido como el mecanismo para definir, almacenar, acceder y
manejar toda la informacin acerca de todo el sistema, sus datos y su software.
Son el corazn de unas herramientas CASE integradas.
El repositorio es algo ms que un diccionario de datos, no slo almacena
informacin sino que adems almacena los mtodos o procesos asociados con
esos datos. As en una empresa, el repositorio almacena el modelo de datos
corporativo, la descripcin del software del sistema y de gestin, la descripcin
de cada componente y, sobre todo, contiene la forma de manejar estos datos
segn las propiedades almacenadas con la caracterstica dinmica de cada
componente. Es mucho mas que un diccionario de datos clsico de Gestin de
Bases de Datos, potencialmente debera soportar cualquier informacin de las
necesidades de la empresa.
Los repositorios pueden contener:
Datos lgicos y modelos de procesos.
Definiciones fsicas y cdigo fuente.
Modelos de proyectos.
Datos de negocios.
Reglas para manejar esos datos o procesos.
Relaciones.
C A P T U L O 17: P R O Y E C T O S E S P E C IA L E S DE IN G E N IE R IA D E L S O F T W A R E 377
Diccionario de metamodelos y reglas de validacin.
Manejo del proyecto e informacin para la auditoria.
Modelo de procesos del ciclo de vida.
Con la utilizacin de repositorios compartimos, en toda la organizacin, la
informacin sobre las aplicaciones, sus herramientas, su configuracin y el
ciclo de vida del sistema, ya que es una herramienta multiusuario integrada que
permite combinar herramientas de distintos fabricantes. Su uso facilita la
comunicacin entre usuarios, incrementa la integridad del sistema y consolida
y elimina redundancias en los datos corporativos. Por ltimo, la utilizacin de
repositorios simplifica el mantenimiento del sistema y los procesos de
conversin y/o migracin.
El concepto de repositorio se amplia con la definicin de repositorio
corporativo. Toda la informacin de la empresa es un activo importante que es
crucial para su funcionamiento competitivo. Esta informacin, y los elementos
que la producen, deben de ser manejados por un mecanismo potente para
protegerla y gestionarla convenientemente. Este mecanismo es el repositorio
coiporativo. El repositorio corporativo ser la nica fuente de toda la
informacin corporativa y el responsable de la integracin de la informacin
con cuatro funciones:
Integrador del diccionario;
Integrador de herramientas;
Integrador del sistema;
Integrador de procesos.
La utilizacin de repositorios se ha extendido tanto y sus ventajas se han hecho
tan importantes que muchos organismos de estandarizacin estn trabajando en
su definicin y normalizacin. Repasemos algunos grupos de trabajo en torno a
repositorios normalizados:
CDIF: Case Data Interchange Format. Especificaciones para un
lenguaje cuyo propsito es compartir la informacin entre herramientas
CASE. Es una extensin del EDIF estndar diseado originalmente
para compartir informacin entre productos CAD/CAM/CIM. Emplea
Metamodelos entendidos como metadatos o esquemas junto con la
informacin asociada a los mismos. Soporta diagramas Dataflow y
ControlFIow, definiciones del diccionario lgico de datos,
378 P L A N IF IC A C I N Y C jE ST l N D E S IS T E M A S IN F O R M T IC O S
especificaciones de procesos y mdulos, diagramas de entidad-relacin
y de control de transacciones, diagramas de Warnier, tablas de decisin,
matrices de estado-suceso, registros de elementos de datos, campos
(tanto de datos como de pantallas), pantallas, mapas, programas y
mdulos.
IRDS: Information Resource Dictionary System. Desarrollado por el
National Institute o f Standars and Technology, incluye seis mdulos:
ncleo del diccionario del sistema, esquema funcional bsico,
seguridad, facilidad para extensin del ciclo de vida, facilidad para los
procedimientos e interfaz para los programas de aplicacin.
Fundamentado en la arquitectura Entidad-Relacin organiza toda la
informacin entorno a los esquemas: esquema de la capa de
descripcin, esquema capa de datos, datos en s mismos, etc.
SAA de IBM y el ciclo AD. SAA (estndar de hecho) es una coleccin
de principios, objetivos y normas que cubren aspectos de
comunicaciones, accesos al usuario, y desarrollo de aplicaciones para
entornos MVS, VM, AS/400 y OS/2. AD/Cycle es la base para facilitar
un esquema para el desarrollo de aplicaciones integradas sobre la
plataforma SAA que ofrece: soporte de funciones completas de ciclo de
vida, inlerfaces de usuario comunes, repositorios comunes y
arquitectura abierta.
ATIS: A tools Integration Standard (1PSE: Integrated Proyect Support
Enviroment: object-oriented interface) de DEC&Atherton Technology.
Define un repositorio comn y cargable desde otras aplicaciones CASE
aportando una interfaz propia. Incluye control de versiones, manejo de
configuraciones, herramientas de comunicacin del grupo, relaciones
entre los objetos software y extensiones dinmicas para herramientas
adicionales. Su corazn lo constituye el denominado BackPlane,
organizado como un escritorio orientado a objetos con soporte a
catlogos, control de la integracin, control de workflow, integracin de
datos, modelos de integracin de usuarios y herramientas de integracin
incremental de procesos.
PCTE: Portable Common Tool Enviroment. Es un interfaz estndar
cuyo fin es asegurar la portabilidad de CASEs en
microcomputadoras/redes LAN. La idea es especificar un interfaz como
un conjunto de funciones que corren entre un sistema operativo y las
herramientas CASE para dar generalidad a los entornos. PCTE tiene
varias ampliaciones pero se encuentra en un modo experimental y est
C A P T U L O 17: P R O Y E C T O S E S P E C IA L E S D E IN G E N IE R IA D E L S O F F W A R E 379
financiado por Europa, de donde es originario, en un plan ESPRIT a
diez aos. Permite proceso distribuido (tanto en almacenamiento como
en proceso), manejo de ventanas heterogneas, datawarehouse, etc.
17.3 REINGENIERA DE PROCESOS DE NEGOCIO.
En la evolucin del ciclo de vida de un producto software se deben adaptar los
procedimientos de negocio a las nuevas tecnologas. La reingeniera de
procesos de negocio se utiliza para realizar esta adaptacin y, normalmente,
constituye un proyecto anterior (a veces forma parte del propio proyecto) a
cualquier proyecto de implantacin o modificacin importante a un Sistema de
Informacin Empresarial.
Empleada inicialmente por Hammer en 1990 en un informe del MIT sobre
los mtodos de gestin que mas xito tendran en la dcada actual, es el
replanteo fundamental y el rediseo radical de los negocios para conseguir una
mejora drstica en medidas crticas del rendimiento tales como costo, calidad,
servicio y velocidad.
Se distingue del cambio organizativo (segn Andrews y Stalick en 1993)
en:
El cambio solo puede producirse cuando se hayan destruido las formas
de pensar y operar. La Reingeniera crea lo que no hay.
Los resultados concretos deben de ponerse en manifiesto rpidamente.
Las tecnologas de la informacin deben de jugar un papel clave en
cualquier esfuerzo de cambio organizacional.
Cualquier cambio afecta a todas las partes de la organizacin.
La metodologa para el desarrollo de proyectos de reingeniera de procesos
de negocio se construye como respuesta a una serie de cuestiones simples,
como:
Se necesita aplicar reingeniera a esta operacin? En caso afirmativo
Cules son los lmites, el alcance y los puntos intermedios de la
operacin de reingeniera?Cmo se debe estructurar el proyecto?Qu
personas?
38 0 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M A T IC O S
Cul es la visin final de los resultados de reingeniera? Cules sus
prioridades y sus metas? Qu valores principales se re ileja en esta
visin?
Cul es el diseo detallado de la operacin reingeniada? Cmo
funciona el proceso? Cmo es la organizacin? Qu sistema se
necesita? Que sistema de creencia o de cultura debe implantarse?
Funcionar el nuevo diseo de la operacin? Ser necesario hacer
cambios al diseo?
Cul es el Plan para que se triplemente este diseo? Qu se requiere
para que esto ocurra? Cunto durar? Cules son sus riesgos?
Cunto costar?
Se debe invertir en la implantacin de un diseo de reingeniera?
La implementacin avanza como se plante? Que correcciones o
cambios deben de hacerse para asegurar una transicin completa al
ambiente de la visin?
Est preparada la operacin reingenierada para una continua mejora
del proceso?
Veamos ahora un ejemplo de los pasos a seguir en la aplicacin de una
metodologa de reingeniera de procesos de negocio:
1. Esquematizar el Proyecto (de 2 semanas a 6 meses). El propsito es
decidir si proceder o no con el proyecto y definir y estructurar el
mismo. El resultado sera la declaracin del esquema del proyecto.
2. Crear Visin, Valores, Objetivos (de lda a 2 semanas). El propsito es
crear un grfico que muestre lo que la operacin llegar a ser. El
resultado sera obtener visiones, valores y declaracin de objetivos.
3. Redisear la operacin de negocio (de 1 a 2 meses). El propsito es
disear una forma nueva de hacer el negocio que sea acorde con la
visin, los valores y los objetivos. El resultado sera un anteproyecto de
reingeniera, que consta de componentes fsico/tcnicos, de
infraestructura y de valor.
C A P T U L O 17: P R O Y E C T O S E S P E C IA L E S D E IN G E N IE R IA D E L S O F T W A R E 381
4. Llevar a cabo una Prueba de Concepto (de 2 semanas a 6 meses). El
propsito es retinar la estimacin de los beneficios esperados del
proyecto y ver si el rediseo de la operacin funciona como se
esperaba. El resultado sera una declaracin de beneficios.
5. Planificar la Implementacin (de 2 a 4 semanas). El propsito es
desarrollar un plan de accin realista para implementar el proyecto de
reingeniera. El resultado sera un plan de implementacin.
6. Obtener la Aprobacin-Implementacin (de 1 a 2 semanas). El
propsito es obtener los fondos y los recursos para empezar la
implantacin del proyecto. El resultado sera una peticin de recursos
consolidada.
7. Implementar el Rediseo (de 6 meses a 3 aos). El propsito es
transitar la operacin de negocios del entorno actual al entorno
reingeniado. El resultado sera obtener conclusiones de los resultados
de las mediciones.
8. Transicin hacia un Estado de Perfeccionamiento (permanente). El
propsito es terminar las actividades del equipo del proyecto y
conseguir la mejora continua del entorno reingeniado. El resultado
sera un funcionamiento continuamente mejorado.
17.4 REUTILIZACION DEL SOFTWARE.
Vamos a conocer las nuevas tecnologas de la reusabilidad del software y como
puede ser utilizada para incrementar la productividad de los equipos de
desarrollo. Las nuevas visiones de implantacin capsular de datos parece que
puede tener una buena cabida ante un futuro incierto ante la pregunta de Qu
sistema tendremos dentro de unos aos? Como conseguir un entorno de
desarrollo del que pueda migrar fcilmente al acontecer futuro? Que haremos
con las aplicaciones existentes?
Una estrategia que cada da se est imponiendo en las empresas es la
reutilizacin del software. Las empresas construyen unos componentes que
utiliza con una frecuencia relativamente alta y se esfuerza en su conservacin,
mejora y catalogacin. Con estos componentes reutilizables las empresas
pueden construir nuevos sistemas de informacin al igual que los ingenieros
382 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 17: P R O Y E C T O S E S P E C IA L E S D E IN G E N IE R IA D E L S O F T W A R E 383

electrnicos montan nuevas placas de circuitos impresos incorporando chips a Comparte las especificaciones del sistema, diseo, cdigo, y otros
sus circuitos. documentos del proyecto producidos por el grupo.

Existen muchos componentes de software reutilizables ms all de los Vamos a listar, al igual que las ventajas, los inconvenientes o problemas
mdulos software. Caper Jones1 define muchos otros conceptos que pueden ser que podemos encontrar al aplicar la reusabilidad:
fcilmente reutilizables entre los que se encuentran:
Cuestiones de lo que es realmente reusable.
Los Planes del Proyecto
La estimacin de costes Dificultad para descubrir componentes comunes sobre el sistema.
La arquitectura
Especificaciones y modelos de requisitos Problemas de estandarizacin de programas.
Diseos
Cdigos fuente Decisiones de lo que debe poseer una librera y de lo que debe de estar
Documentacin de usuario y tcnica fuera de ella.
Interfases humanas
Datos Desconocimiento de los requerimientos de interfase y de la calidad
interna de los componentes del software.
Casos de prueba

Otros posibles componentes reusables pueden ser: prototipos, esqueletos Desconocimiento de los efectos posibles en el cambio.
de estructuras de programas y de datos, modelos de datos, proceso de control
de ciclo de vida del software, etc. Descripcin y clasificacin de los componentes software.

En el artculo antes mencionado se ofrece un estudio econmico de los No aceptacin por parte de las metodologas.
beneficios encontrados cuando una empresa aplica razonadamente los
principios de reutilizacin con disciplina. Algunas ventajas de la reutilizacin Dificultades en manejo en los cambios.
son:
Un componente software reusable puede costar 25 veces mas que un
Reduce tiempo de desarrollo y costo. componente no diseado para reusabilidad.

Aumenta la calidad del software. Los beneficios de la reusabilidad no son a corto plazo.

Incrementa la productividad. No hay prcticas para realimentar la reusabilidad in los componentes

Comparte el conocimiento sobre el sistema y como construir sistemas.
Facilita el aprendizaje sobre la arquitectura del sistema y permite
construir buenos sistemas.
del software existentes.
La reutilizacin se puede hacer de dos formas: planificada y oportunista.
La reutilizacin planificada incluye procedimientos concretos para enfocar la
reutilizacin a lo largo del ciclo de vida del producto. Se trata de sistemas que
tienen una planificacin a largo plazo donde la estrategia ser la de construir
software generalista que pueda ser utilizado para distintos proyectos.

1 The Economics o f Object-Oriented Software. American Programmer, vol.7 n.10, octubre de

1994, pgs. 28-35.
384 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
La reutilizacin oportunista se produce en aquellas organizaciones que,
despus de poseer una amplia experiencia en la construccin de sistemas de
informacin, tratan de acoplar los mdulos desarrollados anteriormente para
tratar de acortar la planificacin de un determinado proyecto. En los sistemas
de reutilizacin oportunista surge el problema de tener que adaptar el software
viejo para que sirva para el nuevo proyecto o seguir el enfoque contrario; es
decir, construir un sistema desde cero pero tratando de reciclar componentes
software del viejo sistema.
Igualmente se debe de planificar el tipo de reutilizacin que se desea para
la empresa y aqu, surge de nuevo el dilema: Construir o comprar. En otras
palabras: Reutilizacin interna o externa. En principio no se debe descartar la
idea de comprar componentes externos como hacer las factoras de electrnica
al adquirir sus componentes. Los componentes externos suelen estar bien
desarrollados, bien probados y, por la difusin de las redes comerciales, suele
ser ms barato que el construirlos internamente.
Algunos prefieren construirse sus propias herramientas as como los
antiguos artesanos disponan de sus tiles de trabajo realizados por ellos
mismos, sin embargo este camino es bastante costoso y, a no ser que la
empresa trate de controlar su propia tecnologa por razones de estrategia de
empresa, esta opcin deber ser desechada de antemano.
El xito de los componentes reutilizables se ha fundamentado en los
nuevos paradigmas de la programacin orientada a objetos que hace que el
equipo de desarrollo se centre en sus problemas y no en utilidades y mdulos
general istas que puede encontrar en el mercado a un precio muy inferior al de
fabricacin interna. Por otra parte la modularidad y la ocultacin de los niveles
de datos, junto con el polimorfismo, ha hecho que los fabricantes de software
cada da estn confiando ms y ms en los componentes reutilizables.
Este tipo de abstraccin de la solucin permite que las empresas de
desarrollo de software sean cada da ms competitivas pudiendo construir sus
soluciones en un menor plazo de ejecucin, de una forma ms fiable y
reduciendo el coste total del producto. Pero para ello vamos a presentar algunas
prcticas que deben llevar a cabo las empresas para reutilizar el software con
calidad:
Elegir un formalismo apropiado para representar todos los componentes
software reusables.
C A P T U L O 17: P R O Y E C T O S E S PE C IA L E S D E IN G E N IE R IA D E L S O F T W A R E 385
Facilitar herramientas para soportar un desarrollo basado en software
reusable.
Manejar una librera de partes reusables.
Usar una metodologa de desarrollo que favorezca la reusabilidad.
Afinar la gestin del proyecto esforzndose en el reuso.
Manejar componentes que cumplan con las siguientes caractersticas:
o Aditividad: posibilidad de combinar componentes con un mnimo
esfuerzo y sin iteraciones destructivas,
o Base matemtica formal: que permita la definicin exacta de las
condiciones en las que puede implementarse cada uno de los
mdulos para conservar las propiedades de cada componente,
o Autocontenidos: cada componente debe contener una sola idea,
o Fcil descripcin.
o Independencia del lenguaje de programacin,
o Verificable: facilidad a los test,
o Interfase simple: nmero de parmetros mnimo,
o Facilidad de cambio.
Las herramientas que nos ayuden a gestionar un software reutilizable
debern estar basadas en, al menos los siguientes componentes:
Una base de datos documental con capacidad para alojar los
componentes en su estado puro para poder ser utilizados por los
miembros del equipo de desarrollo.
Un sistema de clasificacin de componentes.
Un sistema de recuperacin de los componentes.
Un conjunto de herramientas colaborativas.
Una herramienta CASE que identifique y controle el subconjunto de
componentes utilizados en cada proyecto y su gestin de la
configuracin.
386 P L A N IF IC A C IO N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
17.5 IMPLANTACIN DE PAQUETES SOFTWARE ESTNDAR.
Definimos como paquete software estndar un entorno soware (conjunto de
programas, bases de datos, herramientas de desarrollo y/o de gestin,
documentacin, etc.) que proporciona una cierta funcionalidad y que es
comercializado por una empresa soware que lo ha desarrollado y asegura su
continuidad. Segn la importancia del paquete y la empresa comercial, adems
del propio paquete estndar podemos obtener, al comprar el paquete, ayuda a la
adaptacin del mismo a nuestro entorno y nuestras necesidades de informacin,
ayuda a la implantacin, soporte y monitorizacin del sistema durante su
utilizacin, resolucin on-line y/o batch a consultas y problemas, foros de
usuarios, certificaciones y otros utilidades que proporcionan sus asesores y
consultores.
La primera decisin a tomar cuando una compaa decide implantar un
sistema informtico es si comprar un paquete software o desarrollar ella misma
los programas que implementen el sistema. Las empresas pequeas no tienen
mucha eleccin ya que no cuentan con los medios para desarrollar un sistema
tan complejo. Las empresas ms grandes deben decidir entre las ventajas que
tienen ambas posibilidades.
Las principales ventajas de comprar un paquete software son las
siguientes:
En caso de sistemas complejos la necesidad de software (programas,
datos y documentacin) suele ser muy grande, por lo que el coste de
desarrollarlo internamente excede al de la compra.
El tiempo de desarrollar el software internamente es, seguramente,
menor que el de instalar un paquete comprado, ya hecho y probado.
Los analistas y programadores que trabajan en las empresas que
comercializan estos paquetes poseen una experiencia probada en los
temas especficos a implementar.
Los paquetes a la venta normalmente estn ya instalados en otras
empresas, lo cual implica que han sido ya probados y corregidos.
En cambio, el principal argumento para desarrollar un paquete en casa es
que la empresa no encuentre ninguno entre los existentes que cubra sus
necesidades. Hace unos aos era una situacin bastante corriente, pero,
C A P T U L O 17: P R Q V h C T O S E S P E C IA L E S DE IN G E N IE R IA DHL S O F T W A R E 387
actualmente, los paquetes a la venta intentar incluir funciones opcionales
particulares para adaptarse a todo tipo de exigencias.
Una vez decidida la compra de un producto ya desarrollado es muy
importante elegir cual, para ello es aconsejable seguir los siguientes pasos:
1. Determinar que funcionalidad se quiere que cubra el paquete. Es
conveniente establecer dos listas: funciones fundamentales y deseables.
2. Estudiar los paquetes existentes en el mercado. Es conveniente hacerse
aconsejar por consultores especialistas. Es importante tener en cuenta
estos puntos:
La empresa que distribuye el paquete tenga solvencia, est
establecida en la zona donde se quiere implementar y tenga los
recursos necesarios para dar soporte.
El paquete sea compatible con el hardware existente en la
empresa.
Est ya instalado en otras empresas. En este caso sera
conveniente entrar en contacto con los responsables del paquete
en alguna de estas empresas.
3. Ponerse en contacto con los representantes de los paquetes
seleccionados dndoles informacin sobre el entorno donde se quiere
implementar. Ser necesario incluir lo siguiente:
Lista de la funcionalidad deseada.
Informacin sobre la cantidad de datos a tratar.
Informacin sobre la estructura del hardware existente y la
posibilidad de ampliarlo con vistas a la nueva instalacin.
Informacin sobre el sistema informativo existente con el que
el paquete tendr que convivir y conectarse.
4. Estudiar las propuestas recibidas. Aquellas que no puedan satisfacer las
funciones fundamentales debern ser descartadas inmediatamente. Se
estudiarn los restantes teniendo en cuenta los siguientes factores de
decisin:
388 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 17 P R O Y E C T O S E S PE C IA L E S D E IN G E N IE R IA D EL S O F T W A R E 389

sobre la estructura de este que le sern necesarios cuando se quiera

Presencia de funciones deseadas. prescindir de los consultores externos.

La calidad del soporte a la instalacin: cursos, manuales, Veamos, de forma resumida, las fases fundamentales por las que debe
disponibilidad de personal experto, etc. pasar un proyecto de implantacin de paquetes estndar:

Caractersticas del paquete frente al usuario (user-friendly). 1. Organizacin y diseo conceptual. En esta fase se realiza la
preparacin del proyecto, definiendo objetivos, extensin de la
Facilidad de modificacin y mantenimiento de los programas. implementacin., estndares y estrategias, fechas y secuencias, costes y
organizacin del equipo de proyecto. Tambin se debe definir el
entorno final y proporcionar un entorno de prueba, entrenar al equipo
Coste.
de proyecto, definir funciones y procesos del modelo de negocio,
5. Basndose en estos puntos el grupo de paquetes seleccionado debe determinar parmetros y usuarios clave, as como, interfaces con otros
sistemas y mejoras.
quedar reducido a un nmero entre dos y cuatro. Se har un estudio
ms profundo de estos, con contacto directo con los vendedores del
2. Diseo detallado y realizacin. Durante esta fase se debe detallar la
paquete que incluir presentaciones y demostraciones de
configuracin del sistema segn el diseo conceptual obtenido en la
funcionamiento. Al final se har un informe detallado de cada uno de
fase anterior: establecer la configuracin global, la estructura de la
ellos.
compaa, los datos maestros, etc. Tambin se detallan los procesos
definidos asocindoles una secuencia de funciones existentes en el
6. La alta direccin decidir el paquete a instalar con los datos aportados
paquete, interfases con otros sistemas y/o desarrollos a medida. Por
en el punto precedente.
ltimo se realizan las modificaciones, parametrizaciones y nuevos
desarrollos necesarios.
Hasta ahora hemos visto dos soluciones: comprar software estndar o
3. Migracin. Esta fase cubre los aspectos de formacin y carga de datos
desarrollarlo a medida. A veces es factible una solucin intermedia que incluye
necesarios para el buen funcionamiento del nuevo sistema. Se lleva a
ventajas de las dos anteriores. Esta solucin consiste en comprar un paquete y
cabo la formacin de los usuarios finales en las reas del paquete que
personalizarlo adaptndolo de forma ms precisa a nuestras necesidades. Al
van a utiliza, formando a todos en un modulo inicial de visin general.
adoptar esta solucin hay que elegir cuidadosamente el paquete a comprar
Se realiza el traspaso efectivo de datos manuales o informatizados,
como acabamos de ver, debiendo el paquete elegido realizar todas las
tanto estticos como dinmicos, al nuevo sistema, cargndolos
funciones fundamentales. Adems es conveniente tener en cuenta lo siguiente:
directamente o convirtindolos segn la nueva estructura. La carga de
datos dinmicos (aquellos que estn vivos en la organizacin y pueden
Establecer claramente, antes de empezar las modificaciones, el lmite
ser objeto de actualizacin en cualquier momento) debe realizarse en el
donde se quiere llegar. Es fcil caer en la tentacin de aumentar sin
momento de cierre del sistema viejo.
medida las funciones que se quiere que realice el paquete hasta llegar a
desarrollar prcticamente un software a medida. Esto supone no obtener
4. Puesta en marcha y mantenimiento inicial. Durante esta fase se debe
ninguna de las ventajas de las dos soluciones anteriores.
poner el sistema a disposicin de los usuarios. De forma habitual, las
primeras semanas de utilizacin del sistema necesitan un seguimiento
Crear un grupo de trabajo utilizando personal interno y de la sociedad
cercano: atender las dudas y problemas que encuentran los usuarios en
vendedora o distribuidora del paquete para realizar las modificaciones a
su trabajo, resolver los posibles errores del software (normalmente el
los programas. De esta forma el personal interno responsable en un
software comprado est ya probado y es correcto, por lo que esto se da
futuro del software del paquete adquiere conocimientos fundamentales
ms en interfaces y modificaciones), monitorizar los tiempos de
390 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S

sistemas, controlar el volumen de datos, etc. En algunas ocasiones, es

necesario modificar la parametrizacin inicial del sistema. Esta
actividad debe realizarse fuera del entorno de produccin y no hacerla
efectiva hasta que las pruebas de regresin demuestren que la
modificacin pedida no influye negativamente en otros procesos.
CAPTULO 18

AUDITORIA INFORMTICA
Prof. Roberto Barellino Piala

Antes de comenzar el presente captulo, se considera necesario definir el

concepto de auditoria. Para ello, segn el diccionario la Real Academia
Espaola, auditoria es: 1.//Empleo de Auditor.//2.Tribunal o despacho del
auditor.//3. Auditoria Contable.//Contable. Revisin de la contabilidad de una
empresa, sociedad, etc., realizada por un auditor". Como se desprende de la
definicin de auditoria, el nico elemento que se tiene en cuenta es el de
contabilidad, como el establecimiento de unos criterios bsicos de revisin del
estado financiero de una organizacin. Pero el trmino de auditoria es algo
ms, es decir, no est limitada a las funciones de la auditoria contable. En esta
sociedad donde vivimos, el uso de la informacin es un elemento bsico en
cualquier organizacin y conlleva el masivo empleo de Sistemas de
Informacin. La auditoria informtica, surge como una necesidad que tienen
las organizaciones de evaluar, gestionar, comprobar y verificar el buen
funcionamiento de las tecnologas de la informacin que se incorporan en una
empresa, con una doble finalidad, por un lado, verificar que la informacin de
la organizacin se utiliza de forma correcta en la toma de decisiones y por otro
lado, evaluar que los objetivos de negocio de la organizacin son alcanzados
y, lo que es ms importante, mantenidos.

18.1 TIPOS DE AUDITORIA. AUDITORIA INFORMTICA

Los distintos tipos de auditora se pueden clasificar segn la finalidad del

estudio auditor. Antes de enumerar las distintas clases de auditoria que existen,
es importante observar, que en el desarrollo de la funcin auditora, se puede
establecer una divisin entre la funcin de auditoria interna, la cual es
desarrollada por profesionales de dentro de la organizacin y la funcin de
auditoria externa, que es llevada a cabo por profesionales externos a la
organizacin. Por supuesto, independientemente, si se realiza una auditoria
interna o externa los dos pilares bsicos en cualquier auditoria son la
independencia y la objetividad.
392 P L A N IF IC A C I N Y G K STI N D E S IS T E M A S IN F O R M T IC O S
La auditoria financiera, se realiza para verificar el estado de las cuentas
anuales de una organizacin. Para ello, se siguen estndares y normativas que
estn perfectamente aceptados y son conocidos. El objetivo que se pretende en
este tipo de auditoria, ser el presentar la realidad de la situacin financiera de
la organizacin.
En la auditora de gestin, se verifican los distintos procesos,
procedimientos y tareas que se desarrollan en una organizacin, para lograr la
eficacia, eficiencia y reduccin de costes.
La finalidad de la auditora de cumplimiento es verificar si las
operaciones, procesos y actividades que se desarrollan dentro de la
organizacin se adecan a las normas y estndares establecidos por la propia
direccin.
La auditora informtica establece los controles necesarios para verificar
el correcto funcionamiento de los sistemas y recursos informticos, planes de
contingencia, seguridad, integridad de los datos, etc. El auditor informtico
en una organizacin se debe establecer como el garante de la veracidad, validez
y completitud de la informacin que usa la organizacin.
Por supuesto, la funcin del auditor informtico depender de una serie de
factores, que en general son: la propia organizacin de la empresa, es decir, qu
nivel de importancia le dan a las tecnologas de la informacin la direccin; la
estructura interna de la funcin informtica y las relaciones que deben existir
entre los distintos mbitos o departamentos de la empresa.
En la actualidad, un auditor informtico tiene a su disposicin una serie de
asociaciones profesionales a nivel internacional y nacional que le ayudan y
aconsejan en la realizacin de la funcin de auditoria informtica. A nivel
nacional, podemos destacar ALI (Asociacin de Doctores, Licenciados e
Ingenieros en Informtica) que an no siendo su principal objetivo, si que
puede orientar y encaminar cualquier problema de un profesional sobre la
realizacin de una auditoria informtica. La asociacin ms importante de
carcter internacional es ISACA (International Standard Audit & Control
Association) que tiene como funciones bsicas la realizacin de un cdigo de
tica profesional (independencia y objetividad), la emisin de normas o
sistemas de control que garanticen la calidad de la funcin de cualquier tipo de
auditoria informtica y la certificacin internacional mediante un examen
CISA (Certified Information Systems Auditor). La certificacin CISA es
promovida por el ISACA una vez al ao en prcticamente todos los pases del
mundo, en Espaa, por supuesto, tambin se realiza. Aunque, para obtener la
C A P T U L O 18: A U D IT O R IA IN F O R M T IC A 393
certificacin C'ISA, no basta con superar el examen, sino que tambin se debe
acreditar al menos 5 aos de experiencia en sistemas de informacin y el
compromiso de una evaluacin peridica por el ISACA.
El auditor informtico debe poseer una serie de capacidades tcnicas y
ticas que le permitan desarrollar su trabajo con calidad, objetividad y
correccin. Para conseguir una buena calidad, es fundamental su formacin
tcnica, diligencia y capacidad profesional, adems de trabajar con
responsabilidad y guardar siempre el secreto profesional. Debe tener presente
principios ticos, y as aplicarlos durante su funcin auditora, como son la
bsqueda de la verdad, independencia, trato no discriminatorio y la no
injerencia.
En general, para cualquier tipo de auditoria, y en concreto para la
informtica, se debe avalar, dicha funcin auditora, por el apoyo incondicional
de la direccin de la organizacin, si esto no ocurre no se llegar al fin
deseado.
18.2 SISTEMA DE CONTROL INTERNO EN TECNOLOGAS DE LA
INFORMACIN
La informacin que se utiliza en cualquier organizacin, se define, de manera
informal, como los datos que han sido manipulados para tomar, con ellos, una
decisin. No slo en un entorno informtico, sino tambin en entornos
financieros, de gestin, de coordinacin, de personal, etc. Por tanto, no es
exagerado afirmar, que la informacin es un bien preciado en una empresa, ya
que si se posee una correcta informacin, la calidad en la toma de decisiones
ser ptima.
El trmino conocido como control interno, se puede ver como el proceso,
avalado por la direccin de la organizacin, que asegura en la medida de lo
posible que se alcanzarn los objetivos de negocio. En nuestro caso, desde el
punto de vista de las tecnologas de la informacin a travs de la
implementacin de una auditoria informtica.
Pero, cmo se da cuenta una organizacin de la necesidad de implantar
un sistema de control interno? Existen una serie de sntomas que hacen
necesaria, en una organizacin, el establecimiento de un marco de control
interno. La auditora informtica verifica y evala los controles internos
establecidos en una empresa. Algunos de los factores que hacen necesario el
desarrollo de un sistema de control interno son:
394 P L A N I F I C A C I N Y G E S T I N D E S IS T E M A S IN F O R M T I C O S C A P T U L O 18 A U D IT O R IA IN F O R M T IC A 395

La informacin no es fiable.
Los objetivos del negocio y las tecnologas de la informacin de la
organizacin no estn alineados.
Incremento considerable en inversiones informticas no justificadas
razonablemente.
Descontrol e infrautilizacin de los recursos informticos de la
organizacin.
Los usuarios / clientes no son atendidos, ni se solucionan sus problemas
ante cualquier incidencia informtica o si se soluciona sta llega
demasiado tarde.

En general, cuando no existe una coordinacin adecuada tanto de los

profesionales encargados de la organizacin de las tecnologas de la
informacin, com o de la visin de los usuarios a estas mismas tecnologas.

El ISACA, ha desarrollado un modelo de gestin de controles internos

denominado COBIT, Objetivos de Control Basados en T ecnologas de la
Informacin, que representan un consenso y ayudan a realizar a la direccin de
la organizacin una gestin eficaz y eficiente de las tecnologas de la
informacin.

El modelo de referencia COBIT, debe estar alineado con los objetivos de

negocio, ya que al final es lo ms importante, es decir, que el negocio consiga
el mximo rendimiento, en nuestro caso optimizando las m ejores prcticas y
mtodos en tecnologas de la informacin. En concreto, el sistema COBIT se
desarrolla a travs de 4 dominios, que son el de planificacin y organizacin,
adquisicin e implantacin, entrega y soporte y supervisin. Estos dominios se
relacionan con 2 elementos bsicos en el modelo COBIT, que son la
H i d*iii>? and manage service level?
informacin y los recursos tecnolgicos. En total, existen 34 objetivos de D52 manage Stird-j>3rty sersim
C33 manage pertcnnan:* anJ capacity
control, 1 1 para el dominio de planificacin y organizacin, 6 para adquisicin DfS-4 er&tre- ccriixjctn rv
e implementacin, 13 para entrega y soporte y 4 para el dominio de D3i> e m ve systems secirity
D3$ identity ar>d allocate costs
supervisin. Tambin, dentro de los 34 objetivos de control de alto nivel se D57 educate dnd train users
DS8 assist o ik ) adr * customer? AI1 ickiHily itfcroatd
despliegan a su vez 302 objetivos de control detallados que proporcionan la DM manage the corriigiratic AI2 arquir and maintain applicatkn ofcvar*
DS'IO manage probten; and incidHtt AI3 acquire and mamiin tschnobgy Wraitnictur*
certeza de cumplimiento del objetivo de control concreto. Como se observa en D31 1 manage dot AH develop and m aria procedures
D512 manag tilifei 15 retell and oocrcdft
la figura 18.1. D S13 manage operatiou AI6 manag* change

Figura 18.1 Modelo de Referenda COBIT.

Copyright 1996, 1998, 2000 Information Systems Audit and Control Foundation, Information Systems
Audit and Control Foundation and IT Governance Institute.
39 6 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 18: A U D IT O R IA IN F O R M T IC A 397

El dominio, planificacin y organizacin, cubre la estrategia de la DS1 Definir niveles de servicio.

organizacin, adems de identificar, cmo las tecnologas de la informacin DS2 Dirigir servicios a terceros.
pueden contribuir, de la mejor manera posible, ha conseguir los objetivos de DS3 Gestionar rendimiento y capacidad.
negocio de la empresa. En la siguiente tabla se presentan los 11 objetivos de DS4 Asegurar el servicio contino.
control de este dominio. DS5 Asegurar sistemas de seguridad.
DS 6 Identificar costes.
POl Definir un plan estratgico de tecnologa de la informacin. DS7 Formar a usuarios.
P 02 Definir la arquitectura de informacin. DS 8 Asistir y aconsejar a clientes de tecnologas de la informacin.
P03 Establecer la direccin tecnolgica. DS9 Gestionar la configuracin.
P 04 Definir las relaciones y la organizacin de tecnologa de la informacin. DS10 Gestionar problemas e incidentes.
POS Gestionar la inversin de tecnologa de la informacin. D S11 Gestionar datos.
P 0 6 Comunicar los objetivos y directrices de la gestin. DS12 Gestionar la infraestructura de las instalaciones.
P 07 Gestionar los recursos humanos. DS13 Gestionar operaciones.__________________________________________
POS Asegurar el cumplimiento de los requisitos externos.
T abla 18.3 O bjetivo s d e C ontrol d e l D o m in io E ntrega y Soporte.
P 09 Evaluar riesgos.
POlO Dirigir proyectos.
POIl Gestionar la calidad.______________________________________________ Por ltimo, todos los procesos necesitan ser evaluados para verificar su
calidad y suficiencia en cuanto a los requerimientos de control. El dominio de
Tabla 18.1 O b jetivo s de C o ntrol del D o m in io P lanificacin y O rganizacin.
supervisin, est formado por los siguientes objetivos de control:

Dentro del dominio, adquisicin e implcmentacin, las soluciones que la
organizacin incorpore sobre las Tecnologas de la Informacin deben ser
identificadas, desarrolladas o adquiridas a terceros, as como implementadas e
integradas dentro del proceso de negocio. Adems, este dominio cubre los
cambios y el mantenimiento realizado a sistemas ya existentes. El dominio est
formado por los siguientes objetivos de control, que se muestran:
A ll Identificar soluciones.
AI2 Adquirir y mantener el software.
AI3 Adquirir y mantener la arquitectura tecnolgica.
AI4 Desarrollar y mantener procedimientos en tecnologas de la informacin.
AI5 Instalar y verificar sistemas.
AI6 Gestionar cambios._________________________________________________
T abla 18.2 O b jetivo s d e C ontrol d el D o m in io A d q u isici n e Im plantacin.
En el dominio, entrega y soporte, se hace referencia a la entrega de los
servicios requeridos, que abarca desde las operaciones ms tradicionales hasta
la formacin del personal, pasando por la seguridad y aspectos de continuidad
del negocio. Los objetivos de control del dominio entrega y soporte son los
siguientes:
MI Supervisar procesos.
M2 Evaluar la suficiencia del control interno.
M3 Obtener seguridad independiente.
M4 Proporcionar auditoria independiente.
T abla 18.4 O bjetivo s de C ontrol d e l D om inio Supervisin.
Dentro de cada objetivo de control, de los relacionados anteriormente, se
establecen una serie criterios, indicadores y factores que sirven para medir el *
grado de adecuacin del objetivo de control con las prcticas desarrolladas en
la organizacin.
En todos los objetivos de control, aparecen la definicin y enumeracin de
los factores crticos para el xito, que son una serie de acciones importantes
que de no realizarse son crticas para el xito del objetivo que se est
evaluando. Por ejemplo, un buen estudiante debe: estudiar todos los das, asistir
a clase, realizar las prcticas encomendadas, etc. dentro de estas tareas es un
factor crtico para el xito, la actividad estudiar todos los das, ya que si no se
realiza, el objetivo que es aprobar el examen de una asignatura, no tendr
lugar.
Los indicadores de objetivos clave establecen una serie de medidas que
39 8 P L A N IF IC A C I N Y G E S T I N D E SIST E M A S IN F O R M A T IC O S
indican, despus de realizar un proceso, la eficacia de ste. Por tanto, indicar
si un proceso ha alcanzado o no sus objetivos.
Los indicadores de rendimiento clave, presentes en todos los objetivos de
control, indican el grado de eficiencia, es decir, lo bien que se est
desarrollando el objetivo de control. Ser, por tanto, una vigilancia interna de
los procesos que se implementan en un objetivo de control.
18.3 ORGANIZACIN Y FASES DE LA AUDITORIA INFORMTICA
Un departamento de auditoria informtica deber estar formado, si es posible,
por profesionales con perfil informtico, que posean el certificado CISA. En
general, un auditor informtico, debe conocer y mantener los conocimientos
terico-tcnicos para realizar su trabajo de forma adecuada, as pues, se deben
establecer planes de formacin continua del personal adscrito al departamento
de auditoria informtica. En dicho departamento, se nombrar a un director,
quien ser el responsable de la elaboracin de un plan operativo de trabajo, este
plan ser llevado a la prctica, por un nmero indeterminado de auditores que
sern quienes realicen las distintas auditorias informticas. El tamao del
departamento (nmero de auditores), como es lgico, depender de las
funciones encomendadas por la propia direccin de la organizacin. El
departamento rendir cuentas nicamente a la direccin de la organizacin.
Las herramientas o tcnicas que existen para realizar una auditoria
informtica son las siguientes:
Cuestionarios / Check lists.
Las tpicas entrevistas con el personal implicado.
Software especfico de auditoria.
Con el uso de estas tcnicas, aun cuando el principal valuarte es el
conocimiento y la experiencia del auditor, se puede desarrollar una auditoria
informtica, sta tiene siempre una serie de fases que dependen en cierta
medida del propio problema a auditar. Las etapas tpicas de la auditoria
informtica son:
Estudio inicial.
Elaborar un plan de trabajo.
Desarrollar la auditoria.
Elaborar el diagnstico.
C A P T U L O 18: A U D IT O R IA IN F O R M A T IC A 399
Elaborar el informe final.
Elaborar un plan de ayuda.
A continuacin se desarrollan brevemente cada una de stas fases:
1. Estudio inicial de los Sistemas de Informacin que se van a
evaluar y de la propia organizacin. Tambin es importante,
conocer el alcance y objetivos de la auditoria a realizar, que
debern estar consensuados con la direccin de la organizacin.
Los objetivos por los cuales se realiza el estudio inicial, estn
normalmente relacionados con la reduccin de los costes, aumento
de la calidad, y en general la operatividad ptima de los Sistemas
de Informacin.
2. Elaborar un plan de trabajo, establecindose los recursos (tanto
materiales como humanos) y los hitos necesarios para establecer
los puntos de control en el desarrollo de la auditoria informtica.
3. Desarrollar la auditoria. Donde se implementa el plan de trabajo
de la etapa anterior. Esta fase la podemos considerar como la
auditoria propiamente dicha, utilizando para ello las diferentes
tcnicas o herramientas comentadas anteriormente.
4. Elaborar el Diagnstico. Establecer los puntos fuertes y dbiles,
riesgos importantes y leves y por supuesto, si es posible, identificar
las soluciones de los problemas encontrados.
5. Elaborar el informe final. Se crea un informe con las
conclusiones obtenidas en la fase anterior. Este documento deber
tener una redaccin adecuada al personal destinatario del
documento, es decir, la propia direccin de la organizacin.
6 . Elaborar un plan de ayuda. Establecer las actividades necesarias
para solucionar en la medida de lo posible las deficiencias
encontradas en el proceso de la auditoria informtica.
En cuanto a la estrategia general en una organizacin respecto de la
implantacin de la funcin de auditoria informtica, se aconseja elegir entre
seguir una auditoria contina durante todo el proceso que implique el uso de
las tecnologas de la informacin, estableciendo revisiones en puntos de control
determinados por su importancia o criticidad; o realizar slo una auditoria
previa y posterior a dicho proceso que valide los resultados previstos y
400 PL A N IFIC A C I N Y G ESTIO N DE SISTEMAS INFORM TICOS
determine su alineacin con los objetivos de negocio.
18,4 CLASES DE AUDITORIA INFORMTICA
Existen diferentes tipos de auditoria informtica, a continuacin se comenta
brevemente algunas de las clases de auditoria informtica ms importantes.
La auditoria de la gestin de los Sistemas de Informacin, se llevar a
cabo mediante dos tareas fundamentales:
La primera, la planificacin, donde se verifican la existencia de planes a
corto, medio y largo plazo sobre tecnologas de la informacin en
relacin con los objetivos de negocio de la propia organizacin.
La segunda actividad ser la coordinacin, que controlar que se
alcancen los objetivos incorporados en los planes de Sistemas de
Informacin, en esta actividad aparece un elemento importante como es
el de Comit o Consejo de Informtica, cuya tarea fundamental ser la
de planificar y organizar la propia funcin informtica de la
organizacin, el Consejo aprobar o no los planes, las inversiones
(gestin econmica) y ser adems un punto de dialogo entre los
usuarios y los informticos.
La auditoria de la seguridad con extensiones sobre la integridad y la
confidencialidad de los datos personales, tiene como objetivo bsico el
asegurar el mantenimiento de la funcin informtica de una empresa. Para
cumplir este objetivo, aparecen distintos puntos de vista de la seguridad:
Seguridad Fsica, de las instalaciones y materiales. La auditoria de la
seguridad verificar las medidas ante por ejemplo, un incendio,
climatizacin adecuada, proteccin de acceso fsica a algunas
estancias, etc.
Seguridad Lgica, de los principales datos de la organizacin,
verificando los sistemas de copias de seguridad, controlando los
accesos a los sistemas informticos y utilizando tcnicas de
autenticacin como es, por ejemplo, la de usuario/contrasea. Tambin
es importante que se almacene cierta informacin sobre quien entra,
cuando y que hace en el sistema.
Planes de contingencia y Seguros. Se deben verificar los planes de
_________________________________ CAPTULO 18: AUDITORIA IN FO R M TIC A _ _____ ________ 401
contingencia sea cual sea la gravedad de los accidentes ocurridos y las
coberturas de los seguros suscritos.
Un apartado aparte, se merece la proteccin de los datos confidenciales,
ya que en este tipo de datos tienen un tratamiento especial1. La
auditora de la seguridad verificar la existencia de tcnicas para
conseguir la integridad, proteccin, consistencia y exactitud de los
datos confidenciales, normalmente este tipo de tcnicas estn
relacionadas con la criptografa, que cifra los datos especialmente
sensibles tanto dentro de un nico sistema informtico como en la
comunicacin entre distintos sistemas informticos.
La auditoria de las comunicacioncs corporativas tanto internas (Redes
de Area Local / Intranet) como externas (Internet), debe verificar, gestionar,
controlar y proteger las comunicaciones y a los usuarios. La auditoria debe
tener en cuenta una serie de puntos que se enumeran a continuacin:
La gestin y diseo adecuado de las redes de ordenadores corporativas,
incorporando sistemas de control de gestin para controlar tanto la
propia informacin de las comunicaciones como a los usuarios.
* Control de la gestin de la seguridad de las comunicaciones. La
proteccin de los datos de la red, ya sea utilizando tcnicas
criptogrficas o en casos extremos seguridad fsica. Se recomienda e
uso de herramientas de seguridad.
* Control de la gestin de las comunicaciones desde el punto de vista de
protocolos de comunicaciones implicados en todas las comunicaciones
de la organizacin.
Control de explotacin de la red, a travs de la formacin del personal
adecuado, revisiones de las comunicaciones de la red, escalabilidad y
crecimiento de la red, etc.
La auditoria de la produccin software, donde se verifican los criterios
de adquisicin, desarrollo y mantenimiento de aplicaciones software. La
auditoria comprobar:
Las normas para la adquisicin del software que necesita la
organizacin y un seguimiento de los contratos de compra realizados,
1 Ley Orgnica 15/99 de 13 de Diciembre de Proteccin de D atos de Carcter Personal
402 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
garanta y periodo de pruebas.
El control del correcto funcionamiento de los sistemas informticos
tanto software como hardware y por supuesto la fiabilidad de stos.
La existencia y utilizacin de una metodologa para el ciclo de vida del
desarrollo de sistemas software.
Si el sistema ya est funcionando, se controlarn y evaluarn las
modificaciones en los programas, que debern estar autorizados y por
supuesto, no afectarn al funcionamiento correcto del resto de la
aplicacin.
La creacin de un departamento de Calidad que determinar la vala de
los servicios que ofrece el personal adscrito al departamento de
Informtica. Actualmente existen normas y estndares internacionales
como por ejemplo, la norma IEEE 1028 para la calidad del software y
la norma ISO'9126 tambin para la calidad del software que establecen
una serie procesos y actividades para determinar la calidad de un
producto software.
ANEXO I
Project Management Body O f Knowledge
(PMBOK)
PMBOK son las siglas para "Project Management Body o f Knowledge". Este
documento es el estndard internacional para la Gestin de Proyectos,
publicado por el PMI (www.nmi.oraV
Se trata de la principal publicacin del Standards Committee de PMI que
unifica el lxico, conocimientos, habilidades y prcticas empleados en este
campo. El PMBOK ha sido adoptado por la ANSI como estndar para la
Gestin de Proyectos (ANSI/PMI 99-001-2000). El PMBOK es el documento
usado por el PMI para el examen de Certificacin PMP (Project Management
Professional), que permite que una persona demuestre sus conocimientos y
experiencias relacionadas a la gerencia de proyectos, de una manera estndar y
que es seguido por la mayor parte de las empresas de formacin.
Existen distintas versiones de la gua desde el ao 1996, tambin incorpora
variaciones especficas para distintas industrias (Tecnologas de Informacin,
Construccin, Gobierno). A estas variaciones el PMI las llama Extensions.
Actualmente est vigente la versin 2000 pero El PMI ha anunciado que para
fines del 2004 publicar la nueva versin del PMBOK.
PMBOK contempla dos puntos de vista para la Gestin de Proyectos:
1. Temporal, es decir, el orden cronolgico de las grandes fases del
proyecto. Este primer punto es tratado al principio de la gua dentro del
amplio marco en el que deben desarrollarse los proyectos y su ciclo de
vida. Las fases del ciclo de vida las denomina grupos de procesos y
define los siguientes:
Iniciacin. Reconoce que el proyecto debe comenzar y
compromete a toda la organizacin con ello.
Planificacin. Desarrolla y mantiene un esquema revisable de
tareas a desarrollar para completar el proyecto. Este esquema se
denomina plan del proyecto.
 PL A N IFIC A C I N Y G E S T I N D E SISTE M A S IN FO R M TIC O S
Ejecucin. Coordina a las personas y otros recursos para
desarrollar el plan del proyecto.
Control. Asegura que los objetivos del proyecto sean cumplidos
a travs de la monitorizacin y medicin del avance y toma
acciones correctivas cuando sea necesario.
Cierre. Formaliza la aceptacin del proyecto y permite una
terminacin ordenada.
Categora o tipo de proceso a gestionar, llamado por PMI rea de
conocimiento. En la gua se describen de forma pormenorizada las
nueve reas de conocimiento que universalmente se consideran
comunes a todos los tipos de proyectos. Estas reas se refieren a la
gestin de:
Integracin. Describe las medidas necesarias para garantizar una
coordinacin adecuada de los distintos elementos del proyecto.
Alcance. Describe los pasos que hay que seguir para asegurar
que el trabajo realizado para terminar el proyecto con xito sea
el necesario y no exceda los lmites del campo en cuestin.
Tiempo. Describe los procesos requeridos para asegurar que el
cumplimiento de los tiempos del proyecto.
Costos. Describe las decisiones y medidas a tomar para
garantizar que el coste del proyecto no supere el presupuesto
aprobado.
Calidad. Describe el modo de proceder para conseguir el fin con
el cual el proyecto ha sido concebido satisfaciendo todas las
necesidades definidas.
Recursos Humanos. Describe el mtodo de distribucin del
trabajo entre las personas para lograr el mejor uso de las
cualidades de cada participante en el proyecto.
Comunicacin. Describe los pasos necesarios para realizar a
tiempo la generacin, recopilacin, disposicin,
almacenamiento y difusin de manera puntual y adecuada de la
informacin sobre el proyecto.
Riesgos. Describe las decisiones oportunas para la
identificacin, anlisis y tratamiento de los riesgos que conlleva
el proyecto.
Consecucin. Describe la manera de adquirir productos y
servicios de entidades externas que no pertenecen al mbito de
organizacin del proyecto.
A N EX O 1: l'K O JB C T M A N A G E M E N T B O D Y O F K N O W 1.F D E (P M B O K ) 405
A 1.1 DEFINICIONES Y CONCEPTOS
PMBOK incluye conocimiento de prcticas tradicionales probadas que son
aplicadas en la gestin de proyectos en general y conocimiento de prcticas
avanzadas e innovadoras que son aplicadas en casos especficos. PMBOK
define y explica trminos claves relacionados con la gestin de proyectos y el
mbito donde esta se desarrolla.
Las organizaciones trabajan. El trabajo generalmente involucra operaciones
o proyectos. Las operaciones y los proyectos comparten muchas caractersticas;
por ejemplo son:
Desarrollados por personas.
Limitados por recursos determinados.
Son planificados, ejecutados, y controlados.
Las operaciones y los proyectos difieren principalmente en que las
operaciones son sucesivas y repetitivas mientras que los proyectos son
temporales y nicos. El hecho de que sea temporal implica que tiene definido
un inicio y un fin, cuando los objetivos se han cumplido o se da por verificado
que no pueden cumplirse. El hecho de que sea nico quiere decir que el
producto o servicio es diferente de todos los productos o servicios similares.
Los proyectos pueden desarrollarse por un solo departamento o incluir a
toda la organizacin, pueden durar das o aos e involucrar a pocas personas o
a cientos de ellas. Iodos son proyectos.
La gestin de proyectos es la aplicacin de conocimientos, habilidades,
herramientas y tcnicas a actividades de proyectos de forma que cumplan las
necesidades (requisitos identificados) y expectativas (requisitos no
identificados) de los peticionarios del proyecto. Cumplir estas necesidades o
expectativas significar llegar a un compromiso entre las diferentes personas
involucradas en cuanto a alcance, tiempo, coste y calidad.
Los proyectos y la administracin de proyectos operan en un ambiente ms
amplio que el del proyecto mismo. Administrar da a da las actividades del
proyecto es necesario para el xito de este, pero no suficiente. Hay que definir
un contexto de trabajo y una forma de organizacin que PMBOK establece en
tres apartados: Fases y Ciclo de Vida, Procesos y reas de Conocimiento.
406 PL A N IFIC A C I N Y G E S T I N DE SIST E M A S IN FO R M T IC O S ANEXO I: P R O JE C T M A N A G E M E N T B O D Y O F K N O W L E D G E (P M B O K ) 407

Los procesos orientados al producto que se preocupan principalmente

A1.2 FASES Y CICLO DE VEDA
Ya que los proyectos son tareas nicas que involucraran cierto nivel de
incertidumbre, las organizaciones generalmente dividirn cada proyecto en
fases del proyecto para poder gestionar mejor los enlaces entre las distintas
operaciones de la organizacin debe realizar. Cada fase del proyecto est
marcada por uno o ms entregables. Un entregable es un tangible, un producto
de trabajo verificable. Los entregables, y por tanto las fases, son parte
generalmente de una secuencia lgica diseada para asegurar una definicin
apropiada del producto del proyecto.
La conclusin de una fase de proyecto est generalmente marcada por una
revisin de los entregables y de las actividades realizadas. Esto sirve para
poder determinar si el proyecto puede pasar a la siguiente fase y para detectar y
corregir errores de manera eficiente.
El conjunto de estas fases se conocen como el ciclo de vida del proyecto. El
ciclo de vida del proyecto sirve para definir el comienzo y el final de un
proyecto. La definicin de ciclo de vida del proyecto determinar que acciones
de transicin se incluirn al final del proyecto y cuales no. Tambin define el
trabajo tcnico que debe ser hecho en cada fase y quin debe estar involucrado
en cada una.
en especificar y crear el producto del proyecto.
Los procesos de gestin del proyecto y los orientados al producto
interactan entre s a lo largo de todo el proyecto para obtener los objetivos
planteados.
PMBOK organiza los procesos, como ya hemos visto, en cinco grupos, que
le parecen los ms utilizados. Los grupos de proceso estn encadenados por los
resultados que producen: el resultado u output de uno se convierte en la entrada
o input de otro. Este encadenamiento muchas veces implica retroalimentacin,
actualizndose el trabajo obtenido en fases anteriores.
PMBOK describe las relaciones entre procesos como:
Inputs. Documentos mediante los cuales se actuar.
Herramientas y tcnicas. Mecanismos aplicados a los inputs para crear
los outputs.
Outputs. Documentos que son el resultado de los procesos.
Estos procesos no son eventos de una sola ocurrencia, ocurren con
diferentes niveles de intensidad a lo largo de todas las fases del proyecto, como
se muestra en la figura A 1 . 1 .

No hay que confundir el ciclo de vida del proyecto con el ciclo de vida del
producto.

A1.3 PROCESOS

PMBOK describe la gestin de proyectos en trminos de sus procesos

componentes y de sus interacciones para enfatizar la importancia de la
integracin. La gestin de proyectos es una tarea integrada: una accin o la
falta de ella en un rea usualmente afectar otras reas.

Los proyectos estn compuestos de procesos. Un proceso es una serie de

acciones que tiene como consecuencia un resultado. Los procesos del proyecto
son ejecutados por personas y generalmente se dividen en dos categoras:

Los procesos de gestin de proyectos dedicados a describir y organizar F ig u ra A 1.1 P rocesos y fa s e s

el trabajo del proyecto.
408 PL A N IFIC A C I N Y G ES TIN DC SISTE M A S IN FO R M TICOS
A 1.4 PROCESO DE INICIACION
Reconoce que el proyecto debe comenzar y compromete a toda la organizacin
con ello.
El proceso de Iniciacin contiene un nico subproceso:
Iniciacin. Comprometer a la organizacin para que se de comienzo a la
siguiente fase del proyecto.
A1.5 PROCESO DE PLANIFICACION
Desarrolla y mantiene un esquema revisable de tareas a desarrollar para
completa^ el proyecto. Este esquema se denomina plan del proyecto.
El proceso de Planificacin divide sus subprocesos en dos tipos:
Subprocesos bsicos. Algunos procesos de planificacin tienen unas
dependencias claras que requieren que sean ejecutados de la misma
manera en la mayora de los proyectos. Estos subprocesos pueden ser
repetidos varias veces durante cualquier fase de un proyecto. Son los
siguientes:
o Planificacin del alcance del proyecto. Desarrollar un
documento de alcance del proyecto que sirva de base a
decisiones futuras.
o Definicin del alcance del proyecto. Subdividir las principales
entregas del proyecto en componentes ms pequeos y
manejables.
o Definicin de las actividades. Identificar las actividades
especficas que tienen que ser desarrolladas para poder producir
los entregables del proyecto.
o Secuencia de las actividades. Identificar y documentar las
interdependencias de las actividades.
A N EX O 1: P R O JE C T M A N A G E M E N T B O D Y 01; K N O W L E D G E (P M B O K ) 409
o Estimacin de la duracin de las actividades. Estimar el nmero
de medidas de tiempo de trabajo (lloras, das, semanas, meses,
etc.) que se necesitaran para completar las actividades.
o Desarrollo de la programacin. Analizar la secuencia de las
actividades, la duracin de cada una y las necesidades de
recursos para poder crear la programacin del proyecto.
o Planificacin de recursos. Determinar que recursos (personas,
equipos, materiales, etc.) y que cantidad de cada uno de ellos se
debe utilizar para ejecutar las actividades del proyecto.
o Estimacin de costes. Desarrollar una aproximacin de los
costes de los recursos necesarios para completar las actividades
del proyecto.
o Presupuesto de los costes. Descomponer la estimacin general
de costes entre los tems individuales de trabajo.
o Desarrollo del plan del proyecto. Obtener un solo documento
coherente, y lgico integrando los resultados de otros procesos
de planificacin.
Subprocesos de facilitacin. Las interacciones entre este tipo de
procesos de planificacin dependen ms de la naturaleza del proyecto.
Aunque estos procesos son ejecutados de forma intermitente y cuando
son necesarios durante el proyecto, no son opcionales.
o Planificacin de la calidad. Identificar que estndares de calidad
son relevantes al proyecto y determinar como satisfacerlos.
o Planificacin organizativa. Identificar, documentar, y asignar
roles en el proyecto, responsabilidades y relaciones de
comunicacin.
o Adquisicin del personal. Conseguir los recursos humanos
necesarios, asignarlos y ponerlos a trabajar en el proyecto.
o Planificacin de las comunicaciones. Determinar las
necesidades de informacin y comunicacin entre los
participantes interesados del proyecto: quien necesita que
informacin, cuando la necesitar y como se le entregar.
110 PL A N IF IC A C I N Y G ES TIN D E SIS T E M A S IN FO R M T IC O S
o Planificacin de gestin de riesgos. Establecer el plan de gestin
de riesgos (alcance, componentes, finalidad, organizacin).
o Identificacin del riesgo. Determinar que riesgos posiblemente
afecten al proyecto y documentar las caractersticas de cada uno.
o Anlisis cualitativo de riesgos. Evaluar para cada riesgo
identificado su vulnerabilidad o probabilidad de que ocurra ese
riesgo.
o Anlisis cuantitativo del riesgo. Evaluar para cada riesgo
identificado el impacto que puede producir en el proyecto.
o Desarrollo de la respuesta al riesgo. Definir actividades de
mejora, de minimizacin del riego y de respuesta a amenazas.
o Planificacin de adquisiciones. Determinar que adquirir y
cuando.
o Planificacin de solicitudes. Determinar los requerimientos de
producto e identificar las fuentes potenciales.
A1.6 PROCESO DE EJECUCION
Coordina a las personas y otros recursos para desarrollar el plan del proyecto.
Igual que los procesos de planificacin se dividen en subprocesos bsicos y de
facilitacin. Son los siguientes:
Subprocesos bsicos.
o Ejecucin del plan del proyecto. Desarrollar el plan del proyecto
ejecutando las actividades incluidas en el plan.
Subprocesos de facilitacin.
o Verificacin del alcance del proyecto. Formalizar la aceptacin
del alcance del proyecto.
A N EX O I: P R O JE C T M A N A G E M E N T B O D Y O F K N O W L E D G E (P M B O K ) 411
o Aseguramiento de la calidad. Evaluar el desarrollo del proyecto
de manera regular para asegurarse de que el proyecto va a
satisfacer los estndares relevantes de calidad.
o Desarrollo del equipo. Desarrollar las habilidades individuales y
de grupo para la mejora del desarrollo del proyecto.
o Distribucin de la informacin. Hacer que la informacin
necesaria esle disponible para los participantes interesados del
proyecto de manera oportuna.
o Realizacin de solicitudes. Documentar y hacer pblicas las
solicitudes.
o Seleccin de fuentes. Escoger entre proveedores interesados.
o Administracin del contrato. Administrar las relaciones con el
proveedor.
A1.7 PROCESO DE CONTROL
Asegura que los objetivos del proyecto sean cumplidos a travs de la
monitorizacin y medicin del avance y toma acciones correctivas cuando sea
necesario. Controlar tambin significa llevar a cabo acciones preventivas
anticipndose a posibles problemas. Igual que en los procesos anteriores, se
dividen en subprocesos bsicos y de facilitacin. Son los siguientes:
Subprocesos bsicos.
o Control general de cambios. Coordinar los cambios a travs de
todo el proyecto.
o Informes de actividad. Recoger y difundir la informacin sobre
la actividad del proyecto. Esto incluye informes de estado,
mediciones de avance y pronsticos.
Subprocesos de facilitacin.
o Control de cambios del alcance del proyecto. Controlar los
cambios del alcance del proyecto.
412 PLANIFICACIN Y GESTIN D E SISTEM AS INFORMTICOS ANEXO i: PROJECT MANAGEMENT B Q P Y Q F KNOWLEDGE (PMBOK) 413

o Control de la programacin. Controlar los cambios a la

programacin de proyecto.

o Control de costes. Controlar los cambios al presupuesto del

proyecto.

Gestin de Proyectos
o Control de calidad. Monitorizar resultados especficos del
proyecto para determinar si cumplen con los estndares
relevantes de calidad e identificar las acciones a tomar para
eliminar las causas que producen resultados no satisfactorios. G estin del Tiemoo II Gestin de Intearacin Gestin de Calidad
Definicin de actividades | Desarrollo del plan del proyecto. Planificacin de la calidad
Secuencia de actividades B Ejecucin del plan del proyecto Aseguramiento de la calidad
o Monitorizacin y control de riesgos. Seguir las posibles Estimacin duracin de actividades 1 _ Control general de cambios Control de calidad
Desarrollo de la programacin 1
situaciones de riesgo y los posibles cambios en los riesgos Control de la programacin N

durante la ejecucin de proyecto.

B Gestin de lo s Costes
n Planificacin de recursos
| Estimacin de costes
H Presupuesto de los costes
fl Gestin de Com unicaciones
Planificacin de la comunicacin
Distribucin de la infamacin
Informes de actividad
Cierre administrativo
Gestin de R ecurso s Hum anos
Planificacin organizativa
Adquisicin del personal
Desarrollo det equipo

A1.8 P R O C E S O D E C I E R R E 1 " "

Gestin de R ie sao s G estin del Alcance Gestin de la Adquisicin

Formaliza la aceptacin del proyecto y permite una terminacin ordenada. Los Planificacin de gestin de riesgos Iniciacin Planificacin de adquisiciones
Identificacin de riesgos Planificacin del alcance det proyecto Planificacin de solicitudes
subprocesos de cierre son dos: l_ Anlisis cualitativo de riesgos L Definicin del alcance det proyecto Realizacin de solicitudes
Anlisis cuantitativo del riesgo Verificacin del alcance det proyecto Seleccin de fuentes
Desarrollo de la respuesta al riesgo Control de cambios del alcance del proyectc Administracin del contrato
Monitorizacin v control de riesaos Cierre det contrato
Cierre administrativo. Generar, recoger y difundir la informacin
necesaria para formalizar la terminacin de una fase o del proyecto.
F igura A 1.2 Areas de conocim iento y procesos de gestin de proyectos
Cierre del contrato. Cierre y negociacin del contrato incluyendo la
resolucin de cualquier punto abierto. Las reas de conocimiento de los procesos segn PMBOK se detallan a
continuacin. Para cada rea se listan los procesos que la componen y se
muestra entre parntesis para cada proceso su tipo (Iniciacin, Planificacin,
Ejecucin, Control o Cierre).
A1.9 R E A S DE C O N O C IM IE N T O DE LA G E S T I N I) E
Gestin de Integracin del Proyecto.
PROYECTOS
Es una parte de la gestin de proyectos que incluye los procesos requeridos
El PMBOK define reas de conocimiento (Knowledge Areas) en funcin las
para asegurar que los elementos varios del proyecto estn coordinados
prcticas y los procesos definidos anteriormente. apropiadamente. Consta de:

Todas las reas y sus procesos se muestran resumidos en la figura A 1.2.

Desarrollo del plan del proyecto (Planificacin).
Ejecucin del plan del proyecto (Ejecucin).
Control general de cambios (Control).
414 PL A N IFIC A C I N Y G ESTI N DE S IS T E M A S IN FO R M TIC O S
Gestin del Alcance del proyecto
Es una parte de la gestin de proyectos que incluye los procesos requeridos
para asegurar que el proyecto incluye todo el trabajo necesario, y solo el
necesario, para completar el proyecto con xito. Consta de:
Iniciacin (Iniciacin).
Planificacin del alcance del proyecto (Planificacin).
Definicin del alcance del proyecto (Planificacin).
Verificacin del alcance del proyecto (Ejecucin).
Control de cambios del alcance del proyecto (Control)
Gestin del Tiempo del Proyecto
Es una parte de la gestin de proyectos que incluye los procesos requeridos
para asegurar que el proyecto terminara a tiempo. Consta de:
Definicin de actividades (Planificacin).
Secuencia de las actividades (Planificacin).
Estimacin de la duracin de las actividades (Planificacin).
Desarrollo de la programacin (Planificacin)
Control de la programacin (Control).
Gestin de los Costes del Proyecto
Es una parte de la gestin de proyectos que incluye los procesos requeridos
para asegurar que el proyecto se competa dentro del presupuesto aprobado.
Consta de:
Planificacin de recursos (Planificacin).
Estimacin de costes (Planificacin).
Presupuesto de los costes (Planificacin).
Control de costes (Control).
Gestin de la Calidad del Proyecto
Es una parte de la gestin de proyectos que incluye los procesos requeridos
para asegurar que el proyecto va a satisfacer las necesidades para las cuales fue
puesto en marcha. Consta de:
A NEXO I: P R O JE C T M A N A G E M H N T B O D Y O F K N O W L E D G E (P M B O K ) 4 15
Planificacin de la calidad (Planificacin).
Aseguramiento de la calidad (Ejecucin).
Control de calidad (Control).
Gestin de los Recursos Humanos del Proyecto
Es una parte de la gestin de proyectos que incluye los procesos requeridos
para hacer un uso ms efectivo de las personas involucradas con el proyecto.
Consta de:
Planificacin organizativa (Planificacin).
Adquisicin del personal (Planificacin).
Desarrollo del equipo (Ejecucin).
Gestin de las Comunicaciones del Proyecto
Es una parte de la gestin de proyectos que incluye los procesos requeridos
para asegurar la generacin, recopilacin, difusin, almacenamiento, y
disponibilidad de la informacin del proyecto de forma apropiada y a tiempo.
Consta de:
Planificacin de las comunicaciones (Planificacin).
Distribucin de la informacin (Ejecucin).
Informes de actividad (Control).
Ciee administrativo (Cierre).
Gestin del Riesgo del Proyecto
Es una parte de la gestin de proyectos que incluye los procesos que se ocupan
de identificar, analizar, y responder a los riesgos del proyecto. Consta de:
Planificacin de gestin de riesgos (Planificacin).
Identificacin de riesgos (Planificacin).
Anlisis cualitativo de riesgos (Planificacin).
Anlisis cuantitativo del riesgo (Planificacin).
Desarrollo de la respuesta al riesgo (Planificacin).
Monitorizacin y control de riesgos (Control).
416 PL A N IFIC A C I N Y G E S T I N D E SIST E M A S IN FO R M T IC O S
Gestin de la Adquisicin del Proyecto
Es una parte de la gestin de proyectos que incluye los procesos requeridos
para adquirir bienes y servicios de entidades externas a la organizacin. Consta
de:
Planificacin de adquisiciones (Planificacin).
Planificacin de solicitudes (Planificacin).
Realizacin de solicitudes (Ejecucin).
Seleccin de fuentes (Ejecucin).
Administracin del contrato (Ejecucin).
Cierre del contrato (Cierre).
A l . 10 V E R S I N 2004
El Project Management Institute ha emitido la ltima versin del PMBOK que
ser publicada a fines del 2004. En el prefacio al borrador de esta tercera
edicin del PMBOK, PMI explica el alcance del proyecto de actualizacin de
la versin 2000 del PMBOK citando los siguientes puntos:
Cambiar los criterios para la inclusin de material pasando de
generalmente aceptados en la mayor parte de los proyectos la mayor
parte del tiempo a generalmente reconocidos corno buenas prcticas
en la mayor parte de los proyectos la mayor parte del tiempo. De esta
forma se hace hincapi en que el conocimientos y prcticas descritas se
aplican a la mayor parte de proyectos la mayor parte del tiempo, y que
hay un consenso amplio sobre su utilidad y valor.
Aadir nuevo material que refleje el crecimiento de las prcticas y
conocimientos en el campo de la gestin de proyectos documentando
aquellas prcticas, herramientas y tcnicas u otros tems relevantes que
generalmente se reconocen como buenas prcticas.
Ampliar la importancia y el tratamiento de los Grupos de Procesos.
Ampliar el tratamiento de la integracin y transmitir de una manera ms
apropiada su importancia para los proyectos.
AN EX O 1: P R O JE C T M A N A G E M E N T B O D Y O r; K N O W L E D E (P M B O K ) 417
Ampliar el tratamiento del Grupo de Procesos de Iniciacin para
describir de una manera ms precisa el inicio del proyecto y el
comienzo de cada fase cuando sea necesario.
Evaluar todos los procesos para asegurar que han sido puestos en el
lugar correcto y que son completos y claros.
Revisar todo el texto para asegurar que sea claro, completo y relevante.
Asegurar la consistencia en la terminologa y ubicacin de entradas,
salidas, herramientas y tcnicas de los procesos. Identificar el origen de
todas las entradas y el destino de todas las salidas.
Cambiar el texto cuando sea posible con el fin de mejorar la
traducibilidad del documento y considerar palabras y frases que puedan
tener connotaciones culturales negativas.
Ampliar el ndice y el glosario.
Corregir errores existentes en el documento anterior.
Las principales diferencias entre la versin anteriormente desarrollado en
este libro (versin 2000 ) con el borrador de la nueva versin (versin 2004)
son las siguientes:
1. Se ha clarificado la distincin entre los ciclos de vida del
proyecto y ciclo de vida del producto.
2. Se han incrementado los procesos definidos de 39 a 44.
3. Se ha expandido el foco de los Grupos de Procesos y procesos
versus las reas de conocimiento.
4. Se ha cambiado de nombre y lugar al Captulo 3 (Los Procesos
de Gestin de Proyectos para el proyecto). Como parte de este
cambio se ha revisado en profundidad el Captulo 3 sobre los
procesos de la gestin de proyectos con el fin de indicar que los
procesos, entradas y salidas mencionadas en este captulo son la
base del estndar para la gestin de proyectos en un proyecto
nico. Se han reubicado los procesos de la gestin de proyectos
418 P L A N IFIC A C I N Y G E S T I N DE SISTE M A S IN FO R M TIC O S A N EX O 1: P R O JE C T M A N A G E M E N T B O D Y O F K N O W L E D G E ( PM H O K > 419

con el fin de mostrar la integracin de los procesos. Se lian
aadido seis procesos y se ha cambiado el nombre a 14
procesos.
5. Se ha ampliado el Grupo de Procesos de Inicio y el Grupo de
Procesos de Cierre.
6 . Se ha aadido Monitorizacin al Grupo de Procesos de Control
ya existente.
7. Se ha enfatizado la necesidad de mencionar los cinco Grupos de
Procesos y sus procesos constitutivos en cada proyecto.
8. Se ha revisado y ampliado la discusin de la integracin y su
importancia para la gestin del proyecto y para su xito. Este
cambio proporciona ms detalles de las interrelaciones entre los
procesos, incluyendo los procesos de inicio y cierre del
proyecto.
9. Se ha aadido una seccin que identifica las reas de
experiencia necesaria para un proyecto, dada la gran cantidad de
reas en las que el equipo de proyecto debe tener competencia.
10. Se ha ampliado la descripcin los distintos usos de la Oficina de
Gestin de Proyectos en las organizaciones {Project
Management Office)
Se introdujo un nuevo diagrama denominado Estructura de
Descomposicin de los Riesgos (Risk Breakdown Structure).
15. Se ha ahora incluido informacin sobre retroalimentacin
{feedback) y sobre las reuniones de revisin del estado del
proyecto para acentuar la importancia de estos procesos en la
comunicacin en el proyecto.
16. Todas las entradas, herramientas y tcnicas y salidas se han
revisado para soportar una mejor integracin de los procesos.
17. El glosario se ha revisado significativamente y se han aadido
trminos. Algunos trminos se han clasificado para evitar
confusiones.
18. Se han aadido los siguientes procesos:
Desarrollo del Chartcr del Proyecto (Seccin 4.1)
Desarrollo del Documento del Alcance del Proyecto
(Seccin 4.2).
Monitorizacin y Control del Trabajo del Proyecto
(Seccin 4.5)
Cierre del Proyecto (Seccin 4.7)
Crear el WBS (Seccin 5.3)
Estimacin de los Recursos para las Actividades
(Seccin 6.3)
Gestionar al Equipo del Proyecto (Seccin 9.4)

11. Se ha ampliado el proceso de preparacin de la estructura de

descomposicin del proyecto ( Work Breakdown Structure -
WBS), aadiendo una nueva seccin con tcnicas y herramientas
de WBS.
12. Se ha ampliado informacin sobre la influencia en la
planificacin del proyecto de la informacin de seguimiento y el
control de costes y recursos, aclarando el uso del mtodo de
diagrama de flechas y el mtodo de diagrama de precedencias.

13. Se ha ampliado la informacin sobre el proceso de control de

costes, incluyendo herramientas y tcnicas, actividades de
contingencia y gestin de contingencia.

14. Se ha aadido informacin sobre las categoras de riesgos,

supuestos, probabilidad, impacto y la lista de gestin de riesgos.
 420 PL A N IFIC A C I N Y G ESTI N D E SIST E M A S IN FO R M T IC O S

ANEXO II
r
r Gestin de Proyectos de la Administracin
f Publica Espaola (METRICA)
(
(
(
MTRICA es una metodologa de planificacin, desarrollo y mantenimiento de
r
sistemas de informacin. La metodologa de desarrollo de sistemas METRICA
( fue diseada por la Subdireccin General de Coordinacin Informtica del
( Ministerio para las Administraciones Pblicas ante la necesidad de disponer de
r una Tecnologa de la Informacin que soportara dinmica y eficazmente el
( funcionamiento normal de los distintos departamentos que componen la
Administracin a medida que creca el volumen de informacin a manejar pol
(
la misma. Esta metodologa y las tcnicas y herramientas aconsejadas estn
r
disponibles en la Web del Consejo Superior de Informtica: vvww.map.es/csi.
r
( La metodologa METRICA Versin 3 ofrece a las Organizaciones un
r instrumento til para la sistematizacin de las actividades que dan soporte al
c ciclo de vida del software dentro del marco que permite alcanzar los siguientes
objetivos:
r
( Proporcionar o definir Sistemas de Informacin que ayuden a conseguir
( los fines de la Organizacin mediante la definicin de un marco
r estratgico para el desarrollo de los mismos.
(
( Dotar a la Organizacin de productos software que satisfagan las
necesidades de los usuarios dando una mayor importancia al anlisis de
(
requisitos.
(
( Mejorar la productividad de los departamentos de Sistemas y
( Tecnologas de la Informacin y las Comunicaciones, permitiendo una
( mayor capacidad de adaptacin a los cambios y teniendo en cuenta la
< reutilizacin en la medida de lo posible.
<
Facilitar la comunicacin y entendimiento entre los distintos
(
participantes en la produccin de software a lo largo del ciclo de vida
(
(
(
422 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
del proyecto, teniendo en cuenta su papel y responsabilidad, as como
las necesidades de todos y cada uno de ellos.
Facilitar la operacin, mantenimiento y uso de los productos software
obtenidos.
En el desarrollo de METRICA se han considerado las metodologas y
proyectos de estandarizacin en curso siguientes:
SSADM: Metodologa Pblica Britnica.
MER1SE: Metodologa Pblica Francesa.
SUMMIT-D: Metodologa de Coopers & Lybrard.
EUROMTODO: Marco Metodolgico Europeo.
Plan General de Garanta de Calidad aplicable al desarrollo de equipos
lgicos.
MTRICA Versin 3 tiene un enfoque orientado al proceso
Proceso de Desarrollo y el Proceso de Mantenimiento de
Informacin. La metodologa descompone cada uno de los
actividades, y stas a su vez en tareas. As los procesos de
principal de MTRICA Versin 3 son los siguientes:
PLANIFICACIN DE SISTEMAS DE INFORMACIN (PSI).
DESARROLLO DE SISTEMAS DE INFORMACIN.
MANTENIMIENTO DE SISTEMAS DE INFORMACIN (MSI).
En cuanto al Proceso de Desarrollo de Sistemas de Informacin, para
facilitar la comprensin y dada su amplitud y complejidad se ha subdividido en
cinco procesos:
ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS).
ANLISIS DEL SISTEMA DE INFORMACIN (ASI).
DISEO DEL SISTEMA DE INFORMACIN (DSI).
CONSTRUCCIN DEL SISTEMA DE INFORMACIN (CSI).
IMPLANTACIN Y ACEPTACIN DEL SISTEMA (IAS).
En una nica estructura la metodologa MTRICA Versin 3 cubre
distintos tipos de desarrollo: estructurado y orientado a objetos, facilitando a
travs de interfaces la realizacin de los procesos de apoyo u organizativos:
GESTIN DE PROYECTOS (GP).
A N E X O I I : G E S T I N DI: P R O Y E C T O S D E LA A D M IN IS T R A C IO N P B L IC A E S P A O L A (M E T R IC A ) 423
GESTIN DE CONFIGURACIN (GC).
ASEGURAMIENTO DE CALIDAD (CAL).
SEGURIDAD (SEG).
A2.1 INTERFAZ DE GESTIN DE PROYECTOS I)E MTRICA
VERSIN 3
La Gestin de Proyectos tiene como finalidad principal la planificacin, el
seguimiento y control de las actividades y de los recursos humanos y
materiales que intervienen en el desarrollo de un Sistema de Informacin.
Como consecuencia de este control es posible conocer en todo momento qu
problemas se producen y resolverlos o paliarlos de manera inmediata.
La Interfaz de Gestin de Proyectos de MTRICA Versin 3 contempla
que cubre el proyectos de desarrollo de Sistemas de Informacin en sentido amplio. Es
Sistemas de decir, acorde con EUROMTODO se consideran proyectos de desarrollo de
procesos en nuevos Sistemas de Informacin y tambin los proyectos de ampliacin y
la estructura mejora de los ya existentes; estos ltimos, contemplados en MTRICA
Versin 3 al proceso de Mantenimiento del Sistema de Informacin (MSI).
Las actividades de la Interfaz de Gestin de Proyectos se presentan en el
siguiente esquema, en el que se aprecian las reas que cubre. Se distinguen tres
grupos de actividades:
Actividades de Inicio del Proyecto (GPI). AI principio del proyecto, al
concluir el proceso Estudio de Viabilidad del Sistema, se realizarn las
actividades de Estimacin de Esfuerzo y Planificacin del proyecto.
Actividades de Seguimiento y Control (GPS). Comprenden desde la
asignacin de las tareas hasta su aceptacin interna por parte del equipo
de proyecto, incluyendo la gestin de incidencias y cambios en los
requisitos que puedan presentarse y afectar a la planificacin del
proyecto. El Seguimiento y Control del proyecto se realizan durante los
procesos de Anlisis, Diseo, Construccin, Implantacin y
Aceptacin, y Mantenimiento del Sistema de Informacin, para vigilar
el correcto desarrollo de las actividades y tareas establecidas en la
planificacin.
4 24 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Actividades de Finalizacin del Proyecto (GPF). Por ltimo, al concluir
el proyecto se realizan las tareas propias de Cierre del Proyecto y
Registro de la Documentacin de Gestin.
La figura A 2.1 muestra la relacin entre la interfaz de Gestin de
Proyectos y los procesos principales de METRICA.
F ig u ra A2.1 R ela ci n entre la s actividades d e G e sti n de P ro yecto s y los p ro c eso s
p rin c ip a les de M T R IC A V3
Antes de detallar cada una de las actividades de esta interfaz explicaremos
brevemente el nacimiento y la funcin de la metodologa EUROMETODO a la
que se hace referencia en alguna de estas actividades.
A2.2 EUROM TODO
EUROMETODO es una metodologa para la adquisicin de sistemas de
informacin y servicios relacionados, desarrollada en el marco de un proyecto
del mismo nombre, bajo supervisin de la Comisin Europea. La versin en
espaol de EUROMTODO v i, la versin ms reciente, ha sido publicada por
el MAP en 1998.
El resultado, EUROMTODO v i, es un documento con dos orientaciones
diferentes: como marco metodolgico y como mtodo propiamente dicho.
Como marco metodolgico proporciona un conjunto de conceptos y una
terminologa:
para mejorar la relacin cliente-proveedor
para armonizar los mtodos
A N E X O II: G E S T I N D E P R O Y E C T O S DE LA A D M IN IS T R A C I N P U B L IC A E S PA O L A (M E T R IC A ) 425
Como mtodo sirve para definir, planificar y ejecutar la adquisicin de un
sistema de informacin y los servicios relacionados. Se utiliza para valorar y
determinar:
la situacin del problema y los riesgos asociados
el objetivo de la adquisicin
la estrategia de ia adquisicin, de la adaptacin del sistema de
informacin y de la provisin de servicios
el "plan de entregas", el aspecto ms relevante de las relaciones cliente-
proveedor a nivel contractual.
EUROMETODO no se ocupa de aspectos legales ni es un mtodo de
desarrollo de software.
El Ministerio de Administraciones Pblicas ha participado en la iniciativa
EUROMTODO desde su lanzamiento, incluido un ejercicio de validacin de
EUROMETODO versin 0 en base a un proyecto propio, con la supervisin de
un grupo de trabajo, el Foro Espaol de EUROMETODO (FOREM), en el que
se dieron cita todas las instancias interesadas en esta iniciativa:
Administraciones pblicas, proveedores informticos, asociaciones de
profesionales y organizaciones de normalizacin y calidad.
Terminado el proyecto comunitario, el MAP se ha hecho cargo de la
publicacin del mtodo, y el Consejo Superior de Informtica ha incorporado
EUROMTODO como un documento de referencia ms para su trabajo de
produccin de recomendaciones y normativa en las reas de adquisiciones y de
desarrollo de tecnologas de la informacin para las Administraciones Pblicas.
A2.3 ACTIVIDADES DE INICIO DEL PROYECTO (GPI)
Las actividades al inicio de un proyecto tienen un doble objetivo: estimar el
esfuerzo a realizar para desarrollar el sistema y planificar las actividades de
dicho desarrollo. Para ello, tomando como punto de partida la Solucin
Propuesta en el Estudio de Viabilidad del Sistema (EVS 6), se identifican los
elementos a desarrollar, se calcula el esfuerzo a realizar, y se planifican las
actividades del proyecto comprendiendo los aspectos de recursos,
programacin de tareas y establecimiento de un calendario de entregas y
recepciones entre el cliente y los proveedores.
A ctividad GPI 1: E stim acin de Esfuerzo
42 6 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M A T IC O S
F.1 objetivo de esta actividad es conocer el tamao aproximado del sistema a
desarrollar, y establecer el coste, la duracin y los recursos necesarios para
conseguir desarrollarlo.
Esta actividad se compone de las siguientes tareas:
Tarca GPI 1.1: Identificacin de Elementos a Desarrollar. Esta tarea
tiene como finalidad determinar el nmero y caractersticas de los
elementos a desarrollar a partir del modelo de descomposicin en
subsistemas de la alternativa seleccionada.
Tarea GPI 1.2: Clculo del Esfuerzo. Una vez identificados los
elementos a desarrollar se utilizar la tcnica de estimacin apropiada
para calcular el esfuerzo necesario para su desarrollo. Deben tenerse en
cuenta tambin trabajos que no estn encaminados directamente al
desarrollo de elementos del proyecto. Si el desarrollo es estructurado se
pueden emplear el Mtodo Albretch o el Mtodo MARK II para el
Anlisis de los Puntos Funcin. En el caso de orientacin a objetos, se
pueden aplicar las mtricas de estimacin del esfuerzo Staffmg Size.
Actividad GPI 2: Planificacin
El objetivo de esta actividad es definir y preparar las condiciones de trabajo,
estableciendo recursos, fechas y costes, para lograr los objetivos que se
persiguen con el proyecto.
Esta actividad se compone de las siguientes tareas:
Tarea GPI 2.1: Seleccin de la Estrategia de Desarrollo. El objetivo de
esta tarea es elegir la estrategia de desarrollo ms adecuada al proyecto
en funcin de las caractersticas de este, tales como su criticidad,
tamao y complejidad. EUROMETODO ofrece una buena
aproximacin a distintas estrategias de desarrollo, que pueden servir a
ttulo orientativo:
o Clsica o en cascada. Es la opcin estratgica Construccin de
una vez de EUROMETODO. Se considera el proyecto como
un todo, dividido en procesos, y cada proceso no comienza hasta
que finaliza el anterior,
o Por subsistemas. En EUROMETODO esta estrategia se conoce
corno Construccin incremental. Se divide el sistema en
A N E X O II : G E S T I N D E P R O Y E C T O S D E LA A D M IN IS T R A C I N P B L IC A E S P A O L A (M E T R IC A ) 427
subsistemas semi-independientes con estructura, organizacin y
objetivos diferentes,
o Por prototipo. Tambin denominado Construccin evolutiva
en EUROMETODO. Esta aproximacin genera un prototipo
funcional en los primeros procesos del proyecto que se va
completando en sucesivas evaluaciones y revisiones aadiendo
nuevas funcionalidades y mejoras,
o Hbrida. Contempla un desarrollo por subsistemas, que a su vez
se desarrollan bajo una estrategia o enfoque diferente de los
dems.
Tarea GPI 2.2: Seleccin de la Estructura de Actividades, Tareas y
Productos. En esta tarea se selecciona la estructura del proyecto,
estableciendo los procesos principales de desarrollo de MTRICA
Versin 3 que lo integran. Para cada proceso se determinan las
actividades y tareas a realizar, as como los productos a generar, en
funcin de las caractersticas concretas del proyecto.
Tarea GPI 2.3: Establecimiento del Calendario de Hitos y Entregas.
Esta tarea tiene como objetivo establecer los plazos de realizacin de
las actividades y tareas del proyecto, las fechas en que se producirn las
entregas y aquellas en que deben recibirse los productos adquiridos y
los trabajos encargados a terceros. Asimismo, se establecen los hitos o
puntos de control y se detallan los condicionantes y restricciones
existentes.
Tarea GPI 2.4: Planificacin Detallada de Actividades y Recursos
Necesarios. El objetivo de esta tarea es la asignacin de recursos
necesaria en funcin de los distintos perfiles implicados y la
planificacin detallada de actividades y tareas, recursos y plazos para
poder concretar con exactitud el plan de costes del proyecto.
Tarea GPI 2.5: Presentacin y Aceptacin de la Planificacin General
del Proyecto. El objetivo de esta tarea es la presentacin de la
Planificacin General del Proyecto al Comit de Seguimiento para su
aprobacin.
A2.4 ACTIVIDADES DE SEGUIMIENTO Y CONTROL (GPS)
428 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S A N E X O II: G E S T I N DE P R O Y E C T O S D E L A A D M IN IS T R A C I N P B L IC A E S P A O L A (M I-T R IC A ) 429

El seguimiento y control del proyecto tiene como objetivo fundamental la El objetivo de esta actividad es la asignacin de tareas a los miembros del
vigilancia de todas las actividades de desarrollo del sistema. Es una de las equipo de proyecto, documentando los datos necesarios para su control
labores ms importantes en todo desarrollo de sistemas, ya que un adecuado posterior.
control hace posible evitar desviaciones en costes y plazos, o al menos
detectarlas cuanto antes. Esta actividad tiene una nica tarea:

La figura A2.2 muestra la secuencia de actividades de Seguimiento y Tarea GPS 1.1: Asignacin de Tarea. Para que una tarea finalice con
Control del Proyecto: xito es importante asignarla a un tcnico capaz de desarrollarla, por lo
que el Jefe de Proyecto debe estudiar muy bien cada tarea antes de su
GPS6
Aribsisde GPS7
Aprobacin
asignacin y ser consciente de los conocimientos y capacidades de los
la peticin
delasoludt
requisitos
de cambio componentes del equipo de proyecto. El Jefe de Proyecto debe reflejar
en la planificacin las asignaciones realizadas, indicando el nombre del
tcnico, nombre y descripcin de la tarea, esfuerzo estimado, fecha real
GPS1 GPS 2 GPS 3 GPS10 GPS12
GPS 13
Asignacin Corrunioao Seguimenti Fmazacit
efe ricrea
_ Reunrcnesch
seguimento Aceptacin de comienzo y fecha prevista de finalizacin.
delatada alequpo detareas
de tareas del proyecto pianificaceli

Actividad GPS 2: Comunicacin al equipo del proyecto

Una vez que el Jefe de Proyecto dispone de la asignacin de tareas, convoca

una reunin para informar al equipo de proyecto de las caractersticas del
F ig u ra A 2.2. A ctiv id a d e s d e Seg u im ien to y C o n tro l d e l P ro yecto mismo y comunicar a cada miembro las tareas especficas que va a desarrollar.

Dentro de las actividades de Seguimiento y Control se trata de manera Esta actividad tiene una nica tarea:
especial la Gestin de Incidencias, que puede ser la clave del xito o fracaso de
un proyecto. Incidencias son aquellos hechos inesperados y anmalos que se Tarea GPS 2.1: Informar al Equipo del Proyecto. El Jefe de Proyecto
presentan durante la realizacin de las actividades y tareas del proyecto, y que informa a los integrantes del equipo de las caractersticas del proyecto,
producen desviaciones en la planificacin. haciendo especial nfasis en sus caractersticas particulares. Una vez
que todos los miembros del equipo conocen el proyecto global,
Mencin especial merecen los cambios de requisitos, ya que son un tipo comunica la asignacin de trabajos a cada uno de los miembros.
especial de incidencia que exige un tratamiento especial. Uno de los propsitos
del establecimiento de procedimientos para la Gestin de Cambios en los Actividad GPS 3: Seguimiento de tarcas
Requisitos es el de asegurar que, cuando existan cambios en los
requerimientos, su impacto en el proyecto pueda cuantificarse y acordarse con Esta actividad tiene como objetivo el control de todas las tareas que estn
el Cliente o Usuario en cuanto a plazo, esfuerzo y compensacin econmica si siendo desarrolladas, revisando con cada uno de los responsables de las tareas
corresponde. Adems, para cada cambio, se registrar la siguiente informacin: cul es su estado en el momento del seguimiento, su evolucin previsible y los
Formulario de Peticin de Cambio. problemas que estn encontrando para su desarrollo.
Catlogo de Necesidades.
Anlisis Funcional del Cambio. Esta actividad tiene una nica tarea:
Estimacin de Esfuerzo.
Variaciones en Coste y Plazos. Tarea GPS 3.1: Seguimiento de Tareas. El responsable de cada tarea
debe informar de:
A ctividad GPS I: A signacin d etallada de tareas
o La fecha real de comienzo.
430 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
o El tiempo empleado hasta el momento en su realizacin,
o Apreciacin del tiempo que queda para terminarla,
o El tanto por ciento de avance sobre el total,
o Los problemas o incidencias encontradas.
A partir de la informacin obtenida del equipo de desarrollo, el Jefe de
Proyecto debe determinar el estado de cada tarea, indicando la previsin
de finalizacin de cada una. Asimismo, debe prestar atencin a las
incidencias y desviaciones.
Actividad GPS 4: Anlisis y registro de la incidencia
Con esta actividad se persigue conocer el impacto producido por una
incidencia en cuanto a:
Tareas afectadas por la incidencia.
Horas de trabajo perdidas.
Retrasos ocasionados.
Esta actividad se compone de las siguientes tareas:
Tarea GPS 4.1: Analizar Impacto. Es fundamental conocer que tareas se
vern afectadas por una incidencia, en mayor o menor grado, para
poder realizar una evaluacin del coste de la misma. Una vez
identificadas las tareas a las que afecta la incidencia se evala su
impacto en trminos de:
o Horas necesarias para resolverla,
o Retrasos previstos,
o Recursos afectados.
Tarea GPS 4.2: Propuesta de Solucin de la Incidencia. Dependiendo
del tipo de incidencia se plantean posibles alternativas de solucin. El
Jefe de Proyecto elegir entre las alternativas propuestas la forma de
solucionar la incidencia, designando en su caso al miembro o miembros
del equipo de proyecto encargados de realizar los trabajos. De acuerdo
con la solucin adoptada habr que revisar y ajustar la planificacin del
proyecto.
Tarea GPS 4.3: Registrar la Incidencia. El objetivo de esta tarea es
doble: por una parte se intenta resaltar los sucesos que inciden
negativamente sobre el desarrollo del proyecto para que se adopten las
ANEXO I I : G E S T I N D E P R O Y E C T O S DO LA A D M IN IS T R A C I N P B L IC A E S P A O L A (M E T R IC A ) 431
medidas necesarias de forma que no vuelvan a producirse o, al menos,
que se reduzcan en la mayor medida posible, y por otra parte para que
los costes originados por dichas incidencias sean imputados a quien
corresponda. Toda incidencia producida durante el desarrollo del
proyecto debe reflejarse en el Registro de Incidencias.
Actividad GPS 5: Peticin de cambios de requisitos
La primera actividad en la Gestin de Cambios es la peticin realizada por el
usuario para alterar las especificaciones iniciales.
Esta actividad tiene una nica tarea:
Tarea GPS 5.1: Registro de la Peticin de Cambio de Requisitos. El
usuario formula una peticin de cambio de los requisitos iniciales, que
hace llegar al Jefe de Proyecto. Cuando el Jefe de Proyecto la recibe
debe registrarla de inmediato.
Actividad GPS 6: Anlisis de la peticin de cambio de requisitos
Toda peticin de cambio debe ser analizada en detalle por el Equipo del
Proyecto, contemplando los posibles cambios en la funcionalidad y el impacto
que el cambio pedido tendra sobre el resto del Sistema de Informacin.
Esta actividad se compone de las siguientes tareas:
Tarea GPS 6 .1: Estudio de la Peticin de Cambio de Requisitos. El Jefe
de Proyecto entrega la peticin de cambio al Equipo del Proyecto para
su estudio, en el que participa el usuario si es necesario.
Tarea GPS 6.2 Impacto de la Peticin de Cambio de Requisitos. Una
vez conocidas las nuevas necesidades, el Equipo del Proyecto por
medio de sus analistas realizar un anlisis funcional de alto nivel de
los nuevos requerimientos y el correspondiente diseo tcnico a
grandes rasgos.
Tarea GPS 6.3 Estudio de Alternativas y Propuesta de Solucin. A
partir del Anlisis Funcional y Diseo Tcnico obtenido en la tarea
anterior, el Jefe de Proyecto y el Equipo de Proyecto estudiarn las
posibles alternativas de solucin, considerando para cada alternativa los
recursos, esfuerzo, tiempo y coste que supone, presentando la ms
adecuada al Comit de Seguimiento para su aprobacin.
43 2 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
Actividad GPS 7: Aprobacin de la solucin
Esta actividad tiene como objeto que el Comit de Seguimiento considere la
solucin propuesta en la actividad anterior y decida sobre la procedencia o
improcedencia del cambio de requisitos.
Esta actividad tiene una nica tarea:
Tarea GPS 7.1: Aprobacin de la Solucin. Es necesario que el Comit
de Seguimiento est de acuerdo con los costes que el cambio va a
ocasionar y con la dilatacin que se producir en los plazos de entrega.
La peticin puede ser rechazada, aprobada, pospuesta o enviada a
revisin en cuanto a la solucin adoptada.
Actividad GPS 8: Estimacin del esfuerzo y planificacin de la solucin
Una vez aprobada la peticin de cambio de requisitos y previo a iniciar el
desarrollo de la solucin, es preciso estimar con mayor detalle el esfuerzo que
el cambio supone y planificar las actividades necesarias para la realizacin del
cambio de requisitos.
Esta actividad se compone de las siguientes tareas:
Tarea GPS 8.1: Estimacin de Esfuerzo para el Cambio. A partir de la
solucin aprobada para la peticin de cambio, es necesario hacer una
estimacin del esfuerzo requerido para llevarla a cabo. Para ello habr
que realizar las mismas operaciones que en la actividad GPI 1, pero
teniendo en cuenta si la parte del sistema que hay que modificar est
totalmente desarrollada, parcialmente desarrollada o sin desarrollar,
para descontar o no el esfuerzo correspondiente en la estimacin
original.
Tarea GPS 8.2: Planificacin de los Cambios. Una vez hecha la
estimacin del esfuerzo es necesario planificar las actividades
necesarias para la realizacin del cambio, de la misma forma que en la
actividad GPI 2.4 o la GPS 11.1, utilizando la tcnica de planificacin
ms apropiada.
A ctividad G PS 9: R egistro del cam bio de requisitos
A N E X O I I : G E S T I N DE P R O Y E C T O S D E LA A D M IN IS T R A C I N P B L IC A E S P A O L A (M E T R IC A ) 433
lodo cambio de requisitos producido durante el desarrollo del proyecto debe
reflejarse en el Registro de Cambios de Requisitos.
Esta actividad tiene una nica tarea:
I'area GPS 9.1: Registro del Cambio de Requisitos. Al registrar el
cambio de requisitos se deja constancia de la solucin adoptada y de su
impacto en el desarrollo del proyecto.
Actividad GPS 10: Finalizacin de la tarea
Debe quedar registro en la ficha de asignacin de la tarea de su finalizacin,
esfuerzo empleado y aprobacin del responsable.
Esta actividad tiene una nica tarea:
Tarea GPS 10.1: Comprobacin de la Tarea. El miembro del equipo del
proyecto al que se le ha asignado al desarrollo de una tarea es quien est
en disposicin de darla por concluida, reflejando en la ficha de
asignacin de tarea la fecha de finalizacin y el esfuerzo real empleado.
El Jefe de Proyecto o el responsable deber comprobar que la tai'ea ha
finalizado correctamente, firmando la ficha de asignacin de tareas con
los datos relativos a su finalizacin.
Actividad GPS 11: Actualizacin de la planificacin
A medida que se van finalizando las tareas y una vez que son comprobadas
habr que actualizar la planificacin, ya que puede que se hayan producido
desviaciones. Adems se preparar una previsin de lo que puede ocurrir en el
futuro al considerar la nueva situacin, y se elaborar un informe de
seguimiento.
Esta actividad se compone de las siguientes tareas:
Tarea GPS 11.1: Actualizacin de Tareas. Con los datos obtenidos en el
Seguimiento de Tareas (GPS 3.1), Gestin de Incidencias (GPS 4.2) y
Cambios de Requisitos (GPS 8.2), el Jefe de Proyecto debe actualizar la
Planificacin detallada del Proyecto para adecuar el estado de cada
tarea a la situacin real.
Tarea GPS 11.2: Obtencin de la Extrapolacin, el Jefe de Proyecto y el
Comit de Seguimiento deben conocer con exactitud cual ser la
evolucin flitura del proyecto si contina desarrollndose tal y como
43 4 P L A N IF IC A C I N Y G E S T I N D E S IS T E M A S IN F O R M T IC O S
hasta ahora. Para conocer este dato es necesario extrapolar los
resultados obtenidos en el momento del seguimiento.
Tarea GPS 11.3: Elaboracin del Informe de Seguimiento. A partir de
la informacin obtenida en las tareas anteriores, el Jefe de Proyecto
debe elaborar un informe que recoja los objetivos alcanzados durante el
perodo, incidencias y desviaciones detectadas junto con las acciones
encaminadas a corregirlas, objetivos que se prevn para el siguiente
perodo y las variaciones en el equipo de proyecto y en los recursos
materiales.
Actividad GPS 12: Reuniones de seguimiento
Las reuniones de seguimiento tienen lugar entre el Jefe y el Equipo del
Proyecto (internas) o entre el Jefe de Proyecto y el Comit de Seguimiento
(externas). Su finalidad es presentar la informacin sobre la marcha del
proyecto y estudiar las posibles desviaciones e incidencias, tomando decisiones
o adquiriendo compromisos para determinar y realizar las acciones apropiadas
que resuelvan dichas desviaciones o incidencias.
Esta actividad tiene una nica tarea:
Tarea GPS 12.1: Reunin Interna de Seguimiento. Cuando el Jefe de
Proyecto tiene toda la informacin sobre la marcha del proyecto y el
seguimiento de tareas (GPS 3.1), debe reunirse con todo el equipo del
proyecto para terminar de analizar las desviaciones.
Actividad GPS 13: Aceptacin
La aceptacin interna consiste en la verificacin por el Equipo del Proyecto del
cumplimiento de las especificaciones de un conjunto de tareas. Este es un paso
previo a la aceptacin por parte del Cliente.
Esta actividad tiene una nica tarea:
Tarea GPS 13.1: Verificacin de Aceptacin Interna. El Jefe de
Proyecto debe verificar personalmente que los resultados de las
actividades son los esperados. En este caso deber expresar su
aceptacin en el acta correspondiente.
A N E X O II: G E S T I N D E P R O Y E C T O S D E LA A D M IN IS T R A C I N P U B L IC A E S P A O L A (M E T R IC A ) 435
A2.5 ACTIVIDADES DE FINALIZACIN DEL PROYECTO
(GPF)
No se puede considerar terminado un proyecto hasta que el Cliente o Usuario
expresa su conformidad. Cuando un proyecto concluye es necesario realizar las
tareas asociadas al Cierre del Proyecto.
Actividad GPF 1: Cierre del Proyecto
Esta actividad consiste en resumir los datos del proyecto, en cuanto a
funcionalidad, tecnologa, equipo tcnico, formacin recibida, experiencias,
logros, problemas encontrados y, en general, cualquier dato que el Jefe de
Proyecto considere de inters.
Esta actividad se compone de las siguientes tareas:
Tarea GPF 1.1: Inclusin en Histrico de Proyectos. El Histrico de
Proyectos es esencialmente una base de datos, en soporte magntico o
en papel, donde se recoge toda la informacin importante de todos los
sistemas que se desarrollan en una organizacin, lo que en Ingeniera
del Software se denomina mtricas de gestin de proyectos. A modo de
ejemplo se propone incluir en el Histrico de Proyectos informacin
sobre:
o Plataforma tecnolgica (sistema operativo, base de datos,
monitor de teleproceso, sistema de comunicaciones, lenguajes,
etc.).
o Entorno metodolgico (metodologa de anlisis, de diseo, de
programacin, herramientas CASE, generadores, ele.),
o Rutinas y mdulos generales empleados (accesos a ficheros,
conversiones, clculos, etc.),
o Aspectos funcionales del sistema,
o Incidencias dignas de mencin.
o Organizacin del proyecto (indicando los tcnicos que
participaron y sus funciones).