Sie sind auf Seite 1von 30

La gestión La gestión

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

Índice Índice

Introducción .............................................................................................. 5 Introducción .............................................................................................. 5

Objetivos ..................................................................................................... 6 Objetivos ..................................................................................................... 6

1. Planificación en el tiempo de los proyectos 1. Planificación en el tiempo de los proyectos


informáticos ......................................................................................... 7 informáticos ......................................................................................... 7
1.1. La técnica del PERT y el método del camino crítico ........................ 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.2. Herramientas informatizadas para la planificación ......................... 12
1.3. La planificación de un proyecto informático ................................... 13 1.3. La planificación de un proyecto informático ................................... 13
1.3.1. La consideración de los recursos: añadir nuevas 1.3.1. La consideración de los recursos: añadir nuevas
precedencias .......................................................................... 14 precedencias .......................................................................... 14

2. Seguimiento y control de un proyecto informático .................. 17 2. Seguimiento y control de un proyecto informático .................. 17
2.1. Las hojas de actividad y el informe de situación ............................. 18 2.1. Las hojas de actividad y el informe de situación ............................. 18
2.2. La ley de Brooks ................................................................................ 19 2.2. La ley de Brooks ................................................................................ 19

3. Aseguramiento de la calidad en un proyecto 3. Aseguramiento de la calidad en un proyecto


informático .......................................................................................... 21 informático .......................................................................................... 21

Resumen ...................................................................................................... 23 Resumen ...................................................................................................... 23

Actividades ................................................................................................. 25 Actividades ................................................................................................. 25

Ejercicios de autoevaluación ................................................................. 26 Ejercicios de autoevaluación ................................................................. 26

Solucionario ............................................................................................... 28 Solucionario ............................................................................................... 28

Glosario ....................................................................................................... 28 Glosario ....................................................................................................... 28

Bibliografía ................................................................................................ 29 Bibliografía ................................................................................................ 29


 FUOC • P03/7506/02143 La gestión de un proyecto informático  FUOC • P03/7506/02143 La gestión de un proyecto informático
 FUOC • P03/7506/02143 5 La gestión de un proyecto informático  FUOC • P03/7506/02143 5 La gestión de un proyecto informático

Introducción Introducción

En los módulos didácticos “El proyecto informático de construcción de software” 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 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 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 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 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. 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á- Podéis ver el mito del hombre-mes De hecho, lo que ahora queda por ver de la gestión de un proyecto informá- Podéis ver el mito del hombre-mes
en el subapartado 1.3.2 del módulo en el subapartado 1.3.2 del módulo
tico no es en absoluto tan diferente de lo que es habitual en la gestión de “Estimación de costes de un proyecto tico no es en absoluto tan diferente de lo que es habitual en la gestión de “Estimación de costes de un proyecto
informático” de esta asignatura. informático” de esta asignatura.
cualquier otro proyecto de ingeniería, sobre todo si se recuerda, a la hora 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 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 habla de personas-mes para considerar el esfuerzo, no se puede en absoluto
pensar en intercambiar los dos factores. pensar en intercambiar los dos factores.

Una vez se ha llevado a cabo la primera estimación de costes, a menudo, a par- 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- 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 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- 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. 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- 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 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 diagramas PERT o el método del camino crítico (CPM), sin olvidar hacer una
referencia inevitable a las diferentes herramientas informáticas disponibles referencia inevitable a las diferentes herramientas informáticas disponibles
que pueden ayudar en esta actividad de planificación. que pueden ayudar en esta actividad de planificación.

A partir de la planificación de actividades, es mucho más sencillo ordenar el 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 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- finalizar con éxito la actividad de construir un software de aplicación en la in-
formática de gestión. formática de gestión.

Una vez revisadas brevemente las actividades típicas de gestión de proyectos 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 (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 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- 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 tancia en los últimos años, posiblemente por la falta de calidad y fiabilidad de
la mayoría del software construido. la mayoría del software construido.
 FUOC • P03/7506/02143 6 La gestión de un proyecto informático  FUOC • P03/7506/02143 6 La gestión de un proyecto informático

Objetivos Objetivos

En este módulo se cierra el estudio de la gestión de un proyecto informático 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- 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- 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 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 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- del software. Con el estudio de este módulo y de los materiales didácticos aso-
ciados, el estudiante debe alcanzar los objetivos siguientes: ciados, el estudiante debe alcanzar los objetivos siguientes:

1. Conocer la problemática general de la planificación temporal de proyectos, 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 el uso de diagramas de Gantt, la técnica del PERT y el método del camino
crítico (CPM). crítico (CPM).

2. Saber planificar en el tiempo las actividades de un proyecto informático, 2. Saber planificar en el tiempo las actividades de un proyecto informático,
teniendo en cuenta los recursos disponibles y las limitaciones de uso. 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- 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 lizar para controlar el desarrollo de un proyecto y realizar un seguimiento
completo y exhaustivo. completo y exhaustivo.

4. Saber cuáles son las decisiones más habituales que se han de tomar en el 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 proceso de control de un proyecto informático y los aspectos que más las
condicionan. condicionan.

5. Conocer las herramientas informáticas que ayudan tanto en el proceso de 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 del proyecto, como en el de seguimiento y control de una
planificación ya efectuada. planificación ya efectuada.

6. Obtener una visión inicial de los problemas de aseguramiento de la cali- 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 dad del software (software quality assurance) y, en definitiva, de la dificultad de
obtener software seguro, fiable y de calidad. obtener software seguro, fiable y de calidad.
 FUOC • P03/7506/02143 7 La gestión de un proyecto informático  FUOC • P03/7506/02143 7 La gestión de un proyecto informático

1. Planificación en el tiempo de los proyectos 1. Planificación en el tiempo de los proyectos


informáticos informáticos

Tal como explicamos en otro módulo, una vez determinada la voluntad de Podéis ver las etapas de un proyecto Tal como explicamos en otro módulo, una vez determinada la voluntad de Podéis ver las etapas de un proyecto
informático en el subapartado 1.2 informático en el subapartado 1.2
iniciar un proyecto informático, las etapas que caracterizan la gestión son del módulo “El proyecto informático
de construcción de software” de esta
iniciar un proyecto informático, las etapas que caracterizan la gestión son del módulo “El proyecto informático
de construcción de software” de esta
asignatura. asignatura.
dos: la primera es la calificación inicial (estimación de costes y planifica- 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- 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 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 llegar, de una manera o de otra, con éxito o sin él, al final o cierre definitivo
del proyecto. del proyecto.

Una vez conocida la amplia problemática de la estimación de costes, que Podéis ver la problemática Una vez conocida la amplia problemática de la estimación de costes, que Podéis ver la problemática
de la estimación de costes de la estimación de costes
nos ha ocupado un módulo entero, ahora planificaremos en el tiempo las en el módulo “Estimación de costes
de un proyecto informático” de esta
nos ha ocupado un módulo entero, ahora planificaremos en el tiempo las en el módulo “Estimación de costes
de un proyecto informático” de esta
asignatura. asignatura.
diferentes tareas o actividades de las que consta el proyecto. diferentes tareas o actividades de las que consta el proyecto.

Cabe mencionar que la planificación temporal de proyectos a partir de su des- 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 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- proceso suficientemente conocido y que los proyectos informáticos de cons-
trucción de software comparten con muchos otros proyectos de ingeniería. Por 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 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- recursos (las personas que forman el equipo del proyecto), no se dan diferen-
cias esenciales con otros proyectos de ingeniería. cias esenciales con otros proyectos de ingeniería.

Comenzamos con la exposición breve y sintética de conceptos tradiciona- 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 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 el método del camino crítico (CPM) y después analizamos el caso general
de la planificación temporal de proyectos informáticos. de la planificación temporal de proyectos informáticos.

1.1. La técnica del PERT y el método del camino crítico 1.1. La técnica del PERT y el método del camino crítico

* PERT es la sigla de la expresión * PERT es la sigla de la expresión


La técnica del PERT* (técnica de revisión y actualización del programa inglesa Program Evaluation La técnica del PERT* (técnica de revisión y actualización del programa inglesa Program Evaluation
and Review Technique. and Review Technique.
o proyecto) es un procedimiento desarrollado ya hace décadas por la o proyecto) es un procedimiento desarrollado ya hace décadas por la
Marina norteamericana (US Navy) para el tratamiento de grandes pro- Marina norteamericana (US Navy) para el tratamiento de grandes pro-
yectos de ingeniería de todo tipo. yectos de ingeniería de todo tipo.

El fundamento central de las técnicas del PERT es la representación gráfica del 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- 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- 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 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, actividades que a menudo se llama red de actividades (activity network) o, también,
diagrama de precedencias. diagrama de precedencias.
 FUOC • P03/7506/02143 8 La gestión de un proyecto informático  FUOC • P03/7506/02143 8 La gestión de un proyecto informático

El método del camino crítico (CPM) es un método de optimización El método del camino crítico (CPM) es un método de optimización
CPM es la sigla de la expresión CPM es la sigla de la expresión
que, como el PERT, también utiliza una red de tareas del proyecto. inglesa Critical Path Method. que, como el PERT, también utiliza una red de tareas del proyecto. inglesa Critical Path Method.

A menudo, los dos métodos se pueden tratar conjuntamente, tal como hare- A menudo, los dos métodos se pueden tratar conjuntamente, tal como hare-
mos en esta exposición simplificada. mos en esta exposición simplificada.

Conviene advertir que, aunque aquí se habla de tareas o actividades indis- Podéis ver las herramientas Conviene advertir que, aunque aquí se habla de tareas o actividades indis- Podéis ver las herramientas
informatizadas para la planificación informatizadas para la planificación
tintamente, a menudo la nomenclatura más habitual utiliza el término ac- de un proyecto en el subapartado tintamente, a menudo la nomenclatura más habitual utiliza el término ac- de un proyecto en el subapartado
1.2 de este módulo didáctico. 1.2 de este módulo didáctico.
tividades cuando se refiere a PERT, aunque actualmente la elección suele 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- 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 mienta informática de la que nos ayudamos a la hora de llevar a cabo la
planificación de un proyecto. planificación de un proyecto.

El conjunto de las técnicas PERT y el método del camino crítico (CPM) propor- 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: cionan herramientas cuantitativas que permiten determinar lo siguiente:

1) El camino crítico del proyecto, que es la secuencia o cadena de activida- 1) El camino crítico del proyecto, que es la secuencia o cadena de activida-
des que determina la duración total del proyecto. des que determina la duración total del proyecto.

2) Las estimaciones de tiempos más probables, tanto para la totalidad del 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 proyecto como para el inicio y el final de cada una de las tareas o actividades
individuales. individuales.

3) Los márgenes de tiempo que se dan para cada tarea o actividad individual 3) Los márgenes de tiempo que se dan para cada tarea o actividad individual
y que no impliquen un retraso del proyecto. y que no impliquen un retraso del proyecto.

El diagrama PERT es un grafo de precedencias donde los nudos o nodos 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 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 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, las actividades que le son precedentes directos. El resto, en cierta manera,
surge casi automáticamente del mismo diagrama. surge casi automáticamente del mismo diagrama.

Pongamos un ejemplo, que es la manera más clara de verlo. Para no tener que 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- 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- mos efectuado una descomposición en diez actividades, como las que se indi-
can en la tabla siguiente: can en la tabla siguiente:

Actividades, duración y precedencias de un proyecto ficticio Actividades, duración y precedencias de un proyecto ficticio

Identificación Identificación
Nombre de la actividad Duración estimada Precedencias Nombre de la actividad Duración estimada Precedencias
numérica numérica

1 Inicio 0 - 1 Inicio 0 -

Establecer los Establecer los


2 3 1 2 3 1
requerimientos requerimientos

3 Seleccionar los drivers 2 1 3 Seleccionar los drivers 2 1


 FUOC • P03/7506/02143 9 La gestión de un proyecto informático  FUOC • P03/7506/02143 9 La gestión de un proyecto informático

Actividades, duración y precedencias de un proyecto ficticio Actividades, duración y precedencias de un proyecto ficticio

Identificación Identificación
Nombre de la actividad Duración estimada Precedencias Nombre de la actividad Duración estimada Precedencias
numérica numérica

4 Realizar el diseño 4 2 4 Realizar el diseño 4 2

5 Recoger datos 2 2y3 5 Recoger datos 2 2y3

6 Probar los drivers 6 3 6 Probar los drivers 6 3

7 Codificar 4 4 7 Codificar 4 4

8 Elaborar la documentación 2 4 8 Elaborar la documentación 2 4

9 Probar el producto 4 5, 6 y 7 9 Probar el producto 4 5, 6 y 7

10 Final 0 ? 10 Final 0 ?

Conviene, tal como se lleva a cabo aquí, incluir siempre las actividades de ini- Conviene, tal como se lleva a cabo aquí, incluir siempre las actividades de ini-
cio y final, puramente ficticias y con duración cero. cio y final, puramente ficticias y con duración cero.

La tabla nos ofrece para cada actividad un nombre, una identificación nu- 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 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 arbitrarias; por ejemplo, en semanas) y las tareas que son inmediatamente
anteriores e imprescindibles para poder empezar cada actividad en concre- anteriores e imprescindibles para poder empezar cada actividad en concre-
to (precedencias). to (precedencias).

Si se quiere, se puede imaginar que se trata de construir un sistema informáti- 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) 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 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 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 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. ejemplo ficticio para ilustrar el PERT y el CPM.

Si se dispone de estos datos (actividades, duración estimada y precedencias) se 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. 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- 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- 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 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 identificador, el nombre de la actividad y la duración estimada (puesta entre
paréntesis dentro del nudo). paréntesis dentro del nudo).

Sobre cada nudo se ha añadido también la información que sale directamente 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 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 de cada actividad. Conviene darse cuenta de que la actividad final tiene como
precedentes todos los arcos pendientes del diagrama. precedentes todos los arcos pendientes del diagrama.

Por ejemplo, la actividad 1 (inicio) empieza en la semana cero y, al tener una 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- 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- 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 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) precisamente tres semanas. Del mismo modo, la actividad 4 (realizar el diseño)
 FUOC • P03/7506/02143 10 La gestión de un proyecto informático  FUOC • P03/7506/02143 10 La gestión de un proyecto informático

no puede iniciarse hasta que no termine la precedente (la 2, establecer los re- 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 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 tres. Además, al durar cuatro semanas, no finalizará hasta el final de la semana
siete. Y así sucesivamente. siete. Y así sucesivamente.

En el caso de la actividad 9 (probar el producto) se dan tres precedentes direc- 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- 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 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 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 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- 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. 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 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 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 método del camino crítico, nos permite saber algo de gran importancia para
el futuro de la gestión del proyecto. el futuro de la gestión del proyecto.
Las actividades críticas... Las actividades críticas...

Una observación sencilla del diagrama nos muestra que las actividades 1 (ini- ... son las que forman el cami- Una observación sencilla del diagrama nos muestra que las actividades 1 (ini- ... son las que forman el cami-
no crítico y no tienen ningún no crítico y no tienen ningún
cio), 2 (establecer los requerimientos), 4 (realizar el diseño), 7 (codificar), 9 margen. Cualquier desviación cio), 2 (establecer los requerimientos), 4 (realizar el diseño), 7 (codificar), 9 margen. Cualquier desviación
(probar el producto) y 10 (final) no tienen ningún margen. Es decir, si alguna en la duración de estas activi- (probar el producto) y 10 (final) no tienen ningún margen. Es decir, si alguna en la duración de estas activi-
dades se traduce en una dades se traduce en una
de estas actividades tardara más de lo que se ha estimado, todo el proyecto se desviación en la duración de estas actividades tardara más de lo que se ha estimado, todo el proyecto se desviación en la duración
del proyecto. del proyecto.
alargaría más de las quince semanas previstas. alargaría más de las quince semanas previstas.
 FUOC • P03/7506/02143 11 La gestión de un proyecto informático  FUOC • P03/7506/02143 11 La gestión de un proyecto informático

Las actividades que no tienen ningún margen forman lo que se denomi- 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 na camino crítico y, en definitiva, son las que determinan la duración
final del proyecto. A menudo estas actividades se llaman actividades final del proyecto. A menudo estas actividades se llaman actividades
críticas. críticas.

En el diagrama, el camino crítico está marcado por flechas continuas. 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 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 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 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 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 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- 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 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 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 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. (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 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 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- 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 ma, tiene un margen de tres semanas (podría empezar más tarde o durar más
de lo que se había estimado). de lo que se había estimado).

Con vistas a la gestión de un proyecto es muy importante saber qué activida- 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 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- 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- 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 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. estricto de las actividades que forman parte del camino crítico.

La técnica del PERT con la determinación del camino crítico es un sistema 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- 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- 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. lizar las que no lo son para disponer de los recursos con más agilidad.

Para cada actividad... Para cada actividad...


Evidentemente, las cosas son más complicadas en el caso de proyectos con 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 ... se puede establecer una muchas más actividades. Pero, afortunadamente, en estos proyectos es fácil ... se puede establecer una
planificación de tipo: planificación de tipo:
poder disponer de una herramienta informatizada que, de manera automá- • ASAP, del inglés as soon
poder disponer de una herramienta informatizada que, de manera automá- • ASAP, del inglés as soon
tica, nos da el camino crítico y con todas las ventajas que esto representa. as posible, tan pronto tica, nos da el camino crítico y con todas las ventajas que esto representa. as posible, tan pronto
como sea posible. como sea posible.
• ALAP, del inglés as last • ALAP, del inglés as last
Cabe mencionar que en este ejemplo se ha utilizado lo que se llama una pla- • as posible, tan tarde como Cabe mencionar que en este ejemplo se ha utilizado lo que se llama una pla- • as posible, tan tarde como
sea posible. sea posible.
nificación ASAP, que sitúa cada actividad lo antes posible y es el procedi- nificación ASAP, que sitúa cada actividad lo antes posible y es el procedi-
 FUOC • P03/7506/02143 12 La gestión de un proyecto informático  FUOC • P03/7506/02143 12 La gestión de un proyecto informático

miento habitual cuando se parte de la fecha de inicio del proyecto y se quiere 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 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 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 proceso contrario, a partir de la fecha de fin del proyecto, hecho que se conoce
como una planificación ALAP. como una planificación ALAP.

1.2. Herramientas informatizadas para la planificación 1.2. Herramientas informatizadas para la planificación

Cuando se habla de herramientas informatizadas para la planificación, ya no se trata, 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 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 son muy caras* y que sólo se utilizan para la estimación de costes en proyectos
* El SLIM, por ejemplo. * El SLIM, por ejemplo.
informáticos. Ya hemos mencionado que la parte de la planificación temporal de 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 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- 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 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. asequible y su uso se convierta en muy habitual.

El problema que se plantea a menudo es decidir cuál de las muchas herramien- Podéis ver el subapartado 2.2 El problema que se plantea a menudo es decidir cuál de las muchas herramien- Podéis ver el subapartado 2.2
de este módulo didáctico. de este módulo didáctico.
tas disponibles en el mercado se debe escoger. Pero se trata de un problema 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 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, 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- 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 cionalidades que en general no se utilizan. Lo mismo ocurre, por ejemplo, con
los procesadores de textos o las hojas de cálculo. los procesadores de textos o las hojas de cálculo.

Dicho de otra manera, todas las herramientas disponibles en el mercado Dicho de otra manera, todas las herramientas disponibles en el mercado
tienen, además de complementos más o menos interesantes, los ele- tienen, además de complementos más o menos interesantes, los ele-
mentos mínimos para efectuar una buena planificación temporal de un 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 proyecto. El problema, a menudo, es cómo librarse de todo aquello que
la herramienta informática ofrece y que no vamos a utilizar. la herramienta informática ofrece y que no vamos a utilizar.

Ahora bien, actualmente, para la planificación de proyectos, las herramientas 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- 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. 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 Elegir una de las dos herramientas es en cierta manera inútil. Cuando una de
El autor de este módulo... El autor de este módulo...
las herramientas ofrece una funcionalidad nueva no disponible en la otra, sólo 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- ... por ejemplo, ha escrito se debe esperar unos meses y la nueva versión de esta otra herramienta incor- ... por ejemplo, ha escrito
el texto original con el Word el texto original con el Word
porará también la misma funcionalidad. Además, cabe recordar que la mayo- 4.0 de Microsoft para DOS, porará también la misma funcionalidad. Además, cabe recordar que la mayo- 4.0 de Microsoft para DOS,
que data de 1987: para teclear que data de 1987: para teclear
ría de estas funcionalidades no siempre se utilizan. Como ocurre con los es suficiente con ello. ría de estas funcionalidades no siempre se utilizan. Como ocurre con los es suficiente con ello.
procesadores de texto, a menudo es mejor lo que se utiliza desde hace más 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. 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ó- 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 dulo se presentan en MS-PROJECT es únicamente porque esta herramienta ha
 FUOC • P03/7506/02143 13 La gestión de un proyecto informático  FUOC • P03/7506/02143 13 La gestión de un proyecto informático

estado disponible, pero no porque exista alguna preferencia que se pueda ge- estado disponible, pero no porque exista alguna preferencia que se pueda ge-
neralizar a otros usuarios. neralizar a otros usuarios.

Lo que importa de las herramientas informatizadas para la ayuda a la pla- 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 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 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 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 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- incluso realizar una presentación brillante y muy profesional de la planifi-
cación de un proyecto. cación de un proyecto.

1.3. La planificación de un proyecto informático 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 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. suele utilizar una especie de diagrama temporal llamado diagrama de Gantt.

El diagrama de Gantt es un diagrama sencillo que muestra el tiempo 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 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. encuentran todas y cada una de las actividades que forman el proyecto.
En la parte izquierda se escribe el nombre de las actividades, mientras 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 que en la parte derecha se marca una línea desde la fecha inicial hasta
la fecha final de cada actividad. la fecha final de cada actividad.

En el caso del proyecto ficticio que se ha utilizado para exponer el PERT y el Podéis ver el proyecto ficticio En el caso del proyecto ficticio que se ha utilizado para exponer el PERT y el Podéis ver el proyecto ficticio
propuesto en el subapartado 1.1 propuesto en el subapartado 1.1
CPM, el diagrama de Gantt sería el que se muestra en la figura siguiente: de este módulo didáctico. CPM, el diagrama de Gantt sería el que se muestra en la figura siguiente: de este módulo didáctico.
 FUOC • P03/7506/02143 14 La gestión de un proyecto informático  FUOC • P03/7506/02143 14 La gestión de un proyecto informático

En realidad, la mayoría de herramientas informatizadas de ayuda a la planifi- En realidad, la mayoría de herramientas informatizadas de ayuda a la planifi-
Podéis ver la WBS en el subapartado Podéis ver la WBS en el subapartado
cación utilizan el diagrama de Gantt como marco de referencia para introducir 2.2 del módulo “Estimación cación utilizan el diagrama de Gantt como marco de referencia para introducir 2.2 del módulo “Estimación
de costes de un proyecto informático” de costes de un proyecto informático”
los datos de las diferentes tareas o actividades que forman la WBS del proyecto. de esta asignatura. los datos de las diferentes tareas o actividades que forman la WBS del proyecto. de esta asignatura.

Previamente, sin embargo, debe establecerse el calendario del proyecto para Previamente, sin embargo, debe establecerse el calendario del proyecto para
marcar las fechas que no son laborables o cualquier incidencia laboral. Las he- Las ayudas típicas... marcar las fechas que no son laborables o cualquier incidencia laboral. Las he- Las ayudas típicas...
rramientas informatizadas ofrecen también diagramas basados en el calenda- rramientas informatizadas ofrecen también diagramas basados en el calenda-
... que ofrecen las herramientas ... que ofrecen las herramientas
rio para marcar los días de inicio y final de cada tarea, aunque el diagrama de informatizadas de planificación rio para marcar los días de inicio y final de cada tarea, aunque el diagrama de informatizadas de planificación
y seguimiento de proyectos son y seguimiento de proyectos son
Gantt es suficientemente completo en este aspecto. los diagramas PERT, los de Gantt Gantt es suficientemente completo en este aspecto. los diagramas PERT, los de Gantt
y los de calendario. y los de calendario.

El resumen de lo que se debe llevar a cabo para planificar un proyecto en el El resumen de lo que se debe llevar a cabo para planificar un proyecto en el
tiempo es el siguiente: tiempo es el siguiente:

1) Establecer el calendario de días laborables de todo el proyecto y, si es nece- 1) Establecer el calendario de días laborables de todo el proyecto y, si es nece-
sario, de cada persona del equipo (recurso). sario, de cada persona del equipo (recurso).

2) Establecer la descomposición del proyecto en tareas (WBS). 2) Establecer la descomposición del proyecto en tareas (WBS).

3) Estimar la duración (o esfuerzo) de cada tarea o actividad. 3) Estimar la duración (o esfuerzo) de cada tarea o actividad.

4) Establecer las precedencias entre las tareas. Podéis ver el subapartad 1.3.1 4) Establecer las precedencias entre las tareas. Podéis ver el subapartad 1.3.1
de este módulo didáctico. de este módulo didáctico.

5) Realizar el diagrama de Gantt o PERT (red de actividades), preferentemente 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. 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 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 Inicio y Final, de duración nula, conviene añadir siempre algunas
actividades ficticias con duración nula como hitos de control para establecer 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 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- 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- 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 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. dos semanas, uno cada mes, etc., según la duración total del proyecto.

1.3.1. La consideración de los recursos: añadir nuevas 1.3.1. La consideración de los recursos: añadir nuevas
precedencias precedencias

Conviene señalar que a la hora de establecer precedencias, las hay que son ló- Conviene señalar que a la hora de establecer precedencias, las hay que son ló-
Ejemplo de precedencia Ejemplo de precedencia
gicas y las hay que surgen, en el caso concreto de los proyectos informáticos, lógica gicas y las hay que surgen, en el caso concreto de los proyectos informáticos, lógica

de la gestión de los recursos. Un caso sencillo de preceden- de la gestión de los recursos. Un caso sencillo de preceden-
cia lógica es que no se puede cia lógica es que no se puede
codificar un programa si su codificar un programa si su
Por ejemplo, en el diagrama de Gantt de la figura anterior hemos imaginado que cuaderno de cargas no se Por ejemplo, en el diagrama de Gantt de la figura anterior hemos imaginado que cuaderno de cargas no se
ha finalizado. ha finalizado.
es posible efectuar simultáneamente las tareas 2 (establecer los requerimientos) y 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- 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- 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. séis horas y no de ocho como es habitual. No parece, pues, posible.
 FUOC • P03/7506/02143 15 La gestión de un proyecto informático  FUOC • P03/7506/02143 15 La gestión de un proyecto informático

Por ello, en la planificación temporal de proyectos informáticos, ade- 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 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. provienen de la consideración de los recursos y de su utilización.

En el caso de los proyectos informáticos de construcción de software, los recursos 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- 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 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. 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- 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: 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- 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). 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- 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- cionar los drivers) y 6 (probar los drivers) y, tal vez, participar también en la ac-
tividad 9 (probar el producto). tividad 9 (probar el producto).

3) Para no tener problemas de jornada doble, una tercera persona del equipo 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- debería encargarse de las actividades 5 (recoger datos) y 8 (elaborar la docu-
mentación). mentación).

La figura siguiente muestra una modificación sencilla en el caso de que el equi- 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- po del proyecto estuviera formado por dos miembros. Para evitar jornadas do-
bles de los miembros del equipo, se han tenido que introducir nuevas 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- 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- 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. penda de la 5 (recoger datos), para conseguir que las realice la misma persona.

Actividades con precedencias adicionales para evitar jornadas dobles Actividades con precedencias adicionales para evitar jornadas dobles

Identificación Duración Identificación Duración


Nombre de la actividad Precedencias Nombre de la actividad Precedencias
numérica estimada numérica estimada

1 Inicio 0 - - 1 Inicio 0 - -

Establecer los Establecer los


2 3 1 A 2 3 1 A
requerimientos requerimientos

3 Seleccionar los drivers 2 1 B 3 Seleccionar los drivers 2 1 B

4 Realizar el diseño 4 2 A 4 Realizar el diseño 4 2 A

5 Recoger datos 2 2, 3 y 6 B 5 Recoger datos 2 2, 3 y 6 B

6 Probar los drivers 6 3 B 6 Probar los drivers 6 3 B

7 Codificar 4 4 A 7 Codificar 4 4 A

8 Elaborar la documentación 2 4y5 B 8 Elaborar la documentación 2 4y5 B

9 Probar el producto 4 5, 6 y 7 A 9 Probar el producto 4 5, 6 y 7 A

10 Final 0 - - 10 Final 0 - -
 FUOC • P03/7506/02143 16 La gestión de un proyecto informático  FUOC • P03/7506/02143 16 La gestión de un proyecto informático

La tabla muestra, en negrita, las precedencias adicionales introducidas para La tabla muestra, en negrita, las precedencias adicionales introducidas para
evitar la jornada doble de un miembro del equipo. También indica el recurso evitar la jornada doble de un miembro del equipo. También indica el recurso
(la persona miembro del equipo) que realizará cada actividad. (la persona miembro del equipo) que realizará cada actividad.

Cabe decir que, aunque en este ejemplo no ha ocurrido, estas precedencias 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 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 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- los recursos disponibles (teniendo en cuenta el coste) y las precedencias de ac-
tividades hasta que se encuentra un resultado aceptable. tividades hasta que se encuentra un resultado aceptable.

Una vez terminada la planificación, finaliza la calificación y ya se dispone 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- 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 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 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 profesionales que forman parte del equipo del proyecto y del número de
horas de trabajo que les han sido asignadas. horas de trabajo que les han sido asignadas.
 FUOC • P03/7506/02143 17 La gestión de un proyecto informático  FUOC • P03/7506/02143 17 La gestión de un proyecto informático

2. Seguimiento y control de un proyecto informático 2. Seguimiento y control de un proyecto informático

Una vez iniciado el proyecto informático, la tarea de gestión consiste en conseguir 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- 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 tes posible las desviaciones que se deben producir para poder encontrarles una
solución. solución.

El objetivo del seguimiento y el control del proyecto informático es 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- conseguir que no falle y, además, que se desarrolle según la planifica-
ción fijada previamente. ción fijada previamente.

Para conseguir todo esto, es imprescindible comparar periódicamente la reali- 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 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 cualquiera de las nuevas previsiones que se hayan debido realizar al detectar
errores en la estimación o la planificación iniciales. errores en la estimación o la planificación iniciales.

El objetivo declarado del proyecto es alcanzar unas funcionalidades en unos El objetivo declarado del proyecto es alcanzar unas funcionalidades en unos
plazos determinados y habiéndolas presupuestado. La actividad de seguimien- plazos determinados y habiéndolas presupuestado. La actividad de seguimien-
to y control del proyecto debe conseguir detectar los problemas con la máxi- 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, ma antelación posible para poder reajustar la estimación y la planificación y,
en definitiva, cambiar el proyecto modificando los objetivos. en definitiva, cambiar el proyecto modificando los objetivos.

La importancia del seguimiento del proyecto informático radica, pues, La importancia del seguimiento del proyecto informático radica, pues,
en el hecho de poder anticipar los problemas. en el hecho de poder anticipar los problemas.

El seguimiento pretende una anticipación, no una constatación 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- 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- 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 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 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 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 este tipo se pueden tomar las decisiones adecuadas para tratar de salvar las previsiones
del proyecto. del proyecto.

En los hitos de control introducidos en la planificación (bien sea al final de 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 fases o etapas de proyecto, o bien de manera periódica) es cuando debemos
plantearnos, entre otras cosas, lo siguiente: plantearnos, entre otras cosas, lo siguiente:

• Si conviene rehacer la descomposición del proyecto en tareas (WBS) o no, • 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- posiblemente con la intención de incluir algunas no previstas en el mo-
mento inicial, pero que son totalmente necesarias e imprescindibles a me- mento inicial, pero que son totalmente necesarias e imprescindibles a me-
dida que avanza el proyecto. dida que avanza el proyecto.
 FUOC • P03/7506/02143 18 La gestión de un proyecto informático  FUOC • P03/7506/02143 18 La gestión de un proyecto informático

• Si conviene volver a efectuar la estimación del esfuerzo o no, en caso de que • 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. 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 • Si conviene cambiar algunos de los objetivos del proyecto o no, para tratar
de mantener los otros. de mantener los otros.

• Si conviene llevar a cabo una nueva calificación del proyecto o no, para te- • 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 ner en cuenta los datos de nuevas tareas o de una productividad diferente
de la prevista que la realidad nos aporte. de la prevista que la realidad nos aporte.

Como se dice en otro módulo, los problemas de una deficiente calificación ini- Podéis ver los problemas de Como se dice en otro módulo, los problemas de una deficiente calificación ini- Podéis ver los problemas de
una deficiente calificación en el una deficiente calificación en el
cial se intentan “resolver” demasiadas veces de puertas afuera, haciendo todo subapartado 1.1 del módulo “El
proyecto informático de construcción
cial se intentan “resolver” demasiadas veces de puertas afuera, haciendo todo subapartado 1.1 del módulo “El
proyecto informático de construcción
de software”. de software”.
lo posible para cumplir con los plazos y el presupuesto a fuerza de reducir las 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 funcionalidades del proyecto, sobre todo las funcionalidades de calidad. Ésta
es, evidentemente, una solución totalmente falsa que simplemente aplaza los es, evidentemente, una solución totalmente falsa que simplemente aplaza los
problemas hasta la fase de mantenimiento, al mismo tiempo que consigue a 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 menudo que los problemas se conviertan en mucho más graves y que tengan
una solución mucho más difícil. una solución mucho más difícil.

2.1. Las hojas de actividad y el informe de situación 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- 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 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- 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 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 y, en definitiva, controlar el desarrollo. La práctica habitual es recoger estos
datos del seguimiento en unas hojas de actividad. datos del seguimiento en unas hojas de actividad.

La hoja de actividad es el conjunto de datos individuales de segui- La hoja de actividad es el conjunto de datos individuales de segui-
miento de un proyecto, donde cada miembro del equipo señala las 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 horas que ha ocupado en cada una de las tareas previstas de la WBS
que se le han asignado. que se le han asignado.

Conviene recoger de manera individual por cada tarea y cada persona involu- Conviene recoger de manera individual por cada tarea y cada persona involu-
* Si conviene, ayudado de un * Si conviene, ayudado de un
crada estos datos de seguimiento, a partir de los cuales el jefe de proyecto* sistema informático ad hoc. crada estos datos de seguimiento, a partir de los cuales el jefe de proyecto* sistema informático ad hoc.

debe elaborar los datos globales que permiten construir un informe de situa- 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 ción del proyecto. Este informe se suele llevar a cabo para cada uno de los hitos
de control establecidos. de control establecidos.

Un informe de situación es el resumen de la realidad de un proyecto a 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- partir de los datos obtenidos de las hojas de actividad y de su compara-
ción con la planificación vigente. ción con la planificación vigente.
 FUOC • P03/7506/02143 19 La gestión de un proyecto informático  FUOC • P03/7506/02143 19 La gestión de un proyecto informático

Cuando una tarea finaliza, el jefe de proyecto puede saber el esfuerzo real que 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 ha supuesto realizarla y lo puede comparar con el esfuerzo previsto, para ver
si las estimaciones de productividad eran optimistas, pesimistas o realistas. El si las estimaciones de productividad eran optimistas, pesimistas o realistas. El
hecho de disponer de esta productividad real es precisamente lo que debe per- hecho de disponer de esta productividad real es precisamente lo que debe per-
mitir anticipar los problemas. mitir anticipar los problemas.

Con los datos reales obtenidos de la hoja de actividad, el jefe de proyecto rea- Con los datos reales obtenidos de la hoja de actividad, el jefe de proyecto rea-
* Como MS-PROJECT * Como MS-PROJECT
liza el seguimiento, a menudo mediante herramientas informatizadas* que o SUPERPROJECT. liza el seguimiento, a menudo mediante herramientas informatizadas* que o SUPERPROJECT.

permiten, para cada actividad del proyecto, introducir las fechas reales del tra- 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- 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 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 escogidos los que son útiles, ayudan a las tareas de seguimiento y control del
proyecto. proyecto.

2.2. La ley de Brooks 2.2. La ley de Brooks

Aunque ya se trata detenidamente en otros módulos, conviene recordar aquí Podéis ver los módulos “El proyecto Aunque ya se trata detenidamente en otros módulos, conviene recordar aquí Podéis ver los módulos “El proyecto
informático de construcción de informático de construcción de
lo que se ha denominado ley de Brooks, una teoría que proviene de la experien- software” y “Estimación de costes lo que se ha denominado ley de Brooks, una teoría que proviene de la experien- software” y “Estimación de costes
de un proyecto informático” de esta de un proyecto informático” de esta
asignatura. En concreto, podéis ver el asignatura. En concreto, podéis ver el
cia del autor de la obra The Mythical Man-Month (1975) como director del pro- mito del hombre-mes en el subapartado cia del autor de la obra The Mythical Man-Month (1975) como director del pro- mito del hombre-mes en el subapartado
1.3.2 de este último módulo. 1.3.2 de este último módulo.
ceso de construcción del sistema operativo de IBM 360. ceso de construcción del sistema operativo de IBM 360.

La ley de Brooks es una advertencia para no caer en el mito del hom- La ley de Brooks es una advertencia para no caer en el mito del hom-
Lectura recomendada Lectura recomendada
bre-mes, que a menudo tiene formulaciones tan sorprendentes como bre-mes, que a menudo tiene formulaciones tan sorprendentes como
La referencia siguiente os La referencia siguiente os
ésta: si un proyecto va retrasado, el hecho de añadir personal es la ma- permitirá encontrar la obra ésta: si un proyecto va retrasado, el hecho de añadir personal es la ma- permitirá encontrar la obra
mencionada en el texto sobre mencionada en el texto sobre
nera más segura de retrasarlo todavía más. nera más segura de retrasarlo todavía más.
el mito del hombre-mes: el mito del hombre-mes:
F. Brooks (1975). The F. Brooks (1975). The
mythical man-month. mythical man-month.
Reading: Addison-Wesley. Reading: Addison-Wesley.
Es necesario entender esta advertencia en el sentido de que no se pueden inter- 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 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 matemático, sino sólo una advertencia para los que todavía no han captado el
mito del hombre-mes. mito del hombre-mes.

En cualquier proyecto (pensemos, por ejemplo, en la construcción de una ca- 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 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 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). caso de la construcción de una casa).

La ley de Brooks que acabamos de ver nos advierte de que no sucede lo mismo 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 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 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- 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 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 Podéis ver la curva de Rayleigh/ proyecto informático que iba retrasado, el hecho de añadir personal creó más Podéis ver la curva de Rayleigh/
Norden en el subapartado 2.3.3 del Norden en el subapartado 2.3.3 del
problemas de los que resolvió, aunque, evidentemente, esto no debe ocurrir módulo “Estimación de costes
de un proyecto informático” de
problemas de los que resolvió, aunque, evidentemente, esto no debe ocurrir módulo “Estimación de costes
de un proyecto informático” de
esta asignatura. esta asignatura.
siempre. siempre.
 FUOC • P03/7506/02143 20 La gestión de un proyecto informático  FUOC • P03/7506/02143 20 La gestión de un proyecto informático

La explicación tradicional del fenómeno es que en un proyecto informático se 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- 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 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 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 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- 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- 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, 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- 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 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 necesidades adicionales de comunicación pueden provocar incluso que con
más personas se tarde más tiempo. más personas se tarde más tiempo.
 FUOC • P03/7506/02143 21 La gestión de un proyecto informático  FUOC • P03/7506/02143 21 La gestión de un proyecto informático

3. Aseguramiento de la calidad en un proyecto 3. Aseguramiento de la calidad en un proyecto


informático informático

Desgraciadamente, tal como comentamos en otro módulo, la calidad del soft- Podéis ver el módulo “El proyecto Desgraciadamente, tal como comentamos en otro módulo, la calidad del soft- Podéis ver el módulo “El proyecto
informático de construcción de informático de construcción de
ware construido no es siempre la deseable. Hemos visto algunas de las razones software” de esta asignatura. ware construido no es siempre la deseable. Hemos visto algunas de las razones software” de esta asignatura.

que pueden ser la causa, aun así debemos evitar que ello ocurra. 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í- Han transcurrido ya un par de décadas desde que se comenzó a hablar explí-
citamente de aseguramiento de la calidad del software. citamente de aseguramiento de la calidad del software.

Terminología confusa Terminología confusa

Con respecto al término aseguramiento de la calidad del software (software quality assuran- 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- 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, 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 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). vende y que, como tal, puede tener una garantía).

El aseguramiento de la calidad del software es, según AENOR –la entidad 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- española de normalización–, el conjunto de actividades planificadas y sis-
temáticas necesarias para aportar la confianza de que el producto (software) temáticas necesarias para aportar la confianza de que el producto (software)
cumplirá los requerimientos de calidad establecidos. cumplirá los requerimientos de calidad establecidos.

Ya en 1977, Mc Call estableció algunos factores para analizar la calidad del Ya en 1977, Mc Call estableció algunos factores para analizar la calidad del
software * y, desde entonces, el procedimiento habitual ha sido elaborar listas * En inglés, software quality factors. software * y, desde entonces, el procedimiento habitual ha sido elaborar listas * En inglés, software quality factors.
** En inglés, check list. ** En inglés, check list.
de control** complejas y detalladas para revisar todo el proceso de construc- de control** complejas y detalladas para revisar todo el proceso de construc-
ción del software. ción del software.

Actualmente, el aseguramiento de calidad de software consiste en introducir Actualmente, el aseguramiento de calidad de software consiste en introducir
Tasa cero de errores Tasa cero de errores
unos procedimientos y unas metodologías de construcción que tratan de ga- 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 En cuanto a la obtención de rantizar, a priori, que el proceso es correcto y seguro, y que el mismo proceso En cuanto a la obtención de
software de la mejor calidad, se software de la mejor calidad, se
de construcción pueda garantizar también, en cierta manera, que el producto ha llegado a hablar, incluso, de de construcción pueda garantizar también, en cierta manera, que el producto ha llegado a hablar, incluso, de
procesos de construcción que procesos de construcción que
que se obtiene es un software de la mejor calidad. alcanzarían una tasa cero que se obtiene es un software de la mejor calidad. alcanzarían una tasa cero
de errores. de errores.

En general, la calidad del software necesita que exista un acuerdo total entre En general, la calidad del software necesita que exista un acuerdo total entre
los requerimientos (tanto funcionales como de rendimiento) y el software fi- los requerimientos (tanto funcionales como de rendimiento) y el software fi-
nal. Esto implica la utilización de estándares de desarrollo documentados ex- 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 plícitamente y de procedimientos concretos de gestión de todo el proceso de
construcción de software. construcción de software.

La calidad del software es, según el IIEE (Instituto de Ingenieros Eléc- 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- tricos y Electrónicos), el grado en el que un sistema, componente o pro-
ceso cumple con los requerimientos especificados y con las necesidades ceso cumple con los requerimientos especificados y con las necesidades
o expectativas del cliente o usuario. o expectativas del cliente o usuario.
 FUOC • P03/7506/02143 22 La gestión de un proyecto informático  FUOC • P03/7506/02143 22 La gestión de un proyecto informático

El tratamiento del aseguramiento de la calidad se centra tradicionalmente en El tratamiento del aseguramiento de la calidad se centra tradicionalmente en
las inspecciones y revisiones formales, junto con las llamadas reuniones de re- las inspecciones y revisiones formales, junto con las llamadas reuniones de re-
paso*. Uno de los objetivos fundamentales es, evidentemente, obtener la ca- paso*. Uno de los objetivos fundamentales es, evidentemente, obtener la ca-
* En inglés, walkthroughs. * En inglés, walkthroughs.
racterística implícita de la fiabilidad y, sobre todo, un mantenimiento fácil del 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- producto obtenido, teniendo en cuenta la larga duración de la etapa de man-
tenimiento en el ciclo de vida del software. tenimiento en el ciclo de vida del software.

En general, un sistema de aseguramiento de la calidad del software En general, un sistema de aseguramiento de la calidad del software
incluye una estructura organizativa que implica establecer responsabi- incluye una estructura organizativa que implica establecer responsabi-
lidades, procedimientos y procesos de construcción y revisión, y tam- lidades, procedimientos y procesos de construcción y revisión, y tam-
bién garantizar la disponibilidad de los recursos de todo tipo necesarios 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. para efectuar una gestión de calidad que ofrezca un software de calidad.

La ISO* es la organización internacional encargada de crear todo tipo de es- La ISO* es la organización internacional encargada de crear todo tipo de es-
* International Organization * International Organization
tándares. En concreto, los estándares de calidad forman parte de la norma for Standarization. tándares. En concreto, los estándares de calidad forman parte de la norma for Standarization.

ISO 9000, que describe los elementos que debe tener un sistema de asegu- 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- ramiento de la calidad con el fin de que se puedan aplicar a cualquier ne-
gocio o actividad. gocio o actividad.

La ISO 9001 es el estándar de aseguramiento de la calidad que se aplica a la Lectura recomendada La ISO 9001 es el estándar de aseguramiento de la calidad que se aplica a la Lectura recomendada

ingeniería del software y expone hasta veinte exigencias que debe cumplir un Para más detalles, podéis ingeniería del software y expone hasta veinte exigencias que debe cumplir un Para más detalles, podéis
consultar la obra siguiente: consultar la obra siguiente:
buen sistema de calidad. Recientemente, la nueva versión de la norma ISO buen sistema de calidad. Recientemente, la nueva versión de la norma ISO
R. Kehoe; A. Jarvis (1996). R. Kehoe; A. Jarvis (1996).
9000-3, que data de 1996, quiere proporcionar una guía y una ayuda con vis- ISO 9000-3: A Tool for 9000-3, que data de 1996, quiere proporcionar una guía y una ayuda con vis- ISO 9000-3: A Tool for
Software Product and Software Product and
tas a la aplicación de las exigencias de la ISO 9001 en el caso de una industria Process Improvement. tas a la aplicación de las exigencias de la ISO 9001 en el caso de una industria Process Improvement.
Nueva York: Springer. Nueva York: Springer.
de fabricación y/o venta de software. de fabricación y/o venta de software.
 FUOC • P03/7506/02143 23 La gestión de un proyecto informático  FUOC • P03/7506/02143 23 La gestión de un proyecto informático

Resumen Resumen

La planificación temporal de un proyecto informático arranca de la des- 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 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- 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 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- 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. 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, 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 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 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. 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- 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- guimiento de proyectos ofrecen diferentes diagramas (de Gantt, PERT, de ca-
lendario, etc.) y una variedad amplia de listas. lendario, etc.) y una variedad amplia de listas.

El seguimiento y el control del proyecto se realizan comparando los datos 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 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- 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 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 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- 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. visar los objetivos: las funcionalidades, los plazos y el presupuesto.

La ley de Brooks intenta evitar la incomprensión sobre el mito del hombre- 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 mes y afirma que añadir más personal a un proyecto retrasado no siempre
mejora las cosas. mejora las cosas.

El aseguramiento de la calidad del software es el conjunto de actividades de 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 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 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 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 calidad en el campo de la ingeniería del software, en concreto la ISO 9001 y
la ISO 9000-3. la ISO 9000-3.
 FUOC • P03/7506/02143 La gestión de un proyecto informático  FUOC • P03/7506/02143 La gestión de un proyecto informático
 FUOC • P03/7506/02143 25 La gestión de un proyecto informático  FUOC • P03/7506/02143 25 La gestión de un proyecto informático

Actividades Actividades
1. Si podéis disponer de una herramienta de planificación y seguimiento de proyectos como Podéis ver el proyecto ficticio 1. Si podéis disponer de una herramienta de planificación y seguimiento de proyectos como Podéis ver el proyecto ficticio
el MS-PROJECT, el SUPERPROJECT u otros, estudiad sus funcionalidades mediante el sis- expuesto en el subapartado 1.1 de el MS-PROJECT, el SUPERPROJECT u otros, estudiad sus funcionalidades mediante el sis- expuesto en el subapartado 1.1 de
este módulo didáctico. este módulo didáctico.
tema de ayuda (help) y comprobad los listados que se encuentran disponibles. Como ejer- 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 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 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. 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- Podéis ver el ejemplo del PC en el 2. Añadid las precedencias que os parezcan lógicas a los datos de actividades y el esfuerzo es- Podéis ver el ejemplo del PC en el
timado del caso de la contabilidad sencilla en un PC que hemos visto en otro módulo. subapartado 2.4.1 y los precios por timado del caso de la contabilidad sencilla en un PC que hemos visto en otro módulo. subapartado 2.4.1 y los precios por
hora de analista y programador en la hora de analista y programador en la
Imaginad un equipo de un analista (que también trabaja como jefe de proyecto) y un pro- actividad 3 del módulo “Estimación de Imaginad un equipo de un analista (que también trabaja como jefe de proyecto) y un pro- actividad 3 del módulo “Estimación de
costes de un proyecto informático” de costes de un proyecto informático” de
gramador, para obtener, con una herramienta como el MS-PROJECT o el SUPERPROJECT, esta asignatura. gramador, para obtener, con una herramienta como el MS-PROJECT o el SUPERPROJECT, esta asignatura.
el diagrama de Gantt y la red de actividades (diagrama PERT) del proyecto. Con los precios 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. 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- Podéis ver el ejemplo del PC en el 3. Intentad llevar a cabo una descomposición de tareas (WBS), una estimación de costes pa- Podéis ver el ejemplo del PC en el
recida a la del ejemplo de la contabilidad sencilla en un PC y una planificación en el tiem- subapartado 2.4.1 del módulo recida a la del ejemplo de la contabilidad sencilla en un PC y una planificación en el tiem- subapartado 2.4.1 del módulo
“Estimación de costes de un proyecto “Estimación de costes de un proyecto
po contando con un analista y un programador para el caso de la aplicación en un informático” de esta asignatura. po contando con un analista y un programador para el caso de la aplicación en un informático” de esta asignatura.
pequeño hotel. pequeño hotel.

Datos del hotel Datos del hotel

Se quiere implementar una pequeña aplicación (simplificada) de gestión administrativa de 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 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 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- 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 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 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 puede ser posterior a una reserva previa, realizada directamente por el cliente o mediante
una agencia de viajes. una agencia de viajes.

Las funciones que se deben implementar son, al menos, las siguientes: Las funciones que se deben implementar son, al menos, las siguientes:

1) Tratamientos interactivos 1) Tratamientos interactivos

a) Mantenimiento del fichero de habitaciones a) Mantenimiento del fichero de habitaciones

Se debe tener en cuenta que cada habitación tiene un precio normal, un precio de tempo- Se debe tener en cuenta que cada habitación tiene un precio normal, un precio de tempo-
rada alta y otro de temporada baja. rada alta y otro de temporada baja.

b)Gestión de reservas b)Gestión de reservas

Para dar de alta una reserva, hemos de introducir las fechas de la entrada y la salida y el 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- 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- 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 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 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). 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 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 reserva y de la fecha de reserva. Es evidente que en una reserva puede incluirse más de una
habitación. habitación.

c) Entrada de clientes c) Entrada de clientes

Los clientes pueden ocupar habitaciones ya reservadas o las que puedan encontrarse dis- 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- 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 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 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. 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 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 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- 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 cilio de todos los clientes, pero siempre se registrarán estos datos con respecto al titular de
la reserva. la reserva.
 FUOC • P03/7506/02143 26 La gestión de un proyecto informático  FUOC • P03/7506/02143 26 La gestión de un proyecto informático

d)Entrada de gastos adicionales d)Entrada de gastos adicionales

Los diferentes servicios del hotel se encargarán de introducir en sus terminales los gastos Los diferentes servicios del hotel se encargarán de introducir en sus terminales los gastos
(bar, restaurante, tintorería, teléfono, etc.) efectuados por el cliente y los cargarán en la (bar, restaurante, tintorería, teléfono, etc.) efectuados por el cliente y los cargarán en la
habitación correspondiente (la del titular de la reserva). Para registrar uno de estos cargos, habitación correspondiente (la del titular de la reserva). Para registrar uno de estos cargos,
se debe indicar, al menos, el código del tipo de cargo, el concepto del servicio, la fecha y se debe indicar, al menos, el código del tipo de cargo, el concepto del servicio, la fecha y
hora del servicio (opcional), el importe del servicio y la habitación que soporta el cargo hora del servicio (opcional), el importe del servicio y la habitación que soporta el cargo
(siempre la del titular de la reserva). (siempre la del titular de la reserva).

e)Salida de clientes e)Salida de clientes

La salida de clientes se efectuará a partir del número de habitación. Como resultado de esta La salida de clientes se efectuará a partir del número de habitación. Como resultado de esta
operación, la habitación quedará libre y el sistema ofrecerá la posibilidad de encadenar au- operación, la habitación quedará libre y el sistema ofrecerá la posibilidad de encadenar au-
tomáticamente la operación con el procedimiento de liquidación de la cuenta de una ha- tomáticamente la operación con el procedimiento de liquidación de la cuenta de una ha-
bitación. bitación.

f)Liquidación de la cuenta de una habitación f)Liquidación de la cuenta de una habitación

La facturación parcial de la cuenta de una habitación para un cliente directo se puede realizar La facturación parcial de la cuenta de una habitación para un cliente directo se puede realizar
siempre en cualquier momento (pago parcial). La liquidación final se efectúa, obligatoriamen- siempre en cualquier momento (pago parcial). La liquidación final se efectúa, obligatoriamen-
te, siempre que haya sido registrada la salida del cliente. Es necesario tener en cuenta que lo te, siempre que haya sido registrada la salida del cliente. Es necesario tener en cuenta que lo
más habitual es una factura única por reserva en el momento de la salida definitiva de los más habitual es una factura única por reserva en el momento de la salida definitiva de los
clientes. Pero debemos prever las situaciones lógicas que se puedan presentar. clientes. Pero debemos prever las situaciones lógicas que se puedan presentar.

Los clientes que hayan realizado reserva mediante una agencia sólo tendrán una factura Los clientes que hayan realizado reserva mediante una agencia sólo tendrán una factura
complementaria de liquidación de los gastos extraordinarios (bar, restaurante, tintorería, complementaria de liquidación de los gastos extraordinarios (bar, restaurante, tintorería,
teléfono, etc.) no cubiertos por las agencias. Las facturas de alojamiento y los gastos ordi- teléfono, etc.) no cubiertos por las agencias. Las facturas de alojamiento y los gastos ordi-
narios se presentarán semanalmente a las agencias para su liquidación. (Podéis ver la ca- narios se presentarán semanalmente a las agencias para su liquidación. (Podéis ver la ca-
dena semanal.) dena semanal.)

2) Tratamientos diferidos 2) Tratamientos diferidos

a) Cadena diaria a) Cadena diaria

• Anulación de reservas caducadas. Al final de cada día se cancelarán automáticamente • Anulación de reservas caducadas. Al final de cada día se cancelarán automáticamente
las reservas que debían haber comenzado durante el día y que no hayan sido anuladas las reservas que debían haber comenzado durante el día y que no hayan sido anuladas
ni modificadas. Se cancela la totalidad de la reserva (todos los días y todas las habitacio- ni modificadas. Se cancela la totalidad de la reserva (todos los días y todas las habitacio-
nes), pero debe guardarse la información sobre el coste que ello representa para las agen- nes), pero debe guardarse la información sobre el coste que ello representa para las agen-
cias. (Podéis ver la cadena semanal.) cias. (Podéis ver la cadena semanal.)

• Listado de ocupaciones. Diariamente se debe obtener un listado con los datos de los • Listado de ocupaciones. Diariamente se debe obtener un listado con los datos de los
clientes residentes cada noche en el hotel. (Se acuerda que sólo es obligatorio disponer clientes residentes cada noche en el hotel. (Se acuerda que sólo es obligatorio disponer
del nombre del titular de cada reserva.) del nombre del titular de cada reserva.)

b)Cadena semanal b)Cadena semanal

Facturación a las agencias. Al final de la semana se facturarán los cargos de alojamiento Facturación a las agencias. Al final de la semana se facturarán los cargos de alojamiento
de las ocupaciones que provienen de reservas realizadas mediante las agencias. La factura- de las ocupaciones que provienen de reservas realizadas mediante las agencias. La factura-
ción a las agencias tiene, con relación a los precios estándar, un porcentaje de descuento ción a las agencias tiene, con relación a los precios estándar, un porcentaje de descuento
(que puede ser diferente para cada agencia). Además, la factura semanal para cada agencia (que puede ser diferente para cada agencia). Además, la factura semanal para cada agencia
debe incluir el cargo por el primer día de las reservas caducadas sin haber estado ocupadas. debe incluir el cargo por el primer día de las reservas caducadas sin haber estado ocupadas.
El cargo es sólo un porcentaje del coste real de la estancia y este porcentaje se ha pactado El cargo es sólo un porcentaje del coste real de la estancia y este porcentaje se ha pactado
previa y separadamente con cada agencia. previa y separadamente con cada agencia.

c) Cadena mensual c) Cadena mensual

Estadísticas de ocupación. Cada mes se elabora un listado que informe del nivel de ocu- Estadísticas de ocupación. Cada mes se elabora un listado que informe del nivel de ocu-
pación de cada habitación y del hotel en general. pación de cada habitación y del hotel en general.

3) Volúmenes 3) Volúmenes

• Número de habitaciones: 400 (70 sencillas y 330 dobles). • Número de habitaciones: 400 (70 sencillas y 330 dobles).
• Número de agencias: 20. • Número de agencias: 20.
• Admisión de reservas con tres meses de antelación: • Admisión de reservas con tres meses de antelación:
– Media de reservas diarias: 15. – Media de reservas diarias: 15.
– Media de días de estancia de los clientes: 6. – Media de días de estancia de los clientes: 6.
– Media de cargos por servicios, por día y habitación: 5. – Media de cargos por servicios, por día y habitación: 5.
 FUOC • P03/7506/02143 27 La gestión de un proyecto informático  FUOC • P03/7506/02143 27 La gestión de un proyecto informático

Ejercicios de autoevaluación Ejercicios de autoevaluación


1. Los diagramas PERT, ¿son exclusivos de los proyectos informáticos? 1. Los diagramas PERT, ¿son exclusivos de los proyectos informáticos?

2. ¿Qué ocurre cuando una actividad que no forma parte del camino crítico tarda más de lo 2. ¿Qué ocurre cuando una actividad que no forma parte del camino crítico tarda más de lo
que se había estimado? que se había estimado?

3. ¿Qué precedencias debemos tener en cuenta para realizar el diagrama PERT? 3. ¿Qué precedencias debemos tener en cuenta para realizar el diagrama PERT?

4. ¿Cuándo se suele llevar a cabo una planificación ALAP (lo más tarde posible)? 4. ¿Cuándo se suele llevar a cabo una planificación ALAP (lo más tarde posible)?

5. ¿Quién es el responsable de los datos recogidos durante el seguimiento de un proyecto? 5. ¿Quién es el responsable de los datos recogidos durante el seguimiento de un proyecto?

6. ¿Cuándo se suele efectuar un informe de situación de un proyecto? 6. ¿Cuándo se suele efectuar un informe de situación de un proyecto?

7. La ley de Brooks, ¿es segura al cien por cien? 7. La ley de Brooks, ¿es segura al cien por cien?

8. ¿Por qué se debe asegurar la calidad del software? 8. ¿Por qué se debe asegurar la calidad del software?

9. ¿Cuándo se puede decir que un software es de calidad? 9. ¿Cuándo se puede decir que un software es de calidad?

10. ¿Cuáles son las normas ISO que afectan a la calidad del software? 10. ¿Cuáles son las normas ISO que afectan a la calidad del software?
 FUOC • P03/7506/02143 28 La gestión de un proyecto informático  FUOC • P03/7506/02143 28 La gestión de un proyecto informático

Solucionario Solucionario
Ejercicios de autoevaluación Ejercicios de autoevaluación

1. Los diagramas PERT no son exclusivos de los proyectos informáticos, sino que los inven- 1. Los diagramas PERT no son exclusivos de los proyectos informáticos, sino que los inven-
tó hace décadas la Marina norteamericana para cualquier tipo de proyectos. tó hace décadas la Marina norteamericana para cualquier tipo de proyectos.

2. Si el retraso de la actividad es inferior al margen, todo queda en un aumento del coste (el 2. Si el retraso de la actividad es inferior al margen, todo queda en un aumento del coste (el
personal que realiza el trabajo quiere cobrar los días de más), pero la duración global del pro- personal que realiza el trabajo quiere cobrar los días de más), pero la duración global del pro-
yecto no varía. Si el retraso es superior al margen, la duración global del proyecto cambia. yecto no varía. Si el retraso es superior al margen, la duración global del proyecto cambia.

3. Para efectuar el diagrama PERT es necesario tener en cuenta las precedencias que la lógica 3. Para efectuar el diagrama PERT es necesario tener en cuenta las precedencias que la lógica
dicta entre las diferentes actividades que forman la WBS del proyecto y, además, las que dicta entre las diferentes actividades que forman la WBS del proyecto y, además, las que
sean necesarias para garantizar que cada uno de los “recursos” del proyecto (los profesio- sean necesarias para garantizar que cada uno de los “recursos” del proyecto (los profesio-
nales del equipo del proyecto) sólo trabaje ocho horas al día. nales del equipo del proyecto) sólo trabaje ocho horas al día.

4. Existen muchos casos en los que se puede realizar una planificación ALAP, pero uno muy 4. Existen muchos casos en los que se puede realizar una planificación ALAP, pero uno muy
habitual es cuando se conoce la fecha en la que se debe terminar el proyecto y “se tira habitual es cuando se conoce la fecha en la que se debe terminar el proyecto y “se tira
hacia atrás” con el fin de ver cuándo debe iniciarse para estar a tiempo. hacia atrás” con el fin de ver cuándo debe iniciarse para estar a tiempo.

5. Aunque es el jefe de proyecto quien utiliza, procesa y agrega los datos, no debe olvidarse 5. Aunque es el jefe de proyecto quien utiliza, procesa y agrega los datos, no debe olvidarse
que es cada miembro del equipo quien se los proporciona y lo informa de las horas que que es cada miembro del equipo quien se los proporciona y lo informa de las horas que
ha dedicado en cada una de las tareas que le han sido asignadas. Todos los miembros del ha dedicado en cada una de las tareas que le han sido asignadas. Todos los miembros del
equipo son, pues, responsables. equipo son, pues, responsables.

6. El jefe de proyecto elabora los informes de situación y compara la planificación vigente 6. El jefe de proyecto elabora los informes de situación y compara la planificación vigente
con la información real obtenida al agregar los datos de detalle de las diferentes hojas de con la información real obtenida al agregar los datos de detalle de las diferentes hojas de
actividad. A menudo, sirven como documentación de base con vistas a un hito de control actividad. A menudo, sirven como documentación de base con vistas a un hito de control
para realizar un balance de la manera en la que avanza el proyecto. para realizar un balance de la manera en la que avanza el proyecto.

7. La ley de Brooks no es segura al cien por cien. Se trata sólo de una indicación genérica 7. La ley de Brooks no es segura al cien por cien. Se trata sólo de una indicación genérica
para avisar de que se debe estar prevenido ante el mito del hombre-mes y también de que, para avisar de que se debe estar prevenido ante el mito del hombre-mes y también de que,
en un proyecto informático, el hecho de añadir personal cuando se dan retrasos a menu- en un proyecto informático, el hecho de añadir personal cuando se dan retrasos a menu-
do crea más problemas de los que resuelve. do crea más problemas de los que resuelve.

8. Se debe asegurar la calidad del software porque la práctica muestra que el software tiene 8. Se debe asegurar la calidad del software porque la práctica muestra que el software tiene
siempre errores y problemas de fiabilidad y/o mantenimiento. siempre errores y problemas de fiabilidad y/o mantenimiento.

9. Un software es de calidad cuando cumple los requerimientos especificados y, además, sa- 9. Un software es de calidad cuando cumple los requerimientos especificados y, además, sa-
tisface las necesidades o expectativas del cliente o usuario. tisface las necesidades o expectativas del cliente o usuario.

10. La serie ISO 9000 y, en particular, las normas ISO 9001 e ISO 9000-3, que precisamente 10. La serie ISO 9000 y, en particular, las normas ISO 9001 e ISO 9000-3, que precisamente
indica cómo se debe utilizar la ISO 9001. indica cómo se debe utilizar la ISO 9001.

Glosario Glosario
actividad f Cada uno de los trabajos que se debe llevar a cabo en un proyecto y que forma actividad f Cada uno de los trabajos que se debe llevar a cabo en un proyecto y que forma
parte de la WBS (descomposición estructural en actividades). También se denomina tarea. parte de la WBS (descomposición estructural en actividades). También se denomina tarea.

actividad crítica f Actividad que no tiene margen de tiempo y que forma parte del camino actividad crítica f Actividad que no tiene margen de tiempo y que forma parte del camino
crítico. crítico.

aseguramiento de la calidad de software m Conjunto de actividades, planificadas y sis- aseguramiento de la calidad de software m Conjunto de actividades, planificadas y sis-
temáticas, necesarias para certificar que el producto (software) satisface los requerimientos de temáticas, necesarias para certificar que el producto (software) satisface los requerimientos de
calidad establecidos. calidad establecidos.

calidad del software f Grado en el que un sistema, componente o proceso cumple los re- calidad del software f Grado en el que un sistema, componente o proceso cumple los re-
querimientos especificados y las necesidades o expectativas del cliente o usuario. querimientos especificados y las necesidades o expectativas del cliente o usuario.

camino crítico m Conjunto y/o cadena de actividades críticas de un proyecto, es decir, de camino crítico m Conjunto y/o cadena de actividades críticas de un proyecto, es decir, de
actividades sin margen, que determinan la duración global de todo el proyecto. actividades sin margen, que determinan la duración global de todo el proyecto.
sigla: CPM sigla: CPM

CPM m Véase camino crítico CPM m Véase camino crítico

diagrama de Gantt m Diagrama que muestra el tiempo en el eje de abscisas, mientras que diagrama de Gantt m Diagrama que muestra el tiempo en el eje de abscisas, mientras que
en cada línea de las ordenadas se encuentran todas y cada una de las actividades que forman en cada línea de las 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 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 final de cada actividad. parte derecha se marca una línea desde la fecha inicial hasta la final de cada actividad.
 FUOC • P03/7506/02143 29 La gestión de un proyecto informático  FUOC • P03/7506/02143 29 La gestión de un proyecto informático

diagrama PERT m Descripción de un proyecto en forma de grafo donde los nudos del gra- diagrama PERT m Descripción de un proyecto en forma de grafo donde los nudos del gra-
fo son las actividades y las flechas son las relaciones de precedencia directa entre actividades. fo son las actividades y las flechas son las relaciones de precedencia directa entre actividades.
También se conoce como red de actividades o grafo de precedencias. También se conoce como red de actividades o grafo de precedencias.

grafo de precedencias m Véase diagrama PERT grafo de precedencias m Véase diagrama PERT

hitos de control m Actividades ficticias con duración nula, introducidas en la planificación hitos de control m Actividades ficticias con duración nula, introducidas en la planificación
al final de las fases o etapas del proyecto o de manera periódica (una vez en el mes, por ejem- al final de las fases o etapas del proyecto o de manera periódica (una vez en el mes, por ejem-
plo), para facilitar el seguimiento y el control del proyecto. plo), para facilitar el seguimiento y el control del proyecto.

hoja de actividad f Documento de datos individuales de seguimiento de un proyecto, don- hoja de actividad f Documento de datos individuales de seguimiento de un proyecto, don-
de cada miembro del equipo señala las horas que ha ocupado en cada una de las tareas que de cada miembro del equipo señala las horas que ha ocupado en cada una de las tareas que
se le han asignado. se le han asignado.

informe de situación de un proyecto m Resumen de la realidad de un proyecto en un informe de situación de un proyecto m Resumen de la realidad de un proyecto en un
momento determinado, obtenido a partir de los datos de las hojas de actividad y del hecho momento determinado, obtenido a partir de los datos de las hojas de actividad y del hecho
de compararlas con la planificación vigente. de compararlas con la planificación vigente.

ley de Brooks f Advertencia para tener en cuenta el mito del hombre-mes y que señala que ley de Brooks f Advertencia para tener en cuenta el mito del hombre-mes y que señala que
si un proyecto va retrasado, el hecho de añadir más personal es la manera más segura de re- si un proyecto va retrasado, el hecho de añadir más personal es la manera más segura de re-
trasarlo todavía más. trasarlo todavía más.

margen de una actividad m Disponibilidad de tiempo en una actividad. El margen es margen de una actividad m Disponibilidad de tiempo en una actividad. El margen es
nulo en las actividades críticas que forman el camino crítico. nulo en las actividades críticas que forman el camino crítico.

PERT f Véase program evaluation and review technique PERT f Véase program evaluation and review technique

program evaluation and review technique f Técnica de revisión y actualización del pro- program evaluation and review technique f Técnica de revisión y actualización del pro-
grama o proyecto. grama o proyecto.
sigla: PERT sigla: PERT

recurso en un proyecto informático m Cada uno de los profesionales que forman el recurso en un proyecto informático m Cada uno de los profesionales que forman el
equipo de trabajo del proyecto. equipo de trabajo del proyecto.

red de actividades f Véase diagrama PERT red de actividades f Véase diagrama PERT

técnica de revisión y actualización del programa o proyecto f Procedimiento para técnica de revisión y actualización del programa o proyecto f Procedimiento para
planificar y orientar el seguimiento de proyectos, basado en el grafo de precedencias entre planificar y orientar el seguimiento de proyectos, basado en el grafo de precedencias entre
actividades que fue desarrollado ya hace décadas en la Marina norteamericana para el trata- actividades que fue desarrollado ya hace décadas en la Marina norteamericana para el trata-
miento de grandes proyectos de ingeniería de todo tipo. miento de grandes proyectos de ingeniería de todo tipo.

WBS f Véase work breakdown structure WBS f Véase work breakdown structure

work breakdown structure f Descomposición estructural de los trabajos que se deben work breakdown structure f Descomposición estructural de los trabajos que se deben
realizar, es decir, la lista estructurada de todas las actividades y tareas de un proyecto. realizar, es decir, la lista estructurada de todas las actividades y tareas de un proyecto.
sigla: WBS sigla: WBS

Bibliografía Bibliografía
Brooks, F. (1975). The Mythical Man-Month. Reading: Addison-Wesley. Brooks, F. (1975). The Mythical Man-Month. Reading: Addison-Wesley.

Cantor, M.R. (1998). Object-Oriented Project Management with UML. Nueva York: John Wiley Cantor, M.R. (1998). Object-Oriented Project Management with UML. Nueva York: John Wiley
& Sons. & Sons.

Ince, D. (1994). ISO 9001 and Software Quality Assurance. Londres: McGraw-Hill. Ince, D. (1994). ISO 9001 and Software Quality Assurance. Londres: McGraw-Hill.

Jenner, M.G. (1995). Software Quality Management and ISO 9001: How to Make Them Work Jenner, M.G. (1995). Software Quality Management and ISO 9001: How to Make Them Work
for You. Nueva York: John Wiley & Sons. for You. Nueva York: John Wiley & Sons.

Jones, C. (1994). Assesment and Control of Software Risks. Englewood Cliffs: Prentice Hall. Jones, C. (1994). Assesment and Control of Software Risks. Englewood Cliffs: Prentice Hall.

Kehoe, R.; Jarvis, A. (1996). ISO 9000-3: A Tool for Software Product and Process Improvement. Kehoe, R.; Jarvis, A. (1996). ISO 9000-3: A Tool for Software Product and Process Improvement.
Nueva York: Springer. Nueva York: Springer.

Marco, T. de (1982). Controlling Software Projects. Englewood Cliffs: Prentice Hall. Marco, T. de (1982). Controlling Software Projects. Englewood Cliffs: Prentice Hall.

Moder, J.J.; Philips, C.R.; Davis, E.W. (1983). Project Management with CPM, PERT and Moder, J.J.; Philips, C.R.; Davis, E.W. (1983). Project Management with CPM, PERT and
Precedence Diagramming (3.ª ed.). Nueva York: Van Nostrand Reinhold. Precedence Diagramming (3.ª ed.). Nueva York: Van Nostrand Reinhold.

Page-Jones, M. (1985). Practical Project Management: Restoring Quality to DP Projects and Systems. Page-Jones, M. (1985). Practical Project Management: Restoring Quality to DP Projects and Systems.
Nueva York: Dorset House. Nueva York: Dorset House.
 FUOC • P03/7506/02143 30 La gestión de un proyecto informático  FUOC • P03/7506/02143 30 La gestión de un proyecto informático

Piattini, M.; Calvo-Manzano, J.A; Cervera, J.; Fernández, L. (1996). Análisis y diseño Piattini, M.; Calvo-Manzano, J.A; Cervera, J.; Fernández, L. (1996). Análisis y diseño
detallado de aplicaciones de gestión. Madrid: Ra-ma. detallado de aplicaciones de gestión. Madrid: Ra-ma.

Pressman, R.S. (1998). Ingeniería del software: un enfoque práctico (4.ª ed.). Madrid: McGraw- Pressman, R.S. (1998). Ingeniería del software: un enfoque práctico (4.ª ed.). Madrid: McGraw-
Hill. Hill.

Ros, A.; Viñallonga, J. (1995). Gestió dels sistemes d’informació a l’empresa. Barcelona: Edi- Ros, A.; Viñallonga, J. (1995). Gestió dels sistemes d’informació a l’empresa. Barcelona: Edi-
ciones UPC. ciones UPC.

Royce, W. (1998). Software Project Management: A Unified Framework. Reading: Addison-Wesley Royce, W. (1998). Software Project Management: A Unified Framework. Reading: Addison-Wesley
(Object Technology Series). (Object Technology Series).

Sommerville, I. (1996). Software Engineering (5.ª ed.). Reading: Addison- Wesley. Sommerville, I. (1996). Software Engineering (5.ª ed.). Reading: Addison- Wesley.

Thomset, R. (1993). Third Wave Project Management: A Handbook for Managing the Complex Thomset, R. (1993). Third Wave Project Management: A Handbook for Managing the Complex
Information Systems for the 1990 s. Englewood Cliffs: Prentice Hall. Information Systems for the 1990 s. Englewood Cliffs: Prentice Hall.

Das könnte Ihnen auch gefallen