i universidad para la cooperacion internacional propuesta …
TRANSCRIPT
i
i
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL
(UCI)
PROPUESTA DE UNA METODOLOGÍA PARA LA ADMINISTRACIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE PARA APLICACIÓN EN
DEPARTAMENTOS DE TECNOLOGÍA DE INFORMACION
ANDREA ELIZONDO AGUILAR
PROYECTO FINAL DE GRADUACION PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR POR EL TITULO DE MASTER EN ADMINISTRACION DE
PROYECTOS.
San José, Costa Rica
Marzo, 2009
ii
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)
Este Proyecto Final de Graduación fue aprobado por la Universidad como Requisito parcial para optar al grado de Master en Administración de Proyectos
__________________________ Ing. Yorlen de los Ángeles Solís Araya, MAP
PROFESOR TUTOR
_________________________ Ing. Alberto Jiménez Ch, MAP
LECTOR No.1
__________________________ Ing. Juan Carlos Carmona, MAP
LECTOR No.2
________________________ Andrea Elizondo Aguilar
SUSTENTANTE
iii
DEDICATORIA
A Dios padre celestial que me ha dado tanto.
A mi familia que continuamente me han apoyado en mis proyectos de vida.
iv
AGRADECIMIENTOS
A todos los compañeros de la MAP-59 y en especial a Alejo Jiménez, con quien siempre forme equipo de trabajo.
A Yorlen Solís, por sus recomendaciones y apoyo brindado durante esta última fase de
universidad.
A Johnathan Alfaro, jefe gracias!
v
ÍNDICE DE CONTENIDO
DEDICATORIA ................................................................................................................ iii AGRADECIMIENTOS ..................................................................................................... iv ÍNDICE DE ABREVIATURAS.......................................................................................... ix RESUMEN EJECUTIVO...................................................................................................x 1.-INTRODUCCIÓN ........................................................................................................ 1
1.1 Antecedentes.......................................................................................................... 1 1.2 Problemática (u oportunidad) que da origen al PFG. ............................................. 2 1.3 Justificación del proyecto........................................................................................ 4 1.4 Objetivos................................................................................................................. 5
1.4.1 Objetivo general................................................................................................ 5 1.4.2 Objetivos específicos........................................................................................ 6
2. -MARCO TEÓRICO..................................................................................................... 7
2.1 Marco referencial .................................................................................................... 7 2.1.1 Tecnología de la información en las organizaciones ........................................ 7 2.1.2 Tecnología de la información y software .......................................................... 8 2.1.3 ¿Qué es un sistema de información? ............................................................... 8 2.1.4 Ciclo de vida de los sistemas de información (CVDS)...................................... 9 2.1.5 ¿Qué son requerimientos de software?.......................................................... 10
2.2 Marco de administración de proyectos ................................................................. 11
2.2.1 ¿Qué es un proyecto? .................................................................................... 11 2.2.2 Ciclo de vida de los proyectos ........................................................................ 12 2.2.3 Gestión de proyectos y procesos ................................................................... 12 2.2.4 Áreas de conocimiento de los proyectos ........................................................ 14
3. -MARCO METODOLÓGICO ..................................................................................... 16
3.1 Tipo de investigación............................................................................................ 16 3.2 Herramientas y técnicas para la investigación...................................................... 16
3.2.1 Juicio de experto............................................................................................. 16 3.2.2 Revisión documental ...................................................................................... 17 3.2.3 Diagramas de flujo.......................................................................................... 17
3.3 Herramientas y técnicas de administración de proyectos..................................... 17
4. -METODOLOGÍA ADMINISTRACIÓN DE PROYECTOS DESARROLLO DE SW .. 18
4.1 Guía general de la metodología ........................................................................... 18 4.1.1 Generalidades ................................................................................................ 18 4.1.2 Composición................................................................................................... 19
vi
4.2. Propuesta Metodológica para Proyectos de Desarrollo de Software................... 20
4.2.1 Marco metodológico ....................................................................................... 20 4.2.2 Formulación del proyecto. .............................................................................. 21 4.2.3 Planificación del proyecto. .............................................................................. 31 4.2.4 Control y seguimiento del proyecto................................................................. 44 4.2.5 Cierre del proyecto ......................................................................................... 52 4.2.6 Formularios que permiten documentar las actividades del proyecto .............. 56
5. -CONCLUSIONES..................................................................................................... 69 6. -RECOMENDACIONES ............................................................................................ 71 7. -BIBLIOGRAFÍA ........................................................................................................ 73 8.-ANEXOS ................................................................................................................... 74
Anexo Nº 1 Plan de proyecto final de graduación....................................................... 74 Anexo Nº 2 Estructura detallada de trabajo (EDT) ..................................................... 78 Anexo Nº 3 Cronograma del Proyecto Final de Graduación....................................... 79 Anexo Nº 4 Integración de los Elementos de la Metodología ..................................... 82
vii
ÍNDICE DE FIGURAS
Figura Nº 1. Ejemplo de un organigrama de un Departamento de Tecnología ..................7 Figura Nº 2. Ciclo de vida de los proyectos ............................................................................12 Figura Nº 3. Procesos de la Administración de los proyectos ............................................13 Figura Nº 4. Nueve áreas de conocimiento de los proyectos ..............................................14 Figura Nº 5. Fase de Formulación de Proyectos ...................................................................21 Figura Nº 6. Actividades de la Identificación de Proyectos ..................................................23 Figura Nº 7. Informe del Estudio de Viabilidad .......................................................................27 Figura Nº 8. Flujo del Proceso de Formulación de Proyectos .............................................30 Figura Nº 9. Fase de Planeación de Proyectos......................................................................31 Figura Nº 10. Modelo de la Estructura Detallada de Trabajo...............................................32 Figura Nº 11. Proceso Planificación de las Actividades del Proyecto ................................34 Figura Nº 12. Estructura Organizacional para la Administración de Proyecto ..................37 Figura Nº 13. Proceso Planificación de los Recursos Humanos del Proyecto..................38 Figura Nº 14. Proceso de Planificación de los elementos de desarrollo del SW ..............42 Figura Nº 15. Flujo del Proceso de Planificación de Proyectos...........................................43 Figura Nº 16. Fase de Control y Seguimiento de Proyectos ................................................44 Figura Nº 17. Actividades de la Administración Efectiva de Cambios ................................46 Figura N° 18. Flujo del Proceso de Seguimiento y Co ntrol de Proyectos..........................51 Figura N° 19. Fase de cierre de proyectos ..............................................................................52
viii
ÍNDICE DE CUADROS
Cuadro Nº 1. Errores clásicos del desarrollo de software................................................ 4 Cuadro Nº 2. Validación de las características de los requerimientos........................... 29 Cuadro Nº 3. Roles y responsabilidades ....................................................................... 36 Cuadro N° 4. Elementos de la Implantación del Siste ma .............................................. 41
ix
ÍNDICE DE ABREVIATURAS AP Administración de Proyectos CVDS Ciclo de Vida del Desarrollo del Software DERCA Documento de Especificación de Requerimientos y Criterios de Aceptación EDT Estructura de Desglose de Trabajo HW Abrevia la palabra Hardware PMI Siglas en inglés del Instituto de Administración de Proyectos (Project
Management Institute) PMBOK Project Management Body Of Knowledge PFG Proyecto Final de Graduación RUP Siglas en inglés de Proceso Unificado de racional (Rational Unified
process) SW Abrevia la palabra Software TI Tecnología de la Información
x
RESUMEN EJECUTIVO En la actualidad la mayoría de las empresas cuentan con sistemas de información, que proporcionan de forma más eficiente y eficaz, llevar a cabo la operativa propia de sus áreas de negocios y apoyo, igualmente se fortalecen los procesos de toma de decisiones de la alta gerencia. Debido a esto, se demuestra que las tecnologías de información se convierten día con día en un factor clave para el desarrollo de las organizaciones. Para nadie es un secreto que la informática han ido evolucionando junto con las organizaciones y a medida que se han ido produciendo cambios tecnológicos de acuerdo a la era. En este entorno de cambio constante la administración en general de la informática ha dejado de lado la gestión adecuada de los proyectos de desarrollo de software y se ha puesto sencillamente en muchos casos a producir sistemas sin tomar en consideración la planificación, control y seguimiento de los mismos y a la vez incurriendo en errores clásicos. Adicionalmente en los proyectos de desarrollo de software existen fases o actividades que son propias de este campo y son parte del ciclo de vida del sistema: levantamiento de requerimientos, análisis, diseño, programación, pruebas e implementación. El objetivo general del presente proyecto es realizar una propuesta de una metodología de administración de proyectos de desarrollo de software para aplicación en departamentos de tecnología, orientada en los procesos de formulación, planificación, control y seguimiento y cierre y que a la vez permita estandarizar este proceso a lo interno de la organización que lo aplique. Está solución práctica sobre proponer una metodología para los proyectos de desarrollo de software, incluirá las mejores prácticas que incluye el Project Management Institute (PMI) en el Project Management Body Of Knowledge (PMBOK), logrando una interrelación con los conceptos propios del Ciclo de Vida del Desarrollo de los Sistemas (CVDS). Es decir, la propuesta permitirá conseguir que las fases del ciclo de vida se encuentren concebidas dentro de las actividades de la administración del proyecto y viceversa. Igualmente se pretende plantear una alternativa que provea al informático de instrumentos destinados a evitar las deficiencias en la administración de proyectos. A la vez se promoverá la disminución de errores clásicos, ya que el informático no se concentrará solamente en las áreas técnicas y descuidará las actividades relacionadas a la gestión del proyecto, sino que tomará la metodología como herramienta que lo
xi
guiará, para que el desarrollo de software pueda ser llevado a cabo de manera ordenada y eficiente en el manejo de los procesos que ejecuta. El impacto que se espera que tenga esta metodología sobre la organización que la aplique, es que le permita mejorar el rendimiento y desempeño general al simplificar los procesos de manera tal que cada miembro del equipo de trabajo se encuentre enterado de los pasos a seguir para cada proceso. Adicionalmente, ofrecer a los Profesionales en Informática el uso de técnicas de Administración de proyectos, a través de la aplicación de actividades que se integrarán con las fases tradicionales del desarrollo de software que permitan la implementación de procesos para dar un adecuado seguimiento de los proyectos, creando una asociación entre las fases típicas del desarrollo de sistemas y las actividades relacionadas con las áreas del conocimiento. Las áreas de conocimiento involucradas en esta propuesta son: la Gestión del Alcance, Tiempo, Recursos Humanos, Calidad, Comunicación e Integración. En cuanto al tipo de investigación desarrollada se fundamentó en una investigación documental y esencialmente se basó en el criterio experto que se ha acumulado profesionalmente por la autora del presente proyecto de graduación. Finalmente, los resultados del desarrollo de los objetivos propuestos demuestran que sí es posible enmarcar el desarrollo de sistemas dentro de un contexto de la administración de proyectos.
1
1.-INTRODUCCIÓN
1.1 Antecedentes
Según Cleland e Ireland (2001) “Los orígenes de la administración de proyectos se
remontan a la antigüedad y están presentes en las reliquias de los diversos periodos
históricos”. Ello es cierto; no obstante, es hasta mediados del siglo XX que empieza
a tomar auge como una ciencia propiamente dicha, una ciencia de futuro al
presentarse ante las organizaciones como una opción de gestión sistemática en esta
materia.
En otro contraste, las organizaciones han evolucionado desde estructuras
mecanicistas a flexibles para poder hacer frente a un medio ambiente externo muy
cambiante y orientado al cliente. La informática ha ido cambiando tanto
tecnológicamente, como también para apoyar la transformación, ya mencionada, en
las organizaciones.
Los proyectos de informática han ido evolucionando junto con las organizaciones y a
medida que se han ido produciendo cambios tecnológicos. En este entorno de
cambio constante la administración en general de la informática ha dejado de lado la
gestión adecuada de los proyectos de desarrollo de software y se ha puesto
sencillamente en muchos casos a producir sistemas sin tomar en consideración la
planificación, control y seguimiento de los mismos y a la vez incurriendo en errores
clásicos.
Esto radica especialmente en que el profesional de informática es entrenado
académicamente para conceptualizar los componentes técnicos que darán forma a
un sistema de información.
Debido a esto, es común que sucedan problemas cuando el profesional de
informática se orienta más a las ramas técnicas que a las administrativas,
provocando que se le reste valor a las actividades de planeación y control. Dando
2
como problemática el surgimiento de proyectos con mala definición del alcance,
planeación insuficiente, ausencia de controles
Todo proyecto entraña la necesidad de resolver un problema, ya se trate de una
barrera que impide avanzar o de una oportunidad para hacer algo mejor en una
organización, pero el recurrir a situaciones inefectivas como los errores clásicos,
provocan que un proyecto de desarrollo de software se convierta en una gran
dificultad.
El punto de partida para una solución práctica es la metodología del proyecto. Con la
correcta metodología, el desarrollo de software en un área de tecnología
determinada podrá desempeñarse de manera ordenada y ser mucho más
conveniente de manejar.
Asimismo, permitirá que el desarrollo del software y la administración del proyecto
como tal no se vean separadas si no que se puedan ver relacionadas tanto las
mejores prácticas que incluye el PMI como los conceptos propios del ciclo de vida
de los sistemas.
1.2 Problemática (u oportunidad) que da origen al P FG.
En nuestros días, cuando los recursos son limitados, y la oportunidad con la que se
ofrezcan, a los clientes nuevos, productos y servicios, puede ser la diferencia entre
permanecer en el mercado o desaparecer. La figura del proyecto se ha consolidado
como un mecanismo para convertir, en realidad, muchos de los aspectos en la visión
de una empresa reflejados en su planificación estratégica. Se puede afirmar que los
proyectos se originan y desarrollan por dos motivos; en primer lugar, con el fin de
aprovechar una oportunidad de negocio; y, en segunda instancia, para resolver
alguna problemática o dificultad que se esté experimentando en la compañía.
3
Los proyectos cuestan esfuerzo, tiempo y dinero; por eso, deben definirse y llevarse
a cabo tanto para representar una mejora sustancial en la empresa, como con el
objetivo de cumplir con sus expectativas de calidad, costo y tiempo. El cumplimiento
de estos objetivos es básico, y fundamental, para determinar si un proyecto fue
exitoso o no.
Los proyectos informáticos no escapan a estas características. En primer lugar,
deben resultar exitosos y aportar una herramienta para el negocio. Por esto, y a
razón de la responsabilidad inherente a la utilización de recursos, la organización
requiere asegurarse de que aquellos proyectos emprendidos contarán con las
condiciones necesarias para salir avante.
El problema que acontece con los proyectos de desarrollo de software y que
provoca que no lleguen a ser exitosos, es que continuamente son gestionados por
Profesionales que son expertos en la materia técnica pero, que debido a su
formación académica descuidan las condiciones administrativas en las que se
desenvuelven los proyectos de este tipo.
Esto se manifiesta por ejemplo cuando en las etapas de planeación de los sistemas
de información no se invierte el tiempo necesario para planificar el proyecto, porque
la costumbre es observar que el personal ejecute prontamente las labores técnicas
como programación, administración de bases de datos y configuración de equipos.
En el mundo laboral se exige que los ingenieros en sistemas produzcan rápidamente
y que inicien prontamente con funciones al frente de un computador, pero se
descuida fuertemente la planeación lo cual trae consigo las debilidades relacionadas
con las áreas de conocimiento alcance, tiempo y calidad.
Por este motivo acontece frecuentemente en los proyectos la ocurrencia de errores
clásicos, que de acuerdo a Steve McConell (1997) se clasifican en personas,
procesos, producto y tecnología. A continuación se enumeran algunos errores
clásicos para cada clasificación:
4
Cuadro Nº 1. Errores clásicos del desarrollo de software
Personas Procesos
⇒⇒⇒⇒ Añadir más personal a un proyecto
atrasado.
⇒⇒⇒⇒ Expectativas poco realistas.
⇒⇒⇒⇒ Falta de participación de los
implicados.
⇒⇒⇒⇒ Planificación excesivamente
optimista o insuficiente.
⇒⇒⇒⇒ Diseño inadecuado.
⇒⇒⇒⇒ Abandono de la planificación bajo
presión
⇒⇒⇒⇒ Pérdida de tiempo en el inicio
difuso.
Producto Tecnología
⇒⇒⇒⇒ Mala definición de requerimientos
⇒⇒⇒⇒ Exceso de requerimientos.
⇒⇒⇒⇒ Cambios excesivos en
requerimientos.
⇒⇒⇒⇒ Sobreestimación sobre las
ventajas de una nueva
herramienta.
⇒⇒⇒⇒ Cambiar de herramienta a mitad
del proyecto.
Estos errores clásicos se pueden considerar como situaciones inefectivas, que son
elegidas por los involucrados de un proyecto de desarrollo de software con el fin de
concluirlo lo más pronto posible.
Ante esta problemática se considera que los líderes de TI por lo general no le
prestan mucha importancia a todos los aspectos que involucra la gestión de un
proyecto y recurren frecuentemente a estos errores clásicos que provocan la
insatisfacción o el fracaso del proyecto.
1.3 Justificación del proyecto
Los motivos por los cuales se plantea este proyecto de graduación obedecen a un
principio de estandarizar los procesos que realizan las áreas de desarrollo de
sistemas de las organizaciones, mejorándolos de paso para hacerlos más efectivos,
5
que permitan optimizar los recursos organizacionales, dadas las actividades
funcionales que deben realizar quienes participan de los proyectos como ejecutores
del mismo. Además, también está estrechamente relacionado con el costo de
oportunidad de sacar los proyectos en el menor tiempo posible y de la
competitividad que ello puede significar para el negocio.
De lo que se trata es de proponer un método sencillo, que le permita a los
departamento de Tecnología de la información evitar incurrir en los errores clásicos
de los desarrollos de software y cimentar las bases para ir desarrollando una cultura
en torno a la administración de proyectos con herramientas sencillas y considerando
aspectos elementales para obtener resultados exitosos acorde con las necesidades
y expectativas de las áreas organizacionales relacionadas.
Lo que se pretende es generar una metodología que le permita a las áreas
tecnológicas recibir como resultados esperados los siguientes:
⇒⇒⇒⇒ Mejor definición del alcance de los proyectos.
⇒⇒⇒⇒ Mayor uniformidad en el uso y manejo de la información.
⇒⇒⇒⇒ Control más oportuno y eficaz de los proyectos.
⇒⇒⇒⇒ Estandarización de la información y formatos.
1.4 Objetivos
1.4.1 Objetivo general
Realizar una propuesta de una metodología de administración de proyectos de
desarrollo de software para aplicación en departamentos de tecnología, orientada en
los procesos de formulación, planificación, control y seguimiento y cierre y que a la
vez permita estandarizar este proceso a lo interno de la organización que lo aplique.
6
1.4.2 Objetivos específicos
⇒⇒⇒⇒ Definir una metodología que permita administrar de forma adecuada los procesos
de inicio, planificación, control y seguimiento y cierre de los proyectos para la
implementación de proyectos de desarrollo de software.
⇒⇒⇒⇒ Definir las técnicas y herramientas más adecuadas para planificar y controlar de
modo efectivo los proyectos de desarrollo de software.
⇒⇒⇒⇒ Diseñar un conjunto de formatos que permitan documentar las principales
actividades del proyecto desarrollo de software para respaldar cada acción y
todos los documentos utilizados de forma estandarizada.
7
2. -MARCO TEÓRICO
2.1 Marco referencial
2.1.1 Tecnología de la información en las organizac iones
El presente Proyecto Final de Graduación consiste en una metodología para
proyectos de desarrollo de software para ser aplicada en departamentos de
Tecnología de la Información que forman parte de alguna organización, en donde
cumplen un papel de servicio de cara a las solicitudes de los usuarios (clientes
internos de la entidad).
Los departamentos de Tecnología de la Información son un área de apoyo donde
tiene por objetivo el brindar un servicio que permita a la organización resolver una
dificultad o bien para desarrollar una oportunidad de negocio. Existen diferentes
estructuras organizacionales dependiendo principalmente del tamaño de la
institución o empresa donde se ubican.
Figura Nº 1. Ejemplo de un organigrama de un Departamento de Tecnología
8
Es importante señalar que en las estructuras organizaciones de TI debe prevalecer
un principio de seguridad que trata sobre la segregación de funciones en los
colaboradores que laboran para una unidad de Tecnología, lo cual supone que cada
función en un área debe ser desempeñada por una persona diferente, por ejemplo
un programador solo desarrolla aplicaciones y no debe ejercer actividades propias
de base de datos porque debe existir un Administrador de base de datos que las
realice.
Lo anterior evita que una sola persona pueda ser responsable de funciones diversas
y críticas, asimismo que se cometan errores o apropiaciones indebidas. En
empresas pequeñas, deben existir controles compensatorios o internos que
permitan reducir esta debilidad y que ayudan a mitigar el riesgo de no tener esta
segregación.
2.1.2 Tecnología de la información y software
Las tecnologías de la información abreviado TI, son las tecnologías que se
encuentran relacionadas con la administración del procesamiento computarizado de
los datos.
En cuanto al termino software, se le conoce así a todos los componentes
intangibles de una computadora, es decir, al conjunto de programas y
procedimientos que se necesitan para realizar tareas específicas.
2.1.3 ¿Qué es un sistema de información?
Es el medio por el cual los datos fluyen de una persona o departamento hacia otros
y puede ser cualquier cosa, desde la comunicación interna entre los diferentes
componentes de la organización y líneas telefónicas hasta sistemas de cómputo que
generan reportes periódicos para varios usuarios. (Senn, 1992).
9
2.1.4 Ciclo de vida de los sistemas de información (CVDS)
El método del ciclo de vida para el desarrollo de sistemas es el conjunto de
actividades que los analistas, diseñadores y usuarios realizan para desarrollar e
implantar un sistema de información.
De acuerdo con Senn (1992), el ciclo de vida para el desarrollo de sistemas consta
de las siguientes actividades:
⇒⇒⇒⇒ Investigación preeliminar: Esta actividad tiene tres partes:
o Aclaración de la solicitud: La solicitud de proyecto debe examinarse para
determinar con precisión lo que el solicitante desea.
o Estudio de factibilidad: La determinación de que el sistema solicitado sea
factible técnica, económica y operacionalmente.
o Aprobación de la solicitud: No todos los proyectos solicitados son
deseables o factibles.
⇒⇒⇒⇒ Determinación de los requerimientos del sistema: Los analistas al trabajar con los
empleados deben estudiar los procesos de una organización para dar respuesta
a estas preguntas:
o ¿Qué es lo que se hace?
o ¿Cómo se hace?
o Frecuencia
o Existe algún problema
o Grado de eficiencia requerido
⇒⇒⇒⇒ Diseño del sistema: Produce los detalles que establecen la forma en la que el
sistema cumplirá con los requerimientos identificados en la fase de análisis.
⇒⇒⇒⇒ Desarrollo del software: Es producir los requerimientos que fueron analizados y
posteriormente diseñados.
10
⇒⇒⇒⇒ Prueba de los sistemas: El sistema se emplea de manera experimental para
asegurarse que el software no tenga fallas y que funcione de la forma en que se
definieron las especificaciones.
⇒⇒⇒⇒ Implantación y evaluación: Proceso de verificar e instalar nuevo equipo, entrenar
a los usuarios, instalar la aplicación y construir todos los archivos de datos para
utilizarla.
2.1.5 ¿Qué son requerimientos de software?
Según Senn (1992) un requerimiento es una condición o necesidad de un usuario para
resolver un problema o alcanzar un objetivo, los cuales se pueden clasificar en:
⇒⇒⇒⇒ Funcionales: Definen las funciones, tareas o comportamientos específicos de un
sistema, el cual realiza una transformación específica en las entradas para
producir salidas.
⇒⇒⇒⇒ No funcionales: Definen las restricciones, limitantes y otros atributos de calidad
que se asignan a la tarea o comportamiento del sistema.
Las características de un requerimiento son sus propiedades principales:
⇒⇒⇒⇒ Necesario: Si su omisión provoca una deficiencia en el sistema a construir, y
además su capacidad, características físicas o factor de calidad no pueden ser
reemplazados por otras capacidades del producto.
⇒⇒⇒⇒ Conciso: Si es fácil de leer y entender. Su redacción debe ser simple y clara para
aquellos que vayan a consultarlo en un futuro.
⇒⇒⇒⇒ Completo: Si no necesita ampliar detalles en su redacción, es decir, si se
proporciona la información suficiente para su comprensión.
⇒⇒⇒⇒ Consistente: Si no es contradictorio con otro requerimiento.
⇒⇒⇒⇒ No ambiguo: Tiene una sola interpretación, el lenguaje usado en su definición, no
debe causar confusiones al lector.
11
⇒⇒⇒⇒ Verificable: Puede ser cuantificado de manera que permita hacer uso de los
siguientes métodos de verificación: inspección, análisis, demostración o pruebas.
2.2 Marco de administración de proyectos
2.2.1 ¿Qué es un proyecto?
Un proyecto es “Un conjunto de esfuerzos temporales, dirigidos a generar un producto o
servicio único”, (Chamoun, 2002). Se considera que un proyecto es exitoso en el tanto
logre, según este autor “Cumplir los objetivos de tiempo, costo y calidad, a satisfacción
del cliente y de los involucrados clave al mismo tiempo que desarrollamos relaciones a
largo plazo con proveedores y demás integrantes del equipo”.
Un proyecto también se puede definir como un esfuerzo que posee las siguientes
características (Gido & Clements, 2003):
1. Tiene un objetivo: Se tiene un alcance definido y se busca cumplir con algún
nivel de calidad en la consecución del objetivo.
2. Tiene tareas independientes: El proyecto se desarrolla mediante una serie de
tareas independientes que deben ejecutarse en cierto orden.
3. Utiliza recursos: Para su desarrollo, un proyecto puede necesitar personas,
materiales, organizaciones, edificaciones, entre otros.
4. Es temporal: El esfuerzo tiene una fecha de inicio y una fecha de fin. El proyecto
se cierra cuando alcance sus objetivos o el momento en que el proyecto se
decida cancelar pues se sabe que no alcanzará sus objetivos.
5. Es único: El producto, servicio o resultado que se busca alcanzar es único.
6. Tiene un cliente: Alguna persona o entidad, que puede o no pertenecer a la
organización que desarrolla el proyecto.
7. Tiene un grado de incertidumbre: No todas las variables involucradas en el
proyecto son conocidas desde el inicio.
12
2.2.2 Ciclo de vida de los proyectos
El ciclo de vida de un proyecto define las fases que conecta el inicio de un proyecto con
su fin, quedando íntimamente relacionado con el ciclo de vida del producto. Esto quiere
decir que el ciclo del proyecto puede considerarse contenido dentro de las fases de
vigencia del producto.
Asimismo, los grupos de procesos de administración de proyectos no son discretos, o
eventos únicos; son actividades que se traslapan en varios niveles de intensidad a
través de cada fase del proyecto.
La Figura Nº 2 ilustra como los grupos de procesos se traslapan y varían dentro de una
fase.
Figura Nº 2. Ciclo de vida de los proyectos
2.2.3 Gestión de proyectos y procesos
La ciencia de la dirección de proyectos genera la plataforma necesaria para hacer
posible un manejo planificado y controlado de los mismos. El Project Management
Institute, abreviado PMI (2004) la define como “…la aplicación de una serie de
conocimientos, habilidades y técnicas a las actividades del proyecto para satisfacer los
requisitos del mismo”.
13
La dirección de proyectos se logra a través de la integración de cinco grandes conjuntos
de procesos a lo largo del proyecto (Chamoun, 2002):
⇒⇒⇒⇒ Inicio: incluye el establecimiento de los objetivos del proyecto, justificación,
restricciones y limitaciones.
⇒⇒⇒⇒ Planificación: establece las estrategias que se desarrollarán para cumplir con los
objetivos.
⇒⇒⇒⇒ Ejecución: realiza las actividades planificadas.
⇒⇒⇒⇒ Control: compara lo realizado contra lo planeado para detectar y corregir
desviaciones.
⇒⇒⇒⇒ Cierre: consta de cierre administrativo (control de cambios y lecciones
aprendidas) y cierre contractual (recibidos conforme del contrato, pagos a
proveedores).
La integración de estos cinco procesos se especifica en la siguiente figura:
Figura Nº 3. Procesos de la Administración de los proyectos
14
2.2.4 Áreas de conocimiento de los proyectos
En el transcurso de los procesos de la gestión de proyectos, se utilizan técnicas o
herramientas que de acuerdo con el PMI (2004) define nueve grandes áreas de
conocimiento que cruzan estos procesos. Se supone que deben estar presentes en la
gestión de proyectos, la mayoría de las veces; pero depende de factores como
complejidad, costo, tiempo e impacto, acatarlas o prescindir de alguna de ellas. Estas
nueve áreas del conocimiento de los proyectos se mencionan a continuación y son
expuestas mediante la Figura Nº 4:
⇒⇒⇒⇒ Gestión del alcance
⇒⇒⇒⇒ Gestión del tiempo
⇒⇒⇒⇒ Gestión del costo
⇒⇒⇒⇒ Gestión de la calidad
⇒⇒⇒⇒ Gestión de los recursos humanos
⇒⇒⇒⇒ Gestión de las comunicaciones
⇒⇒⇒⇒ Gestión de los riesgos
⇒⇒⇒⇒ Gestión de las adquisiciones
⇒⇒⇒⇒ Gestión de la integración
Figura Nº 4. Nueve áreas de conocimiento de los proyectos
15
Todas estas son importantes, pero siempre hay unas que muestran mayores signos de
deficiencia, quizás aunado a una cultura organizacional del área de Sistemas que
padece de síntomas de inercia, que dificultan la gestión de los proyectos de manera
efectiva y tienda a optimizar los recursos que se disponen.
En virtud de lo anterior, el presente trabajo se enfoca únicamente en las siguientes
áreas de conocimiento:
⇒⇒⇒⇒ Alcance: delimitación de lo que se quiere lograr.
⇒⇒⇒⇒ Tiempo: actividades que deben ser realizadas para alcanzar el objetivo
planteado.
⇒⇒⇒⇒ Calidad: qué y cómo cumplir con los requisitos del cliente, realización de pruebas
que confirmen que el producto corresponde con la solicitud del proyecto.
⇒⇒⇒⇒ Recursos Humanos: incluye los procesos que organizan y dirigen el equipo,
asignación de roles y responsabilidades.
⇒⇒⇒⇒ Integración: contempla las características de unificación y consolidación que son
importantes para concluir satisfactoriamente el proyecto y cumplir con los
requerimientos establecidos.
⇒⇒⇒⇒ Comunicación: recopilar y distribuir información sobre el rendimiento. Esto
incluye informes de estado, reuniones de seguimiento que permitan la medición
del progreso.
16
3. -MARCO METODOLÓGICO
3.1 Tipo de investigación
La técnica de investigación que se empleó en el presente trabajo fue del tipo
documental, cuyo método está centrado en la recopilación de datos existentes.
Asimismo, la metodología que se ha propuesto hace uso de un método analítico-
sintético, debido a que se descompone la totalidad de la metodología en elementos
simples, examinando y desarrollando cada uno de estos de forma individual.
3.2 Herramientas y técnicas para la investigación La información recopilada y analizada en la investigación a través de las fuentes de
datos se utilizó para construir una metodología para proyectos de desarrollo de software
que permita integrar cinco de las áreas de conocimiento, los procesos de la
administración de proyectos y el ciclo de vida del desarrollo de los sistemas.
Se pretende que luego de la aplicación de este Proyecto Final de Graduación en algún
proyecto, el individuo reconozca los beneficios de la misma para su organización y
unidad tecnológica.
Por tal razón al existir tanta diversidad de proyectos de desarrollo de software, el
alcance de este proyecto no abarca la demostración de los beneficios en un proyecto
real, ya que el desarrollo de un caso específico podría ocasionar que el PFG se enfoque
hacía un tipo de proyecto particular y la idea es que sea una metodología que abarque
los proyectos de sistemas de manera general.
3.2.1 Juicio de experto
De manera importante se contó con el uso del juicio experto en las áreas de
administración de proyectos de tecnología de información, debido a la experiencia de la
17
autora en el campo del desarrollo de software y participación en proyectos de esta
índole.
3.2.2 Revisión documental
La revisión documental fue indispensable para obtener la información necesaria para
tener un panorama de las mejores prácticas que existen sobre el desarrollo de software
y la administración de proyectos.
3.2.3 Diagramas de flujo
Se utilizó como elemento de análisis de los procesos y para documentar de forma
gráfica los procedimientos que se establecieron en la metodología.
3.3 Herramientas y técnicas de administración de pr oyectos
A raíz de que el objetivo primordial ha sido crear una propuesta metodológica para
proyectos desarrollo de software, se hizo referencia a las mejores prácticas existentes
para la administración de proyectos y para el desarrollo de software.
Las principales fuentes consideradas para el desarrollo de este Proyecto Final de
Graduación son:
⇒⇒⇒⇒ El PMBOK como referencia primaria para la información de las áreas básicas de
la metodología de administración de proyectos.
⇒⇒⇒⇒ El método del Ciclo de Vida para el Desarrollo de Sistemas, como complemento
importante para integrar cada fase del mismo en correspondencia con las etapas
de Administración de Proyectos de la metodología propuesta.
18
4. - METODOLOGÍA PARA LA ADMINISTRACIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE
4.1 Guía general de la metodología
4.1.1 Generalidades
La administración de proyectos implica primero el proceso de establecer un plan y
después implementarlo para lograr el objetivo del proyecto. Tomarse el tiempo para
desarrollar un plan bien concebido es vital para la realización con éxito de cualquier
proyecto.
Por lo anterior, se puede definir que el desarrollo de un sistema de información es un
proyecto desafiante que requiere una planeación completa y un control total para
asegurar que el sistema cumpla con los requisitos del usuario y se termine a tiempo y
dentro del presupuesto.
Por tal motivo, el presente documento cumple con ser una herramienta para que los
directores de proyectos de desarrollo de software y los equipos de Tecnología,
gestionen los proyectos de manera que a lo interno de la organización puedan
capitalizar el conocimiento, ordenar y sistematizar la forma como se administran estos.
El enfoque de está metodología se encuentra basado en una solución práctica sobre la
propuesta de una metodología para los proyectos de desarrollo de software, la cual
incluye las mejores prácticas que contempla el Project Management Institute (PMI) en el
PMBOK y a la vez logrando una interrelación con los conceptos propios del Ciclo de
Vida del Desarrollo de los Sistemas (CVDS).
Es decir, el CVDS está conformado por un conjunto de fases o pasos que se deben
completar durante el curso de un proyecto de desarrollo de software, la propuesta
permitirá visualizar que estas fases se encuentren concebidas dentro de los procesos y
áreas de conocimiento de la administración de proyectos desarrollada en esta
propuesta metodológica.
19
4.1.2 Composición
Esta propuesta metodológica para la administración de proyecto de desarrollo de
software se compone de la siguiente estructura:
⇒⇒⇒⇒ Marco metodológico básico para la gestión de proyectos: Conceptos elementales
de la Administración de Proyectos y aclaración de la Audiencia a la cual se dirige
la metodología.
⇒⇒⇒⇒ Fases de la metodología: Son las siguientes secciones que se encuentran
ordenadas de acuerdo a su proceso de aplicación.
o Formulación de proyectos
o Planificación de proyectos
o Control y seguimiento de proyectos
o Cierre de proyectos
⇒⇒⇒⇒ Formatos que permiten documentar la gestión del proyecto: Para cada uno de
estos se efectuó una breve explicación de los campos que lo comprenden. La
idea es evidenciar las principales actividades del proyecto desarrollo de software
para respaldar cada acción de forma estandarizada.
Asimismo, se establece una relación entre las fases del Ciclo de vida del desarrollo
de sistemas y las actividades concernientes con las áreas del conocimiento de la
Administración de Proyectos utilizadas en este PFG. La idea que se persigue es
brindar mediante esta metodología el uso de técnicas de AP, a través de una serie
de actividades adicionales que se integran a las fases tradicionales del desarrollo de
sistemas.
Para describir esta situación se ilustra en el Anexo N° 4 la interacción desarrollada
entre los principales elementos de la metodología.
20
4.2. Propuesta Metodológica para Proyectos de Desar rollo de Software
4.2.1 Marco metodológico
Audiencia De aplicación en Departamentos de Tecnología de la Información, específicamente el
área de Desarrollo de Software de una organización pública o privada.
Definiciones
¿Qué es un proyecto?
Es el conjunto de actividades coordinadas y controladas con fechas de inicio y fin que
se realizan para lograr un objetivo de conformidad con requerimientos específicos,
incluyendo problemas de tiempo, costo, calidad y alcance.
¿Qué es administrar un proyecto?
Es la aplicación de conocimientos, capacidades, herramientas y técnicas en las
actividades de un proyecto con el fin de cumplir con las metas o superarlas; la
responsabilidad general del proyecto pertenece al patrocinador del mismo.
¿Cuáles son las fases de un proyecto?
⇒⇒⇒⇒ Inicio: incluye el establecimiento de los objetivos del proyecto, justificación,
restricciones y limitaciones.
⇒⇒⇒⇒ Planificación: establece las estrategias que se desarrollarán para cumplir con los
objetivos.
⇒⇒⇒⇒ Ejecución: realiza las actividades planificadas.
⇒⇒⇒⇒ Control: compara lo realizado contra lo planeado para detectar y corregir
desviaciones.
⇒⇒⇒⇒ Cierre: consta del cierre administrativo del proyecto.
21
4.2.2 Formulación del proyecto.
Introducción
Los proyectos que se formulen en un área de Tecnología deben estar en perfecta
alineación con la estrategia del negocio, en armonía con los objetivos planteados en el
Plan Estratégico de la organización y en concordancia con la legislación que regule las
actividades de la empresa.
Una vez corroborado que el proyecto responde al logro de la estrategia organizacional y
se encuentra de acuerdo a la legislación propia de sus funciones, se debe iniciar
declarándolo de manera formal y dimensionando las características y especificaciones
que debe cumplir el producto de software que se desarrollará; así como también, todo el
trabajo que debe ser realizado para alcanzar el objetivo formulado.
De esta manera, la fase de formulación del proyecto se compone de las siguientes sub
fases:
a) Identificación
b) Alcance
b.1 Estudio de viabilidad
b.2 Definición de requerimientos
Figura Nº 5. Fase de Formulación de Proyectos
INICIO
Identificación
Alcance
Definir requerimientos
Estudiar viabilidad
22
a) Identificación del proyecto
Especificar la necesidad, oportunidad o idea del proyecto, qué es lo
que se espera obtener, el objetivo a lograr, el impacto que generará y
los entes organizacionales externos e internos que estarán
involucrados en el mismo.
En una organización esta iniciativa debe ser realizada por el área del Negocio para ser
trasladada al Área de Desarrollo de Software. Para tales efectos, se completa el
formulario “FOR-01 Identificación del proyecto” (ver sección 4.2.6 de formularios) con
todos los datos que se solicitan.
Es importante indicar que este documento con su aprobación obtiene un carácter de
formalidad en el proyecto, porque le permite al área de Negocios solicitar sus
requerimientos para poder responder a los objetivos institucionales planteados en el
Plan Estratégico. Es por tal razón que la formulación de proyectos se convierte en una
pieza fundamental para que la organización permanezca competitivamente en el
mercado y apostar por estrategias exitosas que consientan en el logro de las metas.
El representante del Área de Desarrollo de Software recibe el documento de
Identificación del proyecto y se debe reunir con el Patrocinador y con el Líder por parte
del área que solicitó el proyecto, junto con el especialista técnico del producto de
software. A partir de este momento estas personas conformarán el “Comité Ejecutivo
del Proyecto”, cuyo papel principal es la toma de decisiones alrededor del mismo y cada
reunión que se efectúe debe quedar documentada en el formulario FOR-07 Minuta del
Proyecto.
La reunión de inicio se realiza con el fin de revisar y analizar el documento “FOR-01
Identificación del proyecto” y resolver sobre el mismo, sometido a su consideración para
ser aprobado, denegado o pospuesto.
Esta actividad de acordar un acuerdo en el inicio de un proyecto debe ser realizada de
conformidad con la contribución que puede dar el proyecto al logro de las estrategias, al
cumplimiento de regulaciones y de acuerdo con el presupuesto.
Propósito
23
Si el acuerdo tomado es aprobar el proyecto se procede con las siguientes decisiones:
⇒⇒⇒⇒ Asignar prioridad al proyecto.
⇒⇒⇒⇒ Nombrar un Líder del proyecto por la parte del negocio.
⇒⇒⇒⇒ Asignar Líder del área de Desarrollo de Software.
⇒⇒⇒⇒ Autoriza que se proceda con la realización del Alcance del proyecto.
⇒⇒⇒⇒ Valorar si es necesario un estudio de viabilidad.
En los casos donde se posponen proyectos, se debe archivar el documento de
identificación y asignar la posible fecha de estudio y si es rechazado se justifican las
razones de la decisión.
Las actividades que se debe llevar a cabo en la sub fase de Identificación se
especifican en la siguiente figura:
Figura Nº 6. Actividades de la Identificación de Proyectos
Sí
Pospone
Actor1Solicitan
Llena formulario FOR-01
Actor1 Actor1Actor1Reunión TI
Envía Revisión y análisis de documento
AApprruueebbaa Rechaza
Indica fecha posible y archiva
Archiva previa justificación
Asigna Responsable y equipo de trabajo. Asigna prioridad. Autoriza inicio del alcance del proyecto. Define si se requiere un estudio de viabilidad
24
b) Alcance del proyecto
Asegurar que se incluyan las especificaciones requeridas para
satisfacer las necesidades, mediante la dimensión de las
características y funcionalidades del producto de software a
desarrollar.
Mediante la definición del alcance se identifican las metas, objetivos y entregables que
tiene la iniciativa del negocio.
En esta sub fase se deben considerar los siguientes elementos:
⇒⇒⇒⇒ Una descripción (lo más detallada y precisa) de las características,
funcionalidades, especificaciones y requisitos que debe poseer el producto de
software.
⇒⇒⇒⇒ Los límites del proyecto (lo que incluye y lo que no incluye), los criterios de
aceptación y cualquier elemento que pueda afectar o restringir al proyecto.
⇒⇒⇒⇒ Los objetivos del proyecto - beneficios.
⇒⇒⇒⇒ La definición de los principales entregables y criterios de aceptación.
⇒⇒⇒⇒ Estrategia (alinear a TI con el negocio).
Es primordial indicar que esta actividad es indispensable para esclarecer la necesidad
de efectuar el proyecto y con un desarrollo adecuado se producirá un producto final
satisfactorio, de lo contrario se corre el riesgo de generar insatisfacción, reprocesos y
atrasos por la frecuente incorporación de cambios.
El entregable de esta actividad es el documento FOR-02 “Alcance del proyecto” (ver
sección 4.2.6 de formularios) y deben participar los líderes tanto del Negocio como del
Área de Desarrollo de Software. Una vez finalizado el documento de Alcance, el
Director del Proyecto, procederá la realización del estudio de viabilidad (en los casos
aprobados por la reunión de inicio) y se debe llevar a cabo la definición de los
requerimientos, que permiten detallar las especificaciones por parte del usuario.
Propósito
25
b.1) Estudio de viabilidad
Se refiere a la realización de un análisis más detallado del proyecto y debe realizarse si
el documento de Identificación del Proyecto analizado en la reunión de inicio indica la
necesidad de efectuarse Su propósito es obtener información técnica, operacional y
económica, que permita evaluar el nuevo proyecto y emitir un criterio sobre su
viabilidad.
El estudio de viabilidad se realiza mediante el registro del FOR-03 “Estudio de
viabilidad”, y es efectuado por parte del Líder del Negocio que determina la viabilidad
económica y operacional y el Líder del Área de Desarrollo de Software que especifica
la viabilidad técnica del proyecto.
A continuación se describe qué debe contener cada una de las partes del estudio de
viabilidad:
Viabilidad Técnica:
El objetivo es analizar las diferentes alternativas técnicas que existen para llevar acabo
el proyecto, ya sea que se realice internamente o se contrate externamente. Debe
contener lo siguiente:
⇒⇒⇒⇒ Alternativas de solución, ventajas y desventajas
⇒⇒⇒⇒ Recomendación mejor opción.
⇒⇒⇒⇒ Responder la interrogante: ¿El proyecto puede realizarse con el equipo actual, la
tecnología existente y el personal disponible?
⇒⇒⇒⇒ Se debe evaluar los siguientes aspectos:
o Los recursos necesarios para que el proyecto brinde los resultados
esperados.
o La posibilidad de adquirir nuevos equipos.
o La capacidad de los equipos actuales (si los hubiese).
o El crecimiento y su repercusión en los equipos actuales.
26
o La garantía de exactitud, confiabilidad, facilidad de acceso y seguridad
que proporciona el equipo actual (si existiera), o en su defecto, el equipo
propuesto.
Viabilidad Operacional:
El objetivo es determinar si operacionalmente el producto a desarrollar podrá ponerse
en operación eficazmente. Debemos respondernos las siguientes preguntas:
⇒⇒⇒⇒ ¿Quién es la oficina responsable?,
⇒⇒⇒⇒ ¿Existirá resistencia al cambio por parte de los usuarios?
⇒⇒⇒⇒ ¿Cuáles son las implicaciones que se puedan presentar en otras áreas, por el
nuevo producto?
⇒⇒⇒⇒ ¿Cuales son las entradas o insumos (información) para el nuevo proyecto?
⇒⇒⇒⇒ ¿Qué procesos involucra el nuevo proyecto?
Viabilidad Económica:
Un nuevo proyecto debe ser considerado por la organización como una buena
inversión. Debemos responder las siguientes preguntas:
⇒⇒⇒⇒ ¿Los beneficios que se obtienen serán suficientes para aceptar los costos?
⇒⇒⇒⇒ ¿Los costos asociados con la decisión de no realizar el proyecto, son tan
elevados que se debe rechazar el proyecto?
⇒⇒⇒⇒ ¿Se cuenta con los recursos económicos para realizarlo?
Se deberán identificar claramente los siguientes aspectos:
⇒⇒⇒⇒ El costo de la investigación del desarrollo del producto o servicio.
⇒⇒⇒⇒ El costo del equipo y del desarrollo para el proyecto propuesto.
⇒⇒⇒⇒ La disminución de errores que representan costos muy altos.
⇒⇒⇒⇒ La reducción de costos operativos.
27
⇒⇒⇒⇒ Los beneficios que se obtendrán.
Por lo tanto, será necesario estimar el retorno financiero que el proyecto otorga al
ejecutarse mediante el uso de flujos de costos, ingresos o ahorros, para determinar la
tasa interna de retorno.
Una vez finalizado el estudio de viabilidad se debe remitir al Director del Proyecto, quién
con base al resultado del impacto decide remitirlo al Comité Ejecutivo del Proyecto, para
que considere el impacto de acuerdo con su complejidad arquitectónica, tecnológica y
de negocios. Dependiendo del criterio del Comité Ejecutivo se continua o no con el
mismo.
Las actividades descritas para efectuar el estudio de viabilidad se esquematizan en la
siguiente figura:
Figura Nº 7. Informe del Estudio de Viabilidad
Análisis de impacto de la solución escogida en términos de:
Operación
Técnicos
Económicos
Impacto?
Produce reporte del estudio de viabilidad
ALTO
BAJO
No produce reporte del estudio de viabilidad
28
b.2) Definición de Requerimientos
Se deben definir los requerimientos generales del proyecto de tal forma que se logre
obtener un panorama más amplio de cuál es el producto que se desea desarrollar. Por
tal razón, es necesario que el usuario desarrolle los requerimientos utilizando el
estándar FOR-04 “Documento de Especificación de Requerimientos y Criterios de
Aceptación”, abreviado DERCA.
Este documento deberá contener una descripción completa de las necesidades y
funcionalidades del sistema que será desarrollado; describe el alcance del sistema y la
forma en como hará sus funciones, definiendo los requerimientos funcionales y los no
funcionales.
En el DERCA se definen todos los requerimientos de hardware (hw) y software (sw),
diagramas, modelos de sistemas y cualquier otra información que sirva de soporte y
guía para fases posteriores.
Es importante destacar que la especificación de requerimientos es el resultado final de
las actividades de análisis y evaluación de los mismos; este documento resultante será
utilizado como fuente básica de comunicación entre los clientes o usuarios finales,
analistas de sistema, personal de pruebas, y todo aquel involucrado en la
implementación del sistema.
Asimismo, es necesario indicar que en el CVDS como primera actividad se debe
ejecutar la Definición de Requerimientos y las etapas siguientes del ciclo se desarrollan
en la fase de Planificación y se ponen en práctica en la fase de Ejecución del proyecto:
Los clientes o usuarios utilizan el DERCA para comparar si lo que se está proponiendo,
coincide con las necesidades de la organización. Los analistas y programadores la
utilizan para determinar el producto que debe desarrollarse. El personal de pruebas
elaborará las pruebas funcionales y de sistemas en base a este documento. Para el
Director del Proyecto sirve como referencia y control de la evolución del sistema.
Una vez llevado a cabo el DERCA, se procede con la validación del mismo, por parte
del usuario y el analista de sistemas. Esto permite demostrar que los requerimientos
29
definidos en el sistema son los que realmente quiere el usuario; además revisa que no
se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes.
Durante la actividad de validación pueden hacerse preguntas en base a cada una de las
características que se desean revisar en los requerimientos, de la siguiente manera:
Cuadro Nº 2. Validación de las características de los requerimientos
Característica del DERCA Cuestionamiento
Completo ¿Están incluidas todas las funciones requeridas por el usuario?
Consistente ¿Existen conflictos en los requerimientos?
Sin ambigüedad ¿Tiene alguno de los requerimientos más de una interpretación?
Entendible ¿Está cada requerimiento claramente representado?
Factible ¿Pueden los requerimientos ser implementados con la tecnología y el presupuesto disponible?
Claridad ¿Está el DERCA escrito en un lenguaje apropiado?
Modificable ¿Existe facilidad para hacer cambios en los requerimientos?
Rastreable ¿Está claramente definido el origen de cada requisito?
Verificable ¿Pueden los requerimientos ser sometidos a medidas cuantitativas?
En caso de presentarse en la validación alguna inconsistencia se debe corregir el
documento de especificación de requerimientos.
Una vez confirmada la validación, el Director de Proyectos debe remitir el documento
FOR-02 Alcance del proyecto junto con el FOR-04 Documento de Especificación de
Requerimientos y Criterios de Aceptación (DERCA) al Comité Ejecutivo del Proyecto,
para que procedan con la revisión del mismo y si todos consienten se aprueba para
continuar con la siguiente fase.
En la Figura Nº 8 se especifica el flujo del proceso para la etapa Formulación del
proyecto.
30
Figura Nº 8. Flujo del Proceso de Formulación de Proyectos
El área de negocio interesada completa el
formulario FOR-01
El documento es revisado en reunión de inicio del
proyecto (FOR-07 Minuta)
Tecnología convoca a reunión a Comité Ejecutivo
del proyecto
Justifica y archiva
¿Se aprueba?
El formulario FOR-01 Identificación del proyecto
es enviado al área de Tecnología
El equipo de trabajo completa el FOR-02 Alcance del proyecto
Estudio viabilidad FOR-03 -Técnica (Analista) -Operacional (Usuario) -Económica (Usuario)
Requiere estudio
viabilidad
No Asigna Director y equipo Asigna prioridad. Define si se requiere un estudio de viabilidad
Planificación
Sí
Sí
No
¿Impacto?
Produce reporte del estudio de viabilidad para Comité Ejecutivo
No produce reporte del estudio de viabilidad
Bajo Alto
Deciden continuar?
Justifica y archiva
No
Sí
Considerar las necesidades y expectativas de los
involucrados.
Definir los requerimientos generales del proyecto
FOR-04 DERCA
Se procede a validar los requerimientos definidos en
el DERCA
¿Todo esta
conforme?
Sí
No
Corregir requerimientos definidos en el DERCA
Aprobar alcance y requerimientos
Reunión con el Comité Ejecutivo del Proyecto
31
4.2.3 Planificación del proyecto.
Introducción
Como todo proyecto, los proyectos de desarrollo de software deben ser planificados
para asegurar una mejor estimación de los tiempos y las actividades que deben ser
realizadas para alcanzar con éxito los objetivos del mismo y establecer los estándares
de la calidad que se desea obtener.
La finalidad de la planificación es obtener un documento preciso, que se convierta en
guía para la etapa de ejecución, el cual, deberá ser elaborado y aprobado por el equipo
del proyectos y avalado por el Comité Ejecutivo del Proyecto. De esta manera, la fase
de planeación del proyecto debe incluir los siguientes elementos principales:
Figura Nº 9. Fase de Planeación de Proyectos
Se hace la aclaración que el esfuerzo de planificación es mayor al inicio del proyecto,
pero, no llega a desaparecer a lo largo de la vida del proyecto; es una actividad
constante cada vez que haya un cambio o situación que afecte al mismo.
PLANIFICACION
Actividades Recurso Humano CVDS
Diseño del Sistema
Desarrollo del SW
Pruebas
Descomposición del alcance
Definir actividades
Secuenciar
Identificar roles
Obtener el RH
Estructura organizacional
Asignar actividades Implementación Estimación de la
duración
Desarrollo del cronograma
32
a) Planificación de las actividades del proyecto
Describir los procesos requeridos para garantizar la terminación
oportuna (a tiempo) del proyecto.
Para efectuar esta sub fase se deben contemplar los siguientes elementos:
a.1) Descomposición del alcance
Desarrollar una descomposición de actividades del proyecto con el fin de definir
claramente las etapas, actividades, tareas, responsables, entregables y fechas,
requeridas para cumplir con los objetivos planteados.
Este desglose debe efectuarse de manera particionada, bajo un esquema top down (de
arriba hacia abajo), primero definiendo las etapas requeridas, luego las actividades
asociadas a estas etapas y por último las tareas incluidas dentro de cada actividad. La
herramienta de mayor acople para desarrollar todo este proceso es la que se conoce
como Estructura Detallada del Trabajo (EDT). Su construcción es una cascada de
elementos macro a componentes de nivel más micro:
Figura Nº 10. Modelo de la Estructura Detallada de Trabajo
Propósito
Estimar tiempo
Objetivo general
Objetivos específicos
Entregables
Tareas
Alcance
33
⇒⇒⇒⇒ Objetivo general: es la razón de ser del proyecto. Se compone de los siguientes
elementos: verbo de acción + resultado + marco de tiempo
⇒⇒⇒⇒ Objetivos específicos: se derivan del objetivo general. Cada uno de estos
objetivos cubre uno o más entregables. Consta de verbo de acción + resultado.
⇒⇒⇒⇒ Entregables/sub entregables: son las grandes partes en que se divide el
proyecto. Se plantean en términos sustantivados. Ejemplo: capacitación.
⇒⇒⇒⇒ Actividades: conjunto de acciones que deben ser realizadas para completar un
entregable o sub entregable.
⇒⇒⇒⇒ Tareas / sub tareas: son acciones más específicas que deben ser ejecutadas
para completar una actividad.
a.2) Definición de actividades
Tomando como punto de partida la descomposición del trabajo donde se detallan todas
las actividades requeridas se identifican las actividades específicas del cronograma que
deben ser realizadas para producir los diferentes productos entregables del proyecto.
a.3) Secuenciar las actividades
Todas las actividades definidas son ordenadas de una forma lógica que permita su
desarrollo, considerando todas las dependencias entre ellas.
De esta manera, teniendo el panorama completo el siguiente paso es establecer las
relaciones entre las diferentes tareas identificadas. Las relaciones pueden ser de tres
tipos:
� Inicio-Inicio: Son aquellas tareas que deben iniciar necesariamente al mismo
tiempo.
� Final-Inicio: Las tareas A y B tienen una relación de este tipo cuando es
necesario que A concluya para que pueda iniciar la tarea B.
� Final-Final: Sucede cuando dos o más tareas deben concluir de manera
simultánea.
34
a.4) Estimación de la duración de las actividades
Se trata de estimar el número de periodos de trabajo necesarios para completar cada
una de las tareas identificadas. De preferencia, estas estimaciones deben elaborarse
por el método de Juicio Experto o por algún otro esquema formal. Además es
conveniente que se establezcan comparaciones con los datos estimados y reales de
proyectos similares anteriores.
a.5) Desarrollo del cronograma
El desarrollo del cronograma exige que se revisen y se corrijan las estimaciones de
duración y las estimaciones de recursos para crear un cronograma del proyecto
aprobado que pueda servir de línea base con respecto al cual poder medir el avance.
El cronograma debe contener como mínimo los siguientes espacios,
independientemente de la herramienta en la que se haga:
⇒⇒⇒⇒ Nombre de las actividades
(separadas por etapa o
entregable).
⇒⇒⇒⇒ Unidades de duración.
⇒⇒⇒⇒ Fecha de inicio.
⇒⇒⇒⇒ Fecha de término.
⇒⇒⇒⇒ Responsable
⇒⇒⇒⇒ % de avance.
El flujo del proceso de planificación de las actividades del proyecto se describe en la
Figura N° 11.
Figura Nº 11. Proceso Planificación de las Actividades del Proyecto
Revisar la Identificación y el Alcance definido
Estimar tiempos
Desarrollo del cronograma
Descomponer los entregables en
tareas
Secuenciar las actividades
Definición de actividades
35
b) Planificación del Recurso Humano del Proyecto
Planear el recurso humano necesario para concluir el proyecto, esto
incluye los procesos que organizan y dirigen el equipo, asignación de
roles y responsabilidades, desarrollo de competencias y seguimiento del
rendimiento de cada miembro.
La definición de los miembros del equipo del proyecto se realizó cuando se implementó
el formulario FOR-01 y FOR-02 de “Identificación” y “Alcance”, respectivamente. En la
fase de planificación se debe revisar con el objeto de incluir posibles ajustes que se
deban realizar producto de lo cambiante del contexto de los proyectos.
Asimismo, se debe conocer si alguno de sus integrantes se encuentra trabajando en
otro proyecto, cuando se estima que finalizará y el nivel de tiempo que le consume. Se
debe analizar más en detalle, si el grupo que le asignaron tiene las competencias
adecuadas, y si es suficiente, o bien, requiere de apoyo adicional.
Los equipos de trabajo deben estar integrados generalmente por personas que
desempeñen al menos, los siguientes roles:
⇒⇒⇒⇒ Patrocinador del Proyecto
⇒⇒⇒⇒ Director del Proyecto
⇒⇒⇒⇒ Líder del área del Negocio
⇒⇒⇒⇒ Líder del área de TI
⇒⇒⇒⇒ Personal técnico de TI
⇒⇒⇒⇒ Usuarios expertos en el producto
El tamaño del equipo de un proyecto depende del mismo proyecto, lo importante es que
cada rol y las funciones del mismo sean asumidas y ejecutadas por los miembros del
equipo de trabajo.
La definición de roles y responsabilidades se debe realizar mediante el uso del FOR-05
Roles y responsabilidades, sin embargo, a continuación se describen las actividades
básicas correspondientes a cada rol principal definido para un proyecto de desarrollo de
software:
Propósito
36
Cuadro Nº 3. Roles y responsabilidades Rol Definición Responsabilidad
Patrocinador del
Proyecto
Es un administrador con experiencia en negocios y es en beneficio de quien se esta llevando el proyecto.
� Representar varias áreas de negocio en la cual más de una línea de negocio es impactada.
� Representar los intereses del proyecto a un alto nivel organizacional.
� Responsable de aprobar las especificaciones del sistema, asegurando que satisfaga los requerimientos de negocio y sea desarrollado y entregado como fue planeado.
Director del Proyecto
Es el líder del proceso de planeación; principal encargado de generar el plan y cronograma del proyecto. Conduce la obtención de requerimientos y el proceso de diseño conceptual. Dirige la toma de decisiones necesarias para liberar el producto correcto.
� Lidera las reuniones de avance del proyecto.
� Responsable por entregar soluciones de calidad y rentables que cumplan con las necesidades reales del negocio de forma oportuna y ordenada.
� Administrar el presupuesto del proyecto a favor del Patrocinador, monitorea los gastos y los costos contra los entregables así como los beneficios planteados a lo largo del progreso del proyecto.
� Facilitador de la coordinación del día a día durante el desarrollo del proyecto.
� Proveer reportes efectivos de avance del proyecto.
Líder del área de Negocio
Responsable de planear, coordinar y monitorear todas las actividades de los miembros del proyecto que pertenecen a negocios.
� Comunicarse directamente con el Líder del área de TI sobre planes y recursos del proyecto.
� Tomar decisiones que afectan el área de negocio.
� Resolver conflictos en el área de negocios � Escalar aspectos importantes a la alta
gerencia.
Líder del área SW de TI
Responsable de planear, coordinar y monitorear todas las actividades de los miembros del proyecto que pertenecen a Ti
� Resolver problemas y/o desafíos claves de TI en el proyecto.
� Resolver conflictos en el área de TI.
Personal Técnico de TI
Expertos en el análisis, diseño, desarrollo y calidad del software.
� Desarrollar las especificaciones del usuario conforme lo establecido en el DERCA y de acuerdo a los tiempos planificados.
� Participación en las pruebas.
37
Rol Definición Responsabilidad
Usuarios
Es una persona experta en el producto asignada a especificar y recolectar los requerimientos de un grupo o grupos de usuarios finales.
� Analizar las necesidades del negocio y de crear conjuntos de ideas para valorar oportunidades de negocio y mejorar los procesos de negocios.
� Contribuir en los requerimientos de usuario y consolidarlos
� Estructuración de las pruebas.
Todo proyecto debe manejarse con una estructura organizacional que provea un marco
adecuado para que el mismo pueda ser gestionado de manera eficiente y logre los
resultados esperados.
A continuación se detalla la siguiente estructura organizacional, la cual es una
propuesta sencilla adaptable a una organización funcional:
Figura Nº 12. Estructura Organizacional para la Administración de Proyecto
Durante la evolución de un proyecto de desarrollo de software, la relación del personal
Técnico de TI con los usuarios expertos del producto se conjuga cada día, por tal
38
motivo es primordial que durante esta etapa de planificación se establezcan los perfiles
idóneos de los usuarios que integrarán el equipo del proyecto mediante el formato FOR-
05 Roles y responsabilidades en el apartado de Perfiles de usuarios.
Es importante destacar que esta etapa es estratégica, pues lo que se hace es definir el
equipo humano que va a trabajar en el proyecto, o al menos los roles que siempre es
preciso definir desde el inicio del proyecto, de tal forma que si es necesario, se puedan
ir incorporando después otros roles, de acuerdo con criterios de oportunidad y
disponibilidad de los recursos.
A continuación se ilustra en la Figura N° 13 el pro ceso para llevar a cabo la
Planificación de los Recursos Humanos del proyecto:
Figura Nº 13. Proceso Planificación de los Recursos Humanos del Proyecto
Identificar y documentar los
roles
Completar el Formulario FOR-05
Estimar
Revisar que el recurso humano no este sobre asignado
Determinar y obtener el recurso humano
necesario
Asignar recursos humanos a las actividades del
cronograma
Establecer la estructura
organizacional
Revisar miembros identificados en el FOR-01 y FOR-02
39
c) Planificación de elementos de Desarrollo del Sof tware
Definir la estrategia que el equipo usará para diseñar, construir, probar,
capacitar a los usuarios y como se adoptará la solución en la operativa
de la organización.
Para cumplir con el CVDS las etapas tempranas del mismo (Investigación preeliminar y
Determinación de requerimientos) fueron desarrolladas en la fase de Formulación de
esta metodología, los elementos del ciclo posteriores se contemplan a continuación en
esta sub fase:
c.1) Diseño del Sistema
Se trata de elaborar el diseño conceptual del sistema donde se describe la entrada, el
procesamiento, la salida, el hardware, el software y la base de datos en un nivel
superior y basado en la especificación de requerimientos (DERCA).
Para este fin el personal técnico realiza varios diseños, donde se exponen los detalles
que establecerán la forma en la cual el sistema cumplirá con los requerimientos
identificados en la Fase de Formulación de Proyectos.
Luego se presentan al Comité Ejecutivo del Proyecto, con el propósito de evaluar cada
una de estas alternativas y se selecciona la que mejor se adecúe a las necesidades del
negocio.
Los documentos que contienen las especificaciones de diseño aprobadas se
proporcionan al personal de programación para comenzar con el desarrollo del
software.
c.2) Desarrollo del sistema
Implica la planificación de cómo se realizará la construcción del sistema, considerando
como punto de partida las especificaciones del diseño, lo cual permitirá el tratamiento
de los elementos de programación que darán como resultado las funcionalidades de los
Propósito
40
procesos requeridos. Asimismo, el método de programación se efectuará conforme con
los estándares de programación interna del área de Desarrollo del Software.
c3). Pruebas
Se realiza la planificación con la finalidad de definir la estrategia que se utilizará para
probar la solución donde se contemple la verificación del funcionamiento correcto del
nuevo aplicativo y que el mismo se encuentre acorde con los criterios de aceptación
indicados por el usuario.
Durante la prueba, el sistema se emplea de manera experimental para asegurarse de
que el software no tenga fallas, es decir, que funciona de acuerdo con las
especificaciones y en la forma en que los usuarios esperan que lo haga. Para esto se
alimentan como entradas conjunto de datos de prueba para su procesamiento y
después se examinan los resultados.
En el plan de pruebas se debe incluir:
⇒⇒⇒⇒ Tipos de pruebas a ser realizadas: pruebas unitarias, pruebas de integración,
pruebas de rendimiento, pruebas de stress, pruebas de utilización, pruebas de
regresión.
⇒⇒⇒⇒ Configuración: información de los recursos de software y hardware requeridos
para probar.
⇒⇒⇒⇒ Formato de las pruebas y criterios de éxito: documento con los escenarios y con
los resultados que deben brindar las pruebas. Para esto se debe documentar
mediante el estándar FOR-08 Documentación de Pruebas.
Dependiendo de los resultados se deben efectuar mejoras en el producto de software o
bien se dan por aceptados y se continua con la siguiente fase de la metodología.
41
c4) Implantación
En la implantación se incluye la estrategia y los detalles requeridos para preparar a los
usuarios y al personal, antes y durante la implementación de la solución. Se debe
considerar los siguientes elementos:
Cuadro N° 4. Elementos de la Implantación del Sist ema
Elemento Definición Contempla
1.Capacitación
Entrenar a los usuarios en el nuevo producto de software. Depende de factores tales como disponibilidad de recursos y el impacto de la solución en los usuarios finales
⇒⇒⇒⇒ Audiencia: todos los usuarios involucrados y personal de help desk.
⇒⇒⇒⇒ Medio por el cual se impartirá: manuales, presentaciones y laboratorios.
⇒⇒⇒⇒ Desarrollo de materiales: Cuándo se construyen y quién lo realiza.
⇒⇒⇒⇒ Duración de la capacitación.
2. Implementación Proceso que permite verificar la estrategia de instalación y puesta en marcha del nuevo producto.
⇒⇒⇒⇒ Estrategia de instalación: por fases o total, sitio por sitio, área por área.
⇒⇒⇒⇒ Contingencias para la continuación de las operaciones: sistemas paralelos, respaldo, entre otros.
⇒⇒⇒⇒ Mecanismo de implementación: manual, instalación por medio de la red, por scripts, entre otros.
⇒⇒⇒⇒ Recursos de hw requeridos en la instalación: memorias, disco, procesador, ancho de banda, versiones del sistema operativo.
3. Entrega del Producto
Contempla la estrategia a seguir por el proyecto para que el producto o servicio final sea adoptado por la operativa de la organización. Para cada entregable se debe completar el FOR-10 Aprobación de entregables.
⇒⇒⇒⇒ Lista de actividades y procesos que se requiere ejecutar para el adecuado manejo del producto.
⇒⇒⇒⇒ Lista de unidades organizacionales que deberían responsabilizarse por ejecutar las actividades.
⇒⇒⇒⇒ Impacto sobre las actividades actuales.
En la Figura N° 14 se describe el flujo de activida des que conlleva el proceso de
planificación de los elementos de desarrollo del software.
42
Figura Nº 14. Proceso de Planificación de los elementos de desarrollo del SW Una vez planificado todos los elementos se compilan en el documento llamado “Plan de
Gestión del Proyecto”, que, deberá ser aprobado por el equipo del proyectos y avalado
por el Comité Ejecutivo del Proyecto. La estructura del documento deberá contener
como mínimo:
- Introducción - Beneficios
- Alcances del proyecto - Estrategia por desarrollar
- Objetivos del proyecto - Equipo del proyecto
- Justificación - Cronograma de actividades
Apéndices / anexos
Capacitación
Entrega del producto (FOR-10)
3. Pruebas
Implementación
Elaboración de alternativas
Presentación de alternativas al Comité Ejecutivo Proyectos
Selección y aprobación de
alternativa de diseño
Programación conforme a los
estándares internos
Release Producto
Tipos de pruebas a realizar FOR -08
Resultados aceptados
4. Implantación del sistema
SI
NO
Consultar DERCAS FOR-04
1. Diseño del sistema
2. Desarrollo del sistema
Revisar requerimiento ir al
paso 2
43
Figura Nº 15. Flujo del Proceso de Planificación de Proyectos
Planificación de las actividades del
proyecto
Se definen actividades, se estiman tiempos de
duración y se secuencian las actividades
Se descomponen los entregables en tareas
Se revisan los documentos de
Identificación y Alcance
Revisar miembros identificados en el FOR-01
y FOR-02
Ejecución
¿Resultados aceptados?
Sí
Se realizan mejoras en el punto con *
Capacitación
Desarrollo del cronograma del proyecto
Planificaci ón de lo s recursos humanos del
proyecto
Identificar y documentar los roles
Identificar y obtener el recurso humano
Establecer la estructura organizacional
Completar el FOR-05 Identifica roles y responsa..
Asignar recursos humanos a actividades- cronograma
Revisar que el recurso humano no este sobre
asignado
Planificac ión de lo s elementos del
Desarrollo del SW
Diseño del Sistema
Se consultan los FOR-04 DERCAS
Elaboración de alternativas de diseño
Presentación de alternativas al Comité Ejecutivo de Proyecto
Selección y aprobación de alternativa de diseño
Desarrollo del sistema
* Programación conforme a los estándares internos
Producto construido
Pruebas del sistema
Tipos de pruebas a realizar
Formatos y criterios de aceptación (FOR-08)
Implantación del sistema
Implementación
Entrega del producto Completar FOR-10
No
Control
Documento del Plan de Gestión de Proyectos
Se presenta ante el Comité Ejecutivo del Proyecto para
su aprobación
44
4.2.4 Control y seguimiento del proyecto . Introducción
Posteriormente de que el proyecto ha sido planificado y aprobado por el Comité
Ejecutivo del Proyecto, corresponde ejecutarlo de la forma más eficiente y siguiendo
como guía el Plan de Gestión del Proyecto.
La finalidad que se persigue obtener al llevar a cabo esta fase en los proyectos,
consiste en controlar y dar seguimiento al desempeño del proyecto en la fase de
ejecución de conformidad con lo planeado para detectar de forma oportuna
desviaciones para emprender las respectivas acciones correctivas o preventivas.
Esto conlleva como beneficio que el rendimiento del proyecto se monitoree
regularmente para identificar las variaciones respecto al Plan de Gestión de Proyectos,
además controlar los cambios y anticiparse ante posibles problemas.
Este capítulo se centrará en los siguientes elementos donde se ejercerá el control y el
seguimiento de los proyectos:
Figura Nº 16. Fase de Control y Seguimiento de Proyectos
Es importante considerar que el monitoreo puede ser oportuno, pero si el ajuste es
retardado, los resultados serán deficientes, de la misma forma que el ajuste oportuno a
un monitoreo tardío tampoco se traducirá en buenos resultados.
CONTROL
Administración de cambios
Aprobación de entregables
Informes de avance Seguimiento
45
a) Administración efectiva de los cambios
Ordenar el proceso de cambios en el proyecto para atenderlos con la
mayor disposición, pero haciéndolo de una forma organizada que nos
asegure el desarrollo efectivo del mismo.
El control de cambios es un instrumento que debe ser practicado cuando los factores
tiempo, costo, calidad o alcance se ven afectados por actividades no previstas como
producto de una inadecuada planificación, nuevas funcionalidades que se incorporen al
sistema a obtener y disminución en los recursos asignados
Además es necesario controlar los cambios porque los proyectos raramente se
desarrollan exactamente acorde con el plan de gestión del proyecto (PMI, 2004). Por
tanto, para realizar una adecuada administración de los cambios debe realizarse las
siguientes actividades:
El Usuario completa el formulario Control de solicitud de cambios (FOR-09 de la sección
4.2.6) y lo presenta ante el Director del Proyecto, quien analiza y resuelve (en la medida
que la situación lo permita) con el equipo de proyecto.
El análisis girará en torno al impacto de la solicitud en el proyecto a nivel del alcance,
cronograma, costos y calidad.
Después de que el impacto esté claro por parte del Director del Proyecto se traslada el
formulario FOR-09 al Comité Ejecutivo del proyecto, con la finalidad de que procedan
con la decisión:
⇒⇒⇒⇒ Si el cambio no implica cambios a nivel de tiempo, costo o calidad y se analiza
como necesario, se aprueba y se actualiza el Plan de Gestión del Proyecto
(PGP).
⇒⇒⇒⇒ Si la solicitud implica un impacto en cuanto a inversión monetaria, tiempo o
calidad se debe llevar ante el Comité de Proyectos para deliberar:
Propósito
46
o En caso de ser aprobada se actualiza el PGP y se informa al equipo del
proyecto.
o Si por el contrario no se acepta se debe comunicar al solicitante.
Figura Nº 17. Actividades de la Administración Efectiva de Cambios
Llena FOR-09 Solicitud de Cambio
Envía
Sí
Sí
Actualiza el PGP, cambia versión
Analiza solicitud con el equipo de
proyecto
Si implica un impacto en costo, tiempo o calidad
No Notifica al solicitante
A c t o r 1
USUARIO
Actor1DIRECTOR PROYECTO
Actor1Comité
Actor1Actor1
Acepta
Comunica a su equipo y otros involucrados
47
b) Informes de avance
Determinar el nivel de avance alcanzado por el proyecto, corroborando
lo planificado versus lo ejecutado para determinar desviaciones y
poder definir las acciones necesarias.
Los informes de avance permiten dar seguimiento continuo y proporcionan al equipo del
proyecto una idea acerca de la situación del mismo y resalta cualquier área que
necesite atención correctiva o preventiva.
Es una actividad importante porque permite monitorear las variaciones que ponen en
peligro los objetivos del proyecto y se observa el rendimiento del proyecto de forma
periódica.
Este informe se lleva a cabo mediante la utilización del FOR-06 “Informe de avance” del
Proyecto, que se indica en la sección 4.2.6 de esta metodología y se considera que
cumple a la vez un papel de comunicación, debido a que desempeñan un rol importante
de transmisión de la información entre los involucrados.
Por tal razón se debe considerar:
⇒⇒⇒⇒ Comunicarlo en las reuniones de equipo para analizar el estado de avance de las
actividades y del proyecto.
⇒⇒⇒⇒ La periodicidad en la cual el Director de Proyectos enviará el reporte del informe
de avance al Comité Ejecutivo de Proyectos, para que se encuentre enterado de
los últimos detalles del proyecto.
⇒⇒⇒⇒ Realizar análisis de los informes permitirá identificar las variaciones con respecto
al Plan de Gestión de Proyectos y detectar cualquier desviación con el fin de
tomar decisiones que puedan corregir o prevenir situaciones.
Propósito
48
c) Reuniones de seguimiento
Proceso necesario para recoger y distribuir la información sobre el
rendimiento y mantener una buena comunicación a lo interno del equipo
de proyecto.
Mediante las reuniones de seguimiento se da un espacio para que los integrantes del
equipo compartan el conocimiento y se expongan las situaciones que enfrenta el
proyecto.
Las reuniones de seguimiento se deben llevar a cabo para:
⇒⇒⇒⇒ Verificar las actividades que deben ser realizadas próximamente por los
diferentes miembros del equipo del proyecto.
⇒⇒⇒⇒ Comunicar el avance del proyecto de acuerdo al Informe de Avance del proyecto
del periodo.
⇒⇒⇒⇒ Informar por parte de cada integrante del equipo el estado en que se encuentran
las actividades a las que se encuentran asignados conforme lo planificado.
El Director de Proyectos deberá planificar las reuniones de seguimiento con el equipo
de proyecto para efectuarlas con la debida agenda, para ello debe tomar en cuenta las
siguientes premisas:
⇒⇒⇒⇒ Asistirán a las reuniones el Líder del Proyecto, el Usuario Responsable y los
colaboradores que él estime pertinente que lo acompañen, los demás integrantes
del Equipo del Proyecto y cualquier Jefatura de área funcional que se estime
necesario convocar.
⇒⇒⇒⇒ Establecer una periodicidad y respetarla. Es recomendable, en proyectos,que se
lleven a cabo semanalmente.
⇒⇒⇒⇒ No suspender la reunión porque no se cumplió con el objetivo propuesto o
porque no se logró avance.
Propósito
49
⇒⇒⇒⇒ En estos casos, la reunión será utilizada para que el Líder del Proyecto informe
el retraso y las decisiones tomadas respecto al mismo. Lo importante es mostrar
un proceso controlado.
⇒⇒⇒⇒ Lograr una participación activa de todos los involucrados, demostrando la
importancia y el beneficio que cada uno consigue a partir de las reuniones. En
especial, se debe lograr una participación muy activa de los usuarios, por ser
estos las personas claves para la toma de decisiones.
⇒⇒⇒⇒ Evitar que las reuniones se dispersen tratando de resolver problemas puntuales.
Debe lograrse separarlas de las demás reuniones de trabajo, tales como
definición de requerimientos o planificación.
⇒⇒⇒⇒ En proyectos de gran complejidad es muy probable que sea necesario separar
las reuniones en dos niveles, con diferentes periodicidades y auditorio.
⇒⇒⇒⇒ Por un lado, reuniones dedicadas al Usuario, con la eventual participación de
Jefes de diferentes áreas funcionales involucradas, separadas por períodos más
extensos (quincenalmente, por ejemplo), donde se muestre el avance y se tomen
decisiones relativas a la planificación, recursos y a otros factores no técnicos.
⇒⇒⇒⇒ Por otro lado, reuniones con el Equipo del Proyecto, donde se tomen decisiones
más operativas, con menor periodicidad (semanalmente, por ejemplo), dada la
relevancia de las decisiones en las actividades diarias, ya que se maneja un
menor nivel de detalle.
⇒⇒⇒⇒ Todas las reuniones deben ser documentadas con minutas (FOR-07 Minuta
sección 4.2.6) registrando así las conclusiones y las acciones a ser tomadas.
50
d) Aprobación de entregables
Generar una aprobación formal de los entregables intermedios que se
hayan definido en el Plan de Gestión del Proyecto conforme se vayan
concluyendo.
La aprobación de entregables en proyectos de desarrollo de software conlleva lo
siguiente:
⇒⇒⇒⇒ Es claro que la aprobación de entregables intermedios por parte del usuario, se
da a través del desarrollo de todo el proyecto.
⇒⇒⇒⇒ Cada vez que un proceso es finalizado en la ejecución de un proyecto y se
genere un entregable, el usuario establecido procederá con la aprobación del
mismo de forma individual para cada entregable.
⇒⇒⇒⇒ La idea se basa en verificar la medida en que se cumplió con las
especificaciones planificadas y generar una aprobación o rechazo.
⇒⇒⇒⇒ El aprobar un entregable significa que se encuentra de acuerdo con el resultado
del mismo y el rechazo se puede otorgar en el caso de que no se cumpla con los
criterios de aceptación establecidos en el DERCA.
⇒⇒⇒⇒ Para documentar este proceso se utiliza el formato FOR-10 “Aprobación de
entregables” que se indica en la sección 4.2.6.
⇒⇒⇒⇒ Sí el entregable final intermedio no es aceptado por quien lo revise, deberá
devolverse con las respectivas observaciones del caso al Líder del proyecto para
que se efectúen los ajustes necesarios de acuerdo con el DERCA.
En la Figura Nº 18 se expone el flujo del proceso para el proceso de seguimiento y
control de proyectos.
Propósito
51
Figura N° 18 . Flujo del Proceso de Seguimiento y Control de Proyectos
El Líder del proyecto realiza reuniones de seguimiento
El Líder del proyecto monitorea
el avance
Ajustes Se realiza el Control de cambios. FOR-09
Se actualiza el plan de gestión del
proyecto Se prepara el informe de avance
Verificar si se cumplió en las
especificaciones
SI
NO
Se aprueban los entregables
52
4.2.5 Cierre del proyecto .
Introducción
La finalización es el último de los procesos en la administración de los proyectos, pero
no por ello es menos importante que los anteriores. Un proyecto puede concluirse por
dos razones, porque se logró el objetivo planteado o porque se canceló por alguna
situación en particular, por ejemplo, cambio de prioridades, mala conducción, pérdida
de oportunidad o agotamiento de los recursos, entre otros.
Mediante el cierre del proyecto, se formaliza la entrega y aceptación de los productos o
servicios del proyecto. Se trata de terminar los trabajos en una forma ordenada y de
analizar los resultados obtenidos para deducir las lecciones aprendidas que serán parte
básica del proceso de mejora continua.
Es por ello que en esta fase se pueden considerar como subprocesos, el cierre
administrativo que es la parte formal de entrega de versiones finales de productos y las
lecciones aprendidas que es la parte no estructurada, pero que nos va a permitir
capitalizar el conocimiento para mejorar la actuación en los diferentes proyectos que
debe desarrollar la organización.
La importancia de esta fase se puede resumir en las siguientes premisas:
⇒ Es una oportunidad para la generación de experiencia documentada.
⇒ Permite la consolidación del conocimiento individual y de los equipos de trabajo.
⇒ Va a permitir la posterior construcción de herramientas para la sistematización de
métricas.
⇒ Asegurar que el usuario conoce el producto y en consecuencia es más fácil inferir
las potenciales mejoras.
Figura N° 19. Fase de cierre de proyectos
CIERRE
Carta aprobación final
Informe por cancelación
Lecciones aprendidas
53
a) Carta de aprobación final del proyecto
Comprende el obtener la aprobación formal por parte del usuario,
aprobación de pagos, cierre de contratos y la elaboración del Informe
Final del Proyecto, entre otros.
La carta de aprobación final del proyecto de desarrollo de software conlleva lo siguiente:
⇒ En la parte de los recursos humanos, implica la reintegración de recursos a las
áreas funcionales que pertenecen o se trasladan a otros proyectos.
⇒ Cuando el proyecto se concluye se debe emitir un documento dirigido al Comité
Ejecutivo de Proyectos donde se especifica que se recibe conforme el resultado
que se haya producido.
⇒ El Comité Ejecutivo de Proyectos debe ser conciente de que el proyecto debe
estar listo para que ingrese en operación, por lo que los sistemas deben estar
ajustados, debidamente probados; los procedimientos adaptados, el usuario
capacitado correctamente en el uso y funcionalidad.
⇒ Una vez conforme con el resultado se debe aceptar la aprobación final del proyecto
mediante la firma del documento FOR-11-Acta de cierre del proyecto. Ver sección
4.2.6.
⇒ Se puede indicar que el proyecto no se cierra hasta tanto, dicho documento esté
firmado.
Propósito
54
b) Informe de finalización por cancelación (cuando pro ceda)
Implica que el Líder del Proyecto, Patrocinador o Usuario Líder del
Negocio tomen la decisión de detener el proyecto.
La búsqueda constante de la administración de proyectos es lograr el éxito en la gestión
realizada, pero puede suceder que existan proyectos en los cuales se determine que es
más rentable para la organización cancelarlo, previo análisis de la situación.
Para estos efectos, se debe analizar los elementos que justifican solicitar la cancelación
del proyecto por parte del funcionario que efectúo la solicitud, la cual puede provenir de
del Patrocinador, del Usuario Líder o del Líder del proyecto.
El informe de finalización por cancelación conlleva lo siguiente:
⇒ La decisión de cancelación debe ser autorizada por el Comité Ejecutivo de
Proyectos y avalada por el Patrocinador.
⇒ La finalización de un proyecto por cancelación implica la preparación de un informe
al Comité Ejecutivo del Proyecto o Patrocinador, el cual debe contener:
o La justificación que lo lleva a tomar esa decisión, claramente especificada.
o Elaboración de Informe de Resultados donde se deje constancia formal
del proceso, los logros alcanzados, los problemas enfrentados y las
razones, en detalle, por las que el proyecto se cancela.
⇒ Se debe realizar el retorno de los recursos asignados al proyecto a sus áreas
respectivas.
Propósito
55
c) Lecciones aprendidas
Identificar los éxitos y los fracasos del proyecto, e incluye
recomendaciones para mejorar el rendimiento futuro de los proyectos.
El Líder de Proyectos deberá llevar a cabo sesiones de análisis de resultados,
obviamente al final del proyecto, que implican una revisión del mismo por todos los
participantes. En las sesiones debe especificar claramente qué funcionó, qué no
funcionó y recomendaciones de mejora para próximos proyectos.
De la misma manera, cuando un proyecto se canceló antes de su terminación, hay que
analizar las razones que llevaron a ello y en general valorar los resultados que generó
esa experiencia.
Para este proceso de Lecciones aprendidas es necesario que los participantes analicen:
⇒ La forma en que se efectuaron los asuntos técnicos y de desarrollo.
⇒ Lo que contribuyó al rendimiento del trabajo.
⇒ Las condiciones que dificultaron el progreso del proyecto.
Con esta fase se pretende generar una base de conocimiento que se mantenga
actualizada y que proporcione a los equipos de proyectos la información que permita
efectividad y eficiencia en su gestión.
Propósito
56
4.2.6 Formularios que permiten documentar las activ idades del proyecto FOR-01 Identificación del proyecto
IDENTIFICACIÓN DEL PROYECTO [Nombre del proyecto]
Descripción de la situación actual (justificación) Se establece qué es lo que motiva la iniciación del proyecto (problema u oportunidad), indica los motivos por los cuales se quiere realizar este proyecto.
Descripción general de la solución propuesta Describe de manera precisa y concisa, cuál es la propuesta para atender el problema o la oportunidad presentada.
Beneficios a obtener Se debe indicar cómo el proyecto mejorará la situación actual, en qué elementos incidirá, cómo se demostrará su efecto positivo en la situación arriba descrita.
Objetivo General: Establece la razón de ser de este proyecto. Debe ser planteado de forma que se pueda verificar o medir su cumplimiento, por lo que deben ser claros y realistas y estar alineados con los objetivos institucionales. Se compone de los siguientes elementos: verbo de acción + resultado + marco de tiempo Objetivos Específicos : 1. Uno Desagrega el objetivo general en componentes más pequeños. Debe ser planteado de forma que se pueda verificar o medir su cumplimiento, por lo que deben ser claros y realistas.
Principales entregables Aquí se mencionan, de forma numerada y a un nivel macro, cuáles serán los principales productos finales verificables que se obtendrán (también puede denominarse “fases”).
Áreas involucradas: Anotar aquellas áreas, personas físicas o jurídicas que se encuentren vinculadas directa o indirectamente con el proyecto. Nombre del solicitante: ____________________________________ Firma :_______________ Se anota el nombre del funcionario que solicita el presente proyecto.
57
Espacio para uso de la reunión de resolución Fecha tentativa de inicio: Fecha tentativa de finalización : Duración: Se anota una fecha tentativa de inicio y de finalización y la duración es la diferencia entre ambas fechas. Aprobado:_____ Denegado:_____ Pospuesto:_____
Equipo asignado al proyecto: Asignará el personal más adecuado para fungir como miembros del equipo de proyecto.
Requiere estudio de viabilidad Sí __ No__ Se debe indicar si para este proyecto se requiere de un estudio que analice la viabilidad del proyecto. Observaciones: Anotaciones importantes sobre el proyecto en cuestión, o bien, registrar los motivos de por qué se deniega o se pospone.
58
FOR-02 Alcance del proyecto
ALCANCE DEL PROYECTO [Nombre del proyecto] Descripción detallada de las características / espe cificaciones / requisitos o funcionalidades del producto a obtener Se trata de identificar cómo será el producto o resultado a obtener, qué características debe tener, qué necesidades debe satisfacer de forma clara, precisa y en un orden lógico. Se definen las especificaciones y funcionalidades que debe incluir ese producto.
Exclusiones Se indica lo que no incluye el proyecto. Este apartado es importante porque se deja bien claro qué es lo que no cubre el proyecto.
Entregables Descripción Criterios de aceptación
Son productos intermedios a obtener durante el proyecto o etapas propias del proceso.
Describe el entregable definido a fin de que todos entiendan lo mismo.
Bajo qué elementos, consideraciones hechos o fechas se recibirá dicho entregable.
Factores Críticos de Éxito:
Identifique y especifique los principales factores técnicos, financieros, administrativos y de recurso humano, que debe ser tomado en cuenta para llevar a cabo con éxito las actividades del proyecto.
Hardware
Software
Recursos Financieros
Recursos Humanos
Otros
1. Equipos cómputo, comunicación y Redes.
1. Clase de software, aplicaciones, bases de datos.
1. Presupuesto aprobado
1. Funcionarios requeridos o contratación outsorcing
1.
2. 2. 2. 2. 2. 3. 3. 3. 3. 3. Nombre y firma de quiénes participaron en la elabor ación del alcance Se registra quiénes participaron en este formulario. Nombre del responsable del proyecto: Firma:
Nombre: Firma:
Nombre: Firma:
Nombre: Firma:
Nombre: Firma:
Nombre: Firma:
59
FOR-03 Estudio de Viabilidad
ESTUDIO DE VIABILIDAD [Nombre del proyecto] Introducción: Justificar la necesidad de evaluar el nuevo proyecto. Se puede dividir en las siguientes, que serán necesarias según el tipo de proyecto:
Técnica:
Analizar las diferentes alternativas técnicas que existen para llevar acabo el proyecto, ya sea que se realice internamente o se contrate externamente .
Operacional:
Determinar si operacionalmente el producto a desarrollar podrá ponerse en operación eficazmente.
Económica
Estimar el retorno financiero que el proyecto otorga al ejecutarse mediante el uso de flujos de costos, ingresos o ahorros, para determinar la tasa interna de retorno.
Valor Actual Neto (V.A.N.): ¢ Solo consigne la cantidad Tasa Interna de
Rend. (T.I.R.): % Solo consigne la cantidad
Consideraciones y recomendaciones: Evaluar el nuevo proyecto y emitir un criterio y recomendaciones sobre su factibilidad.
60
FOR-04 Documento de Especificación de Requerimiento s y Criterios de Aceptación (DERCA)
Especificación de Requerimientos y Criterios de Ace ptación Versión: Consecutivo Nombre del proyecto: Nombre con el que se conoce el
proyecto. Fecha : dd/mm/aaaa Preparado por: Funcionario que preparó el documento Estado: Indicar si el documento esta
vigente o no.
Requerimientos Funcionales Breve introducción de los requerimientos funcionales El proceso ____________, requiere_______________________________________. Por lo tanto,
RF-01 (Nombre del requerimiento)
Usuario:
Detalle del requerimiento
Especificar claramente cómo será el producto o resultado a obtener, qué características debe tener, de forma precisa y en un orden lógico. Se definen las especificaciones y funcionalidades que debe incluir ese producto.
Información adicional
Cualquier comentario adicional que se requiera agregar Criterios de Aceptación Indicar los criterios con los cuales se acepta el requerimiento
Requerimientos No Funcionales Breve introducción de los requerimientos no funcionales El proceso ____________, requiere_______________________________________. Por lo tanto,
RNF-01 (Nombre del requerimiento)
Usuario:
Detalle del requerimiento
Especificar claramente cómo será el producto o resultado a obtener, qué características debe tener, de forma precisa y en un orden lógico. Se definen las especificaciones y funcionalidades que debe incluir ese producto.
Información adicional Cualquier comentario adicional que se requiera agregar Criterios de Aceptación
Indicar los criterios con los cuales se acepta el requerimiento
61
Requerimientos Hardware
Indicar los requerimientos sobre Equipos cómputo, comunicación y Redes.
Requerimientos Software Indicar los requerimientos en cuanto clase de software, aplicaciones, bases de datos.
GAP análisis ID Capacidad existente Capacidad Propuesta
# Indicar la capacidad actual Indicar la capacidad que se espera obtener
Aprobado
Firma Firma
Firma Firma
62
FOR-05 Identificación de roles y responsabilidades
IDENTIFICACIÓN DE ROLES Y RESPONSABILIDADES Establece la responsabilidad de cada uno de los integrantes del proyecto. Estos roles están en función, tipo y las características propias de cada proyecto. Estos roles pueden ser ejecutados, según acuerdo, por un mismo recurso. A continuación se sugiere como roles para un proyecto los siguientes.
Rol Nombre recurso Dedicación Semanal
Localización
Patrocinador del Proyecto: Se especifican las responsabilidades en el proyecto.
Horas Correo electrónico/ Teléfono
Administrador del Producto: Se especifican las responsabilidades en el proyecto.
Director del Proyecto: Se especifican las responsabilidades en el proyecto.
Equipo Desarrollador: Se especifican las responsabilidades en el proyecto.
Equipo Capacitador: Se especifican las responsabilidades en el proyecto.
Equipo de pruebas : Se especifican las responsabilidades en el proyecto.
Perfiles de los Usuarios: Establece cuáles son los tipos de usuario necesarios para la buena marcha del proyecto y que se utilizarán durante todo el ciclo de vida del proyecto.
Usuario Descripción de Funciones
Dedicación Semanal
Localización
Nombre del usuario Indicar las funciones de los usuarios participantes
Horas Correo electrónico/ Teléfono
63
FOR-06 Informe de avance del proyecto
INFORME DE AVANCE PROYECTO (Nombre del proyecto)
Fecha inicial: dd/mm/aaaa Fecha Final estimada: dd/mm/aaaa
Patrocinador: Nombre del Patrocinador
Director del proyecto: Nombre del Director del Proyecto
Objetivo: Indicar el objetivo general del proyecto
Estado en tiempo % Avance anterior Indicar el % anterior
% Avance Indicar el % alcanzado
%Avance planeado Indicar el % planeado a la fecha
Estado en costos
Presupuesto planeado $ planeado a la fecha Presupuesto aprobado $ Monto aprobado total
Presupuesto consumido $ cantidad consumida
Situación del proyecto
Problemas Acciones ante problemas
Indicar problemas acontecidos en el periodo Indicar las acciones efectuadas para contrarrestar
Entregables alcanzados hasta el ultimo informe Entregables por alcanzar hasta el próximo informe
Especificar los entregables logrados hasta el ultim o informe
Entregables pendientes de alcanzar
Comentarios:
Indicadores de desempeño Curva de tiempo Curva de Costo
% Avance programado versus % Real
Presupuesto versus Costo Real a la fecha
64
FOR-07 Minuta de Reunión
MINUTA DE REUNION Proyecto [Nombre]
Fecha dd/mm/aaaa hh:mm Lugar Donde se efectúo la reunión
Número #
Nombre de los participantes
Asistentes:
Objetivo:
Objetivo de la reunión
Temas Tratados: Desarrollo de los hechos relevantes de la reunión.
Puntos Pendientes
(Acuerdos) Acuerdos de la reunión o pendientes que se mantienen del proyecto, indicar quien debe ejecutarlos
65
FOR-08 Documentación de Pruebas
DOCUMENTACION DE PRUEBAS Página 1 de
Información del Proyecto Nombre del Proyecto:
Nombre con el que se conoce el proyecto.
Líder Equipo Pruebas:
Nombre del líder del encargado de pruebas.
Plan de Pruebas No:
Consecutivo Fecha: dd/mm/yyyy
Descripción de las Pruebas
Objetivo Indicar el objetivo de la prueba a desarrollar
Resultados Obtenidos
No. Descripción Resultado Esperado
Resultados Obtenidos Acciones Resultados
Satisfactorios # Detallar la prueba Que se espera
obtener El resultado real obtenido de la prueba
Acciones posteriores
(SI) (NO)
. Detalle de la documentación anexada Indicar la documentación que respalda las pruebas efectuadas
Aprobación de los Resultados
Participantes Comentarios
Nombre Rol Firma
Nombre del participante de la prueba
Rol desempeñado
Cualquier comentario que se desee agregar de las pruebas.
66
FOR-09 Control de cambios
CONTROL DE CAMBIOS Nombre del proyecto: Nombre con el que se conoce el proyecto.
Fecha de solicitud: Fecha en se solicitó el cambio.
Descripción del cambio Indicar en detalle en qué consiste el cambio.
Beneficios del cambio Señalar cuáles son los beneficios que se obtiene si se aplica el cambio solicitado.
Análisis del impacto (ser explícito) Se analiza la forma cómo impactará el cambio en el proyecto. Alcance ¿Las funcionalidades o características del producto o servicio a obtener se incrementarán o disminuirán?
Cronograma ¿Será necesario registrar más actividades o se eliminarán algunas actividades o etapas?, ¿cuáles?, cuánto tiempo demandarán esa nuevas actividades?, ¿el tiempo planteado originalmente en cuánto se verá afectado?, ¿qué recursos requerirá?, ¿hay recursos?.
Costos ¿El cambio demandará financiamiento extra?, ¿cuánto?
Indicar lo que sucede en caso de no aprobarse el cambio Señalar cuáles serían las consecuencias de no aplicarse el cambio solicitado.
APROBACION Situación de la solicitud: Aprobada __ Rechazada__ Observaciones: ____________________________________________________________________________________ ____________________________________________________________________________________ ____________________________________________________________________________________ Nombre de quien firma: Firma::____________ Fecha:____________ Espacio para registrar si la solicitud de cambio fue aprobada o denegada. Cuando se deniegue habrá de indicarse el motivo. También, deberá anotarse el nombre de la persona que está autorizando incorporar el cambio y se requerirá la firma de este y la fecha.
67
FOR-10 Aprobación de entregables
APROBACIÓN DE ENTREGABLES Nombre del Proyecto: Nombre con el que se conoce el proyecto.
Fecha: Fecha en se aprobó
Descripción del entregable Se anota cuál es el entregable en cuestión.
Criterio de aceptación definido Se anota el criterio bajo el cual se recibirá conforme el producto. Se escribe tal como se encuentra indicado en el Plan de Proyecto.
Nivel de cumplimiento del entregable con respecto a las especificaciones Cumple con especificaciones ____ Cumple medianamente ________ No cumple_____ Espacio donde se valora el nivel de cumplimiento de las especificaciones para este entregable en particular, después de haber revisado con detenimiento el producto final intermedio. Comentarios Espacio para anotar observaciones sobre el entregable recibido. Este entregable se: Acepta Rechaza Firma: Fecha :__________________________ Quien haya evaluado el entregable en cuestión, deberá firmar en el lugar donde corresponda, sea para aceptar el entregable, o bien, para rechazarlo.
68
FOR-11 Acta de Cierre del Proyecto
APROBACIÓN DEL INFORME DE CIERRE Y ACEPTACIÓN DEL C IERRE Nombre del Proyecto: Nombre con el que se conoce el proyecto.
Fecha: Fecha en que se finaliza
De conformidad con los requerimientos solicitados para el proyecto y una vez finalizada las
etapas de pruebas y certificación y puesta en Producción por parte del usuario líder del
proyecto y su equipo de trabajo, se da el visto bueno correspondiente para la finalización.
Se procede con el cierre del proyecto con el acuerdo de Desarrollo de Sistemas, el
Patrocinador y el Líder del Proyecto, <Nombre >, <Nombre Patrocinador>, <Nombre del Líder
del Proyecto> respectivamente.
Las metas alcanzadas que respaldan el cierre son las siguientes: 1. Describir las metas que se obtuvieron al finalizar el proyecto. 2. 3.
<FIRMA> <FIRMA>
<FIRMA> <FIRMA>
69
5. -CONCLUSIONES
Después de haber desarrollado esta propuesta se puede confirmar que para cada área
de conocimiento de las planteadas en este PFG se encontró una forma de relacionarla
con la gestión de proyectos de desarrollo de software.
Asimismo, como validación de los resultados obtenidos, se puede evidenciar que cada
uno de los objetivos planteados al inicio se ha cumplido, tal y como se indica a
continuación:
⇒⇒⇒⇒ Se desarrolló un método sencillo que integra las mejores práctica del PMI (2004)
y el CVDS, que le permite a los departamentos de Tecnología, administrar los
procesos de proyectos de desarrollo de software y un conjunto de formularios
que le dan contenido y soporte a este marco.
⇒⇒⇒⇒ Dentro de la metodología se definieron las mejores prácticas para planificar y
controlar los proyectos desarrollo de software.
⇒⇒⇒⇒ Se logró exponer lo más claro posible los pasos a seguir en la metodología,
mediante la utilización de diagramas, que permiten representar la forma sencilla
de llevar a cabo la misma.
Se concluye que entre los beneficios esperados al aplicar la presente metodología se
encuentran:
⇒⇒⇒⇒ Mejorar la definición del alcance, planificación y cierre de los proyectos:
Mediante una especificación clara de los requerimientos del sistema,
planificando detalladamente cada aspecto que conlleva la gestión y
formalizando el cierre del proyecto, todo esto por medio de la aplicación de
las indicaciones expuestas en las secciones 4.2.2 Formulación de Proyectos,
4.2.3 Planificación de proyectos y 4.2.5 Cierre de proyectos.
⇒⇒⇒⇒ Control más oportuno de los proyectos: A través del seguimiento del
desempeño del proyecto en la fase de ejecución, de conformidad con lo
propuesto en la sección 4.2.4 Control y seguimiento, donde de forma sencilla
70
se puede detectar desviaciones y emprender las respectivas acciones
correctivas o preventivas.
⇒⇒⇒⇒ Estandarización de la información: Utilizando los formatos de la sección 4.2.6,
se hace posible tener mayor facilidad en la gestión documental del proyecto y
a la vez permite respaldar cada proceso y evidenciar la labor efectuada a lo
largo del proyecto.
71
6. -RECOMENDACIONES
La metodología propuesta busca ser una herramienta que sea de utilidad para los
Departamentos de Tecnología de la Información, precisamente las áreas de
Desarrollo de Software que consideren su aplicación. Si bien es cierto que se basó
en las mejores prácticas del PMI (2004) y se encuentra complementada con el ciclo
de vida del desarrollo de sistemas, para su implementación y uso en proyectos se
podrían incorporar mejoras, de acuerdo a las necesidades propias de la
organización que la aplique.
De esta manera, se recomienda al Líder de Proyectos, a los miembros de equipos
de proyectos y al lector en general lo siguiente:
⇒⇒⇒⇒ Un aspecto trascendental en el momento de implementar una metodología de
proyecto, consiste en el apoyo de la alta dirección de la empresa, debido a que
es primordial su intervención en las decisiones o acuerdos que se dan alrededor
de la implementación de la metodología.
⇒⇒⇒⇒ El punto anterior, se puede considerar como un factor crítico de éxito en la
aplicación de la metodología junto con la asignación adecuada de recursos.
⇒⇒⇒⇒ Esta metodología deberá ser del conocimiento de todos aquellos funcionarios
que se encuentren vinculados con proyectos de Desarrollo de Software, que por
sus funciones participan continuamente como involucrados o miembros de
equipos de proyecto.
⇒⇒⇒⇒ El Departamento de Tecnología de la Información en coordinación con el área de
Aprendizaje y Desarrollo de la organización, podrán diseñar un plan de
capacitación que permita sensibilizar al personal sobre la gestión de los
proyectos, para fomentar una cultura de proyectos interna.
⇒⇒⇒⇒ En esta propuesta metodológica solamente se incluyen como áreas de
conocimiento las correspondientes a alcance, tiempo, recurso humano, calidad e
integración. En la práctica el Líder de Proyectos puede incorporar otras áreas
que considere necesarias como costos, adquisiciones y riesgos con el fin de
72
ampliar los niveles de control y gestión de los proyectos de desarrollo de
software.
⇒⇒⇒⇒ Es importante que aquel Departamento de Tecnología que aplique esta
metodología considere necesario complementar otras técnicas y herramientas,
como por ejemplo, ruta crítica y valor ganado que le permitan obtener un mejor
desempeño del proyecto, esto conforme al nivel de madurez adquirido en esta
temática.
⇒⇒⇒⇒ Este PFG se sugiere como complemento en la formación de los profesionales de
informática, porque se incorporan aspectos de la Administración de Proyectos
que no son parte del programa de la carrera universitaria del ingeniero en
sistemas y que son vitales para su desempeño en el ambiente de desarrollo de
Software.
73
7. -BIBLIOGRAF ÍA Ciclo de vida de un sistema de información. http://www.monografias.com/trabajos29/ciclo-sistema/ciclo-sistema.shtml#biblio. Consultado el 21 de octubre del 2008. Chamoun, Yamal. Administración Profesional de Proyectos, La Guía. México, D.F: Mc Graw Hill, 2002. Cleland, David; Ireland, Lewis. Manual Portátil del Administrador de Proyectos. México, D.F: Mc Graw Hill, 2001. Gido, Jack; Clements, James. Administración Exitosa de Proyectos. Segunda edición. México, D.F: Thomson, 2003. McConell Steve. Desarrollo y gestión de proyectos informáticos. Segunda edición. México: Mc Graw Hill, 1997. P.M.I (Project Management Institute). Guía de los Fundamentos de la Dirección de Proyectos. PMBOK Guide. Tercera edición. Pennsylvania, E.E.U.U: P.M.I Publicaciones, 2004. Presman Roger. Ingeniería del Software. Cuarta edición. España: Edígrafos, S.A., 1997. Proceso Unificado de Rational. http://es.wikipedia.org/wiki/RUP. Conceptos de la metodología RUP. Consultado el 21 de octubre del 2008. Rodríguez, Nuria y Martínez William. Planificación y Evaluación de Proyectos Informáticos. 1era. Edición. McGraw Hill, 1998. Senn, James. Análisis y Diseño de Sistemas de Información. Segunda edición. México: Mc Graw Hill, 1992.
74
8.-ANEXOS
Anexo Nº 1 Plan de proyecto final de graduación Acta de Constitución
Información General del PFG Nombre del proyecto: Propuesta de una metodología para la administración
de proyectos de desarrollo de software para aplicación en Departamentos de Tecnología de la Información.
Fecha de elaboración: 04 de octubre del 2008
Áreas del conocimiento: ⇒⇒⇒⇒ Alcance ⇒⇒⇒⇒ Tiempo ⇒⇒⇒⇒ Recursos Humanos ⇒⇒⇒⇒ Calidad ⇒⇒⇒⇒ Comunicación ⇒⇒⇒⇒ Integración
Área de aplicación: Departamentos de Tecnologías de Información que requieren un modelo para gestionar sus proyectos de software
Fecha inicio del proyecto: 27 de setiembre del 2008
Fecha tentativa de término: 20 de diciembre del 2008
Objetivos del proyecto General:
Realizar una propuesta de una metodología de administración de proyectos de desarrollo de software para aplicación en departamentos de tecnología, orientada en los procesos de formulación, planificación, control y seguimiento y cierre y que a la vez permita estandarizar este proceso a lo interno de la organización que lo aplique.
Específico:
⇒⇒⇒⇒ Definir una metodología que permita administrar de forma adecuada los procesos de inicio, planificación, control y seguimiento y cierre de los proyectos para la implementación
75
de proyectos de desarrollo de software.
⇒⇒⇒⇒ Definir las técnicas y herramientas más adecuadas para planificar y controlar de modo efectivo los proyectos de desarrollo de software.
⇒⇒⇒⇒ Diseñar un conjunto de formatos que permitan documentar las principales actividades del proyecto desarrollo de software para respaldar cada acción y todos los documentos utilizados de forma estandarizada.
Descripción del producto El propósito es obtener un documento final donde se proponga un método para la administración de proyectos en Tecnología de la Información, sobre el ámbito del desarrollo de software que contenga esencialmente las siguientes especificaciones:
1.1 El método para la gestión de proyectos de desarrollo de software donde permita guiar paso a paso cómo se debe gestionar un proyecto mediante los grupos de procesos inicio, planificación, control y seguimiento y cierre de los proyectos.
1.2 Las técnicas que proporcionen manejar el monitoreo de forma efectiva y
oportuna en el desempeño de un proyecto. 1.3 Los estándares en el uso y manejo de la información mediante formatos que a
la vez funcionen como instrumentos de documentación y respaldo de cada actividad del proyecto.
Necesidad del proyecto La gestión de proyectos informáticos es un área que se ve continuamente emergida en críticas debido a los continuos proyectos convertidos en fracasos. El problema que acontece con los proyectos de desarrollo de software y que provoca que no lleguen a ser exitosos radica especialmente en que el profesional de informática es entrenado académicamente para conceptualizar los componentes técnicos que darán forma a un sistema de información.
Debido a esto, es común que sucedan problemas cuando el profesional de informática se orienta más a las ramas técnicas que a las administrativas, provocando que se le reste valor a las actividades de planeación y control. Dando como problemática el surgimiento de proyectos con mala definición del alcance,
76
planeación insuficiente, ausencia de controles Por este motivo acontece frecuentemente en los proyectos la ocurrencia de errores clásicos, que de acuerdo a Steve McConell (1997) se clasifican en personas, procesos, producto y tecnología. A continuación se definen algunos ejemplos de errores clásicos: Personas
⇒⇒⇒⇒ Añadir más personal a un proyecto atrasado. ⇒⇒⇒⇒ Expectativas poco realistas. ⇒⇒⇒⇒ Falta de participación de los implicados.
Procesos
⇒⇒⇒⇒ Planificación excesivamente optimista o insuficiente. ⇒⇒⇒⇒ Diseño inadecuado. ⇒⇒⇒⇒ Abandono de la planificación bajo presión ⇒⇒⇒⇒ Pérdida de tiempo en el inicio difuso.
Producto
⇒⇒⇒⇒ Mala definición de requerimientos ⇒⇒⇒⇒ Exceso de requerimientos. ⇒⇒⇒⇒ Cambios excesivos en requerimientos.
Tecnología
⇒⇒⇒⇒ Sobreestimación sobre las ventajas de una nueva herramienta. ⇒⇒⇒⇒ Cambiar de herramienta a mitad del proyecto.
Con respecto a los errores del producto causados por la mala definición de requerimientos, se considera como la principal componente del fracaso en los proyectos de desarrollo de software, ya que por lo general no están bien definidos desde el principio lo que conlleva a problemas durante su desarrollo. A menudo cuando se inicia un proyecto nadie parece saber aspecto tales como:
⇒⇒⇒⇒ ¿Cómo empezó el proyecto? ⇒⇒⇒⇒ ¿Cuáles actividades se han llevado a cabo? ⇒⇒⇒⇒ ¿Cuándo terminará el proyecto? ⇒⇒⇒⇒ ¿Cuál es el objetivo primordial del proyecto?
Cuando esto sucede lo usual es que el proyecto sea abandonado a mitad de su vida provocando fatalidad en el éxito del mismo, ya que el éxito de un proyecto está en el logro de su o sus objetivos mediante el cumplimiento del alcance, tiempo, costo y calidad definida.
77
Es por esta razón que se deben de realizar los análisis correspondientes de una adecuada forma de trabajo que permita evitar que el proyecto fracase. De esta manera, se hace necesario contar con un método que defina la forma idónea de administrar los proyectos de software de tal manera que se puedan evitar las razones de fracaso y se consolide la gobernabilidad de Tecnología. Justificación de impacto Los motivos por los cuales se plantea este proyecto obedecen a un principio de estandarizar los procesos que realizan las áreas de desarrollo de sistemas de las organizaciones, mejorándolos de paso para hacerlos más efectivos, que permitan optimizar los recursos organizacionales, dadas las actividades funcionales que deben realizar quienes participan de los proyectos como ejecutores del mismo. Además, también está estrechamente relacionado con el costo de oportunidad de sacar los proyectos en el menor tiempo posible y de la competitividad que ello puede significar para el negocio. De lo que se trata es de proponer un método sencillo, que le permita a los departamento de Tecnología de la información estandarizar este proceso y cimentar las bases para ir desarrollando una cultura en torno a la administración de proyectos con herramientas sencillas y considerando aspectos elementales para obtener resultados exitosos acorde con las necesidades y expectativas de las áreas organizacionales relacionadas. Lo que se pretende es generar una metodología que le permita a las áreas tecnológicas capitalizar el conocimiento, estandarizar, ordenar y sistematizar lo relacionado con proyectos. Específicamente los resultados esperados son:
⇒⇒⇒⇒ Mejor definición del alcance de los proyectos. ⇒⇒⇒⇒ Mayor uniformidad en el uso y manejo de la información. ⇒⇒⇒⇒ Control más oportuno y eficaz de los proyectos. ⇒⇒⇒⇒ Estandarización de la información y formatos.
Restricciones La principal limitación que posee el proyecto, es el tiempo establecido para iniciar y finalizar el mismo. Identificación de grupos de interés Directo : Personal de Tecnología de la información Indirecto: Estudiantes de la maestría de administración de proyectos de la UCI. Aprobación Realizado por: Andrea Elizondo Aguilar Firma: Aprobado por: Firma:
78
Anexo Nº 2 Estructura detallada de trabajo (EDT)
79
Anexo Nº 3 Cronograma del Proyecto Final de Graduac ión
80
Cronograma del Proyecto Final de Graduación (contin ua…)
81
Cronograma del Proyecto Final de Graduación (contin ua…)
82
Anexo Nº 4 Integración de los Elementos de la Metodología
Capítulo Ítem Herramienta que aplica Proceso Área Conocimiento
Ciclo Vida Desarrollo Sistemas
a) Identificación del proyecto FOR-01 Identificación del proyecto b) Alcance del proyecto FOR-02 Alcance del proyecto b.1) Estudio de viabilidad FOR-03 Estudio de viabilidad
4.2.2 Formulación de
proyectos b.2) Análisis de requerimientos FOR-04 DERCA
Inicio Integración -Identificación de requerimientos -Análisis de sistemas
a) Planificación de las actividades a.1) Descomposición del alcance EDT Alcance a.2) Definir actividades a.3) Secuenciar a.4) Estimación de la duración Juicio Experto a.5) Desarrollo del cronograma Cronograma
Tiempo
b) Planificación del recurso humano
FOR-05 Identificación de roles y responsabilidades. Recurso Humano
c) Planificación de los elementos desarrollo SW.
Alcance
c.1) Diseño del sistema FOR-04 DERCA Alcance -Diseño del sistema c.2) Desarrollo del sistema -Desarrollo del sistema c.3) Pruebas FOR-08 Documentación de Pruebas Calidad -Pruebas
Capacitación Recurso Humano -Implantación Puesta en marcha
4.2.3 Planificación de
proyectos
c.4) Implantación Entrega del producto
Planificación
a) Administración efectiva de cambios
FOR-09 Control de cambios Integración
b) Informes de avance FOR-06 Informe de Avance Comunicación c) Reuniones de seguimiento FOR-07 Minuta Comunicación
4.2.4 Control y seguimiento
d) Aprobación de entregables FOR-10 Aprobación de entregables
Control
Calidad -Implantación a) Carta de aprobación final FOR-11 Acta de cierre
b) Informe por cancelación Documentar la justificación de la cancelación del proyecto 4.2.5 Cierre
c) Lecciones aprendidas Documentar las secciones de grupo
Cierre Integración