La Gestion De Un Proyecto Informatico

La gestión de un proyecto informático

La gestión de un proyecto informático

Planificación, seguimiento, y aseguramiento de la calidad

Planificación, seguimiento, y aseguramiento de la calidad

Miquel Barceló García

Miquel Barceló García

P03/75069/02143

P03/75069/02143

 FUOC • P03/7506/02143

La gestión de un proyecto informático

 FUOC • P03/7506/02143

La gestión de un proyecto informático

 FUOC • P03/7506/02143

La gestión de un proyecto informático

 FUOC • P03/7506/02143

Índice

Índice

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La gestión de un proyecto informático

 FUOC • P03/7506/02143

La gestión de un proyecto informático

 FUOC • P03/7506/02143

La gestión de un proyecto informático

 FUOC • P03/7506/02143

5

La gestión de un proyecto informático

 FUOC • P03/7506/02143

5

Introducción

Introducción

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

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

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

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

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

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

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

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

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

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

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

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

De hecho, lo que ahora queda por ver de la gestión de un proyecto informá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

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.

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

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

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

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

pensar en intercambiar los dos factores.

pensar en intercambiar los dos factores.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

referencia inevitable a las diferentes herramientas informáticas disponibles

referencia inevitable a las diferentes herramientas informáticas disponibles

que pueden ayudar en esta actividad de planificación.

que pueden ayudar en esta actividad de planificación.

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

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

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

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

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

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

formática de gestión.

formática de gestión.

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

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

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

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

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

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

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

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

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

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

la mayoría del software construido.

la mayoría del software construido.

La gestión de un proyecto informático

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.

 FUOC • P03/7506/02143

6

La gestión de un proyecto informático

 FUOC • P03/7506/02143

6

Objetivos

Objetivos

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

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

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

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

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

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

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

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

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

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

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

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

ciados, el estudiante debe alcanzar los objetivos siguientes:

ciados, el estudiante debe alcanzar los objetivos siguientes:

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

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

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

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

crítico (CPM).

crítico (CPM).

2. Saber planificar en el tiempo las actividades de un proyecto informático, teniendo en cuenta los recursos disponibles y las limitaciones de uso.

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-

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

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

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

completo y exhaustivo.

completo y exhaustivo.

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

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

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

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

condicionan.

condicionan.

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

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

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

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

planificación ya efectuada.

planificación ya efectuada.

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

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

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

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

obtener software seguro, fiable y de calidad.

obtener software seguro, fiable y de calidad.

La gestión de un proyecto informático

 FUOC • P03/7506/02143

7

La gestión de un proyecto informático

1. Planificación en el tiempo de los proyectos 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-

 FUOC • P03/7506/02143

7

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

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.

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-

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

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

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

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

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

del proyecto.

del proyecto.

Una vez conocida la amplia problemática de la estimación de costes, que nos ha ocupado un módulo entero, ahora planificaremos en el tiempo las diferentes tareas o actividades de las que consta el proyecto.

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.

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-

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

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

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

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

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

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

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

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

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

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

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

cias esenciales con otros proyectos de ingeniería.

cias esenciales con otros proyectos de ingeniería.

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

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

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

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

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

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

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

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

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

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

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

La gestión de un proyecto informático

* PERT es la sigla de la expresión inglesa Program Evaluation and Review Technique.

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

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

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

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

yectos de ingeniería de todo tipo.

yectos de ingeniería de todo tipo.

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

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

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

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

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

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

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

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

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

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

diagrama de precedencias.

diagrama de precedencias.

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.

8

 FUOC • P03/7506/02143

La gestión de un proyecto informático

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.

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

8

 FUOC • P03/7506/02143

La gestión de un proyecto informático

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.

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

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

mos en esta exposición simplificada.

mos en esta exposición simplificada.

Conviene advertir que, aunque aquí se habla de tareas o actividades indistintamente, a menudo la nomenclatura más habitual utiliza el término ac-

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

Conviene advertir que, aunque aquí se habla de tareas o actividades indistintamente, a menudo la nomenclatura más habitual utiliza el término ac-

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

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

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

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

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

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

planificación de un proyecto.

planificación de un proyecto.

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

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

cionan herramientas cuantitativas que permiten determinar lo siguiente:

cionan herramientas cuantitativas que permiten determinar lo siguiente:

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

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

des que determina la duración total del proyecto.

des que determina la duración total del proyecto.

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

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

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

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

individuales.

individuales.

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

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

y que no impliquen un retraso del proyecto.

y que no impliquen un retraso del proyecto.

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

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

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

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

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

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

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

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

surge casi automáticamente del mismo diagrama.

surge casi automáticamente del mismo diagrama.

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

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

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

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

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

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

can en la tabla siguiente:

can en la tabla siguiente:

Actividades, duración y precedencias de un proyecto ficticio Identificación numérica

Nombre de la actividad

Actividades, duración y precedencias de un proyecto ficticio

Duración estimada

Precedencias

Identificación numérica

Nombre de la actividad

Duración estimada

Precedencias

1

Inicio

0

-

1

Inicio

0

-

2

Establecer los requerimientos

3

1

2

Establecer los requerimientos

3

1

3

Seleccionar los drivers

2

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 subapartado 1.2 de este módulo didáctico.

9

 FUOC • P03/7506/02143

La gestión de un proyecto informático

Actividades, duración y precedencias de un proyecto ficticio Identificación numérica

Nombre de la actividad

9

 FUOC • P03/7506/02143

La gestión de un proyecto informático

Actividades, duración y precedencias de un proyecto ficticio

Duración estimada

Precedencias

Identificación numérica

Nombre de la actividad

Duración estimada

Precedencias

4

Realizar el diseño

4

2

4

Realizar el diseño

4

2

5

Recoger datos

2

2y3

5

Recoger datos

2

2y3

6

Probar los drivers

6

3

6

Probar los drivers

6

3

7

Codificar

4

4

7

Codificar

4

4

8

Elaborar la documentación

2

4

8

Elaborar la documentación

2

4

9

Probar el producto

4

5, 6 y 7

9

Probar el producto

4

5, 6 y 7

10

Final

0

?

10

Final

0

?

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

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

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

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

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

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

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

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

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

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

anteriores e imprescindibles para poder empezar cada actividad en concre-

anteriores e imprescindibles para poder empezar cada actividad en concre-

to (precedencias).

to (precedencias).

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

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

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

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

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

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

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

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

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

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

ejemplo ficticio para ilustrar el PERT y el CPM.

ejemplo ficticio para ilustrar el PERT y el CPM.

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

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

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

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

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

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

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

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

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

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

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

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

paréntesis dentro del nudo).

paréntesis dentro del nudo).

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

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

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

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

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

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

precedentes todos los arcos pendientes del diagrama.

precedentes todos los arcos pendientes del diagrama.

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

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

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

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

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

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

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

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

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

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

 FUOC • P03/7506/02143

10

La gestión de un proyecto informático

 FUOC • P03/7506/02143

10

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

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

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

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

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

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

siete. Y así sucesivamente.

siete. Y así sucesivamente.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

el futuro de la gestión del proyecto.

el futuro de la gestión del proyecto. Las actividades críticas...

Una observación sencilla del diagrama nos muestra que las actividades 1 (inicio), 2 (establecer los requerimientos), 4 (realizar el diseño), 7 (codificar), 9 (probar el producto) y 10 (final) no tienen ningún margen. Es decir, si alguna de estas actividades tardara más de lo que se ha estimado, todo el proyecto se alargaría más de las quince semanas previstas.

La gestión de un proyecto informático

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

Las actividades críticas...

Una observación sencilla del diagrama nos muestra que las actividades 1 (inicio), 2 (establecer los requerimientos), 4 (realizar el diseño), 7 (codificar), 9 (probar el producto) y 10 (final) no tienen ningún margen. Es decir, si alguna de estas actividades tardara más de lo que se ha estimado, todo el proyecto se alargaría más de las quince semanas previstas.

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

 FUOC • P03/7506/02143

11

La gestión de un proyecto informático

 FUOC • P03/7506/02143

11

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

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

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

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

final del proyecto. A menudo estas actividades se llaman actividades

final del proyecto. A menudo estas actividades se llaman actividades

críticas.

críticas.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

de lo que se había estimado).

de lo que se había estimado).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Evidentemente, las cosas son más complicadas en el caso de proyectos con muchas más actividades. Pero, afortunadamente, en estos proyectos es fácil poder disponer de una herramienta informatizada que, de manera automática, nos da el camino crítico y con todas las ventajas que esto representa. Cabe mencionar que en este ejemplo se ha utilizado lo que se llama una planificación ASAP, que sitúa cada actividad lo antes posible y es el procedi-

Para cada actividad... ... se puede establecer una planificación de tipo: • ASAP, del inglés as soon as posible, tan pronto como sea posible. • ALAP, del inglés as last • as posible, tan tarde como sea posible.

Evidentemente, las cosas son más complicadas en el caso de proyectos con muchas más actividades. Pero, afortunadamente, en estos proyectos es fácil poder disponer de una herramienta informatizada que, de manera automática, nos da el camino crítico y con todas las ventajas que esto representa. Cabe mencionar que en este ejemplo se ha utilizado lo que se llama una planificación ASAP, que sitúa cada actividad lo antes posible y es el procedi-

La gestión de un proyecto informático

Para cada actividad... ... se puede establecer una planificación de tipo: • ASAP, del inglés as soon as posible, tan pronto como sea posible. • ALAP, del inglés as last • as posible, tan tarde como sea posible.

 FUOC • P03/7506/02143

12

La gestión de un proyecto informático

 FUOC • P03/7506/02143

12

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

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

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

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

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

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

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

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

como una planificación ALAP.

como una planificación ALAP.

1.2. Herramientas informatizadas para la planificación

1.2. Herramientas informatizadas para la planificación

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

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

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

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

son muy caras* y que sólo se utilizan para la estimación de costes en proyectos informáticos. Ya hemos mencionado que la parte de la planificación temporal de

* El SLIM, por ejemplo.

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

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

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

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

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

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

asequible y su uso se convierta en muy habitual.

asequible y su uso se convierta en muy habitual.

El problema que se plantea a menudo es decidir cuál de las muchas herramientas disponibles en el mercado se debe escoger. Pero se trata de un problema

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

El problema que se plantea a menudo es decidir cuál de las muchas herramientas disponibles en el mercado se debe escoger. Pero se trata de un problema

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Elegir una de las dos herramientas es en cierta manera inútil. Cuando una de las herramientas ofrece una funcionalidad nueva no disponible en la otra, sólo se debe esperar unos meses y la nueva versión de esta otra herramienta incorporará también la misma funcionalidad. Además, cabe recordar que la mayoría de estas funcionalidades no siempre se utilizan. Como ocurre con los

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.

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 incorporará también la misma funcionalidad. Además, cabe recordar que la mayoría de estas funcionalidades no siempre se utilizan. Como ocurre con los

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

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

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

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

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

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

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

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

La gestión de un proyecto informático

* 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.

 FUOC • P03/7506/02143

13

La gestión de un proyecto informático

 FUOC • P03/7506/02143

13

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

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

neralizar a otros usuarios.

neralizar a otros usuarios.

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

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

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

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

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

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

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

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

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

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

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

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

cación de un proyecto.

cación de un proyecto.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

la fecha final de cada actividad.

la fecha final de cada actividad.

En el caso del proyecto ficticio que se ha utilizado para exponer el PERT y el CPM, el diagrama de Gantt sería el que se muestra en la figura siguiente:

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

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:

La gestión de un proyecto informático

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

 FUOC • P03/7506/02143

14

La gestión de un proyecto informático

En realidad, la mayoría de herramientas informatizadas de ayuda a la planificació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.

rramientas informatizadas ofrecen también diagramas basados en el calendario para marcar los días de inicio y final de cada tarea, aunque el diagrama de Gantt es suficientemente completo en este aspecto.

14

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.

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.

marcar las fechas que no son laborables o cualquier incidencia laboral. Las herramientas informatizadas ofrecen también diagramas basados en el calendario para marcar los días de inicio y final de cada tarea, aunque el diagrama de Gantt es suficientemente completo en este aspecto. El resumen de lo que se debe llevar a cabo para planificar un proyecto en el

tiempo es el siguiente:

tiempo es el siguiente:

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

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

sario, de cada persona del equipo (recurso).

sario, de cada persona del equipo (recurso).

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

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

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

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

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

4) Establecer las precedencias entre las tareas.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

precedencias 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

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.

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

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

4) Establecer las precedencias entre las tareas.

La gestión de un proyecto informático

En realidad, la mayoría de herramientas informatizadas de ayuda a la planifiPodéis ver la WBS en el subapartado 2.2 del módulo “Estimación de costes de un proyecto informático” de esta asignatura.

Previamente, sin embargo, debe establecerse el calendario del proyecto para marcar las fechas que no son laborables o cualquier incidencia laboral. Las he-

 FUOC • P03/7506/02143

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.

precedencias

Ejemplo de precedencia lógica Un caso sencillo de precedencia lógica es que no se puede codificar un programa si su cuaderno de cargas no se ha finalizado.

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-

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

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

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

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

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

Ejemplo de precedencia lógica Un caso sencillo de precedencia lógica es que no se puede codificar un programa si su cuaderno de cargas no se ha finalizado.

15

 FUOC • P03/7506/02143

La gestión de un proyecto informático

15

 FUOC • P03/7506/02143

La gestión de un proyecto informático

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

tividad 9 (probar el producto).

tividad 9 (probar el producto).

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

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

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

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

mentación).

mentación).

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

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

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

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

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

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

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

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

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

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

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

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

Actividades con precedencias adicionales para evitar jornadas dobles

Actividades con precedencias adicionales para evitar jornadas dobles

Identificación numérica

Nombre de la actividad

Duración estimada

Precedencias

Identificación numérica

Nombre de la actividad

Duración estimada

Precedencias

1

Inicio

0

-

-

1

Inicio

0

-

-

2

Establecer los requerimientos

3

1

A

2

Establecer los requerimientos

3

1

A

3

Seleccionar los drivers

2

1

B

3

Seleccionar los drivers

2

1

B

4

Realizar el diseño

4

2

A

4

Realizar el diseño

4

2

A

5

Recoger datos

2

2, 3 y 6

B

5

Recoger datos

2

2, 3 y 6

B

6

Probar los drivers

6

3

B

6

Probar los drivers

6

3

B

7

Codificar

4

4

A

7

Codificar

4

4

A

8

Elaborar la documentación

2

4y5

B

8

Elaborar la documentación

2

4y5

B

9

Probar el producto

4

5, 6 y 7

A

9

Probar el producto

4

5, 6 y 7

A

10

Final

0

-

-

10

Final

0

-

-

 FUOC • P03/7506/02143

16

La gestión de un proyecto informático

 FUOC • P03/7506/02143

16

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

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

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

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

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

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

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

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

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

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

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

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

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

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

tividades hasta que se encuentra un resultado aceptable.

tividades hasta que se encuentra un resultado aceptable.

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

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

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

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

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

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

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

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

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

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

horas de trabajo que les han sido asignadas.

horas de trabajo que les han sido asignadas.

La gestión de un proyecto informático

 FUOC • P03/7506/02143

17

La gestión de un proyecto informático

 FUOC • P03/7506/02143

17

2. Seguimiento y control de un proyecto informático

2. Seguimiento y control de un proyecto informático

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

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

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

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

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

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

solución.

solución.

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

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

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

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

ción fijada previamente.

ción fijada previamente.

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

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

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

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

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

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

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

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

El objetivo declarado del proyecto es alcanzar unas funcionalidades en unos

El objetivo declarado del proyecto es alcanzar unas funcionalidades en unos

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

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

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

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

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

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

en definitiva, cambiar el proyecto modificando los objetivos.

en definitiva, cambiar el proyecto modificando los objetivos.

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

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

en el hecho de poder anticipar los problemas.

en el hecho de poder anticipar los problemas.

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

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

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

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

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

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

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

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

plantearnos, entre otras cosas, lo siguiente:

plantearnos, entre otras cosas, lo siguiente:

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

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

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

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

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

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

dida que avanza el proyecto.

dida que avanza el proyecto.

La gestión de un proyecto informático

 FUOC • P03/7506/02143

18

La gestión de un proyecto informático

 FUOC • P03/7506/02143

18

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

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

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

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

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

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

de mantener los otros.

de mantener los otros.

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

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

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

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

de la prevista que la realidad nos aporte.

de la prevista que la realidad nos aporte.

Como se dice en otro módulo, los problemas de una deficiente calificación inicial se intentan “resolver” demasiadas veces de puertas afuera, haciendo todo lo posible para cumplir con los plazos y el presupuesto a fuerza de reducir las

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

Como se dice en otro módulo, los problemas de una deficiente calificación inicial se intentan “resolver” demasiadas veces de puertas afuera, haciendo todo lo posible para cumplir con los plazos y el presupuesto a fuerza de reducir las

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

datos del seguimiento en unas hojas de actividad.

datos del seguimiento en unas hojas de actividad.

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

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

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

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

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

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

que se le han asignado.

que se le han asignado.

Conviene recoger de manera individual por cada tarea y cada persona involucrada estos datos de seguimiento, a partir de los cuales el jefe de proyecto*

La gestión de un proyecto informático

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

Conviene recoger de manera individual por cada tarea y cada persona involucrada estos datos de seguimiento, a partir de los cuales el jefe de proyecto*

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

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

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

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

de control establecidos.

de control establecidos.

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

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

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

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

ción con la planificación vigente.

ción con la planificación vigente.

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

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

 FUOC • P03/7506/02143

19

La gestión de un proyecto informático

 FUOC • P03/7506/02143

19

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

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

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

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

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

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

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

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

mitir anticipar los problemas.

mitir anticipar los problemas.

Con los datos reales obtenidos de la hoja de actividad, el jefe de proyecto realiza el seguimiento, a menudo mediante herramientas informatizadas* que

* Como MS-PROJECT o SUPERPROJECT.

Con los datos reales obtenidos de la hoja de actividad, el jefe de proyecto realiza el seguimiento, a menudo mediante herramientas informatizadas* que

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

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

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

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

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

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

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

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

proyecto.

proyecto.

2.2. La ley de Brooks

2.2. La ley de Brooks

Aunque ya se trata detenidamente en otros módulos, conviene recordar aquí lo que se ha denominado ley de Brooks, una teoría que proviene de la experiencia del autor de la obra The Mythical Man-Month (1975) como director del proceso de construcción del sistema operativo de IBM 360.

La ley de Brooks es una advertencia para no caer en el mito del hombre-mes, que a menudo tiene formulaciones tan sorprendentes como ésta: si un proyecto va retrasado, el hecho de añadir personal es la manera más segura de retrasarlo todavía más.

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

Podéis ver los módulos “El proyecto informático de construcción de software” y “Estimación de costes de 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.

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 experiencia del autor de la obra The Mythical Man-Month (1975) como director del proceso de construcción del sistema operativo de IBM 360.

La ley de Brooks es una advertencia para no caer en el mito del hombre-mes, que a menudo tiene formulaciones tan sorprendentes como ésta: si un proyecto va retrasado, el hecho de añadir personal es la manera más segura de retrasarlo todavía más.

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

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

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

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

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

mito del hombre-mes.

mito del hombre-mes.

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

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

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

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

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

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

caso de la construcción de una casa).

caso de la construcción de una casa).

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

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

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

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

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

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

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

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

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

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

proyecto informático que iba retrasado, el hecho de añadir personal creó más problemas de los que resolvió, aunque, evidentemente, esto no debe ocurrir siempre.

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” de esta asignatura.

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 gestión de un proyecto informático

* Como MS-PROJECT o SUPERPROJECT.

Podéis ver los módulos “El proyecto informático de construcción de software” y “Estimación de costes de 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” de esta asignatura.

 FUOC • P03/7506/02143

20

La gestión de un proyecto informático

 FUOC • P03/7506/02143

20

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

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

crean unos circuitos internos de comunicación para comprender qué se reali-

crean unos circuitos internos de comunicación para comprender qué se reali-

za. Entre los trabajos que se deben efectuar se encuentra el de comunicar a

za. Entre los trabajos que se deben efectuar se encuentra el de comunicar a

otros miembros del equipo aquello que uno ha decidido y que condiciona el

otros miembros del equipo aquello que uno ha decidido y que condiciona el

trabajo del resto. El hecho de añadir personal nuevo a mitad de proyecto o

trabajo del resto. El hecho de añadir personal nuevo a mitad de proyecto o

cuando ya se está acabando provoca que haya personas nuevas que no cono-

cuando ya se está acabando provoca que haya personas nuevas que no cono-

cen qué se realiza y que, además, crean necesidades adicionales de comunica-

cen qué se realiza y que, además, crean necesidades adicionales de comunica-

ción que pueden consumir incluso una parte de los recursos que ya existen,

ción que pueden consumir incluso una parte de los recursos que ya existen,

simplemente porque los miembros “viejos” del equipo de proyecto han de ex-

simplemente porque los miembros “viejos” del equipo de proyecto han de ex-

plicar a los “nuevos” qué se lleva a cabo y cómo se realiza. Según Brooks, estas

plicar a los “nuevos” qué se lleva a cabo y cómo se realiza. Según Brooks, estas

necesidades adicionales de comunicación pueden provocar incluso que con

necesidades adicionales de comunicación pueden provocar incluso que con

más personas se tarde más tiempo.

más personas se tarde más tiempo.

La gestión de un proyecto informático

 FUOC • P03/7506/02143

21

La gestión de un proyecto informático

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

Desgraciadamente, tal como comentamos en otro módulo, la calidad del software construido no es siempre la deseable. Hemos visto algunas de las razones

 FUOC • P03/7506/02143

21

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

Podéis ver el módulo “El proyecto informático de construcción de software” de esta asignatura.

Desgraciadamente, tal como comentamos en otro módulo, la calidad del software construido no es siempre la deseable. Hemos visto algunas de las razones

que pueden ser la causa, aun así debemos evitar que ello ocurra.

que pueden ser la causa, aun así debemos evitar que ello ocurra.

Han transcurrido ya un par de décadas desde que se comenzó a hablar explí-

Han transcurrido ya un par de décadas desde que se comenzó a hablar explí-

citamente de aseguramiento de la calidad del software.

citamente de aseguramiento de la calidad del software.

Terminología confusa

Terminología confusa

Con respecto al término aseguramiento de la calidad del software (software quality assurance), a veces se ha traducido del inglés como garantía de calidad del software, aunque diferentes autores se oponen porque crea confusión con el concepto, mucho más tradicional, de garantía de los productos (no debemos olvidar que un software es un producto que se vende y que, como tal, puede tener una garantía).

Con respecto al término aseguramiento de la calidad del software (software quality assurance), a veces se ha traducido del inglés como garantía de calidad del software, aunque diferentes autores se oponen porque crea confusión con el concepto, mucho más tradicional, de garantía de los productos (no debemos olvidar que un software es un producto que se vende y que, como tal, puede tener una garantía).

El aseguramiento de la calidad del software es, según AENOR –la entidad

El aseguramiento de la calidad del software es, según AENOR –la entidad

española de normalización–, el conjunto de actividades planificadas y sis-

española de normalización–, el conjunto de actividades planificadas y sis-

temáticas necesarias para aportar la confianza de que el producto (software)

temáticas necesarias para aportar la confianza de que el producto (software)

cumplirá los requerimientos de calidad establecidos.

cumplirá los requerimientos de calidad establecidos.

Ya en 1977, Mc Call estableció algunos factores para analizar la calidad del software * y, desde entonces, el procedimiento habitual ha sido elaborar listas de control** complejas y detalladas para revisar todo el proceso de construc-

unos procedimientos y unas metodologías de construcción que tratan de garantizar, a priori, que el proceso es correcto y seguro, y que el mismo proceso de construcción pueda garantizar también, en cierta manera, que el producto que se obtiene es un software de la mejor calidad.

Podéis ver el módulo “El proyecto informático de construcción de software” de esta asignatura.

Ya en 1977, Mc Call estableció algunos factores para analizar la calidad del * En inglés, software quality factors. ** En inglés, check list.

ción del software. Actualmente, el aseguramiento de calidad de software consiste en introducir

La gestión de un proyecto informático

software * y, desde entonces, el procedimiento habitual ha sido elaborar listas de control** complejas y detalladas para revisar todo el proceso de construc-

* En inglés, software quality factors. ** En inglés, check list.

ción del software.

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 cero de errores.

Actualmente, el aseguramiento de calidad de software consiste en introducir unos procedimientos y unas metodologías de construcción que tratan de garantizar, a priori, que el proceso es correcto y seguro, y que el mismo proceso de construcción pueda garantizar también, en cierta manera, que el producto que se obtiene es un software de la mejor calidad.

En general, la calidad del software necesita que exista un acuerdo total entre

En general, la calidad del software necesita que exista un acuerdo total entre

los requerimientos (tanto funcionales como de rendimiento) y el software fi-

los requerimientos (tanto funcionales como de rendimiento) y el software fi-

nal. Esto implica la utilización de estándares de desarrollo documentados ex-

nal. Esto implica la utilización de estándares de desarrollo documentados ex-

plícitamente y de procedimientos concretos de gestión de todo el proceso de

plícitamente y de procedimientos concretos de gestión de todo el proceso de

construcción de software.

construcción de software.

La calidad del software es, según el IIEE (Instituto de Ingenieros Eléc-

La calidad del software es, según el IIEE (Instituto de Ingenieros Eléc-

tricos y Electrónicos), el grado en el que un sistema, componente o pro-

tricos y Electrónicos), el grado en el que un sistema, componente o pro-

ceso cumple con los requerimientos especificados y con las necesidades

ceso cumple con los requerimientos especificados y con las necesidades

o expectativas del cliente o usuario.

o expectativas del cliente o usuario.

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 cero de errores.

 FUOC • P03/7506/02143

22

La gestión de un proyecto informático

 FUOC • P03/7506/02143

22

El tratamiento del aseguramiento de la calidad se centra tradicionalmente en

El tratamiento del aseguramiento de la calidad se centra tradicionalmente en

las inspecciones y revisiones formales, junto con las llamadas reuniones de re-

las inspecciones y revisiones formales, junto con las llamadas reuniones de re-

paso*. Uno de los objetivos fundamentales es, evidentemente, obtener la característica implícita de la fiabilidad y, sobre todo, un mantenimiento fácil del

* En inglés, walkthroughs.

paso*. Uno de los objetivos fundamentales es, evidentemente, obtener la característica implícita de la fiabilidad y, sobre todo, un mantenimiento fácil del

producto obtenido, teniendo en cuenta la larga duración de la etapa de man-

producto obtenido, teniendo en cuenta la larga duración de la etapa de man-

tenimiento en el ciclo de vida del software.

tenimiento en el ciclo de vida del software.

En general, un sistema de aseguramiento de la calidad del software

En general, un sistema de aseguramiento de la calidad del software

incluye una estructura organizativa que implica establecer responsabi-

incluye una estructura organizativa que implica establecer responsabi-

lidades, procedimientos y procesos de construcción y revisión, y tam-

lidades, procedimientos y procesos de construcción y revisión, y tam-

bién garantizar la disponibilidad de los recursos de todo tipo necesarios

bién garantizar la disponibilidad de los recursos de todo tipo necesarios

para efectuar una gestión de calidad que ofrezca un software de calidad.

para efectuar una gestión de calidad que ofrezca un software de calidad.

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

* International Organization for Standarization.

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

ISO 9000, que describe los elementos que debe tener un sistema de asegu-

ISO 9000, que describe los elementos que debe tener un sistema de asegu-

ramiento de la calidad con el fin de que se puedan aplicar a cualquier ne-

ramiento de la calidad con el fin de que se puedan aplicar a cualquier ne-

gocio o actividad.

gocio o actividad.

La gestión de un proyecto informático

* En inglés, walkthroughs.

* International Organization for Standarization.

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

Lectura recomendada

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

Lectura recomendada

ingeniería del software y expone hasta veinte exigencias que debe cumplir un

Para más detalles, podéis consultar la obra siguiente: R. Kehoe; A. Jarvis (1996). ISO 9000-3: A Tool for Software Product and Process Improvement. Nueva York: Springer.

ingeniería del software y expone hasta veinte exigencias que debe cumplir un

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.

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 vistas a la aplicación de las exigencias de la ISO 9001 en el caso de una industria de fabricación y/o venta de software.

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 vistas a la aplicación de las exigencias de la ISO 9001 en el caso de una industria de fabricación y/o venta de software.

 FUOC • P03/7506/02143

23

La gestión de un proyecto informático

 FUOC • P03/7506/02143

23

Resumen

Resumen

La planificación temporal de un proyecto informático arranca de la des-

La planificación temporal de un proyecto informático arranca de la des-

composición en tareas del proyecto (WBS), la estimación del esfuerzo de cada

composición en tareas del proyecto (WBS), la estimación del esfuerzo de cada

una y las precedencias entre las tareas o actividades. Esta información se dis-

una y las precedencias entre las tareas o actividades. Esta información se dis-

pone en un diagrama PERT (o red de actividades) y se obtiene así el camino

pone en un diagrama PERT (o red de actividades) y se obtiene así el camino

crítico formado por la cadena de actividades problemáticas que no tienen mar-

crítico formado por la cadena de actividades problemáticas que no tienen mar-

gen de tiempo y que determinan la duración global del proyecto.

gen de tiempo y que determinan la duración global del proyecto.

En el caso de los proyectos informáticos, además de las precedencias lógicas,

En el caso de los proyectos informáticos, además de las precedencias lógicas,

es necesario añadir nuevas precedencias entre actividades para conseguir un

es necesario añadir nuevas precedencias entre actividades para conseguir un

buen uso de los recursos, es decir, de los profesionales que forman el equipo

buen uso de los recursos, es decir, de los profesionales que forman el equipo

de proyecto y evitar que se produzcan casos de jornada doble.

de proyecto y evitar que se produzcan casos de jornada doble.

A menudo, las herramientas informáticas para planificar y llevar a cabo el se-

A menudo, las herramientas informáticas para planificar y llevar a cabo el se-

guimiento de proyectos ofrecen diferentes diagramas (de Gantt, PERT, de ca-

guimiento de proyectos ofrecen diferentes diagramas (de Gantt, PERT, de ca-

lendario, etc.) y una variedad amplia de listas.

lendario, etc.) y una variedad amplia de listas.

El seguimiento y el control del proyecto se realizan comparando los datos

El seguimiento y el control del proyecto se realizan comparando los datos

reales (obtenidos de las hojas de actividad en las que cada miembro del equipo

reales (obtenidos de las hojas de actividad en las que cada miembro del equipo

del proyecto detalla el tiempo que ha dedicado a cada tarea) con los datos pre-

del proyecto detalla el tiempo que ha dedicado a cada tarea) con los datos pre-

vistos en la planificación vigente. Si existen nuevos datos sobre productividad

vistos en la planificación vigente. Si existen nuevos datos sobre productividad

o deben llevarse a cabo tareas no previstas antes, puede ser necesario efectuar

o deben llevarse a cabo tareas no previstas antes, puede ser necesario efectuar

una nueva calificación del proyecto (estimación de costes y planificación) y re-

una nueva calificación del proyecto (estimación de costes y planificación) y re-

visar los objetivos: las funcionalidades, los plazos y el presupuesto.

visar los objetivos: las funcionalidades, los plazos y el presupuesto.

La ley de Brooks intenta evitar la incomprensión sobre el mito del hombre-

La ley de Brooks intenta evitar la incomprensión sobre el mito del hombre-

mes y afirma que añadir más personal a un proyecto retrasado no siempre

mes y afirma que añadir más personal a un proyecto retrasado no siempre

mejora las cosas.

mejora las cosas.

El aseguramiento de la calidad del software es el conjunto de actividades de

El aseguramiento de la calidad del software es el conjunto de actividades de

gestión y organización que permite garantizar que el proceso de construcción

gestión y organización que permite garantizar que el proceso de construcción

del software es seguro y fiable y, por lo tanto, que el software obtenido también

del software es seguro y fiable y, por lo tanto, que el software obtenido también

será de calidad. Existen estándares internacionales sobre el aseguramiento de

será de calidad. Existen estándares internacionales sobre el aseguramiento de

la calidad en el campo de la ingeniería del software, en concreto la ISO 9001 y

la calidad en el campo de la ingeniería del software, en concreto la ISO 9001 y

la ISO 9000-3.

la ISO 9000-3.

La gestión de un proyecto informático

 FUOC • P03/7506/02143

La gestión de un proyecto informático

 FUOC • P03/7506/02143

La gestión de un proyecto informático

 FUOC • P03/7506/02143

25

La gestión de un proyecto informático

Actividades 1. Si podéis disponer de una herramienta de planificación y seguimiento de proyectos como el MS-PROJECT, el SUPERPROJECT u otros, estudiad sus funcionalidades mediante el sistema de ayuda (help) y comprobad los listados que se encuentran disponibles. Como ejercicio concreto, introducid los datos del proyecto ficticio que hemos tratado en este módulo y, tomando a dos o tres personas como recurso (miembros del equipo), observad los diferentes gráficos y listados que os ofrece la herramienta. 2. Añadid las precedencias que os parezcan lógicas a los datos de actividades y el esfuerzo estimado 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 programador, 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 precios por hora de analista y programador que conocéis, obtened el coste global del proyecto. 3. Intentad llevar a cabo una descomposición de tareas (WBS), una estimación de costes parecida a la del ejemplo de la contabilidad sencilla en un PC y una planificación en el tiempo contando con un analista y un programador para el caso de la aplicación en un pequeño hotel.

 FUOC • P03/7506/02143

25

La gestión de un proyecto informático

Actividades 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.

1. Si podéis disponer de una herramienta de planificación y seguimiento de proyectos como el MS-PROJECT, el SUPERPROJECT u otros, estudiad sus funcionalidades mediante el sistema de ayuda (help) y comprobad los listados que se encuentran disponibles. Como ejercicio concreto, introducid los datos del proyecto ficticio que hemos tratado en este módulo y, tomando a dos o tres personas como recurso (miembros del equipo), observad los diferentes gráficos y listados que os ofrece la herramienta. 2. Añadid las precedencias que os parezcan lógicas a los datos de actividades y el esfuerzo estimado 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 programador, 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 precios por hora de analista y programador que conocéis, obtened el coste global del proyecto. 3. Intentad llevar a cabo una descomposición de tareas (WBS), una estimación de costes parecida a la del ejemplo de la contabilidad sencilla en un PC y una planificación en el tiempo contando con un analista y un programador para el caso de la aplicación en un pequeño hotel.

Datos del hotel

Datos del hotel

Se quiere implementar una pequeña aplicación (simplificada) de gestión administrativa de la recepción y facturación de un hotel. La aplicación se debe ejecutar en un conjunto de ordenadores personales, de tipo PC compatible, conectados en red y que comparten los datos. El hotel dispone de habitaciones simples y dobles y ofrece también una serie de servicios (bar, restaurante, tintorería, teléfono, etc.), cuya facturación se ha de incorporar a la gestión informatizada de la recepción y la facturación. La ocupación de las habitaciones puede ser posterior a una reserva previa, realizada directamente por el cliente o mediante una agencia de viajes.

Se quiere implementar una pequeña aplicación (simplificada) de gestión administrativa de la recepción y facturación de un hotel. La aplicación se debe ejecutar en un conjunto de ordenadores personales, de tipo PC compatible, conectados en red y que comparten los datos. El hotel dispone de habitaciones simples y dobles y ofrece también una serie de servicios (bar, restaurante, tintorería, teléfono, etc.), cuya facturación se ha de incorporar a la gestión informatizada de la recepción y la facturación. La ocupación de las habitaciones puede ser posterior a una reserva previa, realizada directamente por el cliente o mediante una agencia de viajes.

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

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

1) Tratamientos interactivos

1) Tratamientos interactivos

a) Mantenimiento del fichero de habitaciones

a) Mantenimiento del fichero de habitaciones

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

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

b)Gestión de reservas

b)Gestión de reservas

Para dar de alta una reserva, hemos de introducir las fechas de la entrada y la salida y el número de personas. El sistema debe ofrecer las habitaciones disponibles y aceptar y registrar la elección que realice el operador a partir de esta información. Los datos complementarios de la reserva serán, al menos, el nombre y el DNI del titular de la reserva, el tipo de reserva (directo o por agencia), el identificador de la agencia (si procede) y el teléfono de la persona que efectúa la reserva (cliente o agencia).

Para dar de alta una reserva, hemos de introducir las fechas de la entrada y la salida y el número de personas. El sistema debe ofrecer las habitaciones disponibles y aceptar y registrar la elección que realice el operador a partir de esta información. Los datos complementarios de la reserva serán, al menos, el nombre y el DNI del titular de la reserva, el tipo de reserva (directo o por agencia), el identificador de la agencia (si procede) y el teléfono de la persona que efectúa la reserva (cliente o agencia).

Para modificar o anular una reserva debemos partir del nombre o del DNI del titular de la reserva y de la fecha de reserva. Es evidente que en una reserva puede incluirse más de una habitación.

Para modificar o anular una reserva debemos partir del nombre o del DNI del titular de la reserva y de la fecha de reserva. Es evidente que en una reserva puede incluirse más de una habitación.

c) Entrada de clientes

c) Entrada de clientes

Los clientes pueden ocupar habitaciones ya reservadas o las que puedan encontrarse disponibles si no se ha realizado ninguna reserva previa. Si existe reserva previa, se asigna automáticamente la habitación reservada y, en caso de que se trate de un cliente nuevo sin reserva, se consulta el estado de las habitaciones disponibles. Si es posible, se le admite la entrada considerándolo un cliente directo y por el número de días que solicite.

Los clientes pueden ocupar habitaciones ya reservadas o las que puedan encontrarse disponibles si no se ha realizado ninguna reserva previa. Si existe reserva previa, se asigna automáticamente la habitación reservada y, en caso de que se trate de un cliente nuevo sin reserva, se consulta el estado de las habitaciones disponibles. Si es posible, se le admite la entrada considerándolo un cliente directo y por el número de días que solicite.

Los datos necesarios para registrar la entrada de los clientes son, al menos, el nombre, el DNI (o pasaporte), el domicilio y la nacionalidad, y la habitación que ocuparán. Cuando la reserva sea para más de una persona, es opcional registrar el nombre, el DNI y el domicilio de todos los clientes, pero siempre se registrarán estos datos con respecto al titular de la reserva.

Los datos necesarios para registrar la entrada de los clientes son, al menos, el nombre, el DNI (o pasaporte), el domicilio y la nacionalidad, y la habitación que ocuparán. Cuando la reserva sea para más de una persona, es opcional registrar el nombre, el DNI y el domicilio de todos los clientes, pero siempre se registrarán estos datos con respecto al titular de la 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.

 FUOC • P03/7506/02143

26

La gestión de un proyecto informático

 FUOC • P03/7506/02143

26

d)Entrada de gastos adicionales

d)Entrada de gastos adicionales

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

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

e)Salida de clientes

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

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

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

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

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

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

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

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

2) Tratamientos diferidos

2) Tratamientos diferidos

a) Cadena diaria

a) Cadena diaria

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

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

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

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

b)Cadena semanal

b)Cadena semanal

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

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

c) Cadena mensual

c) Cadena mensual

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

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

3) Volúmenes

3) Volúmenes

• • • – – –

• • • – – –

Número de habitaciones: 400 (70 sencillas y 330 dobles). Número de 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.

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.

La gestión de un proyecto informático

 FUOC • P03/7506/02143

27

La gestión de un proyecto informático

 FUOC • P03/7506/02143

27

Ejercicios de autoevaluación

Ejercicios de autoevaluación

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10. ¿Cuáles son las normas ISO que afectan a la calidad del software?

10. ¿Cuáles son las normas ISO que afectan a la calidad del software?

La gestión de un proyecto informático

 FUOC • P03/7506/02143

28

La gestión de un proyecto informático

 FUOC • P03/7506/02143

28

Solucionario

Solucionario

Ejercicios de autoevaluación

Ejercicios de autoevaluación

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Glosario

Glosario

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

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

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

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

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

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

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

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

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

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

CPM m Véase camino crítico

CPM m Véase camino crítico

diagrama de Gantt m Diagrama que muestra el tiempo en el eje de abscisas, mientras que en cada línea de las ordenadas se encuentran todas y cada una de las actividades que forman el proyecto. En la parte izquierda se escribe el nombre de las actividades, mientras que en la parte derecha se marca una línea desde la fecha inicial hasta la final de cada actividad.

diagrama de Gantt m Diagrama que muestra el tiempo en el eje de abscisas, mientras que en cada línea de las ordenadas se encuentran todas y cada una de las actividades que forman el proyecto. En la parte izquierda se escribe el nombre de las actividades, mientras que en la parte derecha se marca una línea desde la fecha inicial hasta la final de cada actividad.

La gestión de un proyecto informático

 FUOC • P03/7506/02143

29

La gestión de un proyecto informático

 FUOC • P03/7506/02143

29

diagrama PERT m Descripción de un proyecto en forma de grafo donde los nudos del grafo 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.

diagrama PERT m Descripción de un proyecto en forma de grafo donde los nudos del grafo 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

grafo de precedencias m Véase diagrama PERT

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

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

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

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

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

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

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

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

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

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

PERT f Véase program evaluation and review technique

PERT f Véase program evaluation and review technique

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

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

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

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

red de actividades f Véase diagrama PERT

red de actividades f Véase diagrama PERT

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

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

WBS f Véase work breakdown structure

WBS f Véase work breakdown structure

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

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

Bibliografía

Bibliografía

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

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

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

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.

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

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

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

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

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

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

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.

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

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

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

Page-Jones, M. (1985). Practical Project Management: Restoring Quality to DP Projects and Systems. Nueva York: Dorset House.

Page-Jones, M. (1985). Practical Project Management: Restoring Quality to DP Projects and Systems. Nueva York: Dorset House.

La gestión de un proyecto informático

 FUOC • P03/7506/02143

30

La gestión de un proyecto informático

 FUOC • P03/7506/02143

30

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

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

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

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

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

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

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

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.

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

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

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

La gestión de un proyecto informático