La gestin

de un proyecto
informtico
Planificacin, seguimiento,
y aseguramiento de la calidad
Miquel Barcel Garca
P03/!0"#/0$%&3
'()* + P03/!0"/0$%&3 La gestin de un proyecto informtico
'()* + P03/!0"/0$%&3 La gestin de un proyecto informtico
ndice
Introduccin ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, !
Objetivos ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, "
1. Planificacin en el tiempo de los proyectos
informticos ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
%,%, La t-cnica del P./0 y el m-todo del camino crtico ,,,,,,,,,,,,,,,,,,,,,,,,
%,$, 1erramientas informati2adas para la planificacin ,,,,,,,,,,,,,,,,,,,,,,,,, %$
%,3, La planificacin de un proyecto informtico ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, %3
%,3,%, La consideracin de los recursos3 a4adir nue5as
precedencias ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, %&
2. Seguimiento y control de un proyecto informtico ,,,,,,,,,,,,,,,,,, %
$,%, Las 6o7as de acti5idad y el informe de situacin ,,,,,,,,,,,,,,,,,,,,,,,,,,,,, %8
$,$, La ley de Broo9s ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, %#
. !seguramiento de la calidad en un proyecto
informtico ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, $%
"esumen ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, $3
!ctividades ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, $!
#jercicios de autoevaluacin ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, $"
Solucionario ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, $8
$losario ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, $8
%ibliograf&a ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, $#
'()* + P03/!0"/0$%&3 La gestin de un proyecto informtico
! '()* + P03/!0"/0$%&3 La gestin de un proyecto informtico
Introduccin
.n los mdulos didcticos :.l proyecto informtico de construccin de software;
y :.stimacin de costes de un proyecto informtico; anali2amos los aspectos ms
especficos y peculiares de los proyectos informticos de construccin de software
de aplicacin en la informtica de gestin, .n concreto, nos referimos a cmo el
proyecto informtico se especifica a medida que se 5a ela<orando y la dificultad
que ello conlle5a con 5istas a la estimacin de las cargas y los costes,
=e 6ec6o, lo que a6ora queda por 5er de la gestin de un proyecto inform>
tico no es en a<soluto tan diferente de lo que es 6a<itual en la gestin de
cualquier otro proyecto de ingeniera, so<re todo si se recuerda, a la 6ora de
tomar las decisiones imprescindi<les de gestin del proyecto, que cuando se
6a<la de personas>mes para considerar el esfuer2o, no se puede en a<soluto
pensar en intercam<iar los dos factores,
(na 5e2 se 6a lle5ado a ca<o la primera estimacin de costes, a menudo, a par>
tir de una primera especificacin gen-rica del alcance del proyecto muy pre>
caria, es necesario finali2ar la etapa de calificacin y planificar en el tiempo las
diferentes tareas pendientes y, cuando ya se 6a iniciado el proceso de desarro>
llo del proyecto, slo se de<e reali2ar el seguimiento y el control,
.n este mdulo, repasamos <re5emente los pro<lemas generales de la planifi>
cacin temporal de acti5idades, con la mencin de temas clsicos como los
diagramas P./0 o el m-todo del camino crtico ?*PM@, sin ol5idar 6acer una
referencia ine5ita<le a las diferentes 6erramientas informticas disponi<les
que pueden ayudar en esta acti5idad de planificacin,
A partir de la planificacin de acti5idades, es muc6o ms sencillo ordenar el
proceso de control del proyecto y el seguimiento de su desarrollo para llegar a
finali2ar con -Bito la acti5idad de construir un software de aplicacin en la in>
formtica de gestin,
(na 5e2 re5isadas <re5emente las acti5idades tpicas de gestin de proyectos
?planificacin, seguimiento y control@, al final de este mdulo planteamos, de
manera <sica e introductoria, el pro<lema del aseguramiento de la calidad
del software ?software quality assurance@, que 6a llegado a alcan2ar una gran
impor> tancia en los Cltimos a4os, posi<lemente por la falta de calidad y
fia<ilidad de la mayora del software construido,
Pod-is 5er el mito del 6om<re>mes en
el su<apartado %,3,$ del mdulo
:.stimacin de costes de un proyecto
informtico; de esta asignatura,
Objetivos
.n este mdulo se cierra el estudio de la gestin de un proyecto informtico de
construccin de software de aplicacin en la informtica de gestin, De tra> tan
los temas de la planificacin temporal de acti5idades y, a partir de esta pla>
nificacin, del seguimiento y el control del desarrollo del proyecto, .l mdulo
termina con una referencia <re5e al pro<lema del aseguramiento de la calidad
del software, *on el estudio de este mdulo y de los materiales didcticos aso>
ciados, el estudiante de<e alcan2ar los o<7eti5os siguientes3
1. *onocer la pro<lemtica general de la planificacin temporal de proyectos, el
uso de diagramas de Gantt, la t-cnica del P./0 y el m-todo del camino
crtico ?*PM@,
2. Da<er planificar en el tiempo las acti5idades de un proyecto informtico,
teniendo en cuenta los recursos disponi<les y las limitaciones de uso,
. *onocer los pro<lemas que se plantean y los documentos que se suelen uti>
li2ar para controlar el desarrollo de un proyecto y reali2ar un seguimiento
completo y eB6austi5o,
'. Da<er cules son las decisiones ms 6a<ituales que se 6an de tomar en el
proceso de control de un proyecto informtico y los aspectos que ms las
condicionan,
(. *onocer las 6erramientas informticas que ayudan tanto en el proceso de
planificacin del proyecto, como en el de seguimiento y control de una
planificacin ya efectuada,
). )<tener una 5isin inicial de los pro<lemas de aseguramiento de la cali>
dad del software ?software quality assurance@ y, en definiti5a, de la dificultad de
o<tener software seguro, fia<le y de calidad,
1. Planificacin en el tiempo de los proyectos
informticos
0al como eBplicamos en otro mdulo, una 5e2 determinada la 5oluntad de
iniciar un proyecto informtico, las etapas que caracteri2an la gestin son
dos3 la primera es la calificacin inicial ?estimacin de costes y planifica>
cin temporal@ y la segunda es el desarrollo ?seguimiento y control del pro>
yecto, tal 5e2 acompa4ados de nue5as estimaciones y planificaciones@ para
llegar, de una manera o de otra, con -Bito o sin -l, al final o cierre definiti5o
del proyecto,
(na 5e2 conocida la amplia pro<lemtica de la estimacin de costes, que
nos 6a ocupado un mdulo entero, a6ora planificaremos en el tiempo las
diferentes tareas o acti5idades de las que consta el proyecto,
*a<e mencionar que la planificacin temporal de proyectos a partir de su des>
composicin en tareas ?EBD@ y la estimacin de la duracin de cada una es un
proceso suficientemente conocido y que los proyectos informticos de cons>
truccin de software comparten con muc6os otros proyectos de ingeniera, Por
otra parte, como 5eremos, sal5o una particular manera de tener en cuenta los
recursos ?las personas que forman el equipo del proyecto@, no se dan diferen>
cias esenciales con otros proyectos de ingeniera,
*omen2amos con la eBposicin <re5e y sint-tica de conceptos tradiciona>
les de la planificacin temporal de acti5idades como la t-cnica del P./0 y
el m-todo del camino crtico ?*PM@ y despu-s anali2amos el caso general
de la planificacin temporal de proyectos informticos,
1.1. *a t+cnica del P#", y el m+todo del camino cr&tico
Pod-is 5er las etapas de un proyecto
informtico en el su<apartado %,$
del mdulo :.l proyecto informtico
de construccin de software; de esta
asignatura,
Pod-is 5er la pro<lemtica
de la estimacin de costes
en el mdulo :.stimacin de costes
de un proyecto informtico; de esta
asignatura,
La t-cnica del P./0F ?t-cnica de re5isin y actuali2acin del programa
o proyecto@ es un procedimiento desarrollado ya 6ace d-cadas por la
Marina norteamericana ?(D Ga5y@ para el tratamiento de grandes pro>
yectos de ingeniera de todo tipo,
F P./0 es la sigla de la eBpresin
inglesa Program Evaluation and
Review Technique,
.l fundamento central de las t-cnicas del P./0 es la representacin grfica del
proyecto en un diagrama que muestre las relaciones y, so<re todo, las preceden>
cias entre las tareas que constituyen el proyecto, .ste diagrama, que algunos de>
nominan diagrama PERT, en el fondo no es ms que un grafo de precedencias
de acti5idades que a menudo se llama red de actividades ?activity network@ o,
tam<i-n, diagrama de precedencias,
.l m-todo del camino crtico ?*PM@ es un m-todo de optimi2acin que, como el P./0,
tam<i-n utili2a una red de tareas del proyecto,
*PM es la sigla de la eBpresin
inglesa Critical Path Method,
A menudo, los dos m-todos se pueden tratar con7untamente, tal como 6are>
mos en esta eBposicin simplificada,
*on5iene ad5ertir que, aunque aqu se 6a<la de tareas o actividades indis>
tintamente, a menudo la nomenclatura ms 6a<itual utili2a el t-rmino ac-
tividades cuando se refiere a P./0, aunque actualmente la eleccin suele
depender de la manera como se 6aya traducido el concepto en la 6erra>
mienta informtica de la que nos ayudamos a la 6ora de lle5ar a ca<o la
planificacin de un proyecto,
.l con7unto de las t-cnicas P./0 y el m-todo del camino crtico ?*PM@ propor>
cionan 6erramientas cuantitati5as que permiten determinar lo siguiente3
%@ .l camino crtico del proyecto, que es la secuencia o cadena de acti5ida>
des que determina la duracin total del proyecto,
$@ Las estimaciones de tiempos ms pro<a<les, tanto para la totalidad del
proyecto como para el inicio y el final de cada una de las tareas o acti5idades
indi5iduales,
3@ Los mrgenes de tiempo que se dan para cada tarea o acti5idad indi5idual
y que no impliquen un retraso del proyecto,
Pod-is 5er las 6erramientas
informati2adas para la planificacin
de un proyecto en el su<apartado
%,$ de este mdulo didctico,
.l diagrama P./0 es un grafo de precedencias donde los nudos o nodos
son las acti5idades, mientras que los arcos son las relaciones de precedencia
entre acti5idades, =e cada acti5idad, se de<e sa<er la duracin estimada y
las acti5idades que le son precedentes directos, .l resto, en cierta manera,
surge casi automticamente del mismo diagrama,
Pongamos un e7emplo, que es la manera ms clara de 5erlo, Para no tener que
reali2ar un diagrama comple7o, imaginamos un peque4o proyecto del cual 6e>
mos efectuado una descomposicin en die2 acti5idades, como las que se indi>
can en la ta<la siguiente3
!ctividades- duracin y precedencias de un proyecto ficticio
Hdentificacin
num-rica
Gom<re de la acti5idad =uracin estimada Precedencias
% Hnicio 0 >
$
.sta<lecer los
requerimientos
3 %
3 Deleccionar los drivers $ %
!ctividades- duracin y precedencias de un proyecto ficticio
Hdentificacin
num-rica
Gom<re de la acti5idad =uracin estimada Precedencias
& /eali2ar el dise4o & $
! /ecoger datos $ $ y 3
" Pro<ar los drivers " 3
*odificar & &
8 .la<orar la documentacin $ &
# Pro<ar el producto & !, " y
%0 'inal 0 I
*on5iene, tal como se lle5a a ca<o aqu, incluir siempre las acti5idades de ini> cio
y final, puramente ficticias y con duracin cero,
La ta<la nos ofrece para cada acti5idad un nom<re, una identificacin nu>
m-rica ?de uno a die2@, la duracin estimada de la acti5idad ?en unidades
ar<itrariasJ por e7emplo, en semanas@ y las tareas que son inmediatamente
anteriores e imprescindi<les para poder empe2ar cada acti5idad en concre> to
?precedencias@,
Di se quiere, se puede imaginar que se trata de construir un sistema informti> co
determinado que utili2a datos que ya tenemos ?recogidos en la acti5idad !@ y que
utili2a una serie de drivers diferentes ?que se seleccionan en la acti5idad
3 y se prue<an en la acti5idad "@ para acceder a perif-ricos o a aquello que sea
necesario, =e 6ec6o, el proyecto en s no es importante, ya que se trata de un
e7emplo ficticio para ilustrar el P./0 y el *PM,
Di se dispone de estos datos ?acti5idades, duracin estimada y precedencias@ se
puede di<u7ar un grafo como el de la figura de la pgina siguiente,
*omo se puede 5er en el diagrama, las flec6as marcan las relaciones de prece>
dencia que eBisten entre las acti5idades, mientras que los nudos son las acti>
5idades, de las cuales se 6an recogido tam<i-n una serie de datos3 el nCmero
identificador, el nom<re de la acti5idad y la duracin estimada ?puesta entre
par-ntesis dentro del nudo@,
Do<re cada nudo se 6a a4adido tam<i-n la informacin que sale directamente de
la eBplotacin del diagrama de precedencias3 las semanas de inicio y final de cada
acti5idad, *on5iene darse cuenta de que la acti5idad final tiene como precedentes
todos los arcos pendientes del diagrama,
Por e7emplo, la acti5idad % ?inicio@ empie2a en la semana cero y, al tener una
duracin nula, termina tam<i-n en la semana cero, Pero la acti5idad $ ?esta>
<lecer los requerimientos@ comien2a en la semana cero ?7usto despu-s de la ac>
ti5idad precedente, inicio@ y finali2a al final de la semana tres, ya que dura
precisamente tres semanas, =el mismo modo, la acti5idad & ?reali2ar el dise4o@
no puede iniciarse 6asta que no termine la precedente ?la $, esta<lecer los re>
querimientos@, es decir, no puede empe2ar 6asta que no 6a aca<ado la semana
tres, Adems, al durar cuatro semanas, no finali2ar 6asta el final de la semana
siete, K as sucesi5amente,
.n el caso de la acti5idad # ?pro<ar el producto@ se dan tres precedentes direc>
tos3 la acti5idad ?codificar@, que finali2a en la semana onceJ la acti5idad ! ?re>
coger datos@, que finali2a en la semana cincoJ y la acti5idad " ?pro<ar los
drivers@, que finali2a en la semana oc6o, .5identemente, como se de<e esperar
a que las tres 6ayan terminado, la acti5idad # ?pro<ar el producto@ no puede
empe2ar 6asta que no 6aya aca<ado la acti5idad ?codificar@ en la semana
on>
ce, que es la que finali2a ms tarde de todas,
(na 5e2 se 6a reali2ado el diagrama completo, se puede 5er que el proyecto
dura un total de quince semanas, K no slo esoJ el diagrama P./0, gracias al
m-todo del camino crtico, nos permite sa<er algo de gran importancia para
el futuro de la gestin del proyecto,
(na o<ser5acin sencilla del diagrama nos muestra que las acti5idades % ?ini>
cio@, $ ?esta<lecer los requerimientos@, & ?reali2ar el dise4o@, ?codificar@, #
?pro<ar el producto@ y %0 ?final@ no tienen ningCn margen, .s decir, si alguna
de estas acti5idades tardara ms de lo que se 6a estimado, todo el proyecto se
alargara ms de las quince semanas pre5istas,
*as actividades cr&ticas...
,,, son las que forman el cami>
no crtico y no tienen ningCn
margen, *ualquier des5iacin
en la duracin de estas acti5i>
dades se traduce en una
des5iacin en la duracin
del proyecto,
Las acti5idades que no tienen ningCn margen forman lo que se denomi>
na camino crtico y, en definiti5a, son las que determinan la duracin
final del proyecto, A menudo estas acti5idades se llaman acti5idades
crticas,
.n el diagrama, el camino crtico est marcado por flec6as continuas,
Por otra parte, el diagrama P./0 nos permite 5er que eBisten acti5idades que no
son tan decisi5as en la 5ida del proyecto, Por e7emplo, la acti5idad " ?pro<ar los
drivers@ tiene marcados un inicio y un final ?$, 8@, .s decir, se puede comen2ar
a efectuar una 5e2 finali2ada la segunda semana del proyecto ?7usto cuando
aca<a la acti5idad precedente 3, Deleccionar los drivers@ y, si se cumplen las
estimaciones de duracin, terminar al final de la semana oc6o, A6ora <ien, la
acti5idad # ?pro> <ar el producto@, de la cual la " es precedente, tiene tam<i-n
como precedente la acti5idad ?codificar@J y ello pro5oca que no pueda
empe2ar 6asta que no 6aya finali2ado la semana once y que la acti5idad "
tenga un margen de tres semanas ?%% 8 3@, de manera que no ser nada
crtica,
.s decir, si la acti5idad " ?pro<ar los drivers@ tardara siete semanas en lugar de
las seis semanas estimadas, el proyecto durara tam<i-n quince semanas, ya
que la acti5idad " no forma parte del camino crtico y, como se 5e en el diagra>
ma, tiene un margen de tres semanas ?podra empe2ar ms tarde o durar ms
de lo que se 6a<a estimado@,
*on 5istas a la gestin de un proyecto es muy importante sa<er qu- acti5ida>
des son crticas ?es decir, qu- acti5idades forman parte del camino crtico@ y
cules no, Por otra parte, con5iene remarcar que las acti5idades no crticas dis>
ponen de un margen que permite que el planificador acomode me7or los re>
cursos y, so<re todo, que la <uena gestin del proyecto pase por el control
estricto de las acti5idades que forman parte del camino crtico,
La t-cnica del P./0 con la determinacin del camino crtico es un
sistema muy adecuado para la <uena gestin de un proyecto ?de
cualquier proyec> to@, ya que nos permite centrar los esfuer2os en las
acti5idades crticas y uti> li2ar las que no lo son para disponer de los
recursos con ms agilidad,
.5identemente, las cosas son ms complicadas en el caso de proyectos con
muc6as ms acti5idades, Pero, afortunadamente, en estos proyectos es fcil
poder disponer de una 6erramienta informati2ada que, de manera autom>
tica, nos da el camino crtico y con todas las 5enta7as que esto representa,
*a<e mencionar que en este e7emplo se 6a utili2ado lo que se llama una pla>
nificacin ADAP, que sitCa cada acti5idad lo antes posi<le y es el procedi>
Para cada actividad...
,,, se puede esta<lecer una
planificacin de tipo3
+ ADAP, del ingl-s as soon
as posible, tan pronto
como sea posi<le,
+ ALAP, del ingl-s as last
+ as posible, tan tarde como
sea posi<le,
miento 6a<itual cuando se parte de la fec6a de inicio del proyecto y se quiere
encontrar el momento en el que se finali2ar, .n otros casos, generalmente
cuando se parte del da en el que el proyecto de<e estar aca<ado, se utili2a un
proceso contrario, a partir de la fec6a de fin del proyecto, 6ec6o que se conoce
como una planificacin ALAP,
1.2. .erramientas informati/adas para la planificacin
*uando se 6a<la de herramientas informatiadas para la planificaci!n" ya no se
trata, como pasa<a en el caso de la estimacin de costes, de 6erramientas que a
menudo son muy carasF y que slo se utili2an para la estimacin de costes en
proyectos informticos, Ka 6emos mencionado que la parte de la planificacin
temporal de proyectos informticos es prcticamente igual a la planificacin de
cualquier otro proyecto de ingeniera, .sto pro5oca que las 6erramientas
informticas disponi> <les, por el 6ec6o de tener un mercado muc6o ms
amplio, tengan un coste ms asequi<le y su uso se con5ierta en muy 6a<itual,
.l pro<lema que se plantea a menudo es decidir cul de las muc6as
6erramien> tas disponi<les en el mercado se de<e escoger, Pero se trata de
un pro<lema falso, *omo la mayora de las 6erramientas informticas de
utili2acin muy eBtendida, los sistemas de ayuda a la planificacin de
proyectos ?y tam<i-n, como 5eremos, al seguimiento y control@ proponen
una gran cantidad de fun> cionalidades que en general no se utili2an, Lo
mismo ocurre, por e7emplo, con
los procesadores de teBtos o las 6o7as de clculo,
F .l DLHM, por e7emplo,
Pod-is 5er el su<apartado $,$
de este mdulo didctico,
=ic6o de otra manera, todas las 6erramientas disponi<les en el mercado
tienen, adems de complementos ms o menos interesantes, los ele>
mentos mnimos para efectuar una <uena planificacin temporal de un
proyecto, .l pro<lema, a menudo, es cmo li<rarse de todo aquello que
la 6erramienta informtica ofrece y que no 5amos a utili2ar,
A6ora <ien, actualmente, para la planificacin de proyectos, las 6erramientas
informticas ms 6a<ituales en nuestro entorno geogrfico se reducen al MD>
P/)L.*0 y el D(P./P/)L.*0, a causa de la fuer2a de su sistema de 5entas,
.legir una de las dos 6erramientas es en cierta manera inCtil, *uando una de
las 6erramientas ofrece una funcionalidad nue5a no disponi<le en la otra,
slo se de<e esperar unos meses y la nue5a 5ersin de esta otra 6erramienta
incor> porar tam<i-n la misma funcionalidad, Adems, ca<e recordar que la
mayo> ra de estas funcionalidades no siempre se utili2an, *omo ocurre
con los procesadores de teBto, a menudo es me7or lo que se utili2a desde
6ace ms tiempo, ya que es lo ms conocido y familiar,
(na 5e2 eBplicado esto, de<era quedar claro que si los e7emplos de este m>
dulo se presentan en MD>P/)L.*0 es Cnicamente porque esta 6erramienta 6a
#l autor de este mdulo...
,,, por e7emplo, 6a escrito
el teBto original con el Eord
&,0 de Microsoft para =)D,
que data de %#83 para teclear
es suficiente con ello,
estado disponi<le, pero no porque eBista alguna preferencia que se pueda ge>
nerali2ar a otros usuarios,
Lo que importa de las 6erramientas informati2adas para la ayuda a la pla>
nificacin de proyectos es que todas ofrecen la posi<ilidad de mostrar el
diagrama P./0 ?o red de acti5idades@ y marcar, adems, el camino crtico
de manera automtica, 0am<i-n ofrecen una gestin de recursos completa
y un montn de diagramas y listas ?que aumentan da a da@ que permiten
incluso reali2ar una presentacin <rillante y muy profesional de la planifi>
cacin de un proyecto,
1.. *a planificacin de un proyecto informtico
.n la planificacin de un proyecto informtico, adems del diagrama P./0, se
suele utili2ar una especie de diagrama temporal llamado diagrama de #antt,
.l diagrama de Gantt es un diagrama sencillo que muestra el tiempo
en el e7e de a<scisas, mientras que en cada lnea del e7e de ordenadas se
encuentran todas y cada una de las acti5idades que forman el proyecto,
.n la parte i2quierda se escri<e el nom<re de las acti5idades, mientras
que en la parte derec6a se marca una lnea desde la fec6a inicial 6asta
la fec6a final de cada acti5idad,
.n el caso del proyecto ficticio que se 6a utili2ado para eBponer el P./0 y el
*PM, el diagrama de Gantt sera el que se muestra en la figura siguiente3
Pod-is 5er el proyecto ficticio
propuesto en el su<apartado %,%
de este mdulo didctico,
.n realidad, la mayora de 6erramientas informati2adas de ayuda a la planifi>
cacin utili2an el diagrama de Gantt como marco de referencia para introducir
los datos de las diferentes
tareas o acti5idades que
forman la EBD del proyecto, Pre5iamente, sin em<argo, de<e esta<lecerse el
calendario del proyecto para marcar las fec6as que no son la<ora<les o
cualquier incidencia la<oral, Las 6e> rramientas informati2adas ofrecen
tam<i-n diagramas <asados en el calenda> rio para marcar los das de inicio y
final de cada tarea, aunque el diagrama de Gantt es suficientemente completo
en este aspecto,
.l resumen de lo que se de<e lle5ar a ca<o para planificar un proyecto en el
tiempo es el siguiente3
%@ .sta<lecer el calendario de das la<ora<les de todo el proyecto y, si es nece>
sario, de cada persona del equipo ?recurso@,
$@ .sta<lecer la descomposicin del proyecto en tareas ?EBD@,
3@ .stimar la duracin ?o esfuer2o@ de cada tarea o acti5idad,
&@ .sta<lecer las precedencias entre las tareas,
!@ /eali2ar el diagrama de Gantt o P./0 ?red de acti5idades@, preferentemente
con una 6erramienta informati2ada para la ayuda a la planificacin de proyectos,
Para finali2ar, es importante sa<er que, tal como se 6a lle5ado a ca<o con las
acti5idades Hnicio y 'inal, de duracin nula, con5iene a4adir siempre algunas
acti5idades ficticias con duracin nula como 6itos de control para esta<lecer
momentos concretos en los que es necesario recopilar los datos y efectuar un
<alance de la gestin del proyecto, *uando el proyecto dispone de fases y eta>
pas diferentes, a4adir un 6ito de control al final de cada fase sera lo ms co>
rrecto, aunque muc6as 5eces se ponen 6itos temporales de control3 uno cada
dos semanas, uno cada mes, etc,, segCn la duracin total del proyecto,
1..1. *a consideracin de los recursos0 a1adir nuevas
precedencias
*on5iene se4alar que a la 6ora de esta<lecer precedencias, las 6ay que son l>
gicas y las 6ay que surgen, en el caso concreto de los proyectos informticos,
de la gestin de los recursos,
Por e7emplo, en el diagrama de Gantt de la figura anterior 6emos imaginado que
es posi<le efectuar simultneamente las tareas $ ?esta<lecer los requerimientos@ y
3 ?seleccionar los drivers@, Din em<argo, si las dos las de<e reali2ar la misma perso>
na, este diagrama de Gantt nos dice que esta persona tiene una 7ornada de dieci>
s-is 6oras y no de oc6o como es 6a<itual, Go parece, pues, posi<le,
Pod-is 5er la EBD en el su<apartado
$,$ del mdulo :.stimacin
de costes de un proyecto informtico;
de esta asignatura,
*as ayudas t&picas...
,,, que ofrecen las 6erramientas
informati2adas de planificacin
y seguimiento de proyectos son
los diagramas P./0, los de Gantt
y los de calendario,
Pod-is 5er el su<apartad %,3,%
de este mdulo didctico,
#jemplo de precedencia
lgica
(n caso sencillo de preceden>
cia lgica es que no se puede
codificar un programa si su
cuaderno de cargas no se
6a finali2ado,
Por ello, en la planificacin temporal de proyectos informticos, ade> ms
de las precedencias lgicas, es necesario a4adir otras nue5as que pro5ienen
de la consideracin de los recursos y de su utili2acin,
.n el caso de los proyectos informticos de construccin de software, los recursos son
las personas, los profesionales informticos que forman el equipo del proyec> to, De 6a
de procurar que nadie de<a tra<a7ar ms de una 7ornada por culpa de una planificacin
incompleta que no 6a tenido en cuenta los recursos,
=e 6ec6o, el diagrama de Gantt de la figura anterior sera realista si imagina> mos
que disponemos de tres personas en el equipo del proyecto3
%@ (na primera persona podra lle5ar a ca<o las tareas $ ?esta<lecer los reque>
rimientos@, & ?reali2ar el dise4o@, ?codificar@ y # ?pro<ar el producto@,
$@ (n segundo miem<ro del equipo se podra encargar de las tareas 3 ?selec> cionar
los drivers@ y " ?pro<ar los drivers@ y, tal 5e2, participar tam<i-n en la ac> ti5idad #
?pro<ar el producto@,
3@ Para no tener pro<lemas de 7ornada do<le, una tercera persona del equipo
de<era encargarse de las acti5idades ! ?recoger datos@ y 8 ?ela<orar la docu>
mentacin@,
La figura siguiente muestra una modificacin sencilla en el caso de que el equi> po
del proyecto estu5iera formado por dos miem<ros, Para e5itar 7ornadas do> <les de
los miem<ros del equipo, se 6an tenido que introducir nue5as precedencias3
pro5ocar que la acti5idad ! ?recoger datos@ dependa de la " ?pro> <ar los drivers@ y,
tam<i-n, que la acti5idad 8 ?.la<orar la documentacin@ de> penda de la ! ?recoger
datos@, para conseguir que las realice la misma persona,
!ctividades con precedencias adicionales para evitar jornadas dobles
Hdentificacin
num-rica
Gom<re de la acti5idad
=uracin
estimada
Precedencias
% Hnicio 0 > >
$
.sta<lecer los
requerimientos
3 % A
3 Deleccionar los drivers $ % B
& /eali2ar el dise4o & $ A
! /ecoger datos $ $, 3 y " B
" Pro<ar los drivers " 3 B
*odificar & & A
8 .la<orar la documentacin $ & y ! B
# Pro<ar el producto & !, " y A
%0 'inal 0 > >
La ta<la muestra, en negrita, las precedencias adicionales introducidas para
e5itar la 7ornada do<le de un miem<ro del equipo, 0am<i-n indica el recurso
?la persona miem<ro del equipo@ que reali2ar cada acti5idad,
*a<e decir que, aunque en este e7emplo no 6a ocurrido, estas precedencias
adicionales suelen cam<iar a menudo el camino crtico e incluso la duracin
glo<al del proyecto, =e 6ec6o, a la 6ora de planificar un proyecto se 7uega con
los recursos disponi<les ?teniendo en cuenta el coste@ y las precedencias de ac>
ti5idades 6asta que se encuentra un resultado acepta<le,
(na 5e2 terminada la planificacin, finali2a la calificacin y ya se dispone
de los o<7eti5os del proyecto informtico3 un primer <oceto de las funcio>
nalidades, los pla2os de todo el proyecto y de cada acti5idad de la EBD y el
presupuesto, o<tenido <sicamente del precio por 6ora de cada uno de los
profesionales que forman parte del equipo del proyecto y del nCmero de
6oras de tra<a7o que les 6an sido asignadas,
2. Seguimiento y control de un proyecto informtico
(na 5e2 iniciado el proyecto informtico, la tarea de gestin consiste en conseguir que las
pre5isiones se cumplan y, en caso de que no sea as, poder detectar lo an> tes posi<le las
des5iaciones que se de<en producir para poder encontrarles una
solucin,
.l o<7eti5o del seguimiento y el control del proyecto informtico es
conseguir que no falle y, adems, que se desarrolle segCn la planifica>
cin fi7ada pre5iamente,
Para conseguir todo esto, es imprescindi<le comparar peridicamente la reali> dad del
desarrollo del proyecto con la pre5isin disponi<le, ya sea la inicial o cualquiera de
las nue5as pre5isiones que se 6ayan de<ido reali2ar al detectar errores en la
estimacin o la planificacin iniciales,
.l o<7eti5o declarado del proyecto es alcan2ar unas funcionalidades en unos pla2os
determinados y 6a<i-ndolas presupuestado, La acti5idad de seguimien> to y control
del proyecto de<e conseguir detectar los pro<lemas con la mBi> ma antelacin
posi<le para poder rea7ustar la estimacin y la planificacin y,
en definiti5a, cam<iar el proyecto modificando los o<7eti5os,
La importancia del seguimiento del proyecto informtico radica, pues,
en el 6ec6o de poder anticipar los pro<lemas,
#l seguimiento pretende una anticipacin- no una constatacin
*on el seguimiento de un proyecto informtico no se trata de constatar si en un momen> to
determinado del proyecto se lle5an dos meses de retraso, porque entonces ya sera de> masiado
tarde, Lo que importa es poder decir, por e7emplo, que :aunque actualmente 5amos
suficientemente <ien, si continuamos as de aqu a tres meses se podr constatar un mes de
retraso en el desarrollo del proyecto;, Dlo con una pre5isin anticipada de este tipo se pueden
tomar las decisiones adecuadas para tratar de sal5ar las pre5isiones del proyecto,
.n los 6itos de control introducidos en la planificacin ?<ien sea al final de fases o
etapas de proyecto, o <ien de manera peridica@ es cuando de<emos plantearnos,
entre otras cosas, lo siguiente3
+ Di con5iene re6acer la descomposicin del proyecto en tareas ?EBD@ o no,
posi<lemente con la intencin de incluir algunas no pre5istas en el mo> mento
inicial, pero que son totalmente necesarias e imprescindi<les a me> dida que
a5an2a el proyecto,
+ Di con5iene 5ol5er a efectuar la estimacin del esfuer2o o no, en caso de que
se constate que la producti5idad que se o<tiene es diferente de la pre5ista,
+ Di con5iene cam<iar algunos de los o<7eti5os del proyecto o no, para tratar
de mantener los otros,
+ Di con5iene lle5ar a ca<o una nue5a calificacin del proyecto o no, para te>
ner en cuenta los datos de nue5as tareas o de una producti5idad diferente
de la pre5ista que la realidad nos aporte,
*omo se dice en otro mdulo, los pro<lemas de una deficiente calificacin ini>
cial se intentan :resol5er; demasiadas 5eces de puertas afuera, 6aciendo todo
lo posi<le para cumplir con los pla2os y el presupuesto a fuer2a de reducir las
funcionalidades del proyecto, so<re todo las funcionalidades de calidad, Msta
es, e5identemente, una solucin totalmente falsa que simplemente apla2a los
pro<lemas 6asta la fase de mantenimiento, al mismo tiempo que consigue a
menudo que los pro<lemas se con5iertan en muc6o ms gra5es y que tengan
una solucin muc6o ms difcil,
2.1. *as 2ojas de actividad y el informe de situacin
Para poder lle5ar a ca<o una comparacin correcta entre la realidad y la pre5i>
sin, es necesario :sa<er cmo 5a; el proyecto y, con esta finalidad, se de<en
recoger datos de su desarrollo, *on estos datos del seguimiento ser posi<le
te> ner elementos para tomar decisiones de cam<io de los o<7eti5os del
proyecto y, en definiti5a, controlar el desarrollo, La prctica 6a<itual es
recoger estos
datos del seguimiento en unas 6o7as de acti5idad,
Pod-is 5er los pro<lemas de
una deficiente calificacin en el
su<apartado %,% del mdulo :.l
proyecto informtico de construccin
de software;,
La 6o7a de acti5idad es el con7unto de datos indi5iduales de segui>
miento de un proyecto, donde cada miem<ro del equipo se4ala las
6oras que 6a ocupado en cada una de las tareas pre5istas de la EBD
que se le 6an asignado,
*on5iene recoger de manera indi5idual por cada tarea y cada persona in5olu>
crada estos datos de seguimiento, a partir de los cuales el 7efe de proyectoF
de<e ela<orar los datos glo<ales que permiten construir un informe de situa>
cin del proyecto, .ste informe se suele lle5ar a ca<o para cada uno de los
6itos
de control esta<lecidos,
F Di con5iene, ayudado de un
sistema informtico ad hoc,
(n informe de situacin es el resumen de la realidad de un proyecto a
partir de los datos o<tenidos de las 6o7as de acti5idad y de su compara>
cin con la planificacin 5igente,
*uando una tarea finali2a, el 7efe de proyecto puede sa<er el esfuer2o real que
6a supuesto reali2arla y lo puede comparar con el esfuer2o pre5isto, para 5er
si las estimaciones de producti5idad eran optimistas, pesimistas o realistas, .l
6ec6o de disponer de esta producti5idad real es precisamente lo que de<e per>
mitir anticipar los pro<lemas,
*on los datos reales o<tenidos de la 6o7a de acti5idad, el 7efe de proyecto rea>
li2a el seguimiento, a menudo mediante 6erramientas informati2adasF que
permiten, para cada acti5idad del proyecto, introducir las fec6as reales del tra>
<a7o aca<ado o el porcenta7e del tra<a7o 6ec6o en cada momento, .stas 6erra>
mientas ofrecen tam<i-n una gran cantidad de listas y grficos que, una 5e2
escogidos los que son Ctiles, ayudan a las tareas de seguimiento y control del
proyecto,
2.2. *a ley de %roo3s
Aunque ya se trata detenidamente en otros mdulos, con5iene recordar aqu
lo que se 6a denominado ley de $rooks, una teora que pro5iene de la eBperien>
cia del autor de la o<ra The Mythical Man-Month ?%#!@ como director del pro>
ceso de construccin del sistema operati5o de HBM 3"0,
F *omo MD>P/)L.*0
o D(P./P/)L.*0,
Pod-is 5er los mdulos :.l proyecto
informtico de construccin de
software; y :.stimacin de costes
de un proyecto informtico; de esta
asignatura, .n concreto, pod-is 5er el
mito del 6om<re>mes en el su<apartado
%,3,$ de este Cltimo mdulo,
La ley de Broo9s es una ad5ertencia para no caer en el mito del 6om>
<re>mes, que a menudo tiene formulaciones tan sorprendentes como
-sta3 si un proyecto 5a retrasado, el 6ec6o de a4adir personal es la ma>
nera ms segura de retrasarlo toda5a ms,
.s necesario entender esta ad5ertencia en el sentido de que no se pueden inter>
cam<iar 6om<res y meses, K tam<i-n se de<e entender que la ley no es algo
matemtico, sino slo una ad5ertencia para los que toda5a no 6an captado el
mito del 6om<re>mes,
.n cualquier proyecto ?pensemos, por e7emplo, en la construccin de una ca>
sa@, cuando -ste 5a retrasado, una solucin para mantener los pla2os, aunque
pueda costar ms dinero, es a4adir personal ?por e7emplo, ms al<a4iles en el
caso de la construccin de una casa@,
La ley de Broo9s que aca<amos de 5er nos ad5ierte de que no sucede lo mismo
en los proyectos informticos y que, como ya 6emos dic6o en otros mdulos
didcticos, en un proyecto informtico el reparto de los esfuer2os en el
tiempo no puede ser cualquiera, sino que tiene una forma fi7ada por la
cur5a de /a> yleig6/Gorden, Posi<lemente, Broo9s fue el primero en
constatar que en un proyecto informtico que i<a retrasado, el 6ec6o de
a4adir personal cre ms pro<lemas de los que resol5i, aunque,
e5identemente, esto no de<e ocurrir siempre,
*ectura recomendada
La referencia siguiente os
permitir encontrar la o<ra
mencionada en el teBto so<re
el mito del 6om<re>mes3
', Broo9s ?%#!@, The
mythical man-month,
/eading3 Addison>Eesley,
Pod-is 5er la cur5a de /ayleig6/
Gorden en el su<apartado $,3,3 del
mdulo :.stimacin de costes
de un proyecto informtico; de
esta asignatura,
La eBplicacin tradicional del fenmeno es que en un proyecto informtico se
crean unos circuitos internos de comunicacin para comprender qu- se reali> 2a,
.ntre los tra<a7os que se de<en efectuar se encuentra el de comunicar a otros
miem<ros del equipo aquello que uno 6a decidido y que condiciona el tra<a7o
del resto, .l 6ec6o de a4adir personal nue5o a mitad de proyecto o cuando ya
se est aca<ando pro5oca que 6aya personas nue5as que no cono> cen qu- se
reali2a y que, adems, crean necesidades adicionales de comunica> cin que
pueden consumir incluso una parte de los recursos que ya eBisten, simplemente
porque los miem<ros :5ie7os; del equipo de proyecto 6an de eB> plicar a los
:nue5os; qu- se lle5a a ca<o y cmo se reali2a, DegCn Broo9s, estas necesidades
adicionales de comunicacin pueden pro5ocar incluso que con ms personas se
tarde ms tiempo,
. !seguramiento de la calidad en un proyecto
informtico
=esgraciadamente, tal como comentamos en otro mdulo, la calidad del soft-
ware construido no es siempre la desea<le, 1emos 5isto algunas de las ra2ones
que pueden ser la causa, aun as de<emos e5itar que ello ocurra,
1an transcurrido ya un par de d-cadas desde que se comen2 a 6a<lar eBpl>
citamente de aseguramiento de la calidad del software,
,erminolog&a confusa
*on respecto al t-rmino aseguramiento de la calidad del software ?software quality assuran-
ce@, a 5eces se 6a traducido del ingl-s como garant%a de calidad del software, aunque dife>
rentes autores se oponen porque crea confusin con el concepto, muc6o ms tradicional,
de garant%a de los productos ?no de<emos ol5idar que un software es un producto que se
5ende y que, como tal, puede tener una garanta@,
Pod-is 5er el mdulo :.l proyecto
informtico de construccin de
software; de esta asignatura,
.l aseguramiento de la calidad del software es, segCn A.G)/ Nla
entidad espa4ola de normali2acinN, el con7unto de acti5idades
planificadas y sis> temticas necesarias para aportar la confian2a de que el
producto ?software@
cumplir los requerimientos de calidad esta<lecidos,
Ka en %#, Mc *all esta<leci algunos factores para anali2ar la calidad del
software F y, desde entonces, el procedimiento 6a<itual 6a sido ela<orar listas
de controlFF comple7as y detalladas para re5isar todo el proceso de construc>
cin del software,
Actualmente, el aseguramiento de calidad de software consiste en introducir
unos procedimientos y unas metodologas de construccin que tratan de ga>
ranti2ar, a priori, que el proceso es correcto y seguro, y que el mismo proceso
de construccin pueda garanti2ar tam<i-n, en cierta manera, que el producto
que se o<tiene es un software de la me7or calidad,
.n general, la calidad del software necesita que eBista un acuerdo total entre
los requerimientos ?tanto funcionales como de rendimiento@ y el software fi>
nal, .sto implica la utili2acin de estndares de desarrollo documentados eB>
plcitamente y de procedimientos concretos de gestin de todo el proceso de
construccin de software,
F .n ingl-s, software quality factors,
FF .n ingl-s, check list,
,asa cero de errores
.n cuanto a la o<tencin de
software de la me7or calidad, se
6a llegado a 6a<lar, incluso, de
procesos de construccin que
alcan2aran una tasa cero
de errores,
La calidad del software es, segCn el HH.. ?Hnstituto de Hngenieros .l-c>
tricos y .lectrnicos@, el grado en el que un sistema, componente o pro>
ceso cumple con los requerimientos especificados y con las necesidades
o eBpectati5as del cliente o usuario,
.l tratamiento del aseguramiento de la calidad se centra tradicionalmente en las inspecciones y
re5isiones formales, 7unto con las llamadas reuniones de re- pasoF, (no de los
o<7eti5os fundamentales es, e5identemente, o<tener la ca> racterstica implcita
de la fia<ilidad y, so<re todo, un mantenimiento fcil del producto o<tenido,
teniendo en cuenta la larga duracin de la etapa de man>
tenimiento en el ciclo de 5ida del software,
F .n ingl-s, walkthroughs,
.n general, un sistema de aseguramiento de la calidad del software
incluye una estructura organi2ati5a que implica esta<lecer responsa<i>
lidades, procedimientos y procesos de construccin y re5isin, y tam>
<i-n garanti2ar la disponi<ilidad de los recursos de todo tipo necesarios
para efectuar una gestin de calidad que ofre2ca un software de calidad,
La HD)F es la organi2acin internacional encargada de crear todo tipo de es>
tndares, .n concreto, los estndares de calidad forman parte de la norma
HD) #000, que descri<e los elementos que de<e tener un sistema de asegu>
ramiento de la calidad con el fin de que se puedan aplicar a cualquier ne>
gocio o acti5idad,
La HD) #00% es el estndar de aseguramiento de la calidad que se aplica a la
ingeniera del software y eBpone 6asta 5einte eBigencias que de<e cumplir un
<uen sistema de calidad, /ecientemente, la nue5a 5ersin de la norma HD)
#000>3, que data de %##", quiere proporcionar una gua y una ayuda con 5is>
tas a la aplicacin de las eBigencias de la HD) #00% en el caso de una industria
de fa<ricacin y/o 5enta de software,
F Hnternational )rgani2ation
for Dtandari2ation,
*ectura recomendada
Para ms detalles, pod-is
consultar la o<ra siguiente3
/, Oe6oeJ A, Lar5is ?%##"@,
&'( )***-+, - Tool for
'oftware Product and
Process &mprovement,
Gue5a Kor93 Dpringer,
"esumen
La planificacin temporal de un proyecto informtico arranca de la des>
composicin en tareas del proyecto ?EBD@, la estimacin del esfuer2o de cada una
y las precedencias entre las tareas o acti5idades, .sta informacin se dis> pone en
un diagrama P./0 ?o red de acti5idades@ y se o<tiene as el camino crtico
formado por la cadena de acti5idades pro<lemticas que no tienen mar> gen de
tiempo y que determinan la duracin glo<al del proyecto,
.n el caso de los proyectos informticos, adems de las precedencias lgicas, es
necesario a4adir nue5as precedencias entre acti5idades para conseguir un <uen
uso de los recursos, es decir, de los profesionales que forman el equipo de
proyecto y e5itar que se produ2can casos de 7ornada do<le,
A menudo, las 6erramientas informticas para planificar y lle5ar a ca<o el se>
guimiento de proyectos ofrecen diferentes diagramas ?de Gantt, P./0, de ca>
lendario, etc,@ y una 5ariedad amplia de listas,
.l seguimiento y el control del proyecto se reali2an comparando los datos
reales ?o<tenidos de las 6o7as de acti5idad en las que cada miem<ro del equipo del
proyecto detalla el tiempo que 6a dedicado a cada tarea@ con los datos pre> 5istos
en la planificacin 5igente, Di eBisten nue5os datos so<re producti5idad o de<en
lle5arse a ca<o tareas no pre5istas antes, puede ser necesario efectuar una nue5a
calificacin del proyecto ?estimacin de costes y planificacin@ y re> 5isar los
o<7eti5os3 las funcionalidades, los pla2os y el presupuesto,
La ley de Broo9s intenta e5itar la incomprensin so<re el mito del 6om<re> mes
y afirma que a4adir ms personal a un proyecto retrasado no siempre me7ora
las cosas,
.l aseguramiento de la calidad del software es el con7unto de acti5idades de
gestin y organi2acin que permite garanti2ar que el proceso de construccin del
software es seguro y fia<le y, por lo tanto, que el software o<tenido tam<i-n ser de
calidad, .Bisten estndares internacionales so<re el aseguramiento de la calidad
en el campo de la ingeniera del software, en concreto la HD) #00% y la HD) #000>
3,
'()* + P03/!0"/0$%&3 La gestin de un proyecto informtico
La gestin de un proyecto informtico '()* + P03/!0"/0$%&3 $!
!ctividades
%, Di pod-is disponer de una 6erramienta de planificacin y seguimiento de proyectos como
el MD>P/)L.*0, el D(P./P/)L.*0 u otros, estudiad sus funcionalidades mediante el sis>
tema de ayuda ?help@ y compro<ad los listados que se encuentran disponi<les, *omo e7er>
cicio concreto, introducid los datos del proyecto ficticio que 6emos tratado en este
mdulo y, tomando a dos o tres personas como recurso ?miem<ros del equipo@, o<ser5ad
los diferentes grficos y listados que os ofrece la 6erramienta,
$, A4adid las precedencias que os pare2can lgicas a los datos de acti5idades y el esfuer2o es>
timado del caso de la conta<ilidad sencilla en un P* que 6emos 5isto en otro mdulo,
Hmaginad un equipo de un analista ?que tam<i-n tra<a7a como 7efe de proyecto@ y un pro>
gramador, para o<tener, con una 6erramienta como el MD>P/)L.*0 o el D(P./P/)L.*0,
el diagrama de Gantt y la red de acti5idades ?diagrama P./0@ del proyecto, *on los precios
por 6ora de analista y programador que conoc-is, o<tened el coste glo<al del proyecto,
3, Hntentad lle5ar a ca<o una descomposicin de tareas ?EBD@, una estimacin de costes pa>
recida a la del e7emplo de la conta<ilidad sencilla en un P* y una planificacin en el tiem>
po contando con un analista y un programador para el caso de la aplicacin en un
peque4o 6otel,
4atos del 2otel
De quiere implementar una peque4a aplicacin ?simplificada@ de gestin administrati5a de
la recepcin y facturacin de un 6otel, La aplicacin se de<e e7ecutar en un con7unto de
ordenadores personales, de tipo P* compati<le, conectados en red y que comparten los
datos, .l 6otel dispone de 6a<itaciones simples y do<les y ofrece tam<i-n una serie de ser>
5icios ?<ar, restaurante, tintorera, tel-fono, etc,@, cuya facturacin se 6a de incorporar a
la gestin informati2ada de la recepcin y la facturacin, La ocupacin de las 6a<itaciones
puede ser posterior a una reser5a pre5ia, reali2ada directamente por el cliente o mediante
una agencia de 5ia7es,
Las funciones que se de<en implementar son, al menos, las siguientes3
%@ 0ratamientos interacti5os
a@ Mantenimiento del fic6ero de 6a<itaciones
De de<e tener en cuenta que cada 6a<itacin tiene un precio normal, un precio de tempo>
rada alta y otro de temporada <a7a,
<@ Gestin de reser5as
Para dar de alta una reser5a, 6emos de introducir las fec6as de la entrada y la salida y el
nCmero de personas, .l sistema de<e ofrecer las 6a<itaciones disponi<les y aceptar y regis>
trar la eleccin que realice el operador a partir de esta informacin, Los datos complemen>
tarios de la reser5a sern, al menos, el nom<re y el =GH del titular de la reser5a, el tipo de
reser5a ?directo o por agencia@, el identificador de la agencia ?si procede@ y el tel-fono de
la persona que efectCa la reser5a ?cliente o agencia@,
Para modificar o anular una reser5a de<emos partir del nom<re o del =GH del titular de la
reser5a y de la fec6a de reser5a, .s e5idente que en una reser5a puede incluirse ms de una
6a<itacin,
c@ .ntrada de clientes
Los clientes pueden ocupar 6a<itaciones ya reser5adas o las que puedan encontrarse dis>
poni<les si no se 6a reali2ado ninguna reser5a pre5ia, Di eBiste reser5a pre5ia, se asigna au>
tomticamente la 6a<itacin reser5ada y, en caso de que se trate de un cliente nue5o sin
reser5a, se consulta el estado de las 6a<itaciones disponi<les, Di es posi<le, se le admite la
entrada considerndolo un cliente directo y por el nCmero de das que solicite,
Los datos necesarios para registrar la entrada de los clientes son, al menos, el nom<re, el
=GH ?o pasaporte@, el domicilio y la nacionalidad, y la 6a<itacin que ocuparn, *uando
la reser5a sea para ms de una persona, es opcional registrar el nom<re, el =GH y el domi>
cilio de todos los clientes, pero siempre se registrarn estos datos con respecto al titular de
la reser5a,
Pod-is 5er el proyecto ficticio
eBpuesto en el su<apartado %,% de
este mdulo didctico,
Pod-is 5er el e7emplo del P* en el
su<apartado $,&,% y los precios por
6ora de analista y programador en la
acti5idad 3 del mdulo :.stimacin de
costes de un proyecto informtico; de
esta asignatura,
Pod-is 5er el e7emplo del P* en el
su<apartado $,&,% del mdulo
:.stimacin de costes de un proyecto
informtico; de esta asignatura,
d@.ntrada de gastos adicionales
Los diferentes ser5icios del 6otel se encargarn de introducir en sus terminales los gastos
?<ar, restaurante, tintorera, tel-fono, etc,@ efectuados por el cliente y los cargarn en la
6a<itacin correspondiente ?la del titular de la reser5a@, Para registrar uno de estos cargos, se
de<e indicar, al menos, el cdigo del tipo de cargo, el concepto del ser5icio, la fec6a y 6ora
del ser5icio ?opcional@, el importe del ser5icio y la 6a<itacin que soporta el cargo ?siempre
la del titular de la reser5a@,
e@Dalida de clientes
La salida de clientes se efectuar a partir del nCmero de 6a<itacin, *omo resultado de esta
operacin, la 6a<itacin quedar li<re y el sistema ofrecer la posi<ilidad de encadenar au>
tomticamente la operacin con el procedimiento de liquidacin de la cuenta de una 6a>
<itacin,
f@Liquidacin de la cuenta de una 6a<itacin
La facturacin parcial de la cuenta de una 6a<itacin para un cliente directo se puede reali2ar
siempre en cualquier momento ?pago parcial@, La liquidacin final se efectCa, o<ligatoriamen> te,
siempre que 6aya sido registrada la salida del cliente, .s necesario tener en cuenta que lo ms
6a<itual es una factura Cnica por reser5a en el momento de la salida definiti5a de los clientes,
Pero de<emos pre5er las situaciones lgicas que se puedan presentar,
Los clientes que 6ayan reali2ado reser5a mediante una agencia slo tendrn una factura
complementaria de liquidacin de los gastos eBtraordinarios ?<ar, restaurante, tintorera,
tel-fono, etc,@ no cu<iertos por las agencias, Las facturas de alo7amiento y los gastos ordi>
narios se presentarn semanalmente a las agencias para su liquidacin, ?Pod-is 5er la ca> dena
semanal,@
$@ 0ratamientos diferidos a@
*adena diaria
+ Anulacin de reser5as caducadas, Al final de cada da se cancelarn automticamente las
reser5as que de<an 6a<er comen2ado durante el da y que no 6ayan sido anuladas ni
modificadas, De cancela la totalidad de la reser5a ?todos los das y todas las 6a<itacio> nes@,
pero de<e guardarse la informacin so<re el coste que ello representa para las agen> cias,
?Pod-is 5er la cadena semanal,@
+ Listado de ocupaciones, =iariamente se de<e o<tener un listado con los datos de los
clientes residentes cada noc6e en el 6otel, ?De acuerda que slo es o<ligatorio disponer del
nom<re del titular de cada reser5a,@
<@ *adena semanal
'acturacin a las agencias, Al final de la semana se facturarn los cargos de alo7amiento de
las ocupaciones que pro5ienen de reser5as reali2adas mediante las agencias, La factura> cin a
las agencias tiene, con relacin a los precios estndar, un porcenta7e de descuento ?que
puede ser diferente para cada agencia@, Adems, la factura semanal para cada agencia de<e
incluir el cargo por el primer da de las reser5as caducadas sin 6a<er estado ocupadas, .l cargo
es slo un porcenta7e del coste real de la estancia y este porcenta7e se 6a pactado pre5ia y
separadamente con cada agencia,
c@ *adena mensual
.stadsticas de ocupacin, *ada mes se ela<ora un listado que informe del ni5el de ocu>
pacin de cada 6a<itacin y del 6otel en general,
3@ PolCmenes
+ GCmero de 6a<itaciones3 &00 ?0 sencillas y 330 do<les@,
+ GCmero de agencias3 $0,
+ Admisin de reser5as con tres meses de antelacin3
N Media de reser5as diarias3 %!,
N Media de das de estancia de los clientes3 ",
N Media de cargos por ser5icios, por da y 6a<itacin3 !,
#jercicios de autoevaluacin
%, Los diagramas P./0, Qson eBclusi5os de los proyectos informticosI
$, QRu- ocurre cuando una acti5idad que no forma parte del camino crtico tarda ms de lo que
se 6a<a estimadoI
3, QRu- precedencias de<emos tener en cuenta para reali2ar el diagrama P./0I
&, Q*undo se suele lle5ar a ca<o una planificacin ALAP ?lo ms tarde posi<le@I
!, QRui-n es el responsa<le de los datos recogidos durante el seguimiento de un proyectoI
", Q*undo se suele efectuar un informe de situacin de un proyectoI
, La ley de Broo9s, Qes segura al cien por cienI
8, QPor qu- se de<e asegurar la calidad del softwareI
#, Q*undo se puede decir que un software es de calidadI
%0, Q*ules son las normas HD) que afectan a la calidad del softwareI
Solucionario
#jercicios de autoevaluacin
%, Los diagramas P./0 no son eBclusi5os de los proyectos informticos, sino que los in5en> t
6ace d-cadas la Marina norteamericana para cualquier tipo de proyectos,
$, Di el retraso de la acti5idad es inferior al margen, todo queda en un aumento del coste ?el
personal que reali2a el tra<a7o quiere co<rar los das de ms@, pero la duracin glo<al del pro>
yecto no 5ara, Di el retraso es superior al margen, la duracin glo<al del proyecto cam<ia,
3, Para efectuar el diagrama P./0 es necesario tener en cuenta las precedencias que la lgica
dicta entre las diferentes acti5idades que forman la EBD del proyecto y, adems, las que sean
necesarias para garanti2ar que cada uno de los :recursos; del proyecto ?los profesio> nales del
equipo del proyecto@ slo tra<a7e oc6o 6oras al da,
&, .Bisten muc6os casos en los que se puede reali2ar una planificacin ALAP, pero uno muy
6a<itual es cuando se conoce la fec6a en la que se de<e terminar el proyecto y :se tira
6acia atrs; con el fin de 5er cundo de<e iniciarse para estar a tiempo,
!, Aunque es el 7efe de proyecto quien utili2a, procesa y agrega los datos, no de<e ol5idarse que
es cada miem<ro del equipo quien se los proporciona y lo informa de las 6oras que 6a
dedicado en cada una de las tareas que le 6an sido asignadas, 0odos los miem<ros del equipo
son, pues, responsa<les,
", .l 7efe de proyecto ela<ora los informes de situacin y compara la planificacin 5igente con
la informacin real o<tenida al agregar los datos de detalle de las diferentes 6o7as de
acti5idad, A menudo, sir5en como documentacin de <ase con 5istas a un 6ito de control
para reali2ar un <alance de la manera en la que a5an2a el proyecto,
, La ley de Broo9s no es segura al cien por cien, De trata slo de una indicacin gen-rica para
a5isar de que se de<e estar pre5enido ante el mito del 6om<re>mes y tam<i-n de que, en un
proyecto informtico, el 6ec6o de a4adir personal cuando se dan retrasos a menu> do crea
ms pro<lemas de los que resuel5e,
8, De de<e asegurar la calidad del software porque la prctica muestra que el software tiene
siempre errores y pro<lemas de fia<ilidad y/o mantenimiento,
#, (n software es de calidad cuando cumple los requerimientos especificados y, adems, sa>
tisface las necesidades o eBpectati5as del cliente o usuario,
%0, La serie HD) #000 y, en particular, las normas HD) #00% e HD) #000>3, que precisamente
indica cmo se de<e utili2ar la HD) #00%,
$losario
actividad f *ada uno de los tra<a7os que se de<e lle5ar a ca<o en un proyecto y que forma
parte de la EBD ?descomposicin estructural en acti5idades@, 0am<i-n se denomina tarea,
actividad cr&tica f Acti5idad que no tiene margen de tiempo y que forma parte del camino
crtico,
aseguramiento de la calidad de software m *on7unto de acti5idades, planificadas y sis>
temticas, necesarias para certificar que el producto ?software@ satisface los requerimientos de
calidad esta<lecidos,
calidad del software f Grado en el que un sistema, componente o proceso cumple los re>
querimientos especificados y las necesidades o eBpectati5as del cliente o usuario,
camino cr&tico m *on7unto y/o cadena de acti5idades crticas de un proyecto, es decir, de
acti5idades sin margen, que determinan la duracin glo<al de todo el proyecto,
sigla3 *PM
5P6 m ./ase camino crtico
diagrama de $antt m =iagrama que muestra el tiempo en el e7e de a<scisas, mientras que en
cada lnea de las ordenadas se encuentran todas y cada una de las acti5idades que forman el
proyecto, .n la parte i2quierda se escri<e el nom<re de las acti5idades, mientras que en la parte
derec6a se marca una lnea desde la fec6a inicial 6asta la final de cada acti5idad,
diagrama P#", m =escripcin de un proyecto en forma de grafo donde los nudos del gra> fo
son las acti5idades y las flec6as son las relaciones de precedencia directa entre acti5idades,
0am<i-n se conoce como red de actividades o grafo de precedencias,
grafo de precedencias m ./ase diagrama P./0
2itos de control m Acti5idades ficticias con duracin nula, introducidas en la planificacin al
final de las fases o etapas del proyecto o de manera peridica ?una 5e2 en el mes, por e7em> plo@,
para facilitar el seguimiento y el control del proyecto,
2oja de actividad f =ocumento de datos indi5iduales de seguimiento de un proyecto, don> de
cada miem<ro del equipo se4ala las 6oras que 6a ocupado en cada una de las tareas que se le
6an asignado,
informe de situacin de un proyecto m /esumen de la realidad de un proyecto en un
momento determinado, o<tenido a partir de los datos de las 6o7as de acti5idad y del 6ec6o de
compararlas con la planificacin 5igente,
ley de %roo3s f Ad5ertencia para tener en cuenta el mito del 6om<re>mes y que se4ala que si
un proyecto 5a retrasado, el 6ec6o de a4adir ms personal es la manera ms segura de re>
trasarlo toda5a ms,
margen de una actividad m =isponi<ilidad de tiempo en una acti5idad, .l margen es
nulo en las acti5idades crticas que forman el camino crtico,
P#", f ./ase program e5aluation and re5ieS tec6nique
program evaluation and review technique f 0-cnica de re5isin y actuali2acin del pro>
grama o proyecto,
sigla3 P./0
recurso en un proyecto informtico m *ada uno de los profesionales que forman el
equipo de tra<a7o del proyecto,
red de actividades f ./ase diagrama P./0
t+cnica de revisin y actuali/acin del programa o proyecto f Procedimiento para
planificar y orientar el seguimiento de proyectos, <asado en el grafo de precedencias entre
acti5idades que fue desarrollado ya 6ace d-cadas en la Marina norteamericana para el trata>
miento de grandes proyectos de ingeniera de todo tipo,
7%S f ./ase Sor9 <rea9doSn structure
8or3 brea3do8n structure f =escomposicin estructural de los tra<a7os que se de<en
reali2ar, es decir, la lista estructurada de todas las acti5idades y tareas de un proyecto,
sigla3 EBD
%ibliograf&a
%roo3s- 9. ?%#!@, The Mythical Man-Month, /eading3 Addison>Eesley,
5antor- 6.". ?%##8@, (b0ect-(riented Pro0ect Management with 1M2, Gue5a Kor93 Lo6n Eiley
T Dons,
Ince- 4. ?%##&@, &'( )**3 and 'oftware 4uality -ssurance, Londres3 McGraS>1ill,
:enner- 6.$. ?%##!@, 'oftware 4uality Management and &'( )**3, 5ow to Make Them 6ork for
7ou, Gue5a Kor93 Lo6n Eiley T Dons,
:ones- 5. ?%##&@, -ssesment and Control of 'oftware Risks, .ngleSood *liffs3 Prentice 1all,
;e2oe- ".< :arvis- !. ?%##"@, &'( )***-+, - Tool for 'oftware Product and Process &mprovement8
Gue5a Kor93 Dpringer,
6arco- ,. de ?%#8$@, Controlling 'oftware Pro0ects, .ngleSood *liffs3 Prentice 1all,
6oder- :.:.< P2ilips- 5.".< 4avis- #.7. ?%#83@, Pro0ect Management with CPM" PERT and
Precedence 9iagramming ?3,U ed,@, Gue5a Kor93 Pan Gostrand /ein6old,
Page=:ones- 6. ?%#8!@, Practical Pro0ect Management, Restoring 4uality to 9P Pro0ects and 'ystems,
Gue5a Kor93 =orset 1ouse,
Piattini- 6.< 5alvo=6an/ano- :.!< 5ervera- :.< 9ernnde/- *. ?%##"@, -n:lisis y dise;o
detallado de aplicaciones de gesti!n, Madrid3 /a>ma,
Pressman- ".S. ?%##8@, &ngenier%a del software, un enfoque pr:ctico ?&,U ed,@, Madrid3 McGraS>
1ill,
"os- !.< >i1allonga- :. ?%##!@, #esti! dels sistemes d<informaci! a l<empresa, Barcelona3 .di>
ciones (P*,
"oyce- 7. ?%##8@, 'oftware Pro0ect Management, - 1nified =ramework, /eading3 Addison>Eesley
?)<7ect 0ec6nology Deries@,
Sommerville- I. ?%##"@, 'oftware Engineering ?!,U ed,@, /eading3 Addison> Eesley,
,2omset- ". ?%##3@, Third 6ave Pro0ect Management, - 5andbook for Managing the Comple>
&nformation 'ystems for the 3))* s, .ngleSood *liffs3 Prentice 1all,