Gestión Proyectos Computacionales

La gestión
de un proyecto
informático
Planificación, seguimiento,
y aseguramiento de la calidad
Miquel Barceló García
P03/75069/02143
La gestión
de un proyecto
informático
Planificación, seguimiento,
y aseguramiento de la calidad
Miquel Barceló García
P03/75069/02143

© FUOC • P03/7506/02143 La gestión de un proyecto informático
Índice
Introducción .............................................................................................. 5
Objetivos ..................................................................................................... 6
1. Planificación en el tiempo de los proyectos
informáticos ......................................................................................... 7
1.1. La técnica del PERT y el método del camino crítico ........................ 7
1.2. Herramientas informatizadas para la planificación ......................... 12
1.3. La planificación de un proyecto informático ................................... 13
1.3.1. La consideración de los recursos: añadir nuevas
precedencias .......................................................................... 14
2. Seguimiento y control de un proyecto informático .................. 17
2.1. Las hojas de actividad y el informe de situación ............................. 18
2.2. La ley de Brooks ................................................................................ 19
3. Aseguramiento de la calidad en un proyecto
informático .......................................................................................... 21
Resumen ...................................................................................................... 23
Actividades ................................................................................................. 25
Ejercicios de autoevaluación ................................................................. 26
Solucionario ............................................................................................... 28
Glosario ....................................................................................................... 28
Bibliografía ................................................................................................ 29
© FUOC • P03/7506/02143 La gestión de un proyecto informático
Índice
Introducción .............................................................................................. 5
Objetivos ..................................................................................................... 6
informáticos ......................................................................................... 7
1.1. La técnica del PERT y el método del camino crítico ........................ 7
1.2. Herramientas informatizadas para la planificación ......................... 12
1.3. La planificación de un proyecto informático ................................... 13
precedencias .......................................................................... 14
2. Seguimiento y control de un proyecto informático .................. 17
2.1. Las hojas de actividad y el informe de situación ............................. 18
2.2. La ley de Brooks ................................................................................ 19
informático .......................................................................................... 21
Resumen ...................................................................................................... 23
Actividades ................................................................................................. 25
Ejercicios de autoevaluación ................................................................. 26
Solucionario ............................................................................................... 28
Glosario ....................................................................................................... 28
Bibliografía ................................................................................................ 29

© FUOC • P03/7506/02143 5 La gestión de un proyecto informático
Introducción
En los módulos didácticos “El proyecto informático de construcción de software”
y “Estimación de costes de un proyecto informático” analizamos los aspectos más
específicos y peculiares de los proyectos informáticos de construcción de software
de aplicación en la informática de gestión. En concreto, nos referimos a cómo el
proyecto informático se especifica a medida que se va elaborando y la dificultad
que ello conlleva con vistas a la estimación de las cargas y los costes.
De hecho, lo que ahora queda por ver de la gestión de un proyecto informá-
tico no es en absoluto tan diferente de lo que es habitual en la gestión de
cualquier otro proyecto de ingeniería, sobre todo si se recuerda, a la hora de
tomar las decisiones imprescindibles de gestión del proyecto, que cuando se
habla de personas-mes para considerar el esfuerzo, no se puede en absoluto
pensar en intercambiar los dos factores.
Una vez se ha llevado a cabo la primera estimación de costes, a menudo, a par-
tir de una primera especificación genérica del alcance del proyecto muy pre-
caria, es necesario finalizar la etapa de calificación y planificar en el tiempo las
diferentes tareas pendientes y, cuando ya se ha iniciado el proceso de desarro-
llo del proyecto, sólo se debe realizar el seguimiento y el control.
En este módulo, repasamos brevemente los problemas generales de la planifi-
cación temporal de actividades, con la mención de temas clásicos como los
diagramas PERT o el método del camino crítico (CPM), sin olvidar hacer una
referencia inevitable a las diferentes herramientas informáticas disponibles
que pueden ayudar en esta actividad de planificación.
A partir de la planificación de actividades, es mucho más sencillo ordenar el
proceso de control del proyecto y el seguimiento de su desarrollo para llegar a
finalizar con éxito la actividad de construir un software de aplicación en la in-
formática de gestión.
Una vez revisadas brevemente las actividades típicas de gestión de proyectos
(planificación, seguimiento y control), al final de este módulo planteamos, de
manera básica e introductoria, el problema del aseguramiento de la calidad del
software (software quality assurance), que ha llegado a alcanzar una gran impor-
tancia en los últimos años, posiblemente por la falta de calidad y fiabilidad de
la mayoría del software construido.
Podéis ver el mito del hombre-mes
en el subapartado 1.3.2 del módulo
“Estimación de costes de un proyecto
informático” de esta asignatura.
Introducción
En los módulos didácticos “El proyecto informático de construcción de software”
y “Estimación de costes de un proyecto informático” analizamos los aspectos más
específicos y peculiares de los proyectos informáticos de construcción de software
de aplicación en la informática de gestión. En concreto, nos referimos a cómo el
proyecto informático se especifica a medida que se va elaborando y la dificultad
que ello conlleva con vistas a la estimación de las cargas y los costes.
De hecho, lo que ahora queda por ver de la gestión de un proyecto informá-
tico no es en absoluto tan diferente de lo que es habitual en la gestión de
cualquier otro proyecto de ingeniería, sobre todo si se recuerda, a la hora de
tomar las decisiones imprescindibles de gestión del proyecto, que cuando se
habla de personas-mes para considerar el esfuerzo, no se puede en absoluto
pensar en intercambiar los dos factores.
Una vez se ha llevado a cabo la primera estimación de costes, a menudo, a par-
tir de una primera especificación genérica del alcance del proyecto muy pre-
caria, es necesario finalizar la etapa de calificación y planificar en el tiempo las
diferentes tareas pendientes y, cuando ya se ha iniciado el proceso de desarro-
llo del proyecto, sólo se debe realizar el seguimiento y el control.
En este módulo, repasamos brevemente los problemas generales de la planifi-
cación temporal de actividades, con la mención de temas clásicos como los
diagramas PERT o el método del camino crítico (CPM), sin olvidar hacer una
referencia inevitable a las diferentes herramientas informáticas disponibles
que pueden ayudar en esta actividad de planificación.
A partir de la planificación de actividades, es mucho más sencillo ordenar el
proceso de control del proyecto y el seguimiento de su desarrollo para llegar a
finalizar con éxito la actividad de construir un software de aplicación en la in-
formática de gestión.
Una vez revisadas brevemente las actividades típicas de gestión de proyectos
(planificación, seguimiento y control), al final de este módulo planteamos, de
manera básica e introductoria, el problema del aseguramiento de la calidad del
software (software quality assurance), que ha llegado a alcanzar una gran impor-
tancia en los últimos años, posiblemente por la falta de calidad y fiabilidad de
la mayoría del software construido.
Podéis ver el mito del hombre-mes
en el subapartado 1.3.2 del módulo

Objetivos
En este módulo se cierra el estudio de la gestión de un proyecto informático
de construcción de software de aplicación en la informática de gestión. Se tra-
tan los temas de la planificación temporal de actividades y, a partir de esta pla-
nificación, del seguimiento y el control del desarrollo del proyecto. El módulo
termina con una referencia breve al problema del aseguramiento de la calidad
del software. Con el estudio de este módulo y de los materiales didácticos aso-
ciados, el estudiante debe alcanzar los objetivos siguientes:
1. Conocer la problemática general de la planificación temporal de proyectos,
el uso de diagramas de Gantt, la técnica del PERT y el método del camino
crítico (CPM).
2. Saber planificar en el tiempo las actividades de un proyecto informático,
teniendo en cuenta los recursos disponibles y las limitaciones de uso.
3. Conocer los problemas que se plantean y los documentos que se suelen uti-
lizar para controlar el desarrollo de un proyecto y realizar un seguimiento
completo y exhaustivo.
4. Saber cuáles son las decisiones más habituales que se han de tomar en el
proceso de control de un proyecto informático y los aspectos que más las
condicionan.
5. Conocer las herramientas informáticas que ayudan tanto en el proceso de
planificación del proyecto, como en el de seguimiento y control de una
planificación ya efectuada.
6. Obtener una visión inicial de los problemas de aseguramiento de la cali-
dad del software (software quality assurance) y, en definitiva, de la dificultad de
obtener software seguro, fiable y de calidad.
Objetivos
En este módulo se cierra el estudio de la gestión de un proyecto informático
de construcción de software de aplicación en la informática de gestión. Se tra-
tan los temas de la planificación temporal de actividades y, a partir de esta pla-
nificación, del seguimiento y el control del desarrollo del proyecto. El módulo
termina con una referencia breve al problema del aseguramiento de la calidad
del software. Con el estudio de este módulo y de los materiales didácticos aso-
ciados, el estudiante debe alcanzar los objetivos siguientes:
1. Conocer la problemática general de la planificación temporal de proyectos,
el uso de diagramas de Gantt, la técnica del PERT y el método del camino
crítico (CPM).
2. Saber planificar en el tiempo las actividades de un proyecto informático,
teniendo en cuenta los recursos disponibles y las limitaciones de uso.
3. Conocer los problemas que se plantean y los documentos que se suelen uti-
lizar para controlar el desarrollo de un proyecto y realizar un seguimiento
completo y exhaustivo.
4. Saber cuáles son las decisiones más habituales que se han de tomar en el
proceso de control de un proyecto informático y los aspectos que más las
condicionan.
5. Conocer las herramientas informáticas que ayudan tanto en el proceso de
planificación del proyecto, como en el de seguimiento y control de una
planificación ya efectuada.
6. Obtener una visión inicial de los problemas de aseguramiento de la cali-
dad del software (software quality assurance) y, en definitiva, de la dificultad de
obtener software seguro, fiable y de calidad.

informáticos
Tal como explicamos en otro módulo, una vez determinada la voluntad de
iniciar un proyecto informático, las etapas que caracterizan la gestión son
dos: la primera es la calificación inicial (estimación de costes y planifica-
ción temporal) y la segunda es el desarrollo (seguimiento y control del pro-
yecto, tal vez acompañados de nuevas estimaciones y planificaciones) para
llegar, de una manera o de otra, con éxito o sin él, al final o cierre definitivo
del proyecto.
Una vez conocida la amplia problemática de la estimación de costes, que
nos ha ocupado un módulo entero, ahora planificaremos en el tiempo las
diferentes tareas o actividades de las que consta el proyecto.
Cabe mencionar que la planificación temporal de proyectos a partir de su des-
composición en tareas (WBS) y la estimación de la duración de cada una es un
proceso suficientemente conocido y que los proyectos informáticos de cons-
trucción de software comparten con muchos otros proyectos de ingeniería. Por
otra parte, como veremos, salvo 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 ingeniería.
Comenzamos con la exposición breve y sintética de conceptos tradiciona-
les de la planificación temporal de actividades como la técnica del PERT y
el método del camino crítico (CPM) y después analizamos el caso general
de la planificación temporal de proyectos informáticos.
1.1. La técnica del PERT y el método del camino crítico
El fundamento central de las técnicas del PERT es la representación gráfica del
proyecto en un diagrama que muestre las relaciones y, sobre todo, las preceden-
cias entre las tareas que constituyen el proyecto. Este diagrama, que algunos de-
nominan diagrama PERT, en el fondo no es más que un grafo de precedencias de
actividades que a menudo se llama red de actividades (activity network) o, también,
diagrama de precedencias.
La técnica del PERT* (técnica de revisión y actualización del programa
o proyecto) es un procedimiento desarrollado ya hace décadas por la
Marina norteamericana (US Navy) para el tratamiento de grandes pro-
yectos de ingeniería de todo tipo.
Podéis ver las etapas de un proyecto
informático en el subapartado 1.2
del módulo “El proyecto informático
de construcción de software” de esta
asignatura.
Podéis ver la problemática
de la estimación de costes
en el módulo “Estimación de costes
de un proyecto informático” de esta
asignatura.
* PERT es la sigla de la expresión
inglesa Program Evaluation
and Review Technique.
informáticos
Tal como explicamos en otro módulo, una vez determinada la voluntad de
iniciar un proyecto informático, las etapas que caracterizan la gestión son
dos: la primera es la calificación inicial (estimación de costes y planifica-
ción temporal) y la segunda es el desarrollo (seguimiento y control del pro-
yecto, tal vez acompañados de nuevas estimaciones y planificaciones) para
llegar, de una manera o de otra, con éxito o sin él, al final o cierre definitivo
del proyecto.
Una vez conocida la amplia problemática de la estimación de costes, que
nos ha ocupado un módulo entero, ahora planificaremos en el tiempo las
diferentes tareas o actividades de las que consta el proyecto.
Cabe mencionar que la planificación temporal de proyectos a partir de su des-
composición en tareas (WBS) y la estimación de la duración de cada una es un
proceso suficientemente conocido y que los proyectos informáticos de cons-
trucción de software comparten con muchos otros proyectos de ingeniería. Por
otra parte, como veremos, salvo 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 ingeniería.
Comenzamos con la exposición breve y sintética de conceptos tradiciona-
les de la planificación temporal de actividades como la técnica del PERT y
el método del camino crítico (CPM) y después analizamos el caso general
de la planificación temporal de proyectos informáticos.
1.1. La técnica del PERT y el método del camino crítico
El fundamento central de las técnicas del PERT es la representación gráfica del
proyecto en un diagrama que muestre las relaciones y, sobre todo, las preceden-
cias entre las tareas que constituyen el proyecto. Este diagrama, que algunos de-
nominan diagrama PERT, en el fondo no es más que un grafo de precedencias de
actividades que a menudo se llama red de actividades (activity network) o, también,
diagrama de precedencias.
La técnica del PERT* (técnica de revisión y actualización del programa
o proyecto) es un procedimiento desarrollado ya hace décadas por la
Marina norteamericana (US Navy) para el tratamiento de grandes pro-
yectos de ingeniería de todo tipo.
Podéis ver las etapas de un proyecto
informático en el subapartado 1.2
del módulo “El proyecto informático
de construcción de software” de esta
asignatura.
Podéis ver la problemática
de la estimación de costes
en el módulo “Estimación de costes
asignatura.
* PERT es la sigla de la expresión
inglesa Program Evaluation
and Review Technique.

A menudo, los dos métodos se pueden tratar conjuntamente, tal como hare-
mos en esta exposición simplificada.
Conviene advertir que, aunque aquí se habla de tareas o actividades indis-
tintamente, a menudo la nomenclatura más habitual utiliza el término ac-
tividades cuando se refiere a PERT, aunque actualmente la elección suele
depender de la manera como se haya traducido el concepto en la herra-
mienta informática de la que nos ayudamos a la hora de llevar a cabo la
planificación de un proyecto.
El conjunto de las técnicas PERT y el método del camino crítico (CPM) propor-
cionan herramientas cuantitativas que permiten determinar lo siguiente:
1) El camino crítico del proyecto, que es la secuencia o cadena de activida-
des que determina la duración total del proyecto.
2) Las estimaciones de tiempos más probables, tanto para la totalidad del
proyecto como para el inicio y el final de cada una de las tareas o actividades
individuales.
3) Los márgenes de tiempo que se dan para cada tarea o actividad individual
y que no impliquen un retraso del proyecto.
Pongamos un ejemplo, que es la manera más clara de verlo. Para no tener que
realizar un diagrama complejo, imaginamos un pequeño proyecto del cual he-
mos efectuado una descomposición en diez actividades, como las que se indi-
can en la tabla siguiente:
El método del camino crítico (CPM) es un método de optimización
que, como el PERT, también utiliza una red de tareas del proyecto.
El diagrama PERT es un grafo de precedencias donde los nudos o nodos
son las actividades, mientras que los arcos son las relaciones de precedencia
entre actividades. De cada actividad, se debe saber la duración estimada y
las actividades que le son precedentes directos. El resto, en cierta manera,
surge casi automáticamente del mismo diagrama.
Actividades, duración y precedencias de un proyecto ficticio
Identificación
numérica
Nombre de la actividad Duración estimada Precedencias
1 Inicio 0 -
2
Establecer los
requerimientos
3 1
3 Seleccionar los drivers 2 1
CPM es la sigla de la expresión
inglesa Critical Path Method.
Podéis ver las herramientas
informatizadas para la planificación
de un proyecto en el subapartado
1.2 de este módulo didáctico.
A menudo, los dos métodos se pueden tratar conjuntamente, tal como hare-
mos en esta exposición simplificada.
Conviene advertir que, aunque aquí se habla de tareas o actividades indis-
tintamente, a menudo la nomenclatura más habitual utiliza el término ac-
tividades cuando se refiere a PERT, aunque actualmente la elección suele
depender de la manera como se haya traducido el concepto en la herra-
mienta informática de la que nos ayudamos a la hora de llevar a cabo la
planificación de un proyecto.
El conjunto de las técnicas PERT y el método del camino crítico (CPM) propor-
cionan herramientas cuantitativas que permiten determinar lo siguiente:
1) El camino crítico del proyecto, que es la secuencia o cadena de activida-
des que determina la duración total del proyecto.
2) Las estimaciones de tiempos más probables, tanto para la totalidad del
proyecto como para el inicio y el final de cada una de las tareas o actividades
individuales.
3) Los márgenes de tiempo que se dan para cada tarea o actividad individual
y que no impliquen un retraso del proyecto.
Pongamos un ejemplo, que es la manera más clara de verlo. Para no tener que
realizar un diagrama complejo, imaginamos un pequeño proyecto del cual he-
mos efectuado una descomposición en diez actividades, como las que se indi-
can en la tabla siguiente:
El método del camino crítico (CPM) es un método de optimización
que, como el PERT, también utiliza una red de tareas del proyecto.
El diagrama PERT es un grafo de precedencias donde los nudos o nodos
son las actividades, mientras que los arcos son las relaciones de precedencia
entre actividades. De cada actividad, se debe saber la duración estimada y
las actividades que le son precedentes directos. El resto, en cierta manera,
surge casi automáticamente del mismo diagrama.
Identificación
numérica
1 Inicio 0 -
2
Establecer los
requerimientos
3 1
3 Seleccionar los drivers 2 1
CPM es la sigla de la expresión
inglesa Critical Path Method.
Podéis ver las herramientas
informatizadas para la planificación
de un proyecto en el subapartado
1.2 de este módulo didáctico.

Conviene, tal como se lleva a cabo aquí, incluir siempre las actividades de ini-
cio y final, puramente ficticias y con duración cero.
La tabla nos ofrece para cada actividad un nombre, una identificación nu-
mérica (de uno a diez), la duración estimada de la actividad (en unidades
arbitrarias; por ejemplo, en semanas) y las tareas que son inmediatamente
anteriores e imprescindibles para poder empezar cada actividad en concre-
to (precedencias).
Si se quiere, se puede imaginar que se trata de construir un sistema informáti-
co determinado que utiliza datos que ya tenemos (recogidos en la actividad 5)
y que utiliza una serie de drivers diferentes (que se seleccionan en la actividad
3 y se prueban en la actividad 6) para acceder a periféricos o a aquello que sea
necesario. De hecho, el proyecto en sí no es importante, ya que se trata de un
ejemplo ficticio para ilustrar el PERT y el CPM.
Si se dispone de estos datos (actividades, duración estimada y precedencias) se
puede dibujar un grafo como el de la figura de la página siguiente.
Como se puede ver en el diagrama, las flechas marcan las relaciones de prece-
dencia que existen entre las actividades, mientras que los nudos son las acti-
vidades, de las cuales se han recogido también una serie de datos: el número
identificador, el nombre de la actividad y la duración estimada (puesta entre
paréntesis dentro del nudo).
Sobre cada nudo se ha añadido también la información que sale directamente
de la explotación del diagrama de precedencias: las semanas de inicio y final
de cada actividad. Conviene darse cuenta de que la actividad final tiene como
precedentes todos los arcos pendientes del diagrama.
Por ejemplo, la actividad 1 (inicio) empieza en la semana cero y, al tener una
duración nula, termina también en la semana cero. Pero la actividad 2 (esta-
blecer los requerimientos) comienza en la semana cero (justo después de la ac-
tividad precedente, inicio) y finaliza al final de la semana tres, ya que dura
precisamente tres semanas. Del mismo modo, la actividad 4 (realizar el diseño)
Identificación
numérica
4 Realizar el diseño 4 2
5 Recoger datos 2 2 y 3
6 Probar los drivers 6 3
7 Codificar 4 4
8 Elaborar la documentación 2 4
9 Probar el producto 4 5, 6 y 7
10 Final 0 ?
Conviene, tal como se lleva a cabo aquí, incluir siempre las actividades de ini-
cio y final, puramente ficticias y con duración cero.
La tabla nos ofrece para cada actividad un nombre, una identificación nu-
mérica (de uno a diez), la duración estimada de la actividad (en unidades
arbitrarias; por ejemplo, en semanas) y las tareas que son inmediatamente
anteriores e imprescindibles para poder empezar cada actividad en concre-
to (precedencias).
Si se quiere, se puede imaginar que se trata de construir un sistema informáti-
co determinado que utiliza datos que ya tenemos (recogidos en la actividad 5)
y que utiliza una serie de drivers diferentes (que se seleccionan en la actividad
3 y se prueban en la actividad 6) para acceder a periféricos o a aquello que sea
necesario. De hecho, el proyecto en sí no es importante, ya que se trata de un
ejemplo ficticio para ilustrar el PERT y el CPM.
Si se dispone de estos datos (actividades, duración estimada y precedencias) se
puede dibujar un grafo como el de la figura de la página siguiente.
Como se puede ver en el diagrama, las flechas marcan las relaciones de prece-
dencia que existen entre las actividades, mientras que los nudos son las acti-
vidades, de las cuales se han recogido también una serie de datos: el número
identificador, el nombre de la actividad y la duración estimada (puesta entre
paréntesis dentro del nudo).
Sobre cada nudo se ha añadido también la información que sale directamente
de la explotación del diagrama de precedencias: las semanas de inicio y final
de cada actividad. Conviene darse cuenta de que la actividad final tiene como
precedentes todos los arcos pendientes del diagrama.
Por ejemplo, la actividad 1 (inicio) empieza en la semana cero y, al tener una
duración nula, termina también en la semana cero. Pero la actividad 2 (esta-
blecer los requerimientos) comienza en la semana cero (justo después de la ac-
tividad precedente, inicio) y finaliza al final de la semana tres, ya que dura
precisamente tres semanas. Del mismo modo, la actividad 4 (realizar el diseño)
Identificación
numérica
4 Realizar el diseño 4 2
5 Recoger datos 2 2 y 3
6 Probar los drivers 6 3
7 Codificar 4 4
8 Elaborar la documentación 2 4
9 Probar el producto 4 5, 6 y 7
10 Final 0 ?

no puede iniciarse hasta que no termine la precedente (la 2, establecer los re-
querimientos), es decir, no puede empezar hasta que no ha acabado la semana
tres. Además, al durar cuatro semanas, no finalizará hasta el final de la semana
siete. Y así sucesivamente.
En el caso de la actividad 9 (probar el producto) se dan tres precedentes direc-
tos: la actividad 7 (codificar), que finaliza en la semana once; la actividad 5 (re-
coger datos), que finaliza en la semana cinco; y la actividad 6 (probar los
drivers), que finaliza en la semana ocho. Evidentemente, como se debe esperar
a que las tres hayan terminado, la actividad 9 (probar el producto) no puede
empezar hasta que no haya acabado la actividad 7 (codificar) en la semana on-
ce, que es la que finaliza más tarde de todas.
Una vez se ha realizado el diagrama completo, se puede ver que el proyecto
dura un total de quince semanas. Y no sólo eso; el diagrama PERT, gracias al
método del camino crítico, nos permite saber algo de gran importancia para
el futuro de la gestión del proyecto.
Una observación sencilla del diagrama nos muestra que las actividades 1 (ini-
cio), 2 (establecer los requerimientos), 4 (realizar el diseño), 7 (codificar), 9
(probar el producto) y 10 (final) no tienen ningún margen. Es decir, si alguna
de estas actividades tardara más de lo que se ha estimado, todo el proyecto se
alargaría más de las quince semanas previstas.
Las actividades críticas...
... son las que forman el cami-
no crítico y no tienen ningún
margen. Cualquier desviación
en la duración de estas activi-
dades se traduce en una
desviación en la duración
del proyecto.
no puede iniciarse hasta que no termine la precedente (la 2, establecer los re-
querimientos), es decir, no puede empezar hasta que no ha acabado la semana
tres. Además, al durar cuatro semanas, no finalizará hasta el final de la semana
siete. Y así sucesivamente.
En el caso de la actividad 9 (probar el producto) se dan tres precedentes direc-
tos: la actividad 7 (codificar), que finaliza en la semana once; la actividad 5 (re-
coger datos), que finaliza en la semana cinco; y la actividad 6 (probar los
drivers), que finaliza en la semana ocho. Evidentemente, como se debe esperar
a que las tres hayan terminado, la actividad 9 (probar el producto) no puede
empezar hasta que no haya acabado la actividad 7 (codificar) en la semana on-
ce, que es la que finaliza más tarde de todas.
Una vez se ha realizado el diagrama completo, se puede ver que el proyecto
dura un total de quince semanas. Y no sólo eso; el diagrama PERT, gracias al
método del camino crítico, nos permite saber algo de gran importancia para
el futuro de la gestión del proyecto.
Una observación sencilla del diagrama nos muestra que las actividades 1 (ini-
cio), 2 (establecer los requerimientos), 4 (realizar el diseño), 7 (codificar), 9
(probar el producto) y 10 (final) no tienen ningún margen. Es decir, si alguna
de estas actividades tardara más de lo que se ha estimado, todo el proyecto se
alargaría más de las quince semanas previstas.
Las actividades críticas...
... son las que forman el cami-
no crítico y no tienen ningún
margen. Cualquier desviación
en la duración de estas activi-
dades se traduce en una
desviación en la duración
del proyecto.

En el diagrama, el camino crítico está marcado por flechas continuas.
Por otra parte, el diagrama PERT nos permite ver que existen actividades que no
son tan decisivas en la vida del proyecto. Por ejemplo, la actividad 6 (probar los
drivers) tiene marcados un inicio y un final (2, 8). Es decir, se puede comenzar a
efectuar una vez finalizada la segunda semana del proyecto (justo cuando acaba
la actividad precedente 3, Seleccionar los drivers) y, si se cumplen las estimaciones
de duración, terminará al final de la semana ocho. Ahora bien, la actividad 9 (pro-
bar el producto), de la cual la 6 es precedente, tiene también como precedente la
actividad 7 (codificar); y ello provoca que no pueda empezar hasta que no haya
finalizado la semana once y que la actividad 6 tenga un margen de tres semanas
(11 − 8 = 3), de manera que no será nada crítica.
Es decir, si la actividad 6 (probar los drivers) tardara siete semanas en lugar de
las seis semanas estimadas, el proyecto duraría también quince semanas, ya
que la actividad 6 no forma parte del camino crítico y, como se ve en el diagra-
ma, tiene un margen de tres semanas (podría empezar más tarde o durar más
de lo que se había estimado).
Con vistas a la gestión de un proyecto es muy importante saber qué activida-
des son críticas (es decir, qué actividades forman parte del camino crítico) y
cuáles no. Por otra parte, conviene remarcar que las actividades no críticas dis-
ponen de un margen que permite que el planificador acomode mejor los re-
cursos y, sobre todo, que la buena gestión del proyecto pase por el control
estricto de las actividades que forman parte del camino crítico.
Evidentemente, las cosas son más complicadas en el caso de proyectos con
muchas más actividades. Pero, afortunadamente, en estos proyectos es fácil
poder disponer de una herramienta informatizada que, de manera automá-
tica, nos da el camino crítico y con todas las ventajas que esto representa.
Cabe mencionar que en este ejemplo se ha utilizado lo que se llama una pla-
nificación ASAP, que sitúa cada actividad lo antes posible y es el procedi-
Las actividades que no tienen ningún margen forman lo que se denomi-
na camino crítico y, en definitiva, son las que determinan la duración
final del proyecto. A menudo estas actividades se llaman actividades
críticas.
La técnica del PERT con la determinación del camino crítico es un sistema
muy adecuado para la buena gestión de un proyecto (de cualquier proyec-
to), ya que nos permite centrar los esfuerzos en las actividades críticas y uti-
lizar las que no lo son para disponer de los recursos con más agilidad.
Para cada actividad...
... se puede establecer una
planificación de tipo:
• ASAP, del inglés as soon
as posible, tan pronto
como sea posible.
• ALAP, del inglés as last
• as posible, tan tarde como
sea posible.
En el diagrama, el camino crítico está marcado por flechas continuas.
Por otra parte, el diagrama PERT nos permite ver que existen actividades que no
son tan decisivas en la vida del proyecto. Por ejemplo, la actividad 6 (probar los
drivers) tiene marcados un inicio y un final (2, 8). Es decir, se puede comenzar a
efectuar una vez finalizada la segunda semana del proyecto (justo cuando acaba
la actividad precedente 3, Seleccionar los drivers) y, si se cumplen las estimaciones
de duración, terminará al final de la semana ocho. Ahora bien, la actividad 9 (pro-
bar el producto), de la cual la 6 es precedente, tiene también como precedente la
actividad 7 (codificar); y ello provoca que no pueda empezar hasta que no haya
finalizado la semana once y que la actividad 6 tenga un margen de tres semanas
(11 − 8 = 3), de manera que no será nada crítica.
Es decir, si la actividad 6 (probar los drivers) tardara siete semanas en lugar de
las seis semanas estimadas, el proyecto duraría también quince semanas, ya
que la actividad 6 no forma parte del camino crítico y, como se ve en el diagra-
ma, tiene un margen de tres semanas (podría empezar más tarde o durar más
de lo que se había estimado).
Con vistas a la gestión de un proyecto es muy importante saber qué activida-
des son críticas (es decir, qué actividades forman parte del camino crítico) y
cuáles no. Por otra parte, conviene remarcar que las actividades no críticas dis-
ponen de un margen que permite que el planificador acomode mejor los re-
cursos y, sobre todo, que la buena gestión del proyecto pase por el control
estricto de las actividades que forman parte del camino crítico.
Evidentemente, las cosas son más complicadas en el caso de proyectos con
muchas más actividades. Pero, afortunadamente, en estos proyectos es fácil
poder disponer de una herramienta informatizada que, de manera automá-
tica, nos da el camino crítico y con todas las ventajas que esto representa.
Cabe mencionar que en este ejemplo se ha utilizado lo que se llama una pla-
nificación ASAP, que sitúa cada actividad lo antes posible y es el procedi-
Las actividades que no tienen ningún margen forman lo que se denomi-
na camino crítico y, en definitiva, son las que determinan la duración
final del proyecto. A menudo estas actividades se llaman actividades
críticas.
La técnica del PERT con la determinación del camino crítico es un sistema
muy adecuado para la buena gestión de un proyecto (de cualquier proyec-
to), ya que nos permite centrar los esfuerzos en las actividades críticas y uti-
lizar las que no lo son para disponer de los recursos con más agilidad.
Para cada actividad...
... se puede establecer una
planificación de tipo:
• ASAP, del inglés as soon
as posible, tan pronto
como sea posible.
• ALAP, del inglés as last
• as posible, tan tarde como
sea posible.

miento habitual cuando se parte de la fecha de inicio del proyecto y se quiere
encontrar el momento en el que se finalizará. En otros casos, generalmente
cuando se parte del día en el que el proyecto debe estar acabado, se utiliza un
proceso contrario, a partir de la fecha de fin del proyecto, hecho que se conoce
como una planificación ALAP.
1.2. Herramientas informatizadas para la planificación
Cuando se habla de herramientas informatizadas para la planificación, ya no se trata,
como pasaba en el caso de la estimación de costes, de herramientas que a menudo
son muy caras* y que sólo se utilizan para la estimación de costes en proyectos
informáticos. Ya hemos mencionado que la parte de la planificación temporal de
proyectos informáticos es prácticamente igual a la planificación de cualquier otro
proyecto de ingeniería. Esto provoca que las herramientas informáticas disponi-
bles, por el hecho de tener un mercado mucho más amplio, tengan un coste más
asequible y su uso se convierta en muy habitual.
El problema que se plantea a menudo es decidir cuál de las muchas herramien-
tas disponibles en el mercado se debe escoger. Pero se trata de un problema
falso. Como la mayoría de las herramientas informáticas de utilización muy
extendida, los sistemas de ayuda a la planificación de proyectos (y también,
como veremos, al seguimiento y control) proponen una gran cantidad de fun-
cionalidades que en general no se utilizan. Lo mismo ocurre, por ejemplo, con
los procesadores de textos o las hojas de cálculo.
Ahora bien, actualmente, para la planificación de proyectos, las herramientas
informáticas más habituales en nuestro entorno geográfico se reducen al MS-
PROJECT y el SUPERPROJECT, a causa de la fuerza de su sistema de ventas.
Elegir una de las dos herramientas es en cierta manera inútil. Cuando una de
las herramientas ofrece una funcionalidad nueva no disponible en la otra, sólo
se debe esperar unos meses y la nueva versión de esta otra herramienta incor-
porará también la misma funcionalidad. Además, cabe recordar que la mayo-
ría de estas funcionalidades no siempre se utilizan. Como ocurre con los
procesadores de texto, a menudo es mejor lo que se utiliza desde hace más
tiempo, ya que es lo más conocido y familiar.
Una vez explicado esto, debería quedar claro que si los ejemplos de este mó-
dulo se presentan en MS-PROJECT es únicamente porque esta herramienta ha
Dicho de otra manera, todas las herramientas disponibles en el mercado
tienen, además de complementos más o menos interesantes, los ele-
mentos mínimos para efectuar una buena planificación temporal de un
proyecto. El problema, a menudo, es cómo librarse de todo aquello que
la herramienta informática ofrece y que no vamos a utilizar.
* El SLIM, por ejemplo.
Podéis ver el subapartado 2.2
de este módulo didáctico.
El autor de este módulo...
... por ejemplo, ha escrito
el texto original con el Word
4.0 de Microsoft para DOS,
que data de 1987: para teclear
es suficiente con ello.
miento habitual cuando se parte de la fecha de inicio del proyecto y se quiere
encontrar el momento en el que se finalizará. En otros casos, generalmente
cuando se parte del día en el que el proyecto debe estar acabado, se utiliza un
proceso contrario, a partir de la fecha de fin del proyecto, hecho que se conoce
como una planificación ALAP.
1.2. Herramientas informatizadas para la planificación
Cuando se habla de herramientas informatizadas para la planificación, ya no se trata,
como pasaba en el caso de la estimación de costes, de herramientas que a menudo
son muy caras* y que sólo se utilizan para la estimación de costes en proyectos
informáticos. Ya hemos mencionado que la parte de la planificación temporal de
proyectos informáticos es prácticamente igual a la planificación de cualquier otro
proyecto de ingeniería. Esto provoca que las herramientas informáticas disponi-
bles, por el hecho de tener un mercado mucho más amplio, tengan un coste más
asequible y su uso se convierta en muy habitual.
El problema que se plantea a menudo es decidir cuál de las muchas herramien-
tas disponibles en el mercado se debe escoger. Pero se trata de un problema
falso. Como la mayoría de las herramientas informáticas de utilización muy
extendida, los sistemas de ayuda a la planificación de proyectos (y también,
como veremos, al seguimiento y control) proponen una gran cantidad de fun-
cionalidades que en general no se utilizan. Lo mismo ocurre, por ejemplo, con
los procesadores de textos o las hojas de cálculo.
Ahora bien, actualmente, para la planificación de proyectos, las herramientas
informáticas más habituales en nuestro entorno geográfico se reducen al MS-
PROJECT y el SUPERPROJECT, a causa de la fuerza de su sistema de ventas.
Elegir una de las dos herramientas es en cierta manera inútil. Cuando una de
las herramientas ofrece una funcionalidad nueva no disponible en la otra, sólo
se debe esperar unos meses y la nueva versión de esta otra herramienta incor-
porará también la misma funcionalidad. Además, cabe recordar que la mayo-
ría de estas funcionalidades no siempre se utilizan. Como ocurre con los
procesadores de texto, a menudo es mejor lo que se utiliza desde hace más
tiempo, ya que es lo más conocido y familiar.
Una vez explicado esto, debería quedar claro que si los ejemplos de este mó-
dulo se presentan en MS-PROJECT es únicamente porque esta herramienta ha
Dicho de otra manera, todas las herramientas disponibles en el mercado
tienen, además de complementos más o menos interesantes, los ele-
mentos mínimos para efectuar una buena planificación temporal de un
proyecto. El problema, a menudo, es cómo librarse de todo aquello que
la herramienta informática ofrece y que no vamos a utilizar.
* El SLIM, por ejemplo.
Podéis ver el subapartado 2.2
El autor de este módulo...
... por ejemplo, ha escrito
el texto original con el Word
4.0 de Microsoft para DOS,
que data de 1987: para teclear
es suficiente con ello.

estado disponible, pero no porque exista alguna preferencia que se pueda ge-
neralizar a otros usuarios.
Lo que importa de las herramientas informatizadas para la ayuda a la pla-
nificación de proyectos es que todas ofrecen la posibilidad de mostrar el
diagrama PERT (o red de actividades) y marcar, además, el camino crítico
de manera automática. También ofrecen una gestión de recursos completa
y un montón de diagramas y listas (que aumentan día a día) que permiten
incluso realizar una presentación brillante y muy profesional de la planifi-
cación de un proyecto.
1.3. La planificación de un proyecto informático
En la planificación de un proyecto informático, además del diagrama PERT, se
suele utilizar una especie de diagrama temporal llamado diagrama de Gantt.
En el caso del proyecto ficticio que se ha utilizado para exponer el PERT y el
CPM, el diagrama de Gantt sería el que se muestra en la figura siguiente:
El diagrama de Gantt es un diagrama sencillo que muestra el tiempo
en el eje de abscisas, mientras que en cada línea del eje de ordenadas se
encuentran todas y cada una de las actividades que forman el proyecto.
En la parte izquierda se escribe el nombre de las actividades, mientras
que en la parte derecha se marca una línea desde la fecha inicial hasta
la fecha final de cada actividad.
Podéis ver el proyecto ficticio
propuesto en el subapartado 1.1
estado disponible, pero no porque exista alguna preferencia que se pueda ge-
neralizar a otros usuarios.
Lo que importa de las herramientas informatizadas para la ayuda a la pla-
nificación de proyectos es que todas ofrecen la posibilidad de mostrar el
diagrama PERT (o red de actividades) y marcar, además, el camino crítico
de manera automática. También ofrecen una gestión de recursos completa
y un montón de diagramas y listas (que aumentan día a día) que permiten
incluso realizar una presentación brillante y muy profesional de la planifi-
cación de un proyecto.
1.3. La planificación de un proyecto informático
En la planificación de un proyecto informático, además del diagrama PERT, se
suele utilizar una especie de diagrama temporal llamado diagrama de Gantt.
En el caso del proyecto ficticio que se ha utilizado para exponer el PERT y el
CPM, el diagrama de Gantt sería el que se muestra en la figura siguiente:
El diagrama de Gantt es un diagrama sencillo que muestra el tiempo
en el eje de abscisas, mientras que en cada línea del eje de ordenadas se
encuentran todas y cada una de las actividades que forman el proyecto.
En la parte izquierda se escribe el nombre de las actividades, mientras
que en la parte derecha se marca una línea desde la fecha inicial hasta
la fecha final de cada actividad.
propuesto en el subapartado 1.1

En realidad, la mayoría de herramientas informatizadas de ayuda a la planifi-
cación utilizan el diagrama de Gantt como marco de referencia para introducir
los datos de las diferentes tareas o actividades que forman la WBS del proyecto.
Previamente, sin embargo, debe establecerse el calendario del proyecto para
marcar las fechas que no son laborables o cualquier incidencia laboral. Las he-
rramientas informatizadas ofrecen también diagramas basados en el calenda-
rio para marcar los días de inicio y final de cada tarea, aunque el diagrama de
Gantt es suficientemente completo en este aspecto.
El resumen de lo que se debe llevar a cabo para planificar un proyecto en el
tiempo es el siguiente:
1) Establecer el calendario de días laborables de todo el proyecto y, si es nece-
sario, de cada persona del equipo (recurso).
2) Establecer la descomposición del proyecto en tareas (WBS).
3) Estimar la duración (o esfuerzo) de cada tarea o actividad.
4) Establecer las precedencias entre las tareas.
5) Realizar el diagrama de Gantt o PERT (red de actividades), preferentemente
con una herramienta informatizada para la ayuda a la planificación de proyectos.
Para finalizar, es importante saber que, tal como se ha llevado a cabo con las
actividades Inicio y Final, de duración nula, conviene añadir siempre algunas
actividades ficticias con duración nula como hitos de control para establecer
momentos concretos en los que es necesario recopilar los datos y efectuar un
balance de la gestión del proyecto. Cuando el proyecto dispone de fases y eta-
pas diferentes, añadir un hito de control al final de cada fase sería lo más co-
rrecto, aunque muchas veces se ponen hitos temporales de control: uno cada
dos semanas, uno cada mes, etc., según la duración total del proyecto.
precedencias
Conviene señalar que a la hora de establecer precedencias, las hay que son ló-
gicas y las hay que surgen, en el caso concreto de los proyectos informáticos,
de la gestión de los recursos.
Por ejemplo, en el diagrama de Gantt de la figura anterior hemos imaginado que
es posible efectuar simultáneamente las tareas 2 (establecer los requerimientos) y
3 (seleccionar los drivers). Sin embargo, si las dos las debe realizar la misma perso-
na, este diagrama de Gantt nos dice que esta persona tiene una jornada de dieci-
séis horas y no de ocho como es habitual. No parece, pues, posible.
Podéis ver la WBS en el subapartado
2.2 del módulo “Estimación
de costes de un proyecto informático”
de esta asignatura.
Las ayudas típicas...
... que ofrecen las herramientas
informatizadas de planificación
y seguimiento de proyectos son
los diagramas PERT, los de Gantt
y los de calendario.
Podéis ver el subapartad 1.3.1
Ejemplo de precedencia
lógica
Un caso sencillo de preceden-
cia lógica es que no se puede
codificar un programa si su
cuaderno de cargas no se
ha finalizado.
En realidad, la mayoría de herramientas informatizadas de ayuda a la planifi-
cación utilizan el diagrama de Gantt como marco de referencia para introducir
los datos de las diferentes tareas o actividades que forman la WBS del proyecto.
Previamente, sin embargo, debe establecerse el calendario del proyecto para
marcar las fechas que no son laborables o cualquier incidencia laboral. Las he-
rramientas informatizadas ofrecen también diagramas basados en el calenda-
rio para marcar los días de inicio y final de cada tarea, aunque el diagrama de
Gantt es suficientemente completo en este aspecto.
El resumen de lo que se debe llevar a cabo para planificar un proyecto en el
tiempo es el siguiente:
1) Establecer el calendario de días laborables de todo el proyecto y, si es nece-
sario, de cada persona del equipo (recurso).
2) Establecer la descomposición del proyecto en tareas (WBS).
3) Estimar la duración (o esfuerzo) de cada tarea o actividad.
4) Establecer las precedencias entre las tareas.
5) Realizar el diagrama de Gantt o PERT (red de actividades), preferentemente
con una herramienta informatizada para la ayuda a la planificación de proyectos.
Para finalizar, es importante saber que, tal como se ha llevado a cabo con las
actividades Inicio y Final, de duración nula, conviene añadir siempre algunas
actividades ficticias con duración nula como hitos de control para establecer
momentos concretos en los que es necesario recopilar los datos y efectuar un
balance de la gestión del proyecto. Cuando el proyecto dispone de fases y eta-
pas diferentes, añadir un hito de control al final de cada fase sería lo más co-
rrecto, aunque muchas veces se ponen hitos temporales de control: uno cada
dos semanas, uno cada mes, etc., según la duración total del proyecto.
precedencias
Conviene señalar que a la hora de establecer precedencias, las hay que son ló-
gicas y las hay que surgen, en el caso concreto de los proyectos informáticos,
de la gestión de los recursos.
Por ejemplo, en el diagrama de Gantt de la figura anterior hemos imaginado que
es posible efectuar simultáneamente las tareas 2 (establecer los requerimientos) y
3 (seleccionar los drivers). Sin embargo, si las dos las debe realizar la misma perso-
na, este diagrama de Gantt nos dice que esta persona tiene una jornada de dieci-
séis horas y no de ocho como es habitual. No parece, pues, posible.
Podéis ver la WBS en el subapartado
2.2 del módulo “Estimación
de costes de un proyecto informático”
de esta asignatura.
Las ayudas típicas...
... que ofrecen las herramientas
informatizadas de planificación
y seguimiento de proyectos son
los diagramas PERT, los de Gantt
y los de calendario.
Podéis ver el subapartad 1.3.1
Ejemplo de precedencia
lógica
Un caso sencillo de preceden-
cia lógica es que no se puede
codificar un programa si su
cuaderno de cargas no se
ha finalizado.

En el caso de los proyectos informáticos de construcción de software, los recursos
son las personas, los profesionales informáticos que forman el equipo del proyec-
to. Se ha de procurar que nadie deba trabajar más de una jornada por culpa de una
planificación incompleta que no ha tenido en cuenta los recursos.
De hecho, el diagrama de Gantt de la figura anterior sería realista si imagina-
mos que disponemos de tres personas en el equipo del proyecto:
1) Una primera persona podría llevar a cabo las tareas 2 (establecer los reque-
rimientos), 4 (realizar el diseño), 7 (codificar) y 9 (probar el producto).
2) Un segundo miembro del equipo se podría encargar de las tareas 3 (selec-
cionar los drivers) y 6 (probar los drivers) y, tal vez, participar también en la ac-
tividad 9 (probar el producto).
3) Para no tener problemas de jornada doble, una tercera persona del equipo
debería encargarse de las actividades 5 (recoger datos) y 8 (elaborar la docu-
mentación).
La figura siguiente muestra una modificación sencilla en el caso de que el equi-
po del proyecto estuviera formado por dos miembros. Para evitar jornadas do-
bles de los miembros del equipo, se han tenido que introducir nuevas
precedencias: provocar que la actividad 5 (recoger datos) dependa de la 6 (pro-
bar los drivers) y, también, que la actividad 8 (Elaborar la documentación) de-
penda de la 5 (recoger datos), para conseguir que las realice la misma persona.
Por ello, en la planificación temporal de proyectos informáticos, ade-
más de las precedencias lógicas, es necesario añadir otras nuevas que
provienen de la consideración de los recursos y de su utilización.
Actividades con precedencias adicionales para evitar jornadas dobles
Identificación
numérica
Nombre de la actividad
Duración
estimada
Precedencias
1 Inicio 0 - -
2
Establecer los
requerimientos
3 1 A
3 Seleccionar los drivers 2 1 B
4 Realizar el diseño 4 2 A
5 Recoger datos 2 2, 3 y 6 B
6 Probar los drivers 6 3 B
7 Codificar 4 4 A
8 Elaborar la documentación 2 4 y 5 B
9 Probar el producto 4 5, 6 y 7 A
10 Final 0 - -
En el caso de los proyectos informáticos de construcción de software, los recursos
son las personas, los profesionales informáticos que forman el equipo del proyec-
to. Se ha de procurar que nadie deba trabajar más de una jornada por culpa de una
planificación incompleta que no ha tenido en cuenta los recursos.
De hecho, el diagrama de Gantt de la figura anterior sería realista si imagina-
mos que disponemos de tres personas en el equipo del proyecto:
1) Una primera persona podría llevar a cabo las tareas 2 (establecer los reque-
rimientos), 4 (realizar el diseño), 7 (codificar) y 9 (probar el producto).
2) Un segundo miembro del equipo se podría encargar de las tareas 3 (selec-
cionar los drivers) y 6 (probar los drivers) y, tal vez, participar también en la ac-
tividad 9 (probar el producto).
3) Para no tener problemas de jornada doble, una tercera persona del equipo
debería encargarse de las actividades 5 (recoger datos) y 8 (elaborar la docu-
mentación).
La figura siguiente muestra una modificación sencilla en el caso de que el equi-
po del proyecto estuviera formado por dos miembros. Para evitar jornadas do-
bles de los miembros del equipo, se han tenido que introducir nuevas
precedencias: provocar que la actividad 5 (recoger datos) dependa de la 6 (pro-
bar los drivers) y, también, que la actividad 8 (Elaborar la documentación) de-
penda de la 5 (recoger datos), para conseguir que las realice la misma persona.
Por ello, en la planificación temporal de proyectos informáticos, ade-
más de las precedencias lógicas, es necesario añadir otras nuevas que
provienen de la consideración de los recursos y de su utilización.
Actividades con precedencias adicionales para evitar jornadas dobles
Identificación
numérica
Nombre de la actividad
Duración
estimada
Precedencias
1 Inicio 0 - -
2
Establecer los
requerimientos
3 1 A
3 Seleccionar los drivers 2 1 B
4 Realizar el diseño 4 2 A
5 Recoger datos 2 2, 3 y 6 B
6 Probar los drivers 6 3 B
7 Codificar 4 4 A
8 Elaborar la documentación 2 4 y 5 B
9 Probar el producto 4 5, 6 y 7 A
10 Final 0 - -

La tabla muestra, en negrita, las precedencias adicionales introducidas para
evitar la jornada doble de un miembro del equipo. También indica el recurso
(la persona miembro del equipo) que realizará cada actividad.
Cabe decir que, aunque en este ejemplo no ha ocurrido, estas precedencias
adicionales suelen cambiar a menudo el camino crítico e incluso la duración
global del proyecto. De hecho, a la hora de planificar un proyecto se juega con
los recursos disponibles (teniendo en cuenta el coste) y las precedencias de ac-
tividades hasta que se encuentra un resultado aceptable.
Una vez terminada la planificación, finaliza la calificación y ya se dispone
de los objetivos del proyecto informático: un primer boceto de las funcio-
nalidades, los plazos de todo el proyecto y de cada actividad de la WBS y el
presupuesto, obtenido básicamente del precio por hora de cada uno de los
profesionales que forman parte del equipo del proyecto y del número de
horas de trabajo que les han sido asignadas.
La tabla muestra, en negrita, las precedencias adicionales introducidas para
evitar la jornada doble de un miembro del equipo. También indica el recurso
(la persona miembro del equipo) que realizará cada actividad.
Cabe decir que, aunque en este ejemplo no ha ocurrido, estas precedencias
adicionales suelen cambiar a menudo el camino crítico e incluso la duración
global del proyecto. De hecho, a la hora de planificar un proyecto se juega con
los recursos disponibles (teniendo en cuenta el coste) y las precedencias de ac-
tividades hasta que se encuentra un resultado aceptable.
Una vez terminada la planificación, finaliza la calificación y ya se dispone
de los objetivos del proyecto informático: un primer boceto de las funcio-
nalidades, los plazos de todo el proyecto y de cada actividad de la WBS y el
presupuesto, obtenido básicamente del precio por hora de cada uno de los
profesionales que forman parte del equipo del proyecto y del número de
horas de trabajo que les han sido asignadas.

2. Seguimiento y control de un proyecto informático
Una vez iniciado el proyecto informático, la tarea de gestión consiste en conseguir
que las previsiones se cumplan y, en caso de que no sea así, poder detectar lo an-
tes posible las desviaciones que se deben producir para poder encontrarles una
solución.
Para conseguir todo esto, es imprescindible comparar periódicamente la reali-
dad del desarrollo del proyecto con la previsión disponible, ya sea la inicial o
cualquiera de las nuevas previsiones que se hayan debido realizar al detectar
errores en la estimación o la planificación iniciales.
El objetivo declarado del proyecto es alcanzar unas funcionalidades en unos
plazos determinados y habiéndolas presupuestado. La actividad de seguimien-
to y control del proyecto debe conseguir detectar los problemas con la máxi-
ma antelación posible para poder reajustar la estimación y la planificación y,
en definitiva, cambiar el proyecto modificando los objetivos.
El seguimiento pretende una anticipación, no una constatación
Con el seguimiento de un proyecto informático no se trata de constatar si en un momen-
to determinado del proyecto se llevan dos meses de retraso, porque entonces ya sería de-
masiado tarde. Lo que importa es poder decir, por ejemplo, que “aunque actualmente
vamos suficientemente bien, si continuamos así de aquí a tres meses se podrá constatar
un mes de retraso en el desarrollo del proyecto”. Sólo con una previsión anticipada de
este tipo se pueden tomar las decisiones adecuadas para tratar de salvar las previsiones
del proyecto.
En los hitos de control introducidos en la planificación (bien sea al final de
fases o etapas de proyecto, o bien de manera periódica) es cuando debemos
plantearnos, entre otras cosas, lo siguiente:
• Si conviene rehacer la descomposición del proyecto en tareas (WBS) o no,
posiblemente con la intención de incluir algunas no previstas en el mo-
mento inicial, pero que son totalmente necesarias e imprescindibles a me-
dida que avanza el proyecto.
El objetivo del seguimiento y el control del proyecto informático es
conseguir que no falle y, además, que se desarrolle según la planifica-
ción fijada previamente.
La importancia del seguimiento del proyecto informático radica, pues,
en el hecho de poder anticipar los problemas.
2. Seguimiento y control de un proyecto informático
Una vez iniciado el proyecto informático, la tarea de gestión consiste en conseguir
que las previsiones se cumplan y, en caso de que no sea así, poder detectar lo an-
tes posible las desviaciones que se deben producir para poder encontrarles una
solución.
Para conseguir todo esto, es imprescindible comparar periódicamente la reali-
dad del desarrollo del proyecto con la previsión disponible, ya sea la inicial o
cualquiera de las nuevas previsiones que se hayan debido realizar al detectar
errores en la estimación o la planificación iniciales.
El objetivo declarado del proyecto es alcanzar unas funcionalidades en unos
plazos determinados y habiéndolas presupuestado. La actividad de seguimien-
to y control del proyecto debe conseguir detectar los problemas con la máxi-
ma antelación posible para poder reajustar la estimación y la planificación y,
en definitiva, cambiar el proyecto modificando los objetivos.
El seguimiento pretende una anticipación, no una constatación
Con el seguimiento de un proyecto informático no se trata de constatar si en un momen-
to determinado del proyecto se llevan dos meses de retraso, porque entonces ya sería de-
masiado tarde. Lo que importa es poder decir, por ejemplo, que “aunque actualmente
vamos suficientemente bien, si continuamos así de aquí a tres meses se podrá constatar
un mes de retraso en el desarrollo del proyecto”. Sólo con una previsión anticipada de
este tipo se pueden tomar las decisiones adecuadas para tratar de salvar las previsiones
del proyecto.
En los hitos de control introducidos en la planificación (bien sea al final de
fases o etapas de proyecto, o bien de manera periódica) es cuando debemos
plantearnos, entre otras cosas, lo siguiente:
• Si conviene rehacer la descomposición del proyecto en tareas (WBS) o no,
posiblemente con la intención de incluir algunas no previstas en el mo-
mento inicial, pero que son totalmente necesarias e imprescindibles a me-
dida que avanza el proyecto.
El objetivo del seguimiento y el control del proyecto informático es
conseguir que no falle y, además, que se desarrolle según la planifica-
ción fijada previamente.
La importancia del seguimiento del proyecto informático radica, pues,
en el hecho de poder anticipar los problemas.

• Si conviene volver a efectuar la estimación del esfuerzo o no, en caso de que
se constate que la productividad que se obtiene es diferente de la prevista.
• Si conviene cambiar algunos de los objetivos del proyecto o no, para tratar
de mantener los otros.
• Si conviene llevar a cabo una nueva calificación del proyecto o no, para te-
ner en cuenta los datos de nuevas tareas o de una productividad diferente
de la prevista que la realidad nos aporte.
Como se dice en otro módulo, los problemas de una deficiente calificación ini-
cial se intentan “resolver” demasiadas veces de puertas afuera, haciendo todo
lo posible para cumplir con los plazos y el presupuesto a fuerza de reducir las
funcionalidades del proyecto, sobre todo las funcionalidades de calidad. Ésta
es, evidentemente, una solución totalmente falsa que simplemente aplaza los
problemas hasta la fase de mantenimiento, al mismo tiempo que consigue a
menudo que los problemas se conviertan en mucho más graves y que tengan
una solución mucho más difícil.
2.1. Las hojas de actividad y el informe de situación
Para poder llevar a cabo una comparación correcta entre la realidad y la previ-
sión, es necesario “saber cómo va” el proyecto y, con esta finalidad, se deben
recoger datos de su desarrollo. Con estos datos del seguimiento será posible te-
ner elementos para tomar decisiones de cambio de los objetivos del proyecto
y, en definitiva, controlar el desarrollo. La práctica habitual es recoger estos
datos del seguimiento en unas hojas de actividad.
Conviene recoger de manera individual por cada tarea y cada persona involu-
crada estos datos de seguimiento, a partir de los cuales el jefe de proyecto*
debe elaborar los datos globales que permiten construir un informe de situa-
ción del proyecto. Este informe se suele llevar a cabo para cada uno de los hitos
de control establecidos.
La hoja de actividad es el conjunto de datos individuales de segui-
miento de un proyecto, donde cada miembro del equipo señala las
horas que ha ocupado en cada una de las tareas previstas de la WBS
que se le han asignado.
Un informe de situación es el resumen de la realidad de un proyecto a
partir de los datos obtenidos de las hojas de actividad y de su compara-
ción con la planificación vigente.
Podéis ver los problemas de
una deficiente calificación en el
subapartado 1.1 del módulo “El
proyecto informático de construcción
de software”.
* Si conviene, ayudado de un
sistema informático ad hoc.
• Si conviene volver a efectuar la estimación del esfuerzo o no, en caso de que
se constate que la productividad que se obtiene es diferente de la prevista.
• Si conviene cambiar algunos de los objetivos del proyecto o no, para tratar
de mantener los otros.
• Si conviene llevar a cabo una nueva calificación del proyecto o no, para te-
ner en cuenta los datos de nuevas tareas o de una productividad diferente
de la prevista que la realidad nos aporte.
Como se dice en otro módulo, los problemas de una deficiente calificación ini-
cial se intentan “resolver” demasiadas veces de puertas afuera, haciendo todo
lo posible para cumplir con los plazos y el presupuesto a fuerza de reducir las
funcionalidades del proyecto, sobre todo las funcionalidades de calidad. Ésta
es, evidentemente, una solución totalmente falsa que simplemente aplaza los
problemas hasta la fase de mantenimiento, al mismo tiempo que consigue a
menudo que los problemas se conviertan en mucho más graves y que tengan
una solución mucho más difícil.
2.1. Las hojas de actividad y el informe de situación
Para poder llevar a cabo una comparación correcta entre la realidad y la previ-
sión, es necesario “saber cómo va” el proyecto y, con esta finalidad, se deben
recoger datos de su desarrollo. Con estos datos del seguimiento será posible te-
ner elementos para tomar decisiones de cambio de los objetivos del proyecto
y, en definitiva, controlar el desarrollo. La práctica habitual es recoger estos
datos del seguimiento en unas hojas de actividad.
Conviene recoger de manera individual por cada tarea y cada persona involu-
crada estos datos de seguimiento, a partir de los cuales el jefe de proyecto*
debe elaborar los datos globales que permiten construir un informe de situa-
ción del proyecto. Este informe se suele llevar a cabo para cada uno de los hitos
de control establecidos.
La hoja de actividad es el conjunto de datos individuales de segui-
miento de un proyecto, donde cada miembro del equipo señala las
horas que ha ocupado en cada una de las tareas previstas de la WBS
que se le han asignado.
Un informe de situación es el resumen de la realidad de un proyecto a
partir de los datos obtenidos de las hojas de actividad y de su compara-
ción con la planificación vigente.
Podéis ver los problemas de
una deficiente calificación en el
subapartado 1.1 del módulo “El
proyecto informático de construcción
de software”.
* Si conviene, ayudado de un
sistema informático ad hoc.

Cuando una tarea finaliza, el jefe de proyecto puede saber el esfuerzo real que
ha supuesto realizarla y lo puede comparar con el esfuerzo previsto, para ver
si las estimaciones de productividad eran optimistas, pesimistas o realistas. El
hecho de disponer de esta productividad real es precisamente lo que debe per-
mitir anticipar los problemas.
Con los datos reales obtenidos de la hoja de actividad, el jefe de proyecto rea-
liza el seguimiento, a menudo mediante herramientas informatizadas* que
permiten, para cada actividad del proyecto, introducir las fechas reales del tra-
bajo acabado o el porcentaje del trabajo hecho en cada momento. Estas herra-
mientas ofrecen también una gran cantidad de listas y gráficos que, una vez
escogidos los que son útiles, ayudan a las tareas de seguimiento y control del
proyecto.
2.2. La ley de Brooks
Aunque ya se trata detenidamente en otros módulos, conviene recordar aquí
lo que se ha denominado ley de Brooks, una teoría que proviene de la experien-
cia del autor de la obra The Mythical Man-Month (1975) como director del pro-
ceso de construcción del sistema operativo de IBM 360.
Es necesario entender esta advertencia en el sentido de que no se pueden inter-
cambiar hombres y meses. Y también se debe entender que la ley no es algo
matemático, sino sólo una advertencia para los que todavía no han captado el
mito del hombre-mes.
En cualquier proyecto (pensemos, por ejemplo, en la construcción de una ca-
sa), cuando éste va retrasado, una solución para mantener los plazos, aunque
pueda costar más dinero, es añadir personal (por ejemplo, más albañiles en el
caso de la construcción de una casa).
La ley de Brooks que acabamos de ver nos advierte de que no sucede lo mismo
en los proyectos informáticos y que, como ya hemos dicho en otros módulos
didácticos, en un proyecto informático el reparto de los esfuerzos en el tiempo
no puede ser cualquiera, sino que tiene una forma fijada por la curva de Ra-
yleigh/Norden. Posiblemente, Brooks fue el primero en constatar que en un
proyecto informático que iba retrasado, el hecho de añadir personal creó más
problemas de los que resolvió, aunque, evidentemente, esto no debe ocurrir
siempre.
La ley de Brooks es una advertencia para no caer en el mito del hom-
bre-mes, que a menudo tiene formulaciones tan sorprendentes como
ésta: si un proyecto va retrasado, el hecho de añadir personal es la ma-
nera más segura de retrasarlo todavía más.
* Como MS-PROJECT
o SUPERPROJECT.
Podéis ver los módulos “El proyecto
informático de construcción de
software” y “Estimación de costes
asignatura. En concreto, podéis ver el
mito del hombre-mes en el subapartado
1.3.2 de este último módulo.
Lectura recomendada
La referencia siguiente os
permitirá encontrar la obra
mencionada en el texto sobre
el mito del hombre-mes:
F. Brooks (1975). The
mythical man-month.
Reading: Addison-Wesley.
Podéis ver la curva de Rayleigh/
Norden en el subapartado 2.3.3 del
módulo “Estimación de costes
de un proyecto informático” de
esta asignatura.
Cuando una tarea finaliza, el jefe de proyecto puede saber el esfuerzo real que
ha supuesto realizarla y lo puede comparar con el esfuerzo previsto, para ver
si las estimaciones de productividad eran optimistas, pesimistas o realistas. El
hecho de disponer de esta productividad real es precisamente lo que debe per-
mitir anticipar los problemas.
Con los datos reales obtenidos de la hoja de actividad, el jefe de proyecto rea-
liza el seguimiento, a menudo mediante herramientas informatizadas* que
permiten, para cada actividad del proyecto, introducir las fechas reales del tra-
bajo acabado o el porcentaje del trabajo hecho en cada momento. Estas herra-
mientas ofrecen también una gran cantidad de listas y gráficos que, una vez
escogidos los que son útiles, ayudan a las tareas de seguimiento y control del
proyecto.
2.2. La ley de Brooks
Aunque ya se trata detenidamente en otros módulos, conviene recordar aquí
lo que se ha denominado ley de Brooks, una teoría que proviene de la experien-
cia del autor de la obra The Mythical Man-Month (1975) como director del pro-
ceso de construcción del sistema operativo de IBM 360.
Es necesario entender esta advertencia en el sentido de que no se pueden inter-
cambiar hombres y meses. Y también se debe entender que la ley no es algo
matemático, sino sólo una advertencia para los que todavía no han captado el
mito del hombre-mes.
En cualquier proyecto (pensemos, por ejemplo, en la construcción de una ca-
sa), cuando éste va retrasado, una solución para mantener los plazos, aunque
pueda costar más dinero, es añadir personal (por ejemplo, más albañiles en el
caso de la construcción de una casa).
La ley de Brooks que acabamos de ver nos advierte de que no sucede lo mismo
en los proyectos informáticos y que, como ya hemos dicho en otros módulos
didácticos, en un proyecto informático el reparto de los esfuerzos en el tiempo
no puede ser cualquiera, sino que tiene una forma fijada por la curva de Ra-
yleigh/Norden. Posiblemente, Brooks fue el primero en constatar que en un
proyecto informático que iba retrasado, el hecho de añadir personal creó más
problemas de los que resolvió, aunque, evidentemente, esto no debe ocurrir
siempre.
La ley de Brooks es una advertencia para no caer en el mito del hom-
bre-mes, que a menudo tiene formulaciones tan sorprendentes como
ésta: si un proyecto va retrasado, el hecho de añadir personal es la ma-
nera más segura de retrasarlo todavía más.
* Como MS-PROJECT
o SUPERPROJECT.
Podéis ver los módulos “El proyecto
software” y “Estimación de costes
asignatura. En concreto, podéis ver el
mito del hombre-mes en el subapartado
1.3.2 de este último módulo.
Lectura recomendada
La referencia siguiente os
permitirá encontrar la obra
mencionada en el texto sobre
el mito del hombre-mes:
F. Brooks (1975). The
mythical man-month.
Reading: Addison-Wesley.
Podéis ver la curva de Rayleigh/
Norden en el subapartado 2.3.3 del
módulo “Estimación de costes
de un proyecto informático” de
esta asignatura.

La explicación tradicional del fenómeno es que en un proyecto informático se
crean unos circuitos internos de comunicación para comprender qué se reali-
za. Entre los trabajos que se deben efectuar se encuentra el de comunicar a
otros miembros del equipo aquello que uno ha decidido y que condiciona el
trabajo del resto. El hecho de añadir personal nuevo a mitad de proyecto o
cuando ya se está acabando provoca que haya personas nuevas que no cono-
cen qué se realiza y que, además, crean necesidades adicionales de comunica-
ción que pueden consumir incluso una parte de los recursos que ya existen,
simplemente porque los miembros “viejos” del equipo de proyecto han de ex-
plicar a los “nuevos” qué se lleva a cabo y cómo se realiza. Según Brooks, estas
necesidades adicionales de comunicación pueden provocar incluso que con
más personas se tarde más tiempo.
La explicación tradicional del fenómeno es que en un proyecto informático se
crean unos circuitos internos de comunicación para comprender qué se reali-
za. Entre los trabajos que se deben efectuar se encuentra el de comunicar a
otros miembros del equipo aquello que uno ha decidido y que condiciona el
trabajo del resto. El hecho de añadir personal nuevo a mitad de proyecto o
cuando ya se está acabando provoca que haya personas nuevas que no cono-
cen qué se realiza y que, además, crean necesidades adicionales de comunica-
ción que pueden consumir incluso una parte de los recursos que ya existen,
simplemente porque los miembros “viejos” del equipo de proyecto han de ex-
plicar a los “nuevos” qué se lleva a cabo y cómo se realiza. Según Brooks, estas
necesidades adicionales de comunicación pueden provocar incluso que con
más personas se tarde más tiempo.

informático
Desgraciadamente, tal como comentamos en otro módulo, la calidad del soft-
ware construido no es siempre la deseable. Hemos visto algunas de las razones
que pueden ser la causa, aun así debemos evitar que ello ocurra.
Han transcurrido ya un par de décadas desde que se comenzó a hablar explí-
citamente de aseguramiento de la calidad del software.
Terminología confusa
Con respecto al término aseguramiento de la calidad del software (software quality assuran-
ce), a veces se ha traducido del inglés como garantía de calidad del software, aunque dife-
rentes autores se oponen porque crea confusión con el concepto, mucho más tradicional,
de garantía de los productos (no debemos olvidar que un software es un producto que se
vende y que, como tal, puede tener una garantía).
Ya en 1977, Mc Call estableció algunos factores para analizar la calidad del
software * y, desde entonces, el procedimiento habitual ha sido elaborar listas
de control** complejas y detalladas para revisar todo el proceso de construc-
ción del software.
Actualmente, el aseguramiento de calidad de software consiste en introducir
unos procedimientos y unas metodologías de construcción que tratan de ga-
rantizar, a priori, que el proceso es correcto y seguro, y que el mismo proceso
de construcción pueda garantizar también, en cierta manera, que el producto
que se obtiene es un software de la mejor calidad.
En general, la calidad del software necesita que exista un acuerdo total entre
los requerimientos (tanto funcionales como de rendimiento) y el software fi-
nal. Esto implica la utilización de estándares de desarrollo documentados ex-
plícitamente y de procedimientos concretos de gestión de todo el proceso de
construcción de software.
El aseguramiento de la calidad del software es, según AENOR –la entidad
española de normalización–, el conjunto de actividades planificadas y sis-
temáticas necesarias para aportar la confianza de que el producto (software)
cumplirá los requerimientos de calidad establecidos.
La calidad del software es, según el IIEE (Instituto de Ingenieros Eléc-
tricos y Electrónicos), el grado en el que un sistema, componente o pro-
ceso cumple con los requerimientos especificados y con las necesidades
o expectativas del cliente o usuario.
Podéis ver el módulo “El proyecto
software” de esta asignatura.
* En inglés, software quality factors.
** En inglés, check list.
Tasa cero de errores
En cuanto a la obtención de
software de la mejor calidad, se
ha llegado a hablar, incluso, de
procesos de construcción que
alcanzarían una tasa cero
de errores.
informático
Desgraciadamente, tal como comentamos en otro módulo, la calidad del soft-
ware construido no es siempre la deseable. Hemos visto algunas de las razones
que pueden ser la causa, aun así debemos evitar que ello ocurra.
Han transcurrido ya un par de décadas desde que se comenzó a hablar explí-
citamente de aseguramiento de la calidad del software.
Terminología confusa
Con respecto al término aseguramiento de la calidad del software (software quality assuran-
ce), a veces se ha traducido del inglés como garantía de calidad del software, aunque dife-
rentes autores se oponen porque crea confusión con el concepto, mucho más tradicional,
de garantía de los productos (no debemos olvidar que un software es un producto que se
vende y que, como tal, puede tener una garantía).
Ya en 1977, Mc Call estableció algunos factores para analizar la calidad del
software * y, desde entonces, el procedimiento habitual ha sido elaborar listas
de control** complejas y detalladas para revisar todo el proceso de construc-
ción del software.
Actualmente, el aseguramiento de calidad de software consiste en introducir
unos procedimientos y unas metodologías de construcción que tratan de ga-
rantizar, a priori, que el proceso es correcto y seguro, y que el mismo proceso
de construcción pueda garantizar también, en cierta manera, que el producto
que se obtiene es un software de la mejor calidad.
En general, la calidad del software necesita que exista un acuerdo total entre
los requerimientos (tanto funcionales como de rendimiento) y el software fi-
nal. Esto implica la utilización de estándares de desarrollo documentados ex-
plícitamente y de procedimientos concretos de gestión de todo el proceso de
construcción de software.
El aseguramiento de la calidad del software es, según AENOR –la entidad
española de normalización–, el conjunto de actividades planificadas y sis-
temáticas necesarias para aportar la confianza de que el producto (software)
cumplirá los requerimientos de calidad establecidos.
La calidad del software es, según el IIEE (Instituto de Ingenieros Eléc-
tricos y Electrónicos), el grado en el que un sistema, componente o pro-
ceso cumple con los requerimientos especificados y con las necesidades
o expectativas del cliente o usuario.
Podéis ver el módulo “El proyecto
software” de esta asignatura.
* En inglés, software quality factors.
** En inglés, check list.
Tasa cero de errores
En cuanto a la obtención de
software de la mejor calidad, se
ha llegado a hablar, incluso, de
procesos de construcción que
alcanzarían una tasa cero
de errores.

El tratamiento del aseguramiento de la calidad se centra tradicionalmente en
las inspecciones y revisiones formales, junto con las llamadas reuniones de re-
paso*. Uno de los objetivos fundamentales es, evidentemente, obtener la ca-
racterística implícita de la fiabilidad y, sobre todo, un mantenimiento fácil del
producto obtenido, teniendo en cuenta la larga duración de la etapa de man-
tenimiento en el ciclo de vida del software.
La ISO* es la organización internacional encargada de crear todo tipo de es-
tándares. En concreto, los estándares de calidad forman parte de la norma
ISO 9000, que describe los elementos que debe tener un sistema de asegu-
ramiento de la calidad con el fin de que se puedan aplicar a cualquier ne-
gocio o actividad.
La ISO 9001 es el estándar de aseguramiento de la calidad que se aplica a la
ingeniería del software y expone hasta veinte exigencias que debe cumplir un
buen sistema de calidad. Recientemente, la nueva versión de la norma ISO
9000-3, que data de 1996, quiere proporcionar una guía y una ayuda con vis-
tas a la aplicación de las exigencias de la ISO 9001 en el caso de una industria
de fabricación y/o venta de software.
En general, un sistema de aseguramiento de la calidad del software
incluye una estructura organizativa que implica establecer responsabi-
lidades, procedimientos y procesos de construcción y revisión, y tam-
bién garantizar la disponibilidad de los recursos de todo tipo necesarios
para efectuar una gestión de calidad que ofrezca un software de calidad.
* En inglés, walkthroughs.
* International Organization
for Standarization.
Lectura recomendada
Para más detalles, podéis
consultar la obra siguiente:
R. Kehoe; A. Jarvis (1996).
ISO 9000-3: A Tool for
Software Product and
Process Improvement.
Nueva York: Springer.
El tratamiento del aseguramiento de la calidad se centra tradicionalmente en
las inspecciones y revisiones formales, junto con las llamadas reuniones de re-
paso*. Uno de los objetivos fundamentales es, evidentemente, obtener la ca-
racterística implícita de la fiabilidad y, sobre todo, un mantenimiento fácil del
producto obtenido, teniendo en cuenta la larga duración de la etapa de man-
tenimiento en el ciclo de vida del software.
La ISO* es la organización internacional encargada de crear todo tipo de es-
tándares. En concreto, los estándares de calidad forman parte de la norma
ISO 9000, que describe los elementos que debe tener un sistema de asegu-
ramiento de la calidad con el fin de que se puedan aplicar a cualquier ne-
gocio o actividad.
La ISO 9001 es el estándar de aseguramiento de la calidad que se aplica a la
ingeniería del software y expone hasta veinte exigencias que debe cumplir un
buen sistema de calidad. Recientemente, la nueva versión de la norma ISO
9000-3, que data de 1996, quiere proporcionar una guía y una ayuda con vis-
tas a la aplicación de las exigencias de la ISO 9001 en el caso de una industria
de fabricación y/o venta de software.
En general, un sistema de aseguramiento de la calidad del software
incluye una estructura organizativa que implica establecer responsabi-
lidades, procedimientos y procesos de construcción y revisión, y tam-
bién garantizar la disponibilidad de los recursos de todo tipo necesarios
para efectuar una gestión de calidad que ofrezca un software de calidad.
* En inglés, walkthroughs.
* International Organization
for Standarization.
Lectura recomendada
Para más detalles, podéis
consultar la obra siguiente:
R. Kehoe; A. Jarvis (1996).
ISO 9000-3: A Tool for
Software Product and
Process Improvement.
Nueva York: Springer.

Resumen
La planificación temporal de un proyecto informático arranca de la des-
composición en tareas del proyecto (WBS), la estimación del esfuerzo de cada
una y las precedencias entre las tareas o actividades. Esta información se dis-
pone en un diagrama PERT (o red de actividades) y se obtiene así el camino
crítico formado por la cadena de actividades problemáticas que no tienen mar-
gen de tiempo y que determinan la duración global del proyecto.
En el caso de los proyectos informáticos, además de las precedencias lógicas,
es necesario añadir nuevas precedencias entre actividades para conseguir un
buen uso de los recursos, es decir, de los profesionales que forman el equipo
de proyecto y evitar que se produzcan casos de jornada doble.
A menudo, las herramientas informáticas para planificar y llevar a cabo el se-
guimiento de proyectos ofrecen diferentes diagramas (de Gantt, PERT, de ca-
lendario, etc.) y una variedad amplia de listas.
El seguimiento y el control del proyecto se realizan comparando los datos
reales (obtenidos de las hojas de actividad en las que cada miembro del equipo
del proyecto detalla el tiempo que ha dedicado a cada tarea) con los datos pre-
vistos en la planificación vigente. Si existen nuevos datos sobre productividad
o deben llevarse a cabo tareas no previstas antes, puede ser necesario efectuar
una nueva calificación del proyecto (estimación de costes y planificación) y re-
visar los objetivos: las funcionalidades, los plazos y el presupuesto.
La ley de Brooks intenta evitar la incomprensión sobre el mito del hombre-
mes y afirma que añadir más personal a un proyecto retrasado no siempre
mejora las cosas.
El aseguramiento de la calidad del software es el conjunto de actividades de
gestión y organización que permite garantizar que el proceso de construcción
del software es seguro y fiable y, por lo tanto, que el software obtenido también
será de calidad. Existen estándares internacionales sobre el aseguramiento de
la calidad en el campo de la ingeniería del software, en concreto la ISO 9001 y
la ISO 9000-3.
Resumen
La planificación temporal de un proyecto informático arranca de la des-
composición en tareas del proyecto (WBS), la estimación del esfuerzo de cada
una y las precedencias entre las tareas o actividades. Esta información se dis-
pone en un diagrama PERT (o red de actividades) y se obtiene así el camino
crítico formado por la cadena de actividades problemáticas que no tienen mar-
gen de tiempo y que determinan la duración global del proyecto.
En el caso de los proyectos informáticos, además de las precedencias lógicas,
es necesario añadir nuevas precedencias entre actividades para conseguir un
buen uso de los recursos, es decir, de los profesionales que forman el equipo
de proyecto y evitar que se produzcan casos de jornada doble.
A menudo, las herramientas informáticas para planificar y llevar a cabo el se-
guimiento de proyectos ofrecen diferentes diagramas (de Gantt, PERT, de ca-
lendario, etc.) y una variedad amplia de listas.
El seguimiento y el control del proyecto se realizan comparando los datos
reales (obtenidos de las hojas de actividad en las que cada miembro del equipo
del proyecto detalla el tiempo que ha dedicado a cada tarea) con los datos pre-
vistos en la planificación vigente. Si existen nuevos datos sobre productividad
o deben llevarse a cabo tareas no previstas antes, puede ser necesario efectuar
una nueva calificación del proyecto (estimación de costes y planificación) y re-
visar los objetivos: las funcionalidades, los plazos y el presupuesto.
La ley de Brooks intenta evitar la incomprensión sobre el mito del hombre-
mes y afirma que añadir más personal a un proyecto retrasado no siempre
mejora las cosas.
El aseguramiento de la calidad del software es el conjunto de actividades de
gestión y organización que permite garantizar que el proceso de construcción
del software es seguro y fiable y, por lo tanto, que el software obtenido también
será de calidad. Existen estándares internacionales sobre el aseguramiento de
la calidad en el campo de la ingeniería del software, en concreto la ISO 9001 y
la ISO 9000-3.

Actividades
1. Si podéis disponer de una herramienta de planificación y seguimiento de proyectos como
el MS-PROJECT, el SUPERPROJECT u otros, estudiad sus funcionalidades mediante el sis-
tema de ayuda (help) y comprobad los listados que se encuentran disponibles. Como ejer-
cicio concreto, introducid los datos del proyecto ficticio que hemos tratado en este
módulo y, tomando a dos o tres personas como recurso (miembros del equipo), observad
los diferentes gráficos y listados que os ofrece la herramienta.
2. Añadid las precedencias que os parezcan lógicas a los datos de actividades y el esfuerzo es-
timado del caso de la contabilidad sencilla en un PC que hemos visto en otro módulo.
Imaginad un equipo de un analista (que también trabaja como jefe de proyecto) y un pro-
gramador, para obtener, con una herramienta como el MS-PROJECT o el SUPERPROJECT,
el diagrama de Gantt y la red de actividades (diagrama PERT) del proyecto. Con los precios
por hora de analista y programador que conocéis, obtened el coste global del proyecto.
3. Intentad llevar a cabo una descomposición de tareas (WBS), una estimación de costes pa-
recida a la del ejemplo de la contabilidad sencilla en un PC y una planificación en el tiem-
po contando con un analista y un programador para el caso de la aplicación en un
pequeño hotel.
Datos del hotel
Se quiere implementar una pequeña aplicación (simplificada) de gestión administrativa de
la recepción y facturación de un hotel. La aplicación se debe ejecutar en un conjunto de
ordenadores personales, de tipo PC compatible, conectados en red y que comparten los
datos. El hotel dispone de habitaciones simples y dobles y ofrece también una serie de ser-
vicios (bar, restaurante, tintorería, teléfono, etc.), cuya facturación se ha de incorporar a
la gestión informatizada de la recepción y la facturación. La ocupación de las habitaciones
puede ser posterior a una reserva previa, realizada directamente por el cliente o mediante
una agencia de viajes.
Las funciones que se deben implementar son, al menos, las siguientes:
1)Tratamientos interactivos
a)Mantenimiento del fichero de habitaciones
Se debe tener en cuenta que cada habitación tiene un precio normal, un precio de tempo-
rada alta y otro de temporada baja.
b)Gestión de reservas
Para dar de alta una reserva, hemos de introducir las fechas de la entrada y la salida y el
número de personas. El sistema debe ofrecer las habitaciones disponibles y aceptar y regis-
trar la elección que realice el operador a partir de esta información. Los datos complemen-
tarios de la reserva serán, al menos, el nombre y el DNI del titular de la reserva, el tipo de
reserva (directo o por agencia), el identificador de la agencia (si procede) y el teléfono de
la persona que efectúa la reserva (cliente o agencia).
Para modificar o anular una reserva debemos partir del nombre o del DNI del titular de la
reserva y de la fecha de reserva. Es evidente que en una reserva puede incluirse más de una
habitación.
c) Entrada de clientes
Los clientes pueden ocupar habitaciones ya reservadas o las que puedan encontrarse dis-
ponibles si no se ha realizado ninguna reserva previa. Si existe reserva previa, se asigna au-
tomáticamente la habitación reservada y, en caso de que se trate de un cliente nuevo sin
reserva, se consulta el estado de las habitaciones disponibles. Si es posible, se le admite la
entrada considerándolo un cliente directo y por el número de días que solicite.
Los datos necesarios para registrar la entrada de los clientes son, al menos, el nombre, el
DNI (o pasaporte), el domicilio y la nacionalidad, y la habitación que ocuparán. Cuando
la reserva sea para más de una persona, es opcional registrar el nombre, el DNI y el domi-
cilio de todos los clientes, pero siempre se registrarán estos datos con respecto al titular de
la reserva.
expuesto en el subapartado 1.1 de
este módulo didáctico.
Podéis ver el ejemplo del PC en el
subapartado 2.4.1 y los precios por
hora de analista y programador en la
actividad 3 del módulo “Estimación de
costes de un proyecto informático” de
esta asignatura.
subapartado 2.4.1 del módulo
Actividades
1. Si podéis disponer de una herramienta de planificación y seguimiento de proyectos como
el MS-PROJECT, el SUPERPROJECT u otros, estudiad sus funcionalidades mediante el sis-
tema de ayuda (help) y comprobad los listados que se encuentran disponibles. Como ejer-
cicio concreto, introducid los datos del proyecto ficticio que hemos tratado en este
módulo y, tomando a dos o tres personas como recurso (miembros del equipo), observad
los diferentes gráficos y listados que os ofrece la herramienta.
2. Añadid las precedencias que os parezcan lógicas a los datos de actividades y el esfuerzo es-
timado del caso de la contabilidad sencilla en un PC que hemos visto en otro módulo.
Imaginad un equipo de un analista (que también trabaja como jefe de proyecto) y un pro-
gramador, para obtener, con una herramienta como el MS-PROJECT o el SUPERPROJECT,
el diagrama de Gantt y la red de actividades (diagrama PERT) del proyecto. Con los precios
por hora de analista y programador que conocéis, obtened el coste global del proyecto.
3. Intentad llevar a cabo una descomposición de tareas (WBS), una estimación de costes pa-
recida a la del ejemplo de la contabilidad sencilla en un PC y una planificación en el tiem-
po contando con un analista y un programador para el caso de la aplicación en un
pequeño hotel.
Datos del hotel
Se quiere implementar una pequeña aplicación (simplificada) de gestión administrativa de
la recepción y facturación de un hotel. La aplicación se debe ejecutar en un conjunto de
ordenadores personales, de tipo PC compatible, conectados en red y que comparten los
datos. El hotel dispone de habitaciones simples y dobles y ofrece también una serie de ser-
vicios (bar, restaurante, tintorería, teléfono, etc.), cuya facturación se ha de incorporar a
la gestión informatizada de la recepción y la facturación. La ocupación de las habitaciones
puede ser posterior a una reserva previa, realizada directamente por el cliente o mediante
una agencia de viajes.
Las funciones que se deben implementar son, al menos, las siguientes:
1)Tratamientos interactivos
a)Mantenimiento del fichero de habitaciones
Se debe tener en cuenta que cada habitación tiene un precio normal, un precio de tempo-
rada alta y otro de temporada baja.
b)Gestión de reservas
Para dar de alta una reserva, hemos de introducir las fechas de la entrada y la salida y el
número de personas. El sistema debe ofrecer las habitaciones disponibles y aceptar y regis-
trar la elección que realice el operador a partir de esta información. Los datos complemen-
tarios de la reserva serán, al menos, el nombre y el DNI del titular de la reserva, el tipo de
reserva (directo o por agencia), el identificador de la agencia (si procede) y el teléfono de
la persona que efectúa la reserva (cliente o agencia).
Para modificar o anular una reserva debemos partir del nombre o del DNI del titular de la
reserva y de la fecha de reserva. Es evidente que en una reserva puede incluirse más de una
habitación.
c) Entrada de clientes
Los clientes pueden ocupar habitaciones ya reservadas o las que puedan encontrarse dis-
ponibles si no se ha realizado ninguna reserva previa. Si existe reserva previa, se asigna au-
tomáticamente la habitación reservada y, en caso de que se trate de un cliente nuevo sin
reserva, se consulta el estado de las habitaciones disponibles. Si es posible, se le admite la
entrada considerándolo un cliente directo y por el número de días que solicite.
Los datos necesarios para registrar la entrada de los clientes son, al menos, el nombre, el
DNI (o pasaporte), el domicilio y la nacionalidad, y la habitación que ocuparán. Cuando
la reserva sea para más de una persona, es opcional registrar el nombre, el DNI y el domi-
cilio de todos los clientes, pero siempre se registrarán estos datos con respecto al titular de
la reserva.
expuesto en el subapartado 1.1 de
este módulo didáctico.
subapartado 2.4.1 y los precios por
hora de analista y programador en la
actividad 3 del módulo “Estimación de
costes de un proyecto informático” de
esta asignatura.
subapartado 2.4.1 del módulo

Gestión Proyectos Computacionales

Gestión Proyectos Computacionales

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Destaque

Destaque (20)

Semelhante a Gestión Proyectos Computacionales

Semelhante a Gestión Proyectos Computacionales (20)

Gestión Proyectos Computacionales