pert-cpm-gantt

UNJu – Facultad de Ingeniería
APU 2008
Gestión y Administración de proyectos
Proyecto: esfuerzo temporal que se lleva a cabo para crear un producto, un servicio o una obra.
1. Cada proyecto tiene un comienzo definido y un final definido
2. La duración de un proyecto es limitada aunque sea de años
3. Temporal NO es aplicable generalmente al producto, servicio o resultado creado por el
proyecto
Un proyecto crea entregables únicos
1. Servicio – consultoría
2. Producto – sistema
3. Resultado –mejora / eficiencia de procesos
La singularidad es una característica importante de los productos entregables de un proyecto. La
presencia de elementos repetitivos NO cambia la condición fundamental de único del trabajo de un
proyecto.
Proyectos vs Trabajos Operativos
Similitudes
Diferencias
Finalidad
Finalización
Proyectos
Operaciones
 Realizados por personas
 Limitación de Recursos
 Planificados – Ejecutados - Controlados
 Temporales
 Continuas
 Únicos
 Repetitivas
 Graduales
 Alcanzar el objetivo
 Respaldo al negocio
 Concluye al alcanzar
 Adoptan
nuevos
su objetivo
objetivos
 No concluyen
Cuándo un Proyecto es Exitoso?
1. Cuándo cumplimos en tiempo, sin pasar el presupuesto y entregando lo pedido?
2. Cuándo el cliente nos llama nuevamente?
3. Cuándo el próximo proyecto lo hacemos mejor?
4. Cuándo el cliente está satisfecho?
5. Cuándo el cliente paga?
6. Cuándo hay brindis final?
7. Cuándo?
Por qué no terminan bien los Proyectos?
1. Falta de sponsor
2. "Reinventamos la rueda" en cada proyecto
3. Objetivos poco claros o contradictorios
4. Planificación defectuosa, estimaciones incorrectas
5. Contar con muchas expectativas y pocas necesidades
6. Comunicaciones deficientes, comunicadores inexpertos
7. Cambios permanentes en las especificaciones
Analisis y Diseño I – APU 2008
Página 1
UNJu – Facultad de Ingeniería
8.
9.
10.
11.
APU 2008
Pobre administración de los recursos y de los proveedores
Nuevas tecnologías
Cultura de la organización
Dificultades para cerrar los proyectos
Qué tiene un proyecto exitoso?
En Teoría
Un proyecto se considera exitoso los plazos estipulados, dentro de especificaciones requeridas.
En la Práctica
1. Excelente comunicación
2. Liderazgo, conocimiento y poder
3. Sigue una metodología probada
4. Mostrar resultados, dar calidad
5. Validar las estimaciones
6. Más y mejor conocimientos y experiencias
7. Hace ganar dinero
Stakeholders: Son los individuos y organizaciones activamente involucrados en el proyecto; o
cuyos intereses pueden ser positiva o negativamente afectados como resultado de la ejecución del
proyecto.
Analisis y Diseño I – APU 2008
Página 2
UNJu – Facultad de Ingeniería
APU 2008
Gestión de proyectos: organización y administración de los recursos que intervienen en un
proyecto de manera tal que éste se pueda culminar dentro del alcance, del tiempo y del coste
definido.
Analisis y Diseño I – APU 2008
Página 3
UNJu – Facultad de Ingeniería
APU 2008
Entendamos Gestión de Proyectos como la planificación, el seguimiento y el control de las
actividades y de los recursos humanos y materiales que intervienen en el desarrollo de cualquier
proyecto (realizar un sitio web, organizar un evento, crear una biblioteca, etc.)
Conceptos relacionados con gestión de proyectos
EDT (Estructura de descomposición del trabajo) Work Breakdown Structure o WBS, es una
estructura exhaustiva, jerárquica y descendente formada por las diferentes tareas (unidades de
trabajo) a realizar en un proyecto.
El diagrama de Gantt, gráfica de Gantt o carta Gantt es una herramienta gráfica cuyo objetivo es
mostrar el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un
.
tiempo total determinado
Analisis y Diseño I – APU 2008
Página 4
UNJu – Facultad de Ingeniería
APU 2008
Flujo de trabajo Workflow, es el estudio de los aspectos de desarrollo de un proyecto: cómo se
estructuran las tareas, cómo se realizan, cuál es su orden correlativo, cómo se sincronizan, cómo
fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de las
tareas.
Se pueden distinguir tres tipos de actividad:
1. Actividades colaborativas: Un conjunto de usuarios trabajan sobre un mismo repositorio de
datos para obtener un resultado común. Tiene entidad el trabajo de cada uno de ellos en sí
mismo.
2. Actividades cooperativas: Un conjunto de usuarios trabajan sobre su propio conjunto
particular, estableciendo los mecanismos de cooperación entre ellos. No tiene entidad el
trabajo de ninguno de ellos si no es visto desde el punto de vista global del resultado final.
3. Actividades de coordinación.
Analisis y Diseño I – APU 2008
Página 5
UNJu – Facultad de Ingeniería
APU 2008
Program Evaluation and Review Technique, PERT, es básicamente un método para analizar
las tareas involucradas en completar un proyecto dado, especialmente el tiempo para completar
cada tarea, e identificar el tiempo mínimo necesario para completar el proyecto total.
Método de la ruta crítica, Critical Path Method, CPM. Una ruta crítica es la secuencia de las
tareas de un proyecto con la mayor duración entre ellos, lo cual determina el tiempo más corto en
el que es posible completar el proyecto. La duración de la ruta crítica determina la duración del
proyecto entero. Cualquier retraso en un elemento de la ruta crítica afecta a la fecha de término
planeada del proyecto, y se dice que no hay holgura en la ruta crítica.
A diferencia del método PERT, el método de la ruta crítica usa tiempos ciertos (reales o
determinísticos). Sin embargo, la elaboración de un proyecto en base a redes CPM y PERT son
similares y consisten en:
1. Identificar todas las actividades que involucra el proyecto, lo que significa, determinar
relaciones de precedencia, tiempos técnicos para cada una de las actividades.
2. Construir una red con base en nodos y actividades (o arcos, según el método más usado),
que implican el proyecto.
3. Analizar los cálculos específicos, identificando las rutas críticas y las holguras de los
proyectos.
Diagrama de Gantt
Los cronogramas de barras o “gráficos de Gantt” fueron concebidos por el ingeniero
norteamericano Henry L. Gantt, uno de los precursores de la ingeniería industrial contemporánea
de Taylor. Gantt procuro resolver el problema de la programación de actividades, es decir, su
distribución conforme a un calendario, de manera tal que se pudiese visualizar el periodo de
duración de cada actividad, sus fechas de iniciación y terminación e igualmente el tiempo total
requerido para la ejecución de un trabajo. El instrumento que desarrolló permite también que se
siga el curso de cada actividad, al proporcionar información del porcentaje ejecutado de cada una
de ellas, así como el grado de adelanto o atraso con respecto al plazo previsto.
Este gráfico consiste simplemente en un sistema de coordenadas en que se indica:
En el eje Horizontal: un calendario, o escala de tiempo definido en términos de la unidad más
adecuada al trabajo que se va a ejecutar: hora, día, semana, mes, etc.
En el eje Vertical: Las actividades que constituyen el trabajo a ejecutar. A cada actividad se hace
corresponder una línea horizontal cuya longitud es proporcional a su duración en la cual la
medición efectúa con relación a la escala definida en el eje horizontal conforme se ilustra.
Símbolos Convencionales: En la elaboración del gráfico de Gantt se acostumbra utilizar
determinados símbolos, aunque pueden diseñarse muchos otros para atender las necesidades
específicas del usuario.
Los símbolos básicos son los siguientes:
1. Iniciación de una actividad.
2. Término de una actividad
3. Línea fina que conecta las dos “L” invertidas. Indica la duración prevista de la actividad.
Analisis y Diseño I – APU 2008
Página 6
UNJu – Facultad de Ingeniería
APU 2008
4. Línea gruesa. Indica la fracción ya realizada de la actividad, en términos de porcentaje.
Debe trazarse debajo de la línea fina que representa el plazo previsto.
5. Plazo durante el cual no puede realizarse la actividad. Corresponde al tiempo improductivo
puede anotarse encima del símbolo utilizando una abreviatura.
6. Indica la fecha en que se procedió a la última actualización del gráfico, es decir, en que se
hizo la comparación entre las actividades previstas y las efectivamente realizadas.
Contenido
El diagrama de Gantt consiste en una representación gráfica sobre dos ejes; en el vertical se
disponen las tareas del proyecto y en el horizontal se representa el tiempo.
Características
1. Cada actividad se representa mediante un bloque rectangular cuya longitud indica su
duración; la altura carece de significado.
2. La posición de cada bloque en el diagrama indica los instantes de inicio y finalización de las
tareas a que corresponden.
3. Los bloques correspondientes a tareas del camino crítico acostumbran a rellenarse en otro
color (en el caso del ejemplo, en rojo).
Construir un diagrama de Gantt:
1. Dibujar los ejes horizontal y vertical.
2. Escribir los nombres de las tareas sobre el eje vertical.
3. En primer lugar se dibujan los bloques correspondientes a las tareas que no tienen
predecesoras.
4. Se sitúan de manera que el lado izquierdo de los bloques coincida con el instante cero del
proyecto (su inicio).
5. A continuación, se dibujan el bloque correspondiente a las tareas que sólo dependen de
las tareas ya introducidas en el diagrama. Se repite este punto hasta haber dibujado todas
las tareas. En este proceso se han de tener en cuenta las consideraciones siguientes:
6. Las dependencias fin-inicio se representan alineando el final del bloque de la tarea
predecesora con el inicio del bloque de la tarea dependiente.
7. Las dependencias final-final se representan alineando los finales de los bloques de las
tareas predecesora y dependiente.
8. Las dependencias inicio-inicio se representan alineando los inicios de los bloques de las
tareas predecesora y dependiente.
Analisis y Diseño I – APU 2008
Página 7
UNJu – Facultad de Ingeniería
APU 2008
9. Los retardos se representan desplazando la tarea dependiente hacia la derecha en el caso
de retardos positivos y hacia la izquierda en el caso de retardos negativos.
Ejemplo
Finalmente, una vez realizados los cálculos del proyecto utilizando un sistema adecuado, como el
diagrama PERT o el Roy, resulta conveniente destacar con un color distinto las tareas con margen
total 0, para poder identificar con facilidad los caminos críticos.
VENTAJAS Y DESVENTAJAS DE LOS GRÁFICOS DE GANTT.
La ventaja principal del gráfico de Gantt radica en que su trazado requiere un nivel mínimo de
planificación. Los gráficos de Gantt se revelan muy eficaces en las etapas iniciales de la
planificación. Sin embargo, después de iniciada la ejecución de la actividad y cuando comienza a
efectuarse modificaciones, el gráfico tiende a volverse confuso. Por eso se utiliza mucho la
representación gráfica del plan, en tanto que los ajustes (re planificación) requieren por lo general
de la formulación de un nuevo gráfico. Para superar esa deficiencia se crearon dispositivos
mecánicos, tales como cuadros magnéticos, fichas, cuerdas, etc., que permite una mayor
flexibilidad en las actualizaciones. Aún en términos de planificación, existe todavía una limitación
bastante grande en lo que se refiere a la representación de planes de cierta complejidad. El Gráfico
de Gantt no ofrece condiciones para el análisis de opciones, ni toma en cuenta factores como el
costo. Es fundamentalmente una técnica de pruebas y errores. No permite, tampoco, la
visualización de la relación entre las actividades cuando el número de éstas es grande.
En resumen, para la planificación de actividades relativamente simples, el gráfico de Gantt
representa un instrumento de bajo costo y extrema simplicidad en su utilización. Para proyectos
complejos, sus limitaciones son bastantes serias, y fueron éstas las que llevaron a ensayos que
dieron como resultado el desarrollo del CPM, el PERT y otras técnicas conexas. Estas técnicas
introdujeron nuevos conceptos que, asociados más tarde a los de los gráficos de Gantt, dieron
origen a las denominadas “redes-cronogramas”. Gráfico de Gantt para seguir la marcha de las
actividades: En este tipo de gráfico se usa el eje vertical para representar actividades, en tanto que
los recursos aplicados a cada uno indican, por medio de claves, sobre la línea que representan la
duración de la actividad. Consiste, por lo tanto, en una inversión del caso anterior. El eje horizontal
permanece como registro de escala de tiempo. Gráfico de Gantt para el control de la carga de
trabajo: Este gráfico es semejante al de la distribución de actividad que tiene por objeto
proporcionar el administrador una posición de carga total de trabajo aplicada a cada recurso. Indica
Analisis y Diseño I – APU 2008
Página 8
UNJu – Facultad de Ingeniería
APU 2008
el periodo durante el cual el recurso estará disponible para el trabajo (representado por una línea
fina) y la carga total de trabajo asignada a este recurso (representado por una línea gruesa).
PERT Y CPM
Un diagrama de red es cualquiera de las representaciones que vinculan las actividades y los
eventos de un proyecto entre sí para reflejar las interdependencias entre las mismas. Una actividad
o evento puede presentar interdependencias con actividades o eventos sucesores, predecesores,
o en paralelo. Los más importantes son:
PERT (Program Evaluation and Review Technique). Desarrollado por la Special Projects Office de
la Armada de EE.UU. a finales de los 50s para el programa de I+D que condujo a la construcción
de los misiles balísticos Polaris. Está orientada a los sucesos o eventos, y se ha utilizado
típicamente en proyectos de I+D en los que el tiempo de duración de las actividades es una
incertidumbre. Dado que las estimaciones de duración comportan incertidumbre se estudian las
distribuciones de probabilidad de las duraciones. Con un diagrama PERT se obtiene un
conocimiento preciso de la secuencia necesaria, o planificada para la ejecución de cada actividad y
utilización de diagramas de red.
Se trata de un método muy orientado al plazo de ejecución, con poca consideración hacia al coste.
Se suponen tres duraciones para cada suceso, la optimista a, la pesimista b y la normal m;
suponiendo una distribución beta, la duración más probable: t = (a + 4m + b) / 6 .
Generalmente se denominan técnicas PERT al conjunto de modelos abstractos para la
programación y análisis de proyectos de ingeniería. Estas técnicas nos ayudan a programar un
proyecto con el coste mínimo y la duración más adecuada. Están especialmente difundidas el
PERT y el CPM.
Aplicación de las técnicas PERT:
1. Determinar las actividades necesarias y cuando lo son.
2. Buscar el plazo mínimo de ejecución del proyecto.
3. Buscar las ligaduras temporales entre actividades del proyecto.
4. Identificar las actividades críticas, es decir, aquellas cuyo retraso en la ejecución supone un
retraso del proyecto completo.
5. Identificar el camino crítico, que es aquel formado por la secuencia de actividades críticas
del proyecto.
6. Detectar y cuantificar las holguras de las actividades no críticas, es decir, el tiempo que
pueden retrasarse (en su comienzo o finalización) sin que el proyecto se vea retrasado por
ello.
7. Si se está fuera de tiempo durante la ejecución del proyecto, señala las actividades que
hay que forzar.
8. Nos da un proyecto de coste mínimo.
Camino crítico
El camino crítico en un proyecto es la sucesión de actividades que dan lugar al máximo tiempo
acumulativo.
Analisis y Diseño I – APU 2008
Página 9
UNJu – Facultad de Ingeniería
APU 2008
Determina el tiempo más corto que podemos tardar en hacer el proyecto si se dispone de todos los
recursos necesarios. Es necesario conocer la duración de las actividades.
Este concepto es utilizado por dos métodos:
 Método del tiempo estimado (CPM) La duración de una actividad es la más probable de
duración. Tiempo que se emplearía en condiciones normales (m). Situación determinista.
 Método del tiempo esperado (PERT) Determinación probabilística de los tiempos
esperados (Te), en función de los siguientes tiempos:
1. Duración más corta (a)
2. Duración más larga (b)
3. Duración más probable (m) (el mismo que en CPM)
4. Duración esperada: Te = (a + 4m + b) / 6.
Principios
Estos tres principios deben respetarse siempre a la hora de dibujar una malla PERT:
1. Principio de designación sucesiva: se nombra a los vértices según los números naturales,
de manera que no se les asigna número hasta que han sido nombrados todos aquellos de
los que parten aristas que van a parar a ellos.
2. Principio de unicidad del estado inicial y el final: se prohíbe la existencia de más de un
vértice inicial o final. Sólo existe una situación de inicio y otra de terminación del proyecto.
3. Principio de designación unívoca: no pueden existir dos aristas que tengan los mismos
nodos de origen y de destino. Normalmente, se nombran las actividades mediante el par
de vértices que unen. Si no se respetara este principio, puede que dos aristas recibieran la
misma denominación
Dibujo de una malla PERT
Existen dos metodologías aceptadas para dibujar una malla PERT, la de “Actividad en el Arco” y
las de “Actividad en el Nodo”, siendo ésta última la más utilizada en la actualidad en atención a que
es la que usan la mayoría de las aplicaciones computacionales especialistas en este tema.
Red PERT.
Cada nodo contiene la siguiente información sobre la actividad:
 Nombre de la actividad
 Duración esperada de la actividad (t)
 Tiempo de inicio más temprano (ES = Earliest Start)
 Tiempo de término más temprano (EF = Earliest Finish)
 Tiempo de inicio más tardío (LS = Latest Start)
 Tiempo de término más tardío (LF = Latest Finish)
 Holgura de la Actividad (H)
Analisis y Diseño I – APU 2008
Página 10
UNJu – Facultad de Ingeniería
APU 2008
Por convención los arcos se dibujan siempre con orientación hacia la derecha, hacia el nodo de
término del proyecto, nunca retrocediendo. El dibujo de una malla PERT se comienza en el nodo
de inicio del proyecto. A partir de él se dibujan las actividades que no tienen actividades
precedentes, o sea, aquellas que no tienen que esperar que otras actividades terminen para poder
ellas iniciarse. A continuación, se dibujan las restantes actividades cuidando de respetar la
precedencia entre ellas. Al terminar el dibujo de la malla preliminar, existirán varios nodos ciegos,
nodos terminales a los que llegan aquellas actividades que no son predecesoras de ninguna otra,
es decir aquellas que no influyen en la fecha de inicio de ninguna otra, éstas son las actividades
terminales y concurren por lo tanto al nodo de término del proyecto. para esto no es necesario
utilizarlo
Cálculo de los tiempos de inicio y término más tardíos
El tiempo de inicio más tardío “LS” (Latest Start) y de término más tardío “LF” (Latest finish) para
cada actividad del proyecto, se calculan desde el nodo de término retrocediendo hacia el nodo de
inicio del proyecto según la siguiente relación:
Donde (t) es el tiempo esperado de duración de la actividad y donde LF queda definida según la
siguiente regla:
Regla del tiempo de término más tardío:
El tiempo de término más tardío, LF, de una actividad específica, es igual al menor de los tiempos
LS de todas las actividades que comienzan exactamente después de ella.
El tiempo de término más tardío de las actividades que terminan en el nodo de término del
proyecto es igual a la duración esperada del proyecto (T).
Holguras, actividades críticas y rutas críticas
La Holgura de una actividad, es el tiempo que tiene ésta disponible para, ya sea, atrasarse en su
fecha de inicio, o bien alargarse en su tiempo esperado de ejecución, sin que ello provoque retraso
alguno en la fecha de término del proyecto.
La holgura de una actividad se calcula de la siguiente forma:
Analisis y Diseño I – APU 2008
Página 11
UNJu – Facultad de Ingeniería
APU 2008
H = LF – EF
o bien
H = LS – ES
Actividades críticas
Se denomina actividades críticas a aquellas actividades cuya holgura es nula y que por lo tanto, si
se retrasan en su fecha de inicio o se alargan en su ejecución más allá de su duración esperada,
provocarán un retraso exactamente igual en tiempo en la fecha de término del proyecto.
Rutas críticas
Se denomina rutas críticas a los caminos continuos entre el nodo de inicio y el nodo de término del
proyecto, cuyos arcos componentes son todas actividades críticas. Las rutas críticas se nombran
por la secuencia de actividades críticas que la componen o bien por la secuencia de nodos por los
que atraviesa. Nótese que un proyecto puede tener más de una ruta crítica pero a lo menos tendrá
siempre una.
Otras consideraciones:
Se llama evento al momento de iniciación o terminación de una actividad. Se determina en un
tiempo variable entre el más temprano y el más tardío posible, de iniciación o de terminación.
A los eventos se les conoce también con los nombres de nodos.
i
j
El evento inicial se llama i y el evento final se denomina j. El evento final de una actividad será el
evento inicial de la actividad siguiente. Las flechas no son vectores, escalares ni representan
medida alguna. No interesa la forma de las flechas, ya que se dibujarán de acuerdo con las
necesidades y comodidad de presentación de la red. Pueden ser horizontales, verticales,
ascendentes, descendentes curvas, rectas, quebradas, etc.
En los casos en que haya necesidad de indicar que una actividad tiene una interrelación o
continuación con otra se dibujará entre ambas una línea punteada, llamada liga, que tiene una
duración de cero
La liga puede representar en algunas ocasiones un tiempo de espera para poder iniciar la
actividad siguiente
Varias actividades pueden terminar en un evento o partir de un mismo evento.
Al construir la red, debe evitarse lo siguiente:
1. Dos actividades que parten de un mismo evento y llegan a un mismo evento. Esto
produce confusión de tiempo y de continuidad. Debe abrirse el evento inicial o el evento
final en dos eventos y unirlos con una liga.
2. Partir una actividad de una parte intermedia de otra actividad. Toda actividad debe
empezar invariablemente en un evento y terminar en otro. Cuando se presenta este caso,
a la actividad base o inicial se le divide en eventos basándose en porcentajes y se derivan
de ellos las actividades secundadas.
3. Dejar eventos sueltos al terminar la red. Todos ellos deben relacionarse con el evento
inicial o con el evento final.
Analisis y Diseño I – APU 2008
Página 12
UNJu – Facultad de Ingeniería
APU 2008
La gestión de un proyecto informático
Introducción
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 detonar 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
partir de una primera especificación genérica del alcance del proyecto muy precaria, 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 desarrollo del proyecto, sólo se debe
realizar el seguimiento y el control. En este módulo, repasamos brevemente los
problemas generales de la planificació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 informá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 importancia en los últimos años, posiblemente por la falta de calidad y
fiabilidad de la mayoría del software construido.
Objetivos
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 tratan los temas de la
planificación temporal de actividades y, a partir de esta planificación, del
seguimiento y el control del desarrollo del proyecto. 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 asociados, 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
utilizar para controlar el desarrollo de un proyecto y realizar un seguimiento
completo y exhaustivo.
Analisis y Diseño I – APU 2008
Página 13
UNJu – Facultad de Ingeniería
APU 2008
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 calidad
del Software (software quality assurance ) y, en definitiva, de la dificultad
de obtener Software seguro, fiable y de calidad
Planificación en el tiempo de los proyectos informáticos
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
planificación temporal) y la segunda es el desarrollo (seguimiento y control del proyecto,
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, 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 descomposició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 construcció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
diferencias esenciales con otros proyectos de ingeniería. Comenzamos con la exposición
breve y sintética de conceptos tradicionales 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.
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 precedencias entre las
tareas que constituyen el proyecto. Este diagrama, que algunos denominan 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
A menudo, los dos métodos se pueden tratar conjuntamente, tal como haremos en esta
exposición simplificada. Conviene advertir que, aunque aquí se habla de tareas o
actividades indistintamente, a menudo la nomenclatura más habitual utiliza el término
actividades cuando se refiere a PERT, aunque actualmente la elección suele depender de
la manera como se haya traducido el concepto en la herramienta 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) proporcionan herramientas
cuantitativas que permiten determinar lo siguiente:
1. El camino crítico del proyecto, que es la secuencia o cadena de actividades que
determina la duración total del proyecto.
Analisis y Diseño I – APU 2008
Página 14
UNJu – Facultad de Ingeniería
APU 2008
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 hemos efectuado una
descomposición en diez actividades, como las que se indican en la tabla siguiente
Actividades, duración y precedencia de un proyecto ficticio
Núm. Nombre de la Actividad
Duración estimada
1
Inicio
0
2
Establecer los requerimientos
3
3
Seleccionar los drivers
2
4
Realizar el diseño
4
5
Recoger los datos
2
6
Probar los drivers
6
7
Codificar
4
8
Elaborar la documentación
2
9
Probar el producto
4
10
Final
0
Precedencias
1
1
2
2y3
3
4
4
5, 6 y 7
Conviene, tal como se lleva a cabo aquí, incluir siempre las actividades de inicio y final,
puramente ficticias y con duración cero. La tabla nos ofrece para cada actividad un
nombre, una identificación numé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 concreto
(precedencias).Si se quiere, se puede imaginar que se trata de construir un sistema
informático 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 precedencia que
existen entre las actividades, mientras que los nudos son las actividades, 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 (establecer los
requerimientos) comienza en la semana cero (justo después de la actividad 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 no puede iniciarse hasta que no termine la
precedente (la 2, establecer los requerimientos), es decir, no puede empezar hasta que
Analisis y Diseño I – APU 2008
Página 15
UNJu – Facultad de Ingeniería
APU 2008
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 directos: 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 once, 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 (inicio), 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.
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
Analisis y Diseño I – APU 2008
Página 16
UNJu – Facultad de Ingeniería
APU 2008
puede comenzar a efectuar una vez finalizada la segunda semana del proyecto (justo cuando
acabala 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 (probar 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 diagrama, 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é actividades 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 disponen de un margen que permite que el planificador acomode mejor los
recursos 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 planificación Temprana, que sitúa
cada actividad lo antes posible y es el procedimiento 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 Tardia
Herramientas informatizadas para la planificación
Cuando se habla de herramientas informatizadas para la planificación. 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 disponibles, por el hecho de tener un mercado mucho más amplio, tengan un coste
más accesible y su uso se convierta en muy habitual. El problema que se plantea a menudo es
decidir cuál de las muchas herramientas 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
funcionalidades 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,
SUPERPROJECT, PLANER, PHP PROJEKT, GANTT PROJECT, MEMORANDA,
OPENPRO. Elegir una de las 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 incorporará también la
misma funcionalidad. Además, cabe recordar que la mayoría de estas funcionalidades no
siempre se utilizan. Como ocurre con los procesadores de texto, a menudo es mejor lo
Analisis y Diseño I – APU 2008
Página 17
UNJu – Facultad de Ingeniería
APU 2008
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 estado disponible, pero no
porque exista alguna preferencia que se pueda generalizar a otros usuarios. Lo que
importa de las herramientas informatizadas para la ayuda a la planificació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 planificación de un proyecto.
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
En realidad, la mayoría de herramientas informatizadas de ayuda a la planificación utilizan
el diagrama de Gantt como marco de referencia para introducirlos 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 herramientas informatizadas ofrecen también diagramas
basados en el calendario 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 necesario,
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.
Analisis y Diseño I – APU 2008
Página 18
UNJu – Facultad de Ingeniería
APU 2008
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
etapas diferentes, añadir un hito de control al final de cada fase sería lo más correcto,
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.
La consideración de los recursos: añadir nuevas 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 persona, este diagrama de Gantt nos dice que esta
persona tiene una jornada de dieciséis horas y no de ocho como es habitual. No parece, pues,
posible.
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 proyecto. 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 imaginamos
que disponemos de tres personas en el equipo del proyecto:
1. Una primera persona podría llevar a cabo las tareas 2 (establecer los
requerimientos), 4
2. (realizar el diseño), 7 (codificar) y 9 (probar el producto).
3. Un segundo miembro del equipo se podría encargar de las tareas 3 (seleccionar
los drivers ) y 6 (probar los drivers ) y, tal vez, participar también en la actividad 9
(probar el producto).
4. 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 documentación).La
figura siguiente muestra una modificación sencilla en el caso de que el equipo del
proyecto estuviera formado por dos miembros. Para evitar jornadas dobles 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) dependa de la 5 (recoger datos),
para conseguir que las realice la misma persona
Núm.
1
2
3
4
5
Actividades, duración y precedencia de un proyecto ficticio
Nombre de la Actividad
Duración estimada
Precedencias
Inicio
0
Establecer los requerimientos
3
1
Seleccionar los drivers
2
1
Realizar el diseño
4
2
2, 3 y 6
Recoger los datos
2
Analisis y Diseño I – APU 2008
A
B
A
B
Página 19
UNJu – Facultad de Ingeniería
6
7
8
9
10
Probar los drivers
Codificar
Elaborar la documentación
Probar el producto
Final
APU 2008
6
4
2
4
0
3
4
4y5
5, 6 y 7
B
A
B
A
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 actividades 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.
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 antes posible las
desviaciones que se deben producir para poder encontrarles una solución. Para conseguir
Analisis y Diseño I – APU 2008
Página 20
UNJu – Facultad de Ingeniería
APU 2008
todo esto, es imprescindible comparar periódicamente la realidad 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 seguimiento y
control del proyecto debe conseguir detectar los problemas con la máxima 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 momento determinado del proyecto
se llevan dos meses de retraso, porque entonces ya sería demasiado 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:
1. 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 momento inicial,
pero que son totalmente necesarias e imprescindibles a medida que avanza el
proyecto
2. 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.
3. Si conviene cambiar algunos de los objetivos del proyecto o no, para tratar
de mantener los otros.
4. Si conviene llevar a cabo una nueva calificación del proyecto o no, para
tener 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 inicial 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.
Las hojas de actividad y el informe de situación
Para poder llevar a cabo una comparación correcta entre la realidad y la previsió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 tener 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.
Analisis y Diseño I – APU 2008
Página 21
UNJu – Facultad de Ingeniería
APU 2008
Conviene recoger de manera individual por cada tarea y cada persona involucrada estos
datos de seguimiento, a partir de los cuales el jefe de proyecto debe elaborar los datos
globales que permiten construir un informe de situación del proyecto. Este informe se
suele llevar a cabo para cada uno de los hitos de control establecidos
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 permitir anticipar los
problemas. Con los datos reales obtenidos de la hoja de actividad, el jefe de proyecto
realiza el seguimiento, a menudo mediante herramientas informatizadas que permiten,
para cada actividad del proyecto, introducir las fechas reales del trabajo acabado o el
porcentaje del trabajo hecho en cada momento. Estas herramientas 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
La ley de Brooks
La Ley de Brooks es un principio utilizado en el desarrollo de software que afirma
que "añadir más efectivos a un proyecto de software en retraso, lo retrasará más"
Según el propio libro de Brooks, la ley es una "frívola sobre simplificación", pero se hace
eco de la idea. Brooks destaca dos factores principales que explican el porqué de la ley:
1. Nuevas personas en un proyecto necesitan tiempo para ser productivos. Brooks
denomina este lapso el tiempo de rampa de subida ("ramp up time"). Los
proyectos de software son complejos esfuerzos de ingeniería, y a los nuevos
trabajadores en el proyecto hay que enseñarles primero sobre el trabajo que se
realizó anteriormente; esta formación requiere tiempo entre aquellos que ya
estaban trabajando en el proyecto, disminuyendo su productividad de forma
temporal hasta que los nuevos trabajadores tengan una contribución neta. Cada
nuevo trabajador también tiene que integrarse en un equipo compuesto por
numerosos ingenieros, que han de ayudar en la formación en sus áreas de
conocimiento, día a día. Además, es posible que los nuevos miembros del
proyecto de por sí tengan una productividad incluso negativa; por ejemplo, si
introducen errores en el software por desconocimiento.
2. Aumento de los costes generales (en tiempo) a medida que aumenta el tamaño del
proyecto. El número de canales de comunicación diferentes aumenta con el
número de personas de forma exponencial; si se dobla el número de personas en
el proyecto, el resultado es 4 veces más conversaciones. Todos aquellos que
trabajan en un tema necesitan estar sincronizados entre ellos, de forma que si
crece el número de personas, también crecerá el tiempo invertido en tratar de
averiguar lo que hace el resto.
Excepciones y posibles soluciones
Analisis y Diseño I – APU 2008
Página 22
UNJu – Facultad de Ingeniería
APU 2008
La ley de Brooks se cita a menudo para justificar que los proyectos no se terminan a
tiempo, a pesar de los esfuerzos gestores. Sin embargo, hay algunos puntos clave de la
ley de Brooks que permiten excepciones y abren la puerta a posibles soluciones.
El primer punto es que la ley de Brooks se suele aplicar a proyectos que tienen retraso.
Se puede volver a controlar (o mantener bajo control) si se refuerza el equipo en fases
previas. También es importante determinar si un proyecto se encuentra realmente en
retraso o si las estimaciones iniciales fueron demasiado optimistas, algo frecuente.
Corregir la planificación es la mejor manera de disponer de una ventana de tiempo fiable y
útil para finalizar el proyecto. La cantidad, calidad y papel de la gente que se incorpora al
proyecto son factores a tener en cuenta. Una vía simple de evitar la ley en un proyecto en
retraso es añadir más gente de la necesaria, de forma que la capacidad extra compensa
el overhead en comunicación y formación. Los buenos programadores o especialistas se
pueden incorporar con menos necesidad de tiempo para su formación. También se puede
incorporar personal para realizar otras tareas relacionadas con el proyecto, por ejemplo
documentación o garantía de calidad en caso de que la tarea esté disponible, así se
disminuye el tiempo de la rampa de subida. Una buena labor de gestión y desarrollo
también ayuda a reducir el impacto de la ley de Brooks. Las prácticas modernas de
integración continua, desarrollo guiado por pruebas, y desarrollo iterativo reducen
significativamente el overhead de comunicación entre los desarrolladores, permitiendo
mejor escalabilidad. También nuevas herramientas para el desarrollo de software y su
documentación son de ayuda a minimizar el tiempo de rampa de subida, haciendo más
sencilla la incorporación al proyecto. Los patrones de diseño simplifican la distribución del
trabajo, dado que el equipo completo puede realizar el trabajo dentro del patrón que se le
asignó. Los patrones de diseño definen las reglas que han de seguir los programadores,
simplifica la comunicación por medio del uso de un lenguaje estándar y proporciona
consistencia y escalabilidad. Finalmente, una buena segmentación ayuda minimizando el
overhead entre los miembros del proyecto. Los problemas menores se resuelven en
equipos pequeños y un equipo superior es responsable de la integración del sistema.
Para poder trabajar así es necesario segmentar el problema de forma correcta; en caso
contrario, puede empeorar el problema, impidiendo la comunicación entre los
programadores que trabajan en diferentes partes del problema que están directamente
relacionados, aunque el plan del proyecto afirme que no los están. Algunos autores
véase, por ejemplo, Creating a Software Engineering Culture de Karl E. Wiegers – han
recalcado la importancia de los aspectos sociales y políticos del clima de trabajo como
determinantes de la efectividad de los programadores individuales y del equipo del
proyecto como un todo. En lugar de depender de "héroes" para llevar a cabo la tarea con
esfuerzos extraordinarios, Wiegers afirma que un equipo de individuales de cualidades
ordinarias pueden proveer resultados a tiempo de forma periódica con el ambiente de
trabajo correcto. Los esfuerzos para mejorar la efectividad de los equipos puede mitigar
sino eliminar, las consecuencias de la ley de Brooks.
Una teoría que proviene de la experiencia del autor de la obra The Mythical Man-Month
(1975) como director del proceso de construcción del sistema operativo de IBM 360. Es
necesario entender esta advertencia en el sentido de que no se pueden intercambiar
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.
Analisis y Diseño I – APU 2008
Página 23
UNJu – Facultad de Ingeniería
APU 2008
En cualquier proyecto (pensemos, por ejemplo, en la construcción de una casa), cuando
éste va retrasado, una solución para mantener los plazos, aun que 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, 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 Rayleigh/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 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 realiza. 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 conocen qué se realiza y que, además, crean necesidades adicionales de
comunicación que pueden consumir incluso una parte de los recursos que ya existen,
simplemente porque los miembros “viejos” del equipo de proyecto han de explicar 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
Aseguramiento de la calidad en un proyecto informático
Desgraciadamente, la calidad del software 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 assurance), a veces se ha traducido del inglés como garantía de calidad
del software , aunque diferentes 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 construcció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 garantizar, 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 final. Esto
implica la utilización de estándares de desarrollo documentados explícitamente y de
procedimientos concretos de gestión de todo el proceso de construcción de software
Analisis y Diseño I – APU 2008
Página 24
UNJu – Facultad de Ingeniería
APU 2008
El tratamiento del aseguramiento de la calidad se centra tradicionalmente en las
inspecciones y revisiones formales, junto con las llamadas reuniones de repaso. Uno de
los objetivos fundamentales es, evidentemente, obtener la caracterí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 mantenimiento en el ciclo de vida del software
La ISO es la organización internacional encargada de crear todo tipo de
está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 aseguramiento de
la calidad con el fin de que se puedan aplicar a cualquier negocio 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 ISO9000-3, que data de 1996, quiere
proporcionar una guía y una ayuda con vistas 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
Resumen
La planificación temporal de un proyecto informático arranca de la descomposició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 dispone 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 margen 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 seguimiento de proyectos ofrecen diferentes diagramas (de
Gantt, PERT, de calendario, 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 previstos 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 revisar 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.
Analisis y Diseño I – APU 2008
Página 25