UNIVERSIDAD PARA LA COOPERACIN INTERNACIONAL

(UCI)

METODOLOGA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIN

BASADA EN LOS ESTNDARES DEL PROJECT MANAGEMENT INSTITUTE

EFRAN GMEZ QUIRS

PROYECTO FINAL DE GRADUACIN PRESENTADO COMO REQUISITO

PARCIAL PARA OPTAR POR EL TITULO DE MASTER EN ADMINISTRACIN DE
PROYECTOS

San Jos, Costa Rica

Marzo del 2006

UNIVERSIDAD PARA LA COOPERACIN INTERNACIONAL

(UCI)

Este Proyecto Final de Graduacin fue aprobado por la Universidad como Requisito parcial para
optar al grado de Master en Administracin de Proyectos

____________________________
MSc. Fabio Muoz Jimnez
DIRECTOR DEL PROYECTO

____________________________
MSc. Miguel Vallejo Sols
DIRECTOR DEL PROGRAMA

____________________________
Ing. Efran Gmez Quirs
SUSTENTANTE

ii

DEDICATORIA
Deseo dedicar este esfuerzo de mi vida a mis hijos y a mi madre, comprendo muy bien que han
habido momentos de ausencia durante el transcurso de esta nueva formacin, pero el tiempo se
encargar de demostrar que solo con determinacin y conviccin en nuestros ideales se llega al
final, aunque a veces signifique sacrificio en alguna de las reas de nuestra vida.
Espero que logros como ste contribuyan a que mis hijos comprendan que la sabidura y los valores
del hombre se fundamentan en las semillas del conocimiento y que la riqueza que entrega la
educacin ser un activo que permanecer durante el resto de nuestras vidas.

iii

TABLA DE CONTENIDOS

1.

INTRODUCCIN .................................................................................................................. 1

1.1.

PROBLEMAS DE LOS PROYECTOS DE DESARROLLO DE SISTEMAS DE INFORMACIN ......................... 1

1.1.1. JUSTIFICACIN DEL PROYECTO...................................................................................................... 1

1.1.2.

OBJETIVOS DEL PROYECTO ........................................................................................................... 2

2.

MARCO TERICO ............................................................................................................... 4

2.1.

MARCO REFERENCIAL ............................................................................................................... 4

2.1.1.

ASPECTOS TERICOS RELACIONADOS CON LOS SISTEMAS DE INFORMACIN ................................... 4

2.1.2.

CICLO DE VIDA DEL DESARROLLO DE SISTEMAS .............................................................................. 5

2.1.2.1. FASE CONCEPTUAL ....................................................................................................................... 6

2.1.2.2. FASE DE DEFINICIN ..................................................................................................................... 6
2.1.2.3. FASE DE ADQUISICIN O DE PRODUCCIN ...................................................................................... 6
2.1.2.4. FASE OPERACIONAL...................................................................................................................... 7
2.1.2.5. FASE DE OBSOLESCENCIA ............................................................................................................. 7
2.1.3.

DEFINICIN DE INFORMACIN ........................................................................................................ 7

2.1.4.

DEFINICIN

2.1.5.

ORIGEN DE LOS SISTEMAS DE INFORMACIN .................................................................................. 8

2.1.6.

CARACTERSTICAS DE LOS SISTEMAS DE INFORMACIN................................................................... 9

2.1.7.

CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIN.............................................. 9

2.1.8.

DEFINICIN DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIN ...................... 9

DE UN SISTEMA DE INFORMACIN ............................................................................... 8

2.1.8.1. INVESTIGACIN PRELIMINAR ........................................................................................................ 10

2.1.8.2. ACLARACIN DE LA SOLICITUD..................................................................................................... 10
2.1.8.3. ESTUDIO DE FACTIBILIDAD ........................................................................................................... 10
2.1.8.3.1.LA FACTIBILIDAD TCNICA .......................................................................................................... 11
2.1.8.3.2.FACTIBILIDAD ECONMICA ......................................................................................................... 11
2.1.8.3.3.LA FACTIBILIDAD OPERACIONAL.................................................................................................. 11
2.1.8.4. APROBACIN DE LA SOLICITUD .................................................................................................... 12
2.1.9.

DETERMINACIN DE LOS REQUERIMIENTOS DEL SISTEMA .............................................................. 12

iv

2.1.10. DISEO DEL SISTEMA .................................................................................................................. 13

2.1.11. DESARROLLO DE SISTEMAS ......................................................................................................... 14
2.1.12. PRUEBAS DEL SISTEMA ............................................................................................................... 15
2.1.13. IMPLANTACIN Y EVALUACIN ..................................................................................................... 15

2.2.

TEORA DE LA ADMINISTRACIN DE PROYECTOS. .................................................................. 17

2.2.1.

QU ES UN PROYECTO? ........................................................................................................... 17

2.2.2.

QUE ES LA DIRECCIN DE PROYECTOS? .................................................................................... 17

2.2.3.

REAS DE CONOCIMIENTO DE LA DIRECCIN DE PROYECTOS ......................................................... 18

2.2.4.

PROCESOS Y CARACTERSTICAS DE LA GESTIN DEL ALCANCE DEL PROYECTO ............................. 21

2.2.4.1. PLANIFICACIN DEL ALCANCE ..................................................................................................... 21

2.2.4.2. DEFINICIN DEL ALCANCE........................................................................................................... 21
2.2.4.3. CREACIN DE LA WBS (EDT) .................................................................................................... 22
2.2.4.4. VERIFICACIN DEL ALCANCE ....................................................................................................... 22
2.2.4.5. CONTROL DEL ALCANCE ............................................................................................................. 22
2.2.5.

PROCESOS Y CARACTERSTICAS DE LA GESTIN DEL TIEMPO DEL

PROYECTO ............................... 23

2.2.5.1. DEFINICIN DE LAS ACTIVIDADES ................................................................................................ 23

2.2.5.2. ESTABLECIMIENTO DE LA SECUENCIA DE LAS ACTIVIDADES ........................................................... 23
2.2.5.3. ESTIMACIN DE RECURSOS DE LAS ACTIVIDADES......................................................................... 23
2.2.5.4. ESTIMACIN DE LA DURACIN DE LAS ACTIVIDADES ..................................................................... 23
2.2.5.5. DESARROLLO DEL CRONOGRAMA ................................................................................................ 23
2.2.5.6. CONTROL DEL CRONOGRAMA ..................................................................................................... 23
2.2.6.

PROCESOS Y CARACTERSTICAS DE LA GESTIN DE LOS RIESGOS DEL PROYECTO ........................ 24

2.2.6.1. PLANIFICACIN DE LA GESTIN DE RIESGOS ................................................................................ 24

2.2.6.2. IDENTIFICACIN DE RIESGOS ...................................................................................................... 24
2.2.6.3. ANLISIS CUALITATIVO DE RIESGOS ............................................................................................ 24
2.2.6.4. ANLISIS CUANTITATIVO DE RIESGOS .......................................................................................... 25
2.2.6.5. PLANIFICACIN DE LA RESPUESTA A LOS RIESGOS ....................................................................... 25
2.2.6.6. SEGUIMIENTO Y CONTROL DE RIESGOS ....................................................................................... 25
2.2.7.

PROCESOS Y CARACTERSTICAS DE LA GESTIN DE LA CALIDAD DEL PROYECTO ........................... 25

2.2.7.1. PLANIFICACIN DE CALIDAD ........................................................................................................ 26

2.2.7.2. REALIZAR ASEGURAMIENTO DE CALIDAD ..................................................................................... 26
2.2.7.3. REALIZAR CONTROL DE CALIDAD ................................................................................................ 26

3.

MARCO METODOLGICO ............................................................................................. 29

3.2.1.

SECUENCIA DE ACTIVIDADES ....................................................................................................... 31

3.2.2.

ESTIMACIN DE LA DURACIN DE LAS ACTIVIDADES ...................................................................... 31

3.3.2.

TCNICA DE DIAGRAMACIN

4.

DESARROLLO .................................................................................................................... 37

4.1.

SELECCIN DEL PROYECTO PILOTO ........................................................................................ 37

4.2.

LA GESTIN DEL ALCANCE EN EL DESARROLLO DE SISTEMAS DE INFORMACIN .38

4.3.

LA GESTIN DEL TIEMPO EN EL DESARROLLO DE SISTEMAS DE INFORMACIN ..................... 42

DE CAUSA Y EFECTO ........................................................................ 33

4.3.1. CREACIN DEL DIAGRAMA DE RED.............................................................................................. 42

4.3.2. ESTIMACIN DEL TIEMPO........................................................................................................... 44
4.3.3.

TCNICA PERT ........................................................................................................................... 49

4.4.

LA GESTIN DEL RIESGO EN EL DESARROLLO DE SISTEMAS DE INFORMACION .................... 56

4.4.1. IDENTIFICACIN DE RIESGOS................................................................................................... 56

4.4.1.1. TORMENTA DE IDEAS .................................................................................................................. 56
4.4.1.2. TCNICA DELPHI ........................................................................................................................ 57
4.4.1.3. ENTREVISTAS............................................................................................................................. 57
4.4.1.4. REVISIN DE LOS SUPUESTOS O HIPTESIS.................................................................................. 57
4.4.1.5. DIAGRAMAS DE CAUSA Y EFECTO................................................................................................. 57
4.4.2.

PRIORIDAD

DE LOS

RIESGOS ..................................................................................................... 59

4.4.3. ANLISIS CUALITATIVO DE RIESGOS ....................................................................................... 59

4.4.3.1. CDIGO IDENTIFICADOR DEL RIESGO ........................................................................................... 60
4.4.3.2. CAUSA ....................................................................................................................................... 60
4.4.3.3. PROBABILIDAD ........................................................................................................................... 63
4.4.3.4. IMPACTO .................................................................................................................................... 63
4.4.3.5. RANGO (PXI) ............................................................................................................................. 64

vi

4.4.4. ANLISIS CUANTITATIVO DE RIESGOS .................................................................................... 65

4.4.4.1. ENFOQUE PERT ........................................................................................................................ 66
4.4.4.2. ANLISIS DEL VALOR MONETARIO ESPERADO (EVM) ................................................................... 66
4.4.4.3. ANLISIS MEDIANTE RBOL DE DECISIONES .................................................................................. 67
4.4.4.4. EVALUACIN DEL RBOL DE DECISIONES ...................................................................................... 68
4.4.4.5. SIMULACIN MONTE CARLO........................................................................................................ 68
4.4.4.5.1 PASOS BSICOS DEL MTODO MONTE CARLO ............................................................................ 69

4.4.5. PLANIFICACIN DE LA RESPUESTA A LOS RIESGOS ................................................................ 73

4.4.5.1. EVITAR EL RIESGO ...................................................................................................................... 74
4.4.5.2. EXPLOTAR LA OPORTUNIDAD ....................................................................................................... 74
4.4.5.3. TRANSFERIR EL RIESGO .............................................................................................................. 74
4.4.5.4. MITIGAR EL RIESGO .................................................................................................................... 75
4.4.5.5. ACEPTAR EL RIESGO ................................................................................................................... 75

4.5.

LA GESTIN DE CALIDAD EN PROYECTOS DE DESARROLLO DE SIST. DE INFORMACIN ........ 79

4.5.1.

REPASO DE LOS PRINCIPALES CONCEPTOS TERICOS .................................................................. 79

4.5.2.

NECESIDAD DE USAR LOS

4.5.3.

PROCEDIMIENTO RECOMENDADO PARA GESTIONAR LA CALIDAD EN EL PROYECTO .......................... 81

PROCESOS DE CALIDAD EN LOS PROYECTOS DE SISTEMAS .................... 79

4.5.3.1. FORMULARIOS UTILIZADOS .......................................................................................................... 81

4.5.3.2. INSTRUCTIVO RELACIONADO........................................................................................................ 82
4.5.3.3. DESCRIPCIN DE PARTICIPANTES................................................................................................ 82
4.5.3.4. USO DEL DIAGRAMA DE FLUJO ..................................................................................................... 86
4.5.3.5. USO DE FORMULARIOS................................................................................................................ 88
4.5.3.6. INSTRUCTIVO DE TRABAJO .......................................................................................................... 90

4.6.

GUA DE USO DE LA METODOLOGA PROPUESTA .................................................................... 93

4.6.1.

GESTIN DEL ALCANCE .............................................................................................................. 94

4.6.2.

GESTIN DEL TIEMPO ................................................................................................................. 95

4.6.3.

GESTIN DEL RIESGO................................................................................................................. 96

4.6.4.

GESTIN DE LA CALIDAD............................................................................................................. 98

5.

CONCLUSIONES ....................................................................................................................101

vii

6.

RECOMENDACIONES ............................................................................................................103

7.

BIBLIOGRAFA .......................................................................................................................105

8.

ANEXOS ................................................................................................................................ 106

viii

INDICE DE CUADROS Y FIGURAS

Pgina

Cuadros
Cuadro 1: Matriz de Probabilidad e Impacto

35

Cuadro 2: Descomposicin del trabajo a ejecutar

39

Cuadro 3: Diccionario de las actividades de la Estructura Detallada del Trabajo

41

Cuadro 4: Responsabilidades de los miembros del equipo de trabajo

47

Cuadro 5: Uso de tiempos estimados y probabilidades

51

Cuadro 6: Uso del Pert en el Proyecto de Automatizacin de Actas

53

Cuadro 7: Cronograma del Proyecto de Automatizacin de Actas

55

Cuadro 8: Probabilidad de ocurrencia del Riesgo

61

Cuadro 9: Impacto si ocurre el Riesgo

61

Cuadro 10: Descripcin del impacto segn la escala

62

Cuadro 11: Marcadores de riesgo

63

Cuadro 12: Anlisis cualitativo del sistema de automatizacin de actas

64

Cuadro 13: Aplicacin del Anlisis del Valor Monetario Esperado

67

Cuadro 14: Actividades con incertidumbre y sus tres tiempos

70

Cuadro 15: Repeticiones con tres valores

71

Cuadro 16: Resultado del anlisis de las 100 repeticiones

72

Cuadro 17: Clculo de reserva para contingencias

76

Cuadro 18: Respuesta a los riesgos en el Proyecto de Automatizacin de Actas

77

Cuadro 19: Plan de Contingencias en el Proyecto de Automatizacin de Actas

78

Cuadro 20: Detalle de Productos Entregables de la Metodologa

99

Figuras
Figura 1: Estructura Detallada del Trabajo

30

Figura 2: Estructura detallada del trabajo (EDT)

40

Figura 3: Diagrama de red de actividad en el nodo

43

ix

Figura 4: Diagrama de red del Sistema de Automatizacin de Actas

44

Figura 5: Org. del equipo de trabajo para el Sistema de Automatizacin de Actas

45

Figura 6: Ruta Crtica del proyecto

48

Figura 7: Diagrama de causa y efecto.

58

Figura 8: Estructura de desglose del riesgo

59

Figura 9: Ejemplo de un rbol de decisiones

68

Figura 10: Grafico de Tornado de Proy. de automatizacin de Actas.

73

Figura 11: Flujo del desarrollo de Software

87

Figura 12: Solicitud de un Nuevo Sistema

88

Figura 13: Bitcora de problemas encontrados

89

Figura 14: Diagrama general de la Metodologa

93

Figura 15: Gua de uso de la metodologa en la Gestin del Alcance.

94

Figura 16: Gua de uso de la metodologa en la Gestin del Tiempo

95

Figura 17: Gua de uso de la metodologa en la Gestin del Riesgo

96

Figura 18: Gua de uso de la metodologa en la Gestin de la Calidad

98

RESUMEN EJECUTIVO
Hace aproximadamente 30 aos que los sistemas de informacin se han venido desarrollando y
perfeccionado ms da a da. En la actualidad la mayora de empresas cuentan con sistemas de
informacin. En estos das la tecnologa se ha convertido en un factor clave para el desarrollo de las
naciones y del planeta. El avance de la tecnologa ha contribuido a que la Computacin est
desarrollndose aceleradamente y este avance est relacionado directamente con el funcionamiento
de los sistemas de informacin.
Sin embargo, el campo de los sistemas est acompaado de problemas que se relacionan mucho
con el perfil tcnico de los profesionales de esta rea. Estas personas tienden a concentrarse ms
en las reas tcnicas, como consecuencia descuidan las reas administrativas; esto ha provocado
una imagen problemtica alrededor de los proyectos informticos.
En los proyectos informticos existen fases o actividades que son propias de este campo, tales
como: Levantamiento de requerimientos iniciales, anlisis de la situacin actual, diseo del nuevo
sistema, programacin e implementacin. La propuesta de esta investigacin es lograr que en estas
etapas se ejecuten paralelamente otras actividades que permitan obtener los productos entregables
de las reas del conocimiento a cubrir. As por ejemplo, en la fase del anlisis de la situacin actual,
aparte de obtener lo que dicta la metodologa de sistemas, tambin se obtendr la definicin de la
estructura detallada del trabajo (EDT), lo que permitir tener una visin ms clara del trabajo a
ejecutar. De manera similar se obtendrn los otros productos que identifican las reas del
conocimiento utilizadas, y por consiguiente se aumentar la probabilidad de xito en los proyectos
informticos.
Paralelamente a las actividades adicionales que se recomiendan, se usarn una serie de plantillas
que servirn de gua al Informtico en el momento de realizar las actividades relacionadas con la
administracin de proyectos. Esta investigacin pretende plantear una alternativa que provea al
Informtico de instrumentos destinados a evitar deficiencias en la administracin de proyectos. Esta
alternativa disminuye el riesgo de que los Informticos se concentren solamente en las reas
tcnicas, y por consiguiente descuiden las actividades relacionadas con la administracin del
proyecto. Desafortunadamente es comn que el personal tcnico reste importancia al valor de las
funciones administrativas y esto provoca que los proyectos informticos no presenten una buena
planeacin en las definiciones de alcance, cronograma de trabajo, control del riesgo y control de
calidad.
El objetivo de esta investigacin es ofrecer una metodologa que le permita al Profesional de
Informtica usar tcnicas de Administracin de Proyectos, a travs de una serie de actividades
adicionales que se integren con las fases tradicionales del desarrollo de sistemas, que permitan
implementar procesos para dar un adecuado seguimiento a los proyectos. Para alcanzar las metas
se pretende crear una asociacin entre las fases tpicas del desarrollo de sistemas, y las actividades
relacionadas con las reas del conocimiento utilizadas en ste desarrollo.

xi

Las reas de conocimiento que involucra este trabajo son: La Gestin del Alcance, la Gestin del
Tiempo, la Gestin de Riesgos, y la Gestin de Calidad.
Los resultados del desarrollo de los objetivos propuestos demuestran que si es posible enmarcar el
desarrollo de sistemas dentro de un contexto de Administracin Profesional de Proyectos. La
estrategia que se utiliz en esta investigacin consisti en agregar actividades extra a las fases del
ciclo de vida del desarrollo de Sistemas de Informacin. Las actividades adicionales se incluyeron de
forma que no confundan al profesional informtico, esto se logr a travs de una retroalimentacin
constante acerca de los motivos por los cuales se recomienda el uso de los nuevos instrumentos.
Los productos adicionales que se obtuvieron al utilizar la metodologa corresponden a los
recomendados por el PMI como productos generados para cada una de las cuatros reas del
conocimiento que se cubrieron en esta investigacin.
Otro aspecto importante que se detecta como consecuencia de la investigacin y que se sugiere
como recomendacin es la necesidad del apoyo de la alta direccin en este tipo de situaciones,
porque como sucede con todo lo que es nuevo, al inicio va a haber resistencia al cambio y es en
estas circunstancias donde se requiere la participacin directa de la alta gerencia. Una forma de
disminuir la resistencia podra ser que el uso de la metodologa se haga en forma gradual, esto para
darle oportunidad a la organizacin de ir asimilando los nuevos procedimientos en forma
progresiva, de esta forma se lograr que la introduccin en la Administracin Profesional de
Proyectos sea gradual y por lo tanto se minimice el impacto en el personal.
Al final del desarrollo se podr encontrar una gua en la cual se resumen los productos utilizados en
cada una de las cuatro reas cubiertas. Este resumen le permitir al profesional informtico en forma
rpida detectar cuales sern los componentes que deber usar u obtener, as como la interaccin
entre ellos dentro de las reas de estudio.

xii

1. INTRODUCCIN
1.1. Problemas de los proyectos de desarrollo de Sistemas de Informacin
El profesional de informtica es entrenado acadmicamente para conceptualizar los componentes
tcnicos que darn forma a un sistema de informacin. Parte de su entrenamiento est relacionado
con tcnicas para extraer informacin necesaria para la modelacin de los sistemas. Adems se le
brinda educacin para conceptualizar un sistema como un proyecto que estar formado por
diferentes etapas.
Sin embargo surgen problemas cuando el profesional de informtica se orienta ms a las ramas
tcnicas que a las administrativas, esto provoca que se le reste valor a las actividades de
planeacin, definicin y control. Y como consecuencia de esta problemtica surgen problemas
relacionados con falta de definicin en el alcance, planeacin deficiente de los tiempos del proyecto,
carencia de procedimientos, falta de definicin de las responsabilidades, ausencia de mecanismos
de control de calidad, ausencia de planes para la contingencia de riesgos potenciales.
El problema se manifiesta ms cuando en las etapas de planeacin de los sistemas de informacin
no se invierte suficiente tiempo para la planeacin del proyecto, porque al haber un estereotipo
tcnico, el medio ambiente espera ver al personal al frente de una estacin de trabajo ejecutando
funciones tcnicas como lo son la programacin, la configuracin de equipo de comunicaciones,
administracin de bases de datos etc. Esta idea de sentarse lo ms pronto posible a ejecutar
funciones tcnicas descuidando las funciones de planeacin trae problemas que se repiten da a da
relacionados con el alcance, el tiempo, el control de la calidad y los riesgos.
1.1.1. Justificacin del proyecto
Ante este problema se pretende plantear una alternativa que provea al profesional de informtica
con instrumentos que le permitan evitar caer en los problemas planteados. Se considera que es

necesario que se le brinde a los profesionales del rea alternativas que les permita lograr un trabajo
ms eficiente y eficaz.
Con la preparacin adquirida en la maestra de Administracin de Proyectos se puede visualizar
donde se encuentran las debilidades de los Ingenieros de Sistemas en el campo de la
Administracin de Proyectos, y se considera muy importante brindarle a estos profesionales
herramientas que fortalezcan estas debilidades. Adems, es importante que este desarrollo sea
llevado a cabo por personas que conozcan el campo de la Ingeniera de Sistemas y a la vez que
tengan preparacin acadmica formal en el campo de Administracin de Proyectos, porque esto
permitir amoldar el trabajo adicional a las fases clave del desarrollo de sistemas, y adems ser
bastante transparente para el profesional de Informtica.
1.1.2. Objetivos del proyecto
Objetivo General
Desarrollar una metodologa que incorpore los estndares del Project Management Institute (PMI) en
los proyectos de desarrollo de Sistemas de Informacin.
Objetivos Especficos

Crear instrumentos que le permitan a los Profesionales de Tecnologas de Informacin

identificar, cuantificar y documentar el trabajo necesario para el desarrollo e implementacin
de proyectos de desarrollo de Sistemas de Informacin.

Desarrollar procedimientos que le permitan al Profesional Informtico hacer uso de las

herramientas para la administracin del tiempo en el desarrollo de Sistemas de Informacin.

Desarrollar

mtodos que le permitan al Profesional de Tecnologas de Informacin

protegerse ante la presencia de los riesgos tpicos del rea de Sistemas de Informacin.

Desarrollar los procedimientos que deber seguir el profesional informtico para trabajar en
el desarrollo de sistemas bajo un entorno de Gestin de Calidad.

Aplicar la metodologa propuesta en un proyecto piloto para validar su aplicacin.

2. MARCO TERICO
2.1. Marco Referencial
2.1.1. Aspectos tericos relacionados con los Sistemas de Informacin
Para hacer una introduccin a los sistemas de informacin es recomendable hacer una definicin de
este concepto: Un sistema de informacin se refiere a una serie de componentes interrelacionados
que capturan, almacenan, procesan y distribuyen la informacin para apoyar la toma de decisiones,
el control, anlisis y visin en una institucin (Rodrguez, 2003).
Existen tres actividades de un sistema de informacin que producen la informacin que la institucin
requiere para la toma de decisiones, para el control de las operaciones, el anlisis de los problemas
y la creacin de nuevos productos y servicios. Estas actividades son las de insumo, procesamiento
y producto.
Las actividades de insumo estn relacionadas con la captura o recoleccin de datos primarios dentro
de la Institucin o de su entorno para procesarlos en un sistema de informacin. Las actividades de
procesamiento se

relacionan con la conversin del insumo de forma que sea ms comprensible

para los seres humanos, y las de producto se refieren a la distribucin de informacin procesada a
las personas o en las actividades en donde ser usada.
Los sistemas de informacin hacen uso del hardware y software de computadora para el
procesamiento y la distribucin de la informacin.
Existen clasificaciones en los sistemas, alguna de ellas son:
1. Sistema de nivel operativo: Sistemas de informacin que hacen el seguimiento de las
actividades y las transacciones elementales de la organizacin.

2. Sistemas de nivel de conocimiento: Sistemas de informacin en los que se apoyan los

trabajadores del conocimiento y de la informacin en una institucin.
3. Sistemas de nivel gerencial: Son sistemas de informacin en los que se apoya el
seguimiento, control y toma de decisiones y las actividades administrativas de los
administradores de nivel medio.
4. Sistemas de nivel estratgico: Sistemas de informacin, que apoyan a las actividades de
planificacin a largo plazo de los niveles de direccin de la institucin.
Elementos de un sistema
Es lo que compone un sistema. Sin alguno de estos elementos simplemente no existira el sistema.
Los elementos de un sistema son:
Conceptos: Definiciones de cosas o actividades.
Objetos: Pueden ser por ejemplo, una mquina de escribir compuesta de varias partes.
Sujetos: Como puede ser los integrantes de un equipo de ftbol.
Todo sistema cuenta con estos elementos. Por tanto tambin se dice que un sistema es un
agregado de entidades que estn formadas por elementos (O' Brien, 2001).
2.1.2. Ciclo de vida del desarrollo de sistemas
Todo sistema tiene un ciclo de vida. As, como los seres humanos nacen, crecen, se reproducen y
mueren, los sistemas cuentan con un ciclo. Muchos autores manejan menos o ms fases, pero de
acuerdo a Rodrguez (2003) las ms comunes son:
1. Fase conceptual.
2. Fase de definicin.
3. Fase de adquisicin o de produccin.
4. Fase operacional.
5. Fase de obsolescencia

2.1.2.1.

Fase conceptual

La fase conceptual es aquella en la que la idea se concibe y se le hace una evaluacin preliminar.
En esta fase se realizan pronsticos, se evalan los objetivos y alternativas, se realiza una
evaluacin por primera vez de costos y aspectos relacionados con el tiempo que tardar el
desarrollo, se hace la estrategia bsica de la organizacin y los requerimientos de recursos. El
propsito fundamental de la fase conceptual es hacer un estudio sobre papel de todos los
requerimientos, para proporcionar la base de una evaluacin detallada que posteriormente se har
en la etapa siguiente.
Siempre hay un alto porcentaje de sistemas potenciales que no sern realizados; esto debe ser as,
puesto que el proceso de estudio de esta fase conceptual tiene como objetivo identificar proyectos
que tienen un alto riesgo y no son factibles o no son prcticos desde el punto de vista tcnico,
econmico y del ambiente.
2.1.2.2.

Fase de definicin

El propsito principal de esta fase es definir lo ms pronto posible y exacto, los costos, los
programas, la realizacin y los requerimientos de recursos y si todos estos elementos concordarn
econmica y tcnicamente.
La fase de definicin solo narra con mayor detalle qu es lo que se quiere hacer, cundo se desea
hacerlo, cmo se ejecutar y cunto costar.
2.1.2.3.

Fase de adquisicin o de produccin

El propsito de esta fase de adquisicin o de produccin es adquirir y probar los elementos del
sistema y el sistema total mismo utilizando los estndares que se desarrollaron durante las fases
precedentes. El proceso de adquisicin involucra aspectos tales como la implantacin real del

sistema, la fabricacin del equipo, la asignacin de autoridad y de responsabilidad, la construccin

de las instalaciones y la conclusin de la documentacin de apoyo.
2.1.2.4.

Fase operacional

En esta fase, el papel fundamental del gerente de un sistema es proporcionar el apoyo de recursos
requeridos para llevar a cabo los objetivos del sistema.
El gerente encargado del sistema es el que provee de todos los recursos necesarios para llevar a
cabo los objetivos del sistema. Esta fase es resultado de que el modelo ha sido aprobado desde el
punto de vista econmico y el gerente trata de poner ms atencin en los elementos humanos del
sistema y trata de optimizar los recursos del sistema total.
2.1.2.5.

Fase de obsolescencia

Todo ciclo tiene su inicio y su fin, es decir no todo es eterno, as que esta etapa es la de declinacin
o muerte del sistema.
A menudo, esto no es reconocido por las empresas a simple vista, no quieren reconocer de que
cuentan con sistemas obsoletos y que estos ya no son de utilidad para la empresa, muchas veces
son deficientes y se mantienen con equipos e instalaciones inadecuadas.
La empresa debe asumir la realidad que hay que hacer un cambio en sus sistemas as como sus
instalaciones si realmente quiere ser competitiva.
2.1.3. Definicin de informacin
La informacin se refiere a todos aquellos datos transformados o modificados que tienen valor para
aquellos usuarios que hacen uso de ellos (O' Brien, 2001).

Los datos estn constituidos por los registros de los hechos, acontecimientos, transacciones, etc.
Por el contrario, la informacin implica que los datos estn procesados de tal manera que resulten
tiles o significativos para el receptor de los mismos, por lo que en cierto modo, los datos se pueden
considerar la materia prima para obtener informacin. Con lo anterior se llega a la conclusin de que
la informacin corresponde a datos procesados con un valor para aquel usuario que la necesita.
2.1.4. Definicin de un sistema de informacin
De acuerdo a Rodrguez (2003), un sistema de informacin es un conjunto de subsistemas que
incluyen hardware, software, medios de almacenamiento de datos ya sea primarios, secundarios y
bases de datos relacionadas entre s con el fin de procesar entradas para realizar transformaciones
a esas entradas y convertirlas en salidas de informacin importantes en la toma de decisiones.
El objetivo de un sistema de informacin es ayudar al desempeo de las actividades que desarrolla
la empresa, suministrando la informacin adecuada, con la calidad requerida, a la persona o
departamento que lo solicita, en el momento y lugar especificados con el formato ms til para el
receptor.
El sistema de informacin est al servicio de los objetivos de la empresa. Para lograr dichos
objetivos la empresa y sus individuos adoptan procedimientos y prcticas de trabajo que resultan
ms tiles y eficaces.
2.1.5. Origen de los sistemas de informacin
Cuando una empresa crece la supervisin de las actividades relacionadas con ella se desarrolla
hasta encontrarse lejos del alcance de una sola persona. En ese momento el empresario descubre
que le sera necesario estar en varios lugares al mismo tiempo para poder planear, dirigir, coordinar,
analizar y controlar ( sea administrar) las diferentes actividades de su empresa. Los
enfrentamientos para resolver problemas, transferir informacin y verificar las realizaciones que
resultaban adecuados cuando la empresa era pequea, se vuelven demasiado numerosos y exigen

mucho tiempo. En otras palabras, el administrador propietario se encuentra sumergido en una red
compleja de deberes relacionados recprocamente, que debe cumplir. En esta situacin es cuando el
propietario debe decidir la implantacin de un sistema de informacin para la empresa con el fin de
cubrir todas las necesidades que han nacido con el crecimiento de la empresa.
2.1.6. Caractersticas de los sistemas de informacin
Todo sistema necesita tener interaccin con su medio ambiente el cual est formado por todos los
objetos que se encuentran fuera de las fronteras de los sistemas, a esos sistemas se le conocen
como sistemas abiertos, ya que reciben entradas tanto del medio ambiente como internamente y
producen salidas de importancia tanto internamente como para el medio ambiente. En contraste
todos aquellos sistemas que no interactan con su medio se les llama sistemas cerrados; en
realidad, estos sistemas no existen, solo estn como conceptos, solo existen los sistemas abiertos.
2.1.7. Ciclo de vida para el desarrollo de sistemas de informacin
Anteriormente se haba descrito el ciclo de vida de desarrollo de sistemas, ahora se describir el
ciclo de vida pero para el desarrollo de sistemas de informacin, la mayora de las etapas son
similares solo cambian en el nombre de ellas, o varan por el hecho de que estas son orientadas a
sistemas de informacin, la idea principal es conocer las etapas y saberlas aplicar dependiendo del
problema a solucionar.
2.1.8. Definicin del ciclo de vida para el desarrollo de sistemas de informacin
Es el conjunto de actividades que los analistas, diseadores y usuarios realizan para desarrollar e
implantar un sistema de informacin. A continuacin se describen las etapas del ciclo de vida de
desarrollo de sistemas.

2.1.8.1.

Investigacin preliminar

La investigacin preliminar es la primera etapa dentro del ciclo de vida para el desarrollo de sistemas
de informacin. Esta comienza con la formulacin de una solicitud ya sea por parte de un usuario o
un gerente de un departamento que haya detectado una necesidad de mejoramiento de un sistema
o que haya visto la necesidad de automatizar una serie de actividades.
La investigacin preliminar consta de tres partes:
a. Aclaracin de la solicitud
b. Estudio de factibilidad
c. Aprobacin de la solicitud
2.1.8.2.

Aclaracin de la solicitud

Muchas solicitudes que provienen de usuarios o gerentes de departamentos (por ejemplo: ventas,
produccin, contabilidad, etc.) no estn formuladas de manera clara, stas no tienen los
fundamentos necesarios, como para considerarse una solicitud de proyecto. Es por eso que se debe
determinar con precisin lo que realmente el usuario desea.
2.1.8.3.

Estudio de factibilidad

Despus de haber realizado la aclaracin de la solicitud es necesario saber si es factible lo que se

desea realizar, el estudio de factibilidad cuenta con tres aspectos:

Factibilidad tcnica

Factibilidad econmica

Factibilidad operacional

10

2.1.8.3.1.

La factibilidad tcnica

Se refiere a que el proyecto pueda realizarse con los recursos tcnicos con que cuenta la empresa
como son: el equipo con que se cuenta, la tecnologa existente de software y el personal disponible;
se hacen cuestionamientos Se necesita ms tecnologa de software?, Cul es la posibilidad de
desarrollar el proyecto?, Qu tiempo se llevar el proyecto hasta su implantacin?
2.1.8.3.2.

Factibilidad econmica

La factibilidad econmica se refiere a los beneficios que traer la realizacin del proyecto. Se deben
de hacer una serie de cuestionamientos para poder saber si es factible el desarrollo del sistema
econmicamente Los beneficios que se obtienen sern suficientes para cubrir los costos?, Los
costos asociados con la decisin de no crear el sistema son tan grandes que se debe aceptar el
proyecto?
Sin duda este aspecto es el ms importante en las empresas ya que los gerentes muchas veces no
estn dispuestos a solventar estos costos cuando no existen los suficientes fundamentos que los
convenzan de que es necesario la realizacin del proyecto por los beneficios ya sea tanto
econmicos como de calidad y rapidez en la ejecucin de actividades que se podrn realizar en
menos tiempo.
2.1.8.3.3.

La factibilidad operacional

Este ltimo aspecto trata de la utilidad del sistema una vez desarrollado e implantado en la
empresa, Ser utilizado el sistema?, Existir cierta resistencia al cambio por parte de los usuarios
que de como resultado una disminucin de los posibles beneficios de la aplicacin?
El estudio de factibilidad es realizado por lo regular por una o dos personas que tienen conocimiento
en tcnicas de sistemas de informacin y casi siempre son analistas de sistemas.

11

2.1.8.4.

Aprobacin de la solicitud

No todos los proyectos solicitados son deseables o factibles de realizar. Algunas empresas reciben
muchas solicitudes de proyectos de parte de sus empleados, pero solo es posible atender unas
cuantas. Sin embargo aquellos proyectos que son factibles y deseables deben ser incorporados en
los planes de desarrollo de sistemas. Con la aprobacin de la solicitud de proyecto ste puede
comenzar inmediatamente, aunque lo comn es que los miembros del equipo de desarrollo de
sistemas se encuentren ocupados con otros proyectos. Cuando esto ocurre, los ejecutivos deciden
qu proyectos tienen ms importancia para la empresa y en qu orden se desarrollarn.
En las grandes empresas los planes para el desarrollo de sistemas de informacin se hacen con un
especial cuidado, casi igual que los programas de fabricacin o expansin de sus instalaciones.
Despus de aprobar la solicitud de proyecto se estima su costo y el tiempo necesario para hacerlo
as como tambin las necesidades de personal para realizarlo.
2.1.9. Determinacin de los requerimientos del sistema
En esta etapa el analista debe comprender todas las facetas importantes de la parte de la empresa
que se est estudiando. Los analistas trabajan con los usuarios y deben estudiar los procesos de la
empresa para dar respuesta a las siguientes preguntas clave:
1. Qu es lo que se hace?
2. Cmo se hace?
3. Con que frecuencia se presenta?
4. Qu tan grande es el volumen de transacciones o de decisiones?
5. Cul es el grado de eficiencia con el que se efectan las tareas?
6. Existe algn problema?
7. Si existe un problema, Qu tan serio es?
8. Si existe un problema, cul es la causa que lo origina?

12

Para contestar estas preguntas el Analista de Sistemas conversa con varias personas para reunir
detalles relacionados con los procesos de la empresa, sus opiniones sobre por qu ocurren las
cosas, las soluciones que proponen y sus ideas para cambiar el proceso.
Es necesario elaborar cuestionarios para recabar esta informacin, cuando no es posible
entrevistarse en forma personal con los miembros de grupos grandes dentro de la empresa. As
mismo se requiere del estudio de manuales y reportes, la observacin directa de las actividades y en
algunos casos, formas y documentos para comprender mejor el proceso en su totalidad.
Conforme se va reuniendo la informacin, los Analistas van identificando los requerimientos y
caractersticas que debe tener el nuevo sistema, junto con caractersticas operacionales tales como
controles de procesamiento, tiempos de respuesta y mtodos de entrada y salida.
2.1.10. Diseo del sistema
En esta etapa el Analista usa la informacin recolectada anteriormente para realizar el diseo lgico
del sistema de informacin. Los especialistas en sistemas se refieren con frecuencia, a esta etapa
como diseo lgico en contraste con la etapa de desarrollo de software a la que denominan diseo
fsico.
El Analista disea procedimientos precisos para la captura de datos a fin de que los datos que van a
entrar al sistema sean correctos. Adems, el Analista tambin proporciona entrada efectiva para el
sistema de informacin mediante el uso de tcnicas para el buen diseo de formas y pantallas.
Parte del diseo del sistema de informacin es la interfaz de usuario. La interfaz conecta al usuario
con el sistema, es el puente de comunicacin y por lo tanto es extremadamente importante realizar
un buen diseo. Un ejemplo de interfaz de usuario incluye un teclado para introducir preguntas y
respuestas, mens en pantalla para elegir comandos del usuario y un ratn para seleccionar

13

opciones. Dentro de la fase de diseo se incluye el diseo de base de datos en la cual se guardar
la mayor parte de datos necesarios para los tomadores de decisiones de la empresa.
Una base de datos bien diseada da como resultado unos datos bien organizados, lo que constituye
el fundamento para todos los sistemas de informacin. En esta etapa el Analista tambin trabaja con
los usuarios para disear la salida de informacin de las bases de datos, estas pueden ser en
pantalla o impresas, segn como se satisfaga mejor las necesidades de informacin.
Por ltimo, el Analista debe disear procedimientos de control y respaldo para proteger el sistema y
los datos. Los documentos que contengan las especificaciones de diseo se representarn por
medio de diagramas de flujo, tablas, smbolos especiales, rboles, grficas, etc.
Los diseadores son los responsables de dar a los programadores, las especificaciones del sistema
de informacin completas y claramente delineadas. Una vez comenzada la fase de programacin,
los diseadores contestarn las preguntas y dudas que tengan los programadores, cuando utilicen
las especificaciones de diseo, por eso es recomendable que el diseo sea lo ms claro y preciso en
sus especificaciones.
2.1.11. Desarrollo de sistemas
En esta etapa el analista trabaja junto con el programador para desarrollar cualquier sistema que se
necesite esto se hace apoyndose en el diseo de sistemas.
Los programadores tienen un papel principal en esta etapa ya que son los encargados de la
codificacin de los mdulos correspondientes, as como tambin de la verificacin de sintaxis en el
cdigo para encontrar errores y resolverlos. El programador tambin valida cada uno de los mdulos
programados y realiza pruebas integrales a cada mdulo. Los programadores son responsables de
la documentacin del sistema, se encargan de elaborar el Manual del Usuario que le sirve a ste
para aprender a manejar el nuevo sistema y el Manual del Sistema en donde se incluye la

14

explicacin de la forma de programar los mdulos as como tambin todo lo concerniente a los
procedimientos empleados en la programacin de cada mdulo. Esta documentacin es de vital
importancia para probar el sistema y posteriormente para su mantenimiento.
2.1.12. Pruebas del sistema
Antes de implantar el sistema es necesario realizar pruebas para saber si funciona de acuerdo con
las especificaciones y en la forma en que los usuarios esperan que lo haga. Estas pruebas consisten
en hacer funcionar al sistema como si estuviera realizando sus operaciones cotidianas. Se
introducen entradas de conjunto de datos para su procesamiento y despus se examinan sus salidas
o resultados. Muchas veces se permite a los usuarios finales (aquellos usuarios que usarn el
sistema constantemente) utilizar el sistema como ellos lo usaran, sin limitarlos; es decir, dejarlos en
forma libre manejarlo a su antojo para as poder detectar fallas o errores no encontrados en el
proceso de desarrollo del sistema. Es conveniente que las pruebas sean realizadas por personas
ajenas al proyecto para que stas tengan validez, de lo contrario se comete el error de realizar
pruebas guiadas; es decir, hacer pruebas sabiendo de antemano los resultados de estos y no
obtener resultados favorables. Es difcil hacer pruebas al sistema y no encontrar ningn error, ya que
los errores nos ayudan a mejorar nuestros sistemas, si no tuviramos errores realmente no
sabramos si todo est bien.
2.1.13. Implantacin y evaluacin
La implantacin es el proceso de instalar y verificar un nuevo equipo, capacitar a los usuarios que
usarn el nuevo sistema de informacin. Se debe de hacer una conversin del viejo sistema al
nuevo, verificando que los usuarios no encuentren inconvenientes en el uso del nuevo sistema; esta
conversin incluye la de archivos de formatos antiguos a nuevos o simplemente la construccin de
una base de datos.

15

En ocasiones se propone usar los dos sistemas de informacin, el nuevo y el viejo con el objetivo de
comparar las mejoras del nuevo contra el viejo as como tambin que los usuarios se familiaricen
con el nuevo sistema en forma peridica, ya que pueden usar los dos sistemas y comparar cules
son las ventajas del nuevo sobre el viejo sistema de informacin.
Aparentemente, una vez terminada la etapa de implantacin y evaluacin del sistema de
informacin, solo queda brindar mantenimiento al sistema de informacin dado que los sistemas de
las empresas junto con el ambiente de las empresas experimentan cambios de manera continua y
constante. Los sistemas de informacin deben mantenerse siempre al da, en este sentido se puede
decir que la implantacin es un proceso de constante evolucin.

16

2.2. Teora de la Administracin de Proyectos.

2.2.1. Qu es un proyecto?
Segn el PMBOK (PMI, 2004):
Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o
resultado nico.
Los proyectos se desarrollan en cualquier nivel de la organizacin. Un proyecto puede involucrar a
una sola persona o a muchas y podran requerirse menos de cien horas para completarse o miles
de ellas. Y podra involucrarse a una sola unidad de una organizacin o cruzar muchas fronteras
organizacionales como en el caso de las corporaciones.
El trmino temporal se refiere a que cada proyecto tiene un inicio y una terminacin definitiva. El final
se alcanza cuando los objetivos del proyecto han sido completados, o cuando se reconoce que
todos los objetivos no pueden ser alcanzados y que el proyecto se debe terminar.
Temporal no significa necesariamente corto en duracin; muchos proyectos duran varios aos. El
trmino refiere ms a que la duracin del proyecto es finita, es decir, existe un inicio y un final.
Los proyectos estn relacionados con la creacin de algo que no se ha hecho antes, por lo tanto es
de caractersticas nicas. La presencia de repeticin de elementos no cambia la caracterstica
fundamental de ser nico.
2.2.2. Que es la direccin de proyectos?
Segn el PMBOK (PMI, 2004):
La direccin de proyectos es la aplicacin de conocimientos, habilidades, herramientas y
tcnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto.

17

La direccin de proyectos consiste en aplicar e integrar los procesos de direccin de proyectos de

inicio, planificacin, ejecucin, seguimiento y control, y cierre. El Director del Proyecto es el
responsable de lograr los objetivos del proyecto.
La direccin de un proyecto incluye:

Identificacin de los requisitos

Establecimiento de objetivos claros y posibles de alcanzar

Lograr el equilibrio entre la calidad, el alcance, el tiempo y los costos

Lograr la adaptacin entre las especificaciones, los planes y el enfoque de acuerdo a las
inquietudes y expectativas de las diferentes clases de interesados.
2.2.3. reas de conocimiento de la direccin de proyectos

La direccin de proyectos involucra 44 procesos, stos se han organizado en 9 grupos, y a los

mismos se les conoce como reas de Conocimiento. La presente investigacin cubrir 4 de estas
reas, sin embargo se describirn todas para tener un panorama ms global de la composicin de
un proyecto.
Gestin de la Integracin del Proyecto
Especifica los procesos y actividades que forman los elementos de la direccin de proyectos, que se
identifican, definen, combinan, unen y coordinan dentro de los Grupos de Procesos de Direccin de
Proyectos. Esta rea esta compuesta por los siguientes procesos:
Desarrollar el Acta de Constitucin del Proyecto, Desarrollar el Enunciado del Alcance del Proyecto
(Preliminar), Desarrollar el Plan de Gestin del Proyecto, Dirigir y Gestionar la Ejecucin del
Proyecto, Supervisar y Controlar el Trabajo del Proyecto, Control Integrado de Cambios y Cerrar
Proyecto.

18

Gestin del Alcance del Proyecto

Muestra los procesos necesarios para asegurar que el proyecto incluye todo el trabajo requerido, y
slo el trabajo requerido, para completar el proyecto en forma satisfactoria. Est compuesta por los
siguientes procesos:
Planificacin del Alcance, Definicin del Alcance, Crear EDT, Verificacin del Alcance y Control del
Alcance.
Gestin del Tiempo del Proyecto
Identifica los procesos relacionados con la puntualidad en la conclusin del proyecto. Se compone
de los siguientes procesos:
Definicin de las Actividades, Establecimiento de la Secuencia de las Actividades, Estimacin de
Recursos de las Actividades, Estimacin de la Duracin de las Actividades, Desarrollo del
Cronograma y Control del Cronograma.
Gestin de los Costos del Proyecto
Identifica los procesos relacionados con planificacin, estimacin, presupuesto y control de costos
de tal forma que el proyecto se complete dentro del presupuesto acordado. Se compone de los
siguientes procesos: Estimacin de Costes, Preparacin del Presupuesto de Costes y Control de
Costes.
Gestin de la Calidad del Proyecto
Identifica los procesos que aseguran que el proyecto cumple con los objetivos por los cuales se
inici. Se compone de los siguientes procesos:

19

Planificacin de Calidad, Realizar Aseguramiento de Calidad y Realizar Control de Calidad.

Gestin de los Recursos Humanos del Proyecto
Identifica los procesos que organizan y dirigen el equipo de trabajo del proyecto. Se compone de los
siguientes procesos:
Planificacin de los Recursos Humanos, Adquirir el Equipo del Proyecto, Desarrollar el Equipo del
Proyecto y Gestionar el Equipo del Proyecto.
Gestin de las Comunicaciones del Proyecto
Identifica los procesos relacionados con la creacin, recoleccin, distribucin, almacenamiento y
destino final de la informacin del proyecto en tiempo y forma.
Se compone de los siguientes procesos: Planificacin de las Comunicaciones, Distribucin de la
Informacin, Informar el Rendimiento y Gestionar a los Interesados.
Gestin de los Riesgos del Proyecto
Identifica los procesos que se relacionan con los riesgos de un proyecto. Describe los procesos
relacionados con el desarrollo de la gestin de riesgos de un proyecto. Se compone de los
siguientes procesos:
Planificacin de la Gestin de Riesgos, Identificacin de Riesgos, Anlisis Cualitativo de Riesgos,
Anlisis Cuantitativo de Riesgos, Planificacin de la Respuesta a los Riesgos, y Seguimiento y
Control de Riesgos.

20

Gestin de las Adquisiciones del Proyecto

Identifica los procesos relacionados con las compras o adquisicin de productos, servicios o
resultados, as como la contratacin de procesos de direccin. Se compone de los siguientes
procesos:
Planificar las Compras y Adquisiciones, Planificar la Contratacin, Solicitar Respuestas de
Vendedores, Seleccin de Vendedores, Administracin del Contrato y Cierre del Contrato.
A continuacin se hace un desarrollo ms amplio sobre las reas que se cubrirn en esta
investigacin:
2.2.4. Procesos y caractersticas de la Gestin del Alcance del proyecto
Es el rea del conocimiento que incluye los procesos requeridos para asegurarse que en el proyecto
se cubrir todo el trabajo requerido para completar el proyecto exitosamente. En la gestin del
alcance se define todo lo que se incluir en el proyecto, as como lo que no se incluir. Segn el
PMBOK (PMI, 2004) los procesos de la Gestin del Alcance son los siguientes:
2.2.4.1.

Planificacin del Alcance

Se cubren los tpicos necesarios para crear un plan de gestin del alcance del proyecto que muestre
cmo se definir, verificar y controlar el alcance del proyecto, as como los pasos necesarios para
la creacin de la Estructura de Desglose del Trabajo (EDT).
2.2.4.2.

Definicin del Alcance

Se desarrolla un enunciado en el que se define el alcance del proyecto detallado que servir como
base para las decisiones futuras del proyecto.

21

2.2.4.3.

Creacin de la WBS (EDT)

Descompone los productos entregables ms importantes

del proyecto en componentes ms

pequeos y ms fciles de manejar.

2.2.4.4.

Verificacin del Alcance

Se aceptan los productos entregables completados del proyecto de manera formal.

2.2.4.5.

Control del Alcance

Se gestionan los cambios en el alcance del proyecto. Estos procesos interaccionan entre s y
tambin con los procesos de las dems reas del Conocimiento. Dentro del contexto de proyectos,
el significado de alcance es el siguiente:

Alcance del producto.

Las caractersticas y funciones que identifican a un producto, servicio o resultado.

Alcance del proyecto.

Todo el trabajo que debe realizarse para crear y entregar un producto, servicio o resultado
con las funciones y caractersticas especificadas.

El enunciado del alcance del proyecto detallado y aprobado, y su EDT y el diccionario de la EDT
relacionados, forman la lnea base del alcance del proyecto
Normalmente en un proyecto se da como resultado un nico producto, pero el mismo puede tener
componentes secundarios, cada uno de ellos con su propio alcance del producto, separado pero
interdependiente.
Se requiere que la gestin del alcance del proyecto est bien integrada con los procesos de las
otras reas de Conocimiento, de tal forma que el trabajo final resulte en la entrega del alcance del
producto especificado.

22

2.2.5. Procesos y caractersticas de la Gestin del Tiempo del proyecto

La Gestin del Tiempo del Proyecto comprende los procesos necesarios para lograr que el proyecto
se complete a tiempo. Los procesos que incluye la Gestin del tiempo son los siguientes:
2.2.5.1.

Definicin de las Actividades

Se identifican las actividades especficas del plan de trabajo que se deben ejecutar para crear los
productos entregables del proyecto.
2.2.5.2.

Establecimiento de la Secuencia de las Actividades

Se muestran y se documentan las dependencias entre las actividades del plan de trabajo.
2.2.5.3.

Estimacin de Recursos de las Actividades

Establece el tipo y las cantidades de recursos necesarios para llevar a cabo cada actividad del plan
de trabajo.
2.2.5.4.

Estimacin de la Duracin de las Actividades

Se calcula la cantidad de tiempo necesario para completar cada actividad del cronograma.
2.2.5.5.

Desarrollo del Cronograma

Se analiza el orden en que se deben ejecutar las actividades, las duraciones, la necesidad de
recursos, las restricciones de tiempo que se tengan para crear el cronograma del proyecto.
2.2.5.6.

Control del Cronograma

Se controlan los cambios al plan de trabajo. El trabajo que se requiere para la ejecucin de los seis
procesos de Gestin del Tiempo del Proyecto est precedido por una planificacin previa de parte
del equipo de direccin del proyecto.

23

Esta tarea de planificacin es parte del proceso Desarrollar el Plan de Gestin del Proyecto, que
produce un plan de trabajo que determina el formato y establece los lineamientos para desarrollar y
controlar el cronograma de trabajo del proyecto.
El cronograma de trabajo est incluido en el plan de gestin del proyecto, o es un plan secundario
del mismo, y puede ser formal o informal, poco, o ampliamente detallado, dependiendo de las
necesidades del proyecto.
2.2.6. Procesos y caractersticas de la Gestin de los Riesgos del Proyecto
La Gestin de los Riesgos del Proyecto comprende los procesos relacionados con la planificacin
de la gestin de riesgos, la identificacin y el anlisis de riesgos, las respuestas a los riesgos, y el
seguimiento y control de riesgos de un proyecto.
Loa objetivos de esta gestin son aumentar la probabilidad y el impacto de los eventos positivos, y
disminuir la probabilidad y el impacto de los eventos negativos dentro del proyecto.
Los procesos de Gestin de los Riesgos del Proyecto son los siguientes:
2.2.6.1.

Planificacin de la Gestin de Riesgos

Se planifica la ejecucin de las actividades de gestin de riesgos para el proyecto.

2.2.6.2.

Identificacin de Riesgos

Se analizan los riesgos que pueden afectar al proyecto y se documentan sus caractersticas.
2.2.6.3.

Anlisis Cualitativo de Riesgos

Consiste en establecer la prioridad de los riesgos para realizar otros anlisis o acciones posteriores,
se trata de evaluar la probabilidad ocurrencia y su impacto.

24

2.2.6.4.

Anlisis Cuantitativo de Riesgos

Analiza matemticamente el efecto de los riesgos identificados dentro del plan del proyecto.
2.2.6.5.

Planificacin de la Respuesta a los Riesgos

Se evalan las opciones y acciones necesarias para mejorar las oportunidades y reducir las
amenazas a los objetivos del proyecto.
2.2.6.6.

Seguimiento y Control de Riesgos

Es el proceso que le da el seguimiento a los riesgos previamente identificados, adems supervisa

los riesgos residuales, e identifica los nuevos que podran aparecer, ejecuta planes de respuesta en
caso de que los riesgos se conviertan en realidad.
Un riesgo en un proyecto es un evento o condicin no predecible, que en caso de producirse tiene
un efecto positivo o negativo sobre al menos un objetivo del proyecto, y los objetivos estn
estrechamente relacionados con el tiempo, el costo, el alcance o la calidad.
Las condiciones de riesgo dentro del proyecto se pueden ver afectadas por prcticas deficientes de
direccin de proyectos, la falta de sistemas de gestin integrados, mltiples proyectos concurrentes
o por depender de participantes externos que no pueden ser controlados.
2.2.7. Procesos y caractersticas de la Gestin de la Calidad del Proyecto
En los procesos de Gestin de la Calidad del Proyecto se incluye todo lo necesario para que la
organizacin ejecutante determine las polticas, los objetivos y las responsabilidades concernientes a
la calidad, de modo que el proyecto satisfaga las necesidades por las cuales se estableci.
El sistema de gestin de calidad se implementa por medio de polticas, procedimientos y procesos
de planificacin de calidad, aseguramiento y control de calidad, con actividades de mejora continua
de los procesos que se realizan a lo largo de todo el proyecto

25

Los procesos de Gestin de la Calidad del Proyecto son los siguientes:

2.2.7.1.

Planificacin de Calidad

Consiste en Identificar las normas de calidad que son relevantes para el Proyecto y determina cmo
satisfacerlas.
2.2.7.2.

Realizar Aseguramiento de Calidad

Es la aplicacin de las actividades planificadas relacionadas con la calidad, que aseguran que el
proyecto utilice todos los procesos requeridos para cumplir con los requisitos del proyecto.
2.2.7.3.

Realizar Control de Calidad

Supervisa los resultados del proyecto, para detectar si se est cumpliendo con las normas de calidad
relevantes, e identifica mtodos para eliminar las causas de un rendimiento no satisfactorio.
El enfoque usado por el PMI (2004) en la gestin de calidad es compatible con la Organizacin
Internacional de Normalizacin (Internacional Organization for Standardization, ISO). El enfoque
tambin es compatible con enunciados de calidad propiedad exclusiva correspondientes a Deming,
Juran, Crosby y otros. Y tambin es compatible con enfoques que no son de propiedad exclusiva,
tales como Gestin de la Calidad Total (TQM), Six Sigma, Anlisis de Modos de Fallo y Efectos,
Revisiones del Diseo, Opinin del Cliente, Coste de la Calidad (COQ) y Mejora Continua.
La Gestin de la Calidad del Proyecto cubre tanto la gestin del proyecto como el producto del
proyecto. Mientras que la Gestin de la Calidad del Proyecto se aplica a todos los proyectos, sin
tomar en cuenta la naturaleza de su producto, las medidas y tcnicas de calidad del producto son
especficas del tipo de producto.
La calidad es el grado en el que un conjunto de caractersticas inherentes cumple con los requisitos
(PMI, 2004). La conversin de las necesidades, o expectativas en requisitos se hace por medio del
anlisis de los interesados, que se realiza durante la Gestin del Alcance del Proyecto.

26

Existe una diferencia entre la calidad y el grado. El grado es una categora asignada a productos o
servicios que tienen el mismo uso pero se les asignan diferentes caractersticas tcnicas.
No hay equivalencia entre precisin y exactitud. La precisin es la forma en que se agrupan valores
de mediciones repetidas y se obtiene poca dispersin.
La exactitud es la medida en que el valor obtenido est cercano al valor verdadero. Las mediciones
precisas no son necesariamente exactas. Es responsabilidad del equipo de direccin del proyecto
determinar qu grado de exactitud o precisin, o de ambas, se requiere.
La gestin de calidad actual complementa la direccin de proyectos. Ambas disciplinas reconocen la
importancia de:

Satisfaccin del cliente

Entender, evaluar, definir y gestionar las expectativas, de tal forma que se cumpla con los
requisitos del cliente, para esto se requiere que el proyecto produzca lo comprometido y
debe satisfacer las necesidades establecidas inicialmente.

La prevencin sobre la inspeccin

Los costos de prevenir errores son mucho menores que los costos de corregirlos cuando
estos se detectan por una inspeccin.

Responsabilidad de la direccin
Es necesario que sea la direccin quien proporcione los recursos necesarios para lograr el
xito.

27

Mejora continua
La base de la mejora continua es el ciclo planificar-hacer-revisar-actuar1. Los costos de la
calidad se refieren al costo total de todos los esfuerzos relacionados con la calidad. Ciertas
decisiones pueden causar un impacto sobre los costos operativos de calidad, por concepto
de devoluciones de productos, reclamos de garanta y de retiros de productos.

Segn la definicin de Shewhart, modificada por Deming, en el Manual de la ASQ, pginas 1314,
American Society for Quality, 1999.

28

3. MARCO METODOLGICO
3.1. Primer objetivo planteado
Crear instrumentos que le permitan a los Profesionales de Tecnologas de Informacin
identificar, cuantificar y documentar el trabajo necesario para el desarrollo e implementacin
de proyectos de desarrollo de Sistemas de Informacin
Este objetivo est relacionado con el rea de la gestin del alcance de la administracin de
proyectos del PMI.
Para lograr el objetivo planteado se har uso de plantillas que servirn para guiar el desarrollo de la
estructura detallada del trabajo (EDT o WBS). Las mismas se pueden encontrar en los anexos 5 y 6.
Adems se usar la tcnica de descomposicin que consiste en lo siguiente:
Subdivisin de los productos entregables de un proyecto en componentes ms pequeos y fciles
de manipular, hasta que el trabajo y los productos entregables se definan al nivel del paquete de
trabajo. El nivel del paquete de trabajo es el nivel ms bajo de la EDT y es el punto en el que el
costo y el plan de trabajo pueden estimarse de forma fiable. El nivel de detalle para los paquetes de
trabajo puede variar segn el tamao y la complejidad del proyecto.
Diferentes productos entregables pueden tener diferentes niveles de descomposicin. Para llegar a
un esfuerzo de trabajo fcil de manejar (es decir, un paquete de trabajo), para algunos productos
entregables el trabajo slo debe dividirse hasta el nivel siguiente, mientras que otros requieren
mayor nivel de descomposicin.
La descomposicin de todo el trabajo de un proyecto regularmente cubre las siguientes actividades:

Identificar los productos entregables y el trabajo correspondiente

29

Estructurar y organizar la EDT

Dividir los niveles superiores de la EDT en componentes ms detallados de nivel inferior

Verificar que el grado de descomposicin del trabajo es el necesario y el suficiente para

identificar los paquetes de trabajo.

El objetivo de la descomposicin consiste en lograr una separacin del trabajo hasta poder identificar
las actividades necesarias para obtener los paquetes de trabajo, en la figura 1 se muestra en forma
jerrquica la descomposicin correspondiente:

Figura 1: Estructura Detallada del Trabajo

30

3.2. Segundo objetivo planteado

Desarrollar procedimientos que le permitan al Profesional Informtico hacer uso de las
herramientas para la administracin del tiempo en el desarrollo de Sistemas de Informacin
Se har uso de las siguientes tcnicas:
3.2.1. Secuencia de actividades
Una de las tcnicas que se recomendarn utilizar ser el establecimiento de la secuencia de las
actividades que consiste en identificar y documentar las relaciones lgicas entre las actividades del
plan de trabajo. Las actividades del plan pueden estar ordenadas de forma lgica con relaciones de
precedencia adecuadas, as como tambin adelantos y atrasos, para respaldar el desarrollo
posterior de un plan de trabajo del proyecto realista y factible.
Un componente de mucha importancia que se recomendara en la metodologa propuesta es el
diagrama de red del proyecto, el cual ser parte del secuenciamiento de las actividades de un
Proyecto.
3.2.2. Estimacin de la duracin de las actividades
En el proceso Estimacin de la Duracin de las Actividades se requiere que se estime la cantidad
de esfuerzo de trabajo requerido para completar la actividad del plan de trabajo, que se estime la
cantidad prevista de recursos que se requiere aplicar para completar la actividad del cronograma y
que se determine la cantidad de perodos laborables requeridos para completar la actividad del plan
de trabajo.
Como tcnica para calcular la duracin de las actividades se har uso de la estimacin por tres
valores, o tcnica PERT que consiste en lo siguiente:

31

La exactitud de la estimacin de la duracin de la actividad puede afinarse teniendo en cuenta la

cantidad de riesgo de la estimacin original. La estimacin por tres valores consiste en determinar
tres tipos de estimaciones:

Ms probable. La duracin de la actividad del plan de trabajo, teniendo en cuenta los

recursos que sern asignados con certeza, su productividad, las expectativas realistas de
disponibilidad para la actividad del plan de trabajo, las dependencias de otros participantes y
las interrupciones.

Optimista. La duracin de la actividad se basa en el mejor escenario posible.

Pesimista. La duracin de la actividad se basa en el peor escenario posible. Se puede

obtener una estimacin de la duracin de la actividad utilizando un promedio de las tres
duraciones estimadas. Este promedio con frecuencia suministra una estimacin de la
duracin de la actividad ms precisa que la estimacin de valor nico.

El objetivo es desarrollar un anlisis cientfico como el que se muestra en el anexo 7, el cual muestra
el clculo de duracin de un proyecto haciendo uso de los tres tiempos posibles para cada actividad.
Otro instrumento que se utilizar en la metodologa propuesta ser el Cronograma del Proyecto, el
cual se podr crear despus de haber explicado el secuenciamiento de actividades, el diagrama de
red del proyecto y la necesidad de recursos dentro del proyecto.

32

3.3. Tercer objetivo planteado

Desarrollar

mtodos que le permitan al Profesional de Tecnologas de Informacin

protegerse ante la presencia de los riesgos tpicos del rea de Sistemas de Informacin
Este objetivo est relacionado con el rea de conocimiento de la gestin del riesgo del PMI (2004),
para lograrlo se har uso de las siguientes tcnicas:
El primer paso para cubrir este objetivo consistir en identificar los riesgos posibles que pueden
presentarse en un proyecto informtico. Como tcnicas para esta identificacin se proponen las
siguientes:
1. Tormenta de ideas.
2. Tcnica de diagramacin de causa y efecto.
3.3.1. Tormenta de ideas
Consiste en obtener una lista completa de los riesgos del proyecto. Para lograr esto se acostumbra
realizar tormentas de ideas, a menudo con un grupo multidisciplinario de expertos que no
pertenecen al equipo de trabajo.
Se obtienen ideas acerca de los riesgos del proyecto bajo el liderazgo de un coordinador. Los
riesgos luego son identificados y agrupados por tipo de riesgo y se reforman las definiciones.
3.3.2. Tcnica de diagramacin de causa y efecto
Se usa para identificar las causas raz de los problemas, y as tomar las acciones correctivas. Se
enfoca ms hacia las causas que a los sntomas.

33

Una vez identificados los riesgos se har uso de la tcnica del anlisis cualitativo de riesgos para
analizar el impacto de riesgos en el proyecto.
El Anlisis Cualitativo de Riesgos evala la prioridad de los riesgos identificados y usa la
probabilidad de ocurrencia, y el impacto correspondiente sobre los objetivos del proyecto si los
riesgos llegaran a ocurrir, as como otros factores como el plazo y la tolerancia al riesgo de las
restricciones del proyecto relacionados con los costos, cronograma, alcance y calidad.
El anlisis de probabilidad de los riesgos consiste en investigar la probabilidad de ocurrencia de
cada riesgo especfico. El anlisis del impacto de los riesgos investiga el posible efecto sobre un
objetivo del proyecto, como los son el tiempo, costo, alcance o calidad, incluidos tanto los efectos
negativos por las amenazas que implican, como los efectos positivos por las oportunidades que
generan.
Para lograrlo se usar una matriz de probabilidad e impacto que consiste en lo siguiente:
La evaluacin de la relevancia de cada riesgo y, por consiguiente, de su prioridad, regularmente se
realiza usando una matriz de probabilidad e impacto. Tal matriz especifica combinaciones de
probabilidad e impacto que llevan a la calificacin de los riesgos como de prioridad baja, moderada o
alta, pueden emplearse trminos descriptivos o valores numricos y en el anexo 8 se muestra una
plantilla que podr ser usada para crear la matriz. Un ejemplo de matriz a emplear es el siguiente:

34

Cuadro 1: Matriz de Probabilidad e Impacto

Despus de que se haya hecho el anlisis cualitativo se proceder a realizar un Anlisis Cuantitativo
que consistir en detectar las actividades que pueden causar ms impacto en el proyecto en caso
de haber algn tipo de atraso en su ejecucin. Los mtodos que se mostraran sern conceptos
basados en principios probabilsticas y matemticos y adems se mostrar el uso de herramientas
de Software en este tipo de anlisis.
Y por ltimo se explicar como reaccionar ante la presencia de riesgos por medio de un Plan de
Respuesta a los que se hayan identificado con los Anlisis Cualitativo y Cuantitativo.

35

3.4. Cuarto objetivo planteado

Desarrollar los procedimientos que deber seguir el profesional informtico para trabajar en
el desarrollo de sistemas bajo un entorno de Gestin de Calidad
Para lograr este objetivo se har uso de las siguientes tcnicas:
1. Definicin de procedimientos para el desarrollo de nuevos sistemas de informacin, o para el
mantenimiento de los que ya estn en produccin.
2. Definicin de instructivos de trabajo que

apoyen los procedimientos de desarrollo y

mantenimiento de sistemas.
3. Creacin de diagramas de flujo que permitan identificar grficamente el procedimiento de
desarrollo y mantenimiento de sistemas.
4. Creacin de los documentos que se debern usar para el desarrollo y mantenimiento de
sistemas de informacin.

3.5. Quinto objetivo planteado

Aplicar la metodologa propuesta en un proyecto piloto para validar su aplicacin
Para aplicar la metodologa propuesta se har uso de un sistema de informacin que se
implementar en la entidad encargada de supervisar los recursos destinados a las pensiones de los
costarricenses. Usando este proyecto se mostrarn los procedimientos propuestos para cubrir las
reas del Alcance, Tiempo, Riesgos y Gestin de la calidad en los proyectos de desarrollo de
software.

36

4. DESARROLLO
4.1. Seleccin del proyecto piloto
Para mostrar la aplicacin de la metodologa que se propone para integrar el desarrollo de sistemas
de informacin con estndares del Project Management Institute (PMI) se har uso de un proyecto
de la Superintendencia de Pensiones (SUPEN). El objetivo del proyecto es implementar un sistema
de informacin que permitir controlar la toma de decisiones relacionadas con los dineros de los
fondos de pensiones que se administran en las Operadoras de Pensiones.
El sistema de informacin se conoce como el Sistema de Actas Electrnicas y va a controlar la
creacin de las actas de los Comits de Inversiones de las Operadoras de Pensiones. Estas actas
se crearn en las Operadoras, pero el almacenamiento se har en una base de datos que estar
centralizada en la Superintendencia de Pensiones, esto permitir que cualquier decisin de las
operadoras se observe en lnea en la Superintendencia.
El motivo por el cual se seleccion este proyecto se debe a que el mismo es de impacto para la
Superintendencia de Pensiones, adems el producto a desarrollar aportar mucho valor para la
misin de la Superintendencia. Es por esto que se usar como plan piloto para el desarrollo de esta
metodologa, porque al ser un producto de valor para la organizacin los aportes que se puedan
transmitir haciendo uso de estndares del PMI sern analizados para proyectos futuros en la Supen,
es decir el uso de este proyecto como base para la metodologa servir como estrategia para
mercadear el beneficio del uso de estndares del PMI.
Adems para los lectores Informticos ser de mucho beneficio entender como los mtodos
expuestos en la Metodologa desarrollada se pueden aplicar a los Sistemas de Informacin que
son la base central de cualquier Departamento de Tecnologas de Informacin.

37

4.2. La gestin del alcance en el desarrollo de Sistemas de Informacin

Como paso inicial para incluir la gestin del alcance en los proyectos de software se deben detectar
los productos que se requieren entregar para cumplir con el proyecto, en el caso de los sistemas se
debern detectar productos como el sistema de informacin, manuales de usuario, manuales
tcnicos, planes de prueba, planes de capacitacin, planes de comunicaciones etc.
Para cada uno de estos productos que se deben entregar a lo largo del proyecto se debern
identificar las actividades que se requiere ejecutar para obtener los productos esperados, y luego se
debe continuar con esta descomposicin hasta encontrar un nivel de trabajo que se pueda costear y
asignar a una persona y permita medir el avance en el tiempo.
El objetivo de esta descomposicin es identificar todo el trabajo necesario para lograr un producto
entregable del proyecto. Esta descomposicin se puede agrupar en una plantilla de tal forma que se
muestre la relacin del trabajo y los entregables.
En el Sistema de Automatizacin de Actas que se est usando como proyecto piloto esta plantilla
quedara de la forma en que se muestra en el cuadro 2.

38

Cuadro 2: Descomposicin del trabajo a ejecutar

Desglose del trabajo a ejecutar

NOMBRE DEL
PROYECTO:
DIRECTOR DEL
PROYECTO:

Ing. Efran Gmez Quirs

PATROCINADOR:

Superintendente de Pensiones

Sistema de actas electrnicas

Entrega
Actividad
1. Sistema de
1.1 Analizar el Sistema Actual
informacin para
supervisar las Operadoras
de Pensiones

1.2 Disear el nuevo Sistema

Tarea/ Subtareas
Descripcin
1.1.1 Entrevistar usuarios Consiste en reunirse con los
involucrados que trabajan con
el procesamiento actual,
generalmente es manual y el
objetivo es conocer como
funciona el ambiente actual.
1.1.2 Definir los
El objetivo es documentar las
requerimientos
necesidades de informacin
para el nuevo sistema.
1.2.1 Analizar interfaces Detectar con que sistemas se
podra compartir informacin.
1.2.2 Analizar entradas y Detectar la forma en se
salidas
alimentar el sistema y como
desplegar la informacin.
1.2.3 Disear mdulos de Consiste en definir los
proceso
programas que se encargarn
de procesar la informacin.

Otro componente que se debe generar en los proyectos de software es la estructura detallada del
trabajo (EDT o WBS, siglas del idioma ingles). El objetivo de esta estructura es representar en forma
jerrquica todo el trabajo que se debe ejecutar para cumplir con los entregables. El trabajo que no
se incluye en la EDT queda fuera del alcance del proyecto, y por lo tanto no ser realizado.
La forma en que se debe desarrollar la EDT es representando a los productos entregables en un
nivel superior y luego determinar los elementos del nivel prximo inferior que lo componen. Luego
para cada elemento de nivel inferior se deben detectar los elementos que lo componen en otro nivel
inferior y continuar con este desglose hasta llegar a un nivel de detalle que permita estimar,
monitorear y controlar efectivamente.

39

Con respecto al proyecto piloto que se est usando como ejemplo en esta metodologa se muestra
una parte de la EDT que corresponde al producto entregable del Manual del Usuario, en el ejemplo
se observa el trabajo que habr que desarrollar y la jerarqua muestra actividades en dos niveles en
los cuales se puede notar la descomposicin de tareas y sub-tareas. En el anexo 9 se puede
observar toda la estructura detallada del trabajo correspondiente al proyecto de automatizacin de
actas electrnicas.

Figura 2: Estructura detallada del trabajo (EDT)

Otro componente que se recomienda usar en relacin con la gestin del alcance es el diccionario
de cada actividad de la Estructura Detallada de Trabajo (EDT), el objetivo es hacer una descripcin
detallada de todas las actividades que se definieron en la EDT, de tal forma que se conozca en que
consiste la actividad, los insumos que se requieren para llevarla a cabo y lo que se producir como
elemento de salida. Adems se establece el responsable de ejecutarla, y se puede aprovechar para
empezar a medir el tiempo y el costo de la actividad.
A continuacin se muestra la descripcin detallada de una de las actividades de la EDT
correspondiente al proyecto de actas. La actividad se describi como Analizar el Sistema Actual.

40

Cuadro 3: Diccionario de las actividades de la Estructura Detallada del Trabajo

Diccionario de cada actividad de la Estructura Detallada de Trabajo (EDT)
Informacin General de la actividad
Id:
2
EDT #:
Nombre de la actividad:
Analizar el Sistema Actual
Descripcin:
Entradas:
Salidas:
Responsable (s):

Consiste en entender como funciona el entorno actual, en el cual se desea implementar un

nuevo sistema automatizado. Adems se trata de documentar los requerimientos de los
usuarios para el nuevo sistema de informacin.
Documentos usados actualmente en el rea en que funcionar el nuevo sistema.
Documento desarrollado por el Ingeniero a cargo del desarrollo del sistema, el mismo tiene
el registro de las necesidades planteadas para el nuevo sistema.
Ingeniero a cargo del desarrollo del nuevo sistema
Estimaciones de la actividad

Duracin:

Costo Final:
1 mes

Fecha Inicio:

1.1

25 / 11 / 2003

$ 27540
Fecha Trmino:

06 / 01 / 2004

41

4.3. La gestin del tiempo en el desarrollo de Sistemas de Informacin

4.3.1. Creacin del diagrama de red
Una vez que se tiene bien definido y detallado el trabajo a realizar se debe proceder a establecer el
orden en que se van a ejecutar las actividades, a esta tcnica se le conoce como secuenciamiento
de las actividades. Es recomendable crear un diagrama de red el cual permita observar el orden de
precedencia lgico de las actividades. De acuerdo a Gido y Clements (2003), al decidir sobre el
orden en que se deben dibujar las actividades para que muestren su relacin de precedencia lgica
entre si, se deben plantear algunas preguntas con relacin a cada actividad individual:
1. Qu actividades se tienen que terminar inmediatamente antes de que se pueda iniciar la
siguiente?
2. Cules actividades se pueden hacer de manera simultnea?
3. Qu actividades no se pueden iniciar hasta que se termine la actual?
Contestndose a estas preguntas para cada actividad, se podr estar en posibilidad de dibujar un
diagrama de red que muestre las interrelaciones y el orden de las acciones necesarias para lograr el
alcance del trabajo del proyecto. La red es un mapa que muestra como se acoplan las actividades
para lograr el alcance del trabajo del proyecto. Un ejemplo del tipo de diagrama que se tiene que
obtener se muestra en la figura 3.

42

Figura 3: Diagrama de red de actividad en el nodo

El diagrama de la figura 6 corresponde a un tipo de red que se conoce como actividad en el nodo.
Adems de la tcnica expuesta existen otras que quedan fuera del alcance de esta investigacin y
que tambin sirven para desarrollar el diagrama de red. El motivo por el cual se escogi el de
actividad en el nodo se debe a que es el ms usado por los productos de software orientado a
administracin de proyectos, como es el caso del producto Microsoft Project.
El diagrama de red se puede construir usando algn tipo de software que permita establecer
relaciones entre un conjunto de tareas o actividades, como ejemplo para esta investigacin se us
un programa conocido como el Pert Chart Expert , este software permite interactuar con el Microsoft
Project.
En el caso del Sistema de Automatizacin de Acta se usar el paquete de software Pert Chart
Expert para crear el diagrama de red (secuenciamiento) usando la estructura detallada del trabajo
definida en la Gestin del Alcance. Una muestra del diagrama obtenido se observa en la siguiente

43

figura y en el anexo 10 encontrar el diagrama de red entero que se construyo para el sistema de
automatizacin de actas.

Figura 4: Diagrama de red del Sistema de Automatizacin de Actas

4.3.2. Estimacin del tiempo

Cuando se tenga la secuencia apropiada para ejecutar las actividades del proyecto se debe
proceder a calcular el tiempo necesario para ejecutar las actividades.
Como paso inicial para esto es imprescindible conocer bien la cantidad de recursos con que se
cuenta, tanto humanos, como de infraestructura. Si no se conocen los recursos disponibles no se
pueden hacer los clculos relacionados con la duracin de actividades (PMI, 2004).
En cualquier proyecto se debe conocer el equipo de trabajo con que se cuenta y el rol que cada uno
ejecuta. Se puede hacer uso de una descripcin de roles, o se podra utilizar una plantilla para
registrar lo anterior. En el ejemplo siguiente se muestra como se utilizaran ambos productos para el
Sistema de Automatizacin Actas, y en el anexo 11 se adjunta la plantilla para registrar las
responsabilidades del equipo de trabajo.

44

Automatizacin del Libro de Actas

Director del proyecto
Encargado del rea
de Automatizacin de
Oficinas
Director de la Divisin legal

Directora de la Divisin
de Operadoras

Abogada encargada de
la Normativa en
la Supen

Analistas de Operadoras

Encargado de Telecomunicaciones
de la Supen

Figura 5: Organizacin del equipo de trabajo para el Sistema de Automatizacin de Actas

La descripcin de las responsabilidades de cada miembro del equipo de trabajo en el proyecto de

Automatizacin de Actas quedara de la siguiente forma:
Director del Proyecto
Le corresponder la coordinacin de todas las actividades, y de las tareas relacionadas con el rea
de Informtica, adems ser su responsabilidad directa el anlisis de la informacin, el diseo del
nuevo sistema, la programacin del sistema y la implementacin del mismo.
Tambin ser el encargado de mantener comunicados en forma continua a todos los participantes
del proyecto. Le corresponder la creacin del manual del sistema y de la documentacin necesaria
para retroalimentar al equipo de trabajo con todos los trminos relacionados con un Sistema de
Computacin, y se encargar de preparar la capacitacin en el uso del nuevo sistema.
Se encargar tambin de coordinar todas las
telecomunicaciones.

45

tareas y actividades relacionadas con las

Equipo del proyecto

Se encargar de definir los requerimientos para el nuevo sistema, y adems de retroalimentar al
Ingeniero de Sistemas (Director del proyecto), de forma que los entregables que se vayan creando
correspondan directamente a las necesidades del funcionamiento del nuevo sistema.
Se encargar tambin de conseguir cualquier documentacin que el Director del Proyecto considere
necesaria para la ejecucin del proyecto.

Encargada de la Normativa
Se encargar de desarrollar las disposiciones legales que regularn el uso del nuevo sistema por
parte de las Operadoras de Pensiones.
Deber estudiar el manual del usuario creado por Informtica para que las disposiciones legales
correspondan directamente a los trminos que componen al nuevo sistema.
Y la plantilla para registrar las responsabilidades en el proyecto de Actas se usara de la forma en
que se muestra en el cuadro 4.

46

Cuadro 4: Responsabilidades de los miembros del equipo de trabajo

Teniendo el conocimiento del equipo de trabajo con que se cuenta se debe proceder a calcular la
duracin de las actividades. En esta etapa se pueden usar diferentes criterios, algunos de ellos son:

El Juicio de los expertos del rea en que se implementar el proyecto.

La experiencia del administrador del proyecto.

Registro de proyectos finalizados con semejanza al actual.

El criterio de los miembros del equipo.

Usando los criterios anteriores se debe proceder a establecer la duracin de las actividades del
proyecto, esta accin se puede ejecutar haciendo uso de algn software para apoyar el manejo de
proyectos, uno de los ms comunes en el Microsoft Project. Una de las grandes ventajas que agrega
este producto es que es capaz de identificar la ruta crtica del proyecto, esta es la ruta de
actividades ms larga del proyecto, y por lo tanto es la que requiere ms tiempo. Este tipo de
trabajo se puede hacer manualmente y consiste en encontrar las actividades que tienen la menor

47

holgura, entendindose por holgura la cantidad de tiempo que una actividad puede ser retrasada sin
afectar la fecha de terminacin del proyecto. A continuacin se muestra como el programa Microsoft
Project representa la ruta crtica de un proyecto:

Figura 6: Ruta Crtica del proyecto

En la imagen se puede observar una grfica de Gantt con dependencias entre las actividades que
componen el proyecto. Las actividades que estn marcadas con color rojo son las que pertenecen a
la ruta crtica del proyecto, y stas son las que mas hay que cuidar en cualquier proyecto de
cualquier naturaleza, porque como se explic anteriormente son las actividades que en caso de un
atraso provocan que se atrase todo el proyecto. Las actividades marcadas con azul no estn en la
ruta crtica, y por lo tanto tienen holgura para manejar algn tipo de atraso.

48

4.3.3. Tcnica Pert

Un aspecto importante en la etapa de gestin del tiempo es el efecto que crea la asignacin de
recursos al cronograma del proyecto, ya que esta accin puede alterar la ruta crtica debido a la
disponibilidad de los recursos. Este efecto provoca que la ruta crtica se convierta en la cadena
crtica, y la podemos definir como la alteracin de la ruta critica por el efecto de la asignacin de los
recursos al proyecto (PMI, 2004).
Cuando exista incertidumbre sobre la duracin de algunas actividades de la ruta crtica en el
proyecto se podr hacer uso de una tcnica que permite aplicar clculos probabilsticas para
estimar la duracin de las actividades. Este mtodo se basa en el uso de tres tipos de estimaciones:

Ms probable: Es aquel en que se completara con ms frecuencia una actividad en

particular en condiciones normales. Se hace el calculo de la duracin de las actividades
teniendo en cuenta los recursos que probablemente sern asignados, su productividad y las
expectativas realistas de disponibilidad en el proyecto

Optimista: Es el tiempo en que se puede completar una actividad en particular, si todo va

perfectamente y no hay complicaciones.

Se hace el clculo de la duracin de las

actividades basndose en el mejor escenario posible de lo que se describe en la estimacin

ms probable.

Pesimista: Es el tiempo en que se puede terminar una actividad en particular bajo

condiciones adversas, como la presencia de complicaciones inusuales o imprevistas. Se
hace el clculo de la duracin de las actividades basndose en el peor escenario posible de
lo que se describe en la estimacin ms probable.

El mtodo es conocido como la tcnica PERT (Tcnica de Evaluacin y Revisin de Programas) Y

debido a que establecen tres evaluaciones de tiempo hace posible tomar en cuenta la incertidumbre

49

a la hora de estimar cuanto durar una actividad, y tambin permite calcular la probabilidad de que
el proyecto se complete antes de la fecha estimada de finalizacin del proyecto. Para usar esta
tcnica se deber hacer uso de la siguiente formula:

Aplicando la formula se obtiene el

que corresponde al tiempo estimado de finalizacin de la

actividad (partiendo del hecho de que los tres tiempos mantienen un comportamiento de distribucin
Beta).

corresponden a los tres tiempos estimados para completar una actividad (ver

explicacin anterior).
Otro clculo que se deber efectuar es obtener la Varianza (de la distribucin beta) para cada
actividad en la que existe incertidumbre. Para obtener el clculo se deber aplicar la siguiente
formula:

= Varianza.
y

corresponden a los estimados pesimista y optimista.

Sumando los tiempos esperados de cada actividad y tambin sumando las varianzas de cada una
podremos encontrar el tiempo promedio para todo el proyecto y tambin la varianza para todo el
proyecto. Teniendo estos dos valores se procede a obtener la desviacin estndar usando la
siguiente formula:

50

De acuerdo a Clements y Gido (2003), la formula lo que indica es que la desviacin estndar
corresponde a la raz cuadrada de la suma de las varianzas de las actividades del proyecto.
Con el clculo de la desviacin estndar y el promedio de duracin del proyecto se podr saber que
tiempos de finalizacin corresponden a un 68% de probabilidad, cuales pertenecen a un 95% y
cuales pertenecen a un 99%. Esto se debe a tener relacin directa con la teora de la distribucin
normal. De acuerdo a esta teora se obtiene lo siguiente:

El 68% corresponde al tiempo promedio de duracin

+/- una desviacin estndar.

El 95% corresponde al tiempo promedio de duracin

+/- dos desviaciones estndar.

El 99% % corresponde al tiempo promedio de duracin

+/- tres desviaciones estndar.

A continuacin se muestra un ejemplo con estos clculos:

Cuadro 5: Uso de tiempos estimados y probabilidades

51

Se observa que en las columnas Te y VAR corresponde a los clculos del tiempo estimado y de la
varianza haciendo uso de las formula antes descritas. Tambin se observa las sumatorias de ambas
columnas y el valor DE corresponde a la desviacin estndar de la varianza. Analizando la
informacin anterior se puede deducir que el tiempo medio de duracin ser de 105 das y aplicando
la teora de la distribucin normal deducimos que existe un 68 % de terminar el proyecto entre 100 y
109 das, que existe un 95% de terminar entre 96 y 114 das y que existe un 99% de terminar entre
91 y 118 das.
Y por ultimo teniendo los datos anteriores (Tiempo estimado de duracin y la Desviacin estndar)
se podr armar una tabla como la siguiente en donde se obtienes las probabilidades de finalizar un
proyecto en el tiempo que se especifique en la tabla. Este clculo se hace por medio de la funcin de
Distribucin Normal que usa estos dos valores como parmetros y emite la probabilidad
correspondiente:

De la tabla anterior se deduce que para terminar el proyecto en 110 das se tiene un 86.12 % de
probabilidad de finalizacin en ese tiempo, mientras que para terminar en 90 das apenas se tiene
un 0.033% de probabilidad.

52

Seguidamente se muestra como se aplicara este conocimiento al proyecto de Automatizacin de

Actas:
Cuadro 6: Uso del Pert en el Proyecto de Automatizacin de Actas

Y la tabla de probabilidades quedara de esta forma:

53

De igual forma que en el ejemplo anterior, el anlisis seria el mismo, para finalizar el proyecto en 120
se tiene un 48.97% de probabilidad y para terminar el proyecto en 136 das se tiene un 99.89% de
probabilidad.
En el anexo 12 se muestra la implementacin completa del anlisis PERT en el proyecto de
Automatizacin de Actas.
En el momento en que se tenga claridad en la duracin de las actividades se puede proceder a crear
el cronograma de trabajo que consiste en establecer las fechas de comienzo y final de las
actividades a realizar. Esta labor se puede hacer manualmente o con ayuda de Software orientado a
control de proyectos, el programa mas conocido para estos propsitos es el Microsoft Project y el
trabajo a realizar consistir en asignar las fechas de inicio y final de las actividades que hay que
ejecutar.
Una ventaja que ofrece el Microsoft Project es que se conecta con otros programas que se han
mencionado en esta investigacin, como lo son el WBS Chart Pro y el Pert Chart Expert, esta
facilidad permite dedicarse a establecer las fechas sin tener que digitar los nombres de las
actividades, y tambin asocia las dependencias de las actividades que se establecieron en el
diagrama de red creado por medio del programa Pert Chart Expert.
Al tener las fechas de inicio y final se puede obtener una grafica Gantt, en la cual se muestra en
forma grafica el orden en el tiempo en que se ejecutarn las actividades del proyecto.
A Continuacin se presenta una muestra del cronograma que se usar en el proyecto de
Automatizacin de Actas.

54

Cuadro 7: Cronograma del Proyecto de Automatizacin de Actas

Y en el anexo 13 se muestra el cronograma completo del proyecto de Automatizacin de Actas.

55

4.4. La gestin del riesgo en el desarrollo de Sistemas de Informacin

4.4.1. Identificacin de riesgos

Otro aspecto muy importante que se debe vigilar en la creacin de un plan para un proyecto
informtico es el tema de los riesgos, el cual est relacionado con eventos que pueden afectar los
objetivos del proyecto en forma positiva, o negativa. Los efectos positivos se deben interpretar como
oportunidades que pueden aparecer en el momento en que se est ejecutando el proyecto y los
negativos estn relacionados con eventos que pueden afectar los objetivos del proyecto. Se debe
tener presente que los objetivos del proyecto estn relacionados con tres factores, que son: El
tiempo, el costo y el desempeo; y al referirse a un efecto negativo lo que significa es que algn
evento podra provocar atrasos en el tiempo, aumentos en los costos del proyecto, y disminucin de
la calidad de los productos del proyecto.
Para poder enfrentar los riesgos posibles de un proyecto hay que desarrollar un plan de riesgos el
cual se convertir en parte del plan de proyecto general. Para iniciar este plan el primer paso
consiste en identificar los riesgos posibles y la base para detectarlos ser la definicin del alcance
del proyecto, esto quiere decir que no se puede pensar en planificacin de riesgos si no se tiene
bien definido el alcance del proyecto. En la primera seccin de este capitulo de desarrollo se cubri
el tema del alcance del proyecto.
Analizando la definicin del alcance se podrn detectar riesgos posibles que estn relacionados con
las actividades, y/o productos entregables del proyecto. El anlisis se puede hacer usando diferentes
tcnicas, algunas de ellas son los siguientes:
4.4.1.1.

Tormenta de ideas

Se trata de que el equipo del proyecto genere ideas sobre los riesgos del proyecto, bajo la direccin
de un moderador. En esta tcnica no se debe hacer ninguna restriccin sobre las ideas que se
manifiesten en las reuniones del equipo. Posteriormente el equipo podr hacer un filtrado, pero en

56

acuerdo total de grupo, el objetivo es que al final de la reunin se obtenga una lista de riesgos
posibles (PMI, 2004).
4.4.1.2.

Tcnica Delphi

Se trata de buscar un consenso de expertos referente a los riesgos del proyecto. Ellos participan de
forma annima. Un moderador usa un cuestionario para que los expertos aporten sus ideas. Las
respuestas son resumidas y luego son enviadas nuevamente a los expertos para comentarios
adicionales. El consenso sobre los principales riesgos del proyecto se logra en pocas rondas del
proceso. Esta tcnica ayuda a reducir sesgos en los datos y evita que cualquier persona ejerza
influencias impropias en el resultado.
4.4.1.3.

Entrevistas

Se selecciona a los individuos apropiados (gerentes de proyectos experimentados, expertos,

participantes en negociaciones) y se les informa sobre el proyecto, se les proporciona informacin y
una lista de supuestos. Los entrevistados identifican los riesgos basados en sus experiencias.
4.4.1.4.

Revisin de los supuestos o hiptesis

Cada proyecto es concebido y planificado basado en un conjunto de hiptesis, escenarios,

suposiciones, premisas o creencias, que se consideran verdaderos, reales o ciertos, sin necesidad
de contar con evidencia o demostracin, por lo tanto es recomendable medir riesgos posibles que
podra presentarse en relacin con los supuestos o hiptesis.
4.4.1.5.

Diagramas de causa y efecto

Estos diagramas tambin se conocen como diagramas de Ishikawa o de espina de pescado, y son
tiles para identificar las causas de los riesgos. Para poder desarrollarlo se debe crear un eje

57

horizontal y luego se trazan flechas que apuntan al eje horizontal con un ngulo de inclinacin con
respecto al eje central. Cada una de estas flechas sern categoras de riesgos que pueden afectar al
proyecto, y luego para cada categora se desglosan los eventos que se consideren posibles causas
de riesgos. En la siguiente figura se muestra un ejemplo de este tipo de diagrama usado para
identificar riesgos:

Figura 7: Diagrama de causa y efecto.

Es conveniente que despus de la identificacin de riesgos dentro del proyecto se haga una
agrupacin de tal forma que se puedan crear categoras en donde se pueda representar en forma
jerrquica una estructura que desglose los riesgos posibles del proyecto. Esta estructura se conoce
como RBS (Estructura de desglose del riesgo) y en la siguiente pgina se muestra un ejemplo.

58

Figura 8: Estructura de desglose del riesgo

4.4.2. Prioridad de los Riesgos

Una vez que se hayan identificado los riesgos posibles, que posiblemente sern una gran cantidad
se debe pensar en cuales deben recibir la mayor atencin, evidentemente los riesgos que deben
recibir la mayor atencin son los que tendran tanto el mayor impacto sobre los resultados del
proyecto como la mayor probabilidad de ocurrencia. Para poder evaluar el impacto sobre el proyecto
se hace uso de una tcnica que se conoce como el Anlisis Cualitativo de Riesgos

y se

complementa con otra que se conoce como Anlisis Cuantitativo de Riesgos. Seguidamente se
explican en que consisten ambos y como usarlos.

4.4.3. Anlisis Cualitativo de Riesgos

El anlisis cualitativo de riesgos consiste en aplicar dos valores a cada uno de los riesgos
identificados, el primero corresponde a la probabilidad de que ocurra el riesgo en una escala de 0 a
1 y el segundo equivale al impacto que causara la ocurrencia del evento de riesgo, tambin se usa
la escala de 0 a 1. Luego se obtiene el producto de ambos valores y dependiendo del valor obtenido

59

se ubicar al riesgo como Alto, Moderado o Bajo. La escala que se podr usar para esta
clasificacin ser la siguiente:
De 0 a 0.04 Bajo
De 0.05 a 0.14 Moderado
0.15 a 1 Alto
Para poder hacer el anlisis cualitativo de riesgos se deben registrar los riesgos y se recomienda
trabajar con una hoja electrnica con al menos las siguientes columnas:
4.4.3.1.

Cdigo identificador del riesgo

El cdigo de identificacin permite trabajar de forma estandarizada y ser incluido en una base de
datos de riesgos. Este podra tener, por ejemplo, la estructura RX999, donde 999 es un consecutivo
y la X es la categora del Riesgo:
RA- Riesgo de Administracin de Proyectos
RE- Riesgo Externo
RO- Riesgo Organizacional
RT- Riesgo Tcnico
4.4.3.2.

Causa

Las causas se podrn tomar de la RBS (Estructura de desglose del riesgo) y se relacionan con las
categoras de riesgos previamente analizadas (PMI, 2004).
Evento o condicin del riesgo: El evento que causa el riesgo.
Consecuencia o descripcin: Descripcin del riesgo.

60

Relacin o dependencia con otro riesgo: En el caso que aplique se indica el cdigo de otro riesgo
que est relacionado con el actual, a continuacin se muestra un ejemplo:
Cdigo

Causa

Evento

Descripcin del
riesgo

RE001

Presencia de asbesto

Enfermedades del personal

Atraso en el

producto de la presencia de

calendario por

asbesto

incapacidades.

Una vez que se tiene el Registro de Riesgos con el detalle de todos los riesgos identificados, se
procede a ordenarlos segn un criterio de prioridad, para luego enfocarse en los ms importantes.
El criterio que se utiliza en este tipo de anlisis es por rango o calificacin y para obtenerlo se debe
ubicar la probabilidad y el impacto en las escalas respectivas usando el criterio de un equipo de
gestin de riesgos que podr ser el mismo que trabaj en la identificacin de riesgos. Las escalas a
utilizar se deben especificar en el apartado de gestin de riesgos del plan del proyecto general y con
ellas se crea la matriz PxI. A manera de ejemplo se podrn usar las siguientes escalas:
Cuadro 8: Probabilidad de ocurrencia del Riesgo
Muy Probable

0.9

Bastante Probable

0.7

Probable

0.5

Poco Probable

0.3

Improbable

0.1

Cuadro 9: Impacto si ocurre el Riesgo

Muy Alto

0.8

Alto

0.4

Moderado

0.2

Bajo

0.1

Muy Bajo

0.05

61

Para ubicar el impacto de cada riesgo en la escala se podran utilizar los siguientes criterios:
Cuadro 10: Descripcin del impacto segn la escala
Objetivo del Muy Bajo

Bajo

Moderado

Alto

Muy Alto

proyecto

0.05

0.1

0.2

0.4

0.8

Costo

Insignificante

Incremento del Incremento del

Incremento del

Incremento del

Incremento del

costo < 5%

costo entre el

costo entre el 10 costo

5 10%

20%

> 20%

costo
Tiempo

Alcance

Insignificante

Variacin del

Desviacin

Desviacin

Desviacin

variacin del

calendario

general del

general del

general del

calendario

< 5%

proyecto

proyecto

proyecto

5 10%

10 20%

20 30%

Reduccin del

El producto final

Reduccin del

reas

reas mayores

alcance apenas

menores del

del alcance son alcance

perceptible

alcance son

afectadas

afectadas
Calidad

del proyecto es

inaceptable para inservible

el cliente

Degradacin de

Solo

La reduccin de Reduccin de la El producto final

la calidad

aplicaciones

la calidad

calidad

apenas

muy

demanda la

inaceptable para inservible

perceptible

especificas

aprobacin del

el cliente

son afectadas

cliente

del proyecto es

Combinando las escalas de la probabilidad y el impacto se obtiene la matriz PxI que se muestra en
la siguiente pgina.

62

Cuadro 11: Marcadores de riesgo

Impacto

Muy Bajo

Bajo

Moderado Alto

Muy Alto

0.05

0.1

0.2

0.4

0.8

0.9

0.05

0.09

0.18

0.36

0.72

0.7

0.04

0.07

0.14

0.28

0.56

0.5

0.03

0.05

0.10

0.20

0.40

0.3

0.02

0.03

0.06

0.12

0.24

0.1

0.01

0.01

0.02

0.04

0.08

Probabilidad

Teniendo los productos PxI se debe establecer un rango para declarar cuales riesgos son de
prioridad Alta, Moderada o Baja. Para efectos de ejemplo se usarn los siguientes:
Alto:

0.18- 0.99

Moderado: 0.05 0.17

Bajo:

0.01 0.04

Una vez que se han establecido las escalas anteriores se contina con la creacin de la hoja
electrnica en donde se documentar el anlisis cualitativo. Se le deben agregar las siguientes
columnas:
4.4.3.3.

Probabilidad

Para cada riesgo, utilizando la escala de probabilidad se le asigna el valor correspondiente.

4.4.3.4.

Impacto

Para cada riesgo, utilizando la escala de impacto se le asigna el valor correspondiente.

63

4.4.3.5.

Rango (PxI)

Es el producto de la multiplicacin de la Probabilidad por el Impacto (PxI). A cada riesgo (fila en la

hoja de clculo) se le puede asignar un color (Rojo, Amarillo o verde) segn su rango de calificacin
usando los rangos de Alto, Moderado o Bajo descritos anteriormente y luego se ordena la lista
usando la columna Rango en forma descendente. Con lo anterior se obtiene la lista de riesgos
priorizados. Calculando el promedio general de la columna Rango (PxI) se podr encontrar la
calificacin del riesgo general del proyecto.
En el caso del Sistema de Automatizacin de Actas el resultado del anlisis cualitativo se muestra en
el siguiente cuadro:
Cuadro 12: Anlisis cualitativo del sistema de automatizacin de actas

64

4.4.4. Anlisis Cuantitativo de Riesgos

Una vez que se tiene el anlisis cualitativo se puede usar el anlisis cuantitativo de riesgos para
obtener ms informacin sobre las tareas que presentan mayor prioridad de atencin por presentar
riesgos ms altos.

El proceso de anlisis cuantitativo ayuda a analizar numricamente la

probabilidad de los riesgos priorizados y sus consecuencias en los objetivos del proyecto, as como
el grado de riesgo general del proyecto. Como resultado de este tipo de anlisis se puede obtener lo
siguiente:

Evaluacin de la probabilidad de alcanzar un objetivo especifico del proyecto.

Cuantificar los posibles resultados del proyecto y sus probabilidades.

Identificar los riesgos que requieren la mayor atencin cuantificando sus contribuciones
relativas al riesgo del proyecto.

Identificar objetivos de costo, tiempo y alcance, realistas y alcanzables.

Determinar la mejor decisin de direccin de proyectos cuando algunas condiciones o

resultados son inciertos.

Existen diferentes tcnicas que se pueden usar para realizar un anlisis cuantitativo, algunas de
ellas son:
1. Enfoque PERT
2. Anlisis mediante un rbol de decisiones
3. Simulacin Montecarlo

65

4.4.4.1.

Enfoque PERT

En la seccin de gestin del tiempo se estudi esta tcnica y se encontr que es posible determinar
la probabilidad de concluir el proyecto a tiempo. Para calcular la probabilidad de cumplimiento con el
calendario programado, solo se toman en cuenta las tareas pertenecientes a la ruta crtica, las
cuales fijan la fecha de terminacin del proyecto. Los clculos que se hacen con la tcnica PERT
requieren de tres valores de tiempo, los valores optimistas, los ms probables y los pesimistas.
Estos valores se pueden obtener consultando expertos o por medio de los miembros del equipo de
trabajo.
Teniendo los tres valores se calcula el tiempo promedio de duracin de cada actividad y tambin es
posible obtener la desviacin estndar del tiempo promedio. Usando la distribucin normal como
distribucin de probabilidades es posible calcular la probabilidad de finalizar el proyecto para un
perodo determinado.
Esta tcnica puede ayudar a obtener diferentes escenarios del proyecto haciendo anlisis con las
actividades que manifiestan mayor probabilidad de riesgo en el anlisis cualitativo. Con los
resultados que se obtengan del anlisis PERT se tendr ms criterio para planificar las respuestas a
los riesgos.
4.4.4.2.

Anlisis del Valor Monetario Esperado (EVM)

Es un concepto estadstico que calcula el resultado promedio cuando el futuro incluye escenarios
que pueden ocurrir o no (es decir, anlisis con incertidumbre). El valor monetario esperado de las
oportunidades generalmente se expresar con valores positivos, mientras que el de los riesgos ser
negativo. El EVM equivale al producto del valor de cada posible resultado (impacto) por su
probabilidad de ocurrencia y en el caso de tener varios valores se suman los resultados. Esta
tcnica se recomienda para usarse como reservas de contingencia en riesgos de poco impacto.
A continuacin se muestra un ejemplo:

66

Cuadro 13: Aplicacin del Anlisis del Valor Monetario Esperado

Evento de Riesgo
1
2
3
4
Totales

4.4.4.3.

Impacto $
5.500
2.800
10.750
825
19.875

Prob. %
20%
10%
15%
70%

VME
1.100
420
1.613
578
3.710

Anlisis mediante rbol de decisiones

Un rbol de decisiones es un diagrama que describe una decisin bajo las consideraciones e
implicaciones de la seleccin de una u otra alternativa. Las ramas del rbol representan las
probabilidades de los riesgos y los beneficios netos (costos o premios) y utilizando el valor esperado
de cada rama del rbol podemos tomar la decisin correcta. El valor esperado corresponde al valor
de cada posible resultado por su probabilidad de ocurrencia. La forma en que se debe construir es la
siguiente:
Se dibuja un recuadro en la parte izquierda para representar cul es la decisin que se necesita
tomar. (Los recuadros representan decisiones). Al final de cada lnea se debe estimar cul puede ser
el resultado, Si el resultado es incierto, se puede dibujar un pequeo crculo (nodo de posibilidad o
chance). Si el resultado es otra decisin que necesita ser tomada, se debe dibujar otro recuadro
(nodo de decisin). Si se completa la solucin al final de la lnea, se puede dejar en blanco.
Desde los crculos se deben dibujar lneas que representen las posibles consecuencias. Tambin se
debe hacer una pequea inscripcin sobre las lneas que digan qu significan y la probabilidad de
cada resultado. Por ltimo asignamos un costo o puntaje a cada posible resultado. En la figura 9 se
presenta un ejemplo.

67

Figura 9: Ejemplo de un rbol de decisiones

4.4.4.4.

Evaluacin del rbol de decisiones

El anlisis se comienza de derecha a izquierda. Calculando el valor monetario esperado (EVM) de

los nodos de incertidumbre. El EVM es el producto del valor de cada posible resultado por su
probabilidad de ocurrencia y se suman los resultados. Cuando se evalan los nodos de decisin, se
debe calcular el costo total basado en los valores de los resultados que ya se han calculado. Este
clculo dar un valor que representa el beneficio de tal decisin. Cuando ya se haya calculado el
valor de estas decisiones, se debe elegir la opcin que tiene el beneficio ms importante como la
decisin tomada.
4.4.4.5.

Simulacin Monte Carlo

Esta tcnica repite el cronograma del proyecto muchas veces utilizando valores de datos iniciales
seleccionados al azar a partir de distribuciones de probabilidades de duraciones posibles para
calcular una distribucin estadstica de las fechas de conclusin posibles.
Para implementar esta tcnica es necesario el uso de algn software de computadora orientado a
este tipo de anlisis, la cantidad de operaciones y de repeticiones no se podran ejecutar

68

manualmente y es necesario el uso de herramientas de software para este tipo de anlisis. Algunos
de los productos actuales que se pueden usar en este anlisis son: @Risk, Monte Carlo, Risk Track,
Risk Pro, Crystall Ball etc.
4.4.4.5.1.

Pasos bsicos del Mtodo Monte Carlo

1. Se definen las variables de entrada y las de salida.

2. Se determina cules entradas en el modelo son inciertas, y se representan usando rangos de
valores con funciones de distribucin de la probabilidad.
3. Se corre la simulacin con el nmero de iteraciones que sea necesario (100 - 1000) para
determinar el rango y probabilidades de todas las salidas.
4. Se analizan los resultados y se toman decisiones.
En el proyecto de Automatizacin del Libro de Actas se utiliz el software @Risk para ejecutar el
anlisis cuantitativo. Una caracterstica que tiene el Software escogido es que se interfasa con el
Microsoft Project y las actividades que se ejecutan se hacen directamente en el Project, el cual se
encarga de hacer llamados al @Risk para los clculos probalsticos. La forma en que se implement
este anlisis fue la siguiente:
Primero se seleccionaron actividades que se relacionan con los eventos de riesgo de mayor
prioridad de atencin, estas actividades se pueden definir como actividades con incertidumbre, pues
son las que podran causar impactos en el proyecto. Luego se establecieron tres valores para las
fechas de inicio y la duracin de cada una de las actividades seleccionadas.
Estos tres valores se usaron como entrada a dos funciones de distribucin probabilstica que usa el
@Risk como instrumentos de trabajo, una funcin es la funcin Triangular y la otra es la distribucin

69

Uniforme. Estas dos funciones tienen principios comunes a los explicados en el clculo del tiempo
estimado de la tcnica PERT que usando tres valores pueden emitir un valor promedio que resulta
til en anlisis donde haya incertidumbre.
En el siguiente cuadro se muestran las actividades escogidas y los tres valores de fecha y duracin
que se le dieron al @Risk para que hiciera los clculos de iteracin:
Cuadro 14: Actividades con incertidumbre y sus tres tiempos

Con los tres valores que se le dieron al @Risk se configur el Software para que hiciera una corrida
de 100 repeticiones con las funciones probabilsticas escogidas, en estas repeticiones el software
utiliza los tres valores para hacer posibles combinaciones en cada una de las corridas sin salirse de
los rangos establecidos. Estas combinaciones permiten que

se manifiesten las tcnicas

probabilsticas que nos dicen que despus de muchas repeticiones de un evento se pueden hacer
predicciones, y el @Risk utiliza estos principios matemticos para emitir sus resultados. Una
muestra de los resultados de estas 100 repeticiones para dos de las actividades seleccionadas se
observa en cuadro 15.

70

Cuadro 15: Repeticiones con tres valores

Despus de que se ejecutan las 100 repeticiones se obtiene informacin de las actividades
evaluadas, as como de todo el proyecto. La informacin emitida se basa en tres valores: Un mnimo,
un promedio, y un mximo, esto como producto de las 100 repeticiones. La informacin resultante
del anlisis se muestra en el cuadro 16.

71

Cuadro 16: Resultado del anlisis de las 100 repeticiones

Con la informacin anterior se puede ajustar el tiempo de proyecto y las fechas de las actividades en
una forma ms cientfica, por ejemplo si se observa la parte superior del cuadro anterior se podr
notar que el anlisis est emitiendo fechas posibles de finalizacin y tiempo posible de finalizacin
del proyecto con fundamentos matemticos.
Un grfico de mucho valor que se puede obtener en este tipo de anlisis es el grfico de Tornado, en
l se muestran las actividades de mayor impacto en el proyecto. Estas actividades estarn en la ruta
crtica y son las que hay que ponerles mayor atencin durante el proyecto. En la figura 10 se
muestra el grfico de Tornado para el anlisis practicado en el proyecto de Automatizacin de Actas;
se puede notar que la actividad de mayor impacto es Documentar y diagramar el nuevo sistema.

72

Figura 10: Grafico de Tornado del proyecto de automatizacin de Actas

4.4.5. Planificacin de la respuesta a los riesgos

Una vez que se hayan identificado los riesgos, analizado sus probabilidades y sus magnitudes, y se
hayan priorizado, es el momento de preparar las acciones para responder ante ellos. La planeacin
de la Respuesta a los Riesgos es el proceso de desarrollar procedimientos y acciones para mejorar
las oportunidades y reducir las amenazas a los objetivos del proyecto. Las respuestas a los riesgos
se planifican en funcin de la prioridad de estos, incorporando recursos y actividades en el
presupuesto, cronograma y en el plan de gestin del proyecto, segn sea necesario. Esto implica
hacer variaciones en el alcance, lo cual provoca cambios en los parmetros base del proyecto (PMI,
2004).
Se debe utilizar para cada riesgo la estrategia o combinacin de estrategias adecuada (efectiva) y
desarrollar acciones especficas para implementar dicha estrategia. Es de buena prctica
seleccionar estrategias de apoyo o refuerzo a la estrategia primaria, y/o un plan de reserva, que ser
implantado si la estrategia seleccionada no resulta ser totalmente efectiva.

73

Como reaccin a la presencia de riesgos se pueden seguir estrategias diferentes para enfrentarlos,
algunas de ellas son:
4.4.5.1.

Evitar el riesgo

Consiste en Cambiar el Plan del Proyecto para eliminar la amenaza que representa el riesgo
adverso, as proteger los objetivos del proyecto de sus impactos o relajar el objetivo que est en
peligro (ampliando el cronograma o reduciendo el alcance, por ejemplo). Usualmente el riesgo se
anula eliminando la causa, reduciendo la probabilidad de prdida a cero.
4.4.5.2.

Explotar la oportunidad

La estrategia explotar la oportunidad, trata de eliminar la incertidumbre de la oportunidad identificada

(riesgo positivo), haciendo que sta se concrete. Si se hace la comparacin, explotar es el
equivalente positivo de evitar, sta ltima utilizada para los riesgos negativos. En ambos casos se
quita la incertidumbre; en la de evitar la probabilidad se hace cero y en la de explotar la probabilidad
se hace uno (100%).
4.4.5.3.

Transferir el riesgo

Se trata de trasladar el impacto negativo (o parte) de una amenaza a un tercero conjuntamente con
la propiedad de la respuesta. Al transferir el riesgo a un tercero se le da la responsabilidad para su
administracin, pero no significa que se elimina el riesgo, normalmente se debe pagar una prima a
quien se le transfiere la responsabilidad el riesgo. Ejemplos de estas transferencias son los seguros,
las garantas, y los contratos.

74

4.4.5.4.

Mitigar el riesgo

No todos los riesgos se pueden eliminar, ni transferir, por lo que otro tipo de estrategia de la
respuesta apunta a modificar el "tamao" del riesgo para hacerlo ms aceptable. Mitigar la amenaza
implica reducir la probabilidad de ocurrencia y/o consecuencias a un umbral aceptable. Existen
mtodos diferentes que se pueden emplear para mitigar el riesgo, algunos de ellos son:
A. Mitigacin mediante separacin
La separacin es dividir los bienes o las operaciones en unidades separadas, se utiliza para reducir
la dependencia en algo o alguien, tiende a hacer que las prdidas individuales sean ms pequeas
y predecibles, un ejemplo es la divisin de un proyecto en varias fases.
B. Mitigacin mediante duplicidad
La duplicidad involucra una reproduccin completa de los bienes u operaciones para mantenerlos en
reserva. El duplicado no se utiliza a menos que el original se dae (o viceversa). Se utiliza en riesgos
que de suceder sern catastrficos. Como ejemplo de esta estrategia se pueden usar los respaldos
de una base de datos, o de Software.
C. Mitigacin mediante elementos redundantes
No es una duplicidad completa del elemento, sino que se disea otra variante, por si el original falla.
Se trata de reducir el impacto de riesgos tcnicos, algunos ejemplos son la puesta en paralelo de un
sistema automatizado y los servidores redundantes.
4.4.5.5.

Aceptar el riesgo

La estrategia aceptar es comn tanto para las amenazas como para las oportunidades, el equipo
del proyecto decide no modificar el plan de gestin del proyecto para hacer frente a un riesgo
(positivo o negativo), o porque no se ha identificado ninguna otra estrategia de respuesta adecuada
para el mismo.

75

Una forma activa de aceptar el riesgo consiste en establecer una reserva para contingencias, que
incluya la cantidad de tiempo, dinero o recursos necesarios para manejar las amenazas o las
oportunidades conocidas, o incluso tambin las posibles desconocidas. (Implica actuar como un
asegurador, con aplicacin de tcnicas de control de riesgos, financiamiento de prdidas y
tratamiento de reclamaciones).
Una forma simple de crear una reserva para contingencias en el caso de aceptar riesgos es la que
se muestra en el siguiente cuadro:
Cuadro 17: Clculo de reserva para contingencias

Descripcin del
Probabilidad de
Evento de Riesgo
Ocurrencia
Evento No.1
Prob. P1
Evento No.2
Prob. P2
Evento No.3
Prob. P3
Evento No.n
Prob. Pn
Contingencia Estimada del Proyecto (Pi x Ci)

Costo Estimado
De Consecuencias
Costo C1
Costo C2
Costo C3
Costo Cn

Exposicin al
Riesgo
P1xC1
P2xC2
P3xC3
PnxCn

En el cuadro se pueden observar los eventos de riesgo que pueden presentarse en el proyecto, y
para cada uno de estos se le establece una probabilidad, adems se hace un clculo estimado de
los costos relacionados con las consecuencias en que se puede incurrir en caso de que se cumpla
el riesgo. Con esos dos valores se obtiene su producto y ste ser un monto que se utilizar como
contingencia en caso de que se cumplan los riesgos que se aceptan. Este tipo de estrategia debera
de usarse solo en eventos que en el caso de cumplirse no sean catastrficos para el proyecto.
Se debe tener presente que los costos se debern tratar como un componente ms del plan del
proyecto. En esta investigacin esta rea no ser cubierta, sin embargo se aclara que los costos
representan uno de los componentes ms importantes del proyecto.

76

Volviendo al proyecto de Automatizacin del Libro de Actas las acciones que se tomarn como
respuesta a los riesgos que se detectaron se muestran en el cuadro 18.

Cuadro 18: Respuesta a los riesgos en el Proyecto de Automatizacin de Actas

Como se puede apreciar en el cuadro algunos riesgos se aceptaron y por este motivo se cre un
plan de contingencias haciendo uso de la explicacin anterior, en donde se indic la necesidad de
establecer una frecuencia y un costo. El resultado de este anlisis en el proyecto de Actas se
observa en el cuadro 19.

77

Cuadro 19: Plan de Contingencias en el Proyecto de Automatizacin de Actas

Total ($)

Con las respuestas anteriores se debe volver a revisar la definicin del alcance y del tiempo, porque
al haberse incluido ms actividades en el proyecto causa que haya que volver a revisar la cantidad
de trabajo que requiere el proyecto, y por lo tanto habr que mostrarlos en la WBS, en el
cronograma y en la distribucin de recursos.
En el caso del proyecto de Actas se crearon las siguientes actividades adicionales, las cuales
tambin se incluyeron en la WBS y en el cronograma del proyecto. Ambos productos se muestran
en los anexos 14 y 15.

Implementar prototipos y exponerlos a pruebas de estrs.

Contratar experto en redes.

Compra de servidor redundante.

Contratar asesor legal externo.

Contratar asesor de definicin de requerimientos.

78

4.5. La gestin de calidad en los proyectos de desarrollo de Sistemas de

Informacin
4.5.1. Repaso de los principales conceptos tericos
Haciendo una revisin de los conceptos tericos ms importantes de la gestin de calidad tenemos
lo siguiente:
La Gestin de Calidad incluye todas las actividades relacionadas con polticas, objetivos y
responsabilidades de modo tal que el proyecto satisfaga las necesidades por las cuales se ejecut.
La Gestin de Calidad se implementa a travs de polticas, procedimientos y los procesos de
Planificacin de Calidad, aseguramiento de la calidad y control de calidad, con actividades de mejora
continua de los procesos que se deben realizar durante todo el proyecto, segn corresponda. Los
procesos de la Gestin de Calidad incluyen lo siguiente:
Planificacin de Calidad: Identifica qu normas de calidad son relevantes para el proyecto y
determina cmo satisfacerlas.
Aseguramiento de Calidad: Aplica las actividades planificadas relativas a la calidad para asegurar
que el proyecto utiliza todos los procesos necesarios para cumplir con los requisitos planificados.
Control de Calidad: Supervisa los resultados especficos del proyecto, para determinar si se cumple
con las normas de calidad relevantes e identificar modos de eliminar las causas de un rendimiento
insatisfactorio (PMI, 2004).
4.5.2. Necesidad de usar los procesos de calidad en los proyectos de sistemas
Como recomendacin para tener xito en los proyectos de desarrollo de sistemas se presentan las
siguientes herramientas que estarn relacionadas con el proceso de Planificacin de la Calidad. El
Aseguramiento y el Control de la Calidad slo se podrn poner en prctica hasta que se implemente
el proyecto, por lo tanto en esta investigacin se brindarn instrumentos relacionados con la
Planificacin de Calidad que permitirn que los proyectos de desarrollo de sistemas se puedan

79

implementar bajo un entorno de calidad, y por consecuencia estarn las bases para los procesos de
Aseguramiento y Control de la Calidad.
En el desarrollo de sistemas se manifiestan problemas que inician desde el momento en que se
concibe la idea del proyecto, la informacin no se trasmite en forma clara y los cambios y malestares
que esto genera aumentan considerablemente los costos y el tiempo de cada uno de los proyectos.
Una forma de reducir este tipo de problemas es creando estndares que regulen la informacin
desde el inicio hasta la implementacin de los sistemas.
El problema nace desde el inicio del proyecto cuando los creadores de los sistemas de informacin
no entienden cules son las necesidades del cliente y por lo tanto a lo largo del proceso sern
incapaces de satisfacerlas. Los proyectos atienden a especificaciones que no responden a las
necesidades mnimas del cliente y entran en estados fluctuantes
constantes que afectan tanto los recursos materiales

provocados por cambios

como humanos, generando fracasos

frecuentes en los procesos de Administracin del Proyecto y en los Productos del Proyecto.
Lo que se propone en este captulo es desarrollar un estndar de Calidad que permita ordenar y
controlar el desarrollo de sistemas, de tal forma que se cumpla con el objetivo de la Administracin
de Calidad, que consiste en asegurar que el proyecto satisfaga las necesidades para las cuales
inici, identificar los estndares de calidad relevantes al proyecto y determinar cmo satisfacer
dichos estndares (Chamoun, 2002).
El estndar propuesto consiste en un procedimiento para el desarrollo de sistemas, compuesto por
pasos que se debern seguir durante el desarrollo, as como por formularios que se debern usar
en conjunto con el procedimiento, y por instrucciones de trabajo que servirn para detallar como
hacer las cosas. Adems se adjunta un diagrama de flujo para representar grficamente el
procedimiento recomendado.

80

Este procedimiento ser parte de la Gestin de Calidad que se requiere en todo proyecto de
desarrollo de sistemas, de tal forma que se pueda tener garanta de que los productos entregables
satisfacen los requerimientos iniciales.
Los formularios que se usarn servirn para el aseguramiento de la calidad, puesto que una vez
que se ponga en marcha la implementacin del proyecto se convertirn en registros, los cuales se
podrn revisar para ejecutar el Aseguramiento de la Calidad, y si se detectan malas prcticas, o
problemas en el proyecto se podrn hacer los ajustes necesarios para alinearlo. Con lo anterior se
estar ejecutando el

proceso de Control de Calidad y adems, se estar trabajando bajo un

ambiente de mejora continua, el cual es el ciclo actual con que se trabaja en la Gestin de la
Calidad. A continuacin se expone el procedimiento:
4.5.3. Procedimiento recomendado para gestionar la calidad en el proyecto
Para poder ejecutar el procedimiento recomendado es necesario usar una serie de formularios y
ejecutar un instructivo de trabajo, el cual permite conocer el detalle de cmo realizar ciertas acciones
especficas que requiere el procedimiento. A continuacin se identifican los componentes que se
utilizarn, as como el procedimiento y ms adelante se ampliar ms sobre el contenido de los
componentes.
4.5.3.1.

Formularios utilizados

FO-01

Solicitud de un nuevo sistema

FO-02

Bitcora de problemas encontrados

FO-03

Solicitud de cambios

FO-04

Informe del avance del proyecto

FO-05

Aceptacin del producto o servicio

FO-06

Informe de lecciones aprendidas

FO-07

Requerimientos del sistema

81

4.5.3.2.
IT-01

Instructivo relacionado
Desarrollo de Sistemas

4.5.3.3.

Descripcin de Participantes

Usuario = Persona que solicita el desarrollo de un nuevo Sistema de Informacin.

Jefe de T.I. = Funcionario a cargo del Departamento de Tecnologas de Informacin.
Ingeniero de Sistemas = Funcionario del Departamento de Tecnologas de Informacin encargado
de desarrollar el Software o servir como contraparte en caso de contratacin externa.
Jefe del Usuario = Superior directo de la persona que solicita el Sistema de Informacin
Procedimiento para la solicitud de un Nuevo Sistema
RESPONSABLE

PASO

DESCRIPCIN

USUARIO

Completa el formulario FO-01 Solicitud de un nuevo

Sistema y establece los requerimientos del sistema (FO-07
Requerimientos del Sistema) apoyado por el Ingeniero de
Sistemas, y los enva al Jefe de T.I.

JEFE DE T.I.

Recibe los formularios FO-01 Solicitud de un nuevo

Sistema y FO-07 Requerimientos del Sistema. Determina
si el proyecto se realizar con personal externo
(contratacin) o interno.

82

RESPONSABLE

PASO

DESCRIPCIN
SI ES POR CONTRATACIN EXTERNA

INGENIERO

DE 1

SISTEMAS

Analiza, investiga y elabora los trminos de referencia para

el desarrollo del proyecto y lo remite al JEFE DE T.I. para
su anlisis y discusin.

JEFE DE T.I.

Recibe los trminos de referencia para el desarrollo del

proyecto, lo analiza y discute con el INGENIERO DE
SISTEMAS, solicita los cambios que considere necesarios
usando el formulario FO-03 Solicitud de cambios y una
vez incorporados lo aprueba.

JEFE DE T.I.

Recibe los trminos de referencia aprobados para el

desarrollo del proyecto e inicia el proceso de contratacin,
usando el procedimiento IT-02 seleccin y valoracin de
proveedores.

INGENIERO

DE 4

SISTEMAS
INGENIERO

Coordina con la empresa adjudicataria una reunin para

analizar y discutir el alcance del proyecto.

DE 5

SISTEMAS

Analiza y discute en conjunto con el JEFE DE T.I. y la

empresa adjudicataria el Alcance del Proyecto y los
productos esperados, as como las etapas a desarrollar
para su consecucin.

INGENIERO

DE 6

Establecen los medios de control para ir valorando el

83

RESPONSABLE
SISTEMAS

PASO

EL

DESCRIPCIN
avance del proyecto y usan el formulario FO-04 Informe de
Avance del Proyecto para dar seguimiento a las diferentes

JEFE DE T.I.

etapas de la ejecucin del proyecto por parte de la Empresa

Adjudicataria.
INGENIERO DE

SISTEMAS

Recibe de la Empresa Adjudicataria, los informes o

productos esperados del proyecto, junto con la nota de
aceptacin del usuario (FO-05 Aceptacin de Producto o
Servicio) e informa al JEFE DE T.I.

JEFE DE T.I.

Comunica

la disponibilidad del sistema desarrollado y

coordina con el JEFE DEL USUARIO que requiere de dicho

sistema la respectiva capacitacin instructivo IT-03

autoriza la Instalacin del Sistema.

FIN DE CONTRATACION EXTERNA
SI NO ES CONTRATACIN EXTERNA
INGENIERO DE
SISTEMAS

Recibe la solicitud de desarrollo de nuevo sistema

(Formulario FO-01),

Convoca a una reunin al usuario,

analizan y discuten los requerimientos del proyecto con

base en los formularios Solicitud de un nuevo sistema
FO-01 y los Requerimientos del Sistema FO-07. Define
las responsabilidades que tendr cada miembro del equipo
de trabajo e inicia el instructivo IT-01
Sistemas.

84

Desarrollo de

RESPONSABLE
INGENIERO DE

PASO
2

SISTEMAS

DESCRIPCIN
Confecciona peridicamente el Informe de Avance del
Proyecto, formulario FO-04 y lo remite al JEFE DE T.I.
para su aprobacin. Se debe utilizar en todo el proceso el
formulario FO-02 Bitcora de Problemas encontrados,
para llevar documentados los problemas que se le
presenten.

JEFE DE T.I.

Recibe el Informe de Avance del Proyecto, lo analiza y

discute con el INGENIERO DE SISTEMAS y le indica las
medidas correctivas para su implementacin usando el
formulario FO-03 Solicitud de cambios.

JEFE DE T.I.

Recibe la nota de aceptacin del sistema por parte del

usuario (FO-05 Aceptacin de Producto o Servicio) y
comunica, la disponibilidad del sistema desarrollado.
Coordina con el Jefe del Usuario, para que inicie la
respectiva capacitacin. Autoriza la instalacin del sistema.

INGENIERO DE

SISTEMAS

Prepara un informe con todos los problemas encontrados en

el proyecto (FO-06 Informe de lecciones aprendidas).
Estos problemas sern tomados en cuenta en los siguientes
proyectos como lecciones aprendidas.

INGENIERO EN
SISTEMAS

Asigna el equipo que se va usar con el sistema, hace

pruebas del sistema.

85

RESPONSABLE
INGENIERO DE
SISTEMAS

PASO
7

DESCRIPCIN
Prepara el ambiente informtico donde va a ser instalado el
sistema, crea y otorga permisos de acceso a las bases de
datos y a la red. Hace las depuraciones correspondientes de
los datos e incorpora los programas ejecutables en el rea
correspondiente.
FIN DEL PROCEDIMIENTO

4.5.3.4.

Uso del diagrama de flujo

Un elemento adicional que se puede usar para apoyar la claridad del estndar del Calidad planteado
para el desarrollo de sistemas consiste en un diagrama de flujo que representa grficamente la
secuencia establecida en el procedimiento anterior. Esta herramienta permite percibir algn tipo de
error que exista en el procedimiento y que textualmente sea ms difcil detectar. En la figura 11 se
presenta el diagrama de flujo que equivale al procedimiento anterior.

86

Figura 11: Flujo del desarrollo de sistemas

87

4.5.3.5.

Uso de formularios

El formulario correspondiente a la solicitud de un nuevo sistema tendr el siguiente formato:

Estandarizacin del Proceso de Desarrollo
de Sistemas
Pagina 1de 1

Solicitud de un Nuevo Sistema

FO-01

Fecha de
aprobacin:

Espacio para ser llenado por el Usuario

Gestor del Proyecto:

Nombre de la persona que ide el proyecto ( usuario )

Definicin del Problema:

Defina el problema

Antecedentes:

Digite los antecedentes del problema

Objetivos
Digite el objetivo general del Problema

Objetivo General

Objetivos especficos
1. Digite un objetivo especifco
2.
3.
4.
5.

Digite un objetivo especifco

Digite un objetivo especifco
Digite un objetivo especifco
Digite un objetivo especifco

Factores crticos del xito:

Digite los factores que puedan atentar contra el exito del

proyecto.

Productos o Servicios:

Indique los productos o servicios esperados

Beneficios:
Usuario Responsable:

Digite los beneficios que se esperan obtener

Digite nombre del usuario responsable del proyecto

Restricciones y supuestos:
Digite Restricciones o supuestos
Observaciones o comentarios adicionales:
Digite observaciones o comentarios adicionales
Figura 12: Solicitud de un Nuevo Sistema

Y el formulario correspondiente a la Bitcora de Problemas Encontrados tendr el formato que se

presenta en la figura 13.

88

Bitcora de PROBLEMAS ENCONTRADOS EN UN PROYECTO

(FORMULARIO FO-02)
PROYECTO: ____________________________________________

FECHA

PROBLEMA

SOLUCION

Fecha: ______________
__________________________
Nombre del Responsable

____________________
Firma

Figura 13: Bitcora de problemas encontrados

El resto de documentos que usa el procedimiento recomendado se pueden encontrar en el anexo

16.

89

4.5.3.6.

Instructivo de Trabajo

El instructivo de trabajo IT-01 estara compuesto por los siguientes pasos:

Estandarizacin del Proceso de Desarrollo

de Sistemas
Pagina 1 de 2

RESPONSABLE

Fecha de aprobacin:
Instructivo Desarrollo de Sistemas
IT-01
PASO
DESCRIPCIN

INGENIERO DE
SISTEMAS

Convoca a una reunin al usuario y analiza y discute ms a

fondo con l el sistema a desarrollar, as como los
requerimientos del mismo. (FO-08 Requerimientos del
Sistema)

INGENIERO DE
SISTEMAS

Elabora un diagrama de flujo del sistema, si fuese

necesario y lo somete a aprobacin del usuario e incorpora
nuevos requerimientos de ste. Una vez aprobado el
diagrama de flujo por el usuario elabora la descripcin de
los procesos que el sistema realiza (Diccionario de Datos).

INGENIERO DE
SISTEMAS

Genera el documento de Anlisis del Sistema (hechos,

observaciones y requerimientos discutidos en las reuniones),
anota las observaciones o cambios que considere necesario
y procede a incorporarlos.

INGENIERO DE
SISTEMAS

Transforma lo establecido en el anlisis del sistema, en

estructuras de datos que puedan ser implementadas en un
lenguaje de programacin, elabora el modelo de entidad de
relacin y procede a desarrollar el Script de la base de datos.

INGENIERO DE
SISTEMAS

Elabora la programacin en un lenguaje computacional

apropiado segn sea el sistema, disea las pantallas, as
como el cdigo de validacin de datos. Elabora la lgica de la
programacin y realiza las pruebas de analistas con la
finalidad de comprobar el buen funcionamiento del sistema.

USUARIO

Elabora los escenarios de pruebas para aplicarlos en el

90

Estandarizacin del Proceso de Desarrollo

de Sistemas
Pagina 1 de 2

RESPONSABLE

Fecha de aprobacin:
Instructivo Desarrollo de Sistemas
IT-01
PASO
DESCRIPCIN

ambiente de pruebas, en el cual se evalan datos validos as

como datos errneos para analizar los resultados y con stos
la funcionalidad del sistema.
INGENIERO DE
SISTEMAS

Revisa en conjunto con el usuario los escenarios de pruebas

definidos y los documenta.

USUARIO

Aplica los escenarios de pruebas previamente definidos y

revisados.

INGENIERO DE
SISTEMAS

Elabora en conjunto con el usuario un anlisis de los

resultados de las pruebas con el fin de detectar los posibles
errores que el sistema pueda tener.

INGENIERO DE
SISTEMAS

10

Corrige los errores detectados en las pruebas y lo remite al

usuario.

USUARIO

11

Completa el formulario de aceptacin (FO-06 Aceptacin de

Producto o Servicio) y lo remite al Ingeniero de Sistemas.

INGENIERO DE
SISTEMAS

12

Desarrolla el Manual del Usuario y el Manual del Sistema. Se

debe utilizar en todo el proceso el formulario FO-02 Bitcora
de Problemas encontrados, para llevar documentados los
problemas que se le presenten.

INGENIERO DE
SISTEMAS

13

Efecta las modificaciones necesarias a la base de datos del

ambiente de produccin.

INGENIERO DE
SISTEMAS

14

Hace el pase del nuevo sistema al ambiente de produccin.

FIN DEL INSTRUCTIVO

91

Con las herramientas anteriores se pretende minimizar los problemas de comunicacin y adems se
intenta eliminar el desconocimiento que existe alrededor de las actividades informticas. Estos
detalles crean insatisfaccin entre los stakeholders que interactan en el desarrollo de sistemas, y
es probable que si se implementa el estndar recomendado se aprovecharn mejor los recursos
humanos y materiales, logrando una mejor eficiencia y eficacia en los proyectos de desarrollo de
sistemas.
En el desarrollo del Proyecto de Automatizacin de Actas Electrnicas este ser el estndar que se
usar para la implementacin del proyecto.

92

4.6. Gua de uso de la Metodologa propuesta

A continuacin se muestra en forma grafica como se debera de usar la metodologa propuesta en
los captulos anteriores relacionados con proyectos de desarrollo de sistemas. La forma en que se
dar la explicacin ser haciendo uso de diagramas de bloque que muestren los componentes que
se deben usar para cada una de las reas que se cubrieron en los captulos anteriores
En el diagrama siguiente se muestra en forma general la metodologa propuesta, la idea es
representar a nivel de bloque como se relacionan las reas que se incluyeron en este desarrollo y
posteriormente se hace un desglose de cada uno de los bloques.

Estudio de
Prefactibilidad

WBS

GESTION DEL
ALCANCE

GESTION DEL
TIEMPO

WBS y Otros
Componentes

Cronograma y
Otros
Componentes

GESTION DEL
RIESGO

GESTION DE
CALIDAD

Anlisis Cualitativo

Anlisis
Cuantitativo

Plan de Respuesta
a los Riesgos y
otros
Componentes

Figura 14: Diagrama general de la Metodologa

93

Procedimiento
Estndar de
Calidad

Formularios

Otros
Componentes

4.6.1. Gestin del Alcance

Figura 15: Gua de uso de la metodologa en la Gestin del Alcance.

Para trabajar en la Gestin del alcance de un proyecto es necesario conocer acerca de los productos
entregables que el proyecto tendr que generar. Para el caso de un proyecto de Desarrollo de
Sistemas se estara hablando de productos como reportes, pantallas, manuales, paginas de Internet,
Interfaces etc. Estos productos tendrn que haberse detectado en alguna fase de prefactibilidad que
debe anteceder a la planeacin del proyecto.
En el esquema relacionado con la Gestin del Alcance se pueden observar los productos que se
debern obtener despus de descomponer los productos entregables en actividades que permitan
establecer los costos, el tiempo y asignar un responsable. Se debern obtener 3 productos, los
cuales son:
A. Plantilla con el Diccionario de la Estructura Detallada del Trabajo (EDT).

94

B. Plantilla con el Desglose del Trabajo a realizar.

C. Estructura Detallada del trabajo (EDT o WBS).
Muestras de todos los productos de entrada y salida de esta fase del proyecto se encuentran en la
seccin de anexos de esta investigacin y en el capitulo de desarrollo correspondiente al Alcance.
4.6.2. Gestin del Tiempo

Estructura Detallada
del Trabajo (WBS)

Tcnica Pert

Estructura del
Equipo de Trabajo

Plantilla:
Responsabilidades del
Equipo de Trabajo

Software de Adm.
De Proyectos

GESTION DEL TIEMPO

Diagrama de Red del

Proyecto

Cronograma del
Proyecto

Organizacin del
equipo de Trabajo

Figura 16: Gua de uso de la metodologa en la Gestin del Tiempo

De acuerdo a la figura 16 de la Gestin del Tiempo se observa que la WBS que se obtuvo como
producto de salida de la Gestin del Alcance se usa como elemento de entrada en la Gestin del
Tiempo para calcular la duracin de las actividades y la secuencia en que se har el trabajo,
adems se debern establecer los responsables de hacer el trabajo. Para lograr lo anterior es
necesario conocer quienes componen el Equipo de Trabajo del proyecto y la estructura
correspondiente, es importante tambin contar con la Plantilla de Responsabilidades del Equipo del
Trabajo. Como instrumentos de trabajo para calcular los tiempos de duracin se pueden usar la
Tcnica Pert y Software de Administracin de Proyectos, en este desarrollo se utiliz el Microsoft
Project y el Pert Chart Expert.

95

Como productos de salida de esta etapa se tendrn el Cronograma de Proyecto y el Diagrama de la

Red del Proyecto.
Muestras de todos los productos de entrada y salida de esta fase del proyecto se encuentran en la
seccin de anexos de esta investigacin y en el capitulo de desarrollo correspondiente al Tiempo.
4.6.3. Gestin del Riesgo

Figura 17: Gua de uso de la metodologa en la Gestin del Riesgo

Mirando la figura 17 de la Gestin del Riesgo vemos que la Estructura Detallada del Trabajo (WBS)
funciona como un elemento de entrada al proceso planteado para enfrentar los riesgos posibles del
Proyecto. Se debe recordar que la WBS es un producto generado en la Gestin del Alcance.

96

Analizando la WBS se podr obtener un detalle de los riesgos detectados haciendo uso de las
tcnicas que se recomendaron en el capitulo relacionado con los riesgos (Tormenta de Ideas,
Delphi, Entrevistas, Causa y Efecto etc.).
Con la WBS y el detalle de riesgos detectados se podrn obtener elementos como: Una Estructura
de Desglose de Riesgos y una Hoja Electrnica con los Riesgos identificados. Con estos dos
productos se podr crear el Anlisis Cualitativo de Riesgos y para hacerlo se har uso de dos
Escalas: La Escala de Probabilidad de que ocurra el Riesgo y la Escala del Impacto al Proyecto en
caso de que ocurra el riesgo.
Con el Anlisis Cualitativo se podrn usar otras herramientas para hacer un anlisis ms matemtico
del comportamiento del proyecto, a esto se le conoce como Anlisis Cuantitativo de Riesgos en el
Proyecto y consiste en usar tcnicas como: El Anlisis Pert, rbol de Decisiones, Anlisis del Valor
Monetario Esperado y la Simulacin Montecarlo (entre otros) para detectar el comportamiento en
actividades que manifiestan algn tipo de incertidumbre.
Con los resultados del Anlisis Cuantitativo se podrn identificar las actividades de mayor impacto
en el proyecto y con esto se podr crear un plan de respuesta a los riesgos, y este consistir en
hacer cambios en el alcance y en el cronograma del proyecto, adems se puede crear un plan de
contingencias para atender los riesgos que no se pudieron eliminar y siguen existiendo en potencia.
Muestras de todos los productos de entrada y salida de esta fase del proyecto se encuentran en la
seccin de anexos de esta investigacin y en el capitulo de desarrollo correspondiente al Riesgo.

97

4.6.4. Gestin de la Calidad

Diagrama de
Flujo

Instrucciones
de trabajo

PROCEDIMIENTO
ESTANDAR DE
CALIDAD

Bitcora de
Problemas
Encontrados
FO-02

Rol de
Participantes

Gestin de la Calidad

Solicitud de
un Sistema
Nuevo
FO-01

Solicitud de
Cambios
FO-03

Informe de
lecciones
aprendidas
FO-06

Informe de
avance del
Proyecto
FO-04

Aceptacin
del Producto
o Servicio
FO-05

Requerimientos
del Sistema
FO-07

Figura 18: Gua de uso de la metodologa en la Gestin de la Calidad

En la figura 18 de la Gestin de la Calidad vemos que para obtener el Estndar de Calidad de un

proyecto (en este caso un procedimiento de trabajo) es necesario contar con una serie de
documentos que sirvan como elementos de entrada al proceso de la Gestin de la Calidad, para el
Estndar propuesto se requieren seis formularios (FO-01, FO-02, FO-03, FO-05, FO-06 y FO-08), un
Instructivo de Trabajo y es necesario conocer las personas que participan y el rol que ejecutan.
Con los elementos anteriores se desarroll un procedimiento en el que se establece en forma
secuencial como se deben hacer las cosas, en que orden y cules sern los insumos que se
necesitan para hacer el trabajo y cules sern los productos que se debern obtener.
Como elementos de salida de este proceso tenemos el procedimiento Estndar que se deber usar
y un diagrama de flujo del procedimiento que
procedimiento.

98

muestra grficamente como se ejecuta el

Muestras de todos los productos de entrada y salida de esta fase del proyecto se encuentran en la
seccin de anexos de esta investigacin y en el capitulo de desarrollo correspondiente al la Calidad.
A continuacin se presenta un resumen de los productos entregables que se deben generar en cada
una de las etapas de cubiertas en la metodologa.
Cuadro 20: Detalle de Productos Entregables de la Metodologa

rea

Productos Entregables

Gestin del Alcance

Plantilla del Diccionario de la WBS

Plantilla de Desglose del Trabajo a Realizar
Estructura Detallada del Trabajo (WBS)

Gestin del Tiempo

Diagrama de Red del Proyecto

Cronograma del Proyecto
Organizacin del Equipo de Trabajo del Proyecto

Gestin del Riesgo

Estructura de Desglose del Riesgo

Hoja Electrnica con Riesgos Identificados
Grfico de Tornado
Actividades de Mayor Impacto en el Proyecto
Cambios en el Cronograma
Plan de Respuesta a los Riesgos
Hoja Electrnica con Anlisis Cualitativo
Plan de Contingencias
Escala de Probabilidad del Riesgo
Cambios en el Alcance del Proyecto
Escala de Impacto de los Riesgos
Anlisis del Valor Monetario Esperado
Tcnica Pert
rbol de Decisiones
Simulacin Montecarlo

Gestin de la Calidad

Diagrama de Flujo equivalente al Procedimiento

Desarrollado
Procedimiento Estndar de Calidad
Instrucciones de Trabajo
Bitcora de Problemas Encontrados FO-02
Rol de Participantes

99

rea

Productos Entregables
Solicitud de un Nuevo Sistema FO-01
Solicitud de Cambios FO-03
Informe de Lecciones Aprendidas FO-06
Informe del Avance del Proyecto FO-04
Aceptacin del Producto o Servicio FO-05
Requerimientos del Sistema FO-07

100

5. Conclusiones
5.1. Despus de haber desarrollado los captulos anteriores relacionados con la Gestin del
Alcance, el Tiempo, el Riesgo y la Calidad se puede confirmar que se han cumplido los
objetivos iniciales, puesto que para cada rea de conocimiento de las planteadas en esta
tesina se encontr una forma de relacionar el desarrollo de Proyectos de Sistemas de
Informacin con las reas del conocimiento del PMI.
5.2. El trabajo se desarroll buscando un mtodo que le permita a un Profesional de Informtica
interactuar con otras actividades que no son comunes en el rea de desarrollo de sistemas.
Sin embargo, la metodologa empleada trat de usar guas que ubiquen al Informtico en
otras tareas que permitiran que los proyectos de desarrollo de sistemas cumplan con
estndares del PMI relacionados con la Administracin Profesional de Proyectos.
5.3. Al haber implementado una metodologa de trabajo que crea un vnculo entre la Informtica
y la Administracin de Proyectos se tendr mucha probabilidad de tener xito en los
proyectos relacionados con el desarrollo de sistemas. Esto representa una gran
oportunidad de mejora, pues generalmente los proyectos informticos no utilizan tcnicas
de Administracin de Proyectos, y por lo tanto los resultados no se producen en la forma
esperada.
5.4. En el rea del alcance se cre una relacin entre los requerimientos de los sistemas y la
definicin del alcance de los proyectos, esto garantizar que todos los involucrados
conozcan de qu se trata el proyecto relacionado con desarrollo de sistemas. Con las
tcnicas recomendadas todos los involucrados tendrn claridad en los productos a entregar
y el trabajo necesario para lograr las entregas.
5.5. En el rea del tiempo se crearon recomendaciones que permitirn calcular los tiempos de
los proyectos de software en una forma ms cientfica. Estas tcnicas no son comunes en

101

la Informtica y si se utilizan en los proyectos de software se obtendr ms certeza en los

clculos de los tiempos.
5.6. Un rea que se explota poco en los proyectos de desarrollo de sistemas es la Gestin de
los Riesgos y desafortunadamente es donde ms afectan. De igual forma que en los
captulos anteriores, se mostraron herramientas que un Informtico puede usar en el
desarrollo de sistemas y que le proporcionarn ms seguridad en sus proyectos. El trabajo
se realiz de tal forma que el Profesional de Tecnologas sienta que cuenta con una gua
que le lleva a la creacin de un plan de riesgos sin necesidad de ser un experto en la
Administracin de Proyectos.
5.7. Finalmente, se cre un estndar que le permitir al Informtico trabajar bajo un esquema
de calidad en los proyectos de software. La idea es que todo lo que se haga dentro de un
proyecto de desarrollo

de sistemas funcione dentro de un ambiente previamente

planificado, donde todas las acciones y todos los documentos que se necesiten usar hayan
sido previamente diseados y que nada de lo que se haga quede fuera del estndar. Con lo
anterior se podr tener mucha seguridad de xito en los proyectos de software, as como
contar con registros histricos que muestren como se estn llevando a cabo los proyectos.
5.8. Con las herramientas desarrolladas en esta investigacin se cumple con el compromiso de
crear una metodologa que le permita a un Profesional de Tecnologas de Informacin,
trabajar bajo un entorno de Administracin de Proyectos dentro del desarrollo de sistemas,
sin ser un experto en el campo de la Administracin Profesional de Proyectos.

102

6. Recomendaciones
6.1. Para finalizar con esta investigacin se recomienda al lector investigar sobre las otras reas
del conocimiento (9 en total) que son el estndar del Project Management Institute (PMI).
Conociendo sobre las otras reas de la Administracin de Proyectos se tendr un
panorama ms completo sobre el campo de los proyectos y con respecto a la investigacin
realizada se podr explotar de una mejor forma.
6.2. La investigacin realizada corresponde a un requisito acadmico, es por este motivo que no
se incluyeron las 9 reas dentro de la metodologa propuesta, debido a que se hubiera
necesitado ms tiempo para cubrir la Administracin de Proyectos en forma total. Sin
embargo, el objetivo fue desarrollar una metodologa que sea til para las organizaciones
semejantes a la que labora el sustentante, donde los costos por ejemplo no son tan
relevantes en los proyectos por tratarse de presupuestos cuyos orgenes son los fondos
pblicos.
6.3. Se recomienda al Profesional

Informtico

tener presente los resultados de esta

investigacin en los momentos en que le corresponda desempearse dentro de un

proyecto de desarrollo de sistemas, porque es probable que si usan las tcnicas expuestas
en este trabajo, los resultados sean bastante exitosos y desafortunadamente no existe
mucha presencia de este tipo de tcnicas en el campo de los proyectos informticos.
6.4. Esta investigacin podr servir como complemento a la formacin de los profesionales en
Informtica, porque cubre tpicos que no son cubiertos en las carreras de Computacin y
por lo tanto provoca que haya una deficiencia en la administracin de los proyectos de
desarrollo de sistemas. Al trabajar con una metodologa como la desarrollada se garantiza
mucha probabilidad de xito en los proyectos informticos.

103

6.5. Un aspecto importante que se debe considerar en el momento de aplicar una metodologa
es la importancia del apoyo de la alta gerencia. La experiencia ha demostrado que si no se
cuenta con apoyo de la alta direccin es difcil implementar nuevas tcnicas en cualquier
rea, sobre todo en el campo de Tecnologas de Informacin en donde se tiene contacto
con toda la organizacin. Para implementar una metodologa como la desarrollada es
necesario que se involucre la alta gerencia y que la misma participe en el uso de los
nuevos procedimientos de trabajo.
6.6. Una recomendacin adicional

es tratar de ir introduciendo estas tcnicas en forma

progresiva, esto para darle oportunidad a la organizacin de ir asimilando los nuevos

procedimientos en una forma pausada, y con esto se lograr que la organizacin entre en
etapas de maduracin progresivas en el campo de la Administracin Profesional de
Proyectos y el impacto en el personal se podr minimizar.

104

7. Bibliografa
Chamoun, Yamal. Administracin Profesional de Proyectos La Gua.
Mxico: McGraw Hill Interamericana, 2002.
Gido, Jack; Clements, James. Administracin Exitosa de Proyectos.
Mxico: Edamsa Impresiones, S.A. de C.V., 2003.
Gordon, Davis; Olson, Margrethe. Sistemas de Informacin Gerencial.
Colombia: Editorial Nomos Ltda., 1987.
Laudon, Kenneth. Administracin de los Sistemas de Informacin.
Mxico: Prentice Hall Hispoamericana S, A., 1996.
Levine , Guillermo. Computacin Moderna.
Mxico: Educacin de Mxico, S.A. de C.V., 2001.
Martin, James; Odell, James. Anlisis y Diseo orientado a objetos.
Mxico: Prentice May Hispanoamericana, S.A., 1992.
Murdick, Robert. Sistemas de Informacin Administrativa. Primera edicin.
Mexico: Prentice-Hall., 1998.
OBrien, James. Sistemas de Informacin Gerencial.
Colombia: McGraw-Hill. Interamericana S, A., 2001.
PMI (Project Management Institute). Gua de los Fundamentos de la Direccin de Proyectos.
PMBOK Guide. Tercera edicin. Newton Square, Pennsylvania, E.U.A. 2004.
Presuman, Roger. Ingeniera del Software. Cuarta edicin.
Espaa: Edgrafos, S.A., 1997.
Rodrguez, Jos de Jess. Administracin de Proyectos. 2003.
Disponible en http://www.gestiopolis.com/recursos2/documentos/fulldocs/ger/adproysisinf.htm.
Consultado el 10 de Octubre del 2005.
Senn, James. Anlisis y Diseo de Sistema de Informacin.
Segunda edicin. Mexico: Mc Graw-Hill, 1995.

105

8. ANEXOS

106