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
