2. ___________________________________________________________________________
___________________________________________________________________________
2
Ejecución
Control
Planificación
Introducción
Qué es un Proyecto ? Que es la Administración o Gestión de Proyectos ?
De acuerdo a P.M.I. (Project Management Institute) un proyecto es un esfuerzo temporario
que se emprende para crear un producto o servicio único.
La Gestión de Proyectos comprende la definición, planificación, organización, dirección y
control de los recursos de la organización para cumplir con un objetivo determinado y de
relativo corto plazo, asignando personal a un proyecto.
Un detalle muy importante es que, al inicio del proyecto, se defina un objetivo claro, preciso,
realista y razonable de las necesidades que debe satisfacer el proyecto, así como las
restricciones bajo las cuales se ejecutará el proyecto, es decir, tiempo, costo y alcance.
El tiempo define la cantidad de tiempo para terminar el proyecto.
El costo se refiere a la cantidad presupuestada (recursos).
El alcance se relaciona con lo que hay que hacer, para satisfacer el objetivo planteado.
El resultado de balancear estos 3 elementos, configurarán las restricciones del proyecto.
Si todos o alguno de los elementos antedichos no se encuentran definidos o están mal
enunciados, el proyecto podría resultar incontrolable, y por lo tanto, las consecuencias
podrían ser que se termine pero que se hayan desvirtuado los propósitos originales o
sencillamente, sea cancelado.
El proceso de Gestión de Proyectos comprende las etapas
de Definición, Planeamiento, Ejecución, Control y,
Evaluación y Cierre, en ese orden.
En dicho proceso deberá existir una interacción continua
entre las etapas de Planeamiento, Ejecución y Control, lo
cual asegurará, en gran parte, que se cumpla el proyecto.
En el caso de un área de desarrollo de software, su acción
fundamental será la de producir sistemas informáticos.
Además, dicha área realiza el mantenimiento de dichos sistemas una vez puestos en
producción, es decir, se modifican el código de programación de las aplicaciones con el fin de
incorporar nuevas prestaciones o ajustar su funcionamiento, debido a la aparición de nuevas
necesidades, ya sean funcionales o por adecuación a nueva tecnología.
Una vez que se cuenta con la definición de los objetivos, alcances del proyecto y
restricciones, deberá realizarse la asignación de los recursos necesarios para la producción
del software.
3. ___________________________________________________________________________
___________________________________________________________________________
3
El personal técnico y profesional necesario en las áreas de desarrollo de software, deberá
dominar las herramientas adoptadas por la Organización para la elaboración de aplicaciones
informáticas, que, a su vez, deberán estar basadas en la tecnología y arquitectura de los
equipos de computación y bases de datos instalados.
Los perfiles del personal de dicha área deberían ser los siguientes: analistas funcionales,
analistas técnicos, planificadores, diseñadores de sistemas, diseñadores de bases de datos,
programadores, revisores o “testeadores” de la calidad del software.
Simultáneamente a la asignación de las tareas del proyecto, deberán ponerse en marcha los
mecanismos de seguimiento y control correspondientes. Estos mecanismos implicarán las
acciones necesarias para supervisar la tarea de los colaboradores y el avance del proyecto,
pudiendo utilizarse métodos, técnicas e instrumentos diversos, mediante los cuales se
conocerá si el proyecto se está llevando a cabo como se planeó y se definió.
Un sistema informático para ser una herramienta idónea para una administración eficiente de
los proyectos, debería tener como finalidad lo siguiente:
• Proporcionar información completa, precisa y oportuna sobre lo que se está
realizando.
• Facilitar la detección de los obstáculos que impiden el alcance de los objetivos, a fin
de poder actuar tempranamente sobre esos problemas, evitando riesgos y sorpresas
innecesarios en el desarrollo de las tareas.
• Mejorar la eficiencia y eficacia en el desarrollo de las tareas.
• Orientar al ordenamiento de tareas y a reglar la ejecución del proyecto.
• Permitir el registro de la documentación correspondiente, así como el archivo
electrónico de la misma y su acceso, a medida que avanza el proyecto.
• Asegurar la máxima productividad y el cumplimiento satisfactorio de los objetivos.
• Proporcionar información sobre la carga de trabajo.
• Proporcionar información histórica sobre los proyectos, en particular, para poder
evaluar el desempeño de los activos y el planeamiento de los futuros.
En las secciones siguientes, se describen las funciones principales y datos de un sistema
informático para poder realizar la administración de los proyectos de las áreas de desarrollo
de sistemas de computación.
Asimismo, las ideas vertidas sobre dicho sistema igualmente pueden ser válidas para áreas
que no sean de desarrollo de software, si se cambian las descripciones y definiciones de
determinados conceptos, como ser las de los proyectos y tareas, entre otros.
4. ___________________________________________________________________________
___________________________________________________________________________
4
Sistema informático para la administración de proyectos
Aspectos generales
El sistema deberá contener información de todos los proyectos asignados al área de
desarrollo, no iniciados, activos, cerrados y cancelados.
El ingreso de los datos deberá realizarse en tiempo real y cada integrante del área participará
con la información que corresponda a su accionar.
Esto asegurará que se cargue toda la información de un proyecto, el esfuerzo sea mínimo para
cada uno, los datos se aproximen bastante a lo sucedido y la incorporación de los mismos se
realice en un tiempo cercano a evento.
La información del sistema deberá acomodarse y accederse de forma tal que facilite la
detección de los inconvenientes que pueden afectar a los proyectos, específicamente, los
5. ___________________________________________________________________________
___________________________________________________________________________
5
alertas y avisos sobre las demoras relacionadas con las fechas de finalización prevista y los
tiempos estimados a dedicarles, revistan particular importancia.
También debería facilitar la verificación relacionada con los recursos necesarios y disponibles
para encarar cada proyecto, para poder conseguirlos o reasignarlos oportunamente.
Además, si el sistema permite el acceso a los distintos niveles involucrados, brindando la
información en concordancia con las posiciones o responsabilidades de cada persona, ello
aseguraría que los problemas se detecten enseguida y se actúe con presteza.
Por otro lado, la sistematización de la gestión de los proyectos y la participación de todos,
propiciará la estandarización de las tareas, pondrá orden en la ejecución del proyecto y
clarificará la relación entre las personas.
La apertura automática de ciertas tareas al iniciarse un proyecto, como ser la de Planificación,
Diseño Global y Definición Detallada, podría estar orientada a propiciar un ordenamiento del
mismo.
Asimismo, la inserción automática de la lista de los Documentos obligatorios a “entregar” al
término de las tareas, también producirá una normalización de los trabajos, en este caso la
elaboración de la documentación vinculada con el proyecto, elaborada a medida que se
avanza en el mismo.
Con respecto al registro y
almacenamiento
electrónico de los
documentos, conviene
destacar que, esta
característica como otras
de distinto tenor, harían
que la aplicación deje de
ser un puesto de
observación sobre lo que
pasa, sino que la
convierte en una
herramienta de trabajo
dentro de los grupos
dedicados a los proyectos,
integrándola a dichos
procesos.
6. ___________________________________________________________________________
___________________________________________________________________________
6
Lo antedicho significa que, en la organización, debería existir un elevado nivel de
informatización, o sea que, se disponga de PC en todos los sectores, la mayoría de las
comunicaciones internas se realicen por correo electrónico, se tenga acceso a Internet, y se
utilicen herramientas de creación de documentos y planillas de cálculo.
Además, debe existir una aceptación por parte de todos los integrantes con respecto a la
validez de dichos documentos.
La integración del sistema al proceso de los proyectos tendría otro significado que estaría
vinculado con la resistencia del personal a utilizarlo, reacción propia del ser humano, en
particular de los niveles de instrucción superior como los profesionales y técnicos, y que
podría destrabarse con su
asociación a los procesos de los
proyectos.
Con relación a este tema y antes de
comenzar a utilizar un sistema para
la gestión de los proyectos, debe
procederse con excesiva claridad,
transparencia y honestidad con las
personas que lo utilizarán,
fundamentalmente con las
explicaciones sobre las finalidades
perseguidas por el mismo, las
cuales, a mi entender, deberían estar
orientadas exclusivamente al
seguimiento y control de los
proyectos.
7. ___________________________________________________________________________
___________________________________________________________________________
7
Los proyectos terminados deben quedar en el sistema a fin de conformar una base de datos
histórica y, además, para mantener el archivo de la documentación correspondiente.
Esta historia permitiría extraer información sobre los ratios de los proyectos ya realizados,
servirán de base para la planificación de los nuevos a iniciar, permitirá revisar y dimensionar
la planta del personal según las dedicaciones observadas, se podría comparar con la
performance de los proyectos activos y verificar si la evolución de la efectividad del
desarrollo es positiva, en el tiempo.
Por otra parte, el hecho de disponer de una herramienta específica para la Administración de
los proyectos no obvia la utilización de otros mecanismos de gestión, como ser las reuniones
de trabajo o de evaluación, sino que, al contrario, dicho sistema los complementaría,
proveyendo de información que elevaría el nivel de calidad y discusión en las mismas.
Además, el hecho de contar con información sistémica de los proyectos realizados permitiría
que la evaluación del desempeño del personal se realice bajo un marco de objetividad, dado
que, dicho desempeño, se puede medir y cuantificar.
Con dicha evaluación y datos provistos por el sistema debería ser mas fácil ayudar al
desarrollo de la gente, potenciando las capacidades de cada uno de ellos, y, además,
favoreciendo su reconocimiento, motivación y elevando su autoestima.
Finalmente, los datos procesados por el sistema podrían servir de base para alimentar a otros
sistemas, como ser los de Planeamiento y de Control de Gestión para los niveles superiores o
Institucionales y viceversa.
Con relación a los aspectos técnicos, un sistema informático para la Gestión de Proyectos
debería diseñarse para que su procesamiento se haga utilizando redes de comunicaciones Wan
- Lan, en modalidad “on-line” y con bases de datos centralizadas.
Su arquitectura debería construirse para operar bajo la tecnología WEB, con un esquema
cliente-servidor.
Deberían definirse distintos roles o perfiles para diferenciar a las distintas necesidades de
información de los usuarios, y con tal finalidad, las vistas deberían programarse en función a
lo anterior, mostrándole, por ejemplo, a un Líder de proyecto solo los proyectos en los que
participa o participó y al Jefe del área todos los proyectos bajo su responsabilidad.
El acceso al sistema debería realizarse mediante usuarios con perfiles determinados,
autorizados mediante un LDAP de seguridad.
Asimismo, el sistema debería construirse de forma tal que la información se muestre de en
primera vista de manera global, amplia o resumida y, luego, ante acciones de selección por
parte del operador, se pueda ir descendiendo a niveles mas bajos, con un despliegue de los
datos a mayor detalle.
8. ___________________________________________________________________________
___________________________________________________________________________
8
Funcionalidad
Crear y modificar proyectos
Para la creación de un nuevo proyecto sería necesario cargar los siguientes datos:
• Descripción: Debería escribirse, en forma relativamente extensa, sobre los
objetivos y alcances del proyecto.
• Descripción corta: Se trata de un nombre abreviado o nemotécnico del
proyecto a los efectos de su utilización y reconocimiento en el lenguaje diario.
• Tipo de proyecto: Identifica la naturaleza del proyecto respecto a las tareas que
se realizarán, por ejemplo, si se trata de un nuevo sistema, una mejora a uno
existente, etc. Más abajo se dan, en una lista, los posibles tipos a utilizar.
• Prioridad: Debería señalarse el grado de urgencia que tiene el proyecto.
• Sistema: Debería colocarse la identificación del sistema sobre el cual el
proyecto impactará.
• Versión (opcional): Debería informarse la versión del sistema donde se
incluirán los desarrollos correspondientes al proyecto. Sirve para ordenar los
proyectos para igual sistema, con un orden de procedencia.
Al crearse un proyecto, el mismo
debería nacer con un estado de
ingresado pero no iniciado, sin
responsable asignado, sin la duración
(horas y fecha de fin) estimada, sin
hitos, sin identificar otros proyectos
encadenados o relacionados con este y
sin los documentos que originan el
proyecto.
Estos datos se colocarán, luego, en
módulos separados, justamente para
poder ingresar los proyectos
planificados y aún no definidos, de tal
forma que estén registrados en el
sistema.
En el proceso de modificación se deberían poder cambiar todos los datos antedichos,
incluyendo los relacionados con el responsable, duración del proyecto, estado, etc. y, además,
se deberían poder agregar la identificación y/o contenido digital de nuevos documentos
vinculados al proyecto.
Crear y modificar las tareas de un proyecto
Para un proyecto determinado se deberán ingresar todas las tareas a desarrollar para poder
cumplimentarlo.
Los datos iniciales para crear una nueva tarea serían:
9. ___________________________________________________________________________
___________________________________________________________________________
9
• Descripción: Será la definición resumida (si se agrega documento electrónico)
o amplia lo que hay que realizar.
• Tipo de tarea: Indica la índole del trabajo a hacer. En la sección “Valores y
explicación de los parámetros” se da una lista de los tipos posibles.
• Especificaciones (opcional): Se debería poder agregar un documento
electrónico con las
definiciones para la tarea.
Al igual que para un proyecto, la tarea se
crearía con estado de ingresado (implica
no iniciado), sin responsable asignado,
sin la duración estimada (horas y fecha
de fin), sin identificar otras tareas que
condicionan su realización (precedencia)
y sin colocarles los entregables que
deberá preparar el responsable de la
tarea a su término. Estos datos se
deberían colocar en instancias
independientes.
Por último, la modificación de una tarea,
debería ser similar a lo que se dice para proyectos.
Informar/archivar documentación relacionada con el proyecto
Tanto al inicio del proyecto como durante la vigencia activa del mismo debería poder
registrarse los datos relacionados con la documentación vinculada al proyecto (requerimiento
formal para realizar el proyecto, definiciones
funcionales, definiciones técnicas, minutas de
reunión, e-mail cursado, normas legales y
reglamentarias, etc.), inclusive, previendo subida
del documento electrónico respectivo, si se
cuenta con él.
Los datos a ingresar podrían ser el tipo de
documento, su número o identificación, fecha de
emisión y persona que firma.
Asignar responsable a los proyectos y tareas
Simplemente deberá ingresarse, para un proyecto o
tarea determinada, la identificación de la persona
designada responsable del mismo.
10. ___________________________________________________________________________
___________________________________________________________________________
10
Esta asignación debería comunicarse automáticamente y por sistema, mediante un e-mail al
responsable a los efectos de que el mismo lo asuma. Además, en las vistas del sistema
correspondientes la persona designada debería aparecer el proyecto o la tarea ordenada.
El cambio de responsable se hará de la misma manera y, en todos los casos, debería
archivarse en la base de datos, dicha modificación, conformando de esta manera, la historia de
los todos los responsables que tuvo el proyecto o la tarea, es decir, guardando el nombre,
fecha de inicio y fecha de fin, como mínimo, que se mostraría en un pantalla específica.
Ingresar la duración y la fecha de finalización estimada a proyecto y tareas
La primera vez que se ingresen estos datos, sencillamente se ingresarán según corresponda,
un proyecto o una tarea.
Sin embargo, cuando sea necesario
ajustarlos, debido a demoras o cambio de
planes, los nuevos valores deberían
ingresarse conjuntamente con un motivo o
justificación de dicho cambio. Dichos
ajustes, para ser efectivos, deberían ser
autorizados por el responsable inmediato
superior.
El responsable de autorizar dichos ajustes,
debería evaluar dichas solicitudes y
registrar, en el sistema, su aprobación o
rechazo.
En todos los casos, al igual que el caso del ítem anterior, el sistema debería llevar un registro
de lo sucedido y su exhibición cuando se requiera.
Efectuar cambios de estado de proyecto y tarea
Los estados del proyecto y de las tareas deberán ir cambiándose en función de la evolución
del mismo.
A los efectos de que dicha
modificación se realice, el
sistema debería “obligar”
esa situación.
Por ejemplo, no podría
pasar a estado “en
ejecución” si aún no fue
asignado a un
responsable. Otro caso
sería que no pueda darse
por terminado un
proyecto si hay tareas sin
cerrar.
11. ___________________________________________________________________________
___________________________________________________________________________
11
Como siempre, el sistema debería llevar el registro de todos los cambios y reversiones
realizados.
Marcar los hitos del proyecto
Para un proyecto determinado podrían marcarse todos sus hitos, dicho de otra manera, colocar
señales relacionadas con logros
importantes a alcanzar en determinada
fecha, lo cual facilita el monitoreo del
mismo, en forma más global y sin
necesidad de tener que estar
familiarizado con el proyecto, como
puede ser es el caso de un comité de
directores.
Este registro y control se podría realizar
mediante la creación de tareas
especificas (de tipo “Hito”) las cuales,
al cerrarse, daría por cumplido el hito.
Al cumplirse un hito, el sistema,
automáticamente, debería disparar un
aviso a todos los responsables e
interesados que se determine.
Además, deberían existir reportes referidos al cumplimiento de los hitos y atrasos detectados,
y conformar para todos los proyectos un tablero de control global.
Otros proyectos relacionados.
Existen organizaciones donde la actividad de Testing está separada de la de Desarrollo y,
además, está asignada a un área específica de Control de Calidad.
En esta situación y con el fin de deslindar las responsabilidades respectivas, deberían
registrarse estas actividades en proyectos separados. Sin embargo, el sistema de
Administración de Proyectos debería permitir el tratamiento de ambos, en forma individual,
para facilitar las operatorias de las áreas y, también, de modo unificado para que todos los
niveles de responsabilidad involucrados puedan visualizar y controlar el avance del proyecto
integralmente.
Al respecto, dicho sistema podría tener una funcionalidad que le permita al área de Control de
Calidad vincular, obligatoriamente, su proyecto de testing al correspondiente de desarrollo.
Además, al establecer esta vinculación, las comunicaciones (idas y vueltas para corregir
errores detectados) podrían automatizarse mediante el uso de los e-mail programados
enviados según sea el estado de las tareas “Pase a Testing” y “Pase a Desarrollo”, adjuntando
los archivos electrónicos de la documentación correspondiente.
12. ___________________________________________________________________________
___________________________________________________________________________
12
Administrar los entregables de cada tarea
Para cada tarea deberían indicarse cuales son los entregables exigibles al responsable de la
misma.
Esto significa que, por ejemplo, si se solicitó la programación de una funcionalidad para un
sistema, además, de la realización de ella, podría pedírsele que elabore la documentación
técnica respectiva.
Además, el responsable de la tarea no debería cerrar definitivamente la tarea sino que haría un
“cierre provisorio” y sería el líder del proyecto quién, después de las revisiones
correspondientes, cerraría la tarea.
La totalidad de la documentación incorporada ya sean requerimientos, otros documentos,
especificaciones y entregables, compondrán la documentación del proyecto. Dicha lista
debería exhibirse en reportes especiales y, cuando exista la copia electrónica, que pueda
abrirse y leerse por pantalla.
Fijar las precedencias de las tareas
Este módulo debería permitir
realizar el registro de las relaciones
de precedencia de las tareas.
Para poder señalar estas relaciones,
podría informarse, en cada tarea, si
su inicio esta condicionado a que
otra se encuentre iniciada,
terminada o que no tenga
restricciones para realizarse.
El registro de las precedencias
correspondientes deberá generar los alertas necesarios en el momento oportuno, a los efectos
de la intervención que corresponda.
Además, debería servir para construir el diagrama de red del proyecto, calcular la duración
total e identificar el camino crítico.
13. ___________________________________________________________________________
___________________________________________________________________________
13
Imputar las horas aplicadas y avance a las tareas asignadas
Los responsables de tareas deberán con la periodicidad que se establezca (sería recomendable
que sea diario)
informar en el sistema
la dedicación aplicada
a cada una, indicando,
además, el porcentaje
de avance alcanzado a
la fecha.
La pantalla donde se
carguen las
imputaciones a tareas
debería diseñarse de
tal manera que facilite
el descargo y evite
que se deba salir y
entrar reiteradas veces
para ver datos de la
misma y los
descargos previos
realizados. Además,
en esta instancia, debería facilitarse la subida de los entregables exigibles, en el caso de que se
este informando la terminación de la misma.
Alertas
El sistema debe generar alertas a fin de avisar a los usuarios de algunas anormalidades,
Desvíos o avisos de intervenciones de instancia superior.
Las mismas deberían estar incorporadas en las pantallas del sistema, como ser las apariciones
de semáforos o el resaltado de las líneas a considerar.
Otro tipo de alerta deberá producirse en forma externa al sistema, como ser, por ejemplo,
mediante la generación de e-mail destinados a los responsables correspondientes.
Con respecto a esto último, ésta podría ser la mecánica para generar las comunicaciones
respecto a los ajustes de la duración de proyectos y tareas, cambios de estado, asignación de
responsables, etc.
Reportes programados
El sistema debería considerar tanto la
generación de aquellos reportes
considerados directos o simples,
como ser, listado de los proyectos
activos asignados a un responsable
14. ___________________________________________________________________________
___________________________________________________________________________
14
como de aquellos que requieran una lógica o elaboración más compleja, tal como aquel que
dé, por ejemplo, el tiempo dedicado por cada persona, a tareas de mantenimiento, que fueron
terminadas entre determinadas fechas y para un sistema en particular.
Deberían existir reportes con las siguientes características:
• Orientados a los Proyectos y a las Tareas.
• Detalle general y particular.
• Agrupados o resumidos por determinada variable.
• Carga horaria aplicada.
• Ajustes de duración realizados.
• Atrasos detectados.
• Hitos cumplidos y atrasados.
• Orientados a la actividad sobre los Proyectos y Tareas.
• Detalle diario y agrupado por responsable, de las horas dedicadas.
• Carga de horas faltante a Tareas.
• Inactividades producidas.
• Productividad comparativa de responsables.
Indicadores
Los indicadores deberían considerar, fundamentalmente, los informes relacionados con la
productividad y el avance y estado de los proyectos activos.
15. ___________________________________________________________________________
___________________________________________________________________________
15
En ese sentido, se sugieren reportes o cuadros relacionados con los desvíos tanto en proyectos
como en tareas, activos y terminados, relacionando lo estimado originalmente con lo actual,
ya sea en horas y fechas.
Gráficos y bajadas de archivos con información
El sistema debería prever que determinados reportes, cuya información se presente agrupada o
resumida, en forma matricial, pueda mostrarse gráficamente como ser circular, barras,
histograma, etc.
Estos gráficos podrían ser útiles para poder observar más claramente la distribución de
determinadas variables registradas en el sistema. Por ejemplo, podría analizarse la proporción
de tiempo dedicado según la tarea realizada (análisis, programación, testing, etc.), y servir de
base para dimensionar los recursos del área de desarrollo.
Otra variante podría sería la de generar el diagrama de GANTT de un proyecto determinado,
lo cual podría programarse dentro del sistema o generarse un archivo para descargar en la PC
que, luego, se ingresaría en algún de los programas específicos preparados para tal fin.
Respecto de la obtención de archivos, además, debería considerarse la generación de las
extensiones PDF y CSV, para determinados listados y reportes obtenidos por sistema.
Búsquedas
Debería existir un módulo de búsquedas rápidas o puntuales de determinados elementos
registrados en el sistema, en particular, de aquello vinculado con documentos que tienen que
ver con áreas externas o usuarias.
16. ___________________________________________________________________________
___________________________________________________________________________
16
Sistemas: Descripción y Datos Técnicos.
La información relacionada con cada sistema, sobre los cuales se desarrolla, podría estar
registrada en esta aplicación y mostrarse en Reportes especiales o en particular desde un
proyecto que se dedicó a su desarrollo o mantenimiento.
Los datos a registrar podrían ser:
• Datos funcionales.
• Datos Técnicos.
• Información sobre los responsables informáticos y funcionales.
• Areas usuarias.
• Fechas de inicio de operaciones y de discontinuidad del sistema.
Acceso al sistema
Al ingresar al sistema el usuario operador deberá tener definido un perfil, el cual definirá el
alcance de su gestión. Dicho perfil podrá contener lo siguiente:
• Identificación del operador.
• Acciones autorizadas al operador a realizar.
• Áreas de Trabajo autorizadas a ingresar.
Estos datos deberían ser permanentes mientras dure su sesión de trabajo.
17. ___________________________________________________________________________
___________________________________________________________________________
17
Además, tanto la información a visualizar y como acciones a realizar por el operador debería
estar restringida o según sea el perfil asignado y, además, sería recomendable que la pantalla
de inicio o ingreso sea la que represente la acción principal del operador.
Por ejemplo, para un líder de proyecto podría aparecer solo la lista de sus proyectos, para un
programador la pantalla con sus tareas activas (o la de carga de las imputaciones horarias
diaria) y, para el CIO, podría mostrarse una página con la lista de sus áreas dependientes y
algunos datos resumiendo de actividad de cada una.
Ayudas del sistema
El sistema deberá tener un apartado donde deberán estar los Manuales de Usuario y otros
Instructivos que se vayan emitiendo, los cuales deberían dividirse en Generales y propias del
área donde está ubicado el usuario (para el caso en que haya mas de un área utilizando el
aplicativo)
18. ___________________________________________________________________________
___________________________________________________________________________
18
Resumen de la información procesada en el sistema
Datos relacionados con un proyecto
• Número del Proyecto
• Descripción corta del Proyecto (Nemotécnico)
• Descripción larga
del proyecto.
• Tipo de proyecto.
• Prioridad del
Proyecto.
• Sistema.
• Área responsable.
• Fecha de inicio.
• Fecha de
Finalización
prevista (o real, si
esta terminado).
• Duración
estimada del
Proyecto en
Horas.
• Ajustes realizados
a la duración
estimada y/o
fechas de fin, con
fechas y motivos.
• Responsable actual.
• Responsables anteriores y motivos del reemplazo.
• Estado del proyecto.
• Datos sobre el requerimiento o Inicio del proyecto.
• Hitos del proyecto.
• Documentación electrónica relacionada con el Proyecto.
• Otros Proyectos encadenados al presente.
• Tareas definidas para el proyecto.
Datos relacionados con una tarea
• Número de Tarea.
• Descripción de la Tarea.
• Tipo de Tarea.
• Fase (agrupador de tipos de tarea).
• Prioridad de la Tarea.
• Fecha de Inicio.
• Fecha de Finalización prevista (o real).
19. ___________________________________________________________________________
___________________________________________________________________________
19
• Duración estimada de la Tarea en Horas.
• Ajustes realizados a la duración estimada y/o fechas de fin, con fechas y
motivos.
• Realizado hasta la Fecha en Horas.
• Avance en Porcentaje.
• Responsable actual.
• Responsables
anteriores y motivos
del reemplazo.
• Estado de la Tarea.
• Condicionamiento de
Precedencia de la
Tarea.
• Documentación
electrónica
relacionada con las
definiciones.
• Documentación
electrónica con lo
realizado
(entregables).
• Detalle de la Carga
horaria de lo realizado
en la Tarea.
Datos relacionados con las imputaciones horarias a las tareas
• Cantidad de Horas realizadas para una Tarea en una fecha determinada.
• Porcentaje de avance total de la Tarea a una fecha determinada.
20. ___________________________________________________________________________
___________________________________________________________________________
20
Valor y explicación de los parámetros
Los valores que se explicitan a continuación se orientan a proyectos de desarrollo de software
y, los mismos, deberían residir en la base de datos y el código debería utilizarlos de acuerdo al
usuario y rol que se defina. A tal fin el sistema tendría que contemplar funciones de
Administración, las cuales permitirían el mantenimiento de los mismos.
La prevención de dichos aspectos permitiría actuar con rapidez, sin necesidad de modificar el
código de programación, lo cual facilitaría notablemente su mantenimiento, posibilitando,
entre otras cosas, tener configuraciones distintas para diferentes áreas.
Tipos de proyectos
• MANTENIMIENTO: apunta a modificar el software que se encuentra en
entorno de producción Involucra la corrección de errores, entendidos como una
desviación de la especificación, tanto en el diseño como la programación.
• MEJORA FUNCIONAL: involucra la adaptación de un sistema, por
reemplazo o agregado de
funcionalidad.
• MEJORA TECNICA: Involucra
la adaptación de un sistema por
tareas de optimización técnica o
cambios en el entorno
tecnológico, manteniendo la
misma funcionalidad.
• NUEVO DESARROLLO: se
refiere al desarrollo de un nuevo
sistema.
• DESARROLLO BREVE: se
aplica a nuevos desarrollos de
mejoras funcionales de escasa
duración (no más de 21 horas de
dedicación total)
• CAPACITACION: incluye
asistencia a cursos, tareas de
auto capacitación y tutoría técnica para el aprendizaje de otros.
• REVISION DE CALIDAD: engloba las actividades que se realizan para
asegurar que el software construido cumpla con los requerimientos funcionales
y no funcionales.
21. ___________________________________________________________________________
___________________________________________________________________________
21
Tipos de tarea
• ANÁLISIS DEL REQUERIMIENTO: análisis de los requerimientos en el
contexto de desarrollos breves.
• ASISTENCIA A CURSOS: cursos de capacitación, demos, presentaciones,
etc.
• AUTOCAPACITACIÓN: lectura de manuales, seguimiento de tutórales,
práctica sobre herramientas técnicas, con el fin del autoaprendizaje.
• ELABORACIÓN DE MANUALES: construcción de manuales de usuario,
tutórales, etc.
• ELABORACIÓN DEFINICIÓN TÉCNICA DETALLADA: transformación
de la definición global en una especificación detallada, que posibilite la
construcción de software.
• ESQUEMA Y DEFINICIÓN GLOBAL: Definición de funcionalidades a nivel
detallado y del diseño global del software, desarrollo formal de la arquitectura
a utilizar, la descripción de la estructura modular del sistema y de los modelos
conceptuales y de datos.
• EXPLOTACIÓN DE INFORMACIÓN: proceso realizado para la obtención de
datos, desde el ambiente de producción, y elaboración para su presentación en
algún formato viable para el usuario.
• HOMOLOGACIÓN CON USUARIOS: demostración y pruebas con el área
definidora, que culmina con la conformidad del usuario.
• HITO: para aquellas tareas "falsas" que se utilicen para señalar el
cumplimiento de una etapa importante.
• INVESTIGACION: tarea de capacitación en el marco de un proceso de
desarrollo y destinado exclusivamente al propósito del proyecto en cuestión.
• OPERACIÓN TÉCNICA: engloba una serie de tareas del tipo de generación
de backup, instalación de ejecutables en PC, análisis de conectividad, etc.
• PASE A CONTROL DE CALIDAD: armado de la documentación y del
software para el área de Control de Calidad.
• PASE A DESARROLLO: armado de documentación y reporte de errores para
la vuelta del software revisado, al sector de Desarrollo.
• PLANIFICACIÓN Y SEGUIMIENTO: cubre la planificación global y
detallada del proyecto de desarrollo informático y el seguimiento y control del
mismo. Es una Tarea que se realiza transversalmente a las etapas de definición,
diseño, construcción e implementación y se ejecuta durante las mismas.
• PREPARACIÓN DE AMBIENTES: instalación del software de base, creación
/ exportación de tablas y todo lo necesario para generar un nuevo ambiente de
desarrollo.
• PREPARACIÓN PARA BAJA DEL SISTEMA: acciones para llevar a cabo el
retiro del sistema de producción.
• PREPARACIÓN PASE A PRODUCCIÔN: armado de la documentación
necesaria y del software para su instalación en el ambiente de producción;
incluye la interacción con todas las áreas involucradas.
• PROGRAMACIÓN: creación de objetos de la base y creación y prueba de
piezas de software en función de la tecnología elegida.
• PRUEBA FUNCIONAL: planificación de escenarios para la prueba, con casos
y resultados esperados.
• PRUEBA TÉCNICA: prueba de los aspectos técnicos de un sistema (tiempos
de respuesta, uso de índices, consumo de recursos, etc.).
22. ___________________________________________________________________________
___________________________________________________________________________
22
• PUESTA EN PRODUCCIÓN: engloba las actividades necesarias para la
puesta efectiva en producción de un sistema o una mejora al mismo.
• RECEPCIÓN DESDE CONTROL DE CALIDAD: análisis de los resultados
de las pruebas realizadas por el sector control de calidad y administración de
los eventuales cambios.
• RECEPCIÓN DESDE DESARROLLO: recepción de la documentación y
software enviado y administración de recursos para la homologación.
• RELEVAMIENTO Y ANÁLISIS: tarea tendiente a formalizar un proyecto de
desarrollo, planificar sus fases y delinear la solución informática.
• REUNIÓN CON USUARIOS: incluye las reuniones con áreas usuarias y
definidoras y la elaboración de la minuta correspondiente.
• TUTORÍA TÉCNICA: supervisión del proceso de aprendizaje de otro
integrante del área.
Fases de proyectos
• DEFINICIÓN Cubre desde el planteo de una necesidad de solución
informática, hasta la formalización de la decisión de iniciar un proceso de
desarrollo.
• DISEÑO: Cubre las actividades del relevamiento de las necesidades,
especificación de la funcionalidad, análisis y diseño global de la solución.
• CONSTRUCCIÓN: Cubre las actividades de programación y pruebas de
calidad del software, culminando con la homologación del software producido.
• IMPLANTACIÓN: cubre la planificación y ejecución de las actividades
necesarias para la puesta efectiva en producción de un sistema.
• DISCONTINUIDAD DEL SISTEMA: Cubre la planificación y ejecución de
las actividades para retirar el sistema del ambiente de producción.
• SIN FASE: Para proyectos de Capacitación y de Mantenimiento.
Estados del proyecto
• INGRESADO. Proyecto aún no iniciado.
• EN EJECUCIÓN. Proyecto activo y en marcha.
• CON CIERRE PROVISORIO. Proyecto terminado pero sin el visto de la
Jefatura.
• CERRADO. Proyecto terminado definitivamente, en condición de cumplido.
• ANULADO. Proyecto cerrado sin haber dedicado tiempo al mismo.
• SUSPENDIDO. Proyecto paralizado pero para reanudar más adelante.
• CANCELADO. Proyecto terminado sin haber cumplido sus objetivos y con
tiempos dedicados al mismo.
Estado de la tarea
• INGRESADA. Tarea aún no iniciada y sin asignar.
• EN EJECUCIÓN. Tarea activa y en marcha.
• CON CIERRE PROVISORIO. Tarea terminada pero sin la conformidad del
Líder.
• CERRADA. Tarea terminada y cumplida.
• ANULADA. Tarea cerrada sin haberse dedicado tiempos.
• SUSPENDIDA. Tarea paralizada pero para reanudar próximamente.
23. ___________________________________________________________________________
___________________________________________________________________________
23
• CANCELADA. Tarea cerrada sin cumplimentar y con tiempos dedicados.
Tipos de documentos exigibles por tarea (entregables)
• DAP – DOCUMENTO DE PASE A PRODUCCIÓN. Documento para
especificar la puesta efectiva en producción del sistema.
• DGS – DISEÑO GLOBAL DEL SOFTWARE. Documento para explicitar la
arquitectura a utilizar, describir la estructura modular del sistema, los
ambientes y estándares de desarrollo, la interacción con otros sistemas, el
modelo conceptual y el modelo de datos.
• DIP – DOCUMENTO DE INICIO. Documento donde se formaliza el proyecto
y planifica sus fases y los recursos necesarios. Se describen las características
generales del proyecto.
• DOCUMENTO DE CONFORMIDAD DEL USUARIO. Documento donde se
especifican las pruebas de homologación efectuadas por los usuarios y su
c
o
n
f
o
r
m
i
d
a
d
p
a
ra proceder a la implementación en ambiente de producción.
• DPP – DOCUMENTO PRELIMINAR. Documento donde se expone el
problema o necesidad del negocio y se describe su solución informática.
• ERS – ESPECIFICACIÓN DE REQUERIMIENTO DE SOFTWARE.
Documento para especificar detalladamente los requerimientos del área
usuaria.
• ESPECIFICACIÓN DETALLADA DEL SOFTWARE. Definición técnica de
cada pieza de software a construir.
• IFS – INFORME DE FINALIZACION DE SOFTWARE. Documento para
especificar la configuración de la versión del software y las instrucciones para
poner en disponibilidad de producción dicha versión del sistema.
• INFORME. Documento que contiene las novedades respecto a un tema
particular.
• INFORME TÉCNICO. Documento conteniendo explicaciones técnicas sobre
algún aspecto del sistema.
• LISTADO DE LO CONSTRUIDO. Detalle de lo realizado en al tarea.
• MINUTA DE REUNION. Documento resumen de lo tratado en una reunión de
trabajo relacionada con la tarea o proyecto.
25. ___________________________________________________________________________
___________________________________________________________________________
25
Contenido
• Introducción, 2
• Sistema informático para la administración de proyectos, 4
§ Aspectos generales, 4
§ Funcionalidad, 8
Crear y modificar proyectos, 8
Crear y modificar las tareas de un proyecto, 8
Informar/archivar documentación relacionada con el proyecto, 9
Asignar responsable a los proyectos y tareas, 9
Ingresar la duración y la fecha de finalización estimada a proyecto y
tareas, 10
Efectuar cambios de estado de proyecto y tarea, 10
Marcar los hitos del proyecto, 11
Informar proyectos relacionados (testing), 11
Administrar los entregables de cada tarea, 12
Fijar las precedencias de las tareas, 12
Imputar las horas aplicadas y avance a las tareas asignadas, 13
Alertas, 13
Reportes programados, 13
Indicadores, 14
Gráficos y bajadas de archivos con información, 15
Búsquedas, 15.
Sistemas: Descripción y Datos Técnicos, 16
Acceso al sistema, 16
Ayudas del sistema, 17.
• Resumen de la información procesada en el sistema, 18
§ Datos relacionados con un proyecto, 18
§ Datos relacionados con una tarea, 18
§ Datos relacionados con las imputaciones horarias a las tareas, 19
• Valor y explicación de los parámetros, 20
§ Tipos de proyectos, 20
§ Tipos de tarea, 21
§ Fases de proyectos, 22
§ Estados del proyecto, 22
§ Estado de la tarea, 22
§ Tipos de documentos exigibles por tarea (entregables), 23
