Embed Size (px)
Citation preview
UNIVERSIDAD PARA LA COOPERACIÓN INTERNACIONAL (UCI)
PROPUESTA METODOLÓGICA PARA LA ADMINISTRACIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE A LA MEDIDA Y MODELADO DE BASES DE
DATOS BASADO EN LA GUIA DEL PMI
JOAN SABORÍO OBANDO
PROYECTO FINAL DE GRADUACIÓN PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR POR EL TÍTULO DE MÁSTER EN ADMINISTRACIÓN
DE PROYECTOS
San José, Costa Rica
Julio, 2009
ii
UNIVERSIDAD PARA LA COOPERACIÓN INTERNACIONAL (UCI)
Este Proyecto Final de Graduación fue aprobado por la Universidad como requisito parcial para optar al grado de Máster en Administración de Proyectos.
__________________________ Ing. Mario López Soto, MAP
PROFESOR TUTOR
_________________________ Ing. Ramiro Fonseca Macrini
LECTOR No.1
__________________________ Ing. Fabio Muñoz Jiménez, MBA, Msc
LECTOR No.2
________________________ Joan Saborío Obando
SUSTENTANTE
iii
Dedicatoria
Este proyecto lo dedico a mi familia que a lo largo de toda mi vida
me ha brindado el apoyo incondicional en cada decisión y paso que
he dado, esta es una meta más que alcanzo gracias a ellos.
También a mis amigos que me han acompañado, apoyado y
empujado a buscar nuevos retos y cumplirlos.
iv
Agradecimientos
A mi tutor, don Mario López por todo el apoyo que me brindó durante
la elaboración de este proyecto de principio a fin.
A los lectores por la ayuda y las recomendaciones que me
permitieron mejorar la calidad de este proyecto.
Y finalmente a los profesores y compañeros de la UCI por el aporte
que cada uno de ellos tuvo para que yo pudiera realizar este proyecto
y completar la maestría.
v
Índice de Contenido
RESUMEN EJECUTIVO XI
1 INTRODUCCIÓN 13
1.1 ANTECEDENTES 13
1.2 PROBLEMÁTICA 15
1.3 JUSTIFICACIÓN 16
1.4 OBJETIVO GENERAL 17
1.5 OBJETIVOS ESPECÍFICOS 17
2 MARCO TEÓRICO 18
2.1 MARCO REFERENCIAL 18
2.1.1 INSTITUTO INTERAMERICANO DE COOPERACIÓN PARA LA AGRICULTURA (IICA) 18
2.1.2 GENERALIDADES DE PROYECTOS DE TI 20
2.2 TEORÍA DE TECNOLOGÍAS DE INFORMACIÓN 23
2.2.1 DEFINICIONES GENERALES 23
2.2.2 CICLOS DE VIDA DEL SOFTWARE 25
2.2.3 OUTSOURCING 28
2.2.4 OBTENCIÓN DE REQUERIMIENTOS 29
2.2.5 BASES DE DATOS: DIAGRAMAS ENTIDAD RELACIÓN 36
2.2.6 ESTIMACIÓN DE TIEMPO Y COSTO 39
2.3 TEORÍA DE LA ADMINISTRACIÓN DE PROYECTOS 45
2.3.1 CONCEPTOS GENERALES 45
2.3.2 CICLO DE VIDA DE UN PROYECTO 46
2.3.3 GRUPOS DE PROCESOS 47
2.3.4 ÁREAS DE CONOCIMIENTO 48
3 MARCO METODOLÓGICO 77
3.1 FUENTES DE INFORMACIÓN 77
3.2 MÉTODOS DE INVESTIGACIÓN 77
3.3 HERRAMIENTAS DE INVESTIGACIÓN 78
3.4 CREACIÓN DE LA METODOLOGÍA 79
4 DESARROLLO DE LA METODOLOGÍA 80
4.1 INTRODUCCIÓN 80
4.2 INICIO 80
4.2.1 ACTA DE CONSTITUCIÓN DEL PROYECTO (CHARTER) 81
4.2.2 MODULAR EL PROCESO 82
vi
4.2.3 ANÁLISIS DE ENFOQUE DE LOS PARTICIPANTES 84
4.3 PLANIFICACIÓN 84
4.3.1 PLAN DE GESTIÓN DE ALCANCE 84
4.3.2 PLAN DE GESTIÓN DE TIEMPO 91
4.3.3 PLAN DE GESTIÓN DE COSTO 96
4.3.4 PLAN DE GESTIÓN DE RIESGOS 99
4.4 EJECUCIÓN 106
4.4.1 DIRECCIÓN Y GESTIÓN 106
4.4.2 HERRAMIENTAS 106
4.5 SEGUIMIENTO Y CONTROL 108
4.5.1 CONTROL INTEGRADO DE CAMBIOS 108
4.5.2 VERIFICACIÓN DE ALCANCE 111
4.5.3 VALOR GANADO 112
4.5.4 REPORTES DE SEGUIMIENTO Y CONTROL 113
4.6 CIERRE 118
4.7 RESUMEN GENERAL 120
4.8 CASO PRÁCTICO 124
4.8.1 INICIO 124
4.8.2 PLANIFICACIÓN 125
4.8.3 EJECUCIÓN 132
4.8.4 SEGUIMIENTO Y CONTROL 133
4.8.5 CIERRE 134
5 CONCLUSIONES 136
6 RECOMENDACIONES 138
6.1 GENERALES 138
6.2 DE GESTIÓN DE PROYECTOS 139
6.3 AL IICA 140
BIBLIOGRAFÍA 141
ANEXOS 143
1. ACTA DE CONSTITUCIÓN (CHARTER) 144
2. ESTRUCTURA DETALLADA DE TRABAJO 148
3. CRONOGRAMA 149
vii
Índice de Figuras
Figura 1: Organigrama del IICA __________________________________________________________ 19
Figura 2: Los 4 factores de éxito en proyectos de TI ___________________________________________ 22
Figura 3: Capas de la ingeniería de software _________________________________________________ 24
Figura 4: Modelo lineal secuencial _________________________________________________________ 25
Figura 5: El paradigma de construcción de prototipos __________________________________________ 26
Figura 6: El modelo incremental ___________________________________________________________ 27
Figura 7: Modelo espiral típico ____________________________________________________________ 27
Figura 8: Desarrollo basado en componentes ________________________________________________ 28
Figura 9: Representación del actor _________________________________________________________ 31
Figura 10: Representación de un caso de uso _________________________________________________ 32
Figura 11: Relaciones de casos de uso ______________________________________________________ 32
Figura 12: Diagrama de clases ____________________________________________________________ 33
Figura 13: Diagrama de secuencia (Sparx Systems) ____________________________________________ 34
Figura 14: Caso de uso de ingreso a sistema _________________________________________________ 35
Figura 15: Ejemplo de diagrama Entidad Relación ____________________________________________ 38
Figura 16: Análisis de puntos de función ____________________________________________________ 40
Figura 17: Diagrama de funcionalidad de un sistema por medio de los 5 componentes ________________ 41
Figura 18: Secuencia de fases típica de un ciclo de vida del proyecto ______________________________ 47
Figura 19: Correspondencia de los grupos de procesos de dirección de proyectos al ciclo de Planificar-
Hacer-Revisar-Actuar ___________________________________________________________________ 47
Figura 20: Grupos de procesos ____________________________________________________________ 48
Figura 21: Nueve áreas por considerar en la Administración Profesional de Proyectos (APP) __________ 49
Figura 22: Triángulo Alcance-Tiempo-Costo-Calidad __________________________________________ 49
Figura 23: Ejemplo de diagrama PDM ______________________________________________________ 60
Figura 24: Ejemplo de línea base de costo ___________________________________________________ 64
Figura 25: Diagrama Causa-Efecto (Ishikawa) _______________________________________________ 70
Figura 26: Diagrama de flujo _____________________________________________________________ 71
Figura 27: Ejemplo - Proceso de solicitud de cambio __________________________________________ 83
Figura 28: Ejemplo de EDT ______________________________________________________________ 88
Figura 29: Ejemplo de lista de actividades ___________________________________________________ 92
viii
Índice de Tablas
Tabla 1: Factores de éxito de proyectos de TI _________________________________________________ 20
Tabla 2: Complejidad de funciones de datos __________________________________________________ 41
Tabla 3: Complejidad de funciones transaccionales ____________________________________________ 42
Tabla 4: Resumen de puntos de función sin ajustar ____________________________________________ 42
Tabla 5: Herramientas del plan del proyecto que apoyan el cierre ________________________________ 53
Tabla 6: Métodos para presupuesto base ____________________________________________________ 65
Tabla 7: Plantilla - Acta de constitución o Charter ____________________________________________ 81
Tabla 8: Plantilla - Mapa de expectativas ____________________________________________________ 84
Tabla 9: Plantilla – Enunciado de alcance ___________________________________________________ 85
Tabla 10: Plantilla - Especificación de caso de uso ____________________________________________ 86
Tabla 11: Plantilla - Plan de gestión de alcance _______________________________________________ 88
Tabla 12: Plantilla - Diccionario de EDT ____________________________________________________ 91
Tabla 13: Plantilla - Asignación de recursos _________________________________________________ 92
Tabla 14: Plantilla - Estimación de puntos de función __________________________________________ 93
Tabla 15: Plantilla - Plan de gestión de tiempo _______________________________________________ 95
Tabla 16: Plantilla - Presupuesto por fase ___________________________________________________ 97
Tabla 17: Plantilla - Plan de gestión de costos ________________________________________________ 97
Tabla 18: Plantilla - Registro de riesgos ____________________________________________________ 101
Tabla 19: Plantilla - Matriz de probabilidad e impacto ________________________________________ 102
Tabla 20: Plantilla - Análisis cualitativo de riesgos ___________________________________________ 102
Tabla 21: Plantilla - Matriz de responsabilidad de riesgos _____________________________________ 103
Tabla 22: Roles de responsabilidad _______________________________________________________ 103
Tabla 23: Plantilla - Plan de contingencia __________________________________________________ 104
Tabla 24: Plantilla - Plan de gestión de riesgos ______________________________________________ 104
Tabla 25: Herramientas del plan del proyecto que apoyan la ejecución ___________________________ 106
Tabla 26: Plantilla - Minuta _____________________________________________________________ 107
Tabla 27: Plantilla - Lecciones aprendidas __________________________________________________ 108
Tabla 28: Plantilla - Solicitud de cambio ___________________________________________________ 109
Tabla 29: Plantilla - Informe de avance ____________________________________________________ 110
Tabla 30: Plantilla - Registro de aceptación de entregables _____________________________________ 111
Tabla 31: Plantilla - Costo Total Planificado (CPA) __________________________________________ 112
Tabla 32: Plantilla - Costo Real Acumulado (CRA) ___________________________________________ 112
Tabla 33: Plantilla - Cuadro resumen de valor ganado ________________________________________ 113
ix
Tabla 34: Plantilla - Informe de seguimiento mensual _________________________________________ 113
Tabla 35: Plantilla - Informe de seguimiento semanal _________________________________________ 114
Tabla 36: Plantilla - Scoreboard __________________________________________________________ 116
Tabla 37: Simbología para Scoreboard_____________________________________________________ 116
Tabla 38: Plantilla - Historial de versiones de los documentos __________________________________ 117
Tabla 39: Plantilla - Reporte final _________________________________________________________ 118
Tabla 40: Ejemplo: Charter _____________________________________________________________ 124
Tabla 41: Ejemplo: Especificación de Caso de Uso ___________________________________________ 126
Tabla 42: Ejemplo: Plan de Gestión de Alcance ______________________________________________ 127
Tabla 43: Ejemplo: Estimación de Puntos de Función _________________________________________ 130
Tabla 44: Ejemplo: Minuta ______________________________________________________________ 132
Tabla 45: Ejemplo: Informe de Avance _____________________________________________________ 133
Tabla 46: Ejemplo: Reporte Final _________________________________________________________ 134
x
Índice de Abreviaturas
AP: Administración de Proyectos.
APP: Administración Profesional de Proyectos.
BD: Base de Datos.
CASE: Computer Aided Software Engineering (Ingeniería de Software Asistida por
Computadora.
EDT: Estructura Detallada de Trabajo.
IEEE: Institute of Electrical and Electronics Engineers (Instituto de Ingenieros
Eléctricos y Electrónicos)
IICA: Instituto Interamericano de Cooperación para la Agricultura.
PFG: Proyecto Final de Graduación.
PMBOK: Project Management Body Of Knowledge (Guía de los fundamentos de
la dirección de proyectos).
PMI: Project Management Institute (Instituto de Administración de Proyectos)
TI: Tecnologías de Información.
UML: Unified Modeling Language (Lenguaje Unificado de Modelado).
xi
Resumen Ejecutivo
En la historia, los proyectos de software han tenido poco éxito en términos de planificación y ejecución particularmente en aspectos de costo, tiempo y calidad. Con el paso del tiempo se ha intentado contrarrestar este fenómeno por medio de la implementación de nuevas tendencias como lo es la gestión de proyectos, propuestas de buenas prácticas, entre otras que si bien son diferentes entre sí, buscan un objetivo común, una gestión de proyectos oportuna y eficaz.
El objetivo principal de este proyecto es generar la propuesta de una metodología que combine los principios de la administración de proyectos con distintos aspectos de tecnologías de información, específicamente en el tema de desarrollo de software a la medida y modelado de bases de datos permitiendo así mejorar los procesos.
Específicamente se centrará en las áreas de conocimiento de alcance, tiempo, costo, riesgos e integración las cuales se desarrollarán por medio de definición de políticas, roles y responsabilidades y modelado de procesos. Adicionalmente se propondrán herramientas, técnicas y plantillas adaptadas a las necesidades de este tipo de proyectos, las cuales permitirán diseñar, planificar, ejecutar y brindar seguimiento y control con mayor facilidad.
La investigación será la técnica más importante y base para la realización de este proyecto, se investigará acerca de asuntos afines al tema a desarrollar, como lo son la administración de proyectos, tecnologías de información, ingeniería de software y otras tendencias utilizadas para el desarrollo de sistemas de información. Además se utilizarán como medio de apoyo herramientas como plantillas, software, diagramas, entre otras.
El proceso se dividirá en dos etapas, en la primera se realizará la investigación y en la segunda el procesamiento de la información recopilada y el desarrollo de las políticas, procedimientos, plantillas, herramientas entre otros aspectos que finalmente darán como resultado la propuesta antes mencionada. Ambas etapas se realizarán para cada una de las cinco áreas de conocimiento definidas, esto con el fin de facilitar las revisiones periódicas y retroalimentación durante el desarrollo e implementación de este PFG.
La metodología combina aspectos de ingeniería de software y de gestión de proyectos. Esta solución permite una administración de proyectos flexible y oportuna, una organización y estandarización de los procesos de TI y una documentación adecuada de los mismos para enriquecer los activos de proceso de la empresa.
Entre los aspectos clave que se determinan en esta metodología para una administración exitosa de este tipo de proyectos, se encuentran: un correcto análisis de requerimientos, una continua motivación y capacitación del personal,
xii
documentación adecuada de lecciones aprendidas y la necesidad de adaptar las herramientas y procesos de acuerdo a las necesidades de las empresas y del mercado, sobre todo en el cambiante mundo de TI.
Esta herramienta puede servir como guía para cualquier empresa que desarrolle software a la medida, en particular se desarrolló tomando en cuenta la realidad que se presenta en el IICA y tomando en consideración que una empresa como ésta, lleva un proceso gradual de implementación, comenzando por la capacitación adecuada de los involucrados.
Para sacar el mayor provecho de la metodología es aconsejable llevar a cabo una investigación continua en aspectos de TI, de gestión de proyectos y de mercado, esto permitirá mantener una herramienta actualizada y adaptada a las nuevas tendencias. A su vez debe desarrollarse un proceso de capacitación del personal para lograr una óptima gestión.
Otra de las recomendaciones importantes es que esta herramienta debe adoptarse tomando como premisa que siempre hay posibilidades de mejora, para esto es necesario probarla y analizar periódicamente la documentación que se genera, las lecciones aprendidas, las normas y procedimientos establecidos, para lograr pulir cada vez más la administración de proyectos con sus plantillas, procesos, entre otros.
Finalmente, para potenciar su valor, se recomienda realizar revisiones periódicas a la documentación como parte del seguimiento y mantener la información relacionada al alcance de todos, facilitando así la comunicación y gestionando de manera clara y concisa información referente al estado de proyecto, roles y responsabilidades de los involucrados.
13
Capítulo 1
1 Introducción
Las tecnologías de información se encuentran en constante cambio, por lo tanto
deben adaptarse al entorno, a las necesidades de las empresas y de las personas,
en general son un área de conocimiento que se reinventa y evoluciona a una
velocidad acelerada, principalmente para mejorar y facilitar la calidad de vida de
las personas en los diferentes ámbitos.
Debido a este gran crecimiento las empresas necesitan diferenciarse de la
competencia y asegurarse un lugar en el mercado. Una de las tendencias que más
ha tenido impacto en este tipo de tecnologías es la administración de proyectos,
ya que se ha comprobado que logra mejorar los procesos e incrementar el éxito de
los productos o servicios a desarrollar.
El campo de desarrollo de software no es la excepción, hoy en día este tipo de
empresas suelen apoyarse en metodologías de administración de proyectos con el
fin de alinear procesos en las áreas de interés, las cuales no necesariamente son
todas, pero deben ser las que causan un mayor impacto a corto o mediano plazo
en el producto final.
1.1 Antecedentes
Como es bien sabido todo proyecto cuenta con una serie de factores que los hace
complejos y conllevan ciertos riesgos que hay que tomar en cuenta en todo
momento. En el caso de los proyectos de tecnologías de información se suman
otras variables más, por ejemplo que esta industria es sumamente cambiante lo
que ocasiona que existan diversas opciones para elegir una tecnología, un
lenguaje de programación, un sistema gestor de base de datos o una plataforma,
el problema es que no necesariamente hay una relación de compatibilidad de
todos contra todos y esto da, naturalmente como resultado un continuo proceso de
14
investigación, actualización de equipo y herramientas para estar funcionando el
100% de tiempo y no perder competitividad.
Además estas empresas tienden a ser volátiles, debido al gran crecimiento que se
ha dado, no es raro ver que empresas grandes compren o se fusionen con otras
haciendo todavía más cambiante el mercado y los productos que éste ofrece.
La novedad e innovación de nuevas tecnologías es una particularidad más que se
suma a la lista. Esto puede brindar una ventaja competitiva a una empresa si logra
asumir el riesgo de incursionar en ella, pero por otro lado también conlleva un
riesgo muy grande no solo por que el resultado es un tanto incierto, sino también
por los costos en términos de tiempo y presupuesto, sobre todo por la curva de
aprendizaje que tendrá que asumir el personal involucrado.
Estos y otros factores han ocasionado que los proyectos de software tengan una
cierta mala fama asociada, como lo señala el “Chaos Report” (Standish, 1995) en
el cual se revelan datos alarmantes con respecto a este tipo de proyectos, entre
las cifras que resultan más relevantes encontramos que en el momento de estudio
(1995) típicamente los proyectos terminaban costando mucho más de lo planeado,
se estima que un 52.7% de los proyectos terminan con un sobre costo de 189%,
además se muestra que solo un 31.1% de los proyectos que se plantean se
terminan llevando a cabo.
Entre los datos que más resaltan de este reporte, es el hecho de que se estima
que solo un 9% de los proyectos terminan cumpliendo lo planteado con respecto a
tiempo y costo, como ya se menciona anteriormente resulta inquietante conocer
estas cifras, que si bien seguramente se ha disminuido la brecha, todavía falta
camino por recorrer para eliminarla y una correcta gestión de proyectos puede ser
la respuesta para resolverlo.
Existen muchas empresas que presentan esta problemática debido a la incorrecta
o nula gestión de proyectos, además de la falta de claridad con respecto a
procedimientos y políticas para el desarrollo de software. Este, de hecho es el
caso del IICA que viene a ser una de las razones por las cuales se crea esta
15
metodología, para normalizar los procesos y permitir una mejora de gestión en la
unidad de Informática, específicamente en el área de sistemas de información.
1.2 Problemática
Los sistemas de información se han convertido en un factor determinante e
indispensable para la operación exitosa de las empresas e instituciones y se ha
creado una gran dependencia al uso de los mismos, muchísimas empresas
alrededor del mundo se dedican al desarrollo de este tipo de sistemas buscando
satisfacer las necesidades de los clientes y posicionarse en el mercado.
Las empresas desarrolladoras de software comenzaron a incursionar en este
mercado de manera un tanto empírica, esto frecuentemente ocasionaba
problemas en los proyectos, debido a que no existía un adecuado planeamiento
para llevar a cabo las diferentes tareas y actividades, no se contaba con
herramientas y técnicas para la gestión y control de tiempo, la estimación de
costos era inefectiva, la calidad de los productos cuestionable y la definición de
requerimientos imprecisa.
En los últimos años en nuestro país ha habido una gran influencia de inversión
extranjera y una gran cantidad de empresas internacionales se encuentran
operando, esto nos ha impulsado a mejorar los procesos con el fin de competir,
pero el cambio no es nada sencillo, la mayoría de las empresas nacionales, ya
sean pequeñas o medianas se encuentran en el nivel “caótico” de cualquier
modelo de madurez y aunque normalmente esto no sea percibido por el cliente, ya
que este solo ve los productos finales, para aquellos vinculados con este tipo de
organizaciones es notable que la operación puede y debe optimizarse, mejorando
así no solo la calidad del producto final sino también distintos aspectos en la etapa
de implementación y desarrollo del mismo, que pueden ir desde los niveles de
estrés que manejan los involucrados cuando la fecha de entrega se aproxima
hasta la disminución de tiempo y costo.
16
1.3 Justificación
Actualmente existe una variedad de modelos y metodologías a seguir para
administrar proyectos y si bien es cierto brindan una gran ayuda para el desarrollo
de las organizaciones, también este tipo de propuestas se pueden adoptar y
mejorar en busca de una solución óptima, de manera que se personalicen,
modifiquen y fortalezcan los aspectos que tienen un mayor impacto en el nicho de
mercado que se desea impactar.
Es importante mencionar que no todas las empresas cuentan con la posibilidad de
implementar un costoso modelo ya que esto implica una inversión importante no
solo a nivel de presupuesto sino también a nivel de tiempo y recursos humanos
principalmente.
Por lo tanto, con el fin de solventar los aspectos planteados es que nace la
inquietud de desarrollar una metodología sencilla y versátil que pueda ser
adaptada a cualquier empresa que se dedique a brindar este tipo de servicios, la
idea es normalizar el proceso de desarrollo de software y modelado de bases de
datos dentro del marco de la administración de proyectos para que éstos puedan
ser desarrollados de la manera más exitosa posible, i.e. desarrollando los
requerimientos, cumpliendo los plazos y el presupuesto, entre otros.
Se pretende complementar las herramientas y técnicas de la Administración de
Proyectos con sus homónimos para el desarrollo de software tomando en
consideración factores y características propios de este tipo de proyectos,
facilitando de manera un tanto general la gestión, lo cual brindará sin duda una
ventaja competitiva.
17
1.4 Objetivo General
Desarrollar una propuesta metodológica para la administración de proyectos de
Tecnologías de Información, específicamente en el área desarrollo de software a
la medida y modelado de bases de datos.
1.5 Objetivos Específicos
• Definir políticas que apliquen para la correcta administración de los
proyectos de sistemas de información.
• Determinar los grupos de procesos, áreas de conocimiento, procedimientos,
y otros aspectos que intervienen en la gestión de proyectos de este tipo.
• Proponer el uso de herramientas y técnicas, generar plantillas adecuadas a
la administración de este tipo de proyectos.
• Definir los roles y responsabilidades de los Stakeholders en los proyectos
de desarrollo de software a la medida y modelado de bases de datos.
• Desarrollar una metodología para la gestión de las áreas de conocimiento
Alcance, Tiempo, Costo, Riesgos e Integración para proyectos de TI.
18
Capítulo 2
2 Marco Teórico
2.1 Marco Referencial
2.1.1 Instituto Interamericano de Cooperación para la Agricultura (IICA)
Este instituto forma parte de la Organización de Estados Americanos (OEA), está
compuesto por 34 oficinas, que corresponden a países a lo largo del continente
americano desde Canadá hasta Chile y la Sede Central que se encuentra situada
en nuestro país, la cual se encarga de coordinar proyectos en temas de
agricultura, brindar cooperación en distintos aspectos técnicos y manejar el
presupuesto de manera centralizada.
2.1.1.1 Misión
El IICA es la organización del Sistema Interamericano especializada en la
agricultura y el medio rural cuyo propósito es proveer cooperación técnica
innovadora a los Estados Miembros, para lograr su desarrollo sostenible en
beneficio de los pueblos de las Américas. (IICA, 2008)
2.1.1.2 Visión
Ser la institución de la agricultura líder en las Américas y socio preferente por la
calidad de su cooperación técnica en respuesta a las necesidades de los Estados
Miembros y por sus contribuciones al desarrollo sostenible de la agricultura, la
seguridad alimentaria y la prosperidad rural. (IICA, 2008)
19
2.1.1.3 Organización
El IICA se encuentra organizado de la siguiente manera:
Figura 1: Organigrama del IICA
(IICA, 2006)
La sede central está compuesta por siete direcciones y cada una de ellas por
unidades, el área de Telecomunicaciones y Tecnologías de Información
actualmente debido a un cambio organizacional que se realizó de acuerdo a la
Orden Ejecutiva No. 23 (IICA, 2006), forma parte de la dirección de Liderazgo
Técnico y Gestión del Conocimiento, en esta unidad se maneja todo lo referente a
soporte técnico, telecomunicaciones y sistemas de información, los desarrollos
que se realizan son internos y tienen como finalidad satisfacer las necesidades de
los clientes internos, es decir las unidades y divisiones.
20
En términos de administración de proyectos y buenas prácticas, el IICA es un
típico ejemplo de una organización que no tiene definidos ni procesos ni políticas
para normalizar el desarrollo del software, los proyectos que se realizan no se
formalizan mediante un Acta de Constitución ni nada semejante, sino que se
llevan a cabo “día a día” y generalmente son desarrollados por una sola persona,
la cual cumple con los roles de director de proyecto, líder técnico y desarrollador.
Adicionalmente no existe ningún tipo de plantilla, procedimiento o política para el
desarrollo de software, este tipo de proyectos se desarrollan empíricamente y a
discreción del desarrollador, además no se cuenta con una metodología para
diseñar, planificar y controlar un proyecto.
La propuesta de administración de proyectos que se pretende desarrollar nace
precisamente con el fin de solventar este tipo de situaciones, de manera que se
logre normalizar, orientar y mejorar los procesos en caso de que existan o bien
adoptar los que se proponen para incrementar la efectividad de los proyectos de
desarrollo de software.
2.1.2 Generalidades de proyectos de TI
Este tipo de proyectos se han caracterizado por no cumplir el tiempo estipulado, el
costo presupuestado y la calidad esperada, este problema se ha dado
principalmente por ser un área de conocimiento relativamente nueva lo que
ocasiona que los proyectos no estén tan parametrizados y puntualizados como
otros. Según el Chaos Report (Standish, 1995) existen varios aspectos que se
vuelven indispensables para el éxito de estos proyectos, a continuación se
muestra la tabla con estos factores y su respectivo porcentaje de influencia:
Tabla 1: Factores de éxito de proyectos de TI (Standish, 1995)
Factores de Éxito % de Respuesta
1. Involucramiento del usuario 15.9%
2. Apoyo de la alta gerencia 13.9%
3. Definición clara de requerimientos 13.0%
4. Planeación adecuada 9.6%
21
5. Expectativas realistas 8.2%
6. Hitos más pequeños 7.7%
7. Competencia del personal 7.2%
8. Propiedad 5.3%
9. Objetivos y visión clara 2.9%
Otra propuesta interesante la desarrolla el autor Eliezer Cavazos en donde realiza
una agrupación de aspectos según cuatro factores clave:
1. Negociación
Etapa central del proyecto, en donde se puede identificar si el proyecto será
exitoso o no, qué aspectos ponen en riesgo el alcance el mismo y cuáles son las
expectativas de ambas partes. Se definen dos tipos de negociaciones: Interna (del
cliente o usuario final) y Externa (del departamento de TI o proveedor externo)
2. Tecnología
Consiste en la elección de la tecnología a utilizar, la cual se define por criterios de
costo, infraestructura o políticas de empresa y propuesta del proveedor
seleccionado.
3. Metodología
Debe adaptarse a las características del proyecto e implementarse de manera que
cumpla con las expectativas funcionales y de negocio. Consiste de reglas,
políticas, técnicas y procedimientos para el seguimiento del desarrollo de un
proyecto. (Cavazos, 2008)
4. Recursos
Se refiere a los recursos humanos involucrados, factores como perfiles de
conocimiento, experiencia, metodología de trabajo y tecnología.
Figura
Adicionalmente este tipo de proyectos cuenta con características
como particulares, en este caso se citará la lista de ítems definida por Hurtado en
su artículo Estimación de Proyectos
a. Poder adaptarse a
b. Considerar el costo de comunicación entre personas.
c. Incorporar guías útiles para estimar aquellos parámetros que son subjetivos
o no se deducen en forma explícita a partir del modelo.
d. Usable.
e. Constar de etapas simples d
f. Objetivo.
g. Costo efectivo.
h. Proveer medios para adaptarse a cambios en el ambiente de desarrollo.
i. Permitir una estimación temprana.
Figura 2: Los 4 factores de éxito en proyectos de TI
(Cavazos, 2008)
Adicionalmente este tipo de proyectos cuenta con características tanto importantes
en este caso se citará la lista de ítems definida por Hurtado en
Estimación de Proyectos (Hurtado, 2006):
Poder adaptarse a la productividad de la organización.
Considerar el costo de comunicación entre personas.
Incorporar guías útiles para estimar aquellos parámetros que son subjetivos
o no se deducen en forma explícita a partir del modelo.
Constar de etapas simples de entender y definidas en forma precisa.
Proveer medios para adaptarse a cambios en el ambiente de desarrollo.
Permitir una estimación temprana.
22
tanto importantes
en este caso se citará la lista de ítems definida por Hurtado en
Incorporar guías útiles para estimar aquellos parámetros que son subjetivos
e entender y definidas en forma precisa.
Proveer medios para adaptarse a cambios en el ambiente de desarrollo.
23
2.2 Teoría de Tecnologías de Información
2.2.1 Definiciones Generales
Tecnologías de Información
Conjunto de servicios, redes, software u otros que tienen como finalidad mejorar la
calidad de vida de las personas dentro de un entorno dado y que se integran a un
sistema de información interconectado y complementario.
Software
Término utilizado para describir una colección de programas computacionales y
documentación que realiza ciertas tareas en un sistema computacional. Existen
diversas definiciones, por ejemplo Pressman (2002) lo define como cualquier
artefacto de información almacenado en una computadora, en donde se definen
tres tipos:
- Programas, que consisten en un conjunto de instrucciones que la
computadora debe ejecutar.
- Estructuras de datos que le permiten a los programas manipular la
información que necesitan.
- Información utilizada por los programas.
Para esta investigación se asumirá el término de acuerdo a la primera definición.
Base de Datos
Es una colección de datos lógicamente relacionados, que pueden tener cualquier
tamaño y complejidad.
Proceso
Conjunto de herramientas, métodos y prácticas, que mantiene unidas las capas de
tecnología y permite un desarrollo racional.
24
Ingeniería de Software
La IEEE define este término como “la aplicación de un enfoque sistemático,
disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del
software”.
Con el fin de complementar un poco esta definición Pressman, lo define como una
“tecnología multicapa que debe apoyarse sobre un compromiso de calidad que
parte de la organización”, en donde las capas que lo componen son las siguientes:
Figura 3: Capas de la ingeniería de software
(Pressman, 2002) Este concepto ayuda a comprender que en el ámbito de informática, este es un
modo de enfocar los problemas y de gestionar una solución óptima.
Herramientas CASE
Por sus siglas en inglés Computer Aided Software Engineering (Ingeniería de
Software Asistida por Computadora), son sistemas de soporte para el desarrollo
de software, proporcionan un enfoque automático o semi-automático para el
proceso y para los métodos, permitiendo así aumentar la productividad en el
desarrollo de software reduciendo el costo de las mismas en términos de tiempo y
dinero.
Apoyan el desarrollo de proyectos desde el proceso de diseño, cálculo de costos
hasta la implementación, documentación o detección de errores automática.
Un enfoque de calidad
Procesos
Métodos
Herramientas
25
2.2.2 Ciclos de vida del software
Es de vital importancia definir cuál es el ciclo de vida más adecuado para el
desarrollo un proyecto de software, esto debe realizarse por medio de un análisis
cruzado entre la lista de factores que se presenta a continuación y las
características de cada uno de los modelos.
� El tipo de empresa y su modelo de desarrollo.
� Tiempo del que se dispone para el desarrollo del proyecto.
� Cantidad de recursos disponibles.
� Posibilidad de generar prototipo inicial y su utilidad.
� Calidad de la comunicación con el cliente final.
� Capacidad de segregar en módulos los distintos componentes del software
e independencia entre ellos.
2.2.2.1 Modelo Lineal Secuencial
También llamado ciclo de vida básico o modelo en cascada, consiste básicamente
en que los sistemas progresan de manera gradual siguiendo secuencialmente las
siguientes etapas: análisis, diseño, codificación, pruebas y mantenimiento. Este
modelo no es muy utilizado realmente debido a que no se considera muy eficaz,
puede ocasionar problemas si los requerimiento no se encuentran claros y
especificados al iniciar, la etapa de desarrollo del sistema será larga y el cliente
puede impacientarse por no ver resultados rápidamente, además si se arrastra
algún error en los requerimientos la corrección de mismo puede ser sumamente
costosa.
Figura 4: Modelo lineal secuencial
(Pressman, 2002)
Análisis Diseño Código Prueba
Ingeniería de sistemas/información
26
2.2.2.2 Modelo de Construcción de Prototipos
Este paradigma inicia con una recolección de requisitos y objetivos globales que el
desarrollador y el cliente realizan en conjunto y consiste básicamente en hacer un
“diseño rápido” de lo que el cliente desea, especificando entradas y salidas, de
esta manera el encargado de la implementación tendrá una idea más clara de lo
que se está solicitando y en fases posteriores se realiza el resto de la
programación que requiere el sistema, para este modelo hay una
retroalimentación continua del cliente.
Figura 5: El paradigma de construcción de prototipos
(Pressman, 2002)
2.2.2.3 Modelo de Desarrollo Rápido de Aplicaciones (DRA)
Es un modelo que se basa en el desarrollo secuencial de componentes, agilizando
el tiempo de implementación, una característica importante es que tanto los
requisitos como el alcance del proyecto deben estar bien definidos desde un inicio,
cuenta con las siguientes fases:
- Modelado de Gestión: se modela el flujo de información entre las funciones
de gestión.
- Modelado de datos: se definen características de los objetos necesarios y
las relaciones entre ellos.
- Modelado del proceso: flujo de información necesario para implementar la
función de gestión, se crean para añadir, modificar, suprimir o recuperar un
objeto de datos.
Construir/revisar la maqueta
El cliente prueba la maqueta
Escuchar al cliente
27
- Generación de aplicaciones: se utilizan herramientas para facilitar la
construcción de software o bien reutilizar componentes que ya existen.
- Pruebas y entrega: se prueban los componentes nuevos y se verifican las
interfaces.
2.2.2.4 Modelos Evolutivos de Proceso del Software
Modelo Incremental
Corresponde a una combinación del modelo secuencial con el prototipaje, se
desarrolla siguiendo el modelo secuencial pero se realizan iteraciones
escalonadas, en donde cada secuencia produce un incremento del software.
Figura 6: El modelo incremental
(Pressman, 2002)
Modelo Espiral
Este paradigma combina los elementos iterativos del prototipaje con los aspectos
controlados y sistemáticos del modelo lineal secuencial, de manera que se
desarrolla una versión del producto se presentan al cliente y se van completando
cada vez más hasta que se llega al producto deseado.
Figura 7: Modelo espiral típico
(Pressman, 2002)
28
Desarrollo basado en componentes
Modelo similar al espiral y por tanto es evolutivo e iterativo, se basa en la
reutilización de software, consiste en identificar las clases o componentes, analizar
si ya existen, en caso de que existan reutilizarlas y en caso contrario se
desarrollan y almacenan en una biblioteca de clases o repositorio.
Figura 8: Desarrollo basado en componentes
(Pressman, 2002)
2.2.3 Outsourcing
Proceso mediante el cual una organización asigna recursos a una empresa
externa con el fin de que ésta cumpla ciertas tareas, usualmente mediante un
contrato, el objetivo primordial es que permita a la empresa focalizar sus esfuerzos
en las tareas propias de su negocio y delegue otras que cumplen una función de
apoyo a una empresa especializada.
Ventajas
� Los costos generales tienden a ser menores.
� Mejora la calidad del producto o servicio.
� Reduce el número de tareas rutinarias.
� Permite a la empresa dedicarse a tareas de mayor rentabilidad.
� Permite la des-localización.
Desventajas
� Los empleados subcontratados no son pagados por la empresa que
subcontrata, por lo cual no tienen un incentivo de lealtad hacia ésta.
29
� La empresa contratante no puede brindar beneficios propios a los
empleados subcontratados, por lo tanto se puede dar un alto grado de
rotación de personal.
� Se facilita información sensible que puede ser utilizada por empleados de la
empresa subcontratada en perjuicio de la empresa contratante.
� La subcontratación no elimina puestos de trabajo, pero puede hacer menos
deseables los puestos que son reemplazables y menos valiosos
económicamente los subcontratados.
2.2.4 Obtención de Requerimientos
Este proceso es frecuentemente considerado uno de los más problemáticos y
complejos en los proyectos de software, suele ser complicado obtener la
información necesaria para diseñar y modelar un sistema, incluye a todos los
participantes que típicamente tienen distintos niveles de conocimiento y en
distintas áreas, lo cual ocasiona problemas en la comunicación, ya sea por que el
usuario no logra comunicar sus ideas o bien que el receptor no las interpreta
correctamente, en todo caso la información que se obtenga en esta etapa es la
que finalmente se convertirá en los requerimientos del software a desarrollar.
Con el fin de evitar este tipo de situaciones es necesario normalizar este proceso y
hacerlo lo más objetivo posible. De acuerdo a Esther Derby el aspecto que puede
tener un mayor impacto a la hora del levantamiento de requerimientos es que el
entrevistador haga las preguntas correctas, ya que así guiará al usuario y facilitará
el proceso. Entre los puntos que este autor menciona se encuentran (Derby,
2004):
� Formular claramente el objetivo de la entrevista, generar una lista de
posibles preguntas y organizar esta lista de aspectos generales a
específicos y de conocidos a desconocidos.
� Utilizar preguntas que no estén enlazadas a un contexto en particular, esto
facilita el inicio de la etapa especialmente cuando no se tiene muy claro a
30
dónde se quiere llegar, de manera que se logre un mayor entendimiento
tanto del proyecto como del producto.
� Realizar preguntas abiertas, con la finalidad de que el usuario sienta la
libertad de extenderse en la explicación de lo que requiere y espera del
producto o servicio.
� Es importante utilizar preguntas cerradas también, así se logra guiar al
usuario a lo largo del proceso, confirmar la información que no quede clara
y a su vez ir concluyendo los requerimientos.
� Un aspecto fundamental es entender el contexto completo, comprender
cómo funcionaba el sistema antes, cómo funciona ahora y cómo esperan
que funcione en el futuro, de esta manera es posible detectar problemas,
debilidades y situaciones no previstas.
� Es recomendable también utilizar preguntas de opinión acerca de premisas
que se dan, por ejemplo a manera de conclusión decir lo que se obtuvo en
un aspecto específico de la entrevista y preguntar la opinión del usuario, de
esta manera se confirma o bien se corrige la información.
� Investigar el porqué de las cosas provee una mayor comprensión de la
información recibida, pero es vital hacerlo de manera coherente y
adecuada.
� El punto final corresponde a la organización de la información, es
importante ir concluyendo y organizando las ideas.
Para esta etapa se cuenta con diversas herramientas que resultan útiles para
normalizar aún más la información recibida de las entrevistas u otros medios por
los cuales se obtuvo la información. Existen gran cantidad de paquetes de
software, técnicas y herramientas que simplifican esta tarea, algunas de las cuales
se mencionarán en las siguientes secciones del documento.
31
2.2.4.1 Diseño mediante Casos de Uso (Requisitos Funcionales)
2.2.4.1.1 Conceptos y Definiciones
El modelado mediante casos de uso es un tipo de diagramación que tiene como
objetivo facilitar el entendimiento de un problema, se utiliza para indicar lo que el
sistema debe hacer, mostrando la interacción entre los actores y casos de uso,
conceptos que seguidamente se van a explicar con detalle.
En este contexto, se denomina actor al agente externo que tiene alguna
interacción con el sistema, esta figura puede ser una persona o bien un sistema de
información. La representación del actor en este tipo de modelados puede variar
un poco, pero típicamente se representa de la siguiente manera:
Figura 9: Representación del actor
La definición del actor puede tener varios elementos que ayudan a clarificar el
papel que este tendrá en el sistema, algunos de los datos que resultan útiles son
(Garcerant, 2008):
� Nombre: Actor.
� Representado por: Nombre y datos de contacto del Stakeholders que
puede responder preguntas sobre este actor.
� Facilidades de comunicación: Protocolos o estilos de comunicación que
el actor entiende.
� Relación con otros actores: Relaciones de herencia o dependencia entre
actores.
Un concepto importante de definir es el concepto de escenario, el cual describe
un ejemplo de la utilización del sistema desde el punto de vista de las
interacciones usuario-sistema.
El caso de uso es a grandes rasgos la abstracción de un escenario, que trata de
generalizar o clasificar una serie de escenarios y representarlos de manera más
32
concreta, facilitando así el entendimiento para las fases de implementación. En
resumen, describe la interacción entre el sistema y una entidad externa (actor)
unificando varios escenarios y presentándolos como una funcionalidad particular.
Los casos de uso están compuestos por la definición de los requisitos funcionales
y contienen la información de qué debe hacer y cómo debe comportarse según
cada uno de los usuarios, por lo general se representan de la siguiente manera:
Figura 10: Representación de un caso de uso
Los casos de uso en conjunto con los actores y las relaciones que los unen,
constituyen lo que se denomina Modelo de Requisitos Funcionales, el cual puede
ser complementado con los Requisitos No Funcionales que se suelen detallar en
documentos aparte. Este tipo de técnicas funcionan no solo para la captura de
requerimientos funcionales, sino también para la documentación de pruebas,
documentación de usuario, manuales, entre otros.
Existen distintas relaciones que se pueden utilizar, el primer tipo son las
relaciones de inclusión que permiten la conexión entre casos de uso de manera
que unos puedan utilizar funcionalidad de otros (así no se duplica la definición,
solo se referencia a los que ya existen). Por otro lado las relaciones de extensión
reflejan cuando un caso de uso puede extender o brindar funcionalidad a otro, un
ejemplo sería asumir que existe un caso de uso “Ingresar (Login)” el cual puede
extender al caso de uso “Registrarse con Tienda de Libros”, este segundo requiere
la validación antes de poder llevarse a cabo.
Figura 11: Relaciones de casos de uso
33
Para este modelado existen diversos tipos de diagramas (clases, componentes,
secuencia, colaboración, estados, casos de uso, actividades, paquetes, entre
otros), para facilitar la aplicación de esta metodología, solo se describirán los más
importantes y que pueden tener un mayor impacto en los proyectos de este tipo.
2.2.4.1.2 Diagrama de Clases
Estos diagramas se asocian a los casos de uso y sirven para especificar y
documentar a nivel más detallado algunos elementos de diseño, tales como
componentes y clases mínimos que se requieren para la implementación de esa
funcionalidad del sistema. Cabe destacar que todo lo que se especifique en esta
parte del proceso sirve para planificar y estimar la complejidad del sistema a
desarrollar, pero en el proceso de desarrollo se puede modificar de acuerdo a las
necesidades que se presenten.
Figura 12: Diagrama de clases
(Sparx Systems)
34
2.2.4.1.3 Diagramas de Secuencia
Tienen como finalidad relacionar los casos de uso para comprender de manera
global el sistema, generalmente muestran la interacción entre actores, objetos y
componentes por medio de eventos y mensajes durante la ejecución de un caso
de uso (un escenario de caso de uso). Son muy utilizados para documentar los
escenarios definidos ya que permiten ver el flujo de manera más clara lo cual
facilita el análisis en etapas iniciales.
Con el fin de comprender y poder elaborar este tipo de diagramas, es necesario
especificar lo que significan algunos de los símbolos:
En la figura 13 se muestra un escenario del caso de uso de “Ingresar (Login)”, en
donde el flujo es el siguiente:
- Cliente ingresa a la pantalla destinada para esta función
- El sistema comienza a validar los datos ingresados por el usuario por medio
del gestor de seguridad que corresponda.
- El gestor de seguridad valida los datos y envía los detalles del usuario al
sistema.
- El sistema envía una respuesta al usuario (ya sea que se validaron los
datos correctamente o bien que se dio alguna excepción)
Figura 13: Diagrama de secuencia (Sparx Systems)
35
2.2.4.1.4 Ejemplo
Esta técnica de diagramación está compuesta por una serie de gráficos que
definen las partes de un sistema, generalmente se divide el problema en partes
más pequeñas para facilitar el entendimiento, procesamiento y desarrollo del
mismo. A continuación se presentará un ejemplo de cómo puede utilizarse para un
proyecto ficticio.
Para comenzar con el proceso de diagramación es necesario puntualizar qué es lo
que se va a realizar, quién interactúa e identificar ese caso o comportamiento para
diferenciarlo de los demás, por ejemplo para realizar un caso de uso para
Validarse en un Sistema:
Código: CU-001
Nombre: Validación al Sistema X
Actores: Usuario
Descripción: El usuario ingresa a la página o pantalla que corresponda, digita su
nombre de usuario, la contraseña y envía la solicitud. El sistema envía su respuesta
permitiéndole ingresar al sistema o bien rechazando la solicitud (si algo falló en el
proceso).
Precondición: El usuario tiene un login asignado y cuenta con los privilegios para
ingresar a la aplicación.
Poscondición: Ninguna.
Figura 14: Caso de uso de ingreso a sistema
36
2.2.4.2 Requerimientos No Funcionales
Este tipo de requerimientos son los que si bien forman parte importante para el
usuario, no están relacionados directamente con el comportamiento funcional del
sistema, abarcan aspectos que van desde la interfaz de usuario hasta tiempo de
respuesta y seguridad. (Pressman, 2002) Este tipo de requerimientos pueden
tener un alto impacto en el tiempo, costo y alcance del sistema a desarrollar en
conjunto con los requerimientos funcionales.
Pressman propone que deben investigarse los siguientes temas con el fin de
abstraer los requerimientos funcionales de los sistemas de software.
� Interfaz de usuario y factores humanos.
� Documentación.
� Consideraciones de hardware.
� Características de desempeño.
� Manejo de errores y condiciones extremas.
� Asuntos de calidad.
� Modificaciones al sistema.
� Ambiente físico.
� Cuestiones de seguridad.
� Cuestiones de recursos.
2.2.5 Bases de datos: Diagramas Entidad Relación
2.2.5.1 Conceptos Generales
Esta herramienta está diseñada para el modelado de datos de sistemas de
información, muestra las entidades u objetos de la base de datos y las relaciones
entre ellos. A continuación se especifican algunos conceptos claves para la
utilización de esta técnica.
Se entiende como entidad al objeto sobre el que se tiene información, que tiene
características propias, se representa mediante un rectángulo.
37
Las entidades se relacionan unas con otras por medio de relaciones, éstas en
resumen denotan la dependencia expresada por un verbo entre las entidades que
se encuentre relacionando, este verbo debe tener sentido en ambos lados de la
relación y se representa por medio de un rombo.
El tercer aspecto clave son los atributos qué básicamente son las características
o datos que se deben almacenar de cada una de las entidades, se representan
mediante un óvalo con el nombre en su interior y van relacionadas con la entidad a
la que pertenecen, si el atributo es el identificador de la entidad éste se subraya.
En caso de que el diagrama sea muy grande o tenga demasiados atributos, se
pueden especificar los atributos en un documento adicional.
Existen dos tipos de entidades, las entidades fuertes que se representan por
medio de un rectángulo sencillo y las entidades débiles representadas con un
rectángulo doble. Se denomina entidad fuerte a aquellos elementos de base de
datos que existen por sí solas sin necesidad de tener relación con otras entidades
(por ejemplo, una entidad de “países”, que tal vez no está directamente
relacionada a ninguna de las entidades del modelo, pero se utiliza como catálogo
y por lo tanto no depende de las otras entidades para existir). Las entidades
débiles son por el contrario, las que solo existen por medio de la relación que
exista con ellas (por ejemplo, una entidad “dependiente” sería una entidad débil de
una entidad “empleado” en un marco organizacional).
Finalmente existe la cardinalidad de las relaciones, en donde existen tres tipos de
relaciones:
- Relación uno a uno (1:1): Los elementos de la entidad A tienen un único
elemento correspondiente con la entidad B.
- Relación uno a muchos (1:N): Cada elemento de la entidad A tiene uno o
varios elementos en la entidad B.
- Relación muchos a muchos (N:M): Cada elemento de la entidad A tiene uno
o varios elementos en la entidad B y cada elemento en B tiene uno o varios
en A.
38
Cabe destacar que este es solo uno de los modelos que se utilizan para el
modelado de datos, sin embargo es uno de los más utilizados. Este tipo de
modelaje para ser implementado debe pasar por una etapa de normalización la
cual no se verá acá ya que pertenece propiamente a la parte de implementar la
base de datos.
2.2.5.2 Ejemplo
Para facilitar y a la vez ilustrar la información descrita en la sección anterior, se
presenta el siguiente ejemplo que corresponde a lo que sería una base de datos
con tres entidades (Departamento, Empleado, Dependiente), en donde cada una
de ellas tiene sus atributos respectivos, el modelado del problema tiene las
siguientes características:
- El empleado puede tener 0 ó más dependientes (Relación 1:N).
- El dependiente es una entidad débil, porque depende 100% del empleado,
por lo tanto si no existe un empleado no existirá un dependiente.
- El departamento puede tener 1 o más empleados (Relación 1:N).
Figura 15: Ejemplo de diagrama Entidad Relación
39
2.2.6 Estimación de Tiempo y Costo
Medir el costo en los proyectos de software suele ser una tarea complicada debido
a que hay una serie de factores a tomar en cuenta, en general, hay dos tendencias
marcadas, una de ellas se basa en medir con relación al tamaño y otras a la
función, el primer tipo de métrica suele ser menos compleja de utilizar pero a la
vez bastante inexacta, técnicas como medir el software por medio de cantidad de
líneas de código no expresa de manera real aspectos de complejidad o
funcionalidad de un módulo o sistema, lo que por el contrario sí logra cuantificar la
segunda propuesta.
Como lo menciona Pressman el tamaño del software se debe medir basándose
en: (1) el grado en que el planificador estima correctamente el tamaño del
producto a construir; (2) la habilidad de traducir la estimación de tamaño en
esfuerzo humano, tiempo y costo; (3) el grado en que el plan de proyecto refleja
las habilidades del equipo de software, y (4) la estabilidad de los requisitos del
software y el entorno que soporta el esfuerzo de la ingeniería de software.
(Pressman, 2002)
Dado que las técnicas que se basan en medir la funcionalidad del software son
más exactas y logran describir de mejor manera la realidad de lo complejo que
puede ser el código a desarrollar, se describirá a continuación la técnica de puntos
de función.
2.2.6.1 Puntos de Función
Esta técnica sirve tanto para medir proyectos en desarrollo como para proyectos
implementados, su unidad es lo que se denomina punto de función que es
independiente de la plataforma o tecnología utilizada, ya que se enfoca en medir la
complejidad desde el punto de vista de la funcionalidad partiendo del diseño lógico
y tomando en cuenta la perspectiva del usuario.
Es importante clarificar algunos conceptos claves antes de comenzar a hilar más
fino en los pasos a seguir para su implementación, algunos de estos son:
40
� Archivos lógicos internos (ILF - Internal Logical Files): datos que se
manipulan en la aplicación, ya sea que se generan, modifican o mantienen
y que el usuario puede acceder.
� Archivos lógicos de interfaz (EIF - External Interface Files): datos que sirven
de conexión con otras aplicaciones. En caso de que algún dato sea tanto
archivo lógico interno como de interfaz, debe incluirse en ambos.
� Consultas lógicas (EQ – External Inquiries): son entradas externas que son
resultado de una consulta o búsqueda.
� Entradas externas (EI – External Inputs): datos o comandos de control de
usuario que ingresan a la aplicación y agregan o modifican datos internos.
� Salidas externas (EO – External Outputs): comandos o datos que salen de
la aplicación para el usuario.
Una vez definidos los conceptos básicos, en los siguientes párrafos se explica el
proceso que se recomienda llevar a cabo para el análisis:
Figura 16: Análisis de puntos de función
1. Identificar el alcance y fronteras del proyecto
- Identificar los sistemas, aplicaciones o módulos a medir.
- Se denomina frontera al límite entre la aplicación o subconjunto que se
desea medir con respecto a las aplicaciones externas.
41
Figura 17: Diagrama de funcionalidad de un sistema por medio de los 5 componentes (Durán, 2003)
2. Identificación de funciones de datos y complejidad
- Identificar entidades internas (ILF) y externas (EIF) tomando en cuenta
el número de tipos de elementos de datos o atributos (DET) y los tipos
de elementos de registros (RET).
- Por medio de la siguiente tabla se puede determinar la complejidad de
los elementos de datos, aunque cabe mencionar que esta es solo una
propuesta a seguir, la complejidad se puede determinar tomando en
cuenta la historia de la empresa.
Tabla 2: Complejidad de funciones de datos
No. Registros (RET)
No. de Campos (DET) 1-19 20-50 >= 50
1 Baja Baja Media 2-5 Baja Media Alta >5 Media Alta Alta
3. Identificación de funciones transaccionales y complejidad
a. Identificar entradas externas (EI) consiste en definir cuántas pantallas se
requieren para administrar cada entidad, por ejemplo acciones de
insertar, modificar, eliminar, evaluar, asignar.
42
b. Identificar salidas externas (EO), se caracterizan por contener al menos
una fórmula matemática, cálculo o crear datos derivados, además alterar
el comportamiento del sistema.
c. Identificar consultas externas (EQ), éstas a diferencia de las EO no
administran datos de ILF, no se aplican fórmulas, no se crean datos y no
se puede cambiar el comportamiento de la aplicación.
- La complejidad generalmente se mide por medio de parámetros que
define la empresa, pero con el fin de brindar un punto de partida se
propone la siguiente tabla.
Tabla 3: Complejidad de funciones transaccionales
No. Archivos Referenciados
(FTR)
No. de Campos (DET)
1-5 6-19 >= 20
< 2 Baja Baja Media 2 - 3 Baja Media Alta > 3 Media Alta Alta
4. Calcular los puntos de función sin ajustar (PFSA)
- Se crea la tabla de pesos con la estructura a como se muestra, se
completa la cantidad total de componentes, se multiplica la cantidad por
el valor de la tabla que corresponda según sea su complejidad,
finalmente se suman los valores y se colocan en la última columna.
Tabla 4: Resumen de puntos de función sin ajustar
Componentes Complejidad
PF Baja Media Alta
Archivos Lógicos Internos (ILF) x 7 = _ x 10 = _ x 15 = _ ∑
Archivos Lógicos Externos (EIF) x 5 = _ x 7 = _ x 10 = _ ∑
Entradas Externas (EI) x 3 = _ x 4 = _ x 6 = _ ∑
Salidas Externas (EO) x 4 = _ x 5 = _ x 7 = _ ∑
Consultas Externas (EQ) x 3 = _ x 4 = _ x 6 = _ ∑
Total de Puntos de Función (PF) ∑
43
5. Factor de Ajuste (FA)
- Se calcula tomando en cuenta catorce características definidas para el
software, a las cuales se les da un peso de 0 a 5 dependiendo de la
presencia que éstas tengan en el proyecto. Estos valores se suman para
luego utilizarlos en el ajuste de los PF.
- Las características son:
1. Comunicación de Datos
2. Procesamiento datos
distribuido
3. Rendimiento
4. Configuración
5. Tasa Transaccional
6. Entrada de datos en línea
7. Eficiencia del usuario final
8. Actualización en línea
9. Procesamiento Complejo
10. Reutilización
11. Facilidad de Instalación
12. Facilidad de Operación
13. Adaptabilidad a Múltiples Sitios
14. Facilidad de cambio
6. Puntos de Función Ajustados (PF)
- Se calcula el factor de ajuste:
65.0)01.0( +∗= TIFA
- Seguidamente se calcula el total de puntos de función ajustados:
PFSAFAPF ∗=
7. Estimación del valor esperado (VE)
- Se estiman valores de esfuerzo que denotan el valor pesimista, medio y
optimista, para estimarlos se utilizan distintas métricas de productividad
ya sea a partir de información histórica o por medio de las siguientes:
a. 25 PF/PM equivalente a 4.8 horas por PF (PF/25)
b. 30 PF/PM equivalente a 4 horas por PF (PF/30)
c. 8 horas por PF equivale a 15 PF/PM (PF*8)
d. 10 horas por PF equivale a 12 PF/PM (PF*10)
44
- Finalmente se calcula la duración total por medio de lo que se denomina
valor esperado (VE), éste utiliza los tres valores definidos anteriormente
por medio de la siguiente la fórmula:
6
)4( pesimistamediooptimo SSSVE
+∗+=
8. Estimación del costo
- Una vez obtenido el tamaño del software a desarrollar (PF), este valor
se puede utilizar para calcular el costo total del proyecto, mediante la
siguiente fórmula:
CostoPFPFCostoTotal ∗=
- El valor del costo por punto de función puede obtenerse por medio de un
estudio del histórico de proyectos de la empresa (activos de proceso) o
bien realizando un estudio del mercado, este valor depende también de
la productividad propia de la empresa.
45
2.3 Teoría de la Administración de Proyectos
2.3.1 Conceptos Generales
Proyecto
Es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o
resultado único (PMBOK, 2004). Este a su vez cumple con tres características
principales:
- Temporalidad, es decir que tiene un fin y comienzo determinados, ya sea
por que se cumplan los objetivos planteados o bien por que decida no
realizarse.
- Productos, servicios o resultados únicos, cada proyecto va a dar como
resultado productos entregables únicos.
- Elaboración gradual, implica que los proyectos se desarrollan en pasos y
aumentan mediante incrementos hasta llegar a completar el producto o
servicio deseado.
PMI
Project Management Institute (Instituto de Administración de Proyectos) es el
organismo rector en materia de Administración de Proyectos
PMBOK
Es una guía de los fundamentos de la dirección de proyectos, desarrollada por el
PMI, este entre algunas de sus características proporciona y promueve un
vocabulario común para analizar, escribir y aplicar la dirección de proyectos.
Administración de Proyectos
Aplicación de conocimientos, habilidades, herramientas y técnicas a las
actividades de un proyecto para satisfacer los requisitos del mismo, por medio de
la aplicación e integración de los procesos de dirección de proyectos de inicio,
planificación, ejecución, seguimiento y control y cierre (PMBOK, 2004). Incluye:
- Identificar los requisitos.
46
- Establecer objetivos claros y posibles a realizar.
- Equilibrar las demandas concurrentes de calidad, alcance, tiempo y costo.
- Adaptar las especificaciones, los planes y el enfoque a las diversas
inquietudes y expectativas de los interesados.
2.3.2 Ciclo de vida de un proyecto
Generalmente los proyectos se dividen en fases y el conjunto de estas fases,
dependiendo de la empresa y el proyecto van a resultar en el ciclo de vida del
proyecto. Éstos se definen de acuerdo al trabajo técnico a realizar, a las fechas en
las que se deben presentar entregables, los involucrados o bien de acuerdo a
cómo y quién debe aprobar cada una de las fases.
Algunas características comunes son:
- Fases secuenciales con algún nivel de transferencia de información entre
ellas.
- Los factores de costo y recursos humanos son bajos al inicio, llega al
máximo en las etapas intermedias y vuelve a decaer en la etapa de cierre.
- La incertidumbre es más alta al inicio del proyecto y va disminuyendo.
- El grado de influencia de los interesados en el proyecto es más crítico al
inicio del mismo. El costo de los cambios y corrección de errores aumenta
conforme avanza el proyecto.
En la siguiente figura se muestran los principales componentes de un proyecto y
las grandes categorías en las que se dividen las fases que componen el ciclo de
vida del proyecto, típicamente se dividen en tres grandes categorías de las cuales,
la intermedia puede estar compuesta de varias fases en sí misma.
47
Figura 18: Secuencia de fases típica de un ciclo de vida del proyecto
(PMBOK, 2004)
2.3.3 Grupos de Procesos
Dentro del marco de la guía de administración de proyectos del PMI se definen
cinco grupos de procesos que deben ejecutarse según la etapa del proyecto que
se esté ejecutando, en la siguiente figura se muestran estos grupos de proceso y
su interacción:
Figura 19: Correspondencia de los grupos de procesos de dirección de proyectos al ciclo de
Planificar-Hacer-Revisar-Actuar (PMBOK, 2004)
48
En la figura adjunta se presenta una descripción breve de cada uno de estos
grupos de procesos y su interacción, este cuadro es propuesto por el autor Yamal
Chomoun:
Inicio
Establecer la visión del proyecto, el qué; la misión por cumplir y sus objetivos, la justificación del mismo, las restricciones y supuestos.
Planeación
Desarrollar un plan que nos ayude a prever el cómo cumpliremos los objetivos, tomando en cuenta una serie de factores que afectan todo proyecto. Aquí se establecen las estrategias, con énfasis en la prevención en vez de la improvisación.
Ejecución
Implementar el plan, contratar, administrar los contratos, integrar el equipo, distribuir la información y ejecutar las acciones requeridas de acuerdo con lo establecido.
Control
Comparar lo ejecutado o real contra lo que previmos o planeamos (control), de NO identificar desviaciones, continuamos con la ejecución. Si se encuentran desviaciones, el equipo acordamos la acción correctiva (planeación adicional) y luego continuamos con la ejecución, manteniendo informado al equipo.
Cierre
Concluir y cerrar relaciones contractuales profesionalmente para facilitar referencias posteriores al proyecto así como para el desarrollo de futuros proyectos. Por último, se elaboran los documentos con los resultados finales, archivos, cambios, directorios, evaluaciones y lecciones aprendidas, entre otros.
Figura 20: Grupos de procesos (Chamoun, 2002)
2.3.4 Áreas de Conocimiento
El PMI propone la división de nueve áreas de conocimiento para facilitar la gestión
de proyectos, estas no necesariamente van a estar presentes o van a ser
igualmente importantes en todos los casos. Como anteriormente se definió todos
los proyectos son únicos y es precisamente por esto que las áreas de
conocimiento se proponen con el fin de elegir las que apliquen según sea el caso.
En la siguiente figura se da una breve descripción de cada una de las áreas de
conocimiento según Yamal Chamoun, en la misma figura se destacan por medio
de color las áreas a desarrollar en este PFG:
49
1 Alcance � Definición de lo que incluye y no incluye el proyecto. 2 Tiempo � Programa, calendario, entregas parciales y finales. 3 Costo � Estimados de costo, presupuesto, programa de erogaciones. 4 Calidad � Estándares relevantes, cómo cumplirlos y satisfacer los requerimientos.
5 Recursos Humanos
� Equipo del proyecto que integra colaboradores tanto internos como externos y los roles y funciones de cada cual.
6 Comunicación � Información requerida presentada en reportes o informes, quién la
genera, quien la recibe, con qué frecuencia la entregamos, juntas, medios de distribución, etc.
7 Riesgo � Amenazas por controlar, oportunidades que capitalizar y planes de contingencia.
8 Abastecimientos � Estrategias de contratación, cotizaciones, concursos, contratos y administración de contratos.
9 Integración � Administración de cambios, lecciones aprendidas e integración de todas las áreas.
Figura 21: Nueve áreas por considerar en la Administración Profesional de Proyectos (APP) (Chamoun, 2002)
Particularmente existen cuatro de las áreas que siempre van a estar presentes en
todo proyecto, debido a que conforman la base para realizar cualquier proyecto,
estas áreas son Alcance, Tiempo, Costo e Integración, en la figura adjunta se
muestra la interrelación entre las áreas de conocimiento.
Figura 22: Triángulo Alcance-Tiempo-Costo-Calidad
(Chamoun, 2002) A continuación se va a exponer brevemente los aspectos más importantes acerca
de la teoría de las áreas de conocimiento que se tratarán en el documento, en
particular las técnicas y herramientas, con énfasis en las que se desarrollarán o
recomendarán en el desarrollo de esta metodología.
50
2.3.4.1 Integración
Esta área de conocimiento tiene la función como su nombre lo indica de definir,
combinar, unificar y coordinar diferentes procesos y actividades de gestión de
proyectos, funciona como el común denominador que une las otras áreas de
conocimiento y como ya se mencionó es una de las cuatro que siempre va a estar
presente en todo proyecto.
En las siguientes secciones se expone la teoría de las técnicas y herramientas que
el PMI presenta para la gestión de la Integración y que van a ser contempladas
más adelante en el desarrollo de la metodología.
2.3.4.1.1 Acta de Constitución de Proyecto (Charter)
Este documento tiene como finalidad formalizar la iniciativa de crear un proyecto,
clarificar lo que se pretende obtener y asignar responsabilidades y autoridad a los
involucrados, en general se utiliza al iniciar un proyecto y es necesario actualizarla
en caso de que se presenten modificaciones importantes. Debe contener la
siguiente información:
- Justificación del proyecto.
- Objetivos del proyecto.
- Descripción de lo que se desea y espera del proyecto, incluyendo datos de
entregables finales, con una descripción clara de su contenido.
- Definición de los involucrados con una descripción de sus necesidades,
expectativas y responsabilidades.
- Descripción de restricciones y supuestos, es decir los factores que limitan y
los que se deben asumir para desarrollar el proyecto.
- Información histórica, en caso de que esté disponible de proyectos
anteriores similares al que se desea realizar.
- Información acerca de la autorización, este documento debe ir firmado tanto
por el patrocinador como por el director de proyecto.
51
2.3.4.1.2 Enunciado de Alcance del Proyecto Preliminar
Corresponde a la definición del proyecto, debe definir los objetivos a cumplirse,
características, límites del proyecto, entre otros datos. Debe tomar en cuenta los
siguientes puntos:
- Objetivos del proyecto y del producto.
- Requisitos y características del producto o servicio.
- Criterios de aceptación del producto.
- Límites del proyecto.
- Requisitos y productos entregables del proyecto.
- Restricciones del proyecto.
- Asunciones del proyecto.
- Organización inicial del proyecto.
- Riesgos iniciales definidos.
- Hitos del cronograma.
- EDT inicial.
- Estimación de costos de orden de magnitud.
- Requisitos de gestión de la configuración del proyecto.
- Requisitos de aprobación.
2.3.4.1.3 Mapa de Expectativas
El mapa de expectativas tiene como objetivo dar a conocer qué esperan los
participantes del proyecto para que haya un entendimiento global de las partes y
una conciliación. Este mapa debe contener información acerca de roles,
responsabilidades y expectativas de cada participante según su punto de vista y
necesidades, clarificar esto desde el inicio permitirá trabajar de manera más fluida,
ya que todos van a tener el objetivo claro y la misma dirección.
52
2.3.4.1.4 Dirigir y gestionar la ejecución del proyecto
Esta tarea contiene una serie de acciones que tanto el director como el equipo del
proyecto deben realizar para ejecutar el plan de gestión, entre las acciones que
menciona el PMBook se encuentran:
- Realizar actividades para cumplir con los objetivos del proyecto.
- Realizar esfuerzos e invertir fondos para cumplir con los objetivos.
- Dotar de personal, formar y dirigir a los miembros del equipo del proyecto
asignados al proyecto.
- Obtener presupuestos, licitaciones, ofertas o propuestas, según
corresponda.
- Seleccionar vendedores eligiéndolos entre los posibles vendedores.
- Obtener, gestionar y utilizar recursos, incluidos los materiales,
herramientas, equipos e instalaciones.
- Implementar los métodos y normas planificados.
- Crear, controlar, verificar y validar los productos entregables del proyecto.
- Establecer y gestionar los canales de comunicación del proyecto, tanto
externos como internos al equipo del proyecto.
- Recolectar datos sobre el proyecto e informar sobre el costo, el
cronograma, el avance técnico y calidad, y la información de la situación
para facilitar las proyecciones.
- Documentar las lecciones aprendidas e implementar las actividades de
mejora de los procesos aprobados.
53
2.3.4.1.5 Cierre del Proyecto
El proceso de cierre de proyectos corresponde por decirlo de alguna manera al
cierre administrativo, este proceso está fuertemente relacionado con el área de
conocimiento de abastecimientos, pero en el caso de esta metodología dado que
no se va a analizar el área de abastecimientos solo se estudiará la parte del cierre
administrativo.
A continuación se presenta un breve resumen de las técnicas y herramientas de
otros procesos que son necesarias para el cierre del proyecto.
Tabla 5: Herramientas del plan del proyecto que apoyan el cierre (Chamoun, 2002)
Área Herramienta ¿Cómo nos servirá durante la ejecución?
Alc
ance
WBS - Para registrar el trabajo ejecutado y compararlo contra lo planeado. - De base como formato establecido o estándar, para elaborar el WBS de futuros proyectos de índole similar.
Tie
mp
o
Programa del Proyecto
- Para documentar las duraciones reales de las actividades del proyecto que nos servirán como información histórica para futuros proyectos. - Para actualizar la base de datos de la duración de las actividades.
Co
sto
Control Presupuestal - Para documentar los costos reales del proyecto que nos servirán como información histórica para futuros proyectos. - Para actualizar la base de datos de costos.
Rie
sgo
s Matriz de Administración de
Riesgos - Como información histórica para planear futuros proyectos.
Inte
gra
ció
n Sistema de Control de
Cambios
- Para asegurar el cierre apropiado de todas las órdenes de cambio autorizadas, y evitar el pago de cambios no autorizados. - Para evaluar el desempeño del proyecto y aprender de las desviaciones encontradas para mejorar la planeación del proyectos posteriores.
Lecciones Aprendidas - Para capitalizar las experiencias y el conocimiento adquirido y así apoyar la mejora continua y optimizar la planeación de proyectos futuros.
54
Cierre Contractual
Este proceso consiste en verificar los entregables y realizar el cierre administrativo
de los contratos, de manera que se revisen los términos y condiciones del
contrato, el autor Yamal Chamoun utiliza la siguiente lista de documentos para
este proceso:
• Archivos de contrato.
• Carta finiquito.
• Manuales, garantías y fianzas.
• Planos actualizados según la industria.
• Comunicados.
• Evaluaciones Cliente-Proveedor y Proveedor-Cliente.
• Lecciones aprendidas.
• Bitácoras.
• Cierre de cada contrato.
• Aceptación formal – acta de recepción.
• Cancelación de fianzas.
• Otros documentos, dependiendo del contrato.
Cierre Administrativo
Al terminar el proyecto, se debe realizar el cierre definitivo y formal que indique el
que el proyecto ha finalizado (independientemente de si terminó con éxito o si fue
cancelado), se deben documentar y revisar aspectos propios de la gestión del
proyecto, tales como verificación de entregables, de documentación, efectividad y
aspectos de justificación en caso de que el proyecto no haya finalizado
exitosamente.
En caso de que el proyecto se haya gestionado por fases, este proceso debe
realizarse al finalizar cada una de las fases.
55
2.3.4.2 Alcance
La gestión del alcance es otra de las áreas de conocimiento que se encuentra en
todos los proyectos, está relacionada a los requerimientos, límites y objetivos del
proyecto. Se compone de procesos que determinan cuál es el trabajo que debe
realizarse para cumplir el objetivo propuesto y su finalidad es gestionar que se
realice todo trabajo requerido y solo este trabajo.
2.3.4.2.1 Enunciado de Alcance
Este documento es el punto de partida para definir lo que se quiere y lo que
compone el proyecto a un nivel de detalle tal, que pueda cumplir con la función de
“contrato” entre los involucrados, utiliza de insumo el Acta de Constitución
previamente definida y consiste en completar lo que allí se presenta, se
recomienda que cuente con la siguiente información:
- Resumen Ejecutivo: Tiene como finalidad ubicar al lector en términos de la
empresa y el proyecto sin entrar en mayor detalle.
- Descripción del proyecto: Debe clarificar generalidades importantes del
proyecto tales como la visión, requerimientos, los beneficios que se esperan
y a grandes rasgos la estrategia a seguir, además de los objetivos,
definición de alcance y clasificación de los involucrados del proyecto, este
último para definir los roles y responsabilidades de cada uno de los
participantes.
- Objetivos: Especificar cuáles son los objetivos del proyecto
- Límites del Proyecto: Deben indicarse aquellos factores externos al
proyecto que pueden influir en el desarrollo del mismo.
- Restricciones: Factores que limitan el proyecto de una u otra manera,
aspectos de tiempo, costo, entre otros.
- Supuestos o Asunciones: Aspectos que se deben asumir para realizar el
proyecto, generalmente son factores externos que están fuera del círculo de
56
influencia del proyecto pero que, de cambiar podrían tienen algún impacto
en él.
- Hitos del Cronograma: Definición de los puntos de control que se
consideran relevantes para el seguimiento y control del proyecto.
- Organización del Proyecto: Organigrama y descripción de roles y
responsabilidades de los involucrados del proyecto.
- Riesgos: Lista de riesgos definidos inicialmente.
- Gestión de la configuración: En caso de que se tenga la información,
determinar a grandes rasgos como se realizará el control y seguimiento del
proyecto.
- Requisitos de aprobación: Requisitos que deben cumplirse para la
aceptación del proyecto y de los entregables o documentos que se generen
durante el desarrollo.
2.3.4.2.2 Estructura Detallada de Trabajo
Es la definición estructurada y organizada de las actividades, orientada a
entregables, en donde la jerarquía indica que las tareas de último nivel son las que
se pueden medir, controlar y tomar en cuenta para estimar tiempo y costo. La EDT
debe complementarse con el diccionario para las actividades más importantes, se
considera deseable para todas, pero dependiendo de la magnitud del proyecto
puede que sea demasiado costoso a nivel de tiempo realizar este trabajo tan
detallado. Siguiendo el marco del PMI, se determina que para realizar la
descomposición de actividades, se debe:
- Identificar los productos entregables y el trabajo relacionado a ellos.
- Estructurar y organizar la EDT.
- Descomponer los niveles superiores de la EDT en componentes detallados
de nivel inferior.
- Desarrollar y asignar códigos de identificación a los componentes de la
EDT.
57
- Verificar que el grado de descomposición del trabajo es necesario y
suficiente.
2.3.4.2.3 Plan de Gestión de Alcance
Siguiendo con el proceso el plan de gestión de alcance indica de qué se trata el
proyecto, cuál es su rango de acción, razón de ser y de qué forma se va a llevar a
cabo, consta de varias secciones con información de los objetivos tanto del
proyecto como del producto final, requisitos y características, límites, criterios de
aceptación, entregables, restricciones, asunciones, la organización de los
participantes del proyecto, riesgos definidos (a grandes rasgos), hitos, estimación
de costos a groso modo, aspectos de control, seguimiento y aprobación.
- Resumen Ejecutivo, contiene información resumida de la temática del
proyecto y su objetivo en la organización.
- Descripción del proyecto, con información acerca de generalidades del
proyecto (visión, requerimientos, resultados esperados, estrategia),
objetivos, alcance, involucrados.
- Límites del proyecto, para delimitar el círculo del mismo.
- Restricciones, de cualquier índole que pueda afectar el proyecto.
- Supuestos, aspectos que no están en el círculo de influencia del proyecto,
pero que pueden afectar y que deben asumirse.
- Hitos del cronograma, lista de puntos de control definidos inicialmente para
controlar el proyecto, con la respectiva documentación que los respalda.
- Organización, debe incluir un organigrama del proyecto además de los roles
y responsabilidades de los participantes.
- Estructura detallada de trabajo con el respectivo diccionario de EDT.
58
2.3.4.2.4 Verificación del Alcance
Esta actividad consiste en la revisión y aprobación formal del alcance del proyecto
y sus entregables por parte de los interesados, este proceso se alimenta del
enunciado de alcance, diccionario de la EDT, plan de gestión de alcance y los
productos entregables.
Para llevar a cabo este proceso el PMBook recomienda la técnica de Inspección
que consiste en medir, examinar y verificar para determinar si los productos
entregables cumplen con los requisitos y criterios de aceptación definidos
previamente, en general son revisiones o auditorías y para realizarse deben tener
ciertos criterios definidos.
2.3.4.3 Tiempo
La gestión de tiempo como su nombre lo indica es la organización del trabajo para
determinar la duración del proyecto, el detalle de distribución de tiempo para
realizar las tareas propuestas y, el seguimiento y control para que el proyecto
termine en el tiempo estimado. En las siguientes secciones se presentan los
procesos, técnicas y herramientas necesarias para esta gestión que
posteriormente serán aplicadas en el desarrollo de la metodología.
2.3.4.3.1 Definición de Actividades
El proyecto debe segregarse en partes más pequeñas conocidas como
actividades, con el fin de facilitar la programación del trabajo a realizar, tomando
en cuenta aspectos de tiempo, costo y alcance primordialmente. Esta segregación
de tareas permite realizar el trabajo de manera ordenada y facilita la asignación de
recursos, el seguimiento y control del proyecto.
Las actividades que se definen en las primeras etapas formarán lo que se
denomina la línea base del proyecto, que a grandes rasgos es el punto de partida
de lo que debe ser el proyecto y cómo debe elaborarse, en términos de tiempo,
costo y recursos, entre otros.
59
Entre las herramientas y técnicas que se recomiendan para desarrollar esta tarea
se encuentran las siguientes:
- La descomposición se basa en subdividir los paquetes de trabajo definidos
en la EDT en unidades más pequeñas, de manera que se llegue a tareas
concretas que se puedan ir desarrollando a lo largo del proyecto.
- Los activos de proceso de la empresa son una herramienta importante, ya
que de lo que ya se ha gestionado en el pasado se pueden obtener
plantillas, lecciones aprendidas o listas de actividades definidas en
proyectos similares.
- La planificación gradual es otra de las técnicas propuestas por el PMBOK
que consiste en hacer una descomposición de las actividades a realizar.
- El juicio de expertos ciertamente es una técnica importante en distintas
áreas de la gestión de proyectos y particularmente en esta, debe
complementarse con documentación y activos de proceso de la empresa.
Se debe producir la lista de actividades necesarias para el desarrollo del proyecto,
debe contener además los atributos de cada una de ellas, entre los cuales se
encuentran: identificador único, descripción breve (que clarifique de qué se trata y
qué trabajo hay que realizar), las actividades predecesoras y sucesoras, las
relaciones lógicas, adelantos y retrasos, requisitos de recursos, fechas definidas,
restricciones y asunciones. Además se puede agregar la información del
responsable de esa actividad, lugar donde se realizará (en caso de que las
actividades se lleven a cabo en distintas locaciones) entre otros datos que se
consideren relevantes.
2.3.4.3.2 Secuenciación de Actividades
Las actividades definidas deben organizarse según su relación lógica, esto para
posteriormente construir el cronograma del proyecto. Existen diferentes técnicas
para trabajar en esta fase, entre ellas técnicas de diagramación, para términos de
esta metodología se utilizará el método de diagramación por precedencia (PDM).
60
Este método consiste en la representación de las actividades por medio de
círculos o nodos los cuales se interconectan entre sí, los tipos de relaciones que
conectan las actividades son los siguientes:
- Final-Inicio: El inicio de la actividad sucesora depende de la finalización de
la predecesora.
- Final-Final: La finalización de la actividad sucesora depende de la
finalización de la predecesora.
- Inicio-Inicio: El inicio de la actividad sucesora depende del inicio de la
predecesora.
- Inicio-Fin: La finalización de la actividad sucesora depende del inicio de la
predecesora.
Figura 23: Ejemplo de diagrama PDM
En la figura anterior se muestra un caso sencillo de secuenciación de actividades,
en donde la actividad A y D comienzan al mismo tiempo sin relaciones de
precedencia entre ellas, la actividad B tiene una relación de inicio-fin con la
actividad A, al igual que C con respecto a B y D, en la parte inferior del diagrama D
es predecesora de E y E de F, ambas por medio de relaciones inicio-fin,
finalmente C y F son las actividades que determinan el final del proceso.
La idea de apoyarse en métodos como el que se menciona es facilitar el
entendimiento global de lo que se quiere planificar y a la vez organizar las
actividades según el orden en que deben o pueden llevarse a cabo, simplificando
el desarrollo del cronograma como tal. En la realización del cronograma el orden
puede verse afectado por aspectos de costos o disponibilidad de recursos.
61
2.3.4.3.3 Asignación de Recursos
Tomando de base las actividades que se identificaron en las fases anteriores, se
debe hacer la distribución de los recursos que se tienen asignados al proyecto
para comenzar posteriormente a determinar el tiempo que se durará en cada
actividad y crear formalmente el cronograma. Es importante investigar los activos
de proceso de proyectos similares desarrollados ya sea en la empresa o
información de esta índole en publicaciones ya que permite normalizar y realizar la
asignación de manera más objetiva.
El juicio de expertos es una de las herramientas recomendadas y consiste en que
los expertos apoyen en la asignación de acuerdo a su conocimiento y experiencia.
También es fundamental realizar un análisis de alternativas, en donde se deben
tomar en cuenta aspectos de especialización, habilidades y/o capacidad de los
recursos para realizar x o y actividad, con el fin de asignar los recursos en las
tareas que se consideren más adecuadas buscando siempre el cumplimiento
optimizado de los objetivos del proyecto.
2.3.4.3.4 Desarrollo del Cronograma
Una vez definidas y secuenciadas las actividades, calculada su duración y la
complejidad del software a desarrollar, el siguiente paso consiste en ensamblar y
organizar esa información en un cronograma, que será la línea base de la cual
partirá el proyecto.
Creación del Cronograma
Consiste en definir las fechas de inicio y finalización de cada tarea, tomando como
insumo la lista de actividades previamente definida, la secuencia que estas
llevarán, la duración estimada para completar cada una de ellas, incluyendo las
holgura en caso de que se haya definido y las restricciones, como por ejemplo que
una tarea no debe comenzar antes o después de una fecha en particular. Esta
tarea se facilita si se utiliza un programa especializado para el manejo de
cronogramas como lo es MS Project.
62
El PMBOK recomienda el uso de varias técnicas y herramientas, entre las cuales
se encuentran:
- Método del Camino Crítico: En general se trata de un método que calcula
las fechas de inicio y fin de las actividades, tanto el valor temprano
(optimista) como tardío (pesimista). En este tipo de representación no se
pretende mostrar las fechas reales de planificación de las tareas, pero sí los
periodos en los que deberían programarse las actividades dentro el
cronograma, tomando en cuenta las duración, relaciones lógicas, adelantos,
retrasos y otras restricciones de las cuales se tenga conocimiento. La ruta
crítica se refiere a la secuencia de actividades que determinan la ruta más
larga para terminar el proyecto, es decir, las actividades que en caso de
atrasarse, afectarían directamente la duración del proyecto.
- Compresión del Cronograma: Esta técnica busca optimizar los tiempos
cumpliendo las restricciones, características y alcance del proyecto. El
PMBook propone lo siguiente:
o Intensificación: Se analiza el costo y cronograma buscando
comprimir el cronograma con el mínimo incremento de costo.
o Ejecución rápida: Las fases o actividades que suelen hacerse de
forma secuencial, se harán en paralelo, esta técnica puede hacer
que se aumente el costo y el riesgo de que las cosas salgan de
acuerdo a lo planeado.
- Método de Cadena Crítica: Utiliza como entrada el diagrama de red con
las duraciones, dependencias y restricciones previamente definidas. A partir
de esto, se calcula el camino crítico, luego se agrega la disponibilidad de
recursos al cronograma lo que dará como resultado un cronograma
modificado. Este método consiste en agregar colchones que se visualizan
como actividades no laborables, esto para no alterar la duración estimada
de las actividades planificadas. Una vez definidas las actividades colchón,
se programan las actividades planificadas en las fechas de inicio y
63
finalización más tardías posibles, por consecuencia, este método busca
gestionar las duraciones de las actividades ficticias o colchones y los
recursos aplicados a las actividades previamente planificadas.
- Software de Gestión de Proyectos: Existen programas que facilitan la
gestión de proyectos, desde la elaboración del cronograma, estimación de
costos hasta análisis de riesgos, es importante apoyarse en estas
herramientas ya que facilitan el trabajo y permiten integrar diferentes áreas
de conocimiento.
- Calendarios Aplicables: Los calendarios tanto de recursos como de
actividades deben ser tomados en cuenta al crear el cronograma, para
tomar en cuenta factores como días no laborables, calendarios específicos
para algún recurso o bien para tomar en cuenta condiciones climáticas
predecibles que puedan afectar el desarrollo del proyecto.
Definición de hitos (puntos de control)
La definición de los puntos de control en el cronograma es un aspecto clave para
realizar el seguimiento y control del proyecto, los hitos pueden ser entregables o
simplemente puntos en los que se determina que se va a controlar lo que se está
haciendo en relación con lo que se debería estar haciendo. Esta parte del
desarrollo se lleva a cabo desde que se plantea el enunciado de alcance
preliminar en donde se van definiendo los entregables, éstos generalmente son
por sí mismos puntos de control, pero además es necesario determinar en qué
otros momentos del cronograma se considera pertinente realizar un análisis de
control.
2.3.4.4 Costo
Todos los proyectos tienen asociado un costo de realización, en esta área de
conocimiento se administra todo lo referente a lo que costará realizar el proyecto,
definición, distribución y control del presupuesto. En este apartado se presenta la
información de procesos, técnicas y herramientas para esta gestión.
64
2.3.4.4.1 Línea Base de Costos
La línea base de costos tiene como objetivo graficar el comportamiento esperado
del proyecto a lo largo del tiempo, facilitar la supervisión, medición y control del
rendimiento del costo en el proyecto. Generalmente se desarrolla sumando los
costos estimados por periodo y se representa por medio de una curva S, como se
puede apreciar en la siguiente figura:
Figura 24: Ejemplo de línea base de costo
Las líneas base de costos no necesariamente se hacen para el valor total del
proyecto, esta es una herramienta que se puede utilizar para cualquier evaluación
de costo que quiera hacerse, llámese de la utilización de un material en el
proyecto o bien para detallar el presupuesto estimado para una fase, de manera
que permite entrar en el nivel de detalle que se desee, esto dependerá de la
magnitud de proyecto y del detalle que se requiera administrar. Esta información
es utilizada como base para aplicar la técnica de valor ganado (descrito en la
siguiente sección) Yamal Chamoun en su libro Administración Profesional de
Proyectos, propone los siguientes cuatro métodos para facilitar la tarea:
0
2000
4000
6000
8000
10000
12000
14000
0 2 4 6 8 10
Costo Presupuestado Acumulado
CPA
Valores Acumulativos
Tiempo
65
Tabla 6: Métodos para presupuesto base (Chamoun, 2002)
Método Descripción Ventajas Desventajas Ponderación de objetivos
Para cada partida del WBS se establecen objetivos y se les asigna valores específicos del presupuesto.
Es más objetivo que la mayoría de los métodos disponibles.
Difícil de planear y administrar. Requiere de una coordinación estrecha entre la conformación de los paquetes del WBS, la elaboración del programa y la estimación de los recursos.
Fórmula preestablecida
20/80; Se adquiere el 20% del valor ganado cuando inicia y el 80% cuando termina. Se podría utilizar 25/75, 50/50, etc. ó 20/40/40, 25/25/50, etc.
Fácil de entender Requiere de paquetes de trabajo del WBS detallados y de corta duración.
Porcentaje de avance
Estimados de avance del proyecto con base en porcentajes
Es el más fácil de todos los métodos.
Los estimados de avance tienden a calcularse subjetivamente. Reportes sencillos de manipular.
Porcentaje de avance con objetivos
Permite los estimados de avance con base en porcentajes hasta cierto valor preestablecido para cada objetivo.
Provee el balance entre los estimados subjetivos y el establecimiento de objetivos.
Resulta más complicado que el método del Porcentaje de avance.
2.3.4.4.2 Valor Ganado
Esta herramienta permite medir la relación de tiempo y costo real del proyecto en
un momento dado con respecto a lo planificado, se comparan los datos actuales
con los datos planificados al mismo momento y se determina así, la desviación del
proyecto para posteriormente aplicar acciones correctivas oportunas.
A continuación se definen algunos de los conceptos fundamentales de esta teoría
(Guido, 2003):
- CTP (Costo Total Presupuestado): Se refiere al costo total que se
presupuestó para cada una de las actividades, se puede tomar el valor del
CTP por paquete de trabajo y este valor correspondería a la suma del costo
de sus actividades.
66
- CPA (Costo Presupuesto Acumulado): Es el costo que se tenía
presupuestado para realizar el trabajo programado para un momento dado,
en general este valor será la línea base para el análisis del desempeño del
costo proyecto.
- CR (Costo Real): Corresponde a lo que se ha gastado a la fecha en el
proyecto, este valor se puede determinar por medio de un continuo control y
documentación de facturas, informes u otros documentos que indiquen lo
que se ha gastado.
- CC (Costo Comprometido): Son los costos que si bien no han sido
pagados, ya se han comprometido y se sabe que deben pagarse en un
futuro, por ejemplo contrataciones, pedidos a proveedores.
- CRA (Costo Real Acumulado): Es la suma de lo que se ha gastado hasta el
momento, tomando en cuenta los costos comprometidos.
- Valor Devengado: Valor del trabajo realizado en un punto de tiempo, es el
porcentaje de trabajo realizado por el costo total del proyecto.
- VDA (Valor Devengado Acumulado): Se mide por cada paquete de trabajo
y corresponde a la multiplicación del trabajo realizado por el costo total de
cada uno de los paquetes de trabajo.
Para mayor comodidad este control puede realizarse a nivel de paquetes de
trabajo y si fuera necesario detectar en qué momento del proyecto se han dado
anomalías puede detallarse a nivel de actividades.
Los diagramas y tablas facilitan el análisis, permiten comparar y visualizar el
estado actual del proyecto para así tomar decisiones oportunas, potenciar los
resultados en caso de que sean positivos o bien modificar algunos aspectos para
alinear el proyecto de acuerdo a lo planificado.
Otros aspectos que deben medirse son:
- IDC (Índice del Desempeño del Costo): Mide la eficiencia del costo con que
se está realizando el proyecto, para realizar este cálculo se utiliza la
siguiente fórmula:
67
��� �VRA �� � �������� �������� �
CRA � �� ���� �������� �
- VC (Variación del Costo): Permite conocer la brecha que existe entre el
trabajo realizado y el costo actual.
� � �� �� � �������� �������� � � ��� � �� ���� �������� �
- CPAT (Costo Pronosticado a la Terminación): Este valor permite
pronosticar diferentes escenarios para determinar cómo va a quedar el
costo al finalizar el proyecto.
o Primer Método: Supone que el trabajo por realizar se realizará con
la misma tasa de eficiencia que se ha tenido hasta el momento, este
método nos puede brindar el escenario de cómo va a seguir el
proyecto bajo las condiciones en que está al momento del análisis.
���� � ���
���
o Segundo Método: Se asume que lo que falta del proyecto se
realizará de acuerdo al presupuesto planificado. Este método permite
crear un escenario en donde se va a cumplir el presupuesto,
generalmente para lograr esto se alteran los aspectos de tiempo o
alcance.
���� � ��� ��� � ���
o Tercer Método: Consiste en volver a estimar los costos para las
actividades pendientes de realizar y sumar el monto resultante con el
Costo Real Acumulado. Este método consume más tiempo pero
permite realizar ajustes para cumplir con el presupuesto en la
medida de lo posible.
���� � ��� !���� "��#���#ó� �� � �� ���������
68
Los autores Gido y Clemens presentan en su libro “Administración Exitosa de
Proyectos”, las siguientes recomendaciones generales para aplicar el valor
ganado en los proyectos:
- Este análisis debe realizarse oportuna y periódicamente.
- Se debe analizar el desempeño del costo para determinar qué paquetes o
actividades requieren alguna acción correctiva, elegir la acción correctiva
más adecuada en caso de que corresponda y finalmente revisar y actualizar
el plan de proyecto con la información de tiempo y costo actualizada
además de las acciones correctivas determinadas.
- Los paquetes o actividades que presenten una variación de costo negativa
o bien si su índice de desempeño es inferior a 1.0 deben ser analizadas con
mayor detalle, con el fin de evitar atrasos o faltantes de presupuesto.
- Dos de las técnicas que existen para realizar acciones correctivas son:
o Actividades que se realizarán a corto plazo: En la medida de lo
posible se deben realizar correcciones en las actividades más
prontas a desarrollarse, no es recomendable esperar.
o Actividades que tienen un estimado de costos grande: Generalmente
las actividades que requieren más presupuesto son las que pueden
reducir su costo en mayor medida.
- Buscar alternativas para disminuir costos, ya sea buscando mejores
opciones con respecto a materiales, proveedores, recursos o técnicas para
aumentar la productividad en caso de que esto sea posible.
2.3.4.5 Riesgos
Esta última área de conocimiento si bien no es una de las áreas “base” que se
encuentra en todos los proyectos es una de las más importantes, por su influencia
en el éxito o fracaso de un proyecto, su objetivo es analizar los factores que
puedan tener algún impacto positivo o negativo en el proyecto, para aumentar la
probabilidad de éxito del proyecto.
69
Existen diversas técnicas para gestionar los riesgos de un proyecto, en las
siguientes secciones se presentan las más importantes que además serán
utilizadas en el desarrollo de esta metodología.
2.3.4.5.1 Identificación de Riesgos
Es necesario identificar los riesgos antes de comenzar un proyecto y documentar
las características referentes a ellos con el fin de conocer qué factores pueden
afectar de alguna manera y tener claro el alcance y repercusión de cada uno de
ellos. Deben estar involucrados casi todos los Stakeholders, entre ellos el gerente
de proyecto, miembros del equipo, equipo de gestión de riesgo en caso de que
aplique, clientes, expertos ya sea en la materia o bien en riesgos.
Entre las entradas que alimentan este proceso se encuentran los activos de
proceso de la empresa, en caso de que la empresa no cuente ellos, es necesario
recurrir a técnicas como la lluvia de ideas, análisis de los factores ambientales de
la empresa, investigación de proyectos similares y por supuesto revisión del
enunciado de alcance y el plan de gestión del proyecto para identificar todos
aquellos eventos o factores que pueden influir durante la ejecución.
Algunas de las herramientas que se recomiendan para la realización de esta tarea
son las siguientes:
Para la recopilación de información se recomienda utilizar una o varias de las
siguientes:
- Técnica Delphi: consiste en buscar el consenso entre expertos,
generalmente se realizan encuestas o cuestionarios anónimos de manera
que todos puedan dar su opinión acerca de los riesgos que consideran más
relevantes, luego una persona encargada recopila la información, la
reformula y envía a los expertos en busca de una retroalimentación. Este
proceso se lleva a cabo hasta lograr un consenso o resultado esperado.
70
- Lluvia de ideas entre los miembros del equipo, en este tipo de reuniones
debe haber un moderador y el objetivo es generar una lista de posibles
riesgos y una categorización de los mismos.
- Entrevistas tanto a los involucrados del proyecto como a especialistas.
- Análisis FODA (Fortalezas, Oportunidades, Debilidades y Amenazas) del
proyecto.
El análisis mediante Lista de Control consiste en utilizar una lista de riesgos
previamente definida en proyectos pasados como línea base para la identificación
y gestión de riesgos.
Las asunciones que se plantearon en el acta de constitución del proyecto
generalmente son a su vez, riesgos de los proyectos, dado que no son aspectos
100% seguros, sino que más bien dependen de terceros.
Las técnicas de diagramación facilitan el entendimiento y clasificación de los
riesgos, a continuación se da una breve explicación de tres de estas técnicas con
su respectivo ejemplo.
- Causa-Efecto o también conocido como espina de pescado o Ishikawa el
cual sirve para clasificar los riesgos en grupos y determinar cuál puede ser
la causa de un riesgo o grupo de riesgos.
Figura 25: Diagrama Causa-Efecto (Ishikawa)
71
- Diagrama de flujo es una representación de cómo se lleva a cabo un
proceso, su objetivo es facilitar el entendimiento de un problema; en la
gestión de riesgos resulta útil para el análisis de las consecuencias que
puede ocasionar un riesgo, en la siguiente figura se presenta un ejemplo de
este tipo de diagrama.
Figura 26: Diagrama de flujo
- Diagrama de influencias permite modelar gráficamente un sistema en
donde se identifican las influencias entre los componentes, la cronología de
eventos y otras relaciones que se dan entre variables y resultados.
2.3.4.5.2 Análisis Cualitativo de riesgos
Este tipo de análisis consiste en priorizar los riesgos previamente definidos, de
manera que sea más sencillo visualizar los riesgos de acuerdo a su prioridad de
ocurrencia, al impacto que puedan causar dentro del proyecto, plazo y tolerancia
tomando en cuenta las restricciones definidas en el enunciado preliminar de
alcance.
72
Para este proceso se debe contar con los activos de proceso, el enunciado de
alcance, la información inicial del plan de gestión de riesgos y el registro de
riesgos. Existen diferentes técnicas para realizar este análisis y por medio de la
combinación de ellas se puede disminuir la subjetividad, algunas de las más
utilizadas son las siguientes:
- Evaluación de Probabilidad e Impacto de los riesgos: Determina tanto la
probabilidad de ocurrencia para cada uno de los riesgos, como el impacto
que éste pueda tener sobre cada uno de los objetivos del proyecto, ya sea
en términos de tiempo, costo, alcance o calidad. Estos riesgos se analizan
sin importar que su impacto sea negativo (amenazas) o positivo
(oportunidades). La probabilidad e impacto pueden obtenerse por medio de
activos de proceso (si están disponibles), juicio de expertos y entrevistas o
reuniones con participantes clave, si se hace por medio de reuniones es
importante que las personas que emiten criterio lo hagan justificadamente
de acuerdo a los objetivos del proyecto.
- Matriz de probabilidad e impacto: Esta matriz se basa en definir una
calificación para cada riesgo combinando los datos de probabilidad e
impacto previamente definidos de manera que permite organizar los riesgos
por prioridad alta, media o baja, esta calificación se puede hacer numérica o
bien descriptiva (por medio de los estados antes mencionados) esto
dependerá de la organización, en dado caso, la idea es que esta
calificación refleje cuáles riesgos hay que monitorear con más cuidado.
- Evaluación de la calidad de los datos sobre riesgos: Es una técnica
para evaluar el grado de utilidad de los datos sobre los riesgos, se examina
el grado de entendimiento del riesgo, la exactitud, calidad, fiabilidad e
integridad de los datos sobre el riesgo.
73
2.3.4.5.3 Análisis Cuantitativo de riesgos
Consiste en tomar los resultados obtenidos en el análisis cualitativo y analizarlos
por medio de una asignación numérica, se utilizan técnicas tales como
simulaciones Monte Carlo y análisis mediante el árbol de decisiones, los objetivos
de este análisis son (PMBook, 2004):
- Cuantificar los posibles resultados del proyecto y sus probabilidades.
- Evaluar la probabilidad de lograr los objetivos específicos del proyecto.
- Identificar los riesgos que requieren una mayor atención mediante la
cuantificación de su contribución relativa al riesgo general del proyecto.
- Identificar objetivos de costo, cronograma o alcance realistas y viables,
dados los riesgos del proyecto.
- Determinar la mejor decisión de dirección de proyectos cuando algunas
condiciones o resultados son inciertos.
Este proceso utiliza de insumo los activos de proceso, el enunciado de alcance del
proyecto, el plan de gestión de riesgos, registro de riesgos y el plan de gestión de
proyecto, específicamente la sección de tiempo y costo.
Entre las herramientas y técnicas que presenta el PMBook, se encuentran las
siguientes:
Técnicas de Recopilación y Representación de datos
- Entrevistas, utilizadas principalmente para cuantificar probabilidad e
impacto de los riesgos sobre los objetivos del proyecto, la forma en que se
recopila la información dependerá del análisis posterior que desee hacerse.
- Distribuciones de probabilidad, en el caso de las distribuciones continuas de
probabilidad se representa la incertidumbre de los valores, por ejemplo
duración de las actividades. Las distribuciones discretas generalmente se
utilizan para representar resultados inciertos, como por ejemplo el resultado
de una prueba.
- Juicio de expertos, ya sean internos o externos pueden validar que los
resultados y las técnicas utilizadas sean correctas.
74
Técnicas de Análisis Cuantitativo de Riesgos y de Modelado
- Análisis de sensibilidad, determina cuáles riesgos tienen un mayor impacto
sobre el proyecto, tomando como base un objetivo se examina la
incertidumbre de cada elemento del proyecto sobre ese objetivo para
determinar en qué medida puede verse afectado.
- Análisis del valor monetario esperado, calcula el resultado promedio cuando
existe incertidumbre o varios escenarios a futuro. El valor monetario se
expresa como positivo o negativo dependiendo de si corresponde a
oportunidades o amenazas.
- Análisis mediante árbol de decisiones, describe una situación que se está
considerando y las implicaciones que ésta pueda tener, representando las
opciones y escenarios posibles, tomando en cuenta el costo, probabilidades
y recompensas de cada uno de los caminos.
- Modelado y simulación, las simulaciones transforman las incertidumbres del
proyecto previamente definidas, en el impacto que podrían tener sobre los
objetivos del proyecto, la técnica más utilizada es la de Monte Carlo, la cual
consiste en realizar cálculos reiteradas veces utilizando diferentes entradas
y distribuciones de probabilidad, esto resulta en un comportamiento
esperado del proyecto.
2.3.4.5.4 Planificación de la Respuesta a los Riesgos
Se realiza tomando en cuenta la prioridad y probabilidad de ocurrencia, entre las
tareas a realizar se encuentran: determinar el responsable del riesgo y desarrollar
el plan de contingencia, tomando en cuenta factores como asignación de recursos,
presupuesto, determinación de actividades en el cronograma, entre otros.
Esta información debe ser incluida dentro del plan de gestión de riesgos y debe
ser firmada y acordada por los participantes, así cumplirá la función de acuerdo
oficial sobre cómo actuar en caso de que se dispare uno de los riesgos.
75
Entre las herramientas y técnicas que el PMI propone para este proceso, se
encuentran:
- Estrategias para riesgos negativos o amenazas:
o Evitar: Implica cambiar el plan de gestión para eliminar la amenaza
que representa el riesgo, ya sea aislar los objetivos del proyecto del
impacto del riesgo o relajar el objetivo que está en peligro.
o Transferir: Se refiere a transferir la responsabilidad de gestión del
riesgo a terceros, se aplican primordialmente a asuntos financieros y
se refieren a seguros, garantías de cumplimiento, cauciones,
certificados de garantía, entre otros.
o Mitigar: Esta técnica consiste en reducir la probabilidad y/o impacto
de un evento de riesgo adverso a un umbral aceptable, es decir
tomar acciones preventivas para reducir la probabilidad de
ocurrencia y/o el impacto del riesgo, de manera que las acciones
correctivas sean menos complejas y costosas para el proyecto.
- Estrategias para riesgos positivos u oportunidades:
o Explotar: Se busca este tipo de estrategia cuando se desea o
necesita que la oportunidad o riesgo se dé, consiste en explotar las
respuestas buscando la asignación de recursos o modificaciones de
cronograma de manera que propicie el riesgo.
o Compartir: Implica asignar a un tercero con mejores capacidades o
facilidades para tomar la oportunidad en beneficio del proyecto.
o Mejorar: Modifica el tamaño de la oportunidad de manera que
aumenta la probabilidad y/o impacto positivo, identificando y
maximizando las fuerzas impulsoras clave para el riesgo, buscando
proactivamente reforzar e impulsar las condiciones que lo disparan.
- Estrategia común ante amenazas y oportunidades
o Aceptar: Comúnmente no es fácil o posible eliminar un riesgo, al
aceptar el riesgo se indica que se aceptará con sus consecuencias,
76
ya sea pasivamente (se deja en manos del equipo de proyecto) o
activamente (se establece la reserva de contingencia que se
considere necesaria para hacerle frente).
- Estrategia de respuesta para contingencias
o Es un plan de respuesta a los riesgos que se considera necesario
especificar en caso de que estos se den por las condiciones que allí
se especifiquen, se deben definir los indicadores que servirán como
advertencia del riesgo, así como la forma de proceder si el riesgo
efectivamente se dio.
77
Capítulo 3
3 Marco Metodológico
3.1 Fuentes de Información
La realización de este proyecto se va a llevar por medio de una investigación mixta
en la que las entradas principalmente serán de carácter bibliográfico, tanto de
libros de texto como de información disponible en Internet principalmente en temas
de administración de proyectos, tecnologías de información e ingeniería de
software.
La línea base o punto de partida de la investigación será la “Guía de los
Fundamentos de la Dirección de Proyectos” del PMI, complementando con libros y
artículos acerca de Ingeniería de Software, además de información adicional
acerca de herramientas y técnicas que se utilizan actualmente que puedan apoyar
el desarrollo de esta metodología.
3.2 Métodos de Investigación
La metodología que se va a seguir para desarrollar este proyecto tiene como
primer paso, una investigación de distintas fuentes informativas acerca de temas
relevantes en las áreas de conocimiento indicadas en los objetivos específicos, las
cuales funcionarán como entrada a una segunda etapa que será el planteamiento
de una metodología de administración de proyectos, mediante el desarrollo de
plantillas, políticas, técnicas y herramientas.
Con el fin de facilitar el desarrollo del proyecto se trabajará en un grupo de
proceso a la vez según lo estimado en el cronograma, cada etapa de proyecto se
subdividirá en actividades de investigación y actividades de desarrollo de la
metodología con todo lo que esto implique, al final de cada una de estas etapas se
obtendrá como resultado el entregable correspondiente a un capítulo de la
metodología final, esto con el fin de promover las revisiones periódicas y hacer
78
más sencilla la incorporación de las correcciones en cada etapa según
corresponda.
3.3 Herramientas de Investigación
Las herramientas que se van a utilizar tanto para el desarrollo como para la
propuesta final de esta investigación son las siguientes:
Plantillas
Por medio de la cual se estandarizarán y documentarán los procesos que se
deben desarrollar según la propuesta para la gestión de proyectos de desarrollo
de software a la medida y modelado de bases de datos.
Software
Las diferentes herramientas que ofrece el mercado son fundamentales para el
desarrollo de este proyecto, no solo para utilizarlas y facilitar el desarrollo del PFG,
sino también para investigar acerca de las opciones disponibles con el fin de
proponer las que se brinden mayores beneficios en el desarrollo de este tipo de
proyectos.
Diagramas de flujo
Este tipo de diagramas facilitan mucho la representación de flujos de procesos o
secuencias a seguir en distintas partes de la metodología a desarrollar.
Herramientas propias de Administración de Proyectos
Tales como la EDT (Estructura Detallada de Trabajo), Cronogramas, Diagramas
Causa-Efecto (especialmente para la gestión de riesgos), entre otros.
79
3.4 Creación de la Metodología
La metodología va a estar compuesta por nueve capítulos, de los cuales el
primero tendrá como finalidad explicar a grandes rasgos lo que pretende esta
propuesta a manera de introducción, los siguientes cinco capítulos corresponderán
a cada uno de los grupos de proceso a desarrollar: Inicio, Planificación, Ejecución,
Seguimiento y Control, y Cierre, seguidamente se incluirán dos capítulos con un
resumen general de la metodología y un ejemplo de un caso ficticio. Y Finalmente,
dos capítulos que se definen con las conclusiones y recomendaciones.
En cada uno de los capítulos de grupos de proceso se definirán los procesos,
procedimientos y políticas que se recomienda seguir, además de las herramientas,
técnicas y plantillas propuestas para la gestión del área que corresponda con sus
respectivos ejemplos para facilitar el entendimiento y aplicación de la misma.
En los dos capítulos siguientes se presentará un resumen y un ejemplo de la
metodología, con el fin de sintetizar y ver más claro el orden de las actividades y
plantillas que se desarrollaron, en el caso del ejemplo, se agregan solo algunas de
las plantillas para cada grupo de proceso.
Finalmente en la sección de conclusiones y recomendaciones se sintetizarán
todos aquellos aspectos que se consideren relevantes para el uso correcto de la
metodología en cuestión.
80
Capítulo 4
4 Desarrollo de la Metodología
4.1 Introducción
Esta metodología pretende ser una guía para la implementación de proyectos de
desarrollo de software a la medida y diseño de base de datos en cinco de las
áreas que frecuentemente tienen un mayor impacto en el éxito o fracaso de este
tipo de proyectos.
Para la utilización de esta metodología es recomendable revisar por completo la
información, técnicas y herramientas que aquí se presentan, con el fin de evaluar
en primera instancia el contenido de la misma y su aplicabilidad según el ámbito y
las necesidades particulares tanto del proyecto como del negocio y empresa.
La metodología está definida según las cinco fases de proyecto definidas por el
PMI (Inicio, Planificación, Ejecución, Seguimiento y Control, y Cierre) en cada una
de las etapas mencionadas, se iniciará la sección con un diagrama de proceso,
seguido por el contenido con ejemplos y plantillas según aplique.
4.2 Inicio
En la fase inicial del proyecto se debe trabajar en actividades y documentos
específicos que facilitan posteriormente la planificación, en la figura anterior se
muestra a grandes rasgos cuáles van a ser las tareas a realizar.
81
4.2.1 Acta de Constitución del Proyecto (Charter)
Para el desarrollo de este documento se propone la siguiente plantilla (Tabla No.
7), la cual podrá ser modificada de acuerdo a las necesidades particulares del
proyecto al que se desee aplicar, en los diferentes apartados viene una pequeña
descripción de la información que debe contener.
Tabla 7: Plantilla - Acta de constitución o Charter
Acta de Constitución
Información General
Fecha
[Fecha documento]
Nombre del Proyecto
[Nombre oficial del proyecto a desarrollar]
Áreas de conocimiento / procesos
� [Áreas de conocimiento a desarrollar] � [Procesos que se desarrollarán]
Área de aplicación (sector / actividad)
[Sector de la industria a la que corresponde el proyecto] [Actividad del sector que se va a impactar]
Fecha de Inicio
<Fecha en que iniciará el proyecto>
Fecha tentativa de Finalización
[Fecha en que se planea terminar el proyecto]
Objetivos del Proyecto
General
[Objetivo general que se desea alcanzar con el proyecto]
Específicos
[Objetivos específicos a los que responde el proyecto]
Descripción del Producto
Entregables Finales
[Aquí se definen los entregables que se van a producir a lo largo del proyecto en las diferentes etapas que se definen y se van a desarrollar]
Información del Proyecto
Necesidad del Proyecto
[Se define de manera general por qué se va a realizar el proyecto y a qué necesidad responde, ya sea de la empresa, del negocio o la que corresponde]
Justificación del Impacto
[Se especifica qué impacto tendrá la realización del proyecto en el ámbito que éste se haya planteado y por qué este impacto es importante]
82
Supuestos y Asunciones
[En esta sección del documento se listan todos los aspectos que se deben asumir y que tienen o pueden tener algún impacto en el proyecto, generalmente son ajenos al círculo de influencia tanto del gerente de proyecto como del proyecto mismo]
Restricciones
[Factores generales que delimitan el proyecto, tales como tiempo, presupuesto, recursos entre otros]
Factores Claves de éxito
[Aspectos de los cuales depende el éxito del proyecto, tales como generalidades que permitirán medir la calidad del proyecto o factores de los que depende para que el producto o servicio desarrollado sea considerado exitoso de acuerdo a los parámetros definidos en un inicio]
Identificación de Grupos de Interés (Stakeholders)
[En esta sección se definen a nivel macro quiénes son los involucrados en el proyecto y de manera resumida cuál es el rol de cada uno de ellos en el desarrollo del mismo, se debe mencionar la responsabilidad y participación que tendrán]
Patrocinador Gerente de Proyecto
4.2.2 Modular el proceso
Considerando la cantidad de documentación que debe generarse a lo largo de un
proyecto, es conveniente clarificar y definir los procesos a seguir, sobre todo a
nivel de organización. Es fundamental clarificar el flujo que llevará la información,
aspectos como quién se encarga de elaborar, revisar y aprobar documentos,
organización de las reuniones, entre otros. Aunque hay que tomar en cuenta que
generalmente existen excepciones con respecto a que no siempre son las mismas
personas las que están involucradas en todas las fases, es importante definir a
nivel macro el proceso y los involucrados, puede representarse a manera de
esquema, el objetivo es que sea lo más simple posible.
La siguiente figura muestra un ejemplo sencillo de cómo se puede modular un
proceso de solicitud de cambio, la cantidad de niveles y pasos para su aprobación
es dependiente de la organización del proyecto y de la empresa.
83
Figura 27: Ejemplo - Proceso de solicitud de cambio
4.2.2.1 Documentación
En el área de computación la documentación del software es de vital importancia,
principalmente en términos de mantenimiento ya que los programas de software
bien documentados hacen que el código sea más fácil y rápido de modificar, ya
sea para resolver problemas o bien para adaptarlo a nuevas necesidades.
A manera de resumen la siguiente lista muestra una serie de documentos que
deben generarse1 durante el proceso de ejecución, adicionales a la
documentación de la administración del proyecto:
1. Especificación de los casos de uso.
2. Especificación de requerimientos.
3. Diagramas de clases y de secuencia.
4. Diseño.
5. Casos de Prueba.
6. Código: Listado en papel del código fuente y del ejecutable.
7. Reportes de Pruebas del sistema.
8. Software para la instalación.
9. Documentación para usuarios.
10. Documentos administrativos:
� Minutas de reuniones.
� Reporte técnico.
� Listas de Chequeo.
1 Los documentos descritos en la lista se mencionan a lo largo del documento en las fases que corresponda, se presentan plantillas en caso de que aplique el uso de las mismas.
84
4.2.3 Análisis de enfoque de los participantes
4.2.3.1 Mapa de Expectativas
El mapa de expectativas puede documentarse de diferentes maneras, para
términos de esta metodología se recomienda la siguiente plantilla, al igual que en
documentos anteriores, debe tomarse en cuenta que las columnas pueden ser
modificadas de acuerdo a las necesidades de cada empresa.
Tabla 8: Plantilla - Mapa de expectativas
Proyecto: [Nombre de Proyecto] Mapa de Expectativas
Cód Nombre Unidad Rol Responsabilidad Expectativa
[Id de participante]
[Nombre Completo]
[Dependencia que representa]
Rol que cumple (gerente, colaborador, etc)
[Responsabilidad dentro del proyecto]
[Expectativas con respecto al proyecto]
4.3 Planificación
4.3.1 Plan de Gestión de Alcance
La planificación del alcance cuenta con dos etapas primordiales, una se conoce
como la declaración de alcance que contiene la obtención y análisis de
requerimientos de acuerdo a lo expuesto en el marco teórico y la segunda es la
creación de de la EDT, en esta sección se van a definir las plantillas y
herramientas necesarias para llevar a cabo esta gestión.
85
4.3.1.1 Elección del Ciclo de vida de software
Una de las etapas base para comenzar la planificación del desarrollo de un
sistema de información es la elección del ciclo de vida que se va a utilizar, para
realizar este análisis es necesario recurrir a la información expuesta en la sección
2.2.2 Ciclos de vida del software de este documento.
4.3.1.2 Declaración de Alcance
Para definir el alcance se utiliza el enunciado de alcance y para esto se propone la
siguiente plantilla, que contiene la información necesaria.
Tabla 9: Plantilla – Enunciado de alcance
ID Entregables Descripción Criterios de Aceptación Métricas para los
criterios
FASE #: [Nombre de la Fase (si aplica)]
E#.# [Nombre del entregable]
[Descripción breve del entregable]
[Indicadores definidos para que el entregable se considere correcto y se pueda aceptar]
[Métricas para evaluar la calidad del entregable]
4.3.1.3 Obtención de Requerimientos
4.3.1.3.1 Requerimientos Funcionales
Esta fase suele ser una de las más críticas en los proyectos de software, es
precisamente por esto es que es necesario prestar particular atención,
maximizando la comunicación analista/cliente.
Es fundamental complementar los diagramas con documentación que clarifique y
amplíe los datos para minimizar el porcentaje de error, dentro de esta
documentación está la Especificación de Caso de Uso, tal y como se especifica en
la plantilla que se presenta a continuación, esta contiene la descripción detallada
del caso de uso y viene a complementar los diagramas.
86
Tabla 10: Plantilla - Especificación de caso de uso
[Nombre del Sistema] Versión: # Especificación Caso Uso: [Nombre del Caso de Uso] Fecha: Doc. Nº CU#-V#-[fecha]
Especificación Caso Uso: [Nombre CU]
1. Nombre Caso de Uso: [Nombre CU] 1.1 Descripción Breve [Se describe brevemente en qué consiste el caso de uso y quién interacciona] 2. Flujo de Eventos 2.1 Flujo Básico [Se indica el flujo que se ejecuta para llevar a cabo este caso de uso, en caso de depender de otro caso de uso, se hace la referencia al documento que corresponda. Es importante especificar si el caso de uso puede tener varios flujos alternativos, por ejemplo típicamente cuando se refiere a un IMEC (Insertar-Modificar-Eliminar-Consultar) de algún elemento, se debe especificar el flujo a seguir para cada uno de estos pasos] 2.1.1 Primer Flujo Alterno: [Nombre del Flujo alternativo #1]
E-#: [Se enumeran todas las posibles excepciones que puedan darse en la ejecución de este flujo, en otro punto de documento se describe propiamente el flujo a seguir y se citan estas excepciones. Por ejemplo si se requiere algún dato en particular y este dato no está, se da una excepción en el sistema en un determinado momento].
# Acciones del Actor # Acciones del sistema
1 [Se describen detalladamente todos los pasos que lleva a cabo el actor involucrado]
2 [Se describe la respuesta o acción que realiza el sistema conforme va interactuando el actor, en caso de que sea posible que se de alguna de las excepciones descritas anteriormente, se mencionan de la siguiente forma (E-#)]
3. Requerimientos Especiales [Se menciona cualquier elemento externo que este caso de uso requiera para funcionar correctamente, por ejemplo si se necesita que un servidor esté en línea o permisos en una base de datos] 4. Pre-condiciones [Aquí se describen las acciones previas que se requieren que el flujo funcione, por ejemplo si se necesitan datos previos provenientes de otro caso de uso] 5. Post-condiciones
87
[Elementos posteriores que son necesarios para el correcto funcionamiento del caso de uso, por ejemplo si se necesita que los datos aquí insertados se encuentren relacionados a algún otro elemento del sistema] 6. Puntos de extensión [Son los puntos en los cuales dependiendo de ciertos criterios, el sistema genera una interacción adicional, en caso de que aplique]
Confidencial [Organización, Año] Página #
4.3.1.3.2 Requerimientos No Funcionales
Los requerimientos no funcionales deben listarse como un apartado del
documento, así se pueden tomar en cuenta a la hora de planificar el alcance, pero
por su naturaleza no se utilizará ningún tipo de plantilla, simplemente se deben
incluir dentro del plan de gestión de alcance.
4.3.1.4 Modelado de bases de datos
Para el diseño de base de datos en caso de que corresponda, se recomienda
modelar el problema utilizando la técnica de los diagramas Entidad-Relación
descritos en el marco teórico de este documento, esta parte es de fundamental
importancia ya que permitirá determinar de manera más sencilla aspectos que
afectan alcance, tiempo y costo.
4.3.1.5 Estructura Detallada de Trabajo
Como ya fue definido previamente la estructura detallada de trabajo es la
descomposición jerárquica de las actividades, estas actividades se definen
tomando en cuenta los entregables que se van a producir, los puntos de control
que servirán para medir y controlar el trabajo realizado, los objetivos y
requerimientos del proyecto. Conforme se baja en los niveles de la EDT se ven las
actividades más específicas y detalladas hasta llegar a tareas concretas.
Con el fin de clarificar lo que es y cómo se diseña una EDT, en la siguiente figura
se presenta el esquema de actividades que se definen para el desarrollo de una
página Web sencilla con acceso a base de datos.
88
Figura 28: Ejemplo de EDT
4.3.1.6 Plantilla de Plan de Gestión de Alcance
De acuerdo a lo expuesto en las secciones anteriores, se adjunta la plantilla para
la elaboración de este documento:
Tabla 11: Plantilla - Plan de gestión de alcance
Plan de Gestión de Alcance Versión: # Proyecto: [Nombre del Proyecto] Fecha: Doc. Nº #
Plan de Gestión de Alcance
1. Resumen Ejecutivo [Breve explicación que le permite al lector ubicarse dentro de la realidad del proyecto y lo que este pretende en la organización] 1.1 Descripción Breve [Se describe brevemente en qué consiste el proyecto] 2. Descripción del Proyecto 2.1 Generalidades del Proyecto 2.1.1 Visión [Cuál es la visión del proyecto] 2.1.2 Requerimientos 2.1.2.1 Requerimientos Funcionales [Por medio de la siguiente tabla se enumeran todos los requisitos determinados y se les asigna
89
una prioridad, para determinar los requisitos funcionales es recomendable hacer el análisis mediante casos de uso, se debe hacer referencia tanto a los esquemas generados como a la especificación de cada caso de uso, también se puede hacer una tabla por cada uno con el fin de modular los requerimientos planteados]
No. Descripción Prioridad R# [Nombre del requerimiento] [Baja, Media, Alta] R# [Nombre del requerimiento] [Baja, Media, Alta]
2.1.2.1 Requerimientos No Funcionales [Listado de los requerimientos no funcionales que se deben de tomar en cuenta con el proyecto] 2.1.3 Resultados Esperados [Qué se espera del proyecto, enfocado a lo que se va a producir al final, ya sea un producto per se o un servicio] 2.1.4 Estrategia [Descripción breve de cómo se va a realizar el proyecto, por ejemplo si son varias fases cómo se van a dividir, qué se va a realizar en cada una de ellas y en qué orden] 2.2 Objetivos [Objetivos que se plantean para el proyecto, estos deben ser específicos sobre lo que se quiere lograr y qué debe satisfacer el proyecto] 2.3 Alcance del Proyecto [Esta sección debe contener datos acerca de los entregables, identificación, descripción, criterios de aceptación y métricas para evaluarlos. Para facilitar el procesamiento y organización de los datos, se propone el uso de una tabla como la que se presenta a continuación]
ID Entregables Descripción Criterios de Aceptación
Métricas para los criterios
# (Identificador
del Entregable)
[Nombre del entregable, ya sea un documento o bien un sub producto del producto final]
[Descripción corta de lo que contiene el entregable]
[Se especifican los criterios que determinan que el entregable está correcto, por ejemplo información acerca del contenido o funcionalidad]
[Aspectos que van a servir para medir que el entregable está completo de acuerdo a lo estipulado y cumple con los criterios de aceptación]
2.4 Clasificación de los Involucrados [Se identifican los involucrados y se define su rol en el proyecto] 3. Límites [Hasta donde llega el proyecto, esta sección resulta importante para definir el proyecto como tal] 4. Restricciones [Se deben citar las restricciones que pueden existir, por ejemplo en términos monetarios o bien de alguna otra circunstancia externa que pueda restringir de alguna manera el proyecto]
90
5. Supuestos (Asunciones) [Aspectos que es posible asumir, ya que no hay control directo sobre ellos entonces no se pueden solucionar, frecuentemente estas asunciones van posteriormente relacionadas a los riesgos] 6. Hitos del Cronograma [Puntos de control definidos para dar seguimiento al proyecto conforme se realiza, esto con el fin de permitir al gerente de proyectos hacer las correcciones necesarias para ir alineando la realidad con lo planificado] 6.1 Documentación a Generar [Se recomienda incluir la lista de la documentación que se va a generar, a menos de que esta documentación sea parte de los entregables del proyecto.] 7. Organización 7.1 Organigrama [Un breve resumen de cómo funciona la organización, si se cuenta con un organigrama es pertinente incluirlo] 7.2 Roles y Responsabilidades [Es fundamental definir quiénes van a tener un papel en el proyecto y cuál es su área de acción, es decir sus responsabilidades y su autoridad, con el fin de evitar problemas]
ACTOR RESPONSABILIDAD AUTORIDAD
[Actor identificado]
[Acciones o aspectos que debe controlar o ejecutar y por los cuales será responsable]
[Autoridad que este tiene dentro del proyecto para llevar a cabo las labores que tenga asignadas]
8. Estructura Detallada de Trabajo (EDT) [Se debe incluir el diagrama de EDT desarrollado para el proyecto] 8.1 Diccionario de la EDT [Plantilla del diccionario de EDT para cada una de las actividades definidas, o por lo menos de las actividades que tienen un mayor peso o impacto en el éxito del proyecto] Fecha de Revisión: [Fecha en que se revisa y aprueba el plan de gestión de alcance] Comentarios adicionales: [Espacio disponible para comentarios de la persona asignada a revisar el documento] Director de Proyecto:
_______________________ [Nombre Completo]
Revisor:
_______________________ [Nombre Completo]
91
Tabla 12: Plantilla - Diccionario de EDT
Diccionario de actividades de la Estructura Detallada de Trabajo (EDT)
Información General de la actividad Id: [# Consecutivo] EDT #: [Id de la actividad en la EDT]
Nombre de la Actividad: [Nombre puesto en la EDT] Descripción: [Descripción breve explicando en qué consiste la actividad] Entradas: [Documentos o requerimientos que necesita para comenzar] Salidas: [Cuál va a ser el resultado al finalizar la actividad] Puntos de Control: [Puntos de control o hitos para esta actividad] Responsable(s): [Responsables de la realización de la actividad] Recursos Materiales: [Recursos que se requieren de ser necesarios] Sub-contrataciones: [En caso de que aplique, se especifican las subcontrataciones]
Estimaciones de la Actividad
Trabajo [Trabajo a realizar] Costo Final: [Estimado del costo de
realizar esta actividad] Duración [Duración estimada]
Fecha Inicio [Fecha de inicio según cronograma]
Fecha Término
[Fecha de término según cronograma]
4.3.2 Plan de Gestión de Tiempo
4.3.2.1 Definición de actividades
Este proceso de acuerdo a la teoría descrita en la sección 2.3.4.3.1 se puede
realizar en un documento plano, pero es recomendable utilizar software
especializado para la gestión de proyectos, quizá el más popular es MS Project,
que es el que se va a utilizar en el siguiente ejemplo, este tipo de herramientas
permiten agregar información en columnas adicionales, además facilitan el
desarrollo y seguimiento de las etapas posteriores.
Al finalizar este proceso, debe estar definida la lista de hitos o puntos de control
que se consideran relevantes para el seguimiento y control del proyecto.
92
Figura 29: Ejemplo de lista de actividades
4.3.2.2 Secuenciación de actividades
El siguiente paso es organizar las actividades definidas de acuerdo a los criterios
desarrollados en la sección 2.3.4.3.2 de este documento, con el fin de continuar el
proceso de creación del cronograma.
4.3.2.3 Asignación de Recursos
La tabla No. 13 presenta una alternativa para la documentación de este proceso,
es recomendable incluir esta información en el software de gestión de proyectos
en caso de que se esté utilizando. Además como parte de esta tarea y como ya se
ha mencionado es necesario realizar las modificaciones pertinentes a los
documentos que corresponda con el fin de que la información sea oportuna, se
encuentre actualizada y funcione de entrada para las fases posteriores.
Tabla 13: Plantilla - Asignación de recursos
Recursos del Proyecto
Id Actividad Tipo de Recurso Cantidad estimada Observaciones
[Identificador según EDT]
[Recurso humano, equipo, material]
[Aproximado de las unidades que se consideran necesarias]
[Notas adicionales que sea necesario destacar]
4.3.2.4 Estimación de tiempo
Existen diversas técnicas para la estimación de tiempo y muchas son particulares
según la temática del proyecto, en esta metodología se propone el análisis
mediante puntos de función.
93
4.3.2.4.1 Análisis mediante puntos de función
Siguiendo lo definido en el marco teórico por medio del valor esperado se puede
determinar el tiempo estimado para el desarrollo del proyecto de una manera más
exacta, lo cual permitirá realizar la gestión del proyecto y por ende las otras fases
de gestión de tiempo de una manera más fácil y menos propensa a errores.
Esta técnica puede complementarse con el juicio de expertos y los activos de
proceso de proyectos anteriores, con el fin de analizar el resultado de la
estimación por puntos de función y ajustarla en caso de que se considere
necesario. Se presenta la siguiente plantilla para el análisis de puntos de función,
herramienta que nos servirá para estimar tanto tiempo como costo de proyectos
de software.
Tabla 14: Plantilla - Estimación de puntos de función
[Nombre de la empresa] Proyecto: [Nombre del Proyecto]
Estimación de Puntos de Función 1. Identificación de Funciones de Datos
Campos del Archivo Tipo [Nombre de la Entidad] [Se especifica si es ILF o EIF] [Atributos de esta entidad (especificar si es llave primaria o foránea)]
[Se menciona si es un DET (atributo de la entidad) o si este es de otra tabla (por implementación) ]
… … 2. Complejidad
Entidad ILF DET RET Complejidad [Nombre de la entidad] # # # [Según tabla] … … … … …
3. Funciones Transaccionales (EI)
Transacciones EI Contadas como Complejidad
[Nombre de la Entidad]
[Nombre de Transacción de administración]
[# de atributos (DET’s) y/o # de elementos de registro (FTR’s)] [Según tabla]
… … … 4. Consultas Externas (EQ)
EQ FTR DET Complejidad [Nombre de Transacción de consulta] [# de consultas] # [Según tabla] … … … …
94
5. Puntos de Función sin Ajustar
Componentes Niveles de Función Baja Media Alta
Archivos Lógicos Internos (ILF) # x 7 # x 10 # x 15 Archivos de Interface Externa (EIF) # x 5 # x 7 # x 10 Entradas Externas (EI) # x 3 # x 4 # x 6 Salidas Externas (EO) # x 4 # x 5 # x 7 Consultas Externas (EQ) # x 3 # x 4 # x 6
Total ∑ PFSA 6. Factor de Ajuste
1. Comunicación de Datos: # 2. Procesamiento datos distribuido: # 3. Rendimiento: # 4. Configuración: # 5. Tasa Transaccional: # 6. Entrada de datos en línea: # 7. Eficiencia del usuario final: # 8. Actualización en línea: # 9. Procesamiento Complejo: # 10. Reutilización: # 11. Facilidad de Instalación: # 12. Facilidad de Operación: # 13. Adaptabilidad a Múltiples Sitios: # 14. Facilidad de cambio: #
Total de Grados de Influencia (TI) → ∑
7. Puntos de Función Ajustados FA = (TI * 0.01) + 0.65 PF = FA * PFSA
8. Valor Esperado
6
)4( pesimistamediooptimo SSSVE
+∗+=
9. Costo estimado
CostoPFPFCostoTotal ∗=
10. Duración estimada
TiempoPFPFtalDuraciónTo ∗=
95
4.3.2.5 Desarrollo del Cronograma
De acuerdo a las herramientas expuestas en el marco teórico, se deben aplicar las
que se consideren más adecuadas crear el cronograma, es necesario tomar en
cuenta las duraciones obtenidas para cada una de las entidades analizadas por
puntos de función, de manera que se organicen las tareas de acuerdo al orden
lógico que estas deben seguir, tomando en cuenta la duración y restricciones de
cada una de ellas.
4.3.2.6 Plantilla de Plan de Gestión de Tiempo
En el siguiente cuadro se presenta la plantilla definida para el plan de gestión de
tiempo.
Tabla 15: Plantilla - Plan de gestión de tiempo
Plan de Gestión de Tiempo Versión: # Proyecto: [Nombre del Proyecto] Fecha: Doc. Nº #
Plan de Gestión de Tiempo
1. Presentación [Breve introducción del proyecto para ubicar al lector con respecto a lo que se tratará en este documento, haciendo referencia y/o anexando documentos generados previos a este que facilitarán o son indispensables para el entendimiento del contenido de este plan] 2. Estructura de Desglose de Trabajo (EDT) 2.1 Secuenciación [Se describe qué estrategia se utilizó para establecer la secuencia entre las actividades definidas (esto con el fin de que pueda servir de apoyo o insumo para proyectos próximos)] [Se debe presentar gráficamente la EDT actualizada del proyecto con la secuencia ya incluida y se debe clarificar cualquier nomenclatura utilizada en el mismo] 3. Diagrama de red y Ruta crítica [Debe incluirse el diagrama de red indicando la ruta crítica que se genera, incluyendo cualquier nomenclatura que deba especificarse o bien notas adicionales que sea pertinente mencionar, como restricciones o excepciones de x ó y actividad] 4. Estimación de tiempo y relaciones de dependencia [Se agrega y/o se hace referencia al análisis de puntos de función y se anota cualquier aspecto que haga relevante, la plantilla de este análisis fue presentada en la tabla No. 14. Además se recomienda adicionar el gráfico de Gantt o alguno similar que permita visualizar la secuencia de
96
actividades y tiempos asignados, permitiendo la visión global del proyecto] 6. Hitos del Cronograma [Lista actualizada de los hitos definidos para el seguimiento y control del proyecto] Fecha de Revisión: [Fecha en que se revisa y aprueba el plan de gestión de tiempo] Comentarios adicionales: [Espacio disponible para comentarios de la persona asignada a revisar el documento] Director de Proyecto:
_______________________ [Nombre Completo]
Revisor:
_______________________ [Nombre Completo]
4.3.3 Plan de Gestión de Costo
4.3.3.1 Estimación de Costo por medio de Puntos de Función
Los puntos de función permiten medir el costo de proyectos de esta índole de una
manera bastante acertada, es posible medir la complejidad, duración y basado en
estos dos parámetros, el costo. Al costo global del proyecto deben sumarse gastos
de operación generales en caso de que existan, costos asociados a compras y/o
contrataciones externas a la empresa además de holguras en el presupuesto (por
ejemplo para hacerle frente a imprevistos que se presenten de pequeña o
mediana incidencia), debido a que esta herramienta da como resultado una
estimación de costos únicamente del desarrollo de los objetivos planteados.
En la tabla No. 14, la plantilla de estimación de puntos de función, se presenta el
apartado que corresponde a la estimación de costo, en realidad la fórmula que allí
se presenta es bastante sencilla y es la multiplicación de los puntos de función
estimados para el proyecto por el costo de un punto de función, esto a grandes
rasgos dará el resultado del costo global.
97
Un dato importante es que para poder realizar este cálculo debe investigarse cuál
es el costo de un punto de función y esta unidad es dependiente de las empresas,
mercado, país, entre otros factores externos, es por esto que hay que recurrir a la
investigación del mercado o bien a una estimación interna luego de varios
proyectos realizados.
4.3.3.2 Presupuesto por fase (Plantilla)
Para realizar un seguimiento y control resulta necesario contar con un marco de
referencia de lo que se debe gastar de acuerdo a las fases que se van
desarrollando, para esta tarea se propone la plantilla No. 16, la cual deberá
utilizarse de acuerdo al nivel de detalle requerido. Además se recomienda
complementar la documentación con el gráfico de Línea Base de Costo.
Tabla 16: Plantilla - Presupuesto por fase
Presupuesto por fase Lista de actividades y montos presupuestados
Fase Clave Actividad de WBS Presupuestado %
[Fase macro a la que pertenece]
[Identificador en WBS]
[Actividad o tarea presupuestada]
[Monto estimado de costo para la actividad]
[Porcentaje con respecto al monto total presupuestado]
4.3.3.3 Plantilla de Plan de Gestión de Costo
Para documentar la planificación de costo, se recomienda el uso de la siguiente
plantilla la cual contiene los datos de lo que se analizó anteriormente.
Tabla 17: Plantilla - Plan de gestión de costos
Plan de Gestión de Costos Versión: # Proyecto: [Nombre del Proyecto] Fecha: Doc. Nº #
Plan de Gestión de Costos
98
1. Presentación [Breve presentación del proyecto para ubicar al lector con respecto a lo que se tratará en este documento, haciendo referencia o bien, anexando documentos previos que facilitarán o son indispensables para el entendimiento del contenido de este plan] 2. Estimación de Costos 2.1 Recursos [Se describe brevemente cómo se estimó el costo por recurso]
RECURSO TIPO ETIQUETA PARA MATERIALES DISPONIBILIDAD COSTO
[Nombre del recurso] [Trabajo / Material]
[Descripción del material en caso de que aplique]
[Porcentaje planificado de disponibilidad]
[Costo estimado / unidad de tiempo]
2.2 Actividades [Descripción resumida explicando cómo se trabajó la planificación de los costos según cada una de las actividades. En esta sección del documento debe realizarse el análisis de puntos de función, con el fin de calcular el costo para cada una de las actividades, posteriormente se recomienda anexar la línea base de costos y la tabla No. 16] 2.3 Costo Total [Se especifica cuál es el costo total estimado para el proyecto, este dato es extraído del análisis de puntos de función] Fecha de Revisión: [Fecha en que se revisa y aprueba el plan de gestión de costo] Comentarios adicionales: [Espacio disponible para comentarios de la persona asignada a revisar el documento] Director de Proyecto:
_______________________ [Nombre Completo]
Revisor:
_______________________ [Nombre Completo]
99
4.3.4 Plan de Gestión de Riesgos
La gestión de riesgos básicamente tiene como objetivo prevenir o enfrentar los
riesgos que tienen un impacto negativo y potenciar aquellos que puedan brindar
una ventaja o valor agregado al proyecto. En los proyectos informáticos es
fundamental tomar en cuenta todos los aspectos (internos y externos) que pueden
afectar positiva o negativamente la ejecución de los proyectos en una empresa.
Los riesgos a identificar dependen en gran medida de la realidad de cada
empresa, de cada nicho de mercado, aspectos de infraestructura y aspectos de
tecnología.
4.3.4.1 Identificación de Riesgos
La primera tarea para gestionar riesgos consiste en identificarlos mediante las
diferentes técnicas que existen, algunas de las cuales han sido expuestas en el
marco teórico de este documento, a continuación se propone una lista de riesgos
frecuentes en TI que puede funcionar como base o bien como ejemplo para
determinar los riesgos en proyectos de este tipo.
4.3.4.1.1 Herramienta: Riesgos Frecuentes en TI
Existen múltiples formas de clasificar los riesgos y esto una vez más depende de
la realidad de cada empresa, pero para propósitos de esta metodología se
propone una clasificación que puede ser adaptada según sea el caso, algunos de
los riesgos listados funcionan para cualquier tipo de proyecto y otros son
específicos para desarrollo de software.
Proyecto
���� Falta de cohesión entre las partes del proyecto, personas, grupos,
departamentos o clientes.
���� Poco apoyo por parte de la alta gerencia.
100
���� Falta de personal adecuado.
���� Obtención de requerimientos mal planteada o poco detallada.
���� Mala planificación de alcance del proyecto.
���� Rotación del equipo de trabajo.
���� Poca claridad en la definición de roles y responsabilidades.
���� Comunicación y coordinación débil entre los involucrados del proyecto.
Empresa
���� Falta de definición de estándares, procedimientos y políticas adecuados
para la ejecución de proyectos.
���� Hostilidad por parte de la alta gerencia para la administración de proyectos.
���� Inexistencia de políticas para la administración de la configuración.
���� Poca claridad para evaluar y determinar la calidad de los productos.
Tecnológicos
���� Problemas de soporte con la plataforma utilizada.
���� Aumento inesperado en los costos del hardware o software necesario.
���� Definición de requerimientos de hardware poco realista con respecto a la
plataforma elegida, carga de datos o trabajo necesarios.
���� Personal no capacitado para la implementación en la tecnología que
corresponda.
���� Mal manejo con respecto al tema de seguridad del software.
Externos
���� Riesgos relacionados con contrataciones de outsourcing en caso de que
aplique.
���� Aspectos financieros, con respecto a tasas de interés, cambio de monedas,
inflación entre otros.
���� Cambio constante en el negocio o mercado.
101
4.3.4.1.2 Registro de Riesgos
Este documento contiene información detallada de los riesgos identificados para
llevar un control preventivo que permita monitorear los riesgos y poder evitarlos o
bien determinar cómo se debe proceder en caso de que se presenten, es por esto
que se vuelve necesario contar con un documento que contenga información
oportuna. La siguiente tabla presenta una plantilla que facilita este proceso. se
recomienda completarla para todos los riesgos identificados, pero en general se
puede utilizar solo para los que tengan un mayor impacto en el proyecto o bien
una mayor probabilidad de ocurrencia.
Tabla 18: Plantilla - Registro de riesgos
Detalles del Proyecto©
Nombre del Proyecto: [Nombre]
Director del Proyecto: [Gerente de proyecto]
Detalles del Riesgo
Identificador: [Identificador definido anteriormente para cada riesgo]
Actividades del WBS:
[Lista de actividades que tienen este riesgo asociado]
Descripción del Riesgo:
[Descripción de cuál es el riesgo]
Probabilidad de Ocurrencia:
[Muy Baja / Baja / Media / Alta / Muy Alta]
Nivel de Impacto:
[Muy Baja / Baja / Media / Alta / Muy Alta]
Descripción del Impacto:
[A grandes rasgos qué va a impactar este riesgo]
Mitigación del Riesgo
Acciones Preventivas
[Se definen las acciones que se consideran necesarias para que este riesgo no se dé] Acciones de Contingencia
[En caso de que el riesgo se dé, qué acciones se deben realizar para mitigarlo]
Detalles de Aprobación©
102
Documentación de Soporte:
[Comentarios adicionales de la aprobación de este riesgo] Firma: Fecha: __/__/____ Nombre del Responsable
4.3.4.2 Análisis Cualitativo de riesgos
Para priorizar los riesgos definidos es necesario poner en práctica las técnicas
mencionadas en el marco teórico para desarrollar la matriz de probabilidad e
impacto que se presenta en la tabla No. 19, ésta se presenta utilizando una
medición por medio de estados (Muy alto, Alto, Medio, Bajo, Muy bajo), pero
también es posible realizarlo por medio de un análisis numérico si así se desea.
Tabla 19: Plantilla - Matriz de probabilidad e impacto
Matriz de Probabilidad e Impacto
Id Descripción del riesgo Descripción del impacto
Nivel de probabilidad
Nivel de impacto
[#] [Riesgo definido]
[¿Cómo podría impactar este riesgo en caso de darse? ¿En qué áreas y en qué fase?]
[Muy Alta / Alta / Media / Baja / Muy Baja]
[Muy Alta / Alta / Media / Baja / Muy Baja]
Posteriormente se continúa con el proceso completando la siguiente matriz (tabla
No. 20), que contiene información detallada de cada riesgo, incluyendo la prioridad
definida anteriormente, en este caso se presenta organizada por fase de proyecto.
Tabla 20: Plantilla - Análisis cualitativo de riesgos
Identificación y Análisis Cualitativo de Riesgos
Id Descripción de riesgo
Descripción del impacto Prioridad
Respuesta al Riesgo
Acciones de Contingencia
[# de Fase] [Nombre de la Fase del Proyecto]
[# de Riesgo] [Riesgo definido]
[¿Cómo impactaría este riesgo? ¿En qué áreas y en qué fase?]
[Alta / Media / Baja]
[¿Cómo se pretende prevenir el riesgo? ¿Qué acciones deben tomarse?]
[¿Qué se debe hacer para contrarrestar el riesgo en caso de que se dé?]
103
Finalmente, es recomendable establecer los responsables para cada uno de los
riesgos, es posible agregar una columna más a la tabla anterior, pero si se desea
manejar un detalle de los roles de las personas por riesgo se propone desarrollar
una matriz como la tabla No. 21 la cual presenta los responsables y su papel en
cada uno de los riesgos definidos, los roles propuestos para poder completar esta
matriz se detallan en la tabla No. 22:
Tabla 21: Plantilla - Matriz de responsabilidad de riesgos
Matriz de Responsabilidad de Riesgos
Id Director de Proyecto
Participante 1
Participante 2
Participante 3
[# de riesgo]
[Rol: F / R / C / I]
[Rol: F / R / C / I]
[Rol: F / R / C / I]
[Rol: F / R / C / I]
Tabla 22: Roles de responsabilidad
Roles Responsable Final (F)
Responsable final por el cumplimiento de la tarea o acción de respuesta al riesgo.
Responsable (R)
Responsable de una acción de apoyo necesaria para el cumplimiento de la tarea o acción de respuesta al riesgo.
Consultor (C) Participante que puede ser consultado y provee información útil y necesaria para el desarrollo de la tarea y de la acción de respuesta al riesgo.
Informante (I) Participante que será informado del desarrollo de la tarea o acción de respuesta al riesgo.
4.3.4.3 Análisis Cuantitativo
Esta puede ser una de las tareas más complicadas a la hora de gestionar un
proyecto, pero para este tipo de análisis lo más recomendable es apoyarse en
herramientas de software disponibles en el mercado, ya que realizar este análisis
manualmente puede ser tedioso y consumir mucho tiempo, se recomienda el uso
de herramientas automatizadas y especializas como lo es el @RISK2.
2 Herramienta que administra los riesgos de un proyecto por medio de simulaciones y funciones de probabilidad, fue creada por la compañía Palisade®.
104
4.3.4.4 Plan de Contingencia
De acuerdo a lo expuesto en la sección 2.3.4.5.4 de “Planificación de Respuesta a
los Riesgos” se debe elegir una política o estrategia para cada uno de los riesgos
identificados, en la siguiente tabla se muestra la plantilla para documentar y
gestionar lo que acá denominaremos el plan de contingencia.
Tabla 23: Plantilla - Plan de contingencia
4.3.4.5 Plan de Gestión de Riesgos
A continuación se presenta la plantilla para el desarrollo de este documento, el
cual a grandes rasgos unifica lo que se desarrolló en los apartados anteriores.
Tabla 24: Plantilla - Plan de gestión de riesgos
Plan de Gestión de Riesgos Versión: # Proyecto: [Nombre del Proyecto] Fecha: Doc. Nº #
Plan de Gestión de Riesgos
1. Presentación [Breve introducción del proyecto para ubicar al lector con respecto a lo que se tratará en este documento, haciendo referencia o bien, anexando documentos generados previos a este que facilitarán o son indispensables para el entendimiento de este plan] 2. Descripción del Proyecto [Se describe el propósito y objetivo del proyecto a manera resumida, la estrategia de ejecución del mismo y se debe hacer mención tanto al cronograma como a la organización del proyecto] 3. Metodología [¿Cómo se va a realizar el análisis de riesgos para el proyecto? ¿Qué técnicas y herramientas se van a emplear?] 4. Roles y Responsabilidades [Roles y responsabilidades de los involucrados, en especial definir quiénes intervienen y de qué
105
manera en la gestión de riesgos] 5. Presupuesto [En caso de que haya un presupuesto asignado específicamente a esta tarea, debe indicarse cómo se van a asignar los recursos y a estimar los costos] 6. Periodicidad [Se define la frecuencia de la gestión de riesgos, este ítem es particularmente importante para el seguimiento que posteriormente se realizará] 7. Categorías de Riesgos [Riesgos identificados agrupados por las diferentes categorías que se determinaron más adecuadas para el proyecto] 8. Análisis Cualitativo de Riesgos [Explicación breve de cómo se realizará este análisis] 8.1 Matriz de Probabilidad e Impacto [Priorización de los riesgos según lo que se define en la sección 2.3.4.5.2 de este documento, incluir la plantilla No. 19] 8.2 Análisis Cualitativo [Continuación del análisis cualitativo, debe incluirse la tabla No. 20] 8.3 Matriz de Roles y Responsables [Roles y responsables de cada riesgo analizado, se incluyen las tablas No. 21 y 22] 9. Análisis Cuantitativo de Riesgos [Explicación resumida de la metodología utilizada, datos como el tipo de distribución probabilística, herramienta automatizada y diagramas o gráficos para analizar] 8.1 Análisis de Resultados [De acuerdo a las salidas resultantes del análisis se debe determinar qué medidas son recomendables para adecuar el proyecto en caso de que así se haya determinado o bien a cuáles riesgos se les debe dar más seguimiento para asegurar el éxito del mismo] Fecha de Revisión: [Fecha en que se revisa y aprueba el plan de gestión de riesgos] Comentarios adicionales: [Espacio disponible para comentarios de la persona asignada a revisar el documento] Director de Proyecto:
_______________________ [Nombre Completo]
Revisor:
_______________________ [Nombre Completo]
106
4.4 Ejecución
Esta etapa consiste en desarrollar y gestionar lo que se estipuló en los diferentes
planes de gestión, a continuación se explicará brevemente cuáles herramientas se
utilizarán para llevar a cabo este proceso.
4.4.1 Dirección y Gestión
La dirección y gestión del proyecto consiste en seguir una metodología de gestión
de proyectos y generalmente se facilita por el uso de sistemas automatizados de
gestión de proyectos.
4.4.2 Herramientas
Para determinar las herramientas que se utilizarán en este proceso se presenta la
siguiente tabla, propuesta por Yamal Chamoun, para esta metodología solo se
hace referencia a las herramientas que aplican según los objetivos.
Tabla 25: Herramientas del plan del proyecto que apoyan la ejecución (Chamoun, 2002)
Área Herramienta ¿Cómo nos servirá durante la ejecución?
Alc
ance
WBS
- Para identificar todo el trabajo por ejecutar. - Al momento de ejecutar, seguiremos esta estructura para confirmar el Alcance realizado. - En caso de ajustes al Alcance, éstos deberán ser registrados para actualizar el WBS.
Tie
mp
o
Programa del Proyecto
- Nos permitirá saber cuándo iniciar y terminar cada uno de los entregables, así como las tareas requeridas para terminar el proyecto a tiempo. - Asimismo, nos servirá como referencia antes de contratar los trabajos y durante la ejecución de éstos.
Co
sto
Presupuesto Base
- Para conocer el monto presupuestal asignado a cada entregable, y asegurar antes de contratar, el apego al presupuesto. - Una vez contratados, nos permitirá monitorear el desempeño del proyecto en función de los costos.
107
Rie
sgo
s
Matriz de Administración de Riesgos
- Para confirmar los riesgos previstos y dar seguimiento a las acciones establecidas en esta matriz. - Asimismo, nos servirá como herramienta para identificar, cuantificar y responder periódicamente a las situaciones de riesgo que detectemos a lo largo del proyecto.
Las siguientes plantillas pueden ser clave para la documentación que se realiza en
la ejecución del proyecto.
4.4.2.1 Minuta
La minuta es un documento que se genera cada vez que se realiza una reunión,
es necesario mantener un historial de las reuniones que se hacen, los acuerdos
que se toman y las personas que asisten para que sirva como respaldo del
proyecto, por ejemplo para justificar variaciones en alcance, tiempo, costo o bien
aspectos relacionados a la distribución de responsabilidad o de tareas.
La siguiente tabla muestra una propuesta de plantilla que puede ser simplificada o
complementada con otros datos que sean relevantes.
Tabla 26: Plantilla - Minuta
Minuta No. # Versión: # Proyecto: [Nombre del Proyecto] Fecha:
Inicio Fin Elaborado por Ubicación hh:mm hh:mm [¿Quién elabora el documento?] [Lugar donde se llevo a cabo] Objetivo [Objetivo de la reunión]
Asistente Puesto Departamento [Nombre] [Puesto] [Depto. que representa] Temas desarrollados [Temas que se trataron en la reunión, si es relevante se puede indicar quién trató cada tema] Acuerdos definidos [Si se llegaron a acuerdos con respecto a fechas o entregas, se debe indicar en esta sección]
108
4.4.2.2 Lecciones Aprendidas
Las lecciones aprendidas deben documentarse en la medida en que van
surgiendo durante el ciclo de vida del proyecto, pero particularmente en la
ejecución ya que estos serán los insumos para la empresa en proyectos futuros.
La siguiente plantilla pretende documentar este tipo de activos de proceso de una
manera sencilla y ordenada.
Tabla 27: Plantilla - Lecciones aprendidas
Lecciones Aprendidas No. # Versión: # Proyecto: [Nombre del Proyecto] Fecha:
Fecha No. WBS Elaborado por Etapa [de incidente]
[#] [Quien elabora el documento] [Inicio, Planificación, Ejecución, Seguimiento, Cierre]
Problemática [¿Cuál fue el objetivo, razón o situación que dio pie a la lección aprendida?] Solución Aplicada [¿Cuál fue la solución que se aplicó para solventar el problema? Descripción breve de la situación después de aplicada la solución] Recomendaciones [Luego de aplicada la solución y en un análisis posterior, cuáles recomendaciones podrían darse si el problema se presentara en proyectos similares]
4.5 Seguimiento y Control
4.5.1 Control Integrado de Cambios
4.5.1.1 Plantilla para solicitud de cambios
Es vital mantener un control detallado de los cambios o modificaciones que se
hacen en el proyecto, para documentar y respaldar esta información, se presenta
la siguiente plantilla que contiene la información más relevante.
109
Tabla 28: Plantilla - Solicitud de cambio
[Nombre de la Empresa]
Proyecto: [Nombre del Proyecto] Solicitud de Cambio Versión de documento: #
Proyecto
No. Solicitud: [Consecutivo] Estado: [Estado del cambio] Fecha: [Fecha de Solicitud] Dirigida a: [Revisor de la solicitud] Solicitante: [Nombre de Solicitante] Tipo: [Tipo de cambio a realizar]
Detalle
Cambio: [Nombre del cambio solicitado] Descripción Detallada:
[Explicación breve del cambio]
Impacto en el Proyecto
Justificación: [¿Por qué debe realizarse el cambio?]
Impacto: [¿Qué impacto tendrá a nivel de costo, tiempo o alcance?]
Nueva fecha finalización: [¿En qué fecha se presume terminará el cambio?]
Importe Neto: [¿Qué impacto monetario tendrá este cambio?]
Gerente Cliente Nombre del Gerente Nombre del Cliente
110
4.5.1.2 Plantillas para Informe de Avance
Es de suma importancia realizar un seguimiento acertado del proyecto para medir
la situación en un momento dado con respecto a lo planificado, así se facilitará la
toma de decisiones, la siguiente plantilla permite llevar un control de este tipo y se
recomienda su uso mensual.
Tabla 29: Plantilla - Informe de avance
Informe de Avance Versión: # Proyecto: [Nombre del Proyecto] Fecha: Doc. Nº #
Información General
Nombre del Proyecto: [Nombre] Director del Proyecto: [Gerente de proyecto]
Fecha de Inicio: [Fecha en que inició]
Fecha Finalización: [Fecha estimada de
término] Estado General del Proyecto: [Atrasado / A Tiempo] Observaciones Generales [Notas generales que se deseen incluir]
Cronograma
Planificado Situación Real % Avance: [% esperado de avance] Actividades: [Identificadores de las actividades que deberían estarse realizando]
% Avance: [% real de avance] Actividades: [Identificadores de las actividades que se están realizando] Fecha estimada de término: [Según la situación actual ]
Observaciones: [Comentarios adicionales que sea pertinente destacar, en caso de atrasos justificados con respecto al cronograma o debido a solicitudes de cambio debe hacerse referencia a la documentación que corresponda]
Presupuesto
Planificado Situación Real % de presupuesto gastado: [% de gasto esperado del presupuesto] Presupuesto estimado: [Monto de presupuesto estimado]
% de presupuesto gastado: [% real gastado del presupuesto] Presupuesto estimado: [Monto de presupuesto estimado según la situación real]
Observaciones: [Notas importantes de apoyo para justificar cualquier anomalía que se haya presentado]
111
Alcance
Observaciones: [Agregar comentarios acerca de cualquier cambio que se haya realizado con respecto a los objetivos planteados inicialmente o cualquier elemento del alcance haciendo referencia a la documentación respectiva, en caso de ser necesario agregar información comparativa sobre los objetivos iniciales y reales con el fin de clarificar el estado de la situación]
Aprobación
Fecha de Revisión: [Fecha en que se revisa y aprueba el informe] Comentarios adicionales: [Espacio disponible para comentarios de la persona asignada a revisar el estado del proyecto] Director de Proyecto:
_______________________ [Nombre Completo]
Revisor:
_______________________ [Nombre Completo]
4.5.2 Verificación de Alcance
Se recomienda realizar revisiones de verificación del alcance cada vez que hay un
entregable pronto a culminar, de manera que se vayan monitoreando y de una vez
sean aceptados o rechazados los comentarios justificando la situación o bien
indicando una oportunidad de mejora, para llevar este registro se recomienda la
siguiente tabla.
Tabla 30: Plantilla - Registro de aceptación de entregables
Registro de aceptación de entregables
Id Nombre Fecha Estado Justificación Revisor [#] [Nombre Entregable] [Fecha
de Revisión]
[Aceptado / Rechazado]
[Justificación si fue rechazado, o bien oportunidades de mejora encontradas]
[Quién realiza la revisión]
112
4.5.3 Valor Ganado
El valor ganado es posiblemente una de las herramientas más importantes para el
seguimiento de presupuesto y cronograma de un proyecto ya que permite realizar
correcciones oportunas para que el trabajo se pueda realizar exitosamente y bajo
las condiciones planificadas.
Siguiendo la teoría expuesta en el marco teórico, se desarrollan las siguientes
plantillas para documentar los cálculos y documentación de este proceso.
Tabla 31: Plantilla - Costo Total Planificado (CPA)
Costo Presupuestado por Fase
Fases CTP Semanas
1 2 3 4 …
[Fase 1] ∑ # # # # #
[Fase 2] ∑ # # # # #
… ∑ # # # # #
Total ∑ ∑ ∑ ∑ ∑ ∑
Acumulado ∑ ∑ ∑ ∑ ∑
Tabla 32: Plantilla - Costo Real Acumulado (CRA)
Costo Real por Fase
Fases Semanas Total
Gastado 1 2 3 4 …
[Fase 1] # # # # # ∑
[Fase 2] # # # # # ∑
… # # # # # ∑
Total ∑ ∑ ∑ ∑ ∑ ∑
Acumulado ∑ ∑ ∑ ∑ ∑ ∑
En la siguiente tabla se presenta la plantilla que contiene los datos más
importantes obtenidos del análisis anterior, este tipo de cuadro se puede incluir en
los reportes periódicos que se hacen o bien solo mantenerlos a nivel de director de
proyecto para facilitar la toma de decisiones.
113
Tabla 33: Plantilla - Cuadro resumen de valor ganado
Cuadro Resumen de Valor Ganado
Proyecto: [Nombre del Proyecto] Semana [# semana] de [total] Planificado Cálculos
[Lista de Actividades que deberían estarse realizando en la semana de análisis, con un indicador del % de
avance planificado]
CPA = (Costo Presupuestado Acumulado)
CRA = (Costo Real Acumulado)
VDA = (Valor Devengado Acumulado)
Real Diagrama
[Lista de Actividades que se están realizando, con un indicador del % de
avance tiene actualmente]
[Se recomienda el uso de diagramas lineales indicando los valores de
CPA, CRA y VDA para visualizar el estado actual del proyecto]
4.5.4 Reportes de Seguimiento y Control
En este apartado se presentan diferentes plantillas para la documentación del
seguimiento y control.
4.5.4.1 Reportes Mensuales
Estos se plantean a manera de resumen sobre la situación actual del proyecto con
información muy puntual acerca del rendimiento y ejecución, éstos pueden ser
adecuados para presentar a la alta gerencia.
Tabla 34: Plantilla - Informe de seguimiento mensual
[Nombre del Proyecto] Informe Mensual No. # [Fecha]
Información General
Avance [Descripción de avance general del proyecto a la fecha con respecto a lo planificado]
Desviaciones [Cuáles han sido las deviaciones que ha sufrido el proyecto con respecto a lo planificado, puntos concretos que se han visto afectados]
114
Estado General [Resumen de la ejecución del proyecto, cómo se ha visto el avance y cómo se ha realizado] Recomendaciones
Acciones Correctivas [Listado de Acciones Correctivas que se pueden implementar]
Prioridades [Prioridades para el proyecto a la fecha, cuáles son las tareas más críticas que faltan por realizar]
Oportunidades y Amenazas [Listado de oportunidades y amenazas que se presentaron, para potenciar oportunidades y minimizar amenazas]
Estado de la Situación
Diagrama de Tiempo Diagrama de Valor Ganado [Insertar diagrama con la Situación Planificada vs. la Situación Real]
[Insertar diagrama resultante del análisis de Valor Ganado]
Diagrama de Avance Diagrama de Presupuesto [Diagrama del avance que se tiene con
respecto al que se planificó] [Insertar diagrama del Presupuesto Planificado vs. Presupuesto Real]
4.5.4.2 Reportes Semanales
En el caso de los reportes semanales, éstos se deben realizar con información un
poco más detallada y concisa, de manera que faciliten la toma de decisiones para
el equipo de proyecto.
Tabla 35: Plantilla - Informe de seguimiento semanal
[Nombre del Proyecto] Informe Semanal [Fecha]
[Insertar Diagrama de Gantt actualizado a la fecha, solo el segmento de las actividades que corresponden a la semana en cuestión]
[Lista de Actividades por realizar en la semana analizada y responsable de cada una de ellas] Datos Generales
115
[Descripción general de las tareas que deben realizarse esta semana, especificando cuáles son las más críticas e indicando si en la semana anterior se produjo algún cambio importante o situación extraordinaria que causara alguna modificación en las actividades que ahora se van a desarrollar]
Riesgos [Descripción general de los riesgos esperados en esta semana y cuál es el estado global de los mismos]
ID Riesgo Fecha Impacto Estado Responsable Observaciones
[#] [Descripción] [Esperada] [Nivel de impacto]
[Activo / Inactivo]
[Persona Responsable]
[Observaciones del riesgo]
Alcance [Lista de Entregables que corresponden a esta semana]
ID Nombre Estado Entrega Prog. Entrega Real Responsable Aprobado
[#] [Descripción]
[Entregado / Trabajando / A Tiempo]
[Fecha de Entrega]
[Fecha Real de Entrega]
[Persona Responsable] [Sí / No]
Tiempo
WBS Fechas Programadas % de Avance Diferencia
ID Actividad Inicio Fin Programado Real
[#] [Descripción] [Fecha Inicio] [Fecha Fin] [% de avance esperado]
[% de avance real]
[Diferencia de avance]
Costo
Programado Real Extraordinario Aprobado
Total A la fecha Total A la fecha
[Presupuesto Total]
[Planificado para la fecha]
[Monto Total Real] [Fecha Fin]
[En caso de que aplique]
Valor Ganado [Insertar diagrama de valor ganado, puede ser el mismo indicado en la tabla No. 33] Lecciones Aprendidas [Documentar o bien hacer referencia a las lecciones aprendidas]
4.5.4.3 Scoreboard
El Scoreboard tiene como finalidad
principalmente de los roles y responsabilidades de los involucrados del proyecto,
incluyendo por supuesto a los stakeholders. Esta tabla
lugar visible, debe ser sencilla, concisa y llamativa
y monitoreado por todos los
Debe mostrar el seguimiento y estado del proyecto de
enfocado a las actividades que se están realizando
deben realizar en un periodo estipulado
próxima). Una característica
el responsable de cada actividad y su rol en la misma
el estado del proyecto, los roles y responsabilidades de los participantes
Es recomendable actualizar esta tabla
hacer bisemanalmente en caso de que no existan muchos cambios
Actividad Esperado
[Nombre de la actividad del periodo en cuestión]
[Avance planificado]
tiene como finalidad llevar un control macro
principalmente de los roles y responsabilidades de los involucrados del proyecto,
incluyendo por supuesto a los stakeholders. Esta tabla debe encontrarse en un
sencilla, concisa y llamativa, de manera que pueda ser visto
y monitoreado por todos los miembros del equipo.
mostrar el seguimiento y estado del proyecto de forma general
enfocado a las actividades que se están realizando actualmente
periodo estipulado (puede ser en la semana o quincena
característica muy importante de esta herramienta es que
el responsable de cada actividad y su rol en la misma, de manera que quede claro
el proyecto, los roles y responsabilidades de los participantes
Es recomendable actualizar esta tabla semanalmente, pero también se podría
en caso de que no existan muchos cambios
Tabla 36: Plantilla - Scoreboard
Scoreboard
% de Avance Equipo Responsable
DescripciónEsperado Real
[Avance planificado]
[Avance a la fecha]
[Nombre del equipo o del responsable de su cumplimiento]
[Descripción breve del rol y responsabilidad en esta tarea
Tabla 37: Simbología para Scoreboard
Simbología
A tiempo
Atrasada
Detenida o con errores
116
macro del proyecto,
principalmente de los roles y responsabilidades de los involucrados del proyecto,
debe encontrarse en un
, de manera que pueda ser visto
general y clara,
y a las que se
(puede ser en la semana o quincena
muy importante de esta herramienta es que muestra
, de manera que quede claro
el proyecto, los roles y responsabilidades de los participantes.
semanalmente, pero también se podría
en caso de que no existan muchos cambios.
Descripción Estado
[Descripción ve del rol y
responsabilidad en esta tarea]
117
4.5.4.4 Control de versiones de documentos
Para llevar a cabo una correcta gestión de la configuración dentro del proyecto se
recomienda mantener un historial de los cambios y de revisiones realizadas en los
distintos documentos. En general es importante mantener un orden y claridad en
la documentación que se desarrolla con el fin de facilitar la gestión, evitar
confusiones y que ésta sirva de herramienta de apoyo para proyectos posteriores,
a continuación se presenta un cuadro que resulta útil para esta tarea.
Tabla 38: Plantilla - Historial de versiones de los documentos
Histórico de versiones
No. Versión Fecha Descripción Revisado por
[Número de versión que se
está trabajando]
[Fecha en que se
generó la versión]
[Descripción del documento generado o de las modificaciones realizadas al documento original]
[Nombre de la persona encargada de la revisión]
118
4.6 Cierre
4.6.1.1 Documentación de Cierre
4.6.1.1.1 Reporte Final
Es un documento formal que contiene los datos más importantes a manera de
resumen sobre cómo terminó el proyecto, en la siguiente tabla se presenta la
plantilla propuesta para documentar este proceso.
Tabla 39: Plantilla - Reporte final
Informe Final Versión: # Proyecto: [Nombre del Proyecto] Fecha: Doc. Nº #
Información General
Nombre del Proyecto: [Nombre] Director del Proyecto: [Gerente de proyecto]
Fecha de Inicio: [Fecha de inicio]
Fecha de Fin: [Fecha de término]
Estado Final del Proyecto: [Exitoso / No Exitoso / Cancelado] Observaciones Generales [Notas generales que se deseen incluir]
Cronograma
Planificado Real [Descripción breve de lo que se planificó, se puede hacer referencia al cronograma o anexos relevantes]
[Descripción breve de la situación real en que terminó el proyecto]
Observaciones: [Comentarios relevantes acerca del resultado final con respecto a la parte de gestión del tiempo, justificando por qué no se logró lo planificado si ese fuera el caso]
Presupuesto
Planificado Real Presupuesto estimado: [Monto de presupuesto estimado]
Presupuesto gastado: [Monto de presupuesto gastado]
Observaciones: [Notas importantes acerca de la gestión de costos, incluyendo referencias a documentos externos o a cualquier información relevante, aquí se puede incluir la justificación
119
resumida en caso de que haya una discrepancia en los montos (tanto positiva como negativa)]
Alcance
Observaciones: [Comentarios relevantes con respecto a los objetivos planteados y a los logrados, si se alcanzaron todos los objetivos, si no, cuál fue la razón principal, además de aspectos generales de calidad de los productos entregables]
Lecciones Aprendidas
[Lecciones aprendidas más importantes del proyecto, cómo puede evitarse, gestionarse o solventarse la realización de ciertas las tareas o situaciones que se dieron en este proyecto, es básicamente mencionar qué fue lo que se aprendió en el proceso que puede servir para futuros proyectos]
Documentación
Archivos Participantes [Lista de archivos que se generaron durante la gestión de proyecto]
[Directorio de participantes del proyecto, esta sección puede servir para referencias futuras en proyectos similares]
Control de Cambios Base de datos de conocimiento [Resumen de cómo se elaboró el control de cambios, se pueden mencionar las solicitudes más importantes en caso de que aplique]
[Lista de archivos que se añadirán al repositorio o base de gestión de conocimiento en administración de proyectos de la empresa]
Aprobación
Fecha de Aprobación: [Fecha en que se revisa y aprueba el informe] Comentarios adicionales: [Espacio disponible para comentarios de la persona asignada a revisar el estado del proyecto] Director de Proyecto:
_______________________ [Nombre Completo]
Patrocinador o Cliente:
_______________________ [Nombre Completo]
4.7 Resumen General
El siguiente cuadro se genera a manera de
desarrollo del proyecto con la finalidad de aclarar y resumir l
y herramientas que componen la
orden que se muestra en el siguiente recuadro
realizar tanto los procesos
INICIO
Acta de constitución del proyecto (Charter)
Modulación del proceso
Mapa de expectativas
PLANIFICACIÓN Gestión de Alcance
Elección del ciclo de vida de software
Enunciado de alcance
Obtención de requerimientos
Modelado de base de datos
Estructura Detallada de Trabajo
esumen General
El siguiente cuadro se genera a manera de síntesis para enlistar lo expuesto en el
con la finalidad de aclarar y resumir los procesos, técnicas
y herramientas que componen la metodología. Es importante mencionar
orden que se muestra en el siguiente recuadro, es el orden en que se
tanto los procesos ( ) como las plantillas ( ).
Acta de constitución del Iniciativa formal del proyecto que autoriza su realización, es el primer documento que debe generarse con la información relevante para dar inicio al proyecto.
Modulación del proceso
Corresponde a definir del flujo de responsabilidades y tareas que deben realizarse para lodocumentos que tienen mayor impacto o incidencia a lo largo del proyecto. Por ejemplo las solicitudes de cambio o actualizaciones a planes de gestión.
Mapa de expectativas Listado de los involucrados en el proyecto con información general, rol, responsabilidades y expectativas del proyecto.
Elección del ciclo de La finalidad de elegir un ciclo de vida para el software adesarrollar es definir cómo se va a realizar la implementación, esto es importante para la definición de actividades, estimación de tiempo y costo.
Enunciado de alcance Documento con el cual se iniciará el proceso de definición detallada del proyecto, utiliza como insumo el Acta de Constitución. Se refiere al modelado de casos de uso para el análisis de requerimientos, por medio de la teoría expuesta en el marco teórico. Este análisis es base para definir la EDT y posteriormente alimentará la planificación de tiempo y costo.
Modelado de base de
Técnica de diagramas entidad-relación para definir la estructura de la base de datos que se debe implementar, esto con el fin de definir el nivel de complejidad de se desea desarrollar, información vital para la definición de actividades, cronograma y costo.
Estructura Detallada de Estructura jerárquica de las actividades que deben llevarse a cabo para lograr los objetivos del proyecto, orientada a los entregables que deben ser generados en el proyecto. Básicamente define y agrupa el trabajo a
120
para enlistar lo expuesto en el
procesos, técnicas
mencionar que el
es el orden en que se deben
Iniciativa formal del proyecto que autoriza su realización, es el primer documento que debe generarse con la información relevante para dar inicio al proyecto.
del flujo de responsabilidades y los procesos y
documentos que tienen mayor impacto o incidencia a lo Por ejemplo las solicitudes de cambio
Listado de los involucrados en el proyecto con información general, rol, responsabilidades y expectativas
La finalidad de elegir un ciclo de vida para el software a desarrollar es definir cómo se va a realizar la implementación, esto es importante para la definición de actividades, estimación de tiempo y costo. Documento con el cual se iniciará el proceso de definición
utiliza como insumo el Acta de
Se refiere al modelado de casos de uso para el análisis de requerimientos, por medio de la teoría expuesta en el marco teórico. Este análisis es base para definir la EDT y posteriormente alimentará la planificación de tiempo y
relación para definir la estructura de la base de datos que se debe implementar, esto con el fin de definir el nivel de complejidad de lo que se desea desarrollar, información vital para la definición
Estructura jerárquica de las actividades que deben llevarse a cabo para lograr los objetivos del proyecto, orientada a los entregables que deben ser generados en el proyecto. Básicamente define y agrupa el trabajo a
Plan de Gestión de Alcance
Gestión de Tiempo
Definición de actividades
Secuenciación de actividades
Asignación de recursos
Estimación de tiempo
Desarrollo del cronograma
Plan de Gestión de Tiempo
Gestión de Costo
Estimación de costo
Presupuesto por fase
Plan de Gestión de Costo
Gestión de Riesgos
Identificación de Riesgos
realizarse en tareas concretas que se pucontrolar. Este documento integra la información más importante acerca de lo que debe realizarse en el proyecto. Datos como objetivos, características, organización del equipo, límites, entregables, criterios de aceptación del proyecto, también incluye algunos aspectos breves de presupuesto, riesgos y seguimiento.
Consiste en determinar las tareas concretas que deben realizarse para realizar el proyecto partiendo de definida previamente en la gestión de alcance.Este es el proceso de organizar lógicamente las actividades previamente definidas, tomando en cuenta relaciones de dependencia, restricciones temporales o requisitos de realización.
Asignación de recursos Estimación y asignación de los recursos necesarios para realizar cada una de las actividades definidas, tanto en términos de cantidad como de tipo de recurso.
Estimación de tiempo
Se propone el análisis mediante puntos de función, que permite medir la complejidad del sistema a desarrollar, este análisis da como resultado actividades concretas y una duración estimada para cada una de ellas.Proceso que generalmente se realiza en un automatizado de gestión de proyectos, consiste ensamblar los análisis previos. Organizando las actividades de acuerdo a la secuencia definida, tomando en cuenta restricciones, recursos, duración, fechas de inicio y finalización. Documento que encapsula los análisis realizados en las etapas previas de gestión de tiempo, incluye la EDT, análisis de actividades, cronograma, entre otros.
De acuerdo a la metodología y al marco teórico el análisis de puntos de función. En seguimiento al análisis realizado en la gestión de tiempo, se estima un costo para cada actividad definida.
Presupuesto por fase
Este documento resume la estimación de costos de acuerdo a lo planificado por fase, nace para facilitar el seguimiento y control de presupuesto que posteriormente debe realizarse. Se integran en este documento los resultados de los análisis anteriormente mencionados e incluye la estimación de costos realizada.
Tarea que consiste en documentar y categorizar los aspectos que puedan tener algún impacto en el proyecto
121
realizarse en tareas concretas que se pueden medir y
Este documento integra la información más importante acerca de lo que debe realizarse en el proyecto. Datos como objetivos, características, organización del equipo,
aceptación del proyecto, también incluye algunos aspectos breves de presupuesto,
Consiste en determinar las tareas concretas que deben realizarse para realizar el proyecto partiendo de la EDT definida previamente en la gestión de alcance. Este es el proceso de organizar lógicamente las actividades previamente definidas, tomando en cuenta relaciones de dependencia, restricciones temporales o
Estimación y asignación de los recursos necesarios para realizar cada una de las actividades definidas, tanto en términos de cantidad como de tipo de recurso.
puntos de función, que permite medir la complejidad del sistema a desarrollar, este análisis da como resultado actividades concretas y una duración estimada para cada una de ellas. Proceso que generalmente se realiza en un sistema automatizado de gestión de proyectos, consiste ensamblar los análisis previos. Organizando las actividades de acuerdo a la secuencia definida, tomando en cuenta restricciones, recursos, duración, fechas de
Documento que encapsula los análisis realizados en las etapas previas de gestión de tiempo, incluye la EDT, análisis de actividades, cronograma, entre otros.
De acuerdo a la metodología y al marco teórico se utiliza el análisis de puntos de función. En seguimiento al análisis realizado en la gestión de tiempo, se estima un
Este documento resume la estimación de costos de r fase, nace para facilitar el
seguimiento y control de presupuesto que posteriormente
documento los resultados de los análisis anteriormente mencionados e incluye la
Tarea que consiste en documentar y categorizar los aspectos que puedan tener algún impacto en el proyecto
Análisis Cualitativo de riesgos
Análisis Cuantitativo riesgos
Plan de Contingencia
Plan de Gestión de Riesgos
EJECUCIÓN
Dirección y Gestión
Minuta
Lecciones Aprendidas
SEGUIMIENTO Y CONTROL
Control integrado de cambios
Verificación de alcance
(positivo o negativo). Se incluye la plantilla de registro de riesgos, la cual debe utilizarse para detallar cada uno de los riesgos identificados o por lo menos los que resulten más importantes.
de
Proceso de priorizar los riesgos definidos en la etapa anterior, tomando en cuenta la probabilidad de y su posible impacto, en esta sección se incluyen las siguientes plantillas: (i) Matriz de probabilidad e impacto, (ii) Análisis cualitativo de riesgos, (iii) Matriz de responsabilidad de riesgos y (iv) Roles de responsabilidad.
de Corresponde al análisis numérico de riesgos para determinar el efecto que podrían tener en el proyecto, generalmente se realiza mediante simulaciones por medio de sistemas automatizados para este fin.
Plan de Contingencia
Documento que contiene la información general del riesgo, responsabilidad, prioridad, impacto, acciones preventivas, acciones de contingencia y estrategia a tomar (Evitar, Mitigar, Transferir, etc) Documenta el análisis que se lleva a cabo en los procesos anteriormente mencionados, incluyendo aspectos de metodología, roles y responsabilidades, categorías de riesgos, entre otros.
Se refiere a las acciones que debe realizar el director de proyecto y su equipo para ejecutar el plan de gestión de proyecto, definido en la etapa de Planificación. Generalmente se realiza por medio de sistemas automatizados de gestión de proyectos. Documento que debe generarse posterior a cada reunión que se realice, indicando participantes, temas tratados y acuerdos definidos.
Lecciones Aprendidas Plantilla para la documentación de las lecciones aprendidas, se debe utilizar a lo largo de todo el proyecto, pero es de vital importancia en la ejecución
SEGUIMIENTO Y CONTROL
Control integrado de
Incluye las plantillas de (i) Solicitud de cambio: que permite documentar y respaldar los cambios que se realizan en el proyecto; (ii) Informe de Avance: reporte acerca del avance que tiene el proyecto en un momento dado, estos deben generarse cuando se considere pertinente.
Verificación de alcance Se propone la plantilla de registro de aceptación de entregables que contiene la lista de entregables definida en la etapa de planificación. Esta se complementa con
122
(positivo o negativo). Se incluye la plantilla de registro de utilizarse para detallar cada uno de
los riesgos identificados o por lo menos los que resulten
Proceso de priorizar los riesgos definidos en la etapa anterior, tomando en cuenta la probabilidad de ocurrencia y su posible impacto, en esta sección se incluyen las siguientes plantillas: (i) Matriz de probabilidad e impacto, (ii) Análisis cualitativo de riesgos, (iii) Matriz de responsabilidad de riesgos y (iv) Roles de
Corresponde al análisis numérico de riesgos para determinar el efecto que podrían tener en el proyecto, generalmente se realiza mediante simulaciones por medio de sistemas automatizados para este fin. Documento que contiene la información general del riesgo, responsabilidad, prioridad, impacto, acciones preventivas, acciones de contingencia y estrategia a
lleva a cabo en los procesos anteriormente mencionados, incluyendo aspectos de metodología, roles y responsabilidades,
Se refiere a las acciones que debe realizar el director de proyecto y su equipo para ejecutar el plan de gestión de proyecto, definido en la etapa de Planificación. Generalmente se realiza por medio de sistemas
Documento que debe generarse posterior a cada reunión
ue se realice, indicando participantes, temas tratados y
Plantilla para la documentación de las lecciones aprendidas, se debe utilizar a lo largo de todo el proyecto, pero es de vital importancia en la ejecución del mismo.
Incluye las plantillas de (i) Solicitud de cambio: que permite documentar y respaldar los cambios que se realizan en el proyecto; (ii) Informe de Avance: reporte
el proyecto en un momento dado, estos deben generarse cuando se considere
Se propone la plantilla de registro de aceptación de entregables que contiene la lista de entregables definida en la etapa de planificación. Esta se complementa con
Valor Ganado
Reporte mensual
Reporte semanal
Scoreboard
Control de versionesdocumentos
CIERRE
Reporte final
información de las revisiones, la fecha, el estado, la justificación y el responsable de su aprobación.Herramienta que permite medir el estado de un proyecto en un momento dado y comparar los datos con lo planificado a ese mismo momento (en términos de alcance, tiempo y costo). Esto para controlar que el proyecto vaya de acuerdo a lo esperado y de no ser así, aplicar medidas correctivas oportunas. Esta sección incluye plantillas propias de este análisis, entre las que se encuentran: (i) Costo total planificado (CPA), (ii) Costo real acumulado (CRA)resumen de valor ganado Informe orientado a la alta gerencia con datos acerca del estado del proyecto a grandes rasgos, se recomienda el uso de gráficos y diagramas para denotar el grado de avance. Informe orientado al equipo del proyecto, contiene información detallada y concisa acerca del estado del proyecto, incluye datos de análisis de valor ganado para la toma de decisiones. Tabla con información resumida acerca del estado del proyecto, se enfoca en mostrar la situación actual y las tareas prontas a realizarse. Esta tabla incluye las actividades, porcentajes de avance, estado con respecto a lo planificado y responsables, la idea es que esta permanezca visible para el equipo de proyecto.
versiones de Esta plantilla permite documentar los cambios y versiones que se realizan en cada uno de los documentos oficiales.
Documento que formaliza la culminación del proyecto, independientemente de si el resultado fue este documento viene a resumir y dar por terminado el proyecto, debe ser aprobado por el gerente de proyecto y el patrocinador.
123
información de las revisiones, la fecha, el estado, la aprobación.
Herramienta que permite medir el estado de un proyecto en un momento dado y comparar los datos con lo planificado a ese mismo momento (en términos de alcance, tiempo y costo). Esto para controlar que el
a lo esperado y de no ser así,
Esta sección incluye plantillas propias de este análisis, Costo total planificado
Costo real acumulado (CRA), (iii) Cuadro
Informe orientado a la alta gerencia con datos acerca del estado del proyecto a grandes rasgos, se recomienda el uso de gráficos y diagramas para denotar el grado de
proyecto, contiene información detallada y concisa acerca del estado del proyecto, incluye datos de análisis de valor ganado para
Tabla con información resumida acerca del estado del situación actual y las
tareas prontas a realizarse. Esta tabla incluye las actividades, porcentajes de avance, estado con respecto a lo planificado y responsables, la idea es que esta permanezca visible para el equipo de proyecto. Esta plantilla permite documentar los cambios y versiones que se realizan en cada uno de los documentos oficiales.
Documento que formaliza la culminación del proyecto, independientemente de si el resultado fue exitoso o no, este documento viene a resumir y dar por terminado el proyecto, debe ser aprobado por el gerente de proyecto y
124
4.8 Caso Práctico
Esta sección del documento nace con el fin de aclarar un poco la utilidad de la
metodología desarrollada, se presenta parte del proceso y algunas de las plantillas
con un ejemplo práctico para clarificar el uso de las mismas.
El ejemplo que se plantea es un caso sencillo de la implementación de un sistema
compuesto por una única pantalla de mantenimiento con acceso a base de datos,
vamos a asumir que la base de datos es de Empleados y la pantalla es para el
mantenimiento de estos datos.
4.8.1 Inicio
De esta fase inicial se presenta el ejemplo del Charter o Acta de Constitución, en
cuyo caso quedaría de la siguiente manera:
Tabla 40: Ejemplo: Charter
Acta de Constitución
Información General
Fecha
1 Junio, 2009
Nombre del Proyecto
Implementación del Sistema de Empleados
Áreas de conocimiento / procesos
� Tiempo, Costo, Alcance, Riesgos. � Planificación, Seguimiento y control
Área de aplicación (sector / actividad)
División de Recursos Humanos
Fecha de Inicio
22 Junio, 2009
Fecha tentativa de Finalización
30 Julio, 2009
Objetivos del Proyecto
General
Implementar un sistema de empleados para facilitar el mantenimiento de la información.
Descripción del Producto
Entregables Finales
Versión inicial del Sistema de Empleados. Documentación generada de la gestión del proyecto.
Información del Proyecto
125
Necesidad del Proyecto
La información actualmente se gestiona de forma manual, es necesario automatizar el proceso para tener la información disponible y segura.
Justificación del Impacto
Debido a la necesidad planteada es necesario almacenar la información de manera digital, permitiendo agilizar los procesos, compartir la información con diferentes unidades, facilitar la generación de reportes, entre otras tareas que se realizan actualmente.
Supuestos y Asunciones
El sistema se va a desarrollar dentro de la misma empresa. Existe al menos un funcionario de la unidad de informática que será destinado a esta tarea.
Restricciones
Se cuenta con las herramientas de desarrollo disponibles en la empresa. No hay presupuesto para adquisiciones externas.
Factores Claves de éxito
Comunicación entre el usuario funcional del departamento de recursos humanos y el desarrollador del departamento de TI. Disponibilidad de los involucrados.
Identificación de Grupos de Interés (Stakeholders)
- Director de Proyecto. - Desarrollador - Usuario funcional de recursos humanos.
Patrocinador Gerente de Proyecto
4.8.2 Planificación
En la planificación uno de los pasos más importantes es el análisis de
requerimientos el cual se va a realizar mediante casos de uso, para el caso
planteado el documento quedaría de la siguiente manera (solo se hace para uno
de los casos de uso identificados y tomando en cuenta solo uno los flujos del
sistema):
126
Tabla 41: Ejemplo: Especificación de Caso de Uso
Implementación del Sistema de Empleados Versión: 1.0 Especificación Caso Uso: IMEC Empleados Fecha: 23/06/2009 Doc. Nº CU01-IMEC_Empleados
Especificación Caso Uso: IMEC Empleado
1. Nombre Caso de Uso: IMEC Empleado 1.1 Descripción Breve Caso de uso iniciado por el usuario, su objetivo es que el usuario pueda mantener la información de los empleados. Entre las acciones que puede realizar el usuario están: - Agregar un nuevo empleado. - Modificar información a un empleado existente. - Eliminar un empleado. - Consultar los datos de un empleado. 2. Flujo de Eventos 2.1 Flujo Básico El sistema muestra la ventana que permite dar mantenimiento a la información de los empleados, el formulario permite: - Insertar un empleado: Se ejecuta el sub-flujo A-1 Insertar Empleado. - Modificar los datos de un empleado: Se ejecuta el sub-flujo A-2 Modificar Empleado. - Eliminar un empleado: Se ejecuta el sub-flujo A-3 Eliminar Empleado. - Consultar un empleado: Se ejecuta el sub-flujo A-4 Consultar Empleado. 2.1.1 Primer Flujo Alterno: Insertar un empleado
E-1: Se pierde conexión con la base de datos.
# Acciones del Actor # Acciones del sistema
1 El usuario elige la opción de insertar empleado
2 El sistema muestra la pantalla respectiva para dicha tarea
3 El usuario ingresa los datos y da guardar
4 El sistema guarda la información en la base de datos y despliega una ventana de confirmación (E-1)
3. Requerimientos Especiales Que la base de datos esté creada y disponible. 4. Pre-condiciones Que exista la conexión a la base de datos y las herramientas para administrarla. 5. Post-condiciones No hay pos-condiciones para este caso de uso.
127
6. Puntos de extensión No hay puntos de extensión identificados.
Confidencial [Empresa Ficticia, S.A., 2009] Página #
La siguiente tabla corresponde al plan de gestión de alcance.
Tabla 42: Ejemplo: Plan de Gestión de Alcance
Plan de Gestión de Alcance Versión: 1.0 Proyecto: Implementación de Sistema de Empleados Fecha: 25/06/2009 Doc. Nº GA01-SistemaEmpleados
Plan de Gestión de Alcance
1. Resumen Ejecutivo El departamento de RRHH requiere agilizar y automatizar la información referente a los empleados de la empresa. 1.1 Descripción Breve Consiste en crear un sistema que permita el mantenimiento de esta información. 2. Descripción del Proyecto 2.1 Generalidades del Proyecto 2.1.1 Visión La empresa busca implementar sistemas estables de acuerdo a las necesidades del departamento los clientes internos. 2.1.2 Requerimientos 2.1.2.1 Requerimientos Funcionales De acuerdo al análisis de casos de uso se determinó lo siguiente:
No. Descripción Prioridad R1-01 Crear nuevos empleados Alta R1-02 Modificar información de empleados existentes Alta R1-03 Eliminar empleados Alta R1-04 Consultar información de empleados Alta
2.1.2.1 Requerimientos No Funcionales No aplican para el proyecto. 2.1.3 Resultados Esperados Se espera un sistema estable y accesible para el departamento de RRHH que cumpla los
128
requisitos planteados. 2.1.4 Estrategia El desarrollo del software se dividirá en fases de diseño, codificación y pruebas. 2.2 Objetivos Implementar un sistema de empleados para facilitar el mantenimiento de la información. 2.3 Alcance del Proyecto
ID Entregables Descripción Criterios de Aceptación Métricas para los
criterios
FASE 1: Diseño
E1.1 Diseño del Sistema
Gráfico de la pantalla deseada y diseño de base de datos
Lista de requerimientos y diagrama entidad relación normalizado.
Análisis de requerimientos aprobado
Etc…
2.4 Clasificación de los Involucrados - Gerente de Proyecto: Administra el proyecto en cuestión. - Desarrollador: Encargado de implementa el sistema y diseñar la base de datos, también tendrá un papel de líder en la obtención de requerimientos. - Usuario funcional de RRHH: Usuario final que definirá los requerimientos y en última instancia dará el visto bueno al producto final. 3. Límites El proyecto contempla solo el mantenimiento de empleados, sin tomar en cuenta reportes o ligas con otra información institucional. 4. Restricciones Se cuenta con un mes de tiempo para la realización del proyecto. Solo se pueden utilizar herramientas de TI de las que están disponibles en la empresa. 5. Supuestos (Asunciones) Existen sistemas de información adecuados para el desarrollo de este sistema. Hay al menos un recurso de TI que desarrollará el sistema. 6. Hitos del Cronograma Plan de gestión de cada una de las áreas aprobado. Informe de resultados de pruebas. Programa finalizado y en funcionamiento. 6.1 Documentación a Generar Planes de gestión de la administración del proyecto, lecciones aprendidas, diagramas de base de datos, prototipo de interfaz en papel, informe de pruebas realizadas, informe final del proyecto.
129
7. Organización 7.1 Organigrama
7.2 Roles y Responsabilidades
ACTOR RESPONSABILIDAD AUTORIDAD
Gerente de Proyecto
Coordinar actividades, elaborar documentación del plan del proyecto, velar por el cumplimiento de lo estipulado, brindar seguimiento y control al proyecto, informar sobre avances o cambios a la alta gerencia.
Tomar decisiones y dirigir a los involucrados. Exigir el cumplimiento de políticas y procedimientos.
Etc…
8. Estructura Detallada de Trabajo (EDT)
8.1 Diccionario de la EDT
Diccionario de actividades de la Estructura Detallada de Trabajo (EDT)
Información General de la actividad Id: [# Consecutivo] EDT #: 1.2
Nombre de la Actividad: Analizar puntos de función
Descripción: Consiste en realizar el análisis por medio de puntos de función del sistema a desarrollar
Entradas: Requerimientos planteados por el usuario Salidas: Informe de resultados Puntos de Control: Entrega del informe de resultados Responsable(s): Programador Recursos Materiales: NA Sub-contrataciones: NA
Estimaciones de la Actividad
Trabajo 8 horas Costo Final:
Duración 2 días hábiles
130
Fecha Inicio 29/06/2009 Fecha Término 30/06/2009
Fecha de Revisión: 26 de junio de 2009 Comentarios adicionales: NA Director de Proyecto:
_______________________ José Pérez
Revisor:
_______________________ Luis Campos
La siguiente tabla muestra el análisis de puntos de función realizado para el caso
propuesto, cabe destacar que el cálculo final no se agrega ya que lo datos de
costo y equivalencia en tiempo por punto de función son dependientes de cada
empresa y estos datos generalmente son privados. Una técnica para obtener un
valor aproximado, es luego de realizar el análisis de puntos de función en varios
proyectos, proceder a calcular un estimado del costo utilizando los valores de
puntos de función entre el costo total del mismo, se puede utilizar la misma técnica
para estimar una duración por punto de función.
Tabla 43: Ejemplo: Estimación de Puntos de Función
Empresa Ficticia S.A. Proyecto: Implementación del Sistema de Empleados
Estimación de Puntos de Función 1. Identificación de Funciones de Datos
Campos del Archivo Tipo Empleado tipo_entidad ILF administrado como RET Cédula (llave primaria) DET1 Nombre DET2 Apellidos DET3 Fecha_Nacimiento DET4 Dirección DET5 Teléfono DET6
2. Complejidad
Entidad ILF DET RET Complejidad Empleado 1 6 1 Baja
131
3. Funciones Transaccionales (EI)
Transacciones EI Contadas como Complejidad
Empleado
Crear empleado 6 DETs y 1 FTR Empleado Baja Modificar empleado 6 DETs y 1 FTR Empleado Baja Eliminar empleado 1 DET y 1 FTR Empleado Baja 4. Consultas Externas (EQ)
EQ FTR DET Complejidad Consultar empleado 1 Personal 6 Baja
5. Puntos de Función sin Ajustar
Componentes Niveles de Función Baja Media Alta
Archivos Lógicos Internos (ILF) 1 x 7 Archivos de Interface Externa (EIF) Entradas Externas (EI) 3 x 3 Salidas Externas (EO) Consultas Externas (EQ) 1 x 3
Total 19 PFSA 6. Factor de Ajuste 1. Comunicación de Datos: 5
2. Procesamiento datos distribuido: 0 3. Rendimiento: 4 4. Configuración: 3 5. Tasa Transaccional: 2 6. Entrada de datos en línea: 3 7. Eficiencia del usuario final: 3 8. Actualización en línea: 3 9. Procesamiento Complejo: 0 10. Reutilización: 4 11. Facilidad de Instalación: 3 12. Facilidad de Operación: 5 13. Adaptabilidad a Múltiples Sitios: 1 14. Facilidad de cambio: 3
Total de Grados de Influencia (TI) → 39
7. Puntos de Función Ajustados FA = (39 * 0.01) + 0.65 → 1.04 PF = 1.04 * 19 → 19.76
132
8. Valor Esperado
6
)76.19*10)76.19*8(476.19*6( +∗+=VE → 158.08
9. Costo estimado
CostoPFCostoTotal ∗= 76.19 3
10. Duración estimada
TiempoPFtalDuraciónTo ∗= 76.19 4
4.8.3 Ejecución
Se presenta un ejemplo de las plantillas que resultan útiles en esta fase, la
siguiente corresponde a la minuta, para documentar reuniones.
Tabla 44: Ejemplo: Minuta
Minuta No. 001 Versión: 1.0 Proyecto: Implementación de Sistema de Empleados Fecha: 25/06/2009
Inicio Fin Elaborado por Ubicación 10:30 11:30 Jose Pérez Sala de Reuniones TIC Objetivo Levantar lista de requerimientos
Asistente Puesto Departamento José Pérez Administrador de proyectos TIC Carol González Esp. en Sistemas de Información TIC Mercedes Calderón Técnico en RH RRHH Temas desarrollados Se discute lo que se desea del sistema, de acuerdo a lo que el departamento de RRHH necesita y las herramientas de TI que hay disponibles para su desarrollo. Acuerdos definidos Se define que para el 26/06/2009 debe estar listo el análisis de requerimientos mediante puntos de función.
3 Este valor debe reemplazarse por el costo estimado por punto de función. 4 Este factor debe ser reemplazado por el tiempo equivalente a un punto de función, de acuerdo a lo estimado por la empresa.
133
4.8.4 Seguimiento y Control Tabla 45: Ejemplo: Informe de Avance
Informe de Avance Versión: 1.0 Proyecto: Implementación del Sistema de Empleados Fecha: 20/07/2009 Doc. Nº IA01-SistemaEmpleados
Información General
Nombre del Proyecto: Implementación del Sistema de Empleados Director del Proyecto: José Pérez
Fecha de Inicio: 22/06/2009
Fecha Finalización: 30/07/2009
Estado General del Proyecto: A Tiempo Observaciones Generales: El proyecto va progresando de acuerdo a lo planificado.
Cronograma
Planificado Situación Real % Avance: 70% Actividades: 3.2, 3.3
% Avance: 71% Actividades: 3.2, 3.3 Fecha estimada de término: 30/07/2009
Observaciones: NA
Presupuesto
Planificado Situación Real % de presupuesto gastado: 70% Presupuesto estimado: US$700
% de presupuesto gastado: 75% Presupuesto estimado: US$ 750
Observaciones: El recurso principal tuvo un retraso con respecto al trabajo programado por tanto se incrementaron las horas de trabajo durante una semana.
Alcance
Observaciones: El proyecto va dentro del margen esperado de avance, cumpliendo los objetivos definidos en el levantamiento de requerimientos realizado.
Aprobación
Fecha de Revisión: 21/07/2009 Comentarios adicionales: NA Director de Proyecto:
_______________________ José Pérez
Revisor:
_______________________ Laura Quesada
134
4.8.5 Cierre Tabla 46: Ejemplo: Reporte Final
Informe Final Versión: 1.0 Proyecto: Implementación del Sistema de Empleados Fecha: 30/07/2009 Doc. Nº RF01-SistemaEmpleados
Información General
Nombre del Proyecto: Implementación del Sistema de Empleados Director del Proyecto: José Pérez
Fecha de Inicio: 22/06/2009
Fecha de Fin: 29/07/2009
Estado Final del Proyecto: Exitoso Observaciones Generales El proyecto termina con éxito según lo planificado.
Cronograma
Planificado Real Se planificó terminar para el 30/07/2009. Se termina de acuerdo a lo planificado sin
necesidad de solicitar una prórroga. Observaciones: NA
Presupuesto
Planificado Real Presupuesto estimado: $1000 Presupuesto gastado: $1100 Observaciones: Se tuvo que solicitar un presupuesto adicional de $100 debido a que para culminar en la fecha planificada se iba a tener que aumentar un poco el costo por el pago de horas extra al personal.
Alcance
Observaciones: Se entrega el producto en conformidad con el usuario funcional de acuerdo a los requisitos estipulados en los requerimientos iniciales.
Lecciones Aprendidas
Las versiones de los últimos cambios realizados en el código debe guardarse diariamente en el servidor de respaldo, para evitar problemas de versiones durante la implementación del mismo.
Documentación
Archivos Participantes CU01-IMEC_Empleados GA01-SistemaEmpleados
Gerente de Proyecto: José Pérez Desarrollador: Ana Solano
135
IA01-SistemaEmpleados RF01-SistemaEmpleados
Usuario funcional: Laura Quesada Jefe TI: Luis Campos
Control de Cambios Base de datos de conocimiento No se han aplicado cambios a la fecha
Lecciones aprendidas cuyos identificadores responden a LA-01, LA-02 y LA-03
Aprobación
Fecha de Aprobación: 03/08/2009 Comentarios adicionales: Director de Proyecto:
_______________________ José Pérez
Patrocinador o Cliente:
_______________________ Laura Quesada
136
Capítulo 5
5 Conclusiones
La metodología propuesta permite gestionar proyectos de desarrollo de software a
la medida y modelado de bases de datos de una manera más fluida y
normalizada, el uso oportuno de la misma permite unificar el proceso dentro de la
unidad o departamento de TI y organizar el trabajo a realizar desde un principio, lo
cual permite un ahorro en tiempo y costo, además mejora la calidad de los
sistemas y procesos de implementación.
La documentación que se desarrolla a lo largo de un proyecto fortalece los
procesos de la empresa y enriquece la cultura de administración de proyectos,
permitiendo mejorar la gestión de proyectos futuros, no solo por los activos de
proceso que se generan sino por el conocimiento y experiencia del recurso
humano de la empresa.
La motivación del personal es un factor clave que hay que gestionar
correctamente en los proyectos, permite fomentar el compromiso y obtener un
aprovechamiento mayor del aporte del recurso humano.
El modelado mediante casos de uso es una herramienta que permite centrarse en
las necesidades y expectativas del usuario, permitiendo evaluar la funcionalidad
que se requiere y no sesgar la propuesta de acuerdo a criterios técnicos. Además
esta herramienta facilita la priorización de requerimientos, ya que se centra en las
opciones, módulos o funcionalidades que son más importantes para el usuario y
por tanto para su negocio.
Esta metodología unificada de administración de proyectos y computación permite,
por medio de los procedimientos, procesos, herramientas, técnicas y plantillas
definidas gestionar proyectos de manera ordenada, pero cabe destacar que es
137
solo un punto de partida, para que sea funcional debe adaptarse a las
necesidades de cada empresa y del cambiante mercado, esto puede implicar
agregar, obviar o bien modificar lo que aquí se propone.
En el caso particular del IICA que no tiene actualmente ninguna metodología, debe
implementar una como la que aquí se presenta para mejorar el proceso de
desarrollo de software con todo lo que esto implica, desde modificar procesos,
definir políticas internas, adoptar las plantillas y herramientas propuestas y
fomentar una cultura de proyectos para que la gestión de proyectos
interdepartamentales sea más fluida.
El proceso de implementación de una metodología de proyectos debe ser gradual
ya que es un cambio en la forma de operación que afecta no solo al departamento
de TI sino también a los clientes, este tiene que estar ligado a un proceso de
capacitación fuerte para los empleados que vayan a cumplir algún papel en este
cambio.
Esta metodología fue realizada investigando las herramientas y teoría que existe a
la fecha, es fundamental la continua investigación para adaptar y mejorar la
herramienta, de manera que ésta crezca con las necesidades del mercado, de la
empresa que la adopte y por supuesto de las áreas de estudio de Computación y
Administración de Proyectos.
138
Capítulo 6
6 Recomendaciones
6.1 Generales
Al adoptar esta metodología por primera vez, es necesario establecer en primera
instancia un proceso de implementación, en el cual se defina cuáles proyectos la
van a utilizar, cuál va a ser la estrategia de capacitación, quién va a ser el gerente
de proyecto para cada proyecto y cómo se van a analizar los resultados. Es mejor
iniciar con proyectos pequeños de complejidad baja o media e ir incrementando
conforme se va perfeccionando la herramienta.
Una vez que la metodología sea implementada y utilizada, se recomienda definir
un grupo responsable de investigar y mantenerla actualizada, este grupo puede
reunirse una o dos veces al año para evaluar posibilidades de mejora o bien
necesidades de modificación. Es fundamental que se evalúen aspectos de
administración de proyectos, de tecnologías de información específicamente de
desarrollo de software a la medida y del mercado meta de la empresa.
La alta gerencia debe generar un plan de capacitación para el personal, ya que
esto permitirá que los involucrados del proyecto aunque no sean encargados
directos sepan el funcionamiento, faciliten el proceso y promuevan la cultura de
proyectos a nivel de empresa.
Esta metodología puede mejorarse adicionándole un ejemplo completo de un caso
ficticio, es decir, generando toda la documentación, plantillas, procesos y análisis
que se requerirían siguiendo esta metodología, en este documento se hizo un
ejemplo solo de algunas plantillas debido a las restricciones de tiempo, ya que
este punto no se había contemplado dentro del alcance.
139
6.2 De gestión de proyectos
El gerente del proyecto debe realizar revisiones periódicas de la documentación,
las cuales deben hacerse tan frecuentes como sea posible para detectar
anomalías, depurar problemas en los documentos que alimentan fases siguientes,
explotar posibles mejoras, implementar cambios o ajustes oportunamente, además
de llevar el control adecuado de los riesgos.
El seguimiento de la documentación, particularmente de las lecciones aprendidas
es de vital importancia, ya que éstas serán el legado para la empresa, los gerentes
de proyecto deben verificar que se realice esta documentación de acuerdo a las
normas establecidas.
El gerente de proyecto debe dar a conocer a su equipo información acerca del
estado del proyecto, los roles y responsabilidades en las actividades del
cronograma para que todos los involucrados tengan claro el avance del proyecto y
su papel en él.
El gerente de proyecto debe encargarse de que la documentación del proyecto se
encuentre disponible y actualizada en algún directorio compartido con el equipo.
Documentos como cronogramas, minutas, reportes de avance, matriz de
responsabilidades y planes de gestión.
140
6.3 Al IICA
Para determinar la funcionalidad de la metodología en el IICA lo ideal es realizar
en un plazo de un año un análisis de resultados, tomando en cuenta la opinión de
quiénes gestionaron los proyectos de esa manera, los activos de proceso
generados de esos proyectos y los resultados per se, esta tarea debe llevarla a
cabo un líder de sistemas de información designado por el jefe de la unidad de
informática.
Finalmente, para la actualización y personalización de la herramienta, se
recomienda formar un grupo que incluya tanto al líder de sistemas de información
como a los gerentes de proyecto, este grupo debe actualizar la documentación y
modificar aquellos aspectos que no resulten funcionales o que deban
complementarse de acuerdo al análisis de resultados.
141
Bibliografía
Bruegge, B. Dutoit, A. (2002). Ingeniería de Software Orientada a Objetos. México,
Pearson Education. Cavazos, E. (2008). Los 4 factores de éxito en un proyecto de TI. Disponible en:
http://www.gravitar.biz/index.php/tecnologia_negocios/4-factores-exito-proyectos-ti/, Consultado el 28 de junio, 2008.
Chamoun, Y. (2002). Administración Profesional de Proyectos La Guía. México:
McGraw-Hill. Derby, E. (2004). Building a Requirements Foundation Through Customer
Interviews. Disponible en: http://www.ayeconference.com/buildingreqtsfoundation, consultado el 10 de agosto de 2008.
Durán, E. (2003). Puntos por Función. Una métrica estándar para establecer el
tamaño del software. Boletín de Política Informática Núm. 6, 2003. México. Disponible en: http://www.inegi.gob.mx/inegi/contenidos/espanol/prensa/Contenidos/Articulos/tecnologia/puntosxfuncion.pdf, consultado el 21 de setiembre de 2008.
Espiñeira, S. y Asociados, Firma miembro de PricewaterhouseCoopers. (2004).
Riesgos Asociados a Proyectos en Tecnología de Información. Disponible en: http://www.pc-news.com/detalle.asp?sid=&id=11&Ida=1389, consultado el 27 de junio de 2008.
Garcerant, I. (2008). Modelado de Casos de Uso. Tecnología y Synergix.
Disponible en: http://synergix.wordpress.com/2008/06/02/modelado-de-casos-de-uso/, consultado el 16 de agosto de 2008.
Gido, J. & Clements, J. (2003). Administración Exitosa de Proyectos. México:
Thomson. Hurtado, L. (2006). Estimación de Proyectos. Disponible en:
http://www.wikilearning.com/articulo/estimacion_de_proyectos-caracteristicas_que_deben_tener_los_modelos/9637-6, consultado el 28 de junio de 2008.
IICA, (2006) Orden Ejecutiva No. 23. Estructura de la Organización de la Dirección
General. San José, Costa Rica.
142
IICA, (2008) Web Institucional. ¿Qué es el IICA? San José, Costa Rica. Disponible
en: http://webiica.iica.ac.cr/eliica/, Consultado el 22 de junio de 2008. Pressman, R. (2002). Ingeniería del Software. Un enfoque práctico. (5ª ed.)
McGraw-Hill. Project Management Institute (2004). Guía de los Fundamentos de la Dirección de
Proyectos. Pennsylvania: PMI. Smith, H. & Fingar, P. (2003). IT doesn’t matter business processes do. Mkpress. Sparx Systems. El Modelo de Caso de Uso. Disponible en:
http://www.sparxsystems.com.es/resources/tutorial/use_case_model.html, consultado el 17 de agosto de 2008.
Standish Group International, Inc (1995). The Chaos Report. Disponible en:
http://www3.uta.edu/faculty/reyes/teaching/general_presentations/chaos1994.pdf, consultado el 23 de junio de 2008.
143
Anexos
144
1. Acta de Constitución (Charter)
Histórico de Revisiones
No. Versión Fecha Descripción Revisado por
V.01 16/06/2008 Revisión en el Seminario de Graduación. Edgar Zamora
V.02 23/06/2008 Revisión de correcciones realizadas. Edgar Zamora
145
Información principal y autorización de proyecto
Información General
Fecha
16 Junio 2008
Nombre del Proyecto
Propuesta Metodológica para la Administración de Proyectos de desarrollo de Software a la medida y modelado de bases de datos basado en la Guía del PMI.
Áreas de conocimiento / procesos
� Alcance, Tiempo, Costo, Riesgos, Integración.
� Planificación, Seguimiento y Control.
Área de aplicación (sector / actividad)
Computación e Informática � Sistemas de Información
Fecha de Inicio
05 Junio 2008
Fecha tentativa de Finalización
30 Noviembre 2008
Objetivos del Proyecto
General
Desarrollar una propuesta para la administración de proyectos de Tecnologías de Información, específicamente en el área desarrollo de Software a la medida y Modelado de Bases de Datos en las áreas de conocimiento Alcance, Tiempo, Costo, Riesgos e Integración, con el fin de facilitar y estandarizar la gestión de este tipo de proyectos.
Específicos
• Definir políticas que apliquen para la correcta administración de los proyectos de sistemas de información.
• Determinar los grupos de procesos, áreas de conocimiento, procedimientos, y otros aspectos que intervienen en la gestión de proyectos de este tipo.
• Proponer el uso de herramientas y técnicas, generar plantillas adecuadas a la administración de este tipo de proyectos.
• Definir los roles y responsabilidades de los Stakeholders en los proyectos de desarrollo de software a la medida y modelado de bases de datos.
• Desarrollar una metodología para la gestión de las áreas de conocimiento Alcance, Tiempo, Costo, Riesgos e Integración para proyectos de TI.
Descripción del Producto
146
Entregables Finales
El entregable final será la propuesta para la gestión de proyectos de software y modelado de bases de datos y durante su desarrollo tendrá los siguientes entregables principales:
� Políticas y plantillas para las áreas de conocimiento de Alcance, Tiempo, Costo, Riesgos e Integración.
� Propuesta de técnicas y herramientas para las áreas de conocimiento especificadas. � Procesos y procedimientos definidos para las áreas de conocimiento a analizar. � Definición de roles y responsabilidades para los involucrados en un proyecto de este
tipo. � Metodología para la gestión de proyectos de desarrollo de software a la medida y
modelado de bases de datos. � Documentación de Administración de Proyectos.
Información del Proyecto
Necesidad del Proyecto
Debido al gran crecimiento que ha tenido esta industria en los últimos años tanto en nuestro país como en el mundo, nace la inquietud y a la vez necesidad de complementar el desarrollo de sistemas con la administración de proyectos con el fin de fortalecer y mejorar el desarrollo de software, no solo a nivel de productos sino también a nivel de procesos.
La iniciativa lo que pretende es generar una propuesta flexible, adaptable, que sea fácil y práctica de aplicar, de manera que sirva tanto para empresas pequeñas o medianas, como para empresas grandes que consideren que puedan utilizar el modelo planteado.
Justificación del Impacto
Debido al apogeo de las tecnologías de información y a la importancia que éstas han adquirido en la vida cotidiana se vuelve indispensable contar con sistemas que tengan la información oportuna y que se adapten a las necesidades de cada una de las empresas, es por esto que los proyectos de desarrollo de software a la medida deben administrarse de la manera más efectiva y eficiente posible.
Esto solo podría verse solventado si se complementan las herramientas y técnicas de la Administración de Proyectos con sus homónimos para el desarrollo de software y se toman en consideración los factores y características propios de este tipo de proyectos.
Con el fin de facilitar de manera un tanto general la administración de este tipo de proyectos es que nace la iniciativa de desarrollar una guía adaptada y enfocada a satisfacer las necesidades que tiene este campo tomando en cuenta los factores y particularidades que se logren identificar a lo largo de la investigación.
Supuestos y Asunciones
� La universidad dará su respuesta para la asignación de tutor, lectores y programación de fecha de la presentación final en un período que no supere 15 días naturales.
� El tutor tendrá tiempo disponible para revisar las secciones que se van desarrollando del PFG en un periodo de una semana aproximadamente mientras se avanza en las otras partes o fases del proyecto.
� La fecha de presentación final será en algún momento del mes de noviembre.
147
Restricciones
a. Se cuenta aproximadamente con 4 meses para la elaboración del proyecto. b. El tiempo para el desarrollo, revisión y retroalimentación del mismo es un tanto
limitada. c. La disponibilidad de tiempo de los involucrados es limitada. d. El proyecto se realiza con recursos propios.
Factores Claves de éxito
a. Respuesta oportuna y adecuada del tutor con respecto a las revisiones del trabajo realizado.
b. Construir una metodología flexible y adaptable a diferentes empresas que se dedican a este nicho de mercado.
Identificación de Grupos de Interés (Stakeholders)
El proyecto básicamente esta estructurado en tres niveles de responsabilidad y participación.
� El Director de Proyecto que en este caso será la misma persona que desarrollará el proyecto final de graduación, por lo tanto éste tiene la responsabilidad del desarrollo de los entregables, además de las funciones inherentes del director de proyecto.
� El Tutor del proyecto, tendrá la responsabilidad de leer y revisar los entregables que se vayan realizando y brindar una retroalimentación oportuna.
� Lectores, que serán definidos oportunamente por la universidad van a ser los responsables de revisar el producto final, brindar la retroalimentación respectiva y finalmente participar de la defensa del proyecto.
Edgar Zamora
Joan Saborío Obando
Aprobado por Firma
148
2. Estructura Detallada de Trabajo
149
3. Cronograma
150
