AADDMMIINNIISSTTRRAACCIIÓÓNN DDEE PPRROOYYEECCTTOOSS

EENN ÁÁRREEAASS DDEE DDEESSAARRRROOLLLLOO DDEE

SSOOFFTTWWAARREE

CCAARRAACCTTEERRIISSTTIICCAASS DDEE UUNN SSIISSTTEEMMAA IINNFFOORRMMAATTIICCOO

Buenos Aires, Argentina, 2010

___________________________________________________________________________

___________________________________________________________________________

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

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

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

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

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

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

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

• 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

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

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

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

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

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

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

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

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

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

• 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

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

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

• 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

• 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 conformidad para 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.

___________________________________________________________________________

___________________________________________________________________________

24

• PLANIFICACIÓN DE PRUEBA. Elaboración de un plan de trabajo para realizar la prueba del sistema.

• CASOS DE PRUEBA. Listado o planilla con datos para utilizar en el testing del sistema con todos los desenlaces posibles.

• RESULTADO DE PRUEBA. Planillas con los errores detectados en las pruebas.

• DDS – DOCUMENTO DE DISCONTINUIDAD DEL SOFTWARE. Documento donde se planifica la discontinuidad parcial o total de un sistema.

___________________________________________________________________________

___________________________________________________________________________

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