7. Programación temporal de proyectos (Texto).

7. PROGRAMACIÓN TEMPORAL
DE PROYECTOS
1. INTRODUCCIÓN. ................................................................................................... 89
2. HERRAMIENTAS BÁSICAS USADAS EN LA PLANIFICACIÓN Y
SEGUIMIENTO. ................................................................................................................ 90
3. APLICACIÓN DE LA TÉCNICA CPM. ............................................................... 91
3.1. ETAPA 1. ............................................................................................................ 91
3.2. ETAPA 2. ............................................................................................................ 91
3.3. ETAPA 3. ............................................................................................................ 92
3.4. ETAPA 4. CÁLCULO DEL CAMINO CRÍTICO .......................................................... 94
3.4.1. CALCULAREMOS LAS FECHAS. .............................................................. 94
2.4.1. OBTENCIÓN DEL CAMINO CRÍTICO. .................................................... 96
4. EJEMPLO DE PROGRAMACIÓN DE PROYECTOS Y OBTENCIÓN DE
CALENDARIOS. ............................................................................................................... 96
5. DIFERENCIA FUNDAMENTAL ENTRE EL CPM Y EL PERT. ..................... 98
6. USO DE APLICACIONES PARA LA PLANIFICACIÓN Y CONTROL DE
PROYECTOS. .................................................................................................................... 99
7. MODIFICACIÓN DE LA DURACIÓN DEL PROYECTO. ............................... 99
8. BIBLIOGRAFÍA. ................................................................................................... 102
1. INTRODUCCIÓN.
En este tema vamos a tratar el tema de la creación de calendarios para los
proyectos. Partiendo de las tareas, recursos asignados a cada una y las
precedencias entre las tareas, obtendremos una programación temporal.
Dado que ya sabemos modificar la duración de las tareas, asignando más
recursos (capítulo 4), veremos cómo modificar la duración global del
proyecto e incluso cambiar el camino crítico, pudiendo ofrecer, de este
modo, diferentes programaciones alternativas.
89
PLANIFICACIÓN DE PROYECTOS INFORMATICOS
2. HERRAMIENTAS BÁSICAS USADAS EN LA
PLANIFICACIÓN Y SEGUIMIENTO.
Aunque desde la antigüedad se han realizado proyectos de gran
envergadura como por ejemplo la construcción de edificios públicos,
guerras, viajes, etc., no es hasta principios de este siglo cuando aparece el
conocido diagrama de Gantt en el que se refleja de forma esquemática las
tareas, su duración y las fechas en que se deberán realizar. Trabajando sobre
este diagrama el director de proyecto realizaba planificaciones y seguimiento
de un proyecto. Ver la figura 1.
TAREAS
Especificar Necesidades
Diseño Programas
Diseño Base de Datos
Realización Esquema
Codificación Programas
Pruebas
0
2
4
6
8
10
SEMANAS
12
14
16
figura 1
Dada la evolución tecnológica los seres humanos cada vez abordamos
proyectos más complejos, pero por otra parte creamos técnicas más
evolucionadas, completas y automáticas para gestionar estos proyectos. La
construcción del misil Polaris, así como la solución de los problemas en la
gestión de la producción de Dunlop llevaron al desarrollo de las técnicas
conocidas como PERT (Técnica para la Evaluación y Revisión de
Programas) y CPM (Método del Camino Crítico) que aportan a la
programación de proyectos técnicas matemáticas.
Estas técnicas surgieron de la necesidad de obtener algoritmos
automatizables que ayudasen a los gestores de proyectos complejos en la
90
PROGRAMACIÓN TEMPORAL DE PROYECTOS
construcción de calendarios (programas). En el siguiente punto veremos
mediante un ejemplo como se aplica en el CPM.
3. APLICACIÓN DE LA TÉCNICA CPM.
El CPM se realiza sobre un proyecto en cuatro etapas, a continuación se
describe cada una de ellas.
3.1. ETAPA 1.
Especificar
Necesidades
Diseño
Aplicación
Diseño Base
de Datos
Diseño
Programas
Desarrollo
Contabilidad
Realización
esquemas
Codificación
Identificar tareas. Se utilizará
las técnicas vistas en el capítulo
3 para la identificación de tareas.
Como ejemplo podemos usar el
mostrado en la figura 2.
Si queremos realizar el
proceso de forma manual,
rellenaremos una ficha por cada
Codificación
Programas
Actividad:
Diseño Programas
Pruebas
Recursos: 1 Programador
figura 2
Duración:
3 semanas
actividad identificada. El formato de la
ficha será el que se muestra en la figura 3.
figura 3
3.2. ETAPA 2.
Añadir recursos y tiempos. A cada actividad se le asignarán recursos
como se vio en el tema 4 (personas, material, equipos, etc.) y tiempo
estimado para su realización, completando la ficha.
91
PLANIFICACIÓN DE PROYECTOS INFORMATICOS
3.3. ETAPA 3.
Ordenar las tareas. En esta etapa se tienen que organizar las tareas en
base al orden técnico de ejecución. Así sabemos que hay que hacer las
especificaciones antes de diseñar el programa. Nos podemos plantear las
siguientes preguntas para ordenar las tareas:




¿Qué se puede hacer ahora?
¿Qué debe haberse hecho antes de esto?
¿Qué podría hacerse a la vez?
¿Qué debe seguir a lo que hacemos ahora?
Si se trata de calcular el Camino Crítico de forma manual será interesante
el pinchar todas las tareas en un tablero de corcho, señalando mediante
cuerdas la ordenación de las tareas, ver figura 4. Esta representación es
conocida como red de precedencia, aunque su apariencia es diferente al
gráfico PERT en algunos programas informáticos se describe erróneamente
con este nombre.
figura 4
92
PROGRAMACIÓN TEMPORAL DE PROYECTOS
Si tenemos un diagrama complejo, y queremos realizar los cálculos de
forma manual se puede utilizar el método que se describe a continuación.
Este diagrama se compone de nodos y arcos, similares a las pegatinas
comentadas anteriormente. Los nodos representan a las tareas y la
información necesaria para calcular sus fechas de realización. Los arcos
indican las precedencias entre tareas.
Vamos a representar cada nodo (tarea) como se ve en la figura 5.
Etiqueta actividad
Duración
Inicio temprano
DESCRIPCIÓN DE LA ACTIVIDAD
Inicio tardío
Máximo tiempo disponible
Holgura
Final temprano
Final tardío
figura 5
Donde:

DESCRIPCIÓN DE LA ACTIVIDAD es el nombre que le hemos dado
a la actividad. Por ejemplo: Codificación Programa A

Etiqueta actividad es un número arbitrario y que identifica
unívocamente a cada actividad.

Duración es el tiempo que calculamos que se tardará en completar la
tarea, teniendo en cuenta el esfuerzo y los recursos asignados a la
tarea. Por ejemplo una tarea que estimamos requerirá seis díashombre de esfuerzo, si se realiza entre tres personas podría tener una
duración de dos días (ver capítulo 4 punto 4.3).

Inicio temprano es la fecha en que se podrá comenzar la tarea si no se
retrasa ninguna otra. Más adelante veremos como calcularla.

Final temprano es, en el caso de iniciarse la tarea en el inicio
temprano, lo antes que puede finalizar, respetando su duración.

Inicio tardío es la fecha más retrasada en la que puede comenzar la
93
PLANIFICACIÓN DE PROYECTOS INFORMATICOS
tarea para que se pueda completar el proyecto en la fecha marcada
como final del proyecto.

Final tardío es la fecha más retrasada en la que puede terminar la
tarea para que se pueda completar el proyecto en la fecha marcada
como final del proyecto.

Máximo tiempo disponible el tiempo máximo que puede durar una
tarea en caso de comenzar en su Inicio temprano y concluir en su
Final tardío.

Holgura es la diferencia entre el Máximo tiempo disponible y su
Duración
3.4. ETAPA 4. Cálculo del camino crítico
3.4.1. CALCULAREMOS LAS FECHAS.
Una vez tenemos todas las tareas con sus respectivas duraciones y las
precedencias pasamos a dibujar una red en la que aparezca para cada tarea
una caja similar a la vista en el punto anterior con casi todos los campos
vacíos. Entre ellas aparecerán los arcos indicando precedencias. tendremos
algo similar a la figura 6.
Ahora calculamos las fechas tempranas. Para esto seguimos los
siguientes pasos:
1) En aquellas tareas que no tienen ningún predecesor se le asigna a
Inicio temprano el valor cero.
2) Si la tarea tiene predecesoras y todas estas tienen calculado su Final
temprano se toma como Inicio temprano el máximo de todos ellos.
3) El Final temprano de cada tarea se calcula como el Inicio temprano
más la Duración.
Repetiremos estos pasos hasta que todas las tareas tengan sus
94
PROGRAMACIÓN TEMPORAL DE PROYECTOS
fechas tempranas.
Para calcular las fechas tardías procederemos con los pasos que se
describen a continuación.
figura 6
4) Se obtiene la fecha de finalización de proyecto más tardía. Esta puede
venir dada por algún tipo de razones externas o puede que se nos pida
que el proyecto termine lo antes posible, en este caso la fecha de
finalización más tardía será el máximo de los "Final temprano" de
todas las tareas.
5) A aquellas tareas que no sean predecesoras de ninguna otra se les
asigna como Final tardío la fecha de finalización mas tardía del
punto 4.
6) El Inicio tardío se calcula restando al Final tardío la Duración.
7) En aquellas tareas que son predecesoras de otras se calcula el Final
tardío como el mínimo de los Inicio tardío de las tareas de que es
predecesora.
95
PLANIFICACIÓN DE PROYECTOS INFORMATICOS
Los otros dos campos de cada tarea: Máximo tiempo disponible y
Holgura se calculan mediante las siguientes fórmulas:
Máximo tiempo disponible = Final tardío - Inicio temprano
Holgura = Máximo tiempo disponible - Duración
2.4.1. OBTENCIÓN DEL CAMINO CRÍTICO.
Llamamos camino crítico de una planificación al conjunto de tareas que
tienen Holgura cero. Siempre que se solicita que el proyecto tenga la
duración mínima tendremos un camino crítico.
Se le llama camino crítico porque suele ser un camino que parte de una
tarea que no tiene predecesoras y atraviesa el grafo por tareas con holgura
cero hasta terminar en una tarea que no es predecesora de ninguna otra.
Puede darse el caso de que con el "camino crítico" se puedan construir
varias secuencias, partiendo de tareas sin predecesoras y se alcancen tareas
sin sucesoras.
A las tareas del camino crítico se les llama tareas criticas y esto se debe a
que un retraso en cualquiera de ellas lleva a un retraso del final del proyecto.
4. Ejemplo de programación de proyectos y obtención
de calendarios.
Comenzaremos por crear un calendario, que ilustraremos con el siguiente
problema:
Se ha evaluado el desarrollo de una aplicación, obteniéndose que el
esfuerzo necesario para realizarla es de 25 meses/hombre. Tras el estudio de
las tareas a realizar y los recursos disponibles se han determinado las tareas,
recursos y precedencias, que se muestran en la tabla siguiente.
96
PROGRAMACIÓN TEMPORAL DE PROYECTOS
Se ha de tener en cuenta que la empresa puede asignar tantos Analistas y
Programadores al proyecto, como sea necesario, respetando los datos de la
tabla.
Se desea conocer el tiempo mínimo, necesario, para el desarrollo del
proyecto así como el Camino Crítico.
También se desea disponer de los diagramas de precedencia y Gantt.
Tarea
Descripción
Esfuerzo
A
B
C
D
E
F
Análisis de Requerimientos
Diseño de la Base de Datos
Diseño de los Procesos
Construcción del Prototipo
Desarrollo del Esquema
Codificación
3 meses
1 mes
4 meses
1 mes
0,5 meses
8 meses
Tipo
Brooks
1
2
1
2
1
1
G
0,5 meses
2
2 meses
1
I
Revisión
Usuario
del
Prototipo
Revisión del Código con
Mejoras Solicitadas
Pruebas
2 meses
1
J
Instalación Sistema
1 mes
1
K
Mantenimiento Inicial
2 meses
2
H
Recursos
2 Analistas
1 Analista
2 Analistas
1 Programador
1 Analista
4
Programadores
1 Analista
2
Programadores
2
Programadores
2
Programadores
1 Programador
Sigu
e a:
A
A
C, E
B
C, E
D
F, G
H
I
J
SOLUCIÓN:
Diagrama de precedencias:
B
1,5
A
0
0
1,5
Análisis
1,5
1,5
1,5
0
2
1,5
C
1,5
1,5
2
Diseño
B.D
Diseño
Progrm.
1
2,5
E
2,5
3
0,5
3
1
2
3,5
3,5
0
Desarroll
o
Esquema
0,5
3
D
3,5
3,5
0,5
4 Prototipo 5
1,5
0,5
F
3,5
3,5
2
Codifica.
Construc
1
4,5
G
4,5
5
1
Revisión
Prototipo
0,5
5
5,5
0,5
2
5,5
5,5
0
97
PLANIFICACIÓN DE PROYECTOS INFORMATICOS
H
5,5
5,5
1
Revisión
Código
1
6,5
6,5
0
I
6,5
6,5
1
Pruebas
1
7,5
7,5
0
J
7,5
7,5
0,5
Instalaci.
0,5
8
8
0
K
8
8
2
Manten.
Inicial
2
10
10
0
Diagrama de Gantt:
A
2ª
B
1A
C
2A
D
1P
E
1A
F
4P
G
1A
H
2P
I
2P
J
2P
K
1P
1
2
3
4
5
6
7
8
9
10
La duración mínima es de 10 meses, siendo el camino crítico A-C-F-H-IJ-K
5. DIFERENCIA FUNDAMENTAL ENTRE EL CPM
Y EL PERT.
Aunque en principio son similares los algoritmos de ambos métodos, la
asignación de duraciones de las tareas en el PERT es algo mas elaborada. En
lugar de realizarse una sola estimación se realizan tres estimaciones:
"tm" tiempo medio que se estima para la actividad,
"to" tiempo optimista, el que resultaría de ir todo muy bien, y el
"tp" el tiempo pesimista, el que resultaría si todo fuese mal en esta tarea.
A la tarea se le asigna como duración el resultado de:
98
PROGRAMACIÓN TEMPORAL DE PROYECTOS
duración = ( to + 4 tm + tp) / 6
Por otra parte el grafo se construye de forma dual a la vista. Los arcos
modelan las actividades o tareas, mientras que los nodos modelan la relación
de precedencia de las tareas. Así un nodo indica que los arcos que llegan a él
anteceden a los que salen de él.
6. USO DE APLICACIONES PARA LA
PLANIFICACIÓN Y CONTROL DE PROYECTOS.
Como hemos indicado estos algoritmos se hicieron pensando en el uso de
sistemas de cómputo automático, así que no es de extrañar que existan
muchas aplicaciones que den soporte a éstos. Entre las más conocidas que
funcionan sobre PC están el CA-SuperProject y el MICROSOFT Project.
7. MODIFICACIÓN DE LA DURACIÓN DEL
PROYECTO.
Al realizar la primera planificación del desarrollo de una aplicación
informática nos solemos concentrar en los aspectos más técnicos del
desarrollo. Como es normal, la planificación tendría un calendario diferente
de haber sido otras las personas implicadas. Esto se debe a varios factores
como la experiencia por ejemplo, que llevan a realizar ciertas suposiciones
implícitas o explícitas sobre las necesidades de los usuarios, la
productividad que se obtiene con ciertas herramientas, la cantidad de
personas que se implicarán en el proyecto y los niveles de destreza que estos
dispongan sobre las herramientas, así como su experiencia y conocimientos
sobre el tema de la aplicación a desarrollar.
Por otra parte, los clientes tienen una visión diferente de sus necesidades,
de modo que les resultará más atractivo el pagar más a cambio de disponer
antes de la aplicación. En otros casos puede ocurrir lo contrario, que
hayamos planificado el proyecto con fuertes restricciones en cuanto al
99
PLANIFICACIÓN DE PROYECTOS INFORMATICOS
tiempo de entrega, pero que el cliente realmente desearía pagar menos
aunque se prolongara el plazo de entrega.
Un ejemplo que puede ilustrar lo anterior es el desarrollo de una
aplicación que de soporte al alquiler de esquís para una estación de los
Pirineos. Si planificamos su finalización para el mes de Enero, es normal
que el cliente esté dispuesto a pagar más si puede disponer de esta
aplicación en el mes de Noviembre. Por otra parte si nuestra planificación
resulta que termina en el mes de Julio, seguro que al cliente le dará igual
disponer de ella dos o tres meses más tarde, si con ello puede ahorrarse algo
de dinero.
Esto se debe a que hay un coste de oportunidad asociado a la disposición
o no del subsistema informático. Así en la temporada de invierno el cliente
puede estar dispuesto a pagar 100.000 ptas. Por cada mes que se anticipe la
entrega de la aplicación, mientras que en la temporada de verano le será
prácticamente indiferente el disponer de esta aplicación un mes antes o
después.
Si queremos actuar sobre la duración del proyecto deberemos
concentrarnos en las tareas del camino crítico tratando de aumentar la
concurrencia entre algunas de ellas o reducir la duración de éstas.
Con el objetivo de reducir la duración del camino crítico podremos
aumentar el paralelismo entre las tareas de éste. Para ello haremos que
algunas tareas que se relacionan mediante una secuencia de fin-inicio pasen
a una secuencia inicio-inicio, aunque sea con cierta demora. Así las tareas C
y F las podríamos relacionar de modo que transcurrido un mes del comienzo
del “Diseño de los Procesos” se comenzasen a codificar aquellos procesos
que se puedan dar por buenos, aunque esto pueda suponer un mayor
esfuerzo como consecuencia de posibles modificaciones a realizar por no
habernos esperado a que estuviera diseñado todo el sistema.
Por otra parte también podemos reducir la duración del camino crítico,
actuando exclusivamente sobre una de sus tareas. A modo de ejemplo
estudiar lo que ocurriría si redujéramos la duración de la tarea A, del
100
PROGRAMACIÓN TEMPORAL DE PROYECTOS
ejemplo anterior, a un mes. Como se ve en este caso cualquier reducción de
la tarea se propaga a todo el proyecto. Por otra parte si redujéramos la
duración de la tarea F, “Codificación”, de dos meses a uno, sólo
obtendríamos una reducción de la duración del proyecto de medio mes,
haciendo que además cambiase el camino crítico.
Los factores que más pueden influir en la duración de una tarea y por
tanto del proyecto, si se trata de una tarea del camino crítico, los podemos
clasificar en tres grandes grupos:

Modificar las técnicas y herramientas en las que se basa la duración
de la tarea o su propia existencia.

Si existe un software que puede dar soporte a una tarea o
conjunto de tareas que por su precio no ha parecido oportuno
considerarlo, a la vista de los costes de oportunidad del cliente
puede resultar atractivo el utilizarlo, reduciendo así los plazos
del proyecto (tener en cuenta la curva de aprendizaje).

Otra situación sería la existencia de tareas de formación sobre
un nuevo sistema de gestión de Bases de Datos, del que
realmente no era obligatoria su utilización. Así que podríamos
optar por otro conocido, si el cliente no tiene preferencias,
eliminando las tareas de formación.

Modificar la productividad y calidad del recurso trabajo asociado a
una tarea. Aunque sea parcial, Sackman en un estudio sobre, la
diferencia de productividad entre los programadores detecta una
oscilación de 1 a 25. Tanto Tom DeMarco, como M. Page-Jones
comentan el artículo y dan su punto de vista, dejando claro que
relaciones de uno a tres son muy usuales dentro de una misma
organización.

Modificar la cantidad del recurso trabajo asociado a una tarea.
 Podemos planificar el desarrollo suponiendo que los
desarrolladores realizarán horas extra. Esto en principio puede
101
PLANIFICACIÓN DE PROYECTOS INFORMATICOS
suponer un coste adicional o no. Page-Jones recomienda hacer
uso de las horas extra sólo en casos muy puntuales y como
consecuencia de una desviación en la programación, durante
el desarrollo. Parece poco razonable pensar en este recurso en
la fase de planificación.

Podemos asignar más personas al proyecto, de modo que en
las tareas críticas se puedan incluir más personas. Hay que
tener en cuenta dos cosas que remarca Brooks en su libro “el
mítico hombre-mes”:

Los diferentes tipos de tareas que hay, en función de la
cantidad de personas que asignemos (capítulo 4).

El añadir más personal a un proyecto en marcha puede
retrasar la finalización del proyecto. Esto en principio
se debe a que el personal que no se ha involucrado
desde el principio debe ser formado, lo que puede
suponer un coste en tiempo considerable para las
personas más productivas, porque ya saben de que va
el proyecto, teniendo que dejar sus tareas para aclarar
las dudas de los nuevos.
Como ejemplo de lo anterior reducir la duración del proyecto que hemos
visto al comienzo del tema. Se ha de tener en cuenta que podremos disponer
de un Analista y dos programadores más durante la duración del proyecto.
Dado que estos profesionales son contratados externos y con un coste
superior a los ya asignados, sólo se deberán asignar en aquellas situaciones
en las que realmente aporten un beneficio al proyecto.
8. Bibliografía.
1. de Cos Castillo, M. Teoría general del proyecto. Editorial Sintesis.1995.
2. Cotterell, M, Hughes,B. Software project management. ITP (Thomson
Publishing Inc.) 1995.
102
PROGRAMACIÓN TEMPORAL DE PROYECTOS
3. Lock, D. Gestión de proyectos. Paraninfo, 1990.
4. Microsoft Press. Microsoft Project para windows 95 paso a paso.
McGraw-Hill 1995.
5. Page-Jones, M. Practical Projec Management. Dorset House, 1985.
6. DeMarco, Tom, Lister, Peopleware. Dorset House, 1987.
103