Gestión Proyectos Computacionales

La gestión de un proyecto informáticoPlanificación, seguimiento, y aseguramiento de la calidad

Miquel Barceló García

P03/75069/02143

La gestión de un proyecto informáticoPlanificación, seguimiento, y aseguramiento de la calidad

Miquel Barceló García

P03/75069/02143

FUOC • P03/7506/02143 La gestión de un proyecto informático 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

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

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

1. Planificación en el tiempo de los proyectos informáticos ......................................................................................... 71.1. La técnica del PERT y el método del camino crítico ........................ 7

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

1.3. La planificación de un proyecto informático ................................... 13

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

precedencias .......................................................................... 14

2. Seguimiento y control de un proyecto informático .................. 172.1. Las hojas de actividad y el informe de situación ............................. 18

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

3. Aseguramiento de la calidad en un proyecto informático .......................................................................................... 21

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

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

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

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

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

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

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

Índice

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

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

1. Planificación en el tiempo de los proyectos informáticos ......................................................................................... 71.1. La técnica del PERT y el método del camino crítico ........................ 7

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

1.3. La planificación de un proyecto informático ................................... 13


precedencias .......................................................................... 14

2. Seguimiento y control de un proyecto informático .................. 172.1. Las hojas de actividad y el informe de situación ............................. 18

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

3. Aseguramiento de la calidad en un proyecto informático .......................................................................................... 21

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

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

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

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

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

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


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

Introducción

En los módulos didácticos “El proyecto informático de construcción de software”

y “Estimación de costes de un proyecto informático” analizamos los aspectos más

específicos y peculiares de los proyectos informáticos de construcción de software

de aplicación en la informática de gestión. En concreto, nos referimos a cómo el

proyecto informático se especifica a medida que se va elaborando y la dificultad

que ello conlleva con vistas a la estimación de las cargas y los costes.

De hecho, lo que ahora queda por ver de la gestión de un proyecto informá-

tico no es en absoluto tan diferente de lo que es habitual en la gestión de

cualquier otro proyecto de ingeniería, sobre todo si se recuerda, a la hora de

tomar las decisiones imprescindibles de gestión del proyecto, que cuando se

habla de personas-mes para considerar el esfuerzo, no se puede en absoluto

pensar en intercambiar los dos factores.

Una vez se ha llevado a cabo la primera estimación de costes, a menudo, a par-

tir de una primera especificación genérica del alcance del proyecto muy pre-

caria, es necesario finalizar la etapa de calificación y planificar en el tiempo las

diferentes tareas pendientes y, cuando ya se ha iniciado el proceso de desarro-

llo del proyecto, sólo se debe realizar el seguimiento y el control.

En este módulo, repasamos brevemente los problemas generales de la planifi-

cación temporal de actividades, con la mención de temas clásicos como los

diagramas PERT o el método del camino crítico (CPM), sin olvidar hacer una

referencia inevitable a las diferentes herramientas informáticas disponibles

que pueden ayudar en esta actividad de planificación.

A partir de la planificación de actividades, es mucho más sencillo ordenar el

proceso de control del proyecto y el seguimiento de su desarrollo para llegar a

finalizar con éxito la actividad de construir un software de aplicación en la in-

formática de gestión.

Una vez revisadas brevemente las actividades típicas de gestión de proyectos

(planificación, seguimiento y control), al final de este módulo planteamos, de

manera básica e introductoria, el problema del aseguramiento de la calidad del

software (software quality assurance), que ha llegado a alcanzar una gran impor-

tancia en los últimos años, posiblemente por la falta de calidad y fiabilidad de

la mayoría del software construido.

Podéis ver el mito del hombre-mes en el subapartado 1.3.2 del módulo “Estimación de costes de un proyecto informático” de esta asignatura.


Introducción

En los módulos didácticos “El proyecto informático de construcción de software”

y “Estimación de costes de un proyecto informático” analizamos los aspectos más

específicos y peculiares de los proyectos informáticos de construcción de software

de aplicación en la informática de gestión. En concreto, nos referimos a cómo el

proyecto informático se especifica a medida que se va elaborando y la dificultad

que ello conlleva con vistas a la estimación de las cargas y los costes.

De hecho, lo que ahora queda por ver de la gestión de un proyecto informá-

tico no es en absoluto tan diferente de lo que es habitual en la gestión de

cualquier otro proyecto de ingeniería, sobre todo si se recuerda, a la hora de

tomar las decisiones imprescindibles de gestión del proyecto, que cuando se

habla de personas-mes para considerar el esfuerzo, no se puede en absoluto

pensar en intercambiar los dos factores.

Una vez se ha llevado a cabo la primera estimación de costes, a menudo, a par-

tir de una primera especificación genérica del alcance del proyecto muy pre-

caria, es necesario finalizar la etapa de calificación y planificar en el tiempo las

diferentes tareas pendientes y, cuando ya se ha iniciado el proceso de desarro-

llo del proyecto, sólo se debe realizar el seguimiento y el control.

En este módulo, repasamos brevemente los problemas generales de la planifi-

cación temporal de actividades, con la mención de temas clásicos como los

diagramas PERT o el método del camino crítico (CPM), sin olvidar hacer una

referencia inevitable a las diferentes herramientas informáticas disponibles

que pueden ayudar en esta actividad de planificación.

A partir de la planificación de actividades, es mucho más sencillo ordenar el

proceso de control del proyecto y el seguimiento de su desarrollo para llegar a

finalizar con éxito la actividad de construir un software de aplicación en la in-

formática de gestión.

Una vez revisadas brevemente las actividades típicas de gestión de proyectos

(planificación, seguimiento y control), al final de este módulo planteamos, de

manera básica e introductoria, el problema del aseguramiento de la calidad del

software (software quality assurance), que ha llegado a alcanzar una gran impor-

tancia en los últimos años, posiblemente por la falta de calidad y fiabilidad de

la mayoría del software construido.

Podéis ver el mito del hombre-mes en el subapartado 1.3.2 del módulo “Estimación de costes de un proyecto informático” de esta asignatura.


Objetivos

En este módulo se cierra el estudio de la gestión de un proyecto informático

de construcción de software de aplicación en la informática de gestión. Se tra-

tan los temas de la planificación temporal de actividades y, a partir de esta pla-

nificación, del seguimiento y el control del desarrollo del proyecto. El módulo

termina con una referencia breve al problema del aseguramiento de la calidad

del software. Con el estudio de este módulo y de los materiales didácticos aso-

ciados, el estudiante debe alcanzar los objetivos siguientes:

1. Conocer la problemática general de la planificación temporal de proyectos,

el uso de diagramas de Gantt, la técnica del PERT y el método del camino

crítico (CPM).

2. Saber planificar en el tiempo las actividades de un proyecto informático,

teniendo en cuenta los recursos disponibles y las limitaciones de uso.

3. Conocer los problemas que se plantean y los documentos que se suelen uti-

lizar para controlar el desarrollo de un proyecto y realizar un seguimiento

completo y exhaustivo.

4. Saber cuáles son las decisiones más habituales que se han de tomar en el

proceso de control de un proyecto informático y los aspectos que más las

condicionan.

5. Conocer las herramientas informáticas que ayudan tanto en el proceso de

planificación del proyecto, como en el de seguimiento y control de una

planificación ya efectuada.

6. Obtener una visión inicial de los problemas de aseguramiento de la cali-

dad del software (software quality assurance) y, en definitiva, de la dificultad de

obtener software seguro, fiable y de calidad.


Objetivos

En este módulo se cierra el estudio de la gestión de un proyecto informático

de construcción de software de aplicación en la informática de gestión. Se tra-

tan los temas de la planificación temporal de actividades y, a partir de esta pla-

nificación, del seguimiento y el control del desarrollo del proyecto. El módulo

termina con una referencia breve al problema del aseguramiento de la calidad

del software. Con el estudio de este módulo y de los materiales didácticos aso-

ciados, el estudiante debe alcanzar los objetivos siguientes:

1. Conocer la problemática general de la planificación temporal de proyectos,

el uso de diagramas de Gantt, la técnica del PERT y el método del camino

crítico (CPM).

2. Saber planificar en el tiempo las actividades de un proyecto informático,

teniendo en cuenta los recursos disponibles y las limitaciones de uso.

3. Conocer los problemas que se plantean y los documentos que se suelen uti-

lizar para controlar el desarrollo de un proyecto y realizar un seguimiento

completo y exhaustivo.

4. Saber cuáles son las decisiones más habituales que se han de tomar en el

proceso de control de un proyecto informático y los aspectos que más las

condicionan.

5. Conocer las herramientas informáticas que ayudan tanto en el proceso de

planificación del proyecto, como en el de seguimiento y control de una

planificación ya efectuada.

6. Obtener una visión inicial de los problemas de aseguramiento de la cali-

dad del software (software quality assurance) y, en definitiva, de la dificultad de

obtener software seguro, fiable y de calidad.


1. Planificación en el tiempo de los proyectos informáticos

Tal como explicamos en otro módulo, una vez determinada la voluntad de

iniciar un proyecto informático, las etapas que caracterizan la gestión son

dos: la primera es la calificación inicial (estimación de costes y planifica-

ción temporal) y la segunda es el desarrollo (seguimiento y control del pro-

yecto, tal vez acompañados de nuevas estimaciones y planificaciones) para

llegar, de una manera o de otra, con éxito o sin él, al final o cierre definitivo

del proyecto.

Una vez conocida la amplia problemática de la estimación de costes, que

nos ha ocupado un módulo entero, ahora planificaremos en el tiempo las

diferentes tareas o actividades de las que consta el proyecto.

Cabe mencionar que la planificación temporal de proyectos a partir de su des-

composición en tareas (WBS) y la estimación de la duración de cada una es un

proceso suficientemente conocido y que los proyectos informáticos de cons-

trucción de software comparten con muchos otros proyectos de ingeniería. Por

otra parte, como veremos, salvo una particular manera de tener en cuenta los

recursos (las personas que forman el equipo del proyecto), no se dan diferen-

cias esenciales con otros proyectos de ingeniería.

Comenzamos con la exposición breve y sintética de conceptos tradiciona-

les de la planificación temporal de actividades como la técnica del PERT y

el método del camino crítico (CPM) y después analizamos el caso general

de la planificación temporal de proyectos informáticos.

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

El fundamento central de las técnicas del PERT es la representación gráfica del

proyecto en un diagrama que muestre las relaciones y, sobre todo, las preceden-

cias entre las tareas que constituyen el proyecto. Este diagrama, que algunos de-

nominan diagrama PERT, en el fondo no es más que un grafo de precedencias de

actividades que a menudo se llama red de actividades (activity network) o, también,

diagrama de precedencias.

La técnica del PERT* (técnica de revisión y actualización del programa

o proyecto) es un procedimiento desarrollado ya hace décadas por la

Marina norteamericana (US Navy) para el tratamiento de grandes pro-

yectos de ingeniería de todo tipo.

Podéis ver las etapas de un proyecto informático en el subapartado 1.2 del módulo “El proyecto informático de construcción de software” de esta asignatura.

Podéis ver la problemática de la estimación de costes en el módulo “Estimación de costes de un proyecto informático” de esta asignatura.

* PERT es la sigla de la expresión inglesa Program Evaluation

and Review Technique.


1. Planificación en el tiempo de los proyectos informáticos

Tal como explicamos en otro módulo, una vez determinada la voluntad de

iniciar un proyecto informático, las etapas que caracterizan la gestión son

dos: la primera es la calificación inicial (estimación de costes y planifica-

ción temporal) y la segunda es el desarrollo (seguimiento y control del pro-

yecto, tal vez acompañados de nuevas estimaciones y planificaciones) para

llegar, de una manera o de otra, con éxito o sin él, al final o cierre definitivo

del proyecto.

Una vez conocida la amplia problemática de la estimación de costes, que

nos ha ocupado un módulo entero, ahora planificaremos en el tiempo las

diferentes tareas o actividades de las que consta el proyecto.

Cabe mencionar que la planificación temporal de proyectos a partir de su des-

composición en tareas (WBS) y la estimación de la duración de cada una es un

proceso suficientemente conocido y que los proyectos informáticos de cons-

trucción de software comparten con muchos otros proyectos de ingeniería. Por

otra parte, como veremos, salvo una particular manera de tener en cuenta los

recursos (las personas que forman el equipo del proyecto), no se dan diferen-

cias esenciales con otros proyectos de ingeniería.

Comenzamos con la exposición breve y sintética de conceptos tradiciona-

les de la planificación temporal de actividades como la técnica del PERT y

el método del camino crítico (CPM) y después analizamos el caso general

de la planificación temporal de proyectos informáticos.

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

El fundamento central de las técnicas del PERT es la representación gráfica del

proyecto en un diagrama que muestre las relaciones y, sobre todo, las preceden-

cias entre las tareas que constituyen el proyecto. Este diagrama, que algunos de-

nominan diagrama PERT, en el fondo no es más que un grafo de precedencias de

actividades que a menudo se llama red de actividades (activity network) o, también,

diagrama de precedencias.

La técnica del PERT* (técnica de revisión y actualización del programa

o proyecto) es un procedimiento desarrollado ya hace décadas por la

Marina norteamericana (US Navy) para el tratamiento de grandes pro-

yectos de ingeniería de todo tipo.

Podéis ver las etapas de un proyecto informático en el subapartado 1.2 del módulo “El proyecto informático de construcción de software” de esta asignatura.

Podéis ver la problemática de la estimación de costes en el módulo “Estimación de costes de un proyecto informático” de esta asignatura.

* PERT es la sigla de la expresión inglesa Program Evaluation

and Review Technique.


A menudo, los dos métodos se pueden tratar conjuntamente, tal como hare-

mos en esta exposición simplificada.

Conviene advertir que, aunque aquí se habla de tareas o actividades indis-

tintamente, a menudo la nomenclatura más habitual utiliza el término ac-

tividades cuando se refiere a PERT, aunque actualmente la elección suele

depender de la manera como se haya traducido el concepto en la herra-

mienta informática de la que nos ayudamos a la hora de llevar a cabo la

planificación de un proyecto.

El conjunto de las técnicas PERT y el método del camino crítico (CPM) propor-

cionan herramientas cuantitativas que permiten determinar lo siguiente:

1) El camino crítico del proyecto, que es la secuencia o cadena de activida-

des que determina la duración total del proyecto.

2) Las estimaciones de tiempos más probables, tanto para la totalidad del

proyecto como para el inicio y el final de cada una de las tareas o actividades

individuales.

3) Los márgenes de tiempo que se dan para cada tarea o actividad individual

y que no impliquen un retraso del proyecto.

Pongamos un ejemplo, que es la manera más clara de verlo. Para no tener que

realizar un diagrama complejo, imaginamos un pequeño proyecto del cual he-

mos efectuado una descomposición en diez actividades, como las que se indi-

can en la tabla siguiente:

El método del camino crítico (CPM) es un método de optimización

que, como el PERT, también utiliza una red de tareas del proyecto.

El diagrama PERT es un grafo de precedencias donde los nudos o nodos

son las actividades, mientras que los arcos son las relaciones de precedencia

entre actividades. De cada actividad, se debe saber la duración estimada y

las actividades que le son precedentes directos. El resto, en cierta manera,

surge casi automáticamente del mismo diagrama.

Actividades, duración y precedencias de un proyecto ficticio

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

1 Inicio 0 -

2 Establecer los requerimientos 3 1

3 Seleccionar los drivers 2 1

CPM es la sigla de la expresión inglesa Critical Path Method.

Podéis ver las herramientas informatizadas para la planificación de un proyecto en el subapartado1.2 de este módulo didáctico.


A menudo, los dos métodos se pueden tratar conjuntamente, tal como hare-

mos en esta exposición simplificada.

Conviene advertir que, aunque aquí se habla de tareas o actividades indis-

tintamente, a menudo la nomenclatura más habitual utiliza el término ac-

tividades cuando se refiere a PERT, aunque actualmente la elección suele

depender de la manera como se haya traducido el concepto en la herra-

mienta informática de la que nos ayudamos a la hora de llevar a cabo la

planificación de un proyecto.

El conjunto de las técnicas PERT y el método del camino crítico (CPM) propor-

cionan herramientas cuantitativas que permiten determinar lo siguiente:

1) El camino crítico del proyecto, que es la secuencia o cadena de activida-

des que determina la duración total del proyecto.

2) Las estimaciones de tiempos más probables, tanto para la totalidad del

proyecto como para el inicio y el final de cada una de las tareas o actividades

individuales.

3) Los márgenes de tiempo que se dan para cada tarea o actividad individual

y que no impliquen un retraso del proyecto.

Pongamos un ejemplo, que es la manera más clara de verlo. Para no tener que

realizar un diagrama complejo, imaginamos un pequeño proyecto del cual he-

mos efectuado una descomposición en diez actividades, como las que se indi-

can en la tabla siguiente:

El método del camino crítico (CPM) es un método de optimización

que, como el PERT, también utiliza una red de tareas del proyecto.

El diagrama PERT es un grafo de precedencias donde los nudos o nodos

son las actividades, mientras que los arcos son las relaciones de precedencia

entre actividades. De cada actividad, se debe saber la duración estimada y

las actividades que le son precedentes directos. El resto, en cierta manera,

surge casi automáticamente del mismo diagrama.



1 Inicio 0 -

2 Establecer los requerimientos 3 1

3 Seleccionar los drivers 2 1

CPM es la sigla de la expresión inglesa Critical Path Method.

Podéis ver las herramientas informatizadas para la planificación de un proyecto en el subapartado1.2 de este módulo didáctico.


Conviene, tal como se lleva a cabo aquí, incluir siempre las actividades de ini-

cio y final, puramente ficticias y con duración cero.

La tabla nos ofrece para cada actividad un nombre, una identificación nu-

mérica (de uno a diez), la duración estimada de la actividad (en unidades

arbitrarias; por ejemplo, en semanas) y las tareas que son inmediatamente

anteriores e imprescindibles para poder empezar cada actividad en concre-

to (precedencias).

Si se quiere, se puede imaginar que se trata de construir un sistema informáti-

co determinado que utiliza datos que ya tenemos (recogidos en la actividad 5)

y que utiliza una serie de drivers diferentes (que se seleccionan en la actividad

3 y se prueban en la actividad 6) para acceder a periféricos o a aquello que sea

necesario. De hecho, el proyecto en sí no es importante, ya que se trata de un

ejemplo ficticio para ilustrar el PERT y el CPM.

Si se dispone de estos datos (actividades, duración estimada y precedencias) se

puede dibujar un grafo como el de la figura de la página siguiente.

Como se puede ver en el diagrama, las flechas marcan las relaciones de prece-

dencia que existen entre las actividades, mientras que los nudos son las acti-

vidades, de las cuales se han recogido también una serie de datos: el número

identificador, el nombre de la actividad y la duración estimada (puesta entre

paréntesis dentro del nudo).

Sobre cada nudo se ha añadido también la información que sale directamente

de la explotación del diagrama de precedencias: las semanas de inicio y final

de cada actividad. Conviene darse cuenta de que la actividad final tiene como

precedentes todos los arcos pendientes del diagrama.

Por ejemplo, la actividad 1 (inicio) empieza en la semana cero y, al tener una

duración nula, termina también en la semana cero. Pero la actividad 2 (esta-

blecer los requerimientos) comienza en la semana cero (justo después de la ac-

tividad precedente, inicio) y finaliza al final de la semana tres, ya que dura

precisamente tres semanas. Del mismo modo, la actividad 4 (realizar el diseño)



4 Realizar el diseño 4 2

5 Recoger datos 2 2 y 3

6 Probar los drivers 6 3

7 Codificar 4 4

8 Elaborar la documentación 2 4

9 Probar el producto 4 5, 6 y 7

10 Final 0 ?


Conviene, tal como se lleva a cabo aquí, incluir siempre las actividades de ini-

cio y final, puramente ficticias y con duración cero.

La tabla nos ofrece para cada actividad un nombre, una identificación nu-

mérica (de uno a diez), la duración estimada de la actividad (en unidades

arbitrarias; por ejemplo, en semanas) y las tareas que son inmediatamente

anteriores e imprescindibles para poder empezar cada actividad en concre-

to (precedencias).

Si se quiere, se puede imaginar que se trata de construir un sistema informáti-

co determinado que utiliza datos que ya tenemos (recogidos en la actividad 5)

y que utiliza una serie de drivers diferentes (que se seleccionan en la actividad

3 y se prueban en la actividad 6) para acceder a periféricos o a aquello que sea

necesario. De hecho, el proyecto en sí no es importante, ya que se trata de un

ejemplo ficticio para ilustrar el PERT y el CPM.

Si se dispone de estos datos (actividades, duración estimada y precedencias) se

puede dibujar un grafo como el de la figura de la página siguiente.

Como se puede ver en el diagrama, las flechas marcan las relaciones de prece-

dencia que existen entre las actividades, mientras que los nudos son las acti-

vidades, de las cuales se han recogido también una serie de datos: el número

identificador, el nombre de la actividad y la duración estimada (puesta entre

paréntesis dentro del nudo).

Sobre cada nudo se ha añadido también la información que sale directamente

de la explotación del diagrama de precedencias: las semanas de inicio y final

de cada actividad. Conviene darse cuenta de que la actividad final tiene como

precedentes todos los arcos pendientes del diagrama.

Por ejemplo, la actividad 1 (inicio) empieza en la semana cero y, al tener una

duración nula, termina también en la semana cero. Pero la actividad 2 (esta-

blecer los requerimientos) comienza en la semana cero (justo después de la ac-

tividad precedente, inicio) y finaliza al final de la semana tres, ya que dura

precisamente tres semanas. Del mismo modo, la actividad 4 (realizar el diseño)



4 Realizar el diseño 4 2

5 Recoger datos 2 2 y 3

6 Probar los drivers 6 3

7 Codificar 4 4

8 Elaborar la documentación 2 4

9 Probar el producto 4 5, 6 y 7

10 Final 0 ?


no puede iniciarse hasta que no termine la precedente (la 2, establecer los re-

querimientos), es decir, no puede empezar hasta que no ha acabado la semana

tres. Además, al durar cuatro semanas, no finalizará hasta el final de la semana

siete. Y así sucesivamente.

En el caso de la actividad 9 (probar el producto) se dan tres precedentes direc-

tos: la actividad 7 (codificar), que finaliza en la semana once; la actividad 5 (re-

coger datos), que finaliza en la semana cinco; y la actividad 6 (probar los

drivers), que finaliza en la semana ocho. Evidentemente, como se debe esperar

a que las tres hayan terminado, la actividad 9 (probar el producto) no puede

empezar hasta que no haya acabado la actividad 7 (codificar) en la semana on-

ce, que es la que finaliza más tarde de todas.

Una vez se ha realizado el diagrama completo, se puede ver que el proyecto

dura un total de quince semanas. Y no sólo eso; el diagrama PERT, gracias al

método del camino crítico, nos permite saber algo de gran importancia para

el futuro de la gestión del proyecto.

Una observación sencilla del diagrama nos muestra que las actividades 1 (ini-

cio), 2 (establecer los requerimientos), 4 (realizar el diseño), 7 (codificar), 9

(probar el producto) y 10 (final) no tienen ningún margen. Es decir, si alguna

de estas actividades tardara más de lo que se ha estimado, todo el proyecto se

alargaría más de las quince semanas previstas.

Las actividades críticas...

... son las que forman el cami-no crítico y no tienen ningún margen. Cualquier desviación en la duración de estas activi-dades se traduce en una desviación en la duración del proyecto.


no puede iniciarse hasta que no termine la precedente (la 2, establecer los re-

querimientos), es decir, no puede empezar hasta que no ha acabado la semana

tres. Además, al durar cuatro semanas, no finalizará hasta el final de la semana

siete. Y así sucesivamente.

En el caso de la actividad 9 (probar el producto) se dan tres precedentes direc-

tos: la actividad 7 (codificar), que finaliza en la semana once; la actividad 5 (re-

coger datos), que finaliza en la semana cinco; y la actividad 6 (probar los

drivers), que finaliza en la semana ocho. Evidentemente, como se debe esperar

a que las tres hayan terminado, la actividad 9 (probar el producto) no puede

empezar hasta que no haya acabado la actividad 7 (codificar) en la semana on-

ce, que es la que finaliza más tarde de todas.

Una vez se ha realizado el diagrama completo, se puede ver que el proyecto

dura un total de quince semanas. Y no sólo eso; el diagrama PERT, gracias al

método del camino crítico, nos permite saber algo de gran importancia para

el futuro de la gestión del proyecto.

Una observación sencilla del diagrama nos muestra que las actividades 1 (ini-

cio), 2 (establecer los requerimientos), 4 (realizar el diseño), 7 (codificar), 9

(probar el producto) y 10 (final) no tienen ningún margen. Es decir, si alguna

de estas actividades tardara más de lo que se ha estimado, todo el proyecto se

alargaría más de las quince semanas previstas.

Las actividades críticas...

... son las que forman el cami-no crítico y no tienen ningún margen. Cualquier desviación en la duración de estas activi-dades se traduce en una desviación en la duración del proyecto.


En el diagrama, el camino crítico está marcado por flechas continuas.

Por otra parte, el diagrama PERT nos permite ver que existen actividades que no

son tan decisivas en la vida del proyecto. Por ejemplo, la actividad 6 (probar los

drivers) tiene marcados un inicio y un final (2, 8). Es decir, se puede comenzar a

efectuar una vez finalizada la segunda semana del proyecto (justo cuando acaba

la actividad precedente 3, Seleccionar los drivers) y, si se cumplen las estimaciones

de duración, terminará al final de la semana ocho. Ahora bien, la actividad 9 (pro-

bar el producto), de la cual la 6 es precedente, tiene también como precedente la

actividad 7 (codificar); y ello provoca que no pueda empezar hasta que no haya

finalizado la semana once y que la actividad 6 tenga un margen de tres semanas

(11 − 8 = 3), de manera que no será nada crítica.

Es decir, si la actividad 6 (probar los drivers) tardara siete semanas en lugar de

las seis semanas estimadas, el proyecto duraría también quince semanas, ya

que la actividad 6 no forma parte del camino crítico y, como se ve en el diagra-

ma, tiene un margen de tres semanas (podría empezar más tarde o durar más

de lo que se había estimado).

Con vistas a la gestión de un proyecto es muy importante saber qué activida-

des son críticas (es decir, qué actividades forman parte del camino crítico) y

cuáles no. Por otra parte, conviene remarcar que las actividades no críticas dis-

ponen de un margen que permite que el planificador acomode mejor los re-

cursos y, sobre todo, que la buena gestión del proyecto pase por el control

estricto de las actividades que forman parte del camino crítico.

Evidentemente, las cosas son más complicadas en el caso de proyectos con

muchas más actividades. Pero, afortunadamente, en estos proyectos es fácil

poder disponer de una herramienta informatizada que, de manera automá-

tica, nos da el camino crítico y con todas las ventajas que esto representa.

Cabe mencionar que en este ejemplo se ha utilizado lo que se llama una pla-

nificación ASAP, que sitúa cada actividad lo antes posible y es el procedi-

Las actividades que no tienen ningún margen forman lo que se denomi-

na camino crítico y, en definitiva, son las que determinan la duración

final del proyecto. A menudo estas actividades se llaman actividades

críticas.

La técnica del PERT con la determinación del camino crítico es un sistema

muy adecuado para la buena gestión de un proyecto (de cualquier proyec-

to), ya que nos permite centrar los esfuerzos en las actividades críticas y uti-

lizar las que no lo son para disponer de los recursos con más agilidad.

Para cada actividad...

... se puede establecer unaplanificación de tipo:• ASAP, del inglés as soon

as posible, tan prontocomo sea posible.

• ALAP, del inglés as last • as posible, tan tarde como

sea posible.


En el diagrama, el camino crítico está marcado por flechas continuas.

Por otra parte, el diagrama PERT nos permite ver que existen actividades que no

son tan decisivas en la vida del proyecto. Por ejemplo, la actividad 6 (probar los

drivers) tiene marcados un inicio y un final (2, 8). Es decir, se puede comenzar a

efectuar una vez finalizada la segunda semana del proyecto (justo cuando acaba

la actividad precedente 3, Seleccionar los drivers) y, si se cumplen las estimaciones

de duración, terminará al final de la semana ocho. Ahora bien, la actividad 9 (pro-

bar el producto), de la cual la 6 es precedente, tiene también como precedente la

actividad 7 (codificar); y ello provoca que no pueda empezar hasta que no haya

finalizado la semana once y que la actividad 6 tenga un margen de tres semanas

(11 − 8 = 3), de manera que no será nada crítica.

Es decir, si la actividad 6 (probar los drivers) tardara siete semanas en lugar de

las seis semanas estimadas, el proyecto duraría también quince semanas, ya

que la actividad 6 no forma parte del camino crítico y, como se ve en el diagra-

ma, tiene un margen de tres semanas (podría empezar más tarde o durar más

de lo que se había estimado).

Con vistas a la gestión de un proyecto es muy importante saber qué activida-

des son críticas (es decir, qué actividades forman parte del camino crítico) y

cuáles no. Por otra parte, conviene remarcar que las actividades no críticas dis-

ponen de un margen que permite que el planificador acomode mejor los re-

cursos y, sobre todo, que la buena gestión del proyecto pase por el control

estricto de las actividades que forman parte del camino crítico.

Evidentemente, las cosas son más complicadas en el caso de proyectos con

muchas más actividades. Pero, afortunadamente, en estos proyectos es fácil

poder disponer de una herramienta informatizada que, de manera automá-

tica, nos da el camino crítico y con todas las ventajas que esto representa.

Cabe mencionar que en este ejemplo se ha utilizado lo que se llama una pla-

nificación ASAP, que sitúa cada actividad lo antes posible y es el procedi-

Las actividades que no tienen ningún margen forman lo que se denomi-

na camino crítico y, en definitiva, son las que determinan la duración

final del proyecto. A menudo estas actividades se llaman actividades

críticas.

La técnica del PERT con la determinación del camino crítico es un sistema

muy adecuado para la buena gestión de un proyecto (de cualquier proyec-

to), ya que nos permite centrar los esfuerzos en las actividades críticas y uti-

lizar las que no lo son para disponer de los recursos con más agilidad.

Para cada actividad...

... se puede establecer unaplanificación de tipo:• ASAP, del inglés as soon

as posible, tan prontocomo sea posible.

• ALAP, del inglés as last • as posible, tan tarde como

sea posible.


miento habitual cuando se parte de la fecha de inicio del proyecto y se quiere

encontrar el momento en el que se finalizará. En otros casos, generalmente

cuando se parte del día en el que el proyecto debe estar acabado, se utiliza un

proceso contrario, a partir de la fecha de fin del proyecto, hecho que se conoce

como una planificación ALAP.

1.2. Herramientas informatizadas para la planificación

Cuando se habla de herramientas informatizadas para la planificación, ya no se trata,

como pasaba en el caso de la estimación de costes, de herramientas que a menudo

son muy caras* y que sólo se utilizan para la estimación de costes en proyectos

informáticos. Ya hemos mencionado que la parte de la planificación temporal de

proyectos informáticos es prácticamente igual a la planificación de cualquier otro

proyecto de ingeniería. Esto provoca que las herramientas informáticas disponi-

bles, por el hecho de tener un mercado mucho más amplio, tengan un coste más

asequible y su uso se convierta en muy habitual.

El problema que se plantea a menudo es decidir cuál de las muchas herramien-

tas disponibles en el mercado se debe escoger. Pero se trata de un problema

falso. Como la mayoría de las herramientas informáticas de utilización muy

extendida, los sistemas de ayuda a la planificación de proyectos (y también,

como veremos, al seguimiento y control) proponen una gran cantidad de fun-

cionalidades que en general no se utilizan. Lo mismo ocurre, por ejemplo, con

los procesadores de textos o las hojas de cálculo.

Ahora bien, actualmente, para la planificación de proyectos, las herramientas

informáticas más habituales en nuestro entorno geográfico se reducen al MS-

PROJECT y el SUPERPROJECT, a causa de la fuerza de su sistema de ventas.

Elegir una de las dos herramientas es en cierta manera inútil. Cuando una de

las herramientas ofrece una funcionalidad nueva no disponible en la otra, sólo

se debe esperar unos meses y la nueva versión de esta otra herramienta incor-

porará también la misma funcionalidad. Además, cabe recordar que la mayo-

ría de estas funcionalidades no siempre se utilizan. Como ocurre con los

procesadores de texto, a menudo es mejor lo que se utiliza desde hace más

tiempo, ya que es lo más conocido y familiar.

Una vez explicado esto, debería quedar claro que si los ejemplos de este mó-

dulo se presentan en MS-PROJECT es únicamente porque esta herramienta ha

Dicho de otra manera, todas las herramientas disponibles en el mercado

tienen, además de complementos más o menos interesantes, los ele-

mentos mínimos para efectuar una buena planificación temporal de un

proyecto. El problema, a menudo, es cómo librarse de todo aquello que

la herramienta informática ofrece y que no vamos a utilizar.

* El SLIM, por ejemplo.

Podéis ver el subapartado 2.2 de este módulo didáctico.

El autor de este módulo...

... por ejemplo, ha escrito el texto original con el Word 4.0 de Microsoft para DOS, que data de 1987: para teclear es suficiente con ello.


miento habitual cuando se parte de la fecha de inicio del proyecto y se quiere

encontrar el momento en el que se finalizará. En otros casos, generalmente

cuando se parte del día en el que el proyecto debe estar acabado, se utiliza un

proceso contrario, a partir de la fecha de fin del proyecto, hecho que se conoce

como una planificación ALAP.

1.2. Herramientas informatizadas para la planificación

Cuando se habla de herramientas informatizadas para la planificación, ya no se trata,

como pasaba en el caso de la estimación de costes, de herramientas que a menudo

son muy caras* y que sólo se utilizan para la estimación de costes en proyectos

informáticos. Ya hemos mencionado que la parte de la planificación temporal de

proyectos informáticos es prácticamente igual a la planificación de cualquier otro

proyecto de ingeniería. Esto provoca que las herramientas informáticas disponi-

bles, por el hecho de tener un mercado mucho más amplio, tengan un coste más

asequible y su uso se convierta en muy habitual.

El problema que se plantea a menudo es decidir cuál de las muchas herramien-

tas disponibles en el mercado se debe escoger. Pero se trata de un problema

falso. Como la mayoría de las herramientas informáticas de utilización muy

extendida, los sistemas de ayuda a la planificación de proyectos (y también,

como veremos, al seguimiento y control) proponen una gran cantidad de fun-

cionalidades que en general no se utilizan. Lo mismo ocurre, por ejemplo, con

los procesadores de textos o las hojas de cálculo.

Ahora bien, actualmente, para la planificación de proyectos, las herramientas

informáticas más habituales en nuestro entorno geográfico se reducen al MS-

PROJECT y el SUPERPROJECT, a causa de la fuerza de su sistema de ventas.

Elegir una de las dos herramientas es en cierta manera inútil. Cuando una de

las herramientas ofrece una funcionalidad nueva no disponible en la otra, sólo

se debe esperar unos meses y la nueva versión de esta otra herramienta incor-

porará también la misma funcionalidad. Además, cabe recordar que la mayo-

ría de estas funcionalidades no siempre se utilizan. Como ocurre con los

procesadores de texto, a menudo es mejor lo que se utiliza desde hace más

tiempo, ya que es lo más conocido y familiar.

Una vez explicado esto, debería quedar claro que si los ejemplos de este mó-

dulo se presentan en MS-PROJECT es únicamente porque esta herramienta ha

Dicho de otra manera, todas las herramientas disponibles en el mercado

tienen, además de complementos más o menos interesantes, los ele-

mentos mínimos para efectuar una buena planificación temporal de un

proyecto. El problema, a menudo, es cómo librarse de todo aquello que

la herramienta informática ofrece y que no vamos a utilizar.

* El SLIM, por ejemplo.

Podéis ver el subapartado 2.2 de este módulo didáctico.

El autor de este módulo...

... por ejemplo, ha escrito el texto original con el Word 4.0 de Microsoft para DOS, que data de 1987: para teclear es suficiente con ello.


estado disponible, pero no porque exista alguna preferencia que se pueda ge-

neralizar a otros usuarios.

Lo que importa de las herramientas informatizadas para la ayuda a la pla-

nificación de proyectos es que todas ofrecen la posibilidad de mostrar el

diagrama PERT (o red de actividades) y marcar, además, el camino crítico

de manera automática. También ofrecen una gestión de recursos completa

y un montón de diagramas y listas (que aumentan día a día) que permiten

incluso realizar una presentación brillante y muy profesional de la planifi-

cación de un proyecto.

1.3. La planificación de un proyecto informático

En la planificación de un proyecto informático, además del diagrama PERT, se

suele utilizar una especie de diagrama temporal llamado diagrama de Gantt.

En el caso del proyecto ficticio que se ha utilizado para exponer el PERT y el

CPM, el diagrama de Gantt sería el que se muestra en la figura siguiente:

El diagrama de Gantt es un diagrama sencillo que muestra el tiempo

en el eje de abscisas, mientras que en cada línea del eje de ordenadas se

encuentran todas y cada una de las actividades que forman el proyecto.

En la parte izquierda se escribe el nombre de las actividades, mientras

que en la parte derecha se marca una línea desde la fecha inicial hasta

la fecha final de cada actividad.

Podéis ver el proyecto ficticio propuesto en el subapartado 1.1 de este módulo didáctico.


estado disponible, pero no porque exista alguna preferencia que se pueda ge-

neralizar a otros usuarios.

Lo que importa de las herramientas informatizadas para la ayuda a la pla-

nificación de proyectos es que todas ofrecen la posibilidad de mostrar el

diagrama PERT (o red de actividades) y marcar, además, el camino crítico

de manera automática. También ofrecen una gestión de recursos completa

y un montón de diagramas y listas (que aumentan día a día) que permiten

incluso realizar una presentación brillante y muy profesional de la planifi-

cación de un proyecto.

1.3. La planificación de un proyecto informático

En la planificación de un proyecto informático, además del diagrama PERT, se

suele utilizar una especie de diagrama temporal llamado diagrama de Gantt.

En el caso del proyecto ficticio que se ha utilizado para exponer el PERT y el

CPM, el diagrama de Gantt sería el que se muestra en la figura siguiente:

El diagrama de Gantt es un diagrama sencillo que muestra el tiempo

en el eje de abscisas, mientras que en cada línea del eje de ordenadas se

encuentran todas y cada una de las actividades que forman el proyecto.

En la parte izquierda se escribe el nombre de las actividades, mientras

que en la parte derecha se marca una línea desde la fecha inicial hasta

la fecha final de cada actividad.

Podéis ver el proyecto ficticio propuesto en el subapartado 1.1 de este módulo didáctico.


En realidad, la mayoría de herramientas informatizadas de ayuda a la planifi-

cación utilizan el diagrama de Gantt como marco de referencia para introducir

los datos de las diferentes tareas o actividades que forman la WBS del proyecto.

Previamente, sin embargo, debe establecerse el calendario del proyecto para

marcar las fechas que no son laborables o cualquier incidencia laboral. Las he-

rramientas informatizadas ofrecen también diagramas basados en el calenda-

rio para marcar los días de inicio y final de cada tarea, aunque el diagrama de

Gantt es suficientemente completo en este aspecto.

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

tiempo es el siguiente:

1) Establecer el calendario de días laborables de todo el proyecto y, si es nece-

sario, de cada persona del equipo (recurso).

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

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

4) Establecer las precedencias entre las tareas.

5) Realizar el diagrama de Gantt o PERT (red de actividades), preferentemente

con una herramienta informatizada para la ayuda a la planificación de proyectos.

Para finalizar, es importante saber que, tal como se ha llevado a cabo con las

actividades Inicio y Final, de duración nula, conviene añadir siempre algunas

actividades ficticias con duración nula como hitos de control para establecer

momentos concretos en los que es necesario recopilar los datos y efectuar un

balance de la gestión del proyecto. Cuando el proyecto dispone de fases y eta-

pas diferentes, añadir un hito de control al final de cada fase sería lo más co-

rrecto, aunque muchas veces se ponen hitos temporales de control: uno cada

dos semanas, uno cada mes, etc., según la duración total del proyecto.


precedencias

Conviene señalar que a la hora de establecer precedencias, las hay que son ló-

gicas y las hay que surgen, en el caso concreto de los proyectos informáticos,

de la gestión de los recursos.

Por ejemplo, en el diagrama de Gantt de la figura anterior hemos imaginado que

es posible efectuar simultáneamente las tareas 2 (establecer los requerimientos) y

3 (seleccionar los drivers). Sin embargo, si las dos las debe realizar la misma perso-

na, este diagrama de Gantt nos dice que esta persona tiene una jornada de dieci-

séis horas y no de ocho como es habitual. No parece, pues, posible.

Podéis ver la WBS en el subapartado 2.2 del módulo “Estimación de costes de un proyecto informático” de esta asignatura.

Las ayudas típicas...

... que ofrecen las herramientas informatizadas de planificación y seguimiento de proyectos son los diagramas PERT, los de Gantt y los de calendario.

Podéis ver el subapartad 1.3.1 de este módulo didáctico.

Ejemplo de precedencia lógica

Un caso sencillo de preceden-cia lógica es que no se puede codificar un programa si su cuaderno de cargas no seha finalizado.


En realidad, la mayoría de herramientas informatizadas de ayuda a la planifi-

cación utilizan el diagrama de Gantt como marco de referencia para introducir

los datos de las diferentes tareas o actividades que forman la WBS del proyecto.

Previamente, sin embargo, debe establecerse el calendario del proyecto para

marcar las fechas que no son laborables o cualquier incidencia laboral. Las he-

rramientas informatizadas ofrecen también diagramas basados en el calenda-

rio para marcar los días de inicio y final de cada tarea, aunque el diagrama de

Gantt es suficientemente completo en este aspecto.

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

tiempo es el siguiente:

1) Establecer el calendario de días laborables de todo el proyecto y, si es nece-

sario, de cada persona del equipo (recurso).

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

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

4) Establecer las precedencias entre las tareas.

5) Realizar el diagrama de Gantt o PERT (red de actividades), preferentemente

con una herramienta informatizada para la ayuda a la planificación de proyectos.

Para finalizar, es importante saber que, tal como se ha llevado a cabo con las

actividades Inicio y Final, de duración nula, conviene añadir siempre algunas

actividades ficticias con duración nula como hitos de control para establecer

momentos concretos en los que es necesario recopilar los datos y efectuar un

balance de la gestión del proyecto. Cuando el proyecto dispone de fases y eta-

pas diferentes, añadir un hito de control al final de cada fase sería lo más co-

rrecto, aunque muchas veces se ponen hitos temporales de control: uno cada

dos semanas, uno cada mes, etc., según la duración total del proyecto.


precedencias

Conviene señalar que a la hora de establecer precedencias, las hay que son ló-

gicas y las hay que surgen, en el caso concreto de los proyectos informáticos,

de la gestión de los recursos.

Por ejemplo, en el diagrama de Gantt de la figura anterior hemos imaginado que

es posible efectuar simultáneamente las tareas 2 (establecer los requerimientos) y

3 (seleccionar los drivers). Sin embargo, si las dos las debe realizar la misma perso-

na, este diagrama de Gantt nos dice que esta persona tiene una jornada de dieci-

séis horas y no de ocho como es habitual. No parece, pues, posible.

Podéis ver la WBS en el subapartado 2.2 del módulo “Estimación de costes de un proyecto informático” de esta asignatura.

Las ayudas típicas...

... que ofrecen las herramientas informatizadas de planificación y seguimiento de proyectos son los diagramas PERT, los de Gantt y los de calendario.

Podéis ver el subapartad 1.3.1 de este módulo didáctico.

Ejemplo de precedencia lógica

Un caso sencillo de preceden-cia lógica es que no se puede codificar un programa si su cuaderno de cargas no seha finalizado.


En el caso de los proyectos informáticos de construcción de software, los recursos

son las personas, los profesionales informáticos que forman el equipo del proyec-

to. Se ha de procurar que nadie deba trabajar más de una jornada por culpa de una

planificación incompleta que no ha tenido en cuenta los recursos.

De hecho, el diagrama de Gantt de la figura anterior sería realista si imagina-

mos que disponemos de tres personas en el equipo del proyecto:

1) Una primera persona podría llevar a cabo las tareas 2 (establecer los reque-

rimientos), 4 (realizar el diseño), 7 (codificar) y 9 (probar el producto).

2) Un segundo miembro del equipo se podría encargar de las tareas 3 (selec-

cionar los drivers) y 6 (probar los drivers) y, tal vez, participar también en la ac-

tividad 9 (probar el producto).

3) Para no tener problemas de jornada doble, una tercera persona del equipo

debería encargarse de las actividades 5 (recoger datos) y 8 (elaborar la docu-

mentación).

La figura siguiente muestra una modificación sencilla en el caso de que el equi-

po del proyecto estuviera formado por dos miembros. Para evitar jornadas do-

bles de los miembros del equipo, se han tenido que introducir nuevas

precedencias: provocar que la actividad 5 (recoger datos) dependa de la 6 (pro-

bar los drivers) y, también, que la actividad 8 (Elaborar la documentación) de-

penda de la 5 (recoger datos), para conseguir que las realice la misma persona.

Por ello, en la planificación temporal de proyectos informáticos, ade-

más de las precedencias lógicas, es necesario añadir otras nuevas que

provienen de la consideración de los recursos y de su utilización.

Actividades con precedencias adicionales para evitar jornadas dobles

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

estimada Precedencias

1 Inicio 0 - -

2 Establecer los requerimientos 3 1 A

3 Seleccionar los drivers 2 1 B

4 Realizar el diseño 4 2 A

5 Recoger datos 2 2, 3 y 6 B

6 Probar los drivers 6 3 B

7 Codificar 4 4 A

8 Elaborar la documentación 2 4 y 5 B

9 Probar el producto 4 5, 6 y 7 A

10 Final 0 - -


En el caso de los proyectos informáticos de construcción de software, los recursos

son las personas, los profesionales informáticos que forman el equipo del proyec-

to. Se ha de procurar que nadie deba trabajar más de una jornada por culpa de una

planificación incompleta que no ha tenido en cuenta los recursos.

De hecho, el diagrama de Gantt de la figura anterior sería realista si imagina-

mos que disponemos de tres personas en el equipo del proyecto:

1) Una primera persona podría llevar a cabo las tareas 2 (establecer los reque-

rimientos), 4 (realizar el diseño), 7 (codificar) y 9 (probar el producto).

2) Un segundo miembro del equipo se podría encargar de las tareas 3 (selec-

cionar los drivers) y 6 (probar los drivers) y, tal vez, participar también en la ac-

tividad 9 (probar el producto).

3) Para no tener problemas de jornada doble, una tercera persona del equipo

debería encargarse de las actividades 5 (recoger datos) y 8 (elaborar la docu-

mentación).

La figura siguiente muestra una modificación sencilla en el caso de que el equi-

po del proyecto estuviera formado por dos miembros. Para evitar jornadas do-

bles de los miembros del equipo, se han tenido que introducir nuevas

precedencias: provocar que la actividad 5 (recoger datos) dependa de la 6 (pro-

bar los drivers) y, también, que la actividad 8 (Elaborar la documentación) de-

penda de la 5 (recoger datos), para conseguir que las realice la misma persona.

Por ello, en la planificación temporal de proyectos informáticos, ade-

más de las precedencias lógicas, es necesario añadir otras nuevas que

provienen de la consideración de los recursos y de su utilización.

Actividades con precedencias adicionales para evitar jornadas dobles

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

estimada Precedencias

1 Inicio 0 - -

2 Establecer los requerimientos 3 1 A

3 Seleccionar los drivers 2 1 B

4 Realizar el diseño 4 2 A

5 Recoger datos 2 2, 3 y 6 B

6 Probar los drivers 6 3 B

7 Codificar 4 4 A

8 Elaborar la documentación 2 4 y 5 B

9 Probar el producto 4 5, 6 y 7 A

10 Final 0 - -


La tabla muestra, en negrita, las precedencias adicionales introducidas para

evitar la jornada doble de un miembro del equipo. También indica el recurso

(la persona miembro del equipo) que realizará cada actividad.

Cabe decir que, aunque en este ejemplo no ha ocurrido, estas precedencias

adicionales suelen cambiar a menudo el camino crítico e incluso la duración

global del proyecto. De hecho, a la hora de planificar un proyecto se juega con

los recursos disponibles (teniendo en cuenta el coste) y las precedencias de ac-

tividades hasta que se encuentra un resultado aceptable.

Una vez terminada la planificación, finaliza la calificación y ya se dispone

de los objetivos del proyecto informático: un primer boceto de las funcio-

nalidades, los plazos de todo el proyecto y de cada actividad de la WBS y el

presupuesto, obtenido básicamente del precio por hora de cada uno de los

profesionales que forman parte del equipo del proyecto y del número de

horas de trabajo que les han sido asignadas.


La tabla muestra, en negrita, las precedencias adicionales introducidas para

evitar la jornada doble de un miembro del equipo. También indica el recurso

(la persona miembro del equipo) que realizará cada actividad.

Cabe decir que, aunque en este ejemplo no ha ocurrido, estas precedencias

adicionales suelen cambiar a menudo el camino crítico e incluso la duración

global del proyecto. De hecho, a la hora de planificar un proyecto se juega con

los recursos disponibles (teniendo en cuenta el coste) y las precedencias de ac-

tividades hasta que se encuentra un resultado aceptable.

Una vez terminada la planificación, finaliza la calificación y ya se dispone

de los objetivos del proyecto informático: un primer boceto de las funcio-

nalidades, los plazos de todo el proyecto y de cada actividad de la WBS y el

presupuesto, obtenido básicamente del precio por hora de cada uno de los

profesionales que forman parte del equipo del proyecto y del número de

horas de trabajo que les han sido asignadas.


2. Seguimiento y control de un proyecto informático

Una vez iniciado el proyecto informático, la tarea de gestión consiste en conseguir

que las previsiones se cumplan y, en caso de que no sea así, poder detectar lo an-

tes posible las desviaciones que se deben producir para poder encontrarles una

solución.

Para conseguir todo esto, es imprescindible comparar periódicamente la reali-

dad del desarrollo del proyecto con la previsión disponible, ya sea la inicial o

cualquiera de las nuevas previsiones que se hayan debido realizar al detectar

errores en la estimación o la planificación iniciales.

El objetivo declarado del proyecto es alcanzar unas funcionalidades en unos

plazos determinados y habiéndolas presupuestado. La actividad de seguimien-

to y control del proyecto debe conseguir detectar los problemas con la máxi-

ma antelación posible para poder reajustar la estimación y la planificación y,

en definitiva, cambiar el proyecto modificando los objetivos.

El seguimiento pretende una anticipación, no una constatación

Con el seguimiento de un proyecto informático no se trata de constatar si en un momen-to determinado del proyecto se llevan dos meses de retraso, porque entonces ya sería de-masiado tarde. Lo que importa es poder decir, por ejemplo, que “aunque actualmentevamos suficientemente bien, si continuamos así de aquí a tres meses se podrá constatarun mes de retraso en el desarrollo del proyecto”. Sólo con una previsión anticipada deeste tipo se pueden tomar las decisiones adecuadas para tratar de salvar las previsionesdel proyecto.

En los hitos de control introducidos en la planificación (bien sea al final de

fases o etapas de proyecto, o bien de manera periódica) es cuando debemos

plantearnos, entre otras cosas, lo siguiente:

• Si conviene rehacer la descomposición del proyecto en tareas (WBS) o no,

posiblemente con la intención de incluir algunas no previstas en el mo-

mento inicial, pero que son totalmente necesarias e imprescindibles a me-

dida que avanza el proyecto.

El objetivo del seguimiento y el control del proyecto informático es

conseguir que no falle y, además, que se desarrolle según la planifica-

ción fijada previamente.

La importancia del seguimiento del proyecto informático radica, pues,

en el hecho de poder anticipar los problemas.


2. Seguimiento y control de un proyecto informático

Una vez iniciado el proyecto informático, la tarea de gestión consiste en conseguir

que las previsiones se cumplan y, en caso de que no sea así, poder detectar lo an-

tes posible las desviaciones que se deben producir para poder encontrarles una

solución.

Para conseguir todo esto, es imprescindible comparar periódicamente la reali-

dad del desarrollo del proyecto con la previsión disponible, ya sea la inicial o

cualquiera de las nuevas previsiones que se hayan debido realizar al detectar

errores en la estimación o la planificación iniciales.

El objetivo declarado del proyecto es alcanzar unas funcionalidades en unos

plazos determinados y habiéndolas presupuestado. La actividad de seguimien-

to y control del proyecto debe conseguir detectar los problemas con la máxi-

ma antelación posible para poder reajustar la estimación y la planificación y,

en definitiva, cambiar el proyecto modificando los objetivos.

El seguimiento pretende una anticipación, no una constatación

Con el seguimiento de un proyecto informático no se trata de constatar si en un momen-to determinado del proyecto se llevan dos meses de retraso, porque entonces ya sería de-masiado tarde. Lo que importa es poder decir, por ejemplo, que “aunque actualmentevamos suficientemente bien, si continuamos así de aquí a tres meses se podrá constatarun mes de retraso en el desarrollo del proyecto”. Sólo con una previsión anticipada deeste tipo se pueden tomar las decisiones adecuadas para tratar de salvar las previsionesdel proyecto.

En los hitos de control introducidos en la planificación (bien sea al final de

fases o etapas de proyecto, o bien de manera periódica) es cuando debemos

plantearnos, entre otras cosas, lo siguiente:

• Si conviene rehacer la descomposición del proyecto en tareas (WBS) o no,

posiblemente con la intención de incluir algunas no previstas en el mo-

mento inicial, pero que son totalmente necesarias e imprescindibles a me-

dida que avanza el proyecto.

El objetivo del seguimiento y el control del proyecto informático es

conseguir que no falle y, además, que se desarrolle según la planifica-

ción fijada previamente.

La importancia del seguimiento del proyecto informático radica, pues,

en el hecho de poder anticipar los problemas.


• Si conviene volver a efectuar la estimación del esfuerzo o no, en caso de que

se constate que la productividad que se obtiene es diferente de la prevista.

• Si conviene cambiar algunos de los objetivos del proyecto o no, para tratar

de mantener los otros.

• Si conviene llevar a cabo una nueva calificación del proyecto o no, para te-

ner en cuenta los datos de nuevas tareas o de una productividad diferente

de la prevista que la realidad nos aporte.

Como se dice en otro módulo, los problemas de una deficiente calificación ini-

cial se intentan “resolver” demasiadas veces de puertas afuera, haciendo todo

lo posible para cumplir con los plazos y el presupuesto a fuerza de reducir las

funcionalidades del proyecto, sobre todo las funcionalidades de calidad. Ésta

es, evidentemente, una solución totalmente falsa que simplemente aplaza los

problemas hasta la fase de mantenimiento, al mismo tiempo que consigue a

menudo que los problemas se conviertan en mucho más graves y que tengan

una solución mucho más difícil.

2.1. Las hojas de actividad y el informe de situación

Para poder llevar a cabo una comparación correcta entre la realidad y la previ-

sión, es necesario “saber cómo va” el proyecto y, con esta finalidad, se deben

recoger datos de su desarrollo. Con estos datos del seguimiento será posible te-

ner elementos para tomar decisiones de cambio de los objetivos del proyecto

y, en definitiva, controlar el desarrollo. La práctica habitual es recoger estos

datos del seguimiento en unas hojas de actividad.

Conviene recoger de manera individual por cada tarea y cada persona involu-

crada estos datos de seguimiento, a partir de los cuales el jefe de proyecto*

debe elaborar los datos globales que permiten construir un informe de situa-

ción del proyecto. Este informe se suele llevar a cabo para cada uno de los hitos

de control establecidos.

La hoja de actividad es el conjunto de datos individuales de segui-

miento de un proyecto, donde cada miembro del equipo señala las

horas que ha ocupado en cada una de las tareas previstas de la WBS

que se le han asignado.

Un informe de situación es el resumen de la realidad de un proyecto a

partir de los datos obtenidos de las hojas de actividad y de su compara-

ción con la planificación vigente.

Podéis ver los problemas deuna deficiente calificación en el subapartado 1.1 del módulo “El proyecto informático de construcciónde software”.

* Si conviene, ayudado de un sistema informático ad hoc.


• Si conviene volver a efectuar la estimación del esfuerzo o no, en caso de que

se constate que la productividad que se obtiene es diferente de la prevista.

• Si conviene cambiar algunos de los objetivos del proyecto o no, para tratar

de mantener los otros.

• Si conviene llevar a cabo una nueva calificación del proyecto o no, para te-

ner en cuenta los datos de nuevas tareas o de una productividad diferente

de la prevista que la realidad nos aporte.

Como se dice en otro módulo, los problemas de una deficiente calificación ini-

cial se intentan “resolver” demasiadas veces de puertas afuera, haciendo todo

lo posible para cumplir con los plazos y el presupuesto a fuerza de reducir las

funcionalidades del proyecto, sobre todo las funcionalidades de calidad. Ésta

es, evidentemente, una solución totalmente falsa que simplemente aplaza los

problemas hasta la fase de mantenimiento, al mismo tiempo que consigue a

menudo que los problemas se conviertan en mucho más graves y que tengan

una solución mucho más difícil.

2.1. Las hojas de actividad y el informe de situación

Para poder llevar a cabo una comparación correcta entre la realidad y la previ-

sión, es necesario “saber cómo va” el proyecto y, con esta finalidad, se deben

recoger datos de su desarrollo. Con estos datos del seguimiento será posible te-

ner elementos para tomar decisiones de cambio de los objetivos del proyecto

y, en definitiva, controlar el desarrollo. La práctica habitual es recoger estos

datos del seguimiento en unas hojas de actividad.

Conviene recoger de manera individual por cada tarea y cada persona involu-

crada estos datos de seguimiento, a partir de los cuales el jefe de proyecto*

debe elaborar los datos globales que permiten construir un informe de situa-

ción del proyecto. Este informe se suele llevar a cabo para cada uno de los hitos

de control establecidos.

La hoja de actividad es el conjunto de datos individuales de segui-

miento de un proyecto, donde cada miembro del equipo señala las

horas que ha ocupado en cada una de las tareas previstas de la WBS

que se le han asignado.

Un informe de situación es el resumen de la realidad de un proyecto a

partir de los datos obtenidos de las hojas de actividad y de su compara-

ción con la planificación vigente.

Podéis ver los problemas deuna deficiente calificación en el subapartado 1.1 del módulo “El proyecto informático de construcciónde software”.

* Si conviene, ayudado de un sistema informático ad hoc.


Cuando una tarea finaliza, el jefe de proyecto puede saber el esfuerzo real que

ha supuesto realizarla y lo puede comparar con el esfuerzo previsto, para ver

si las estimaciones de productividad eran optimistas, pesimistas o realistas. El

hecho de disponer de esta productividad real es precisamente lo que debe per-

mitir anticipar los problemas.

Con los datos reales obtenidos de la hoja de actividad, el jefe de proyecto rea-

liza el seguimiento, a menudo mediante herramientas informatizadas* que

permiten, para cada actividad del proyecto, introducir las fechas reales del tra-

bajo acabado o el porcentaje del trabajo hecho en cada momento. Estas herra-

mientas ofrecen también una gran cantidad de listas y gráficos que, una vez

escogidos los que son útiles, ayudan a las tareas de seguimiento y control del

proyecto.

2.2. La ley de Brooks

Aunque ya se trata detenidamente en otros módulos, conviene recordar aquí

lo que se ha denominado ley de Brooks, una teoría que proviene de la experien-

cia del autor de la obra The Mythical Man-Month (1975) como director del pro-

ceso de construcción del sistema operativo de IBM 360.

Es necesario entender esta advertencia en el sentido de que no se pueden inter-

cambiar hombres y meses. Y también se debe entender que la ley no es algo

matemático, sino sólo una advertencia para los que todavía no han captado el

mito del hombre-mes.

En cualquier proyecto (pensemos, por ejemplo, en la construcción de una ca-

sa), cuando éste va retrasado, una solución para mantener los plazos, aunque

pueda costar más dinero, es añadir personal (por ejemplo, más albañiles en el

caso de la construcción de una casa).

La ley de Brooks que acabamos de ver nos advierte de que no sucede lo mismo

en los proyectos informáticos y que, como ya hemos dicho en otros módulos

didácticos, en un proyecto informático el reparto de los esfuerzos en el tiempo

no puede ser cualquiera, sino que tiene una forma fijada por la curva de Ra-

yleigh/Norden. Posiblemente, Brooks fue el primero en constatar que en un

proyecto informático que iba retrasado, el hecho de añadir personal creó más

problemas de los que resolvió, aunque, evidentemente, esto no debe ocurrir

siempre.

La ley de Brooks es una advertencia para no caer en el mito del hom-

bre-mes, que a menudo tiene formulaciones tan sorprendentes como

ésta: si un proyecto va retrasado, el hecho de añadir personal es la ma-

nera más segura de retrasarlo todavía más.

* Como MS-PROJECT o SUPERPROJECT.

Podéis ver los módulos “El proyecto informático de construcción de software” y “Estimación de costesde un proyecto informático” de esta asignatura. En concreto, podéis ver el mito del hombre-mes en el subapartado 1.3.2 de este último módulo.

Lectura recomendada

La referencia siguiente os permitirá encontrar la obra mencionada en el texto sobre el mito del hombre-mes:F. Brooks (1975). The mythical man-month. Reading: Addison-Wesley.

Podéis ver la curva de Rayleigh/Norden en el subapartado 2.3.3 del módulo “Estimación de costes de un proyecto informático” deesta asignatura.


Cuando una tarea finaliza, el jefe de proyecto puede saber el esfuerzo real que

ha supuesto realizarla y lo puede comparar con el esfuerzo previsto, para ver

si las estimaciones de productividad eran optimistas, pesimistas o realistas. El

hecho de disponer de esta productividad real es precisamente lo que debe per-

mitir anticipar los problemas.

Con los datos reales obtenidos de la hoja de actividad, el jefe de proyecto rea-

liza el seguimiento, a menudo mediante herramientas informatizadas* que

permiten, para cada actividad del proyecto, introducir las fechas reales del tra-

bajo acabado o el porcentaje del trabajo hecho en cada momento. Estas herra-

mientas ofrecen también una gran cantidad de listas y gráficos que, una vez

escogidos los que son útiles, ayudan a las tareas de seguimiento y control del

proyecto.

2.2. La ley de Brooks

Aunque ya se trata detenidamente en otros módulos, conviene recordar aquí

lo que se ha denominado ley de Brooks, una teoría que proviene de la experien-

cia del autor de la obra The Mythical Man-Month (1975) como director del pro-

ceso de construcción del sistema operativo de IBM 360.

Es necesario entender esta advertencia en el sentido de que no se pueden inter-

cambiar hombres y meses. Y también se debe entender que la ley no es algo

matemático, sino sólo una advertencia para los que todavía no han captado el

mito del hombre-mes.

En cualquier proyecto (pensemos, por ejemplo, en la construcción de una ca-

sa), cuando éste va retrasado, una solución para mantener los plazos, aunque

pueda costar más dinero, es añadir personal (por ejemplo, más albañiles en el

caso de la construcción de una casa).

La ley de Brooks que acabamos de ver nos advierte de que no sucede lo mismo

en los proyectos informáticos y que, como ya hemos dicho en otros módulos

didácticos, en un proyecto informático el reparto de los esfuerzos en el tiempo

no puede ser cualquiera, sino que tiene una forma fijada por la curva de Ra-

yleigh/Norden. Posiblemente, Brooks fue el primero en constatar que en un

proyecto informático que iba retrasado, el hecho de añadir personal creó más

problemas de los que resolvió, aunque, evidentemente, esto no debe ocurrir

siempre.

La ley de Brooks es una advertencia para no caer en el mito del hom-

bre-mes, que a menudo tiene formulaciones tan sorprendentes como

ésta: si un proyecto va retrasado, el hecho de añadir personal es la ma-

nera más segura de retrasarlo todavía más.

* Como MS-PROJECT o SUPERPROJECT.

Podéis ver los módulos “El proyecto informático de construcción de software” y “Estimación de costesde un proyecto informático” de esta asignatura. En concreto, podéis ver el mito del hombre-mes en el subapartado 1.3.2 de este último módulo.

Lectura recomendada

La referencia siguiente os permitirá encontrar la obra mencionada en el texto sobre el mito del hombre-mes:F. Brooks (1975). The mythical man-month. Reading: Addison-Wesley.

Podéis ver la curva de Rayleigh/Norden en el subapartado 2.3.3 del módulo “Estimación de costes de un proyecto informático” deesta asignatura.


La explicación tradicional del fenómeno es que en un proyecto informático se

crean unos circuitos internos de comunicación para comprender qué se reali-

za. Entre los trabajos que se deben efectuar se encuentra el de comunicar a

otros miembros del equipo aquello que uno ha decidido y que condiciona el

trabajo del resto. El hecho de añadir personal nuevo a mitad de proyecto o

cuando ya se está acabando provoca que haya personas nuevas que no cono-

cen qué se realiza y que, además, crean necesidades adicionales de comunica-

ción que pueden consumir incluso una parte de los recursos que ya existen,

simplemente porque los miembros “viejos” del equipo de proyecto han de ex-

plicar a los “nuevos” qué se lleva a cabo y cómo se realiza. Según Brooks, estas

necesidades adicionales de comunicación pueden provocar incluso que con

más personas se tarde más tiempo.


La explicación tradicional del fenómeno es que en un proyecto informático se

crean unos circuitos internos de comunicación para comprender qué se reali-

za. Entre los trabajos que se deben efectuar se encuentra el de comunicar a

otros miembros del equipo aquello que uno ha decidido y que condiciona el

trabajo del resto. El hecho de añadir personal nuevo a mitad de proyecto o

cuando ya se está acabando provoca que haya personas nuevas que no cono-

cen qué se realiza y que, además, crean necesidades adicionales de comunica-

ción que pueden consumir incluso una parte de los recursos que ya existen,

simplemente porque los miembros “viejos” del equipo de proyecto han de ex-

plicar a los “nuevos” qué se lleva a cabo y cómo se realiza. Según Brooks, estas

necesidades adicionales de comunicación pueden provocar incluso que con

más personas se tarde más tiempo.


3. Aseguramiento de la calidad en un proyecto informático

Desgraciadamente, tal como comentamos en otro módulo, la calidad del soft-

ware construido no es siempre la deseable. Hemos visto algunas de las razones

que pueden ser la causa, aun así debemos evitar que ello ocurra.

Han transcurrido ya un par de décadas desde que se comenzó a hablar explí-

citamente de aseguramiento de la calidad del software.

Terminología confusa

Con respecto al término aseguramiento de la calidad del software (software quality assuran-ce), a veces se ha traducido del inglés como garantía de calidad del software, aunque dife-rentes autores se oponen porque crea confusión con el concepto, mucho más tradicional,de garantía de los productos (no debemos olvidar que un software es un producto que sevende y que, como tal, puede tener una garantía).

Ya en 1977, Mc Call estableció algunos factores para analizar la calidad del

software * y, desde entonces, el procedimiento habitual ha sido elaborar listas

de control** complejas y detalladas para revisar todo el proceso de construc-

ción del software.

Actualmente, el aseguramiento de calidad de software consiste en introducir

unos procedimientos y unas metodologías de construcción que tratan de ga-

rantizar, a priori, que el proceso es correcto y seguro, y que el mismo proceso

de construcción pueda garantizar también, en cierta manera, que el producto

que se obtiene es un software de la mejor calidad.

En general, la calidad del software necesita que exista un acuerdo total entre

los requerimientos (tanto funcionales como de rendimiento) y el software fi-

nal. Esto implica la utilización de estándares de desarrollo documentados ex-

plícitamente y de procedimientos concretos de gestión de todo el proceso de

construcción de software.

El aseguramiento de la calidad del software es, según AENOR –la entidad

española de normalización–, el conjunto de actividades planificadas y sis-

temáticas necesarias para aportar la confianza de que el producto (software)

cumplirá los requerimientos de calidad establecidos.

La calidad del software es, según el IIEE (Instituto de Ingenieros Eléc-

tricos y Electrónicos), el grado en el que un sistema, componente o pro-

ceso cumple con los requerimientos especificados y con las necesidades

o expectativas del cliente o usuario.

Podéis ver el módulo “El proyecto informático de construcción de software” de esta asignatura.

* En inglés, software quality factors.** En inglés, check list.

Tasa cero de errores

En cuanto a la obtención de software de la mejor calidad, se ha llegado a hablar, incluso, de procesos de construcción que alcanzarían una tasa cerode errores.


3. Aseguramiento de la calidad en un proyecto informático

Desgraciadamente, tal como comentamos en otro módulo, la calidad del soft-

ware construido no es siempre la deseable. Hemos visto algunas de las razones

que pueden ser la causa, aun así debemos evitar que ello ocurra.

Han transcurrido ya un par de décadas desde que se comenzó a hablar explí-

citamente de aseguramiento de la calidad del software.

Terminología confusa

Con respecto al término aseguramiento de la calidad del software (software quality assuran-ce), a veces se ha traducido del inglés como garantía de calidad del software, aunque dife-rentes autores se oponen porque crea confusión con el concepto, mucho más tradicional,de garantía de los productos (no debemos olvidar que un software es un producto que sevende y que, como tal, puede tener una garantía).

Ya en 1977, Mc Call estableció algunos factores para analizar la calidad del

software * y, desde entonces, el procedimiento habitual ha sido elaborar listas

de control** complejas y detalladas para revisar todo el proceso de construc-

ción del software.

Actualmente, el aseguramiento de calidad de software consiste en introducir

unos procedimientos y unas metodologías de construcción que tratan de ga-

rantizar, a priori, que el proceso es correcto y seguro, y que el mismo proceso

de construcción pueda garantizar también, en cierta manera, que el producto

que se obtiene es un software de la mejor calidad.

En general, la calidad del software necesita que exista un acuerdo total entre

los requerimientos (tanto funcionales como de rendimiento) y el software fi-

nal. Esto implica la utilización de estándares de desarrollo documentados ex-

plícitamente y de procedimientos concretos de gestión de todo el proceso de

construcción de software.

El aseguramiento de la calidad del software es, según AENOR –la entidad

española de normalización–, el conjunto de actividades planificadas y sis-

temáticas necesarias para aportar la confianza de que el producto (software)

cumplirá los requerimientos de calidad establecidos.

La calidad del software es, según el IIEE (Instituto de Ingenieros Eléc-

tricos y Electrónicos), el grado en el que un sistema, componente o pro-

ceso cumple con los requerimientos especificados y con las necesidades

o expectativas del cliente o usuario.

Podéis ver el módulo “El proyecto informático de construcción de software” de esta asignatura.

* En inglés, software quality factors.** En inglés, check list.

Tasa cero de errores

En cuanto a la obtención de software de la mejor calidad, se ha llegado a hablar, incluso, de procesos de construcción que alcanzarían una tasa cerode errores.


El tratamiento del aseguramiento de la calidad se centra tradicionalmente en

las inspecciones y revisiones formales, junto con las llamadas reuniones de re-

paso*. Uno de los objetivos fundamentales es, evidentemente, obtener la ca-

racterística implícita de la fiabilidad y, sobre todo, un mantenimiento fácil del

producto obtenido, teniendo en cuenta la larga duración de la etapa de man-

tenimiento en el ciclo de vida del software.

La ISO* es la organización internacional encargada de crear todo tipo de es-

tándares. En concreto, los estándares de calidad forman parte de la norma

ISO 9000, que describe los elementos que debe tener un sistema de asegu-

ramiento de la calidad con el fin de que se puedan aplicar a cualquier ne-

gocio o actividad.

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

ingeniería del software y expone hasta veinte exigencias que debe cumplir un

buen sistema de calidad. Recientemente, la nueva versión de la norma ISO

9000-3, que data de 1996, quiere proporcionar una guía y una ayuda con vis-

tas a la aplicación de las exigencias de la ISO 9001 en el caso de una industria

de fabricación y/o venta de software.

En general, un sistema de aseguramiento de la calidad del software

incluye una estructura organizativa que implica establecer responsabi-

lidades, procedimientos y procesos de construcción y revisión, y tam-

bién garantizar la disponibilidad de los recursos de todo tipo necesarios

para efectuar una gestión de calidad que ofrezca un software de calidad.

* En inglés, walkthroughs.

* International Organization for Standarization.

Lectura recomendada

Para más detalles, podéis consultar la obra siguiente:R. Kehoe; A. Jarvis (1996). ISO 9000-3: A Tool for Software Product and Process Improvement. Nueva York: Springer.


El tratamiento del aseguramiento de la calidad se centra tradicionalmente en

las inspecciones y revisiones formales, junto con las llamadas reuniones de re-

paso*. Uno de los objetivos fundamentales es, evidentemente, obtener la ca-

racterística implícita de la fiabilidad y, sobre todo, un mantenimiento fácil del

producto obtenido, teniendo en cuenta la larga duración de la etapa de man-

tenimiento en el ciclo de vida del software.

La ISO* es la organización internacional encargada de crear todo tipo de es-

tándares. En concreto, los estándares de calidad forman parte de la norma

ISO 9000, que describe los elementos que debe tener un sistema de asegu-

ramiento de la calidad con el fin de que se puedan aplicar a cualquier ne-

gocio o actividad.

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

ingeniería del software y expone hasta veinte exigencias que debe cumplir un

buen sistema de calidad. Recientemente, la nueva versión de la norma ISO

9000-3, que data de 1996, quiere proporcionar una guía y una ayuda con vis-

tas a la aplicación de las exigencias de la ISO 9001 en el caso de una industria

de fabricación y/o venta de software.

En general, un sistema de aseguramiento de la calidad del software

incluye una estructura organizativa que implica establecer responsabi-

lidades, procedimientos y procesos de construcción y revisión, y tam-

bién garantizar la disponibilidad de los recursos de todo tipo necesarios

para efectuar una gestión de calidad que ofrezca un software de calidad.

* En inglés, walkthroughs.

* International Organization for Standarization.

Lectura recomendada

Para más detalles, podéis consultar la obra siguiente:R. Kehoe; A. Jarvis (1996). ISO 9000-3: A Tool for Software Product and Process Improvement. Nueva York: Springer.


Resumen

La planificación temporal de un proyecto informático arranca de la des-

composición en tareas del proyecto (WBS), la estimación del esfuerzo de cada

una y las precedencias entre las tareas o actividades. Esta información se dis-

pone en un diagrama PERT (o red de actividades) y se obtiene así el camino

crítico formado por la cadena de actividades problemáticas que no tienen mar-

gen de tiempo y que determinan la duración global del proyecto.

En el caso de los proyectos informáticos, además de las precedencias lógicas,

es necesario añadir nuevas precedencias entre actividades para conseguir un

buen uso de los recursos, es decir, de los profesionales que forman el equipo

de proyecto y evitar que se produzcan casos de jornada doble.

A menudo, las herramientas informáticas para planificar y llevar a cabo el se-

guimiento de proyectos ofrecen diferentes diagramas (de Gantt, PERT, de ca-

lendario, etc.) y una variedad amplia de listas.

El seguimiento y el control del proyecto se realizan comparando los datos

reales (obtenidos de las hojas de actividad en las que cada miembro del equipo

del proyecto detalla el tiempo que ha dedicado a cada tarea) con los datos pre-

vistos en la planificación vigente. Si existen nuevos datos sobre productividad

o deben llevarse a cabo tareas no previstas antes, puede ser necesario efectuar

una nueva calificación del proyecto (estimación de costes y planificación) y re-

visar los objetivos: las funcionalidades, los plazos y el presupuesto.

La ley de Brooks intenta evitar la incomprensión sobre el mito del hombre-

mes y afirma que añadir más personal a un proyecto retrasado no siempre

mejora las cosas.

El aseguramiento de la calidad del software es el conjunto de actividades de

gestión y organización que permite garantizar que el proceso de construcción

del software es seguro y fiable y, por lo tanto, que el software obtenido también

será de calidad. Existen estándares internacionales sobre el aseguramiento de

la calidad en el campo de la ingeniería del software, en concreto la ISO 9001 y

la ISO 9000-3.


Resumen

La planificación temporal de un proyecto informático arranca de la des-

composición en tareas del proyecto (WBS), la estimación del esfuerzo de cada

una y las precedencias entre las tareas o actividades. Esta información se dis-

pone en un diagrama PERT (o red de actividades) y se obtiene así el camino

crítico formado por la cadena de actividades problemáticas que no tienen mar-

gen de tiempo y que determinan la duración global del proyecto.

En el caso de los proyectos informáticos, además de las precedencias lógicas,

es necesario añadir nuevas precedencias entre actividades para conseguir un

buen uso de los recursos, es decir, de los profesionales que forman el equipo

de proyecto y evitar que se produzcan casos de jornada doble.

A menudo, las herramientas informáticas para planificar y llevar a cabo el se-

guimiento de proyectos ofrecen diferentes diagramas (de Gantt, PERT, de ca-

lendario, etc.) y una variedad amplia de listas.

El seguimiento y el control del proyecto se realizan comparando los datos

reales (obtenidos de las hojas de actividad en las que cada miembro del equipo

del proyecto detalla el tiempo que ha dedicado a cada tarea) con los datos pre-

vistos en la planificación vigente. Si existen nuevos datos sobre productividad

o deben llevarse a cabo tareas no previstas antes, puede ser necesario efectuar

una nueva calificación del proyecto (estimación de costes y planificación) y re-

visar los objetivos: las funcionalidades, los plazos y el presupuesto.

La ley de Brooks intenta evitar la incomprensión sobre el mito del hombre-

mes y afirma que añadir más personal a un proyecto retrasado no siempre

mejora las cosas.

El aseguramiento de la calidad del software es el conjunto de actividades de

gestión y organización que permite garantizar que el proceso de construcción

del software es seguro y fiable y, por lo tanto, que el software obtenido también

será de calidad. Existen estándares internacionales sobre el aseguramiento de

la calidad en el campo de la ingeniería del software, en concreto la ISO 9001 y

la ISO 9000-3.



Actividades

1. Si podéis disponer de una herramienta de planificación y seguimiento de proyectos comoel MS-PROJECT, el SUPERPROJECT u otros, estudiad sus funcionalidades mediante el sis-tema de ayuda (help) y comprobad los listados que se encuentran disponibles. Como ejer-cicio concreto, introducid los datos del proyecto ficticio que hemos tratado en estemódulo y, tomando a dos o tres personas como recurso (miembros del equipo), observadlos diferentes gráficos y listados que os ofrece la herramienta.

2. Añadid las precedencias que os parezcan lógicas a los datos de actividades y el esfuerzo es-timado del caso de la contabilidad sencilla en un PC que hemos visto en otro módulo.Imaginad un equipo de un analista (que también trabaja como jefe de proyecto) y un pro-gramador, para obtener, con una herramienta como el MS-PROJECT o el SUPERPROJECT,el diagrama de Gantt y la red de actividades (diagrama PERT) del proyecto. Con los preciospor hora de analista y programador que conocéis, obtened el coste global del proyecto.

3. Intentad llevar a cabo una descomposición de tareas (WBS), una estimación de costes pa-recida a la del ejemplo de la contabilidad sencilla en un PC y una planificación en el tiem-po contando con un analista y un programador para el caso de la aplicación en unpequeño hotel.

Datos del hotel

Se quiere implementar una pequeña aplicación (simplificada) de gestión administrativa dela recepción y facturación de un hotel. La aplicación se debe ejecutar en un conjunto deordenadores personales, de tipo PC compatible, conectados en red y que comparten losdatos. 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 ala gestión informatizada de la recepción y la facturación. La ocupación de las habitacionespuede ser posterior a una reserva previa, realizada directamente por el cliente o medianteuna agencia de viajes.

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

1)Tratamientos interactivos

a)Mantenimiento del fichero de habitaciones

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

b)Gestión de reservas

Para dar de alta una reserva, hemos de introducir las fechas de la entrada y la salida y elnúmero de personas. El sistema debe ofrecer las habitaciones disponibles y aceptar y regis-trar la elección que realice el operador a partir de esta información. Los datos complemen-tarios de la reserva serán, al menos, el nombre y el DNI del titular de la reserva, el tipo dereserva (directo o por agencia), el identificador de la agencia (si procede) y el teléfono dela 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 lareserva y de la fecha de reserva. Es evidente que en una reserva puede incluirse más de unahabitación.

c) Entrada de clientes

Los clientes pueden ocupar habitaciones ya reservadas o las que puedan encontrarse dis-ponibles si no se ha realizado ninguna reserva previa. Si existe reserva previa, se asigna au-tomáticamente la habitación reservada y, en caso de que se trate de un cliente nuevo sinreserva, se consulta el estado de las habitaciones disponibles. Si es posible, se le admite laentrada 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, elDNI (o pasaporte), el domicilio y la nacionalidad, y la habitación que ocuparán. Cuandola 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 dela reserva.

Podéis ver el proyecto ficticio expuesto en el subapartado 1.1 de este módulo didáctico.

Podéis ver el ejemplo del PC en el subapartado 2.4.1 y los precios por hora de analista y programador en la actividad 3 del módulo “Estimación de costes de un proyecto informático” de esta asignatura.

Podéis ver el ejemplo del PC en el subapartado 2.4.1 del módulo “Estimación de costes de un proyecto informático” de esta asignatura.


Actividades

1. Si podéis disponer de una herramienta de planificación y seguimiento de proyectos comoel MS-PROJECT, el SUPERPROJECT u otros, estudiad sus funcionalidades mediante el sis-tema de ayuda (help) y comprobad los listados que se encuentran disponibles. Como ejer-cicio concreto, introducid los datos del proyecto ficticio que hemos tratado en estemódulo y, tomando a dos o tres personas como recurso (miembros del equipo), observadlos diferentes gráficos y listados que os ofrece la herramienta.

2. Añadid las precedencias que os parezcan lógicas a los datos de actividades y el esfuerzo es-timado del caso de la contabilidad sencilla en un PC que hemos visto en otro módulo.Imaginad un equipo de un analista (que también trabaja como jefe de proyecto) y un pro-gramador, para obtener, con una herramienta como el MS-PROJECT o el SUPERPROJECT,el diagrama de Gantt y la red de actividades (diagrama PERT) del proyecto. Con los preciospor hora de analista y programador que conocéis, obtened el coste global del proyecto.

3. Intentad llevar a cabo una descomposición de tareas (WBS), una estimación de costes pa-recida a la del ejemplo de la contabilidad sencilla en un PC y una planificación en el tiem-po contando con un analista y un programador para el caso de la aplicación en unpequeño hotel.

Datos del hotel

Se quiere implementar una pequeña aplicación (simplificada) de gestión administrativa dela recepción y facturación de un hotel. La aplicación se debe ejecutar en un conjunto deordenadores personales, de tipo PC compatible, conectados en red y que comparten losdatos. 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 ala gestión informatizada de la recepción y la facturación. La ocupación de las habitacionespuede ser posterior a una reserva previa, realizada directamente por el cliente o medianteuna agencia de viajes.

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

1)Tratamientos interactivos

a)Mantenimiento del fichero de habitaciones

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

b)Gestión de reservas

Para dar de alta una reserva, hemos de introducir las fechas de la entrada y la salida y elnúmero de personas. El sistema debe ofrecer las habitaciones disponibles y aceptar y regis-trar la elección que realice el operador a partir de esta información. Los datos complemen-tarios de la reserva serán, al menos, el nombre y el DNI del titular de la reserva, el tipo dereserva (directo o por agencia), el identificador de la agencia (si procede) y el teléfono dela 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 lareserva y de la fecha de reserva. Es evidente que en una reserva puede incluirse más de unahabitación.

c) Entrada de clientes

Los clientes pueden ocupar habitaciones ya reservadas o las que puedan encontrarse dis-ponibles si no se ha realizado ninguna reserva previa. Si existe reserva previa, se asigna au-tomáticamente la habitación reservada y, en caso de que se trate de un cliente nuevo sinreserva, se consulta el estado de las habitaciones disponibles. Si es posible, se le admite laentrada 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, elDNI (o pasaporte), el domicilio y la nacionalidad, y la habitación que ocuparán. Cuandola 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 dela reserva.

Podéis ver el proyecto ficticio expuesto en el subapartado 1.1 de este módulo didáctico.

Podéis ver el ejemplo del PC en el subapartado 2.4.1 y los precios por hora de analista y programador en la actividad 3 del módulo “Estimación de costes de un proyecto informático” de esta asignatura.

Podéis ver el ejemplo del PC en el subapartado 2.4.1 del módulo “Estimación de costes de un proyecto informático” de esta asignatura.


d)Entrada de gastos adicionales

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 lahabitació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 yhora del servicio (opcional), el importe del servicio y la habitación que soporta el cargo(siempre la del titular de la reserva).

e)Salida de clientes

La salida de clientes se efectuará a partir del número de habitación. Como resultado de estaoperació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-bitació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 realizarsiempre 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 lomás habitual es una factura única por reserva en el momento de la salida definitiva de losclientes. 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 facturacomplementaria 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-narios se presentarán semanalmente a las agencias para su liquidación. (Podéis ver la ca-dena semanal.)

2)Tratamientos diferidos

a)Cadena diaria

• Anulación de reservas caducadas. Al final de cada día se cancelarán automáticamentelas reservas que debían haber comenzado durante el día y que no hayan sido anuladasni 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-cias. (Podéis ver la cadena semanal.)

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

b)Cadena semanal

Facturación a las agencias. Al final de la semana se facturarán los cargos de alojamientode 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(que puede ser diferente para cada agencia). Además, la factura semanal para cada agenciadebe 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 pactadoprevia y separadamente con cada agencia.

c) Cadena mensual

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.

3)Volúmenes

• Número de habitaciones: 400 (70 sencillas y 330 dobles).• Número de agencias: 20.• Admisión de reservas con tres meses de antelación:– Media de reservas diarias: 15.– Media de días de estancia de los clientes: 6.– Media de cargos por servicios, por día y habitación: 5.


d)Entrada de gastos adicionales

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 lahabitació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 yhora del servicio (opcional), el importe del servicio y la habitación que soporta el cargo(siempre la del titular de la reserva).

e)Salida de clientes

La salida de clientes se efectuará a partir del número de habitación. Como resultado de estaoperació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-bitació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 realizarsiempre 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 lomás habitual es una factura única por reserva en el momento de la salida definitiva de losclientes. 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 facturacomplementaria 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-narios se presentarán semanalmente a las agencias para su liquidación. (Podéis ver la ca-dena semanal.)

2)Tratamientos diferidos

a)Cadena diaria

• Anulación de reservas caducadas. Al final de cada día se cancelarán automáticamentelas reservas que debían haber comenzado durante el día y que no hayan sido anuladasni 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-cias. (Podéis ver la cadena semanal.)

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

b)Cadena semanal

Facturación a las agencias. Al final de la semana se facturarán los cargos de alojamientode 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(que puede ser diferente para cada agencia). Además, la factura semanal para cada agenciadebe 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 pactadoprevia y separadamente con cada agencia.

c) Cadena mensual

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.

3)Volúmenes

• Número de habitaciones: 400 (70 sencillas y 330 dobles).• Número de agencias: 20.• Admisión de reservas con tres meses de antelación:– Media de reservas diarias: 15.– Media de días de estancia de los clientes: 6.– Media de cargos por servicios, por día y habitación: 5.


Ejercicios de autoevaluación

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 loque se había estimado?

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)?

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?

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

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

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?



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 loque se había estimado?

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)?

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?

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

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

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?


Solucionario


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.

2. Si el retraso de la actividad es inferior al margen, todo queda en un aumento del coste (elpersonal 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.

3. Para efectuar el diagrama PERT es necesario tener en cuenta las precedencias que la lógicadicta entre las diferentes actividades que forman la WBS del proyecto y, además, las quesean 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.

4. Existen muchos casos en los que se puede realizar una planificación ALAP, pero uno muyhabitual es cuando se conoce la fecha en la que se debe terminar el proyecto y “se tirahacia 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 olvidarseque es cada miembro del equipo quien se los proporciona y lo informa de las horas queha dedicado en cada una de las tareas que le han sido asignadas. Todos los miembros delequipo son, pues, responsables.

6. El jefe de proyecto elabora los informes de situación y compara la planificación vigentecon la información real obtenida al agregar los datos de detalle de las diferentes hojas deactividad. A menudo, sirven como documentación de base con vistas a un hito de controlpara 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éricapara 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-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 tienesiempre errores y problemas de fiabilidad y/o mantenimiento.

9. Un software es de calidad cuando cumple los requerimientos especificados y, además, sa-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 precisamenteindica cómo se debe utilizar la ISO 9001.

Glosarioactividad f Cada uno de los trabajos que se debe llevar a cabo en un proyecto y que formaparte 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 caminocrítico.

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 decalidad establecidos.

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.

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

CPM m Véase camino crítico

diagrama de Gantt m Diagrama que muestra el tiempo en el eje de abscisas, mientras queen cada línea de las ordenadas se encuentran todas y cada una de las actividades que formanel proyecto. En la parte izquierda se escribe el nombre de las actividades, mientras que en laparte derecha se marca una línea desde la fecha inicial hasta la final de cada actividad.


Solucionario


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.

2. Si el retraso de la actividad es inferior al margen, todo queda en un aumento del coste (elpersonal 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.

3. Para efectuar el diagrama PERT es necesario tener en cuenta las precedencias que la lógicadicta entre las diferentes actividades que forman la WBS del proyecto y, además, las quesean 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.

4. Existen muchos casos en los que se puede realizar una planificación ALAP, pero uno muyhabitual es cuando se conoce la fecha en la que se debe terminar el proyecto y “se tirahacia 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 olvidarseque es cada miembro del equipo quien se los proporciona y lo informa de las horas queha dedicado en cada una de las tareas que le han sido asignadas. Todos los miembros delequipo son, pues, responsables.

6. El jefe de proyecto elabora los informes de situación y compara la planificación vigentecon la información real obtenida al agregar los datos de detalle de las diferentes hojas deactividad. A menudo, sirven como documentación de base con vistas a un hito de controlpara 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éricapara 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-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 tienesiempre errores y problemas de fiabilidad y/o mantenimiento.

9. Un software es de calidad cuando cumple los requerimientos especificados y, además, sa-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 precisamenteindica cómo se debe utilizar la ISO 9001.

Glosarioactividad f Cada uno de los trabajos que se debe llevar a cabo en un proyecto y que formaparte 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 caminocrítico.

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 decalidad establecidos.

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.

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

CPM m Véase camino crítico

diagrama de Gantt m Diagrama que muestra el tiempo en el eje de abscisas, mientras queen cada línea de las ordenadas se encuentran todas y cada una de las actividades que formanel proyecto. En la parte izquierda se escribe el nombre de las actividades, mientras que en laparte derecha se marca una línea desde la fecha inicial hasta la final de cada actividad.


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.También se conoce como red de actividades o grafo de precedencias.

grafo de precedencias m Véase diagrama PERT

hitos de control m Actividades ficticias con duración nula, introducidas en la planificaciónal 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.

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 quese le han asignado.

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

ley de Brooks f Advertencia para tener en cuenta el mito del hombre-mes y que señala quesi 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.

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

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-grama o proyecto.sigla: PERT

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

red de actividades f Véase diagrama PERT

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

WBS f Véase work breakdown structure

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

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

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

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 Workfor You. Nueva York: John Wiley & Sons.

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.Nueva York: Springer.

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 andPrecedence Diagramming (3.ª ed.). Nueva York: Van Nostrand Reinhold.

Page-Jones, M. (1985). Practical Project Management: Restoring Quality to DP Projects and Systems.Nueva York: Dorset House.


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.También se conoce como red de actividades o grafo de precedencias.

grafo de precedencias m Véase diagrama PERT

hitos de control m Actividades ficticias con duración nula, introducidas en la planificaciónal 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.

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 quese le han asignado.

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

ley de Brooks f Advertencia para tener en cuenta el mito del hombre-mes y que señala quesi 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.

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

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-grama o proyecto.sigla: PERT

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

red de actividades f Véase diagrama PERT

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

WBS f Véase work breakdown structure

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

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

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

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 Workfor You. Nueva York: John Wiley & Sons.

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.Nueva York: Springer.

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 andPrecedence Diagramming (3.ª ed.). Nueva York: Van Nostrand Reinhold.

Page-Jones, M. (1985). Practical Project Management: Restoring Quality to DP Projects and Systems.Nueva York: Dorset House.


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

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

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

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

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

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


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

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

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

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

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

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

Internet

Gestión Proyectos Computacionales