Está en la página 1de 121

1.

EL PROYECTO: UNA
FORMA DE ORGANIZAR
EL TRABAJO
Índice
1. EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO ................. 1
1. DIFERENTES FORMAS DE ORGANIZAR EL TRABAJO. ................................................. 1
2. ¿QUÉ ES UN PROYECTO? ....................................................................................... 3
3. ¿QUE ES LA GESTIÓN?........................................................................................... 4
4. ¿QUE ES LA GESTIÓN DE PROYECTOS?.................................................................... 5
5. FASES DE UN PROYECTO. ...................................................................................... 6
5.1. Planeación.................................................................................................. 6
5.2. Ejecución del proyecto.............................................................................. 11
6. VISIÓN GLOBAL DEL PROYECTO Y LOS COSTES. .................................................... 13
BIBLIOGRAFÍA. ...................................................................................................... 14

1. Diferentes formas de organizar el trabajo.


Los seres humanos nos caracterizamos entre otras cosas por que
transformamos la realidad que nos rodea de forma drástica, y todo ello con
nuestras manos e ingenio. Desde la antigüedad nos dimos cuenta de que para
ser más productivos necesitábamos organizarnos ante los objetivos que
pretendíamos alcanzar. Así las tropas de Carlo Magno, las legiones romanas,
o los griegos en las guerras médicas, diferían, fundamentalmente de sus
contrincantes en dos aspectos clave:

a) la tecnología que utilizaban era mejor (bronce, hierro,..), y


b) la planificación y seguimiento estaba más elaborada, es decir:
- tenían los objetivos más claros,
- tenían mejor preparada la estrategia a seguir,
- estaban mejor organizados,
- informaban rápidamente a sus compañeros, para que estos pudieran
actuar en consecuencia y corregir cualquier desviación. Recordar que
el nombre de la Maratón proviene del de una ciudad del Ática en donde
los griegos obtubieron la victoria que puso fin a la primera guerra
médicas y el corredor que llevo la noticia a Atenas puso tanto empeño
en cumplir su misión, que murió de agotamiento.

1
GESTIÓN DE PROYECTOS INFORMÁTICOS

En la actualidad las empresas tienen aprendida la lección, o la tienen que


aprender, de forma acelerada. Es decir las empresas que se encuentran en un
mercado competitivo, saben que los aspectos comentados anteriormente son
piezas clave para su éxito.
Dado que las empresas se dedican a producir bienes o servicios, es
interesante observar que los diferentes tipos sistemas productivos se adaptan
a situaciones complementarias. En la actualidad nos encontramos con tres
grandes grupos de sistemas productivos1:

 Los diseñados para la producción en masa. Se caracterizan por estar


centrados en procesos específicos de ensamblaje de un producto. En
esta situación se aplican las economías de escala, lo que permite la
adquisición de maquinaria muy específica, a medida de los procesos.
Ejemplos pueden ser la fabricación de coches o electrodomésticos.

 Los diseñados para la producción por lotes. Se caracterizan por ser


sistemas flexibles que sirven para la producción de productos similares,
pero en cantidades no suficientes como para tener un sistema
productivo dedicado. Se debe poder cambiar y recomponer la planta de
producción para las diferentes series. Un ejemplo típico es la
fabricación de muebles.

 Los diseñados para producir o alcanzar objetivos no repetitivos. Aquí


estamos pensando en un producto que se realizará una vez y que para
producirlo, habrá que hacer una serie de tareas específicas, que antes
no se habían realizado y que posiblemente no se vuelvan a realizar. Se
le llama proyecto.

A ésta última situación es a la que se refiere este libro. De forma


específica nos centraremos en el caso de querer alcanzar un producto
informático, tal como una aplicación. Hay que hacer notar que la mayoría de
conceptos y técnicas que veremos se pueden aplicar a otro tipo de proyectos,
tales como realización de auditorías, selección e instalación de hardware,

1
A. Shutub en el punto 1.2

2
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

implantación de sistemas de información y un largo etc. Veremos en detalle,


el desarrollo de software que dispone de técnicas específicas para cálculo de
esfuerzo, identificación de tareas, etc.

2. ¿Qué es un proyecto?
Cuando escuchamos el vocablo proyecto nos vienen a la mente diferentes
acepciones tales como:

 Trabajo final de carrera,

 Conjunto de documentos que conforman la especificación técnica de


un bien o servicio a desarrollar. Una vez construido se le conoce como
planos o especificaciones.

 Forma de organizar el trabajo, que consiste en planificar el curso de


las tareas que se realizarán, con el objetivo de obtener un bien o
servicio determinado, y controlar el seguimiento de esta planificación,
para evitar las desviaciones. Aun en el caso de haber desviaciones se
deberá adaptar el plan de modo que se alcancen los objetivos
propuestos.

La definición de proyecto que da el Project Management Institute (PMI)


es: “Un proyecto es un esfuerzo temporal acometido para crear un único
servicio o producto. Temporal quiere decir que todo proyecto tiene un
comienzo claro y un final claro. Único significa que el producto o servicio es
diferente de alguna forma clara de todos los productos o servicios similares.”

Como hemos visto, el concepto fundamental de lo que es un proyecto se


centra en el producir o alcanzar un bien u objetivo. Además se le asocia a
características tales como:
Existe un objetivo claro.
Se puede identificar un conjunto de tareas que necesario realizar.
Las tareas no son habituales.
Las tareas tienen que realizarse de forma ordenada.

3
GESTIÓN DE PROYECTOS INFORMÁTICOS

Es necesaria la intervención de varias personas.


Es necesaria la intervención de especialistas.
Se utilizaran recursos de diversos tipos.
Existen limitaciones en los recursos.
El presupuesto es limitado.
El objetivo se tiene que alcanzar en plazo de tiempo limitado.
Tiene una fecha de inicio y otra de final.
Se requiere una planificación.
El producto final tendrá que cumplir las especificaciones.
Se desea un determinado nivel de calidad en el producto.
Como se ve son muchas las características que hemos enunciado.
Habitualmente nos encontraremos con proyectos de diversas envergaduras,
desde proyectos en los que hará falta la colaboración de muchas personas, y
las que tendremos que solicitar su participación con la antelación suficiente
para que organicen sus agendas, hasta aquellos en los que prácticamente un
par de personas mantendrán reuniones con los clientes y realizan todo el
trabajo.
A veces es difícil establecer una línea divisoria entre lo que es un proyecto
y lo que no lo es.
Así, si vamos de visita a casa de un amigo, este nos muestra el ordenador
nuevo que se ha comprado y tratando de explicarle como funciona el access,
hacemos una miniaplicación que le sirva para tener catalogados sus libros,
¿podríamos decir que hemos realizado un proyecto?, la respuesta es que no,
hemos creado un producto, pero de forma accidental.
En cambio, si en la empresa en la que trabajamos, se nos pide que
realicemos un sistema para soportar el catalogo de los libros de ésta, lo que
supone consultar con los usuarios potenciales, con idea de especificar la
aplicación (proceso de recepción de libros, prestamos,...) y se nos pide que
hagamos una evaluación del coste en económico y los plazos de entrega, nos
encontraremos con una realidad diferente.

3. ¿Que es la gestión?
Podemos comenzar por ver lo que dice el diccionario de la Real Academia
Española:
gestión. Acción y efecto de gestionar. ...

4
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

gestionar. Hacer diligencias conducentes al logro de un negocio o de un


deseo cualquiera.
Estas definiciones enmarcan el significado de las palabras, pero cuando
entramos en la de gestión de empresas, nos encontramos todo un mundo de
autores y definiciones. No contradicen lo anterior, pero mientras algunos
autores (Fayol) se centran en las tareas de la dirección (funciones) o los
procesos de la gestión, otros se centran en el funcionamiento de las empresas
desde las visiones mecanicistas del trabajo (Taylor, ...) incluso nos
encontramos con humanistas que contemplan a los empleados como el
autentico capital de la empresa (Follet, Mayo, ...).
A lo largo de este libro iremos recurriendo a diversas formas de ver la
gestión, pero ahora nos centraremos en las funciones de la gestión, que son:
Planificar. Determina que resultados ha de obtener la organización y
establecer estrategias adecuadas para su realización.
Organizar. Especifica como lograr los resultados planificados, asignado
las tareas identificadas en la planificación a los miembros y equipos de la
organización para que se alcances dichos objetivos.
Controlar. Comprobar si se están alcanzando los resultados previstos,
corrigiendo las desviaciones que se detecten.
Dirigir. Liderar y motivar a los miembros de la organización, de modo
que se alcancen los objetivos marcados.

4. ¿Que es la gestión de proyectos?


Se trata de articular el método para alcanzar un objetivo único y no
repetitivo en un plazo con principio y fin claros, mediante las técnicas que
nos proporciona la gestión. Es decir, se trata de un tipo de empresa
especifica. En cierto modo todos ejercemos de directores de proyectos, al
menos potencialmente, ya que solemos encontrarnos con cometidos que
debemos cumplimentar en unos plazos. Desde un punto de vista menos
formal, todos hemos tenido que organizar una fiesta de cumpleaños, la
decoración de casa en Navidad o preparar unos exámenes. Quizás lo que no
hayamos hecho es utilizar las herramientas disponibles para la organización
del trabajo. En este libro trataremos de conocer las teorías, técnicas y
herramientas disponibles para estos casos.

5
GESTIÓN DE PROYECTOS INFORMÁTICOS

Dado que los proyectos solo realizan una vez, la secuencia de las
funciones es clara, por lo que la documentación sobre proyectos la clasifica
en fases, que son más o menos secuenciales. A continuación se describen en
detalle.

5. Fases de un proyecto.
Todos los proyectos, que se gestionan como tales, tienen una serie de
fases comunes, no tanto porque se realicen tareas iguales, sino porque el
objetivo de cada fase con relación al producto a obtener es común a
cualquier proyecto.

Así tenemos dos grandes fases: Planeación y Ejecución. Estas fases se


subdividen en otras menores. Veamos cada una de ellas por separado.

5.1. Planeación.

El objetivo de toda planeación es la de clarificar el problema a solucionar,


definir el producto a obtener, o servicio a proporcionar, estimar los costes
económicos en que se va a incurrir, así como los recursos humanos y de
cualquier otro tipo que se requieran para alcanzar la meta.

En la planeación se suelen distinguir dos grandes subfases: Definición del


problema y Definición del plan de desarrollo. Mientras que la primera se
centra en clarificar el producto a obtener, la segunda atiende a las
necesidades que aparecerán a lo largo del desarrollo, anticipando el curso de
las tareas a realizar, la secuencia en que se llevarán a cabo, los recursos y el
momento en que serán necesarios. Hay que tener en cuenta que normalmente
hay más bienes o servicios que desearíamos obtener, que recursos disponibles
para obtenerlos, por lo que las empresas deben seleccionar entre varias
alternativas. Así una mala definición de un proyecto puede engañar a la
empresa y que ésta comprometa sus recursos en un bien del que hubiera
podido prescindir en favor de un sustituto más económico.

6
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

5.1.1. Definición del problema.

El origen de un proyecto suele ser difuso. Normalmente alguien identifica


un problema o una necesidad. Este problema-necesidad hace muy interesante
el nacimiento de un proyecto, ya que podemos observar como ante el
problema que se plantea unos gerentes lo ven como un impedimento para
alcanzar sus metas, mientras otros, pensando que el mismo problema
también la tienen sus competidores, lo ven como una oportunidad para dar
una solución correcta y posicionarse mejor en el mercado.

Ya sea visto como problema u oportunidad, lo primero que hay que hacer
es obtener una descripción clara de éste. La pregunta clave a responder es:
¿Cuál es el problema, o dónde está la oportunidad? Evidentemente aquí hay
que trabajar con los usuarios, directores de empresa y clientes, pues ellos son
los que conocen su negocio y será de ellos de quien tendremos que obtener
la información para responder a esta pregunta.

La definición del problema suele ocupar muy poco tiempo, por esto
muchas veces no se le da la importancia central que tiene. Hay que tener en
cuenta que todo el proyecto se basará en esta definición y es mejor que
quede clara. La definición del problema debe ser revisada por todos los
implicados en el problema: Usuarios, Directores de empresa y clientes.

En este punto conviene aclarar la diferencia de roles en los implicados,


así:

 Usuario: persona que utilizará el sistema a nivel operativo. Es el que nos


da pistas sobre el problema a nivel de funcionamiento. Son responsables
de que el sistema funcione de manera eficiente.

 Director de empresa: Los responsables de que el sistema funcione de


manera eficaz. Tienen una visión de conjunto, es decir, no solo del
sistema, sino que además la interrelación de éste con otros subsistemas
de la empresa.

7
GESTIÓN DE PROYECTOS INFORMÁTICOS

 Cliente es el que arriesga su dinero en el desarrollo, es decir, el que


pagará por el sistema.

Estos roles, en muchas situaciones los llevan las mismas personas, así en
una cooperativa de trabajo, el cliente y el usuario son la misma persona, En
una sociedad limitada, suelen coincidir director de empresa y cliente, …

Normalmente al definir el problema debemos hurgar en la organización,


sus objetivos y fines. También debemos, una vez clarificado el problema,
identificar los beneficios que se obtendrá si los solucionamos.

Hay que evitar “las soluciones en busca de un problema”, es decir cuando


alguien ha visto una aplicación en marcha, o un sistema, y quiere algo similar.
Muchas veces se esconde la idea intuitiva de que aquello resolverá un
problema o generará una oportunidad. Lo mejor es sacar a flote el problema
o la oportunidad y entonces definirlo en términos claros.

También es peligrosa la situación en la que los únicos interesados en el


problema y su solución son los implicados en el proyecto. Muchas veces los
técnicos desean aplicar nuevas técnicas o herramientas y organizan un
proyecto entorno a éstas. En todo caso lo que se debe hacer es buscar en la
empresa, identificando alguna aplicación que no sea compleja y que sea útil a
los objetivos de la misma.

Los siguientes puntos nos dan una idea de la forma de pensar, así como
las tareas a realizar durante esta fase:

 Estudiar el sistema actual,

 Discutir y analizar lo que se desea obtener,

 Clarificar las áreas de la empresa que se verán afectadas,

 Definir el problema y sus componentes, aclarando: que es fundamental,


que es deseable y que es opcional.

8
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

 visualizar el producto o sistema a proporcionar, así como su adaptación a


la organización.

 Identificar al responsable del proyecto.

 Crear una declaración clara de lo que se va a hacer.

 Obtener el sí de los implicados: “Sí, tenemos exactamente ese problema”

En todas las fases y en esta de forma especial se debe estimar los costes
previsibles del proyecto y sobre todo el coste de la siguiente fase, la
planificación.

En muchas organizaciones, una vez definido el problema, éste se añade a


la lista de los problemas pendientes de resolución. De modo que un comité
de dirección selecciona el próximo problema a resolver, o sistema a
desarrollar.

5.1.2. Planificación del proyecto.

La planificación del proyecto es la fase en la que se deberán identificar


todas las cosas necesarias para poder alcanzar el objetivo marcado. En esta
fase se han de concretar los tres cimientos sobre los que se apoyará el
desarrollo de todo el proyecto, estos son:

 Calidad: viene dadas por las especificaciones.

 Coste económico, valorado en el presupuesto.

 Duración: asignada en el calendario de trabajo.

Así como en la fase anterior nos centrábamos en identificar el problema,


aquí tendremos que identificar diferentes soluciones y los costes asociados a
cada una de ellas.

9
GESTIÓN DE PROYECTOS INFORMÁTICOS

Aunque muchos autores separan el análisis de la aplicación de la propia


planificación, por entenderse que la primera es una tarea técnica, mientras
que la planificación es una tarea de gestión, cronológicamente se han de
realizar de forma simultánea, aunque, se debería partir de una especificación
seria del problema, antes de planificar las tareas, costes y recursos necesarios
para desarrollar la aplicación.

Otro asunto es que cada trabajo que se realiza se debe planificar antes de
acometerlo. Así antes de realizar el análisis se deberá hacer una planificación
de los trabajos asociados a éste, pero difícilmente se podrá realizar la
planificación de todo el proyecto.

Las tareas a realizar para planificar el proyecto, las podemos agrupar en:
 Estimar el tamaño de la aplicación a desarrollar.
 Estimar el coste en recursos humanos.
 Identificar las tareas a realizar.
 Asignar recursos a cada tarea.
 Crear un calendario de las tareas.
 Realizar un estudio económico.
 Reunir todo en un documento, Estudio de viabilidad.

Todas estas tareas se suelen realizar de forma secuencial o iterando entre


ellas, otro asunto es la secuencia a seguir. En este libro organizaremos una
secuencia lógica de modo que lo s temas enlacen unos con otros. La
secuencia que seguiremos es la implícita en la lista anterior, aunque la
realidad es más compleja y nos encontraremos ante diferentes secuencias y en
procesos iterativos.

En otras ingenierías se utiliza la siguiente secuencia:


 Descomposición del trabajo a realizar en tareas.
 Asignación de recursos a cada tarea.
 Cálculo del esfuerzo necesario
 Creación de un calendario
 Estudio económico.

10
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

5.2. Ejecución del proyecto.

En esta fase, se trata de llevar a cabo el plan previo. Se verá fuertemente


influida por la planificación. Una mala planificación, llevará a una mala
ejecución, ya que si se planifica que costará menos tiempo del real, los
usuarios presionarán a los desarrolladores, con lo que éstos trabajarán en
peores condiciones, del mismo modo, si se planifica un coste inferior, los
administradores de la empresa presionarán al personal del proyecto, con lo
que estos trabajarán con más estrés.

En la ejecución del proyecto se identifican tres subfases: la puesta en


marcha, la subfase productiva y la conclusión del proyecto.

5.2.1. Puesta en marcha.

Esta fase se caracteriza fundamentalmente porque en ella se ha de


organizar el equipo de desarrollo, los mecanismos de comunicación, la
asignación de roles y de responsabilidades a cada persona. Tareas
fundamentales son:
 Identificar las necesidades de personal, que aunque ya venían de
la fase de planificación, habrá que ajustarla a las disponibilidades
actuales.
 Establecimiento de la estructura organizativa.
 Definir responsabilidades y autoridad.
 Organizar el lugar de trabajo. En muchas ocasiones el comienzo
de un proyecto tiene tareas como instalación de equipamientos,
acondicionamiento de locales, …
 Puesta en funcionamiento del equipo. Cuando las personas que
van a trabajar en un proyecto no se conocen, es oportuno el
organizar reuniones más o menos informales para que se
conozcan, esto evitará malentendidos y conflictos durante la
ejecución del proyecto.
 Divulgación de los estándares de trabajo y sistemas de informes.
Al comenzar el proyecto, las personas están más receptivas que
cuando se encuentran en un trabajo rutinario o cuando el objetivo
se transforma en algo obsesivo. Ésta es una razón de peso para

11
GESTIÓN DE PROYECTOS INFORMÁTICOS

introducir los nuevos métodos de trabajo. Es posible que sea el


cliente el que marque los estándares.

5.2.2. Fase productiva.

En esta subfase, ya tenemos el proyecto con su calendario etc., las


especificaciones claras, los recursos y personas en situación de trabajo. Las
personas deben llevar a término cada una de las tareas que se les ha asignado
en el momento que se le haya indicado. En caso de que alguna persona
piense que se pueden producir problemas que vayan a incrementar la
planificación, deben informar lo antes posible al responsable del proyecto.

Por su parte el responsable del proyecto debe:


 tomar medidas del rendimiento,
 revisar los informes que le llegan de los empleados,
 mantener reuniones para identificar los problemas antes de que
aparezcan,
 en caso de desviaciones poner en práctica las acciones correctivas
necesarias,
 coordinar las tareas,
 motivar y liderar a los empleados,
 recompensar y disciplinar

5.2.3. Conclusión del proyecto.

Ésta subfase es la opuesta a la de puesta en marcha. En ésta se trata de


primero dar por finalizado el proyecto y entregar el producto, o dejar de
producir el servicio encomendado. Ésta suele ser una fase muy alegre, se han
alcanzado los objetivos propuestos, pero también algo triste, hay que
separarse de los compañeros de trabajo.

Las actividades a realizar son las siguientes:


 Hacer entrega definitiva del producto al cliente,
 Revisar las desviaciones del proyecto, identificar causas e indicar
formas diferentes de actuación en futuros proyectos.

12
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

 Reasignar el personal a los nuevos proyectos o reintegrarlos en


los departamentos de partida.
 Es interesante documentar las relaciones entre los empleados para
futuros proyectos.

6. Visión global del proyecto y los costes.


Cuando tratamos de ver un proyecto desde un punto de vista lejano,
podemos apreciar algunas curiosidades que nos dan una idea de la
importancia de cada fase. Así desde el punto de vista del coste, las primeras
fases se caracterizan por tener costes bajos, mientras que la cantidad de coste
que se compromete es muy alta. En otras palabras, al principio gastaremos
poco dinero en decir que es lo que queremos, pero esto condicionará una
serie de gastos en el resto del proyecto. Por contra las ultimas fases se
caracterizan por tener un coste alto, aunque los compromisos que se toman
son bajos, ya se decidió el curso de los gastos a priori. La figura 1 muestra la
relación descrita.

13
GESTIÓN DE PROYECTOS INFORMÁTICOS

Coste

acumulado

Comprometido

definición Planificación Lanzamiento producción conclusión

figura 1

Bibliografía.
1. Shtub, A., Bard, J. Et Sholomo, G. “Project Management Engineering,
Technology and Implementation”, Prentice-Hall, 1994.
2. Haynes, M. E. “Administración de proyectos” Grupo editorial
Iberoamerica, 1992.
3. Weiss, J. W., Wysocki, R.K. “Dirección de proyectos, las 5 fases de su
desarrollo”. Addison-Wesley Iberoamericana.
4. Davis, W. S. “Herramientas Case” Editorial Paraninfo, 1992.

14
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

2. ESTIMACIÓN EN
DESARROLLO DE
SOFTWARE.

1. INTRODUCCIÓN.
Este tema se centra en la estimación del esfuerzo que tendrá que realizar
una empresa para desarrollar una aplicación. Por esfuerzo nos referimos a la
cantidad de recursos humanos, usualmente medidos en meses/hombre.
Partiremos de que ya se ha realizado un análisis estructurado y disponemos
de la especificación de requerimientos del sistema. Por desgracia esto no es
habitual, como dice Edward Yourdon un problema de la estimación es que se
nos pide que la realicemos cuando aún no está claro que desea el usuario (no
disponemos de la especificación).

Comparando esta ingeniería con la arquitectura (construcción de


edificios), el arquitecto para valorar lo que costará construir un edificio
necesitará tener los planos de éste. Además, lo que en urbanismo se conoce
con el nombre de edificio singular ,edificios que tienen formas extrañas (la
Sagrada Familia de Gaudi, etc.), tienden a salirse del standard y deben ser
valorados cuidadosamente. En el desarrollo de software nos podemos
encontrar con algo similar, la gran mayoría de las aplicaciones que se
desarrollan se hacen muy a medida del usuario, es decir se apartan con
mucha frecuencia de lo que serían aplicaciones fácilmente estimables.

Descompondremos el proceso de estimación del esfuerzo necesario para


realizar el desarrollo de una aplicación informática como muestra la figura 1.

15
figura 2
GESTIÓN DE PROYECTOS INFORMÁTICOS

Especificación de Requisitos a
requerimientos Cumplir Tareas a
realizar

Medir lo que
Estimación Descomponer
quiere el
del Esfuerzo por fases y
usuario tareas

Estimar lo
Medida de lo que que Costara
(esfuerzo) Historial
quiere el usuario Empresa

MEDIR LO QUE QUIERE EL USUARIO, volviendo al ejemplo anterior


sería como medir la casa que se quiere es decir lo que serían m2 de suelo,
pilares, vigas, etc., (en otros temas veremos lo relacionado con las calidades
y también los riesgos de construir en zonas sísmicas). Conociendo los
elementos (pilares, etc.) de los que constará nuestro sistema, pasamos a
valorar cada uno de ellos. Hay pilares gordos, finos, altos y bajos, cada uno
requiere una cantidad de hormigón diferente, un trabajo de encofrado, etc..
Para valorar cada elemento utilizaremos medidas "objetivas" (con estadísticas
anteriores) y una dimensión "homogénea". En el caso de la construcción es
difícil pensar en una medida "homogénea" ya que intervienen muchas
dimensiones m3 hormigón, m2 cristal, horas de trabajo, etc.. En el caso de
proyectos informáticos esta medida hará referencia, de forma indirecta, a la
cantidad de esfuerzo humano y técnico a aplicar. Sumando las valoraciones
de cada elemento obtendremos una primera aproximación del esfuerzo
demandado.

También deberemos valorar otros factores que pueden afectar al coste,


tales como el tener que armonizar con el entorno o si el lugar de
construcción es muy lluvioso o muy frío.

A lo largo del tema transferiremos esta estructura de cálculo al caso de


proyectos informáticos.

16
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

ESTIMAR LO QUE COSTARÁ, Una vez medido lo que quiere el


usuario debemos estimar lo que le costará a nuestra empresa desarrollar este
proyecto. Para realizar este proceso hace falta experiencia en valoraciones.
Esta experiencia puede gestionarse de dos formas diferentes, individual y de
empresa:

 La experiencia individual es la que aporta un individuo de la


organización que, tras acumular muchas experiencias en su mente,
tiene una apreciación de "por donde van los tiros".

 La experiencia de empresa se basa en la información que ésta ha ido


acumulando en ficheros históricos sobre valoraciones realizadas y
costes reales de desarrollos realizados.

Ésta última forma de experiencia es más deseable que la primera ya que


permite un mayor cúmulo de información, más proyectos. También es menos
dependiente de las personas, con lo que la empresa será más estable a
posibles pérdidas de personal. Además esta más estructurada ya que se
pueden recoger todas las medidas que los diferentes directores de proyecto
estimen necesarias. Por ejemplo podría recoger información sobre
herramientas usadas, grado de experiencia al aplicarse, etc.. Esto no quiere
decir que la primera sea innecesaria, sino que habrá que conjugar las dos, ya
que siempre habrán momentos en los que aplicar el "sentido común" y este es
imposible de sintetizar completamente.

DESCOMPONER EL ESFUERZO POR FASES. Una vez obtenido el


esfuerzo, meses/hombre o similares, hay que asignar estos esfuerzos a tareas
y personas, dado que no suele cobrar lo mismo el analista que el
programador, el que tiene experiencia y el que no, etc.. Lo razonable es
identificar a grandes rasgos las diferentes componentes del proceso de
desarrollo del software de modo que cada a una se pueda asignar un tipo
determinado de personal.

Una vez conocidas las tareas a realizar se deberá programar (planificar), el


proceso de desarrollo y de esta planificación obtendremos una estimación
económica del coste. Este punto lo veremos en otros temas.

17
GESTIÓN DE PROYECTOS INFORMÁTICOS

En este tema revisaremos varios métodos para realizar estimaciones del


coste de software. Nos centraremos en uno de los que actualmente tiene más
respaldo entre los consultores, además de soporte con herramientas CASE e
incluso parece ser que se encamina a transformarse en un standard.

2. METODOS UTILIZADOS PARA LA


ESTIMACIÓN DE PROYECTOS.
La estimación de proyectos acompaña a cualquier ingeniería y la
informática no es una excepción. Otro tema son los métodos utilizados y su
fiabilidad (conformidad con los resultados obtenidos). Dada la juventud de la
informática hasta hace poco no se vislumbraban métodos estándar. Esta es
una de las razones que hace aconsejable el hacer un pequeño repaso a los
métodos utilizados hasta hoy en día. La siguiente clasificación ha sido
ampliada en clase:

 Métodos basados exclusivamente en la experiencia:

 Juicio experto

 Puro, tal y como lo propone Gibson (página 59)

 Delphi que es la propuesta de O’Conell (página 128)

 Analogía. King en la página 86 da una visión detallada, aunque


con estos métodos cada uno se lo adapta. O’Conell también lo
comenta

 Distribución de la utilización de recursos en el ciclo de vida como


base de la estimación como propone King (página 86)

 Método basado exclusivamente en los recursos: Parkinson:

18
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

 Método basado exclusivamente en el mercado: Precio para vender

 Método basado en los componentes del producto a desarrollar o


proceso de desarrollo:

 Top-Down

 Bottom-up

 Métodos algorítmicos, se basan en la utilización de fórmulas que


aplicadas sobre modelos top-down o bottom-up producen una
estimación de coste del proyecto

Barry W. Boehm en su articulo titulado “Software Engineering


Economics” hace un repaso de algunos de estos métodos.

3. PUNTOS DE FUNCIÓN.
Esta técnica de medición y estimación trata de evaluar una aplicación
informática en base a sus características externas. Estas características se
descomponen en dos grupos: la funcionalidad que provee el sistema y los
factores de complejidad. La funcionalidad que provee el sistema son aquellos
elementos que dan soporte a formularios de entrada, salidas, consultas y
ficheros a los que debe dar soporte la aplicación. Los factores de
complejidad son indicadores del entorno en que se ha de desarrollar y
explotar la aplicación informática.

Este método de estimación contempla la aplicación a desarrollar como


una caja negra, es decir, no se interesa por las interioridades de la aplicación,
sino que se centra en lo que puede ver el usuario.

El ejemplo clásico de una caja negra es el equipo de música, en el que los


usuarios están interesados por su funcionamiento externo, la calidad del
sonido y el coste, prescindiendo usualmente de como estén construidos los
circuitos integrados o sus transistores.

19
GESTIÓN DE PROYECTOS INFORMÁTICOS

Por otra parte evaluamos de forma explícita los factores de desarrollo que
influyen sobre la productividad como lenguajes de desarrollo, entornos de
trabajo, etc. Seguiremos manteniendo la idea de caja negra, ya que los
gestores del desarrollo no están interesados en cómo se desarrolla en cada
lenguaje (ensamblador, 4GL, etc.) sino que se centran en los diferentes
niveles de productividad que se tiene con cada uno de ellos. El que realiza la
estimación necesitará tener información histórica que sea apropiada sobre los
lenguajes, como veremos más adelante.

3.1. IDENTIFICACIÓN DE LOS ELEMENTOS DE FUNCIÓN.

Partimos de una especificación de la aplicación a desarrollar, en nuestro


caso suponemos que está disponible el DFD de ésta, el modelo Entidad-
Relación de los datos y el Diccionario de Datos que definen a la aplicación.
La funcionalidad que provee el sistema esta asociada a los siguientes
componentes de la aplicación:

 Entradas desde el exterior del sistema (Pantallas, lecturas de scanner, etc.).

 Salidas al exterior (Pantallas, Listados, etc.).

 Consultas (entrada seguida de una salida).

 Ficheros lógicos internos, grupos de datos que se mantienen internamente.

 Ficheros de interfaz, grupos de datos que se mantienen externamente.

Veamos algunas definiciones pr evias:

 Proceso elemental: es la menor unidad de actividad que tiene sentido para


el usuario, conocedor del sistema en estudio.

 Datos e informaciones de control: son los datos elementales con que


trabaja la aplicación en estudio. Nos referiremos a ellos siempre como
datos aunque se componen de los Datos propios del sistema en estudio

20
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJOfigura 3

más las Informaciones de Control que solicita el usuario (mensajes de


error, claves de seguridad, etc.)

 Lógica de proceso: se trata de procesos que se producen como


consecuencia de un proceso elemental y puede ser de dos tipos:

 Ediciones, algoritmos o cálculos

 Accesos a un fichero ya sea para consulta o actualización

Veamos en detalle cada tipo de elemento de función, su definición, y


ejemplos de éstos.

3.1.1. ENTRADAS DESDE EL EXTERIOR DEL SISTEMA.

En esta categoría clasificaremos todos los procesos elementales que hacen


llegar a la aplicación datos desde
el exterior, provenientes de un
usuario o de otra aplicación. El
flujo de datos deberá tener una
sola dirección, del exterior al
interior. Como consecuencia de
una entrada siempre deberá
actualizarse un fichero lógico
interno. En la figura 2 se muestra
su apariencia en el DFD.

Ejemplo de estas entradas son


los procesos asociados a:

 Pantallas para entrada de datos a la aplicación en cada transacción.

 Otros tipos de entradas como lecturas de códigos de barras, tarjetas


magnéticas, captura de imágenes, voz, o cualquier otro sistema que se
utilice para obtener información suministrada por el usuario.

21
figura 4
GESTIÓN DE PROYECTOS INFORMÁTICOS

Un mismo formato externo de pantalla de entrada que se


utilice varias veces, se contará como diferentes procesos en el
caso de estar soportado con una lógica distinta. Nos realizamos
las siguientes preguntas para asegurarnos de contar una
entrada:

Cuestión: Respuesta
Entran datos desde exterior de la aplicación Sí
Existen datos en algún fichero lógico interno que son actualizados Sí
El proceso es la unidad mínima de actividad que tiene sentido para el Sí
usuario
El proceso es completo y deja al sistema en un estado consistente SÍ
Para el proceso subyacente se debe de cumplir AoB
A Lógica del proceso exclusiva de esta entrada, o la primera vez
que la contamos
B Los datos elementales son diferentes de otras entradas

3.1.2. Salidas

En esta categoría clasificaremos


los procesos elementales que
elaboran informaciones dentro del
sistema y que se transmitan a un
usuario u otra aplicación
atravesando la frontera del sistema.
En la figura 3 se muestra su
apariencia en el DFD.

Las salidas están asociadas a:

 Pantallas para informar al


usuario del resultado de un proceso. Este puede ser correcto o
erróneo.

22
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

 Listados que se producen como consecuencia de un proceso, incluimos


cualquier formato, ya sean textos, gráficos, códigos de barras, etc..

 Formatos especiales de salida como grabación de bandas magnéticas,


etc.

 Transferencias de datos a otras aplicaciones, ya sea mediante ficheros


editados con el formato requerido o transmisiones de datos.

Identificaremos distintas salidas aunque tengan el mismo formato si la


lógica de generación es diferente, o viceversa aunque tengan la misma lógica,
difieran los datos elementales que la componen.

Si de un mismo listado se hacen varias copias para enviar a diferentes


usuarios, sólo se contará una vez. Por el contrario si un listado incluye varias
lógicas de generación se contará varias veces, por ejemplo listado de
compras de clientes se podría componer de un listado individualizado y a
continuación de un listado resumido por zonas. Los mensajes de error que se
producen en la edición de una entrada no se han de contar, ya que pertenecen
a la entrada.

Nos realizamos las siguientes preguntas para asegurarnos de contar una


salida:

Cuestión: Respuesta
El proceso envía datos o información al exterior de la aplicación Sí
El proceso es la unidad mínima de actividad con sentido para el usuario Sí
El proceso es completo y deja al sistema en un estado consistente SÍ
Para el proceso subyacente se debe de cumplir AoB
A Lógica del proceso exclusiva de esta salida (o primera vez)
B Los datos elementales son diferentes de otras salidas

23
figura 5
GESTIÓN DE PROYECTOS INFORMÁTICOS

3.1.3. CONSULTAS.

En esta categoría clasificaremos los procesos elementales que están


formados por una combinación de entrada y salida, produciendo una consulta
a los datos.

La salida no puede contener información derivada (calculada). Como


consecuencia de una consulta no se modifican los datos del sistema (de
ningún Fichero Lógico Interno).

En la figura 4 se muestra su
apariencia en el DFD.

Son usuales en los sistemas


EN_LÍNEA, Las entradas de datos
EN_LÍNEA suelen ir precedidas de
una consulta.

Nos realizamos las siguientes


preguntas para asegurarnos de contar
una consulta:

Cuestión: Respuesta
Una petición atraviesa la frontera del sistema Sí
El proceso envía datos o información al exterior de la aplicación Sí
Se recuperan datos Sí
No se calculan datos derivados para enviar al exterior Sí
El proceso (entrada/salida) es la unidad mínima de actividad que tiene Sí
sentido para el usuario
El proceso es completo y deja al sistema en un estado consistente Sí
El proceso no actualiza ningún Fichero Lógico Interno Sí
Para el proceso subyacente se debe de cumplir AoB
A Lógica del proceso en su parte de entrada o salida, es distinto del de
otras consultas del sistema (o la primera vez)
B Los datos elementales de la entrada o salida son diferentes de otras
consultas

24
figura 6
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

3.1.4. FICHEROS LÓGICOS INTERNOS.

Un fichero lógico interno es un grupo de datos relacionados, tal y como


los percibe el usuario y que son mantenidos por la aplicación. Es decir, como
se usarían en un sistema manual.

Es importante diferenciar estos


de las entidades, relaciones, las
tablas o los ficheros resultantes del
diseño físico. Se identifican a las
agrupaciones de datos que el
usuario ya conoce como
relevantes para el sistema, por
ejemplo: Clientes, Artículos,
Facturas, Proveedores, etc.

Los ficheros se cuentan una sola vez independientemente del número de


procesos o frecuencia con que sean accedidos. Por supuesto de las veces que
aparezcan en los DFD para mejorar la legibilidad.

No hay que contar los ficheros de índices ni los ficheros intermedios


creados durante el diseño para simplificar el desarrollo, por ejemplo ficheros
de spool por no disponer de impresora dedicada, etc.. Los ficheros
intermedios inherentes a la filosofía de la aplicación sí que se cuentan, por
ejemplo matrícula-curso-97-98 que es actualizado por la aplicación y que el
usuario ha solicitado su existencia hasta que se cierre la matrícula del curso y
que más tarde se consolida en el fichero de alumnos UPV, etc.

Nos realizamos las siguientes preguntas para asegurarnos de contar un


Fichero Lógico Interno:

Cuestión: Respuesta,
Se trata de una agrupación de datos lógica o identificable desde el punto de
vista del usuario y satisface un requerimiento específico del usuario Sí
La agrupación de datos es mantenida por procesos de la aplicación en estudio Sí
La agrupación de datos es mantenida mediante un proceso elemental de la
aplicación Sí

25
GESTIÓN DE PROYECTOS INFORMÁTICOS
figura 7

La agrupación de datos no ha sido contada como un fichero de interfaz


externo Sí
3.1.5. FICHEROS DE INTERFAZ EXTERNOS.

Un fichero de interfaz externo es


un grupo de datos relacionados, tal DIAGRAMA DE CONTEXTO
y como los percibe el usuario,
referenciados por la aplicación, pero
mantenidos por otra aplicación. Es
decir, nuestra aplicación nunca
actualizará un fichero de este tipo y
además será un fichero interno de
otra aplicación.

Pueden ser ficheros que son


generados por otra aplicación y distribuidos en la empresa. Aparecerán en el
diagrama de contexto. Si el fichero que aparece en el diagrama de contexto
lo utiliza un proceso para cargar ficheros internos, entonces se deberá
contemplar como una entrada. En caso de escribirse un fichero, que aparece
en el diagrama de contexto, con el fin de que sea entrada a otra aplicación,
deberá contarse como una salida. Sólo contaremos como ficheros externos a
aquellos que son mantenidos por otras aplicaciones y de los que nuestra
aplicación hace uso.

Nos realizamos las siguientes preguntas para asegurarnos de contar un


Fichero de Interfaz Externo:
Cuestión: Respuesta
Se trata de una agrupación de datos lógica o identificable Sí
desde el punto de vista del usuario y satisface un
requerimiento específico del usuario
La agrupación de datos es referenciada, y externa, a la Sí
aplicación en estudio
La agrupación de datos no es mantenida mediante la Sí
aplicación en estudio
La agrupación de datos ha sido contada como un fichero Sí
lógico Interno en otra aplicación
La agrupación de datos no ha sido contada como un fichero Sí

26
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

lógico Interno de la aplicación en estudio


3.2. CÁLCULO DE LOS PUNTOS DE FUNCIÓN SIN AJUSTAR.

Las siguientes tablas muestran como clasificar los diferentes elementos de


función y asignarles pesos. Así por ejemplo una entrada que contenga 10
atributos y que en su lógica se requiera acceder a un fichero diremos que se
clasifica de complejidad baja y tiene asociados tres puntos de función, ver
tablas adjuntas.

CLASIFICACIÓN Número de Campos o Atributos de la Entrada


ENTRADAS 1-4 Atributos 5-15 Atributos 16 ó más Atrib.
BAJA BAJA MEDIA
0 ó 1 ficheros accedidos 3 3 4
BAJA MEDIA ALTA
2 ficheros accedidos 3 4 6
MEDIA ALTA ALTA
3 ó más ficheros accedidos 4 6 6

CLASIFICACIÓN Número de Campos o Atributos de la Salida


SALIDAS 1-5 Atributos 6-19 Atributos 20 ó más Atrib.
BAJA BAJA MEDIA
0 ó 1 ficheros accedidos 4 4 5
BAJA MEDIA ALTA
2 ó 3 ficheros accedidos 4 5 7
MEDIA ALTA ALTA
4 ó más ficheros accedidos 5 7 7

En el caso de las consultas diferenciaremos la complejidad de lo que sería


la entrada y la salida, le asignaremos la complejidad mayor de las dos (baja,
media o alta), pero solo un peso (3, 4 ó 6), equivalente al de una entrada de
la complejidad calculada.

Los ficheros de las entradas, salidas y consultas se calculan a partir de los


ficheros, lógicos internos o de interfaz externos, que son accedidos durante
el proceso asociado.

Los atributos son tipos de datos elementales reconocibles por el usuario.


En las entradas se contarán también aquellos datos que son almacenados en
un fichero como consecuencia de la entrada. Los datos que se almacenen en
muchos campos se contarán sólo una vez. Ejemplo DNI en la gestión de
notas. En las salidas se contarán los campos calculados, por ejemplo totales.
En las salidas no se deben contar ni los literales ni los campos provenientes
de variables del sistema como fecha, número de página, opciones de próxima

27
GESTIÓN DE PROYECTOS INFORMÁTICOS

página o página previa. Siempre se contarán los mensajes de verificación y


error como un campo que puede contener estos valores. También se cuentan
las opciones que indican la tarea a realizar, ejemplos son: aceptar o
continuar.

Complejidad FICHEROS Número de Campos o Atributos


LÓGICOS INTERNOS 1-19 Atributos 20-50 Atributos 51 o ­ Atributos
BAJA BAJA MEDIA
1 Registro Lógico 7 7 10
BAJA MEDIA ALTA
2-5 Registros Lógicos 7 10 15
MEDIA ALTA ALTA
6 o más Registros Lógicos 10 15 15

Complejidad FICHEROS Número de Campos o Atributos


INTERFAZ EXTERNOS 1-19 Atributos 20-50 Atributos 51 ­ Atributos
BAJA BAJA
1 Registro Lógico 5 5 MEDIA 7
BAJA MEDIA
2-5 Registros Lógicos 5 7 ALTA 10
MEDIA ALTA
6 o más Registros Lógicos 7 10 ALTA 10

Cuando se cuenten los atributos en un fichero se tendrá en cuenta:

 Sólo aquellos que el usuario es capaz de reconocer, aunque aparezcan


de forma repetida se cuentan una sola vez.

 Se han de contar los campos que hacen falta para mantener las
relaciones con otros ficheros Internos o Externos.

 Contar como un solo campo aquellos que aparecen como


consecuencia de las técnicas utilizadas en la implementación física:

 Campos que aparecen más de una vez en una agrupación de datos


por la tecnología o implementación. Por ejemplo un DNI que
aparezca en alumno y en una tabla de aficiones, si hemos decidido
que forman parte del mismo fichero las dos tablas.

 Campos repetidos con el mismo formato pero que están para


permitir múltiples ocurrencias. Por ejemplo nota ordinaria
(Febrero) y nota extraordinaria (Junio)

28
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

Para contar los registros lógicos (tipo de registro) de una agrupación de


datos (fichero), se han de tener en cuenta las siguientes reglas:

 Todo fichero tiene un conjunto de datos básicos (no repetitivos) más


otros registros lógicos.

 Un registro lógico es un subgrupo de datos elementales de un fichero,


identificables por el usuario. Hay dos tipos de subgrupos los
obligatorios y los opcionales. En el fichero de alumnos sería
obligatorio sus datos de acceso (Mayor-25, FP, COU y Otras-
Carreras que contendrán datos diferentes, habrá sólo uno de estos,
con el que accedió a la carrera actual) y opcionales como sus aficiones
deportivas, aficiones de lectura, etc. que pueden aparecer o no.

 Contar un registro lógico por cada subgrupo, opcional u obligatorio.

 Si no hay subgrupos contar un registro lógico.

Con esto se puede realizar la clasificación de los elementos de función. A


continuación hay que calcular los puntos de función sin ajustar, para ello se
puede utilizar la siguiente tabla, que además deja documentado el cálculo del
los Puntos de Función sin Ajustar (PFSA).

29
GESTIÓN DE PROYECTOS INFORMÁTICOS

Tipo Elemento Dificultad Peso Cantid Total Total Elemento


ad Puntos
Entradas Simple 3 E1 3 * E1
Media 4 E2 4 * E2
Compleja 6 E3 6 * E3
Total Puntos de Función
Entradas  Peso * Ei
Salidas Simple 4 S1 4 * S1
Media 5 S2 5 * S2
Compleja 7 S3 7 * S3
Total Puntos de Función
Salidas  Peso * Si
Consultas: Simple 3 C1 3 * C1
Máximo - Media 4 C2 4 * C2
Complejidad( Compleja 6 C3 6 * C3
Entrada, Salida ) Total Puntos de Función
Consultas  Peso * Ci
Ficheros Internos Simple 7 F1 7 * F1
Media 10 F2 10 * F2
Compleja 15 F3 15 * F3
Total Puntos de Función
Ficheros Internos  Peso * Fi
Ficheros de Simple 5 I1 5 * I1
Interfaz Media 7 I2 7 * I2
Compleja 10 I3 10 * I3
Total Puntos de Función
Ficheros de Interfaz  Peso * Ii

Total Puntos de Función Sin Ajustar (PFSA)  Peso*Xij

3.3. IDENTIFICACIÓN DE LOS FACTORES DE COMPLEJIDAD.

Los Puntos de Función sin ajustar son una aproximación de la


complejidad del sistema, pero quedan características externas que no hemos
contemplado, así como características del proceso de desarrollo del sistema
informático que influirán en el coste del sistema y que podemos cuantificar
desde las primeras fases del desarrollo. Estos factores adicionales según

30
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

Albrecht son catorce. Cada factor tomará un valor entre 0 y 5, de modo que
cuanta más importancia tenga un factor mayor valor se le asignará.

La siguiente tabla indica los valores posibles de un factor y su significado.

Valor asignado Significado del valor


0 Sin influencia, factor no presente
1 Influencia insignificante, muy baja
2 Influencia moderada o baja
3 Influencia media, normal
4 Influencia alta, significativa
5 Influencia muy alta, esencial

Con estos valores calculados, los sumaremos y obtendremos el Factor de


Complejidad Total.

A continuación describimos cada factor e indicamos cuando deberían


tomar los valores extremos, a modo de guía.

1) Comunicación de Datos.

Los datos usados en el sistema se envían o reciben por líneas de


comunicaciones.

0  Sistema aislado del exterior (sólo usuarios directos. Ej.: PC; BATCH ).

1  Aplicación batch con entrada de datos remota o (exclusiva) utilización


de periféricos de salida remotos.

2  Aplicación batch con entrada de datos remota y utilización de


periféricos de salida remotos.

3  plicación de captura de datos En_Línea o hay un sistema de


teleproceso que pasa los datos a la aplicación batch o sistema de
consulta.

4  Varios teleprocesos pero con el mismo protocolo de comunicaciones.

31
GESTIÓN DE PROYECTOS INFORMÁTICOS

5  Hay teleproceso con varios protocolos de comunicación. Sistema


Abierto y con interfaces de todo tipo al exterior.

2) Proceso Distribuido.

Existen Procesos o Datos distribuidos, y el control de estos forma parte


del sistema.

0  Sistema totalmente Centralizado o no tiene como objetivo el transferir


datos o procesos entre componentes del sistema.

1  El sistema realiza sus procesos en un equipo, pero las salidas se


preparan de modo que son utilizadas vía software de otros equipos.
Por ejemplo a la salida del sistema se accede vía una hoja de cálculo o
un procesador de textos en un PC.

2  El sistema captura los datos en un equipo, que les da formato, siendo


enviados a otro equipo del sistema que los trata.

3  Proceso distribuido pero con transferencia de datos "en línea" en una


sola dirección.

4  Proceso de datos distribuidos y transferencia de datos "en línea" en


ambas direcciones. Por ejemplo una red de cajeros automáticos en
donde éstos procesan parte la transacción.

5  El sistema esta ejecutándose en una red con procesos cooperantes


ejecutándose en distintos equipos.

3) Objetivos de Rendimiento.

Si el rendimiento es un requisito del sistema. Es decir es crítico algún


factor como tiempo de respuesta o cantidad de operaciones por hora. Se
tendrá que hacer consideraciones especiales durante el diseño, codificación y
mantenimiento.

32
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

0  Rendimiento normal (el que suelen dar los sistemas informáticos en los
que no se pone énfasis en este tema).

1  Se indican requerimientos de rendimiento y del diseño que son


revisados, pero no es necesario tomar medidas especiales.

2  El tiempo de respuesta o cantidad de operaciones por hora es crítico en


algunos momentos. No se solicita que realicemos un diseño de la
utilización de la CPU. Los procesos deberán estar terminados antes de
la siguiente sesión de trabajo (próximo día)

3  El tiempo de respuesta o cantidad de operaciones por hora es crítico


durante todas las horas de trabajo. No se solicita que realicemos un
diseño de la utilización de la CPU. Los requerimientos indican que los
procesos con sistemas de interfaz deberán estar terminados según
ciertas restricciones.

4  Además, los requerimientos indican que el tiempo de respuesta o la


cantidad de operaciones por hora es lo suficientemente crítico, como
para requerir tareas de análisis de rendimiento durante la fase de
diseño.

5  Además se utilizan herramientas de análisis de rendimiento durante el


diseño, desarrollo e instalación, con el objetivo de alcanzar el
rendimiento demandado por el usuario.

4) Configuración de Explotación Usada intensamente por Otros Sistemas.

El sistema tendrá que ejecutarse en un equipo en el que coexistirá con


otros, compitiendo por los recursos, y esta es una característica fundamental,
teniendo que tenerse en cuenta en las fase de diseño.

0  No se han indicado restricciones ni explícita ni implícitamente.

33
GESTIÓN DE PROYECTOS INFORMÁTICOS

1  Existen restricciones, pero son las usuales de cualquier equipo


departamental. No es necesario hacer consideraciones especiales.

2  El usuario declara explícitamente características de seguridad o


relativos a tiempos.

3  Algunos programas deben funcionar con restricciones en algún


procesador.

4  Las restricciones operativas definidas implican que el software deberá


funcionar con restricciones de uso del procesador central o en un
procesador dedicado.

5  Además, hay restricciones especiales para la aplicación en ol s


componentes distribuidos del sistema.

5) Tasa de Transacciones.

La tasa de transacciones será elevada. Se tendrá que hacer


consideraciones especiales durante el diseño, codificación e instalación.

0  No se prevén períodos con picos de transacciones.

1  Se prevén picos de operaciones de forma regular, pero poco frecuente


(mensualmente, trimestralmente o anualmente). Ejemplos serían la
automatricula, los cierres de contabilidad, o el préstamo de libros antes
de los exámenes.

2  Se prevén picos de operaciones semanales.

3  Se prevén horas punta, diarias. Ejemplo sería las ventas en los


supermercados.

4  La tasa de transacciones se prevé tan elevada que durante el diseño se


debe incluir tareas de análisis del rendimiento.

34
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

5  Se ha especificado una cantidad de transacciones muy elevada. Se


utilizarán herramientas de análisis de rendimiento durante el diseño,
implementación e instalación.

6) Entrada de Datos EN-LÍNEA.

La entrada de datos será directa desde el usuario a la aplicación, de


forma interactiva.
0  No hay entrada de datos interactiva, todo es batch.

1  Entre el 1% y el 7% de las transacciones son entradas interactivas.

2  Entre el 8% y el 15% de las transacciones son entradas interactivas.

3  Entre el 16% y el 23% de las transacciones son entradas interactivas.

4  Entre el 24% y el 30% de las transacciones son entradas interactivas.

5  La entradas de datos interactivas superan el 30% de las transacciones.

7) Eficiencia con el Usuario Final.

Se demanda eficiencia para el usuario en su trabajo, es decir se tiene que


diseñar e implementar la aplicación con interfaces fáciles de usar y con
ayudas integradas. Los tipos de elementos asociados a la eficiencia del
usuario son:
 Menús.
 Ayudas "en línea".
 Movimiento automático del cursor.
 Efectos de Scroll (papiro).
 Impresión remota (mediante transacciones en línea)
 Teclas de función predefinidas
 Lanzamiento de procesos batch desde las transacciones "en línea".
 Selección mediante cursor de datos de la pantalla.
 Pantallas con muchos colores y efectos.
 Documentación impresa de las operaciones “en línea”.

35
GESTIÓN DE PROYECTOS INFORMÁTICOS

 Uso de ratón.
 Ventanas de "pop-up".
 Forzar la aplicación a tener el menor número posible de pantallas por
transacción.
 Aplicación bilingüe (cuenta por cuatro).
 Aplicación Multilingüe (más de dos, cuenta por seis).

Toma el valor:

0  No hay especial énfasis en los interfaces de uso con el usuario.

1  De uno a tres de los factores anteriores.

2  De cuatro a cinco.

3  Seis o más factores, pero sin especiales requerimientos de eficiencia.

4  Más de seis factores, con requerimientos lo suficientemente específicos


como para justificar en el diseño estudios de los factores humanos.
Ejemplo: minimizar la cantidad de pulsaciones, proveer valores por
defecto, uso de marcos estandarizados, etc..

5  Igual al anterior, pero los requerimientos son tan fuertes que se


demanda la construcción de prototipos y utilización de herramientas
para su evaluación y comprobar que se alcanzarán los objetivos.

8) Actualizaciones EN-LÍNEA.

Los ficheros maestros y las Bases de Datos son modificadas directamente


de forma interactiva.

0  No hay actualizaciones interactivas.

1  Actualización en línea de uno a tres ficheros con información de


control. Ejemplo fichero con usuarios, horas en que se puede acceder,

36
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

etc.. La cantidad de actualizaciones es baja y es fácil recuperar el


fichero.

2  Igual al anterior, pero con cuatro o más ficheros de control.

3  Actualización En-Línea de ficheros lógicos internos importantes.


Ejemplo: en un banco sería TRANSACCIONES, CLIENTES,
CUENTAS, etc..

4  Además de lo anterior, es esencial la protección ante perdidas y el


sistema se ha de diseñar e implementar con estas consideraciones.

5  Gran cantidad de actualizaciones interactivas, debiéndose considerar


los costes de recuperación. Además deben tenerse sistemas de
recuperación, en caso de fallo, muy automatizados y con poca
intervención del operador.

9) Lógica de Proceso Interno Compleja.

La complejidad de los procesos es una característica de la aplicación.


Alguno de las siguientes características están presentes:

a) Los algoritmos matemáticos especificados complejos.

b) Procesos con lógica compleja.

c) Se han especificado muchas excepciones, consecuencia de


transacciones incompletas, que deberán tratarse.

d) Manejar múltiples dispositivos de entrada/salida.

e) La aplicación llevará incorporados sistemas de seguridad y control.

La complejidad algorítmica realmente está mal resuelta en esta técnica.


Hay que tener en cuenta que se ha desarrollado pensando en sistemas de

37
GESTIÓN DE PROYECTOS INFORMÁTICOS

proceso empresarial. Para sistemas complejos algorítmicamente hay técnicas


que miden la complejidad como las de McCabe.
La valoración será la siguiente:

0  No se da ninguna de las características anteriores.

1  Se da una característica de las enunciadas.

2  Se dan dos características de las enunciadas.

3  Se dan tres características de las enunciadas.

4  Se dan cuatro características de las enunciadas.

5  Se dan las cinco características de las enunciadas.

10) Reusabilidad del Código.

Se tendrá que hacer consideraciones especiales durante el diseño,


codificación y mantenimiento para que el código se reutilice en otras
aplicaciones.

0  No se piensa en reutilizar el código a generar.

1  Se pretende reutilizar el código a generar dentro de la propia


aplicación.

2  Menos del 10% de la aplicación tiene en cuenta las necesidades de más


de un usuario (sistema).

3  El 10% de la aplicación o más tiene en cuenta las necesidades de más


de un usuario (sistema).

4  La aplicación ha sido específicamente empaquetada y/o documentada


para ser fácil de reutilizar. La aplicación se adaptará a las necesidades
de los usuarios a nivel de código.

38
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

5  La aplicación ha sido específicamente empaquetada y/o documentada


para ser fácil de reutilizar. La aplicación se adaptará a las necesidades
de los usuarios por medio de parámetros.

11) Contempla la Conversión e Instalación.

Se proveerán facilidades de instalación y conversión en el sistema. Se


desea que la conversión del sistema antiguo sea fácil de realizar durante la
puesta en marcha del sistema nuevo.

0  No reemplazamos un sistema existente o no se requiere conversión.


Tampoco se enuncia nada sobre la instalación.

1  Se solicita facilidad de instalación.

2  Se ha solicitado procesos de conversión e instalación, se han


construido guías y han sido probadas, pero no son considerados
importantes en el proyecto.

3  Se han solicitado procesos de conversión e instalación, dándose guías


explícitas, y estos procesos han de ser probados. En este proyecto se
considera muy importante el proceso de conversión.

4  Adicionalmente a la valoración de 2 se añade el que tendrán que


desarrollarse herramientas de conversión e instalación probadas.

5  Adicionalmente a la valoración de 3 se añade el que tendrán que


desarrollarse herramientas de conversión e instalación probadas. El
sistema es crítico para la empresa y ya estaba automatizado. Los
usuarios no pueden permitirse el lujo de tener problemas o bajo
rendimiento durante la transición. Estas condiciones se han descrito
como requisitos a cumplir por el sistema.

39
GESTIÓN DE PROYECTOS INFORMÁTICOS

12) Facilidad de Operación.

Entendemos por operación del sistema los trabajos asignados al centro de


proceso de datos para una aplicación dada como: arranque, parada,
recuperación ante fallos, copias de seguridad. Aquí tendremos en cuenta la
minimización de las actividades manuales en el CPD. Así, ésta característica
se valora cuando se ha descrito desde las primeras fases, habiendo de
dedicarse especial atención durante el diseño, codificación y pruebas.

Se pueden tener en cuenta las siguientes posibilidades de automatización:



 Se proveerá de procesos de arranque, back-up y recuperación pero con
intervención del operador.

 Se proveerá de procesos de arranque, back-up y recuperación pero sin
intervención del operador (vale por dos).

 En la aplicación se minimiza la necesidad de montar cintas u otros
dispositivos de almacenamiento externo.

 Se minimiza la necesidad de manejar papel.

Valoraremos con:

0  No se especifica nada, en todo caso lo que debieran ser procedimientos


usuales de back-up.

1 a 4  sumar la cantidad de ítems en la lista anterior.

5  Sistema automático sin intervención humana.

13) Instalaciones Múltiples

El sistema ha de incluir los requerimientos de diversas empresas o


departamentos en donde se ejecutará (incluso distintas plataformas). Estas
características estarán presentes durante el diseño, codificación y pruebas.

40
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

0  En sólo un lugar.

1  Múltiples lugares pero con idéntico Hardware y entorno Software.

2  En el diseño se ha de tener en cuenta que rodará en diferentes


entornos, pero con Hardware y Software similares.

3  La aplicación deberá rodar en múltiples entornos de Hardware o


Software y se tiene en cuenta desde la fase de diseño.

4  Se documentará y se planearán sistemas para dar soporte a la


situaciones descritas en las valoraciones 1 o 2.

5  Se documentará y se planearán sistemas para dar soporte a la situación


descrita en la valoración 3.

14) Facilidad de Cambios

Se tendrá que hacer consideraciones especiales durante el diseño,


codificación y mantenimiento para que en el sistema sea fácil de introducir
cambios y fácil de adaptar al usuario. Esto contemplara:

a) Consultas flexibles del usuario. Podemos tener Consultas:



 Simples con condiciones lógicas And/Or que implican un solo
fichero lógico. Contar 1.

 Medias con condiciones lógicas de complejidad media mediante


And/Or que relacionan a más de un fichero lógico. Contar 2.

 Complejas con condiciones lógicas muy complejas mediante


combinaciones lógicas And/Or entre varios ficheros lógicos).
Contar 3.

b) Parámetros de la aplicación vía tablas ajenas al código.


41
GESTIÓN DE PROYECTOS INFORMÁTICOS

 El cambio de la configuración se hace efectivo al arrancar el


sistema al día siguiente. Contar 1.

 El cambio de la configuración se hace interactivamente y tiene
efecto inmediato. Contar 2.

Toma el valor::

0  No se especifica nada.

1  Se da un ítem de los descritos anteriormente con valor 1.

2  Se dan algunos ítems de los descritos anteriormente acumulando un


valor de 2.

3  Se dan algunos ítems de los descritos anteriormente acumulando un


valor de 3.

4  Se dan algunos ítems de los descritos anteriormente acumulando un


valor de 4.

5  Se dan algunos ítems de los descritos anteriormente acumulando un


valor de 5.

42
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

CÁLCULO del factor de complejidad total.

La siguiente tabla documenta el cálculo del factor de complejidad total


(FCT).
# Factor de Complejidad Valor (0..5)
1 Comunicación de Datos.
2 Proceso Distribuido.
3 Objetivos de Rendimiento
4 Configuración de Explotación compartida
5 Tasa de Transacciones
6 Entrada de Datos EN-LÍNEA
7 Eficiencia con el Usuario Final
8 Actualizaciones EN-LÍNEA
9 Lógica del Proceso Interno Compleja
10 Reusabilidad del Código
11 Contempla la Conversión e Instalación
12 Facilidad de Operación
13 Instalaciones Múltiples
14 Facilidad de Cambios

Factor de Complejidad Total (FCT)  Valori

3.4. OBTENCIÓN DE LOS PUNTOS DE FUNCIÓN AJUSTADOS.

Para obtener los puntos de función ajustados de una aplicación se utiliza


la siguiente fórmula:

PFA = PFSA * (0.65 + (0.01 * FCT))

43
GESTIÓN DE PROYECTOS INFORMÁTICOS

Esta fórmula indica que en principio cada factor de complejidad puede


actuar sobre los PFSA incrementando
140 o decrementando en un 2,5% la
120 cantidad de puntos de función
100 ajustados.
80
60 De forma global producirá una
40 valoración de los PFA de entre el 65%
20 y el 135% del PFSA.
0
0 35 70
Para calcular los puntos de función
de un proyecto nos podemos
encontrar en tres situaciones:

 La aplicación a desarrollar parte de cero. No tenemos nada


desarrollado que podamos utilizar, ni tenemos que convertir datos de
una aplicación previa. En este caso se aplica la fórmula que mide el
tamaño de la aplicación.

 La aplicación a desarrollar parte de una aplicación previa de la que


sólo se desea convertir los datos a la nueva aplicación. Deberemos
añadir a los puntos de función sin ajustar el tamaño que incorporaran
las utilidades de conversión (puntos de función de la conversión
CONVER). Así:

PFC=(PFSA+CONVER)*(0,65+(0,01*FCT))

 El cálculo más complejo se da cuando modificamos una aplicación. La


fórmula a utilizar es:

PFM = [(AÑADIDO+CAMBIADO+CONVER) * (0,65+(0,01*FCD))] +


(BORR*(0,65+(0,01*FCP)))

Donde se introducen los PF añadidos, cambiados, borrados y de


conversión, así como los factores de complejidad después de la modificación
(FCD) y los factores de complejidad previos a la modificación (FCP)

44
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

4. ESTIMACIÓN DEL E SFUERZO REQUERIDO


POR LA APLICACIÓN.
El objetivo ahora es estimar la cantidad de esfuerzo necesario para
desarrollar la aplicación. Este esfuerzo se mide en horas/hombre,
meses/hombre o años/hombre. Los puntos de función en cierto modo son
una medida subjetiva (aunque el objetivo de IFPUG es que esta subjetividad
se minimice), ya que se puede realizar valoraciones diferentes por personas
con diferentes puntos de vista. Además en principio este número no dice
nada, nos hace falta conocer la cantidad de meses/hombre que costará cada
punto de función.

La cantidad de horas/hombre por punto de función es algo difícil e


impreciso de valorar, de forma global. Esto es normal, lo contrario sería
suponer que la productividad de todas las empresas de desarrollo de software
es igual.

Se ha constatado que en una misma empresa se pueden realizar


estimaciones muy buenas conociendo su productividad histórica, aquí si que
tiene sentido el esperar que los puntos de función tengan cierta uniformidad,
cuando se utilizan entornos similares.

De forma general, para proyectos de tamaño medio (300 PFA), se han


publicado valores como los mostrados en la siguiente tabla:

Entorno, Lenguaje Horas / Punto Función Líneas Código/P.Función


Ensamblador 20 a 30 300
COBOL 10 a 20 100
Lenguajes 4GL 5 a 10 20

De todos modos esto no deja de ser una orientación ya que como indica
Thomsett algunas organizaciones usan valores como 40 horas por punto de
función en COBOL.

45
GESTIÓN DE PROYECTOS INFORMÁTICOS

Dreger comenta que la productividad no sólo varía entre programadores,


sino que también con el tamaño del proyecto. Indica que en algunos estudios
se ha llegado a la conclusión de que un equipo medio, en un proyecto de 400
PFA, utiliza 20 horas por punto de función, mientras que en un proyecto de
2000 PFA, pasa a ser de 52 horas por punto de función.

En cualquier caso nuestra empresa deberá mantener una base de datos con
la información de los proyectos realizados en ésta. Se deberá tener como
mínimo los puntos de función que se estimaron en cada proyecto, los que
resultaron a final del proyecto, el esfuerzo que costó, el entorno y los
lenguajes utilizados. Si deseamos una mejor información deberíamos
mantener la información de base para calcular los puntos de función, factores
de complejidad y añadir aquellos factores que pensemos que son relevantes
en nuestra organización. Un ejemplo de esto puede ser el suponer que el
apoyo de la alta dirección es un elemento clave, así pues lo valoraremos de 0
a 5 y mantendremos esta información para posibles interpretaciones futuras.

Con todas las cautelas que hemos indicado, podemos calcular el esfuerzo
requerido en nuestra organización para un proyecto como:

Esfuerzo = PFA * Promedio_Organización( Lenguaje )

Suponiendo que nuestra organización realiza proyectos de características


similares. con tamaños de entre 200 y 500 puntos de función. Para una
mayor precisión consultar la bibliografía.

Con esto obtendremos una aproximación a la cantidad bruta de horas,


meses o años hombre necesarios.

Hay que tener en cuenta que normalmente, aunque se trabaja 8 horas


diarias, sólo 5 son productivas, que un mes tiene 20 días de trabajo efectivos,

46
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

y que un año tiene 11 meses de trabajo. Es decir aproximadamente un año


tiene 220 días de trabajo real.

5. OTRAS UTILIDADES DE LAS MEDICIONES


MEDIANTE PUNTOS DE FUNCIÓN.
Dado que lo que realmente miden los puntos de función es la
funcionalidad de una aplicación informática, también se utilizan para:

 Comparar lo que solicitó el cliente con lo que recibió.

 Comparar la productividad de los diferentes entornos de desarrollo.

 Comparar la calidad que se obtiene mediante las diferentes técnicas de


desarrollo.

6. BIBLIOGRAFÍA Y REFERENCIAS A
CONSULTAR.
1. Albrecht, A.J. and Gaffney, J.E.. "Software Function, Source Lines of
Code, and Development Effort Prediction: A Software Science
Validation". IEEE Transaction on Software Engineering, Vol. SE-9, Nº
6, Nov. 1983, pp. 639-648. (Hemeroteca UPV).
2. Boehm, Barry. Software Engineering Economics. Reimpreso en
Software Management (4 ed.), Donald J. Reifer, IEEE Computer Society
Press 1993. (Biblioteca UPV).
3. Dreger, J.B. "Function Point Analysis", Prentice Hall, 1989. (Biblioteca
UPV).
4. Gibson, Robin. Managing Computer Projects. Avoiding the Pitfalls.
Prentice Hall, 1992. (Biblioteca UPV).
5. International Function Point Users Group: "Function Point as an Asset -
Reporting to Management", 1992. (Disponible para consulta restringida
en el Dpto.).

47
GESTIÓN DE PROYECTOS INFORMÁTICOS

6. International Function Point Users Group: "Function Point Counting


Practices Manual: Case Studies (Case Study 2)", Release 1.0, 1994.
(Disponible para consulta restringida en el Dpto.).
7. International Function Point Users Group: "Function Point Counting
Practices Manual", Release 4.0, 1994. (Disponible para consulta
restringida en Dpto.).
8. Jones, Capers. Applied Software Measurement - Assuring Productivity
and Quality". McGraw Hill, 1991. (Biblioteca UPV).
9. Jones, Capers. Assessment and Control of Software Risks. Yourdon
Press, Prentice Hall, 1994. (Biblioteca UPV).
10. King, Davis. Project Management Made Simple. A guide to successful of
computer Systems projects . Yourdon Press, Prentice Hall, 1992.
(Biblioteca UPV).
11. Kemerer, C.F.. "Reliability of Function Point Measurement: A Field
Experiment", Communications of the ACM, Feb. 1993. (Hemeroteca
UPV).
12. Kemerer, C.F. and Porter B.S.. "Improving the Reliability of Function
Point Measurement: An Empirical Study", IEEE Transaction on
Software Engineering, Vol. SE-18, Nº 11, Nov. 1992, pp. 1011-1024.
(Hemeroteca).
13. Low, G.C. and Jeffery, D.R.. "Function Point in the Estimation and
Evaluation of the Software Process", IEEE Transaction on Software
Engineering, Vol. SE-16, Nº 1, Jan. 1990, pp. 64-71. (Hemeroteca
UPV).
14. O’Conell, Fergus. How to Run Successful projects. BCS Series, Prentice
Hall, 1994. (Biblioteca UPV).
15. Pressman, R. Ingeniería del Software, un enfoque aplicado. McGraw Hill
1993. (Biblioteca UPV)
16. Thomsett, Rob. Third Wave Project Management: a Handbook for
Managing the Complex Information Systems of the 1990s. Yourdon
Press, Prentice Hall, 1993. (Biblioteca UPV).

48
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

3. IDENTIFICACIÓN DE FASES,
TAREAS Y ENTREGABLES EN
PROYECTOS INFORMÁTICOS

En este capitulo vamos a centrar nuestra atención en la descomposición


del esfuerzo asignado a un proyecto. En el capitulo anterior vimos como
realizar la estimación del esfuerzo.
H. S. Geneen dijo: “Para leer un libro, se va del principio al fin. Para
dirigir una empresa, se va exactamente al revés, Se empieza por los fines y
luego se hace lo necesario para conseguirlos”. En nuestro caso podemos
pensar de forma parecida, para realizar un proyecto, empezaremos por ver
cuales son los objetivos que queremos alcanzar y luego pensaremos que
cosas tenemos que hacer para alcanzar estos fines.
Esta descomposición pasará por identificar las fases de nuestro proyecto y
el esfuerzo a aplicar en cada una de ellas. A su vez estas fases se
descompondrán en tareas. También tendremos que marcar unos puntos
(hitos) de control que nos permitan saber si el proyecto va de acuerdo a lo
previsto.
Normalmente todas las fases y muchas tareas terminan en la generación de
uno o varios documentos. A éstos se les llama entregables. Este nombre se
debe a que pasan de manos del desarrollador a manos del controlador del
proyecto o del cliente. En los proyectos informáticos se suele asociar los
hitos a la consecución de un entregable.
De forma genérica ya habíamos identificado dos métodos
complementarios que se pueden aplicar en la descomposición de proyectos:
 la descomposición del proceso (Análisis, Diseño, Codificación, …), y
 la descomposición del producto (Contabilidad, Nomina,…).
Lo usual en este punto del proyecto es que éste ya se haya enfocado hacia
sólo un producto, es decir, los gestores de la empresa habrán identificado
diferentes productos a desarrollar y solicitado el desarrollo de uno de ellos.
Así será extraño que un proyecto consista en la nómina, contabilidad,

49
GESTIÓN DE PROYECTOS INFORMÁTICOS

facturación y gestión de la producción, todo de una pieza, por varias


razones, tales como:

 El tamaño de un proyecto tiene una relación directa y superior a la


lineal con el riesgo de fracaso.

 Los costes de coordinación suben tanto que la productividad media


del personal baja, estando correlacionada de forma inversa al tamaño
del proyecto.

 Las visiones actuales de desarrollo de software se aproximan cada vez


más al desarrollo incremental. Y éste consiste en implementar
subsistemas hasta alcanzar el sistema completo.

 Dado que un proyecto de gran tamaño debería seccionarse para su


implementación. Lo lógico es que sea la dirección estratégica de la
empresa la que identifique los subsistemas más críticos, y primeros
candidatos a ser desarrollados, y no que sean los desarrolladores de
software los que toman esta decisión.

Por lo visto, podemos suponer que el proyecto se refiere a un solo


producto, así pues veremos como primer paso una descomposición del
proyecto en fases (procesos) y en un paso posterior refinaremos esta
descomposición identificando las tareas.

Una vez conocidas las tareas a realizar se deberá programar (planificar), el


proceso de desarrollo y asignarse los recursos, fundamentalmente humanos.
La programación de proyectos la llevaremos a cabo utilizando las técnicas
matemáticas de la investigación operativa conocidas como PERT o CPM que
veremos más adelante en este libro.

50
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

1. DESCOMPOSICIÓN EN ACTIVIDAD
ES DEL
PROYECTO (WBS).
Empezaremos por ver la herramienta que se utiliza a la hora de
descomponer y documentar el trabajo de un proyecto, como un conjunto de
tareas. Habitualmente se le conoce como WBS (Work Breakdown Structure)
que literalmente significa estructura de descomposición del trabajo. Es un
método de representar de forma jerárquica los componentes de un proceso o
producto. Puede ser utilizado para documentar la descomposición de un
proceso, la descomposición de un producto, o de forma híbrida.

0.0. Proyecto
Contabilidad

1.0. Especificar 2.0. Analizar 3.0. Diseñar 4.0. Codificación 5.0. Pruebas
necesidades Contabilidad Aplicación

1.1. Estudiar 2.1. Estudiar 3.1. Diseño 4.1. Creación 5.1. Prueba
Sistema Actual Procesos B.D Esquema Unidades

1.2. ide. nuevas 2.2. Estudiar 3.2. Diseño 4.2. Codificación 5.2. Prueba del
carácteristica Datos Programas Programas Sistema

Hay dos formas de representar un WBS. La primera es mediante una


representación gráfica, en forma de árbol, como se muestra en la figura 1. La
segunda consiste en una lista indentada de tareas, como muestra la figura 2.

En ambos casos se muestra la misma descomposición del trabajo. Los


números se usan para etiquetar los nodos, de forma que dado un componente
resulte fácil localizarlo en la estructura. Dado un nodo de la estructura
decimos que contiene a todos sus descendentes, y esta contenido en su
antecesor. Así la el nodo “2.0. Analizar la contabilidad” esta contenida en el

51
GESTIÓN DE PROYECTOS INFORMÁTICOS

“0. Proyecto Contabilidad”, y contiene a “Estudiar Procesos” y “2.2.


Estudiar Datos”.
Para crear un WBS empezaremos por clarificar la utilidad que se desea de
esta estructuración. Nombramos un primer nodo con el nombre del proyecto.
Identificamos componentes de este nodo, tenemos que intentar crear una
estructura en la que cada nodo tenga del orden de 72 componentes.
Numeramos los nodos por niveles. Las tareas son los nodos del nivel más
bajo, las que no se descomponen más. De modo que los nodos que se
descomponen no indicaran que hay una tarea, sino el conjunto de tareas de
las que se compone.
En los proyectos informáticos es importante generar una ficha para cada
tarea identificada, en la que de momento anotaremos su número, nombre,
una breve descripción y el esfuerzo estimado.

0. Proyecto Contabilidad.
1. Especificar necesidades.
1.1. Estudiar Sistema Actual.
1.2. Añadir Nuevas Características.
2. Analizar Contabilidad.
2.1. Estudiar Procesos.
2.2. Estudiar Datos.
3. Diseñar Aplicación.
3.1. Diseño B.D.
3.2. Diseño Programas.
4. Codificación.
4.1. Construcción del esquema.
4.2. Codificación de los Programas
5. Pruebas
5.1. Prueba de Unidades
5.2. Prueba del Sistema

52
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

Especificación de tarea
Número: 3.1.
Nombre: Diseño B.D.
Descripción: Se diseñara la base de datos, partiendo del
modelo entidad-relación propuesto en el análisis y
con el objetivo de tener un sistema funcionando
sobre DB2.
Esfuerzo Estimado: 2 semanas/hombre
Entregables: Estructura de implementación de la B.D.
…: …

2. ENTREGABLES DE UN PROYECTO
INFORMÁTICO.
Dado que el objetivo final del proyecto es la entrega de un subsistema
informático (entregable) veamos algunas definiciones y utilidades de los
entregables. Los entregables los definiremos como "Productos que, en un
cierto estado, se intercambian entre los clientes y los desarrolladores a lo
largo de la ejecución del proyecto informático".

Los entregables los clasificamos como relativos al objetivo y relativos a la


gestión del proyecto. Son entregables relativos al objetivo todos aquellos
documentos que hacen referencia exclusivamente al sistema de información y
al subsistema informático en desarrollo. Pertenecen a este conjunto los
requisitos del sistema, la especificación del sistema, la documentación del
diseño, él código fuente, los programas ejecutables, los manuales de usuario,
etc. Los entregables relativos a la gestión del proyecto hacen referencia a
aquellos documentos que se refieren a la situación en que se encuentra un
proyecto, previsiones de costes, gastos realizados, informe sobre ambientes
de trabajo, etc., siendo su objetivo el poder controlar el proyecto. Pertenecen
a esta clase la planificación del proyecto, los presupuestos, los documentos
de control de la planificación o de la calidad, los estudios de riesgos durante
el desarrollo, etc.

53
GESTIÓN DE PROYECTOS INFORMÁTICOS

Se deberá definir de forma clara el conjunto mínimo de entregables


necesarios para dar por terminada cada fase de desarrollo. Aunque algunos
entregables se desarrollan a lo largo de varias tareas. Los entregables nos
proveen de:

1. Un conjunto de componentes que formarán el producto una vez


finalizado el desarrollo.

2. Los medios para medir el progreso y la calidad del producto en


desarrollo.

3. Los materiales necesarios para la siguiente etapa.

2.1. ENTREGABLES MÁS USUALES DE UN PROYECTO.

Dado que como hemos visto los entregables juegan un papel central en el
desarrollo de un subsistema informático, vamos a listar los más importantes.
Basándonos en el capitulo 4 de King tenemos:

 Estudio de viabilidad:

 Descripción breve del sistema propuesto y sus características.

 Descripción breve de las necesidades del negocio en el


sistema propuesto.

 Propuesta de organización del equipo de desarrollo y


definición de responsabilidades.

 Estudio de los costes, que contendrán estimaciones groseras


de la planificación y fechas, tentativas, de entrega de los
productos.

 Estudio de los beneficios que producirá el sistema.

 Análisis:

54
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

 Captura de requisitos:

 Análisis del sistema actual (si existe).

 Requisitos nuevos de los usuarios.

 Descripción del sistema propuesto.

 Especificación del sistema:

 Descripción del sistema (DFDs, etc.).

 Requisitos de datos.

 Requisitos de telecomunicaciones.

 Requisitos de hardware.

 Plan de pruebas de integración.

 Diseño:

 Descripción detallada del sist ema, contendrá:

 Programas, módulos reutilizables y objetos.

 Ficheros y bases de datos.

 Transacciones

 Diccionario de datos

 Procedimientos

55
GESTIÓN DE PROYECTOS INFORMÁTICOS

 Carga del sistema y tiempos de respuesta

 Interfaces, tanto humanos como de máquinas.

 Descripción de los controles del sistema propuestos.


Diseños alternativos recomendados.

 Estándares de programación y diseño de programas,


recomendados.

 Técnicas de implementación recomendadas: codificación


propia, compra de paquetes, contratación externa, etc.

 Plan de pruebas de programas.

 Codificación:

 Documentos del diseño final del sistema y de cada programa.

 Diagramas definitivos del sist ema y de los programas.

 Descripción detallada de la ló gica de cada programa.

 Descripción de las Entradas y Salidas (ficheros, pantallas,


listados, etc.).

 Listado de los programas, conteniendo comentarios.

 Cadenas de ejecución si es necesario (JCL, scripts, etc.).

 Resultado de las pruebas de cada unidad.

 Resultado de las pruebas de cada programa.

 Resultado de las pruebas de la integración.

56
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

 Guía para los operadores del sistema.

 Programa de entrenamiento de los operadores.

 Manual de usuario del sistema.

 Pruebas:

 Plan de pruebas del sistema (actualizado).

 Informe de los resultados de las pruebas.

 Descripción de las pruebas, el resultado esperado, resultado


obtenido y acciones a tomar para corregir las desviaciones.

 Resultados de las pruebas a la documentación.

 Instalación:

 Planes detallados de contingencias de explotación, caídas del


sistema y recuperación.

 Plan de revisión post-instalación.

 Informe de la instalación.

 Carta de aceptación del sistema.

 Mantenimiento:

 Listado de fallos detectados en el sistema.

 Listado de mejoras solicitadas por los usuarios (si no dan


lugar a nuevos proyectos).

57
GESTIÓN DE PROYECTOS INFORMÁTICOS

 Traza detallada de los cambios realizados en el sistema.

 Actas de las revisiones regulares del sistema y aceptación de


los niveles de soporte.

A todos estos documentos hay que añadir en todas las fases documentos
con la estimación y planificación de la próxima fase y del resto del proyecto.
También habrá que ir actualizando el índice de todo el material relacionado.

3. DESCOMPOSICIÓN EN FASES DEL


DESARROLLO DE UNA APLICACIÓN.
La descomposición por fases (actividades) se basa en referencias
históricas de la empresa que asocian una cantidad media de horas de trabajo
a una actividad concreta, de modo que dado un proyecto concreto podemos
estimar la cantidad de esfuerzo que se dedicara a esa actividad. En ésta se ha
de tener en cuenta el tipo de proyecto, el lenguaje de desarrollo y la
maduración de la organización. Martyn A. Ould, desde una perspectiva
histórica, ofrece en las siguientes gráficas estos datos comparativos.

58
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

Reparto del Esfuerzo a mediados de los ´70


Dirección Proyecto
20
Definición del
5 Sistema
Diseño del Sistema
% 5

46 Producción del
Sistema
24 Integración del
Sistema

0 10 20 30 40 50

Reparto del Esfuerzo a principios de los ´80

Dirección Proyecto
19
Definición del
14 Sistema
Diseño del Sistema
% 13

35 Producción del
Sistema
19 Integración del
Sistema

0 10 20 30 40

Reparto del Esfuerzo a finales de los ´80

Dirección Proyecto
21
Definición del
28 Sistema
Diseño del Sistema
% 15

25 Producción del
Sistema
11 Integración del
Sistema

0 10 20 30

59
GESTIÓN DE PROYECTOS INFORMÁTICOS

Estos datos muestran la evolución de la empresa, pero también el cambio


de lenguajes y entornos de trabajo.

En el siguiente gráfico, se muestran los resultados parciales que un jefe de


proyecto en HP ofrece sobre los proyectos en que ha trabajado. Este gráfico
tiene mayor nivel de detalle y muestra las características propias de una
empresa que vende software, así por ejemplo, a los Manuales se dedica el
7%. También añade tareas que aunque significan un componente importante
del esfuerzo suelen ser olvidadas, como: Supervisión y Soporte
Administrativo.
Reparto del Esfuerzo, Medias de HP
Investigación
20
Analisis y Diseño
2
19 Codificación
19 Depuración
% 11
Integración
8
7 Asegurar la
9 Calidad
Manuales
5
Supervisión

0 5 10 15 20 Soporte
Administrativo

Las empresas deberán identificar las fases (ítems del ciclo de vida) o
actividades importantes de desarrollo de sus aplicaciones y almacenar el
consumo de recursos (esfuerzo) aplicado en cada uno de éstas. Es
aconsejable el identificar aquellas componentes del desarrollo que supongan
un consumo substancial de recursos.

En la revista Computer de Mayo del ‘96, Caper Jones hace una propuesta
muy interesante en la que relaciona en una tabla 25 actividades, las que
suelen tenerse en cuenta en su empresa ante un proyecto nuevo, el tamaño
mínimo de proyecto a partir del que consideran la actividad, los costes
asociados en esfuerzo, salarios y coste económico de la actividad por punto
de función. Aunque no lo indica explícitamente, esto da lugar a una
justificación sencilla dando a del porqué los proyectos grandes tienen un
mayor coste por punto de función.

60
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

4. DESCOMPOSICIÓN DEL DESARROLLO DE LA


APLICACIÓN EN TAREAS.
Podemos plantear la descomposición desde el enfoque de entregables y
asociar las tareas a la producción de un entregable concreto. Este enfoque
tiene la ventaja de que la culminación de una tarea indica que ha concluido
un producto y viceversa. Dado que, como veremos, no es aconsejable el
tener tareas que duren más de una semana, se plantean problemas con
algunos entregables que cuestan más.

El planteamiento de descomponer por procesos o actividades puede


resultar más natural en algunos casos. Es más fácil el conseguir tareas
acotadas en el tiempo. Tiene la desventaja de que el proyecto no será tan
fácil de controlar ya que en muchos casos será la palabra de los realizadores
la única constancia de que la tarea está terminada o al "90%".

En cualquier caso los proyectos se planifican con dos horizontes, el de la


próxima fase y el del proyecto completo. En el horizonte de la próxima fase
se realiza con mayor nivel de detalle, mientras que según se alejan las fases se
aplica un menor nivel de detalle.

4.1. EL ENFOQUE DE EQUIPO EN LA IDENTIFICACIÓN DE


TAREAS, POR ACTIVIDADES.

La descomposición del proyecto con mayor nivel de refinamiento no


puede basarse en datos recogidos de forma analítica, sino que hace falta una
aportación personal de los miembros del equipo de trabajo, tanto para
identificar tareas como para asignarles esfuerzos. Se suele aconsejar el
trabajo en grupo donde todos puedan aportar sus conocimientos y
experiencias previas.

Hay que tener en cuenta que si identificamos las tareas y se las


imponemos a los desarrolladores, éstos funcionarán en una situación de
sumisión lo que puede tener efectos perniciosos tanto para los plazos de

61
GESTIÓN DE PROYECTOS INFORMÁTICOS

entrega como para la calidad del software. Por otra parte el dejar que sean
los propios desarrolladores los que identifiquen tareas y recursos, dentro de
un marco razonable (puntos de función) les llevará a una situación de
compromiso personal, pasando a interiorizar los objetivos y como
consecuencia obtendremos mejores resultados.

4.2. FORMAS USUALES DE IDENTIFICAR TAREAS ASOCIADAS


A UN ENTREGABLE.

Hay que tener en cuenta que la tarea fundamental de los desarrolladores


es escuchar a los clientes o usuarios y traducir sus requisitos a un lenguaje
comprensible por la maquina, de modo que el subsistema informático se
adapte a las necesidades expresadas. Así para cualquier tarea podremos
encontrar las siguientes subtareas:

 Documentarse, Buscar o Investigar,


 Organizar, Escribir Documentos,
 Verificar, Comprobar,
 Revisar, Actualizar Documentos,
 Entregar, Finalizar

Además de lo anterior hay que tener en cuenta que al ir desarrollando el


sistema obtenemos información que nos será útil a la hora de identificar
nuevas tareas. Así el análisis estructurado nos provee de una descomposición
del proyecto por productos: transacciones, archivos, entradas, salidas, etc. El
Diseño de programas nos descompone el sistema por módulos, el Diseño de
BD descompone por tablas, archivos, etc., y los diseños de interfaz de
pantallas, listados, mensajes, etc. Así por ejemplo una entrada puede ser que
requiera de una reunión con el usuario, un estudio de ésta y la posterior
presentación y aprobación de la propuesta a desarrollar.

4.3. TAREAS USUALES DE UN PROYECTO INFORMÁTICO.

Siguiendo la estructura de los entregables enunciados anteriormente y


basado en King identificamos las siguientes tareas:

62
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

 Estudio de viabilidad:
 Analizar el sistema propuesto y escribir una descripción.
 Definir y documentar posibles tipos de sistemas.
 Hacer un análisis de coste de sistemas similares.
 Hacer una estimación del tamaño del sistema, la planificación y los
costes. (tener en cuenta los entregables más importantes).
 Definir cualitativa y cuantitativamente los beneficios del sistema
propuesto.
 Realizar una planificación inicial del plazo de recuperación de la
inversión.
 Realización de una estimación detallada de costes, planificación,
recursos, etc., de la siguiente fase (Análisis).
 Asignar director del proyecto.
 Composición del documento de estudio de viabilidad.
 Presentación del documento de viabilidad a la dirección para su
aprobación.

 Análisis:

 Captura de requisitos:
 Definir el ámbito del sistema propuesto
 Funciones
 Dimensiones
 Usuarios
 Restricciones
 Entrevista a todos los usuarios propuestos y actuales:
 Determinar:
 Utilización del sistema actual
 Deficiencias del sistema actual
 Requisitos nuevos del sistema
 Documentar:
 Descripción del sistema actual
 Deficiencias del sistema actual
 Producir el documento de requisitos del nuevo sistema
 Incluir:

63
GESTIÓN DE PROYECTOS INFORMÁTICOS

 Requisitos del usuario priorizados


 Resoluciones sobre las deficiencias del
sistema actual
 Producir una lista de los beneficios tangibles e intangibles (un
refinamiento de la lista del estudio de viabilidad)
 Realización de una estimación detallada de costes,
planificación, recursos, etc., de la siguiente fase
(Especificación del sistema).
 Producir una estimación revisada de costes, planificación,
recursos, etc., para el resto del proyecto.
 Producir el documento de definición de requisitos; Esta tarea
incluye la construcción de un prototipo.
 Realizar una revisión final del documento de requisitos.
 Tomar la decisión de continuar o no con el proyecto.
 Definir las responsabilidades en la próxima fase para el
director, miembros del equipo de desarrollo y otros.

 Especificación del sistema:


 Definir el tipo de sistema propuesto: Transformar las
restricciones físicas, ambientales y operacionales a
características del sistema; Por ejemplo ¿Sistema basado en
transacciones? ¿Distribuido o centralizado? ¿Estaciones de
trabajo o terminales?
 Esquematizar el sistema propuesto: transformar los
requerimientos del usuario de la fase anterior en unas
especificaciones funcionales ( DFD, Organigramas, etc.)
 Construir el diccionario de datos: Describir todos los
elementos del DFD incluyendo funciones y datos; asegurarse
de que todas las relaciones inter-funcionales y entre datos
sean documentadas. Si existe DD de la empresa, hacerlo
compatible.
 Revisar y expandir el análisis de coste beneficio: Actualizar
con la información nueva; Verificar que los beneficios
esperados se mantienen y que el plazo de recuperación de la
inversión sigue siendo aceptable.

64
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

 Realización de una estimación detallada de costes,


planificación, recursos, etc., de la siguiente fase (Diseño del
sistema).
 Producir una estimación revisada de costes, planificación,
recursos, etc., para el resto del proyecto.
 Producir el documento de especificación del sistema.
 Realizar una revisión final del documento de especificación
del sistema.
 Tomar la decisión de continuar o no con el proyecto.
 Definir las responsabilidades en la próxima fase para el
director, miembros del equipo de desarrollo y otros.

 Diseño:
 Producir el diseño global del sistema, contendrá:
 Definir los programas y sus principales funciones.
 Definir los principales flujos de datos entre programas y
funciones.
 Diseñar el esquema de datos lógico y físico.
 Definir las fronteras con paquetes software, si existen.
 Definir los entornos de hardware y software, proponiendo
alternativas.
 Documentar los diagramas de diseño alternativos.
 Localización de paquetes software: Buscar paquetes software
apropiados que puedan implementar parte, o toda la funcionalidad
requerida del sistema de forma rentable y que, si se implementa,
ofrezca un entorno compatible con los objetivos de la organización.
(Puede realizarse antes del diseño, o de forma simultánea a la tarea
anterior).
 Desarrollar un diseño detallado del sistema, para cada alternativa de
diseño planteada:
 Crear una descripción narrativa detallada del diseño para
todo el sistema y cada una de sus partes (programas,
funciones y datos).
 Actualizar el diccionario de datos.
 Definir los componentes hardware específicos (Capturadores

65
GESTIÓN DE PROYECTOS INFORMÁTICOS

de datos, sistemas de comunicación, etc.) y sus funciones.


 Validar el diseño con las especificaciones del sistema.
 Documentar el entorno hardware y software necesarios para
esta alternativa.
 Revisar y expandir el análisis de co ste beneficio para cada alternativa:
 Actualizar con la información nueva.
 Verificar que los beneficios esperados se mantienen y que el
plazo de recuperación de la inversión sigue siendo aceptable.
 Evaluar las alternativas de diseño, para cada alternativa, documentar:
 Requerimientos de usuario que se alcanzan con esta
alternativa.
 Nivel de aceptación esperado de los usuarios.
 Realización de una estimación detallada de costes,
planificación, recursos, etc., de la siguiente fase
(Codificación) con esta alternativa.
 Producir una estimación revisada de costes, planificación,
recursos, etc., para el resto del proyecto.
 Alternativa recomendada.
 Desarrollo de un plan de test del sistema:
 Crear datos de entrada del test.
 Producir el listado de los resultados esperados.
 Producir el listado de los criterios de test.
 Desarrollar la planificación d e test del sistema.
 Desarrollar un plan de test diferenciado para cada alternativa.
 Identificar las necesidades de entrenamiento y documentación de los
usuarios; Definir las guías de:
 Documentación completa de usuario.
 Manuales de operador.
 Documentos y planificación de formación para usuarios y
operadores.
 Producir el documento de diseño del sistema.
 Realizar una revisión final del documento de diseño del sistema.
 Tomar la decisión de continuar o no con el proyecto.
 Recomendar una alternativa.
 Hacer recomendaciones sobre el nivel de compromiso, si los hay, de

66
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

programadores subcontratados y otros.


 Definir las responsabilidades en la próxima fase para el director,
miembros de los equipos de programación y test, así como de otros
implicados.

 Codificación:
 Producir un plan de trabajo:
 Creación de la lista detallada de tareas necesarias para
realizar la codificación y test de todos los componentes del
sistema.
 Producir una planificación para las tareas anteriores con las
fechas más tempranas y más tardías, así como la asignación
de responsabilidades.
 Instaurar los procedimientos para recoger los progresos y
estados del proyecto.
 Instaurar los procedimientos para recoger tiempos, si resulta
apropiado.
 Obtener la aprobación del plan de trabajo por parte de la
dirección.
 Realización del diseño detallado de cada programa:
 Diseñar detalladamente los diagramas:
 De estructura de los programas y jcl
 De estructura de los ficheros
 Pantallas, informes, y otras composiciones
 Esquemas de la base de datos
 Composición de las tablas y sus diseños
 Pseudocódigo de la lógica del programa. (Dependerá de los
métodos de diseño utilizados).
 Codificar, documentar y pasar los test en cada programa:
 Codificar el programa y los procedimientos de control (jcl)
 Realizar las pruebas de unidad, hasta que los programas se
adapten a las especificaciones descritas en las etapas
anteriores
 Actualizar todo lo necesario en el sistema y en el DD de la
organización

67
GESTIÓN DE PROYECTOS INFORMÁTICOS

 Realizar el test de integración


 Poner todos los programas probados en la librería de pruebas
de integración
 Realizar el test de integración de cada programa.
 Documentar todos los resultados del test de integración
 Terminar los manuales de operador y usuario, así como los de
formación.
 Realización de una estimación detallada de costes, planificación,
recursos, etc., de la siguiente fase (Prueba del sistema).
 Producir una estimación revisada de costes, planificación, recursos,
etc., para el resto del proyecto.
 Confeccionar el documento de diseño de programas y codificación.
 Realizar revisiones del documento de diseño de programas y
codificación.
 Obtener los resultados finales de la integración completa del sistema
y de las pruebas de integración.
 Definir las responsabilidades en la próxima fase para el director,
miembros del equipo de test, así como de otros implicados.

 Pruebas:
 Realizar el test del sistema
 Hacer el test de sistema de acuerdo al documento de test del
sistema.
 Verificar la operatividad de los manuales de usuario y
operador, utilizándolas en los cursos de formación de los
usuarios y operadores que realicen el test del sistema.
 Verificar los documentos de entrenamiento de usuarios y
operadores, utilizándolos en los cursos de formación de los
usuarios y operadores que realicen el test del sistema.
 Documentar completamente los resultados del test del
sistema.
 Revisar la planificación de instalación:
 Disponibilidad de los recursos.
 Revisión de los factores de contingencia que puedan afectar a
la instalación.

68
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

 Procesos especiales de final de mes y fin de año.


 Vacaciones y fiestas.
 Disponibilidad de soporte por parte de terceros vendedores.
 Revisión final del calendario de instalación.
 Esbozar el plan ante caídas:
 Criterios para las caídas.
 Identificación de recursos para contingencias.
 Horario para recuperaciones o abandonos.
 Desarrollar un acuerdo de nivel de servicio:
 Criterios de rendimiento de usuario, precisión y volumen.
 Criterios de apoyo de los vendedores.
 Tiempo medio entre fallos.
 Tiempo medio de reparación.
 Criterios de calidad del sistema.
 Frecuencia de medición.
 Producir los documentos de test en la entrega.
 Revisión y aprobación de los documentos de entrega.
 Aprobación de la documentación del sistema
 Documentación de programas.
 Manuales de operador.
 Manuales de usuario.
 Manuales de formación.
 Documentación de ayuda.
 Aprobación del plan de instalación.
 Aprobación de los planes de co ntingencia, recuperación y caídas
 Finalización del sistema completamente probado.
 Acuerdo de finalización del desarrollo del sistema.
 Acuerdo de finalización de los usuarios.
 Acuerdo de finalización del CPD.
 Acuerdo de finalización de gar antía de calidad.
 Acuerdo de finalización de finanzas.
 Instalación:
 Instalación del hardware y software nuevo.
 Formar a los primeros usuarios y operadores.

69
GESTIÓN DE PROYECTOS INFORMÁTICOS

 Desarrollar los planes de cont ingencia, recuperación y caída.


 Desarrollar los procedimientos de mantenimiento y versiones.
 Establecer procedimientos para:
 Versiones regulares
 Versiones de emergencia
 Versión por configuración (hardware o estaciones de trabajo)
 Llevar a cabo cualquier conversión de datos necesaria.
 Llevar a cabo la instalación del sistema nuevo a producción.
 Instalación completa desde cero.
 Instalación en paralelo.
 Instalación por fases.
 Comenzar el uso de los acuerdos de nivel de servicio.
 Planificar y programar las revisiones post-instalación:
 Establecer los criterios de:
 Rendimiento del sistema.
 Calidad del sistema.
 Satisfacción del usuario.
 Calidad y facilidad de manejo de:
 Manuales de usuario y operador.
 Formación de usuarios y operadores.
 Información y datos producidos.
 Fluidez de la instalación.
 Costes de desarrollo, instalación, operaciones y
mantenimiento.
 Establecer la planificación y calendario para
las revisiones:
 Asegurar la disponibilidad de:
 Personal requerido
 Documentación requerida
 Llevar a cabo las revisiones post-instalación:
 Crear el informe de la revisión post-instalación.
 Obtener la aprobación firmada de los informes de:
 Usuarios finales del sistema
 Operadores del sistema
 Auditoría y garantía de la calidad

70
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

 Desarrollo de sistemas
 Soporte de sistemas y mantenimiento
 Finanzas
 Obtener la carta de aprobación del sistema
 Establecer el calendario para otras revisiones post-instalación si es
necesario.

 Mantenimiento:
 Implementar los cambios del sistema:
 Utilizar los procedimientos de implementación de versiones,
o
 Implementar versiones de emergencia y después utilizar los
procedimientos de versiones fo rmales de forma retroactiva.
 Asegurarse de que el sistema continua solucionando las necesidades
de los usuarios.
 Utilizar los acuerdos de niveles de soporte.
 Revisiones regulares de requerimientos del nivel de
acuerdo.
 Revisiones regulares de como el sistema esta
alcanzando sus objetivos
 Llevar a cabo revisiones regulares del sistema
 Utilizar los procedimientos y contenido de las
revisiones post-instalación.
Estas tareas se han enumerado a modo de lista de comprobación, de
forma que serán los desarrolladores los encargados de identificar las tareas
apropiadas a cada proyecto así como los recursos necesarios, teniendo en
cuenta la estimación previa del esfuerzo.

5. ALGUNAS REFLEXIONES SOBRE LA


DESCOMPOSICIÓN DE UN PROYECTOEN
TAREAS.
Edward Yourdon sugiere algunas reglas a la hora de descomponer un
proyecto en tareas, de éstas cabe recordar:

71
GESTIÓN DE PROYECTOS INFORMÁTICOS

a) Hacer las unidades de estimación tan pequeñas como se pueda, a ser


posible que se aproximen a la semana.
b) Que las tareas sean tan independientes como se pueda, es decir no
cortar procesos naturales como la codificación de un módulo en varias
tareas.
c) Tener en cuenta los factores de comunicación entre personas, hacerlo
sencillo.
d) Tener en cuenta la posibilidad de reutilizar código, siendo conscientes
de que también es trabajo el buscarlo y adaptarse a este código.

6. BIBLIOGRAFÍA Y REFERENCIAS A
CONSULTAR.
1. David King. "Project management made simple", Prentice Hall, 1992.
2. Jones, Caper. “Activity-based software costing,” Computer, May 1996, p.
103-104.
3. Fergus O'Connell. "How to run successful projects". Prentice Hall, 1994.
4. Martyn A. Ould. "Strategies for software engineering". Jonh Wiley, 1990.
5. Yourdon, Edward. Análisis Estructurado Moderno. Prentice Hall, 1993.

4. ASIGNACIÓN DE RECURSOS
EN LOS PROYECTOS
INFORMÁTICOS

72
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

1. INTRODUCCIÓN.
La asignación de recursos consiste en asociar a cada una de las tareas, en
el proyecto, las personas, equipos y materiales necesarios para que éstas se
puedan realizar. Esta es una al bor complicada y fundamental en la
planificación del desarrollo de una aplicación informática.

La visión de las personas como recursos es errónea. Como dice Handy en


“La era de lo irrazonable”: “Las personas no son recursos humanos. Son
individuos vivos, con todo su derecho a ser diferentes.” De hecho, Peter
Druker, haciendo referencia a las empresas del futuro dice que no se
parecerán a lo que pueden imaginar empresarios y profesores, sino que serán
similares a los hospitales, universidades o grandes orquestas sinfónicas. Al
igual que estas tendrán en el conocimiento su principal recurso, pasando a
ser organizaciones compuestas fundamentalmente por especialistas que
trabajaran de acuerdo a las informaciones que reciban.

En cualquier caso esto no eximirá al director o coordinador de tener que


enfrentarse al reparto de tareas y adscripción de las mismas a los miembros
de la organización

Actualmente los recursos humanos son el componente económico más


importante, en los proyectos informáticos, por encima de los recursos físicos
como Hardware o instalaciones.

Como hemos visto, mediante la estimación con los Puntos de Función y


dependiendo de los datos históricos de la organización, estimamos el
esfuerzo que deberán realizar las personas encargadas de desarrollar la
aplicación.

El no tener en cuenta, con estas estimaciones, los recursos físicos de


instalaciones y hardware necesarios para el desarrollo parece deberse a que el
precio del Hardware baja de forma continua y que en todo caso el consumo

73
GESTIÓN DE PROYECTOS INFORMÁTICOS

de estos recursos es función de la cantidad de meses-hombre que dure el


proyecto2.

Otro aspecto importante es el de los consultores, profesionales externos,


que asesoran y dan soporte a tareas en donde la empresa no tiene experiencia
o le resultaría oneroso mantener a un empleado. En grandes proyectos
pueden llegar a suponer un importe similar al consumido por las personas
que desarrollan la aplicación.

De forma general podemos afirmar que el coste del proyecto total es el


doble del de los recursos humanos, el de los desarrolladores más el del HW,
Instalaciones y software base. En grandes proyectos, que se alejen del
proyecto típico de la organización habrá que añadir los servicios de empresas
consultoras, que pueden significar una parte más en el coste (tres veces el
gasto en recursos humanos). En cualquier caso, como vimos, la empresa
mantendrá un registro del esfuerzo dedicado a los proyectos informáticos y
su coste global.

En los recursos utilizados por el proyecto habría que incluir el consumo


de tiempo dedicado a éste por parte de los usuarios. No se suele tener en
cuenta y este puede suponer un esfuerzo considerable, aunque no se evalúe.
Suele salir a la luz en las críticas del tipo: "¡Con el tiempo que nos han estado
consultando y vaya aplicación han hecho!". También queda patente cuando
un usuario justifica el no asistir a una reunión por tener mucho trabajo
pendiente.

Desde un punto de vista global, además de las tareas propias del proyecto
debemos tener en cuenta, que para que un grupo haga su trabajo, es
necesario que:
 Se realicen las tareas en si mismas.
 Se realicen tareas de mantenimiento del equipo, esto es, lo que ayude
a mantener su cohesión, su motivación y su voluntad general de

2
Se puede argumentar que con un Hardware más eficiente, con unas oficinas mejor
acondicionadas o que con herramientas de desarrollo más evolucionadas se podría realizar
el proyecto en menos tiempo. Este tipo de cuestiones y otras que influyen en la duración y
calidad del Software las trataremos en DPI'

74
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

dedicarse a la tarea.
 Se satisfagan las necesidades individuales, es decir, lo que ayuda al
individuo a sentirse parte del grupo y le capacita para realizar su
aportación máxima.

Las planificaciones forzadas artificialmente, para que duren o cuesten


menos de lo previsible, condenan al proyecto independientemente de la
calidad del personal o de la disponibilidad de herramientas, lenguajes y
procesos de desarrollo. Si se trata de comprimir la duración o el
presupuesto, el personal que trabaje en el proyecto, no lo hará
eficientemente, no se forzaran si ven que es imposible alcanzar la meta.
Peor aun, cuando los retrasos empiecen, sufrira la moral y el proyecto
probablemente cueste más de lo que hubiera costado de haberse hecho de
forma razonable.

Como se ve la asignación de recursos es complicada e implica a muchas


personas.

2. DETERMINACIÓN DEL PLAZO DE ENTREGA


DE LA APLICACIÓN.
A lo largo de la asignatura utilizamos los términos "Proyecto Informático"
y "Aplicación Objetivo" como sinónimos y complementarios, así,
determinamos los puntos de función de la "Aplicación", N, y decimos que se
trata de un "Proyecto Informático" con N puntos de función.

La diferencia entre estos conceptos, para los informáticos, es que mientras


la aplicación es el objetivo, el proyecto es el medio para alcanzarlo. Los
clientes y usuarios suelen percibirlo de forma distinta, la aplicación es el
producto que les hace falta para poder alcanzar sus objetivos empresariales, y
cuanto antes esté disponible mejor. Mientras que el proyecto lo perciben
como algo "oscuro", que siempre consume más de lo que se dijo en dinero y
tiempo.

De modo que al determinar el plazo de entrega de la aplicación hay dos


variables importantes, que responden a:

75
GESTIÓN DE PROYECTOS INFORMÁTICOS

 ¿Cuánto tiempo y dinero consumirá este proyecto? y

 ¿Cuándo deberíamos tener disponible la aplicación para optimizar el


trabajo de los usuarios?

2.1. IDENTIFICACIÓN DE LOS LÍMITES TEMPORALES DEL


PROYECTO VERSUS ASIGNACIÓN DE RECURSOS

Una vez estimado el esfuerzo necesario para realizar una aplicación


(Puntos de Función - Tareas) y antes de obtener una planificación definitiva
con la asignación de recursos, debemos conocer, a grandes rasgos las
limitaciones temporales del proyecto.

Evidentemente si un proyecto requiere el esfuerzo de 165 meses/hombre


si decidimos que una persona realice el proyecto, dentro de 15 años
entregaremos la aplicación al usuario, si la empresa existe y el usuario o su
departamento siguen teniendo interés en esta aplicación.
Hay varias razones que hacen absurdo el planteamiento anterior:

1) Los negocios actuales son muy agresivos lo que implica que las
organizaciones que les dan soporte han de ser ágiles y flexibles.
Posiblemente ningún sistema pueda sobrevivir 10 años en una
empresa.

2) Una aplicación importante para la empresa deberá estar disponible lo


antes posible dados los costes de oportunidad que tendrá.

3) La tecnología evoluciona a tal velocidad que el lenguaje o entorno de


trabajo de la aplicación quedarán obsoletos mucho antes de estar
disponible la aplicación. Imagine una aplicación que comenzó a
desarrollarse hace 15 años, con las últimas tecnologías.

4) El desarrollo de aplicaciones informáticas, de cierta envergadura,


requiere de especialistas en diversas áreas como bases de datos,
telecomunicaciones, diseño de interfaces, obtención de

76
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

especificaciones, programación de sistemas, etc.

Éstas son razones suficientes para pensar que es imposible el que una sola
persona lleve a cabo el desarrollo de una aplicación como ésta.

Lo opuesto es pensar en desarrollar la aplicación en un sólo día con


(165*20 =) 3.300 personas en el desarrollo. Esto no es viable técnicamente
dado que unas tareas no se pueden iniciar antes de la finalización de otras.
Alguien puede pensar que asignando muchas personas a una tarea, esta se
podrá finalizar en digamos una hora, cosa que como veremos también resulta
técnicamente imposible 3.

Así pues los proyectos informáticos deberán ajustar su duración:

 por una parte adaptándose a los aspectos del negocio que nos indican
unas fechas a partir de las cuales ya no resulta interesante el disponer
de la aplicación o tener unos costes de oportunidad elevados,

 por otra parte a los aspectos técnicos del desarrollo que indican la
cantidad máxima de recursos que se pueden asignar a cada tarea,

 además los aspectos de gestión hacen aconsejable tener un equipo de


desarrollo lo más pequeño posible, con el fin de evitar problemas de
comunicación y coordinación.

Evaluando estos aspectos, y otros que veremos en la asignatura, se deberá


llegar a un consenso sobre la duración total del proyecto y el consumo de
recursos a realizar.

3
Frederick P. Brooks comenta en su libro The mythical man-month: "Por lo tanto el meses-
hombre como una unidad para medir el tamaño de un trabajo es un mito peligroso y engañoso.
Implica que los meses y los hombres son intercambiables.".

77
GESTIÓN DE PROYECTOS INFORMÁTICOS

2.2. DETERMINACIÓN DEL PLAZO.

Para determinar el plazo de entrega se puede seguir tres caminos, uno se


basa exclusivamente en la negociación y dos de ellos siguen un método
técnico. Empezaremos por el menos recomendable y más difundido.

LA NEGOCIACIÓN.

La negociación4 es una de las técnicas más extendidas para fijar los plazos
de entrega de aplicaciones informáticas. Esta técnica puede ser muy peligrosa
si se producen ciertas circunstancias como:

 Se comienza a negociar sin tener claras las especificaciones del cliente.

 El usuario con ligeras nociones de las técnicas de desarrollo actuales,


fundamentalmente basadas en presentaciones comerciales de
distribuidores de herramientas fuerza a que el plazo negociado sea lo
menor posible.

 El usuario tiene la necesidad de disponer de la aplicación lo antes


posible.

 El director del CPD o jefe de proyecto tiene que negociar con un


usuario de mayor nivel jerárquico.

 El trabajo usual de muchos usuarios es el de contratar servicios a


empresas externas y saben que siempre hay un margen que se puede
disminuir.

Con todas estas circunstancias es normal que tras la negociación de los


plazos de entrega de la hipotética nueva aplicación se tengan:

 Fuertes niveles de compromiso personal del jefe del proyecto,

4
Ver Análisis Estructurado Moderno, E. Yourdon; pág. 536. o Assesment and Control of
Software Risks, C. Jones; pág. 118.

78
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

 Escasa participación en la fijación de plazos de los que van a


desarrollar la aplicación.

Este marco es el ideal para el fracaso de un proyecto ya que el


desconocimiento de las necesidades del usuario suele hacer que se
subestimen, por lo general. Además el compromiso unilateral del jefe, en
estas condiciones, difícilmente será respaldado por sus subordinados.

En cualquier caso la negociación es habitual en estas circunstancias, por lo


que el planteamiento que se propone puede ser más aconsejable. Además, el
espíritu comercial es imprescindible en las empresas.

SELECCIÓN DE UNA ALTERNATIVA

El segundo método es el seguido a lo largo de esta asignatura. Puede


verse como una negociación en la que el director del proyecto ha preparado
una serie de alternativas y se las ofrece al cliente. Se parte de la obtención de
una especificación de lo que desea el cliente y sobre ella se diseñan diferentes
alternativas. Aplicando el historial productivo de la empresa, se estima el
esfuerzo necesario para cada alternativa.

En una reunión posterior los posibles implicados en el proyecto (analistas,


programadores, etc.) llegan a consensos sobre las planificaciones y recursos
necesarios. Si la empresa desea un presupuesto, éste se calcula basándose en
las planificaciones realizadas. En cualquier caso se pueden obtener diferentes
planificaciones, para un mismo sistema con distintos diseños e incluso un
mismo diseño, modificando los recursos asignados. Los presupuestos y
planificaciones se presentan al usuario que selecciona el más apropiado al
negocio.

Este sistema tiene muchas probabilidades de alcanzar el éxito ya que,


primero: se basa en datos históricos de productividad, y segundo: el
compromiso de los desarrolladores es alto, ya que formaban parte del grupo
que realizó la estimación.

79
GESTIÓN DE PROYECTOS INFORMÁTICOS

MÉTODO EMPÍRICO DE PUTNAM Y NORDEN.

El tercer método que hemos mencionado se basa en estudios empíricos


que inicialmente realizó Norden (1963), basados en proyectos de IBM. Se
basa en el estudio de la duración de los proyectos y la cantidad de personas
asignadas cada mes. Éstos le llevaron a identificar la curva de desarrollo, que
se muestra en la figura 1. Putnam estudió y refinó esta curva a partir de datos
sobre grandes proyectos de la armada americana. En pequeños proyectos
esta curva queda distorsionada.

La fórmula a que obedece esta curva es:

Esfuerzo_en_hombres(t) = 2K a t e-at²

donde

 Esfuerzo_en_hombres es la cantidad de meses hombre que se aplican


en un momento determinado,

 a es el factor de aceleración, indica el incremento inicial de la curva, y

 K es el esfuerzo total del proyecto, en meses/hombre (área de la


curva).

 t es un instante de tiempo a lo largo de la realización del proyecto.

80
15
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO Esfuerzo
Asignado
10

0
0 2 4 6 8 10 12 14 16 18 20 22 24
Meses de Desarrollo

figura 8. Curva para un proyecto de 165 meses hombre

Ésta curva contiene la siguiente información:

 Al principio del proyecto aunque se asigne muchas personas, estas no


pueden ser utilizadas de forma eficiente.

 Al ir apareciendo tareas técnicas de programación, diseño e


implementación de bases de datos, preparación de pantallas, informes,
etc. se puede utilizar más personal.

 Una vez realizado el grueso del trabajo van quedando menos tareas y
la cantidad de personas que se pueden asignar son menos.

La curva la podemos aplicar para estimar la duración de un proyecto con


K esfuerzo en hombres/mes, teniendo unas perdidas mínimas. Dicho de otra
manera, si aplicamos a un proyecto una cantidad fija de personas desde el
inicio del proyecto, nos encontraremos en la situación descrita en la figura 2.

81
GESTIÓN DE PROYECTOS INFORMÁTICOS

figura 9
o o
nd ad tra
No cua lic de Ex ara
zo o zo le Ap tar zo io p r la
er tad r b zo o er r
fu as e
fu ni lta er ad fu sa sa
s
E alg Es ispo a fa fu si Es ece pen ión
M D aci Es ema N om nac cta
h d C ig rre
16 as co
in
14
12
10
8
Personas

6
4
2
0
0 2 4 6 8 10 12 14 16 18 20 22 24
M e s es d e D e sa rro llo

Otros usos de estas curvas se dan cuando podemos fijar la cantidad


máxima de personas de las que podremos disponer en cualquier momento del
desarrollo. En este caso nos podemos mover en una familia de curvas, como
las de la figura 3 y seleccionar la que se adapte mejor a nuestra situación.

80
60
40
PERSONAS

20
0
0 12 24 36 48 60 72 84
MESES DE DESARROLLO

figura 10

Algo similar a esto postulo Boehm, definiendo la región imposible en


cuanto a la duración de un proyecto, en concreto, basándose en los recursos
necesarios para realizar el proyecto, indica que desde la especificación a la
entrega de un producto informático, no puede pasar menos de:

82
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

T  2,15  3 PersonasMes

Y el 99% de los proyectos cumplen esto.

3. TIPOS DE RECURSOS USUALES.


Por recurso entendemos el trabajo de las personas o cosas necesarias para
realizar alguna tarea. Podemos clasificarlos en:

 Trabajo, puede realizarse por personas de la organización o externas;


podemos descomponerlo en:
 Equipo de desarrollo: Director del proyecto, Analistas,
Diseñadores y Programadores.
 Soporte al desarrollo: Especialistas en Base de datos, en redes
locales y comunicaciones, en interfaces, en formación, así
como Operadores y Administrativos5.
 Clientes y Usuarios: Personal de la alta dirección (es
recomendable que el liderazgo del proyecto recaiga en una
persona de este tipo), Directores y personal de los
departamentos afectados.

 Lugar de trabajo, espacio en donde los desarrolladores realizarán sus


tareas, podemos clasificarlo en:
 Salas de reuniones, en donde suuarios, clientes y
desarrolladores realizarán tareas conjuntas.
 Entorno de desarrollo, donde los informáticos realizan trabajos
individualmente como documentar o programar. Hay que
hacer notar que muchas de las compañías y empleados más
productivos disponen de oficinas silenciosas. Con teléfonos
que se pueden silenciar o desviar. Están aislados de las
interrupciones que no son propias del asunto.
 Zonas para recogida de datos, lugares de trabajo de los

5
Ver falta de especialización en el libro de C. Jones "Assesment and Control of Software
Risks" pág. 409-18

83
GESTIÓN DE PROYECTOS INFORMÁTICOS

usuarios y zonas de archivos tanto actuales como futuros.

 Equipamiento, muebles necesarios para poder realizar el trabajo.


podemos clasificarlo en:
 Mobiliario de oficina, mesas, sillas, lámparas, teléfono, fax,
etc.
 Material para presentaciones, proyectores, pantallas, mesas
apropiadas, etc.
 Ordenadores, Infraestructura de red, estaciones de trabajo,
Hardware específico del sistema de desarrollo, etc.

 Material básico para el desarrollo, Software y Manuales:


 S.O., Lenguajes de desarrollo, Herramientas de desarrollo
(CASE).
 Manuales del software: iniciación, manual de usuario, librerías,
etc..
 Libros con referencia a técnicas de desarrollo: ejemplo
"Análisis Estructurado Moderno de Edward Yourdon", etc.

 Material fungible, es el material que se consume durante el desarrollo.


Son ejemplos:
 el material de escritorio: bolígrafos, clips, grapas, barras de
pegamento, líquido corrector, etc..
 el material necesario para los equipos: tinta o toner de
impresora, papel de impresora, transparencias, disquetes,
cintas de back-up, etc.

El haber descrito con tanto detalle algunos de los materiales se debe a que
en la práctica se pierde mucho tiempo, de personal de desarrollo, por no
estar disponibles cosas que aparentemente tienen poca importancia.

4. DURACIÓN DE LAS TAREAS.


Por lo visto hasta ahora, las tareas ya tienen asignado un esfuerzo, ahora
hay que decidir cuántos recursos se le asignan a cada tarea, de modo que
obtengamos la duración en tiempo de cada una de ellas.

84
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

4.1. ESFUERZO Y DURACIÓN DE LAS TAREAS.

Normalmente se suele confundir el esfuerzo necesario para desarrollar una


tarea (meses/hombre) con el tiempo necesario para llevar a cabo la misma.

Una tarea que tenga asignado un esfuerzo de 10 días, puede llevarse a


cabo en el plazo de 5 semanas, aplicando un esfuerzo de 2 días a la semana.
También nos podemos encontrar con el caso contrario en que una tarea que
necesita el esfuerzo de 10 días se lleve a cabo en una semana, empleando a
dos personas a tiempo completo en su ejecución.

El esfuerzo aplicado puede verse afectado por interferencias externas. Por


ejemplo, teniendo que realizarse un esfuerzo de una semana - hombre, y
asignando una persona a esta tarea durante una semana, puede no finalizar a
causa de las interferencias. Thomsett dice que hay muchas razones para esto
y en concreto menciona algunas como:

 Es necesario repetir trabajos o corregir defectos de tareas previas,


que se suponían terminadas, para poder realizar la tarea actual.

 Hay que tener en cuenta las vacaciones, fiestas, fiestas locales,


puentes, etc. que puedan afectar al proyecto tanto en los lugares de
trabajo como en las zonas de clientes o usuario.

 Otros equipos de la empresa pueden realizar consultas al personal del


proyecto actual sobre temas ajenos a éste.

 La falta de administrativos puede implicar que los programadores


tengan que realizar todos sus papeleos que deberían haber sido
delegados.

 Falta de formación y adiestramiento adecuada en el personal del


proyecto.

 Falta de reuniones del equipo.

85
GESTIÓN DE PROYECTOS INFORMÁTICOS

 Interrupciones de todo tipo como llamadas telefónicas etc..

 Tiempo de espera en reuniones.

 Tiempo que tarda el personal en cambiar de tarea, no se puede


esperar que sea instantáneo.

Estos factores se pueden llevar entre el 30% y el 50% del esfuerzo


realizado. No sería extraño que para una reunión en otra ciudad, de dos días
de duración, a una persona dedique cuatro días de esfuerzo si no tiene
soporte administrativo y tiene que gestionarse los billetes, las reservas de
hotel, etc. Otro ejemplo lo dan los retrasos a la hora de comenzar una
reunión por falta de personas.

Aunque parezca paradójico, por culpa de estos factores, las personas con
mayor nivel de experiencia y responsabilidad en la empresa son los mas
afectados. Pues:

 deben enseñar y adiestrar al personal del proyecto en temas no


previstos;

 son consultados por otros proyectos, y

 se les suele pedir que asistan a reuniones, presentaciones, etc. que en


principio no tienen relación con el proyecto actual.

4.2. ASIGNACIÓN DE PERSONAS A TAREAS.

La experiencia indica que es mejor disponer de un equipo pequeño de


buenos profesionales que uno mayor de personas no tan capacitadas. De
hecho la gente correcta aun con herramientas, lenguajes y procesos
insuficientes, pueden tener éxito. Lo contrario parece imposible. Por otra
parte si confiamos todo a unas pocas personas nos podemos encontrar con
problemas: ¿Qué ocurre si se van? De modo que tendremos equilibrar al
personal.

86
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

A la hora de asignar personas a cada tarea nos encontramos con un grupo


de tareas y otro de personas. Al comienzo del tema ya digimos que las
personas no pueden verse como un recurso más. Los enfoques actuales
relativos a esta asignación pasan por evaluar de cada empleado y tarea los
siguientes aspectos:

 El conativo o KAS (Knowledge, Abilities, Skills), se puede ver como


la capacidad técnica. Es decir:
 Los conocimientos para realizar la tarea
 La capacidad de realizarla, y
 La experiencia sobre la materia.
 El cognitivo o MAC (Motivation, Attachment, Confidence), se puede
ver como la voluntad de realizar la tarea. Es decir:
 La motivación de la persona,
 El compromiso que asumirá, y
 La seguridad que tiene en si para realizarla

Da la impresión, de que basándose en esto, Fergus O'Connell6 compara a


un proyecto con un puzzle e indica que se ha de asignar las piezas (tareas) a
las personas. Dice que eres una persona con suerte si encuentras la persona
apropiada a cada pieza. Por persona hace referencia al conjunto de
personalidad, habilidades, experiencia, motivación, metas personales, puntos
fuertes y puntos débiles que nos hacen como somos. Además asocia los
aspectos conativos al que la persona pueda realizar la tarea desde el punto de
vista técnico. Los aspectos cognitivos los asocia a si la persona quiere
realizar la tarea.

Dado que tenemos una lista de tareas y una lista de personas, se trata de
realizar la mejor asignación posible. O'Connell propone la siguientes
posibilidades para cada par tarea - persona:

 Puede realizar el trabajo y quiere realizarlo.

6
En su libro "How to Run Successful Projects"

87
GESTIÓN DE PROYECTOS INFORMÁTICOS

 Esto es lo ideal.

 Puede realizar el trabajo y accede a realizarlo.

 Esta bien para el proyecto, habría que motivar a ésta persona y


buscar, a largo plazo, trabajos que se le ajusten.

 Puede realizar el trabajo pero no esta dispuesto a realizarlo.

 Tenemos problemas, hay que ver cuál es el problema y


resolverlo o nos encontraremos realmente en la última
categoría.

 Puede ser formado para realizar el trabajo.

Si estás dispuesto a:

 gastar dinero y tiempo en formación,


 modificar la programación del proyecto con la formación,
 soportar una sobrecarga en la dirección, y
 a afrontar el riesgo de que no funcione bien,

Entonces todo está bien. En el futuro es posible que tengas una


persona en tus proyectos de la primera categoría mencionada.

 No puede realizar el trabajo.

 Tienes problemas serios, tendrás que identificar otras tareas


para esta persona.

4.3. TIPO Y DURACIÓN DE TAREAS EN FUNCIÓN DE LA


CANTIDAD DE PERSONAS ASIGNADAS.

En principio el asignar muchas personas a una tarea no quiere decir


que la tarea forzosamente dure menos tiempo. Es decir, la gente y la

88
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

duración no son intercambiables. Frederick P. Brooks en su libro “The


mythical man-month” ofrece cuatro tipos posibles de tareas. En cada una de
ellas la relación existente entre meses y hombres es diferente. Las posibles
situaciones son:

9 1) Las tareas se pueden repartir de


8
7
forma perfecta, sin necesidad de
6 comunicación entre las
5 personas. Cuando más personas
4
uración

se asignen a una tarea, ésta


D

3
2 tendrá una duración
1
0
proporcionalmente menor.
0 1 2 3 4 5 6 7 8
Personas
2) La tarea no se puede partir
(Para que nazca un niño se
9
requieren nueve meses, no
8
7 importa cuantas mujeres se
6 asignen). Éste tipo de tareas
5
4
suelen darse cuando tenemos
uración

limitaciones en algún recurso. Así


D

3
2 por ejemplo, si para realizar las
1
0
pruebas me hace falta un
0 1 2 3 4 5 6 7 8 dispositivo Hw especial, del que
Personas tan solo se dispone de una
unidad, no tendrá sentido que
asigne muchas personas a esta
tarea.
9
8
3) La tarea se puede partir, pero se
7 requiere comunicación entre las
6 personas. En principio es la
5
4 situación más habitual dado que
uración
D

3 de contener subtareas
2
independientes, esto se hubiera
1
0 tenido en cuenta en la
0 1 2 3 4 5 6 7 8 descomposición en tareas y
Personas tendríamos varias tareas bien

89
GESTIÓN DE PROYECTOS INFORMÁTICOS

definidas en el proyecto. Por otra parte es habitual tener tareas


grandes que son criticas requiriendo mucho esfuerzo y que
necesitamos que tengan un
9 duración limitada.
8
7
6 4) La tarea se puede partir pero las
5 interrelaciones son tan
4
uración

complejas que cuesta más


D

3
2 tiempo realizar la tarea con
1 muchas personas. Son las tareas
0
0 1 2 3 4 5 6 7 8
en que habitualmente alguien
Personas dice: “mira prefiero hacerlo
solo, por que entre varios no
terminaremos nunca”.

5. Asignación consistente de las tareas


Uno de los problemas clásicos que se producen al asignar las tareas es que
estas no son vistas de la misma forma por el director y los subordinados. Es
muy usual que si preguntamos a un director que es lo que espera de un
subordinado y lo escribimos en un papel y hacemos lo propio con el
subordinado, obtengamos dos pedazos de papel, cuyo único parecido sea el
hecho de que son de papel.
Otro problema clásico es que aun cuando hacemos la asignación de tareas
de forma cautelosa, muchos trabajadores sienten que alguna de las tareas que
se han asignado a otro, le correspondía a el, por lo que la suele reclamar y
puede llegar a suponer un conflicto que se encone, según se va desarrollando
el proyecto.
Una forma de evitar ambos problemas consiste en dar a conocer el plan,
de forma más o menos completa a todos los trabajadores, luego se elabora
una lista de objetivos y tareas junto a cada trabajador. De este modo se evita
el primer problema, además de sernos útil para verificar que el trabajador
este conforme con la asignación. Esta lista no debería ser superior a una
pagina, legible en menos de un minuto (El ejecutivo al minuto, Blanchard).
Una vez terminada la asignación de objetivos y tareas, recibiremos una serie

90
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

de solicitudes, quejas y aclaraciones, sobre: las tareas que una persona cree
que debería tener asignadas, dado que están muy relacionadas con sus
objetivos y que han sido asignadas a otro; tareas que alguien piensa que no
han sido asignadas; e incluso asignaciones que comparten varios
participantes del proyecto, pero que parecen incompatibles por la
personalidad de los estos.
Pasados un par de días de las quejas, se hace una reunión con todos los
participantes, se habla sobre los problemas surgidos. Sé reescriben las
asignaciones y se entregan de nuevo a los participantes. Este proceso puede
requerir un par de iteraciones y las reuniones puede que sean tensas. Pero
habrá valido la pena, ya que tendremos una descripción clara y compartida de
los objetivos, responsabilidades y tareas asignadas a cada miembro del
equipo. Además las tareas no se superpondrán y completaran todas las
necesidades del proyecto. (Managing a Programming Project, Metzger).

6.CONSIDERACIONES FINALES.
Como se ve habrá que buscar la situación en que se optimicen cualquiera
o todas estas condiciones:

 Coste Mínimo de desarrollo

 En tiempo (Especialistas ya formados en cada área de trabajo.


Tantos como se pueda, siempre y cuando no se tengan que
relacionar de forma compleja por razón de las tareas
asignadas).

 En dinero (Utilizar el personal necesario para que se lleven a


cabo las tareas de modo que se deban de comunicar lo mínimo
posible y que ya conozcan las áreas que se les asignan).

 Coste mínimo a largo plazo (pensar en el mantenimiento y en otros


proyectos)

 Hacer que el personal menos experimentado trabaje en el

91
GESTIÓN DE PROYECTOS INFORMÁTICOS

desarrollo, dando formación en caso necesario.

 Hacer que el personal se sienta promocionado. Detectar los


objetivos de cada empleado y hacer que cada nuevo proyecto
sea un paso en la consecución de su objetivo.

Conviene recordar, al asignar personas a tareas, que la productividad de


los programadores es muy variable, en un estudio se dio el mismo programa
a desarrollar a varios programadores obteniéndose diferencias de 1 a 26 en
los niveles de productividad. Esto quiere decir que en las tareas críticas
convendrá poner al personal con mayor experiencia y reputación, ya que se
espera que estos sean los más productivos.

6. BIBLIOGRAFÍA
1. Blanchard, K., Johnson, S. “El ejecutivo al minuto”. Grijalbo Mandadori,
S.A. 1983.
2. Brooks, Frederick P. ”The mythical man-month”
3. DeMarco, Tom. Controlling Software Projects. Prentice Hall, 1982.
(Biblioteca UPV)
4. Fergus O'Connell. "How to run successful projects". Prentice Hall, 1994.
(Biblioteca UPV)
5. Metzger, P. Boddie, J. “Managing a programming project: people and
processes” 3 ed. Prentice Hall, 1996.
6. Thomsett, R. “Third Wave Project Management”. Prentice Hall, 1993.
(Biblioteca UPV)
7. Yourdon, Edward. Análisis Estructurado Moderno. Prentice Hall, 1993.
(Biblioteca UPV)

92
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

5. PROGRAMACIÓN TEMPORAL
DE PROYECTOS

1. INTRODUCCIÓN............................................................................................... 93

2. HERRAMIENTAS BÁSICAS USADAS EN LA PLANIFICACIÓN Y


SEGUIMIENTO. .......................................................................................................... 94

3. APLICACIÓN DE LA TÉCNICA CPM. ........................................................... 95


3.1. ETAPA 1. ...................................................................................................... 95
3.2. ETAPA 2. ...................................................................................................... 96
3.3. ETAPA 3. ...................................................................................................... 96
3.4. ETAPA 4. CÁLCULO DEL CAMINO CRÍTICO ....................................................... 99
3.4.1. CALCULAREMOS LAS FECHAS. ......................................................... 99
2.4.1. OBTENCIÓN DEL CAMINO CRÍTICO. .............................................. 101
4. EJEMPLO DE PROGRAMACIÓN DE PROYECTOS Y OBTENCIÓN DE
CALENDARIOS......................................................................................................... 101

5. DIFERENCIA FUNDAMENTAL ENTRE EL CPM Y EL PERT.................. 103

6. USO DE APLICACIONES PARA LA PLANIFICACIÓN Y CONTROL DE


PROYECTOS............................................................................................................. 104

7. MODIFICACIÓN DE LA DURACIÓN DEL PROYECTO. .......................... 104

8. BIBLIOGRAFÍA............................................................................................... 107

1. INTRODUCCIÓN.
En este tema vamos a tratar el tema de la creación de calendarios para los
proyectos. Partiendo de las tareas, recursos asignados a cada una y las
precedencias entre las tareas, obtendremos una programación temporal.

93
GESTIÓN DE PROYECTOS INFORMÁTICOS

Dado que ya sabemos modificar la duración de las tareas, asignando más


recursos (capítulo 4), veremos cómo modificar la duración global del
proyecto e incluso cambiar el camino crítico, pudiendo ofrecer, de este
modo, diferentes programaciones alternativas.

2. HERRAMIENTAS BÁSICAS USADAS EN LA


PLANIFICACIÓN Y SEGUIMIENTO.
Aunque desde la antigüedad se han realizado proyectos de gran
envergadura como por ejemplo la construcción de edificios públicos, guerras,
viajes, etc., no es hasta principios de este siglo cuando aparece el conocido
diagrama de Gantt en el que se refleja de forma esquemática las tareas, su
duración y las fechas en que se deberán realizar. Trabajando sobre este
diagrama el director de proyecto realizaba planificaciones y seguimiento de
un proyecto. Ver la figura 1.
TAREAS
Especificar Necesidades

Diseño Programas

Diseño Base de Datos

Realización Esquema

Codificación Programas

Pruebas

0 2 4 6 8 10 12 14 16
SEMANAS

figura 11
Dada la evolución tecnológica los seres humanos cada vez abordamos
proyectos más complejos, pero por otra parte creamos técnicas más
evolucionadas, completas y automáticas para gestionar estos proyectos. La
construcción del misil Polaris, así como la solución de los problemas en la
gestión de la producción de Dunlop llevaron al desarrollo de las técnicas

94
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

conocidas como PERT (Técnica para la Evaluación y Revisión de


Programas) y CPM (Método del Camino Crítico) que aportan a al
programación de proyectos técnicas matemáticas.

Estas técnicas surgieron de la necesidad de obtener algoritmos


automatizables que ayudasen a los gestores de proyectos complejos en la
construcción de calendarios (programas). En el siguiente punto veremos
mediante un ejemplo como se aplica en el CPM.

3. APLICACIÓN DE LA TÉCNICA CPM.


El CPM se realiza sobre un proyecto en cuatro etapas, a continuación se
describe cada una de ellas.

3.1. ETAPA 1.

Identificar tareas. Se utilizará


Especificar
Necesidades
las técnicas vistas en el capítulo
3 para la identificación de tareas.
Diseño Base
Diseño de Datos Como ejemplo podemos usar el
Aplicación mostrado en la figura 2.
Diseño
Programas
Desarrollo Si queremos realizar el
Contabilidad Realización proceso de forma manual,
esquemas
Codificación rellenaremos una ficha por cada
Codificación
Programas
Actividad: Diseño Programas
Pruebas
Recursos: 1 Programador
figura 12 Duración: 3 semanas
actividad identificada. El formato de la
ficha será el que se muestra en la figura 3.
figura 13

95
GESTIÓN DE PROYECTOS INFORMÁTICOS

3.2. ETAPA 2.

Añadir recursos y tiempos. A cada actividad se le asignarán recursos


como se vio en el tema 4 (personas, material, equipos, etc.) y tiempo
estimado para su realización, completando la ficha.

3.3. ETAPA 3.

Ordenar las tareas. En esta etapa se tienen que organizar las tareas en base
al orden técnico de ejecución. Así sabemos que hay que hacer las
especificaciones antes de diseñar el programa. Nos podemos plantear las
siguientes preguntas para ordenar las tareas:

 ¿Qué se puede hacer ahora?


 ¿Qué debe haberse hecho antes de esto?
 ¿Qué podría hacerse a la vez?
 ¿Qué debe seguir a lo que hacemos ahora?

Si se trata de calcular el Camino Crítico de forma manual será interesante


el pinchar todas las tareas en un tablero de corcho, señalando mediante
cuerdas la ordenación de las tareas, ver figura 4. Esta representación es
conocida como red de precedencia, aunque su apariencia es diferente al
gráfico PERT en algunos programas informáticos se describe erróneamente
con este nombre.

96
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

figura 14
Si tenemos un diagrama complejo, y queremos realizar los cálculos de
forma manual se puede utilizar el método que se describe a continuación.

Este diagrama se compone de nodos y arcos, similares a las pegatinas


comentadas anteriormente. Los nodos representan a las tareas y la
información necesaria para calcular sus fechas de realización. Los arcos
indican las precedencias entre tareas.

Vamos a representar cada nodo (tarea) como se ve en la figura 5.

Etiqueta actividad Duración


Inicio temprano DESCRIPCIÓN DE LA ACTIVIDAD Final temprano
Inicio tardío Final tardío
Máximo tiempo disponible Holgura

figura 15
Donde:

 DESCRIPCIÓN DE LA ACTIVIDAD es el nombre que le hemos dado

97
GESTIÓN DE PROYECTOS INFORMÁTICOS

a la actividad. Por ejemplo: Codificación Programa A

 Etiqueta actividad es un número arbitrario y que identifica


unívocamente a cada actividad.

 Duración es el tiempo que calculamos que se tardará en completar la


tarea, teniendo en cuenta el esfuerzo y los recursos asignados a la
tarea. Por ejemplo una tarea que estimamos requerirá seis días-hombre
de esfuerzo, si se realiza entre tres personas podría tener una duración
de dos días (ver capítulo 4 punto 4.3).

 Inicio temprano es la fecha en que se podrá comenzar la tarea si no se


retrasa ninguna otra. Más adelante veremos como calcularla.

 Final temprano es, en el caso de iniciarse al tarea en el inicio


temprano, lo antes que puede finalizar, respetando su duración.

 Inicio tardío es la fecha más retrasada en la que puede comenzar la


tarea para que se pueda completar el proyecto en la fecha marcada
como final del proyecto.

 Final tardío es la fecha más retrasada en la que puede terminar la


tarea para que se pueda completar el proyecto en la fecha marcada
como final del proyecto.

 Máximo tiempo disponible el tiempo máximo que puede durar una


tarea en caso de comenzar en su Inicio temprano y concluir en su
Final tardío.

 Holgura es la diferencia entre el Máximo tiempo disponible y su


Duración

98
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

3.4. ETAPA 4. Cálculo del camino crítico

3.4.1. calcularemos las fechas.

Una vez tenemos todas las tareas con sus respectivas duraciones y las
precedencias pasamos a dibujar una red en la que aparezca para cada tarea
una caja similar a la vista en el punto anterior con casi todos los campos
vacíos. Entre ellas aparecerán los arcos indicando precedencias. tendremos
algo similar a la figura 6.

Ahora calculamos las fechas tempranas. Para esto seguimos los siguientes
pasos:

1) En aquellas tareas que no tienen ningún predecesor se le asigna a


Inicio temprano el valor cero.

2) Si la tarea tiene predecesoras y todas estas tienen calculado su Final


temprano se toma como Inicio temprano el máximo de todos ellos.

3) El Final temprano de cada tarea se calcula como el Inicio temprano


más la Duración.
Repetiremos estos pasos hasta que todas las tareas tengan sus
fechas tempranas.
Para calcular las fechas tardías procederemos con los pasos que se
describen a continuación.

99
GESTIÓN DE PROYECTOS INFORMÁTICOS

figura 16
4) Se obtiene la fecha de finalización de proyecto más tardía. Esta puede
venir dada por algún tipo de razones externas o puede que se nos pida
que el proyecto termine lo antes posible, en este caso la fecha de
finalización más tardía será el máximo de los "Final temprano" de
todas las tareas.

5) A aquellas tareas que no sean predecesoras de ninguna otra se les


asigna como Final tardío la fecha de finalización mas tardía del punto
4.

6) El Inicio tardío se calcula restando al Final tardío la Duración.

7) En aquellas tareas que son predecesoras de otras se calcula el Final


tardío como el mínimo de los Inicio tardío de las tareas de que es
predecesora.

Los otros dos campos de cada tarea: Máximo tiempo disponible y


Holgura se calculan mediante las siguientes fórmulas:

100
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

Máximo tiempo disponible = Final tardío - Inicio temprano

Holgura = Máximo tiempo disponible - Duración

2.4.1. Obtención del Camino Crítico.

Llamamos camino crítico de una planificación al conjunto de tareas que


tienen Holgura cero. Siempre que se solicita que el proyecto tenga la
duración mínima tendremos un camino crítico.

Se le llama camino crítico porque suele ser un camino que parte de una
tarea que no tiene predecesoras y atraviesa el grafo por tareas con holgura
cero hasta terminar en una tarea que no es predecesora de ninguna otra.
Puede darse el caso de que con el "camino crítico" se puedan construir varias
secuencias, partiendo de tareas sin predecesoras y se alcancen tareas sin
sucesoras.

A las tareas del camino crítico se les llama tareas criticas y esto se debe a
que un retraso en cualquiera de ellas lleva a un retraso del final del proyecto.

4. Ejemplo de programación de proyectos y obtención


de calendarios.
Comenzaremos por crear un calendario, que ilustraremos con el siguiente
problema:

Se ha evaluado el desarrollo de una aplicación, obteniéndose que el


esfuerzo necesario para realizarla es de 25 meses/hombre. Tras el estudio de
las tareas a realizar y los recursos disponibles se han determinado las tareas,
recursos y precedencias, que se muestran en la tabla siguiente.

Se ha de tener en cuenta que la empresa puede asignar tantos Analistas y


Programadores al proyecto, como sea necesario, respetando los datos de la
tabla.

101
GESTIÓN DE PROYECTOS INFORMÁTICOS

Se desea conocer el tiempo mínimo, necesario, para el desarrollo del


proyecto así como el Camino Crítico.

También se desea disponer de los diagramas de precedencia y Gantt.

Tarea Descripción Esfuerzo Tipo Recursos Sigu


Brooks e a:
A Análisis de Requerimientos 3 meses 1 2 Analistas -
B Diseño de la Base de Datos 1 mes 2 1 Analista A
C Diseño de los Procesos 4 meses 1 2 Analistas A
D Construcción del Prototipo 1 mes 2 1 Programador C, E
E Desarrollo del Esquema 0,5 meses 1 1 Analista B
F Codificación 8 meses 1 4 Programadores C, E
G Revisión Usuario del 0,5 meses 2 1 Analista D
Prototipo
H Revisión del Código con 2 meses 1 2 Programadores F, G
Mejoras Solicitadas
I Pruebas 2 meses 1 2 Programadores H
J Instalación Sistema 1 mes 1 2 Programadores I
K Mantenimiento Inicial 2 meses 2 1 Programador J

SOLUCIÓN:
Diagrama de precedencias:
B 1 E 0,5 D 1 G 0,5
1,5 Diseño 2,5 2,5 Desarroll 3 3,5 Construc 4,5 4,5 Revisión 5
o
2 B.D 3 3 Esquema 3,5 4 Prototipo 5 5 Prototipo 5,5
A 1,5 1,5 0,5 1 0,5 1,5 0,5 1 0,5
0 Análisis 1,5
0 1,5
1,5 0 C 2 F 2
1,5 Diseño 3,5 3,5 Codifica. 5,5
1,5 Progrm. 3,5 3,5 5,5
2 0 2 0

H 1 I 1 J 0,5 K 2
5,5 Revisión 6,5 6,5 Pruebas 7,5 7,5 Instalaci. 8 8 Manten. 10
5,5 Código 6,5 6,5 7,5 7,5 8 8 Inicial 10
1 0 1 0 0,5 0 2 0
Diagrama de Gantt:

102
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

A 2ª
B 1A
C 2A
D 1P
E 1A
F 4P
G 1A
H 2P
I 2P
J 2P
K 1P
1 2 3 4 5 6 7 8 9 10

La duración mínima es de 10 meses, siendo el camino crítico A-C-F-H-I-


J-K

5. DIFERENCIA FUNDAMENTAL ENTRE EL CPM


Y EL PERT.
Aunque en principio son similares los algoritmos de ambos métodos, la
asignación de duraciones de las tareas en el PERT es algo mas elaborada. En
lugar de realizarse una sola estimación se realizan tres estimaciones:

"tm" tiempo medio que se estima para la actividad,


"to" tiempo optimista, el que resultaría de ir todo muy bien, y el
"tp" el tiempo pesimista, el que resultaría si todo fuese mal en esta tarea.

A la tarea se le asigna como duración el resultado de:

duración = ( to + 4 tm + tp) / 6

Por otra parte el grafo se construye de forma dual a la vista. Los arcos
modelan las actividades o tareas, mientras que los nodos modelan la relación

103
GESTIÓN DE PROYECTOS INFORMÁTICOS

de precedencia de las tareas. Así un nodo indica que los arcos que llegan a él
anteceden a los que salen de él.

6. USO DE APLICACIONES PARA LA


PLANIFICACIÓN Y CONTROL DE PROYECTOS.
Como hemos indicado estos algoritmos se hicieron pensando en el uso de
sistemas de cómputo automático, así que no es de extrañar que existan
muchas aplicaciones que den soporte a éstos. Entre las más conocidas que
funcionan sobre PC están el CA-SuperProject y el MICROSOFT Project.

7. MODIFICACIÓN DE LA DURACIÓNDEL
PROYECTO.
Al realizar la primera planificación del desarrollo de una aplicación
informática nos solemos concentrar en los aspectos más técnicos del
desarrollo. Como es normal, la planificación tendría un calendario diferente
de haber sido otras las personas implicadas. Esto se debe a varios factores
como la experiencia por ejemplo, que llevan a realizar ciertas suposiciones
implícitas o explícitas sobre las necesidades de los usuarios, la productividad
que se obtiene con ciertas herramientas, la cantidad de personas que se
implicarán en el proyecto y los niveles de destreza que estos dispongan sobre
las herramientas, así como su experiencia y conocimientos sobre el tema de la
aplicación a desarrollar.

Por otra parte, los clientes tienen una visión diferente de sus necesidades,
de modo que les resultará más atractivo el pagar más a cambio de disponer
antes de la aplicación. En otros casos puede ocurrir lo contrario, que
hayamos planificado el proyecto con fuertes restricciones en cuanto al
tiempo de entrega, pero que el cliente realmente desearía pagar menos
aunque se prolongara el plazo de entrega.

Un ejemplo que puede ilustrar lo anterior es el desarrollo de una


aplicación que de soporte al alquiler de esquís para una estación de lo s

104
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

Pirineos. Si planificamos su finalización para el mes de Enero, es normal que


el cliente esté dispuesto a pagar más si puede disponer de esta aplicación en
el mes de Noviembre. Por otra parte si nuestra planificación resulta que
termina en el mes de Julio, seguro que al cliente le dará igual disponer de ella
dos o tres meses más tarde, si con ello puede ahorrarse algo de dinero.

Esto se debe a que hay un coste de oportunidad asociado a la disposición


o no del subsistema informático. Así en la temporada de invierno el cliente
puede estar dispuesto a pagar 100.000 ptas. Por cada mes que se anticipe la
entrega de la aplicación, mientras que en la temporada de verano le será
prácticamente indiferente el disponer de esta aplicación un mes antes o
después.

Si queremos actuar sobre la duración del proyecto deberemos


concentrarnos en las tareas del camino crítico tratando de aumentar la
concurrencia entre algunas de ellas o reducir la duración de éstas.

Con el objetivo de reducir la duración del camino crítico podremos


aumentar el paralelismo entre las tareas de éste. Para ello haremos que
algunas tareas que se relacionan mediante una secuencia de fin-inicio pasen a
una secuencia inicio-inicio, aunque sea con cierta demora. Así las tareas C y
F las podríamos relacionar de modo que transcurrido un mes del comienzo
del “Diseño de los Procesos” se comenzasen a codificar aquellos procesos
que se puedan dar por buenos, aunque esto pueda suponer un mayor
esfuerzo como consecuencia de posibles modificaciones a realizar por no
habernos esperado a que estuviera diseñado todo el sistema.

Por otra parte también podemos reducir la duración del camino crítico,
actuando exclusivamente sobre una de sus tareas. A modo de ejemplo
estudiar lo que ocurriría si redujéramos la duración de la tarea A, del ejemplo
anterior, a un mes. Como se ve en este caso cualquier reducción de la tarea
se propaga a todo el proyecto. Por otra parte si redujéramos la duración de
la tarea F, “Codificación”, de dos meses a uno, sólo obtendríamos una
reducción de la duración del proyecto de medio mes, haciendo que además
cambiase el camino crítico.

105
GESTIÓN DE PROYECTOS INFORMÁTICOS

Los factores que más pueden influir en la duración de una tarea y por
tanto del proyecto, si se trata de una tarea del camino crítico, los podemos
clasificar en tres grandes grupos:

 Modificar las técnicas y herramientas en las que se basa la duración de


la tarea o su propia existencia.

 Si existe un software que puede dar soporte a una tarea o


conjunto de tareas que por su precio no ha parecido oportuno
considerarlo, a la vista de los costes de oportunidad del cliente
puede resultar atractivo el utilizarlo, reduciendo así los plazos
del proyecto (tener en cuenta la curva de aprendizaje).

 Otra situación sería la existencia de tareas de formación sobre


un nuevo sistema de gestión de Bases de Datos, del que
realmente no era obligatoria su utilización. Así que podríamos
optar por otro conocido, si el cliente no tiene preferencias,
eliminando las tareas de formación.

 Modificar la productividad y calidad del recurso trabajo asociado a


una tarea. Aunque sea parcial, Sackman en un estudio sobre, la
diferencia de productividad entre los programadores detecta una
oscilación de 1 a 25. Tanto Tom DeMarco, como M. Page-Jones
comentan el artículo y dan su punto de vista, dejando claro que
relaciones de uno a tres son muy usuales dentro de una misma
organización.

 Modificar la cantidad del recurso trabajo asociado a una tarea.


 Podemos planificar el desarrollo suponiendo que los
desarrolladores realizarán horas extra. Esto en principio puede
suponer un coste adicional o no. Page-Jones recomienda hacer
uso de las horas extra sólo en casos muy puntuales y como
consecuencia de una desviación en la programación, durante el
desarrollo. Parece poco razonable pensar en este recurso en la
fase de planificación.

106
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

 Podemos asignar más personas al proyecto, de modo que en


las tareas críticas se puedan incluir más personas. Hay que
tener en cuenta dos cosas que remarca Brooks en su libro “el
mítico hombre-mes”:

 Los diferentes tipos de tareas que hay, en función de la


cantidad de personas que asignemos (capítulo 4).

 El añadir más personal a un proyecto en marcha puede


retrasar la finalización del proyecto. Esto en principio
se debe a que el personal que no se ha involucrado
desde el principio debe ser formado, lo que puede
suponer un coste en tiempo considerable para las
personas más productivas, porque ya saben de que va
el proyecto, teniendo que dejar sus tareas para aclarar
las dudas de los nuevos.

Como ejemplo de lo anterior reducir la duración del proyecto que hemos


visto al comienzo del tema. Se ha de tener en cuenta que podremos disponer
de un Analista y dos programadores más durante la duración del proyecto.
Dado que estos profesionales son contratados externos y con un coste
superior a los ya asignados, sólo se deberán asignar en aquellas situaciones
en las que realmente aporten un beneficio al proyecto.

8. Bibliografía.
1. de Cos Castillo, M. Teoría general del proyecto. Editorial Sintesis.1995.
2. Cotterell, M, Hughes,B. Software project management. ITP (Thomson
Publishing Inc.) 1995.
3. Lock, D. Gestión de proyectos. Paraninfo, 1990.
4. Microsoft Press. Microsoft Project para windows 95 paso a paso.
McGraw-Hill 1995.
5. Page-Jones, M. Practical Projec Management. Dorset House, 1985.
6. DeMarco, Tom, Lister, Peopleware. Dorset House, 1987.

107
GESTIÓN DE PROYECTOS INFORMÁTICOS

108
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

6. EVALUACIÓN ECONÓMICA
DE PROYECTOS

1. INTRODUCCIÓN............................................................................................. 109

2. ANALISIS ECONÓMICO DEL PROYECTO. ............................................... 110

3. FLUJO DE CAJA. ............................................................................................ 111


3.1 EJEMPLO. ...................................................................................................... 112
4. VISIÓN FINANCIERA DEL PROYECTO INFORMÁTICO. V.A.N............ 113

BIBLIOGRAFÍA: REFERENCIAS Y AMPLIACIÓN DE TEMAS. ................. 120

1. INTRODUCCIÓN.
Una vez determinada la programación del proyecto pasaremos a estudiar
las facetas económicas del mismo comenzando por calcular el flujo de caja.
A continuación aplicaremos la visión financiera a este flujo de caja, que
deberá ser contemplada por la empresa antes de tomar la decisión de realizar
el proyecto.

Por otra parte, un tema muy importante en los proyectos informáticos es


el de los riesgos. Es sabido que muchos proyectos de este tipo exceden la
duración estimada y los costes de forma sustanciosa. El estudio de los
riesgos lo realizaremos en temas próximos. El reseñarlo se debe a que
muchas veces puede parecer una trivialidad la aplicación de tasas de interés
próximas al 20% anual, en proyectos de duración inferior al año, si nos
encontramos con unos excesos de costes entre el 50% y el 100%.

En cualquier caso es imprescindible la visión financiera de la gestión del


proyecto, ya que nos hará comprender la situación de la empresa ante los
retrasos.

109
GESTIÓN DE PROYECTOS INFORMÁTICOS

2. ANÁLISIS ECONÓMICO DEL PROYECTO.


Todo proyecto tiene como objetivo la producción de bienes o servicios
para la personas o sociedades que los promueven.

Este tema no es el lugar apropiado para estudiar los beneficios que puede
proporcionar un subsistema informático a una ONG o a la sociedad y menos
para vislumbrar las repercusiones que el tema pueda tener en el futuro.

Tampoco vamos a estudiar los beneficios económicos que puede


proporcionar la instalación de un sistema informático en una empresa. No es
que no sea necesario, sino que el tema se trata en asignaturas como la
implantación de la informática en las organizaciones. El estudio de los
beneficios se puede consultar en el libro de E. Yourdon Análisis
Estructurado Moderno (Apéndice C) o el de W. S. Davis titulado en
castellano Herramientas Case (tema 8).

En cualquier caso y por desgracia, en esta sociedad, todo se puede reducir


a importes monetarios, lo que desde un punto de vista meramente técnico
simplifica la toma de decisiones. Siendo éste uno de los puntos de partida en
del tema.

Nos vamos a centrar en el coste de los proyectos informáticos. Hay que


tener en cuenta que los proyectos informáticos se deben contemplar como
una inversión y no como un gasto (a pesar de que en una empresa los estados
contables hagan aconsejable otras alternativas). La idea asociada al gasto
conlleva el pago por algo que se necesita en un instante determinado,
mientras que la inversión supone que se realizan una serie de pagos para
obtener más dinero en el futuro.

Así, podemos clasificar los proyectos informáticos en dos grandes grupos:

 Los proyectos que realiza una empresa de desarrollo de software para


un cliente y por los que se cobra.

110
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

 Los proyectos que nacen en el seno de una empresa y que se realizan


con sus propios recursos.

La diferencia fundamental radica en que aun cuando ambos proyectos


deben demostrar al que paga que son rentables, en el primer caso el director
del proyecto, una vez aprobado el presupuesto, se verá ajustado a éste
(cobro/s), mientras que en el segundo caso el director del proyecto puede
detectar nuevos beneficios para la empresa y justificar una modificación del
proyecto.

El estudio de los costes lo vamos a plantear en dos fases, en la primera


calcularemos el flujo de caja (o de efectivo) de un proyecto y haremos
algunas consideraciones sobre estos flujos. Más adelante pasaremos a hacer
un estudio de los valores actualizados de los flujos de caja, es decir a aplicar
las tasas de interés que hacen que el valor del dinero no sea independiente del
instante en el que se gaste o reciba.

3. FLUJO DE CAJA.
Definimos el flujo de costes de un proyecto como el conjunto de pagos
que realizamos por los recursos que aplicamos a un proyecto. Siempre se ha
de tener en cuenta el momento en que este pago se hace efectivo.

Flujo de ingresos de un proyecto es el conjunto de ingresos percibidos por


la empresa que desarrollo el sistema. Cada ingreso se tiene en cuenta en el
instante en que se hace efectivo.

Flujo de caja (efectivo) es el conjunto de flujos de ingresos menos el flujo


de gastos. Así al final de cada período de pagos acumulamos los pagos e
ingresos que realizamos en el proyecto.

A la hora de asignar importes monetarios a las actividades, las empresas


hacen un cálculo ponderado de los gastos totales por la cantidad de personas
disponibles para realizar proyectos, de modo que asumiremos como gasto de

111
GESTIÓN DE PROYECTOS INFORMÁTICOS

una tarea la cantidad de personas efectivas asignadas durante ese mes a la


tarea, multiplicado por el coste asociado a cada una de ellas.

Los periodos del flujo de caja pueden ser diarios, semanales, mensuales o
anuales, según la planificación y su nivel de detalle será más apropiado uno
de ellos en particular.

Otro dato importante en el estudio económico es el flujo de caja


acumulado a lo largo del proyecto. Consiste en ir acumulando los importes
del flujo de caja. En la gráfica adjunta se puede observar su comportamiento.
Éste acumulado se compone de costes e ingresos. La gráfica de los costes
tiene forma de S y suele ser muy significativa la comparación de la S
planificada y la real del proyecto en curso. El acumulado de caja es útil para
visualizar los niveles de endeudamiento en que incurre el gestor del proyecto
y caso de no poder afrontarlos debería desistir de su realización, aun cuando
se tratase de un sistema que produjera beneficios.

3.1 Ejemplo.

A modo de ejemplo vamos a calcular el flujo de caja del proyecto


planteado en el anteriormente. Partiremos de que los analistas suponen un
coste para la empresa de 400.000 pesetas y los programadores 200.000
pesetas al mes. Por el proyecto se cobrará 10.000.000 pesetas cuando se
finalice la Instalación del sistema, tarea J. Tener en cuenta que los pagos y
cobros se realizan a final de cada mes.

112
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

SOLUCIÓN

A 2A

B 1A
C 2A
D 1P

E 1A

F 4P
G 1A

H 2P
I 2P

J 2P

K 1P
MES: 1 2 3 4 5 6 7 8 9 10
Analistas 400 2 2.5 3 1 0.5
Programadores 200 2.5 4.5 3 2 2 1 1

Pagos Analistas 800 1000 1200 400 200 0 0 0 0 0


Pagos Program. 0 0 0 500 900 600 400 400 200 200

Flujo pagos 800 1000 1200 900 1100 600 400 400 200 200
Flujo cobros 10000

Flujo de Caja -800 -1000 -1200 -900 -1100 -600 -400 9600 -200 -200
Acumulado -800 -1800 -3000 -3900 -5000 -5600 -6000 3600 3400 3200

4. VISIÓN FINANCIERA DEL PROYE


CTO
INFORMÁTICO. V.A.N.
Acabamos de ver como se calcula el flujo de caja así como su acumulado
en un proyecto pero, aun suponiendo que hemos acertado con todos los
recursos, realmente el acumulado que acabamos de obtener: ¿incluye todos
los costes en los que se incurre en el proyecto?.

113
GESTIÓN DE PROYECTOS INFORMÁTICOS

Hay una variable que no hemos en cuenta, esta es el valor del dinero.
Como hemos visto vamos pagando e ingresando dinero como consecuencia
del proyecto, pero se pueden sumar los importes en diferentes instantes del
tiempo. Planteando el problema de forma sencilla: ¿disponer de mil pesetas
hoy, tiene el mismo valor que disponerla dentro de un año? ¿Y dentro de dos
años?.

Supongamos que le propongo a una persona que me preste 100.000


pesetas y se las devolveré dentro de un año, ¿es normal que el acceda sin
ninguna contraprestación? ¿Podría el haber obtenido un rendimiento a ese
dinero, que sacrifica al prestármelo?.

Sin tener en cuenta la inflación, normalmente la gente prefiere satisfacer


sus necesidades actuales, que esperar a disponer del efectivo. Así tenemos
que el valor del dinero fluctúa a lo largo del tiempo y en función de las
necesidades de la empresa. Podemos identificar dos razones para ello:
 disponer de él tiene un coste, aunque lo devolvamos en el futuro, y
 la inflación hace que aun cuando dispongamos del dinero, tengamos
que prever que éste tiene valoraciones diferentes.

En resumen, desde nuestro punto de vista podemos considerar que el


dinero de hoy es diferente del de mañana según una tasa de interés i, es decir
que 100 pesetas de hoy son lo mismo que 100+i del próximo año.

Para actualizar el valor del dinero podemos utilizar la siguiente fórmula


[URRIEGAS]:
F  P (1  i ) n
donde:

 F: Valor Futuro (ptas.)

 P: Valor Presente (Ptas.)

 i: Tasa de Interés en el periodo (incremento del valor)

114
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

 n: Número de periodos transcurridos.

Veamos de donde viene esta fórmula. Esta claro que:

Fn  Fn1  Fn 1 * i  Fn 1 (1  i )
(el valor del dinero de un año dado es el valor del dinero el año anterior
aplicándole el interés correspondiente )

Así pues, deductivamente:

Fn  Fn1 (1  i )  Fn 2 (1  i )(1  i )  Fn  2 (1  i ) 2 
n
 Fn  3 (1  i ) 2 (1  i )  Fn 3 (1  i ) 3 ...  P(1  i )

Si queremos saber cual es el valor futuro de 1000 ptas., siendo n un año y


el interés un 20%, tendremos que: F=1000*(1,2)1 = 1.200 ptas.

Es decir, para mi, sería equivalente el disponer de 1.000 ptas. hoy o 1.200
ptas. dentro de un año.

Si ampliamos el período a cinco años, tendré: F=1000(1,2)5= 2.488 ptas.

La siguiente representación gráfica nos muestra la evolución del valor de


mil pesetas de hoy, con los intereses del 20%, a lo largo de los próximos diez
años:

115
GESTIÓN DE PROYECTOS INFORMÁTICOS

Valor Futuro al 20% anual

7000

6000

5000

4000
Pesetas

3000

2000

1000

0
0 1 2 3 4 5 6 7 8 9 10
Años

Vemos en ésta gráfica otro dato que no puede escapar de nuestra


atención: el incremento es exponencial, no se trata de que cada año suba
linealmente 200 ptas., si no de que cada año el incremento es mayor, desde
las 1.200 ptas. del primer año que suponen un incremento de 200 ptas. con el
año anterior hasta las 6.191 del último año, que suponen 1.032 ptas. de
incremento con respecto al año anterior.

Debemos por otra parte hacer hincapié en que el interés lo debe fijar el
dueño de la empresa, o en su defecto, quien entienda financieramente de
esta7, pero observemos que nunca será 0, ya que siempre habrá algún
negocio del que se hubieran obtenido rendimientos del capital (letras del
tesoro, bonos de empresas solventes, son ejemplos de lugares donde el
dinero además de dar un rendimiento, no estaría expuesto a riesgos).

Normalmente, cuando prevemos un negocio, podemos estimar los


importes que deberemos gastar a lo largo de la duración del negocio, así
como los ingresos que obtendremos de éste. De modo que nos interesaría
saber cuales serán los valores de estos importes a fecha de hoy, para poder
sumarlos y saber, a fecha de hoy, cual es el rendimiento neto. Para esto nos

7
Un ejemplo de interés calculado sería el T.A.E. de los bancos.

116
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

hace falta actualizar los flujos de caja al valor presente. Para ésto podemos
darle la vuelta a la formula y obtener el valor actual como:
P  Fn (1  i )  n
Esta fórmula viene de:

Fn
Fn  P(1  i ) n  P   Fn (1  i )  n
(1  i ) n

Ahora que ya disponemos de fórmulas para viajar económicamente en el


tiempo, veamos cuales serían los valores actuales y futuros de 1.000 ptas. al
0,4% semanal.
Valor actual y futuro de 1000 pts al 0,4% semanal

1400

1200

1000

800
Pesetas

600

400

200

0
0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51
Semanas

Observemos que 1.000 ptas. de hoy serían 815 al final del año, mientras
que 1.230 ptas. de fin de año tendrán el mismo valor adquisitivo que 1.000
ptas. de hoy.

Actualizando el flujo de caja de nuestro ejemplo anterior, con unos


intereses del 1,8% mensual ( 21,6% anual ).

117
GESTIÓN DE PROYECTOS INFORMÁTICOS

10000

8000

6000

4000 Flujo Caja

Valor Actual
2000

0
1 2 3 4 5 6 7 8 9 10
-2000

Observamos que los importes actualizados son menores cuanto más


avanzado esta el proyecto. Veremos más claramente esto si representamos
con una gráfica el flujo de caja, su actualización y el acumulado de este. En
él incidiremos en un punto: la capacidad máxima de endeudamiento de un
proyecto, que vendrá dada por el mayor valor negativo del acumulado. Ante
este valor, la empresa deberá decidir si es capaz de soportarlo o en caso
contrario, bien modificar el proyecto para disminuirlo, bien abandonarlo.

10000
8000 Flujo Caja
6000
4000 Valor Actual
2000
0 Acumulado
-2000 1 2 3 4 5 6 7 8 9 10
-4000 Acumulado no
-6000 actualizado
-8000

Veamos para finalizar, que esta visión financiera puede modificar nuestro
punto de vista sobre los retrasos de un proyecto. Empezaremos con un

118
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

ejemplo: Sabemos que el valor acumulado al final de este proyecto ( mes 10 )


es de 2.361.000 ptas. ¿ Qué pasaría si el octavo mes coincidiera con agosto y
la empresa lo tomara como vacacional? ¿Se retrasaría el cobro un mes? ¿Cúal
será el nuevo acumulado? ¿Cuánto perderíamos?

Si no tuviéramos ese retraso, al fin del proyecto, tendríamos un valor


actual del proyecto de 2.360.000 ptas., con el retraso, esa cantidad se
reducirá a 2.220.000 ptas., es decir, perderemos 140.000 ptas. como
consecuencia de retrasar un mes la entrega del proyecto, como se muestra en
las siguientes tablas.

Tabla considerando duración de 10 meses:


Mes Flujo Caja Valor Actual Acumulado Acumulado no
Actualizado actualizado
1 -800 -785,854617 -785,854617 -800
2 -1000 -964,949186 -1750,8038 -1800
3 -1200 -1137,46466 -2888,26846 -3000
4 -900 -838,014238 -3726,2827 -3900
5 -1100 -1006,1293 -4732,412 -5000
6 -600 -539,094104 -5271,5061 -5600
7 -400 -353,041326 -5624,54743 -6000
8 9600 8323,17467 2698,62725 3600
9 -200 -170,33347 2528,29378 3400
10 -200 -167,32168 2360,9721 3200
Tabla considerando 11 meses ( 10 + vacaciones ):
Mes Flujo Caja Valor Actual Acumulado Acumulado
no actualizado
1 -800 -785,854617 -785,854617 -800
2 -1000 -964,949186 -1750,8038 -1800
3 -1200 -1137,46466 -2888,26846 -3000
4 -900 -838,014238 -3726,2827 -3900
5 -1100 -1006,1293 -4732,412 -5000
6 -600 -539,094104 -5271,5061 -5600
7 -400 -353,041326 -5624,54743 -6000
8 0 0 -5624,54743 -6000
9 9600 8176,00656 2551,45913 3600
10 -200 -167,32168 2384,13745 3400
11 -200 -164,363143 2219,77431 3200

119
GESTIÓN DE PROYECTOS INFORMÁTICOS

BIBLIOGRAFÍA: REFERENCIAS Y AMPLIACIÓN


DE TEMAS.
1. DeMarco, Tom. Controlling Software Projects. Prentice Hall, 1982.
(Biblioteca UPV)

2. Page-Jones, Meilir. Practical Project Management, Dorset House, 1985.


(Biblioteca UPV)

3. Shtub, A., Bard, J.F. ,Globerson, S., PROJECT MANAGEMENT,


Engineering, Technology and Implementation, Prentice Hall International,
1994. (Biblioteca UPV ).

4. Uriegas Torres, Carlos. ANÁLISIS ECONÓMICO DE SISTEMAS EN


LA INGENIERÍA, Limusa, 1987

120
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO

121