Professional Documents
Culture Documents
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
GESTIÓN DE PROYECTOS INFORMÁTICOS
1
A. Shutub en el punto 1.2
2
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
2. ¿Qué es un proyecto?
Cuando escuchamos el vocablo proyecto nos vienen a la mente diferentes
acepciones tales como:
3
GESTIÓN DE PROYECTOS INFORMÁTICOS
3. ¿Que es la gestión?
Podemos comenzar por ver lo que dice el diccionario de la Real Academia
Española:
gestión. Acción y efecto de gestionar. ...
4
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
5
GESTIÓN DE PROYECTOS INFORMÁTICOS
Dado que los proyectos solo realizan una vez, la secuencia de las
funciones es clara, por lo que la documentación sobre proyectos la clasifica
en fases, que son más o menos secuenciales. A continuación se describen en
detalle.
5. Fases de un proyecto.
Todos los proyectos, que se gestionan como tales, tienen una serie de
fases comunes, no tanto porque se realicen tareas iguales, sino porque el
objetivo de cada fase con relación al producto a obtener es común a
cualquier proyecto.
5.1. Planeación.
6
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
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.
7
GESTIÓN DE PROYECTOS INFORMÁTICOS
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, …
Los siguientes puntos nos dan una idea de la forma de pensar, así como
las tareas a realizar durante esta fase:
8
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
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.
9
GESTIÓN DE PROYECTOS INFORMÁTICOS
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.
10
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
11
GESTIÓN DE PROYECTOS INFORMÁTICOS
12
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
13
GESTIÓN DE PROYECTOS INFORMÁTICOS
Coste
acumulado
Comprometido
figura 1
Bibliografía.
1. Shtub, A., Bard, J. Et Sholomo, G. “Project Management Engineering,
Technology and Implementation”, Prentice-Hall, 1994.
2. Haynes, M. E. “Administración de proyectos” Grupo editorial
Iberoamerica, 1992.
3. Weiss, J. W., Wysocki, R.K. “Dirección de proyectos, las 5 fases de su
desarrollo”. Addison-Wesley Iberoamericana.
4. Davis, W. S. “Herramientas Case” Editorial Paraninfo, 1992.
14
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
2. ESTIMACIÓN EN
DESARROLLO DE
SOFTWARE.
1. INTRODUCCIÓN.
Este tema se centra en la estimación del esfuerzo que tendrá que realizar
una empresa para desarrollar una aplicación. Por esfuerzo nos referimos a la
cantidad de recursos humanos, usualmente medidos en meses/hombre.
Partiremos de que ya se ha realizado un análisis estructurado y disponemos
de la especificación de requerimientos del sistema. Por desgracia esto no es
habitual, como dice Edward Yourdon un problema de la estimación es que se
nos pide que la realicemos cuando aún no está claro que desea el usuario (no
disponemos de la especificación).
15
figura 2
GESTIÓN DE PROYECTOS INFORMÁTICOS
Especificación de Requisitos a
requerimientos Cumplir Tareas a
realizar
Medir lo que
Estimación Descomponer
quiere el
del Esfuerzo por fases y
usuario tareas
Estimar lo
Medida de lo que que Costara
(esfuerzo) Historial
quiere el usuario Empresa
16
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
17
GESTIÓN DE PROYECTOS INFORMÁTICOS
Juicio experto
18
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
Top-Down
Bottom-up
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.
19
GESTIÓN DE PROYECTOS INFORMÁTICOS
Por otra parte evaluamos de forma explícita los factores de desarrollo que
influyen sobre la productividad como lenguajes de desarrollo, entornos de
trabajo, etc. Seguiremos manteniendo la idea de caja negra, ya que los
gestores del desarrollo no están interesados en cómo se desarrolla en cada
lenguaje (ensamblador, 4GL, etc.) sino que se centran en los diferentes
niveles de productividad que se tiene con cada uno de ellos. El que realiza la
estimación necesitará tener información histórica que sea apropiada sobre los
lenguajes, como veremos más adelante.
20
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJOfigura 3
21
figura 4
GESTIÓN DE PROYECTOS INFORMÁTICOS
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
22
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
Cuestión: Respuesta
El proceso envía datos o información al exterior de la aplicación Sí
El proceso es la unidad mínima de actividad con sentido para el usuario Sí
El proceso es completo y deja al sistema en un estado consistente SÍ
Para el proceso subyacente se debe de cumplir AoB
A Lógica del proceso exclusiva de esta salida (o primera vez)
B Los datos elementales son diferentes de otras salidas
23
figura 5
GESTIÓN DE PROYECTOS INFORMÁTICOS
3.1.3. CONSULTAS.
En la figura 4 se muestra su
apariencia en el DFD.
Cuestión: Respuesta
Una petición atraviesa la frontera del sistema Sí
El proceso envía datos o información al exterior de la aplicación Sí
Se recuperan datos Sí
No se calculan datos derivados para enviar al exterior Sí
El proceso (entrada/salida) es la unidad mínima de actividad que tiene Sí
sentido para el usuario
El proceso es completo y deja al sistema en un estado consistente Sí
El proceso no actualiza ningún Fichero Lógico Interno Sí
Para el proceso subyacente se debe de cumplir AoB
A Lógica del proceso en su parte de entrada o salida, es distinto del de
otras consultas del sistema (o la primera vez)
B Los datos elementales de la entrada o salida son diferentes de otras
consultas
24
figura 6
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
Cuestión: Respuesta,
Se trata de una agrupación de datos lógica o identificable desde el punto de
vista del usuario y satisface un requerimiento específico del usuario Sí
La agrupación de datos es mantenida por procesos de la aplicación en estudio Sí
La agrupación de datos es mantenida mediante un proceso elemental de la
aplicación Sí
25
GESTIÓN DE PROYECTOS INFORMÁTICOS
figura 7
26
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
27
GESTIÓN DE PROYECTOS INFORMÁTICOS
Se han de contar los campos que hacen falta para mantener las
relaciones con otros ficheros Internos o Externos.
28
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
29
GESTIÓN DE PROYECTOS INFORMÁTICOS
30
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
Albrecht son catorce. Cada factor tomará un valor entre 0 y 5, de modo que
cuanta más importancia tenga un factor mayor valor se le asignará.
1) Comunicación de Datos.
0 Sistema aislado del exterior (sólo usuarios directos. Ej.: PC; BATCH ).
31
GESTIÓN DE PROYECTOS INFORMÁTICOS
2) Proceso Distribuido.
3) Objetivos de Rendimiento.
32
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
0 Rendimiento normal (el que suelen dar los sistemas informáticos en los
que no se pone énfasis en este tema).
33
GESTIÓN DE PROYECTOS INFORMÁTICOS
5) Tasa de Transacciones.
34
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
35
GESTIÓN DE PROYECTOS INFORMÁTICOS
Uso de ratón.
Ventanas de "pop-up".
Forzar la aplicación a tener el menor número posible de pantallas por
transacción.
Aplicación bilingüe (cuenta por cuatro).
Aplicación Multilingüe (más de dos, cuenta por seis).
Toma el valor:
2 De cuatro a cinco.
8) Actualizaciones EN-LÍNEA.
36
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
37
GESTIÓN DE PROYECTOS INFORMÁTICOS
38
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
39
GESTIÓN DE PROYECTOS INFORMÁTICOS
Valoraremos con:
40
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
0 En sólo un lugar.
41
GESTIÓN DE PROYECTOS INFORMÁTICOS
Toma el valor::
0 No se especifica nada.
42
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
43
GESTIÓN DE PROYECTOS INFORMÁTICOS
PFC=(PFSA+CONVER)*(0,65+(0,01*FCT))
44
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
De todos modos esto no deja de ser una orientación ya que como indica
Thomsett algunas organizaciones usan valores como 40 horas por punto de
función en COBOL.
45
GESTIÓN DE PROYECTOS INFORMÁTICOS
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:
46
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
6. BIBLIOGRAFÍA Y REFERENCIAS A
CONSULTAR.
1. Albrecht, A.J. and Gaffney, J.E.. "Software Function, Source Lines of
Code, and Development Effort Prediction: A Software Science
Validation". IEEE Transaction on Software Engineering, Vol. SE-9, Nº
6, Nov. 1983, pp. 639-648. (Hemeroteca UPV).
2. Boehm, Barry. Software Engineering Economics. Reimpreso en
Software Management (4 ed.), Donald J. Reifer, IEEE Computer Society
Press 1993. (Biblioteca UPV).
3. Dreger, J.B. "Function Point Analysis", Prentice Hall, 1989. (Biblioteca
UPV).
4. Gibson, Robin. Managing Computer Projects. Avoiding the Pitfalls.
Prentice Hall, 1992. (Biblioteca UPV).
5. International Function Point Users Group: "Function Point as an Asset -
Reporting to Management", 1992. (Disponible para consulta restringida
en el Dpto.).
47
GESTIÓN DE PROYECTOS INFORMÁTICOS
48
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
3. IDENTIFICACIÓN DE FASES,
TAREAS Y ENTREGABLES EN
PROYECTOS INFORMÁTICOS
49
GESTIÓN DE PROYECTOS INFORMÁTICOS
50
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
1. DESCOMPOSICIÓN EN ACTIVIDAD
ES DEL
PROYECTO (WBS).
Empezaremos por ver la herramienta que se utiliza a la hora de
descomponer y documentar el trabajo de un proyecto, como un conjunto de
tareas. Habitualmente se le conoce como WBS (Work Breakdown Structure)
que literalmente significa estructura de descomposición del trabajo. Es un
método de representar de forma jerárquica los componentes de un proceso o
producto. Puede ser utilizado para documentar la descomposición de un
proceso, la descomposición de un producto, o de forma híbrida.
0.0. Proyecto
Contabilidad
1.0. Especificar 2.0. Analizar 3.0. Diseñar 4.0. Codificación 5.0. Pruebas
necesidades Contabilidad Aplicación
1.1. Estudiar 2.1. Estudiar 3.1. Diseño 4.1. Creación 5.1. Prueba
Sistema Actual Procesos B.D Esquema Unidades
1.2. ide. nuevas 2.2. Estudiar 3.2. Diseño 4.2. Codificación 5.2. Prueba del
carácteristica Datos Programas Programas Sistema
51
GESTIÓN DE PROYECTOS INFORMÁTICOS
0. Proyecto Contabilidad.
1. Especificar necesidades.
1.1. Estudiar Sistema Actual.
1.2. Añadir Nuevas Características.
2. Analizar Contabilidad.
2.1. Estudiar Procesos.
2.2. Estudiar Datos.
3. Diseñar Aplicación.
3.1. Diseño B.D.
3.2. Diseño Programas.
4. Codificación.
4.1. Construcción del esquema.
4.2. Codificación de los Programas
5. Pruebas
5.1. Prueba de Unidades
5.2. Prueba del Sistema
52
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
Especificación de tarea
Número: 3.1.
Nombre: Diseño B.D.
Descripción: Se diseñara la base de datos, partiendo del
modelo entidad-relación propuesto en el análisis y
con el objetivo de tener un sistema funcionando
sobre DB2.
Esfuerzo Estimado: 2 semanas/hombre
Entregables: Estructura de implementación de la B.D.
…: …
2. ENTREGABLES DE UN PROYECTO
INFORMÁTICO.
Dado que el objetivo final del proyecto es la entrega de un subsistema
informático (entregable) veamos algunas definiciones y utilidades de los
entregables. Los entregables los definiremos como "Productos que, en un
cierto estado, se intercambian entre los clientes y los desarrolladores a lo
largo de la ejecución del proyecto informático".
53
GESTIÓN DE PROYECTOS INFORMÁTICOS
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:
Análisis:
54
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
Captura de requisitos:
Requisitos de datos.
Requisitos de telecomunicaciones.
Requisitos de hardware.
Diseño:
Transacciones
Diccionario de datos
Procedimientos
55
GESTIÓN DE PROYECTOS INFORMÁTICOS
Codificación:
56
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
Pruebas:
Instalación:
Informe de la instalación.
Mantenimiento:
57
GESTIÓN DE PROYECTOS INFORMÁTICOS
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.
58
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
46 Producción del
Sistema
24 Integración del
Sistema
0 10 20 30 40 50
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
Dirección Proyecto
21
Definición del
28 Sistema
Diseño del Sistema
% 15
25 Producción del
Sistema
11 Integración del
Sistema
0 10 20 30
59
GESTIÓN DE PROYECTOS INFORMÁTICOS
0 5 10 15 20 Soporte
Administrativo
Las empresas deberán identificar las fases (ítems del ciclo de vida) o
actividades importantes de desarrollo de sus aplicaciones y almacenar el
consumo de recursos (esfuerzo) aplicado en cada uno de éstas. Es
aconsejable el identificar aquellas componentes del desarrollo que supongan
un consumo substancial de recursos.
En la revista Computer de Mayo del ‘96, Caper Jones hace una propuesta
muy interesante en la que relaciona en una tabla 25 actividades, las que
suelen tenerse en cuenta en su empresa ante un proyecto nuevo, el tamaño
mínimo de proyecto a partir del que consideran la actividad, los costes
asociados en esfuerzo, salarios y coste económico de la actividad por punto
de función. Aunque no lo indica explícitamente, esto da lugar a una
justificación sencilla dando a del porqué los proyectos grandes tienen un
mayor coste por punto de función.
60
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
61
GESTIÓN DE PROYECTOS INFORMÁTICOS
entrega como para la calidad del software. Por otra parte el dejar que sean
los propios desarrolladores los que identifiquen tareas y recursos, dentro de
un marco razonable (puntos de función) les llevará a una situación de
compromiso personal, pasando a interiorizar los objetivos y como
consecuencia obtendremos mejores resultados.
62
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
Estudio de viabilidad:
Analizar el sistema propuesto y escribir una descripción.
Definir y documentar posibles tipos de sistemas.
Hacer un análisis de coste de sistemas similares.
Hacer una estimación del tamaño del sistema, la planificación y los
costes. (tener en cuenta los entregables más importantes).
Definir cualitativa y cuantitativamente los beneficios del sistema
propuesto.
Realizar una planificación inicial del plazo de recuperación de la
inversión.
Realización de una estimación detallada de costes, planificación,
recursos, etc., de la siguiente fase (Análisis).
Asignar director del proyecto.
Composición del documento de estudio de viabilidad.
Presentación del documento de viabilidad a la dirección para su
aprobación.
Análisis:
Captura de requisitos:
Definir el ámbito del sistema propuesto
Funciones
Dimensiones
Usuarios
Restricciones
Entrevista a todos los usuarios propuestos y actuales:
Determinar:
Utilización del sistema actual
Deficiencias del sistema actual
Requisitos nuevos del sistema
Documentar:
Descripción del sistema actual
Deficiencias del sistema actual
Producir el documento de requisitos del nuevo sistema
Incluir:
63
GESTIÓN DE PROYECTOS INFORMÁTICOS
64
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
Diseño:
Producir el diseño global del sistema, contendrá:
Definir los programas y sus principales funciones.
Definir los principales flujos de datos entre programas y
funciones.
Diseñar el esquema de datos lógico y físico.
Definir las fronteras con paquetes software, si existen.
Definir los entornos de hardware y software, proponiendo
alternativas.
Documentar los diagramas de diseño alternativos.
Localización de paquetes software: Buscar paquetes software
apropiados que puedan implementar parte, o toda la funcionalidad
requerida del sistema de forma rentable y que, si se implementa,
ofrezca un entorno compatible con los objetivos de la organización.
(Puede realizarse antes del diseño, o de forma simultánea a la tarea
anterior).
Desarrollar un diseño detallado del sistema, para cada alternativa de
diseño planteada:
Crear una descripción narrativa detallada del diseño para
todo el sistema y cada una de sus partes (programas,
funciones y datos).
Actualizar el diccionario de datos.
Definir los componentes hardware específicos (Capturadores
65
GESTIÓN DE PROYECTOS INFORMÁTICOS
66
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
Codificación:
Producir un plan de trabajo:
Creación de la lista detallada de tareas necesarias para
realizar la codificación y test de todos los componentes del
sistema.
Producir una planificación para las tareas anteriores con las
fechas más tempranas y más tardías, así como la asignación
de responsabilidades.
Instaurar los procedimientos para recoger los progresos y
estados del proyecto.
Instaurar los procedimientos para recoger tiempos, si resulta
apropiado.
Obtener la aprobación del plan de trabajo por parte de la
dirección.
Realización del diseño detallado de cada programa:
Diseñar detalladamente los diagramas:
De estructura de los programas y jcl
De estructura de los ficheros
Pantallas, informes, y otras composiciones
Esquemas de la base de datos
Composición de las tablas y sus diseños
Pseudocódigo de la lógica del programa. (Dependerá de los
métodos de diseño utilizados).
Codificar, documentar y pasar los test en cada programa:
Codificar el programa y los procedimientos de control (jcl)
Realizar las pruebas de unidad, hasta que los programas se
adapten a las especificaciones descritas en las etapas
anteriores
Actualizar todo lo necesario en el sistema y en el DD de la
organización
67
GESTIÓN DE PROYECTOS INFORMÁTICOS
Pruebas:
Realizar el test del sistema
Hacer el test de sistema de acuerdo al documento de test del
sistema.
Verificar la operatividad de los manuales de usuario y
operador, utilizándolas en los cursos de formación de los
usuarios y operadores que realicen el test del sistema.
Verificar los documentos de entrenamiento de usuarios y
operadores, utilizándolos en los cursos de formación de los
usuarios y operadores que realicen el test del sistema.
Documentar completamente los resultados del test del
sistema.
Revisar la planificación de instalación:
Disponibilidad de los recursos.
Revisión de los factores de contingencia que puedan afectar a
la instalación.
68
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
69
GESTIÓN DE PROYECTOS INFORMÁTICOS
70
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
Desarrollo de sistemas
Soporte de sistemas y mantenimiento
Finanzas
Obtener la carta de aprobación del sistema
Establecer el calendario para otras revisiones post-instalación si es
necesario.
Mantenimiento:
Implementar los cambios del sistema:
Utilizar los procedimientos de implementación de versiones,
o
Implementar versiones de emergencia y después utilizar los
procedimientos de versiones fo rmales de forma retroactiva.
Asegurarse de que el sistema continua solucionando las necesidades
de los usuarios.
Utilizar los acuerdos de niveles de soporte.
Revisiones regulares de requerimientos del nivel de
acuerdo.
Revisiones regulares de como el sistema esta
alcanzando sus objetivos
Llevar a cabo revisiones regulares del sistema
Utilizar los procedimientos y contenido de las
revisiones post-instalación.
Estas tareas se han enumerado a modo de lista de comprobación, de
forma que serán los desarrolladores los encargados de identificar las tareas
apropiadas a cada proyecto así como los recursos necesarios, teniendo en
cuenta la estimación previa del esfuerzo.
71
GESTIÓN DE PROYECTOS INFORMÁTICOS
6. BIBLIOGRAFÍA Y REFERENCIAS A
CONSULTAR.
1. David King. "Project management made simple", Prentice Hall, 1992.
2. Jones, Caper. “Activity-based software costing,” Computer, May 1996, p.
103-104.
3. Fergus O'Connell. "How to run successful projects". Prentice Hall, 1994.
4. Martyn A. Ould. "Strategies for software engineering". Jonh Wiley, 1990.
5. Yourdon, Edward. Análisis Estructurado Moderno. Prentice Hall, 1993.
4. ASIGNACIÓN DE RECURSOS
EN LOS PROYECTOS
INFORMÁTICOS
72
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
1. INTRODUCCIÓN.
La asignación de recursos consiste en asociar a cada una de las tareas, en
el proyecto, las personas, equipos y materiales necesarios para que éstas se
puedan realizar. Esta es una al bor complicada y fundamental en la
planificación del desarrollo de una aplicación informática.
73
GESTIÓN DE PROYECTOS INFORMÁTICOS
Desde un punto de vista global, además de las tareas propias del proyecto
debemos tener en cuenta, que para que un grupo haga su trabajo, es
necesario que:
Se realicen las tareas en si mismas.
Se realicen tareas de mantenimiento del equipo, esto es, lo que ayude
a mantener su cohesión, su motivación y su voluntad general de
2
Se puede argumentar que con un Hardware más eficiente, con unas oficinas mejor
acondicionadas o que con herramientas de desarrollo más evolucionadas se podría realizar
el proyecto en menos tiempo. Este tipo de cuestiones y otras que influyen en la duración y
calidad del Software las trataremos en DPI'
74
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
dedicarse a la tarea.
Se satisfagan las necesidades individuales, es decir, lo que ayuda al
individuo a sentirse parte del grupo y le capacita para realizar su
aportación máxima.
75
GESTIÓN DE PROYECTOS INFORMÁTICOS
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.
76
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
É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.
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,
3
Frederick P. Brooks comenta en su libro The mythical man-month: "Por lo tanto el meses-
hombre como una unidad para medir el tamaño de un trabajo es un mito peligroso y engañoso.
Implica que los meses y los hombres son intercambiables.".
77
GESTIÓN DE PROYECTOS INFORMÁTICOS
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:
4
Ver Análisis Estructurado Moderno, E. Yourdon; pág. 536. o Assesment and Control of
Software Risks, C. Jones; pág. 118.
78
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
79
GESTIÓN DE PROYECTOS INFORMÁTICOS
Esfuerzo_en_hombres(t) = 2K a t e-at²
donde
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
Una vez realizado el grueso del trabajo van quedando menos tareas y
la cantidad de personas que se pueden asignar son menos.
81
GESTIÓN DE PROYECTOS INFORMÁTICOS
figura 9
o o
nd ad tra
No cua lic de Ex ara
zo o zo le Ap tar zo io p r la
er tad r b zo o er r
fu as e
fu ni lta er ad fu sa sa
s
E alg Es ispo a fa fu si Es ece pen ión
M D aci Es ema N om nac cta
h d C ig rre
16 as co
in
14
12
10
8
Personas
6
4
2
0
0 2 4 6 8 10 12 14 16 18 20 22 24
M e s es d e D e sa rro llo
80
60
40
PERSONAS
20
0
0 12 24 36 48 60 72 84
MESES DE DESARROLLO
figura 10
82
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
T 2,15 3 PersonasMes
5
Ver falta de especialización en el libro de C. Jones "Assesment and Control of Software
Risks" pág. 409-18
83
GESTIÓN DE PROYECTOS INFORMÁTICOS
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.
84
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
85
GESTIÓN DE PROYECTOS INFORMÁTICOS
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:
86
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
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:
6
En su libro "How to Run Successful Projects"
87
GESTIÓN DE PROYECTOS INFORMÁTICOS
Esto es lo ideal.
Si estás dispuesto a:
88
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
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
3
2 por ejemplo, si para realizar las
1
0
pruebas me hace falta un
0 1 2 3 4 5 6 7 8 dispositivo Hw especial, del que
Personas tan solo se dispone de una
unidad, no tendrá sentido que
asigne muchas personas a esta
tarea.
9
8
3) La tarea se puede partir, pero se
7 requiere comunicación entre las
6 personas. En principio es la
5
4 situación más habitual dado que
uración
D
3 de contener subtareas
2
independientes, esto se hubiera
1
0 tenido en cuenta en la
0 1 2 3 4 5 6 7 8 descomposición en tareas y
Personas tendríamos varias tareas bien
89
GESTIÓN DE PROYECTOS INFORMÁTICOS
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”.
90
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
de solicitudes, quejas y aclaraciones, sobre: las tareas que una persona cree
que debería tener asignadas, dado que están muy relacionadas con sus
objetivos y que han sido asignadas a otro; tareas que alguien piensa que no
han sido asignadas; e incluso asignaciones que comparten varios
participantes del proyecto, pero que parecen incompatibles por la
personalidad de los estos.
Pasados un par de días de las quejas, se hace una reunión con todos los
participantes, se habla sobre los problemas surgidos. Sé reescriben las
asignaciones y se entregan de nuevo a los participantes. Este proceso puede
requerir un par de iteraciones y las reuniones puede que sean tensas. Pero
habrá valido la pena, ya que tendremos una descripción clara y compartida de
los objetivos, responsabilidades y tareas asignadas a cada miembro del
equipo. Además las tareas no se superpondrán y completaran todas las
necesidades del proyecto. (Managing a Programming Project, Metzger).
6.CONSIDERACIONES FINALES.
Como se ve habrá que buscar la situación en que se optimicen cualquiera
o todas estas condiciones:
91
GESTIÓN DE PROYECTOS INFORMÁTICOS
6. BIBLIOGRAFÍA
1. Blanchard, K., Johnson, S. “El ejecutivo al minuto”. Grijalbo Mandadori,
S.A. 1983.
2. Brooks, Frederick P. ”The mythical man-month”
3. DeMarco, Tom. Controlling Software Projects. Prentice Hall, 1982.
(Biblioteca UPV)
4. Fergus O'Connell. "How to run successful projects". Prentice Hall, 1994.
(Biblioteca UPV)
5. Metzger, P. Boddie, J. “Managing a programming project: people and
processes” 3 ed. Prentice Hall, 1996.
6. Thomsett, R. “Third Wave Project Management”. Prentice Hall, 1993.
(Biblioteca UPV)
7. Yourdon, Edward. Análisis Estructurado Moderno. Prentice Hall, 1993.
(Biblioteca UPV)
92
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
5. PROGRAMACIÓN TEMPORAL
DE PROYECTOS
1. INTRODUCCIÓN............................................................................................... 93
8. BIBLIOGRAFÍA............................................................................................... 107
1. INTRODUCCIÓN.
En este tema vamos a tratar el tema de la creación de calendarios para los
proyectos. Partiendo de las tareas, recursos asignados a cada una y las
precedencias entre las tareas, obtendremos una programación temporal.
93
GESTIÓN DE PROYECTOS INFORMÁTICOS
Diseño Programas
Realización Esquema
Codificación Programas
Pruebas
0 2 4 6 8 10 12 14 16
SEMANAS
figura 11
Dada la evolución tecnológica los seres humanos cada vez abordamos
proyectos más complejos, pero por otra parte creamos técnicas más
evolucionadas, completas y automáticas para gestionar estos proyectos. La
construcción del misil Polaris, así como la solución de los problemas en la
gestión de la producción de Dunlop llevaron al desarrollo de las técnicas
94
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
3.1. ETAPA 1.
95
GESTIÓN DE PROYECTOS INFORMÁTICOS
3.2. ETAPA 2.
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:
96
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
figura 14
Si tenemos un diagrama complejo, y queremos realizar los cálculos de
forma manual se puede utilizar el método que se describe a continuación.
figura 15
Donde:
97
GESTIÓN DE PROYECTOS INFORMÁTICOS
98
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
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:
99
GESTIÓN DE PROYECTOS INFORMÁTICOS
figura 16
4) Se obtiene la fecha de finalización de proyecto más tardía. Esta puede
venir dada por algún tipo de razones externas o puede que se nos pida
que el proyecto termine lo antes posible, en este caso la fecha de
finalización más tardía será el máximo de los "Final temprano" de
todas las tareas.
100
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
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.
101
GESTIÓN DE PROYECTOS INFORMÁTICOS
SOLUCIÓN:
Diagrama de precedencias:
B 1 E 0,5 D 1 G 0,5
1,5 Diseño 2,5 2,5 Desarroll 3 3,5 Construc 4,5 4,5 Revisión 5
o
2 B.D 3 3 Esquema 3,5 4 Prototipo 5 5 Prototipo 5,5
A 1,5 1,5 0,5 1 0,5 1,5 0,5 1 0,5
0 Análisis 1,5
0 1,5
1,5 0 C 2 F 2
1,5 Diseño 3,5 3,5 Codifica. 5,5
1,5 Progrm. 3,5 3,5 5,5
2 0 2 0
H 1 I 1 J 0,5 K 2
5,5 Revisión 6,5 6,5 Pruebas 7,5 7,5 Instalaci. 8 8 Manten. 10
5,5 Código 6,5 6,5 7,5 7,5 8 8 Inicial 10
1 0 1 0 0,5 0 2 0
Diagrama de Gantt:
102
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
A 2ª
B 1A
C 2A
D 1P
E 1A
F 4P
G 1A
H 2P
I 2P
J 2P
K 1P
1 2 3 4 5 6 7 8 9 10
duración = ( to + 4 tm + tp) / 6
Por otra parte el grafo se construye de forma dual a la vista. Los arcos
modelan las actividades o tareas, mientras que los nodos modelan la relación
103
GESTIÓN DE PROYECTOS INFORMÁTICOS
de precedencia de las tareas. Así un nodo indica que los arcos que llegan a él
anteceden a los que salen de él.
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.
104
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
Por otra parte también podemos reducir la duración del camino crítico,
actuando exclusivamente sobre una de sus tareas. A modo de ejemplo
estudiar lo que ocurriría si redujéramos la duración de la tarea A, del ejemplo
anterior, a un mes. Como se ve en este caso cualquier reducción de la tarea
se propaga a todo el proyecto. Por otra parte si redujéramos la duración de
la tarea F, “Codificación”, de dos meses a uno, sólo obtendríamos una
reducción de la duración del proyecto de medio mes, haciendo que además
cambiase el camino crítico.
105
GESTIÓN DE PROYECTOS INFORMÁTICOS
Los factores que más pueden influir en la duración de una tarea y por
tanto del proyecto, si se trata de una tarea del camino crítico, los podemos
clasificar en tres grandes grupos:
106
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
8. Bibliografía.
1. de Cos Castillo, M. Teoría general del proyecto. Editorial Sintesis.1995.
2. Cotterell, M, Hughes,B. Software project management. ITP (Thomson
Publishing Inc.) 1995.
3. Lock, D. Gestión de proyectos. Paraninfo, 1990.
4. Microsoft Press. Microsoft Project para windows 95 paso a paso.
McGraw-Hill 1995.
5. Page-Jones, M. Practical Projec Management. Dorset House, 1985.
6. DeMarco, Tom, Lister, Peopleware. Dorset House, 1987.
107
GESTIÓN DE PROYECTOS INFORMÁTICOS
108
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
6. EVALUACIÓN ECONÓMICA
DE PROYECTOS
1. INTRODUCCIÓN............................................................................................. 109
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.
109
GESTIÓN DE PROYECTOS INFORMÁTICOS
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.
110
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
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.
111
GESTIÓN DE PROYECTOS INFORMÁTICOS
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.
3.1 Ejemplo.
112
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
SOLUCIÓN
A 2A
B 1A
C 2A
D 1P
E 1A
F 4P
G 1A
H 2P
I 2P
J 2P
K 1P
MES: 1 2 3 4 5 6 7 8 9 10
Analistas 400 2 2.5 3 1 0.5
Programadores 200 2.5 4.5 3 2 2 1 1
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
113
GESTIÓN DE PROYECTOS INFORMÁTICOS
Hay una variable que no hemos en cuenta, esta es el valor del dinero.
Como hemos visto vamos pagando e ingresando dinero como consecuencia
del proyecto, pero se pueden sumar los importes en diferentes instantes del
tiempo. Planteando el problema de forma sencilla: ¿disponer de mil pesetas
hoy, tiene el mismo valor que disponerla dentro de un año? ¿Y dentro de dos
años?.
114
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
Fn Fn1 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 )
Fn Fn1 (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 )
Es decir, para mi, sería equivalente el disponer de 1.000 ptas. hoy o 1.200
ptas. dentro de un año.
115
GESTIÓN DE PROYECTOS INFORMÁTICOS
7000
6000
5000
4000
Pesetas
3000
2000
1000
0
0 1 2 3 4 5 6 7 8 9 10
Años
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).
7
Un ejemplo de interés calculado sería el T.A.E. de los bancos.
116
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
hace falta actualizar los flujos de caja al valor presente. Para ésto podemos
darle la vuelta a la formula y obtener el valor actual como:
P Fn (1 i ) n
Esta fórmula viene de:
Fn
Fn P(1 i ) n P Fn (1 i ) n
(1 i ) n
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.
117
GESTIÓN DE PROYECTOS INFORMÁTICOS
10000
8000
6000
Valor Actual
2000
0
1 2 3 4 5 6 7 8 9 10
-2000
10000
8000 Flujo Caja
6000
4000 Valor Actual
2000
0 Acumulado
-2000 1 2 3 4 5 6 7 8 9 10
-4000 Acumulado no
-6000 actualizado
-8000
Veamos para finalizar, que esta visión financiera puede modificar nuestro
punto de vista sobre los retrasos de un proyecto. Empezaremos con un
118
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
119
GESTIÓN DE PROYECTOS INFORMÁTICOS
120
EL PROYECTO: UNA FORMA DE ORGANIZAR EL TRABAJO
121