CAPÍTULO 27 CALENDARIZACIÓN DEL PROYECTO 620

- 27.1 Conceptos básicos 621

- 27.2 Calendarización del proyecto 622
o 27.2.1 Principios básicos 623
o 27.2.2 Relación entre personal y esfuerzo 624
o 27.2.3 Distribución de esfuerzo 625
- 27.3 Definición de un conjunto de tareas para el proyecto de software 626
o 27.3.1 Un ejemplo de conjunto de tareas 627
o 27.3.2 Refinamiento de acciones de ingeniería del software 627
- 27.4 Definición de una red de tareas 628
- 27.5 Calendarización 629
o 27.5.1 Cronogramas 629
o 27.5.2 Seguimiento del calendario 631
o 27.5.3 Seguimiento del progreso para un proyecto OO 632
o 27.5.4 Calendarización para proyectos webapp 633
- 27.6 Análisis de valor ganado 635
- 27.7 Resumen 637

Afínales de los años sesenta del siglo pasado, se eligió a un entusiasta joven ingeniero
para que “escribiera” un programa de computadora para una aplicación de fabricación
automatizada. La razón para su selección fue simple. Él era la única persona en su grupo
técnico que asistió a un seminario de programación de computadoras. Sabía los pros y los
contras del lenguaje ensamblador y de FORTRAN, pero nada conocía acerca de ingeniería
de software incluso menos acerca de la calendarización y el seguimiento de proyectos.
Su jefe le dio los manuales apropiados y una descripción verbal de lo que tenía que hacer.
Se le informó que el proyecto debía estar terminado en dos meses.

Leyó los manuales, consideró su enfoque y comenzó a escribir el código. Después de dos
semanas, el jefe lo llamó a su oficina y le preguntó sobre cómo iban las cosas. “Realmente
grandiosas”, dijo el ingeniero con entusiasmo juvenil. “Esto fue mucho más simple de lo
que pensé. Probablemente tenga ya un avance de 75 por ciento”.
El jefe sonrió y alentó al joven ingeniero a seguir con el buen trabajo. Planearon reunirse
de nuevo en una semana.
Una semana después, el jefe llamó al ingeniero a su oficina y le preguntó: “¿Dónde
estamos?”
“Todo está bien”, dijo el joven, “pero encontré algunos tropiezos. Los allanaré y pronto
estaré de vuelta en el camino”. “¿Qué te parece la fecha límite?”, preguntó el jefe. “No
hay problema”, dijo el ingeniero. “tengo un avance de cerca de 90 por ciento”.
Si el lector ha trabajado en el mundo del software durante algunos años, puede terminar
la historia. No es de sorprender que el joven ingeniero1 se quedara en 90 por ciento de
avance durante todo el proyecto y terminara (con la ayuda de otros) sólo un mes más
tarde.
Esta historia se ha repetido decenas de miles de veces entre los desarrolladores de
software durante las pasadas cinco décadas. La gran pregunta es por qué.

27.1 CONCEPTOS BÁSICOS

Aunque existen muchas razones por las que el software se entrega tardíamente, la
mayoría pueden rastrearse en una o más de las siguientes causas fundamentales:
• Una fecha límite irreal establecida por alguien externo al equipo de software y que
fuerza a los gerentes y profesionales.
• Requerimientos del cliente variables que no se reflejan en cambios del calendario.
• Una honesta subestimación de la cantidad de esfuerzo y/o número de recursos
que se requerirán para hacer el trabajo.
• Riesgos predecibles y/o impredecibles que no se consideraron cuando comenzó el
proyecto.
• Dificultades humanas que no podían preverse por anticipado.
• Falta de comunicación entre el personal del proyecto que da como resultado
demoras.
• Falta de comunicación entre el equipo de trabajo que se traduce en retrasos.
• Una falla por parte de la administración del proyecto para reconocer que el
proyecto tiene retrasos en el calendario y una falta de acción para corregir el
problema.

Las fechas límite agresivas (léase “irreales”) son un hecho de la vida en el negocio del
software.
En ocasiones, tales fechas límite se demandan por razones legítimas, desde el punto de
vista de la persona que las establece. Pero el sentido común dice que la legitimidad
también debe percibirla el personal que hace el trabajo.
Napoleón dijo una vez: “Cualquier comandante que se comprometa a llevar a cabo un
plan que considere defectuoso está equivocado; debe plantear sus razones, insistir en que
se cambie el plan y finalmente ofrecer formalmente su renuncia en lugar de ser el
instrumento de la derrota
de su ejército”. Éstas son duras palabras que muchos gerentes de proyecto de software
deberían ponderar.
Las actividades de estimación estudiadas en el capítulo 26 y las técnicas de
calendarización descritas en este capítulo con frecuencia se implementan bajo la
restricción de una fecha límite definida. Si las mejores estimaciones indican que la fecha
límite es irreal, un gerente de proyecto competente debe “proteger a su equipo contra la
presión excesiva [calendario]... [y] devolver la presión a quienes la originaron” [Pag85].
Para ilustrar lo anterior, suponga que a su equipo de software se le pide construir un
controlador en tiempo real para un instrumento de diagnóstico médico que debe
introducirse en el mercado en nueve meses. Después de realizar la estimación y el análisis
de riesgo cuidadosamente
(capítulo 28), llega a la conclusión de que el software, como se solicitó, requerirá 14
meses para su creación con el personal que se tiene disponible. ¿Cómo procedería?
Es irreal marchar hacia la oficina del cliente (en este caso el probable cliente es
mercadotecnia/
ventas) y demandar que se cambie la fecha de entrega. Las presiones del mercado externo
dictaron la fecha y el producto debe liberarse. Es igualmente temerario rechazar el
compromiso
de realizar el trabajo (desde el punto de vista profesional). De modo que, ¿qué hacer?
Ante esta
situación, los autores recomiendan los siguientes pasos:

La calendarización es la culminación de una actividad de planificación que es un

componente principal de la administración de proyectos de software. Cuando se combina
con los métodos de estimación y análisis de riesgos, establece un mapa de caminos para el
gerente del proyecto.
La calendarización comienza con la descomposición del proceso. Las características del
proyecto se usan para adaptar un conjunto de tareas adecuado para el trabajo que se va a
realizar.
Una red de tareas muestra cada tarea de ingeniería, su dependencia de otras tareas y su
duración proyectada. La red de tareas se usa para calcular la ruta crítica, un cronograma y
otra información del proyecto. Al usar el calendario como guía, puede monitorearse y
controlar cada paso en el proceso de software.

Preguntas:
27.1. Las fechas límite “irracionales” son un hecho de la vida en el negocio del software.
¿Cómo debe proceder
si se enfrenta con una?
27.2. ¿Cuál es la diferencia entre un calendario macroscópico y uno detallado? ¿Es posible
administrar un
proyecto si sólo se desarrolla un calendario macroscópico? Explique su respuesta.
27.3. ¿Puede existir un caso donde un hito de proyecto de software no se ligue a una
revisión? Si es así,
ofrezca uno o más ejemplos.