Libro Gestion - Informatica

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
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
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
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
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
 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
 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
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
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
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
 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
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
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
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
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
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
 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
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
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
 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:
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Í
A Lógica del proceso exclusiva de esta salida (o primera vez)
B Los datos elementales son diferentes de otras salidas
23
figura 5
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:
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í
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
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
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:
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
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
BAJA MEDIA ALTA
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
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
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
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
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
Ficheros Internos  Peso * Fi
Ficheros de Simple 5 I1 5 * I1
Interfaz Media 7 I2 7 * I2
Compleja 10 I3 10 * I3
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
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
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
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
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
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.
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
 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
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
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
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
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
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
 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.

valor de 4.

valor de 5.
42
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
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
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
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
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
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
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
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
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
“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
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
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
 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
 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
 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
 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
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
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
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
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
 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
 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

planificación, recursos, etc., de la siguiente fase (Diseño del
sistema).
 Producir el documento de especificación del sistema.
 Realizar una revisión final del documento de especificación
del sistema.
 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
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.
planificación, recursos, etc., de la siguiente fase
(Codificación) con esta alternativa.
 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.
 Recomendar una alternativa.
 Hacer recomendaciones sobre el nivel de compromiso, si los hay, de
66
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
 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
 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
 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
 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
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
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
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
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
 ¿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
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
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
 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
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
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
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
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
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
 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
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
 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
 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
108
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
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
 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
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
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
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
 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
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
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
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
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
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
121

Libro Gestion - Informatica

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Libro Gestion - Informatica

Diunggah oleh

Hak Cipta:

Format Tersedia

1.

1. Diferentes formas de organizar el trabajo.

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

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

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

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

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

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

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

 Trabajo final de carrera,

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

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

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

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

Es necesaria la intervención de varias personas.

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

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

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

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

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

5.1.1. Definición del problema.

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

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

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

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

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

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

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

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

 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,

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

 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 muchas organizaciones, una vez definido el problema, éste se añade a

5.1.2. Planificación del proyecto.

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

 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,

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

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

En otras ingenierías se utiliza la siguiente secuencia:

5.2. Ejecución del proyecto.

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

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

5.2.1. Puesta en marcha.

Esta fase se caracteriza fundamentalmente porque en ella se ha de

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

5.2.2. Fase productiva.

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

Por su parte el responsable del proyecto debe:

5.2.3. Conclusión del proyecto.

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

Las actividades a realizar son las siguientes:

 Reasignar el personal a los nuevos proyectos o reintegrarlos en

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

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

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