Taller de proyectos

UNIVERSIDAD PARA LA COOPERACIÓN INTERNACIONAL (UCI)

METODOLOGÍA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIÓN BASADA EN LOS ESTÁNDARES DEL PROJECT MANAGEMENT INSTITUTE

EFRAÍN GÓMEZ QUIRÓS

PROYECTO FINAL DE GRADUACIÓN PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR POR EL TITULO DE MASTER EN ADMINISTRACIÓN DE

PROYECTOS

San José, Costa Rica Marzo del 2006

ii

UNIVERSIDAD PARA LA COOPERACIÓN INTERNACIONAL (UCI)

Este Proyecto Final de Graduación fue aprobado por la Universidad como Requisito parcial para optar al grado de Master en Administración de Proyectos

____________________________

MSc. Fabio Muñoz Jiménez DIRECTOR DEL PROYECTO

____________________________ MSc. Miguel Vallejo Solís

DIRECTOR DEL PROGRAMA

____________________________ Ing. Efraín Gómez Quirós

SUSTENTANTE

iii

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 formación, pero el tiempo se encargará de demostrar que solo con determinación y convicción 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 sabiduría y los valores del hombre se fundamentan en las semillas del conocimiento y que la riqueza que entrega la educación será un activo que permanecerá durante el resto de nuestras vidas.

iv

TABLA DE CONTENIDOS

1. INTRODUCCIÓN .................................................................................................................. 1

1.1. PROBLEMAS DE LOS PROYECTOS DE DESARROLLO DE SISTEMAS DE INFORMACIÓN ......................... 1 1.1.1. JUSTIFICACIÓN DEL PROYECTO ...................................................................................................... 1 1.1.2. OBJETIVOS DEL PROYECTO ........................................................................................................... 2

2. MARCO TEÓRICO ............................................................................................................... 4

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

2.1.1. ASPECTOS TEÓRICOS RELACIONADOS CON LOS SISTEMAS DE INFORMACIÓN ................................... 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 DEFINICIÓN ..................................................................................................................... 6 2.1.2.3. FASE DE ADQUISICIÓN O DE PRODUCCIÓN ...................................................................................... 6 2.1.2.4. FASE OPERACIONAL ...................................................................................................................... 7 2.1.2.5. FASE DE OBSOLESCENCIA ............................................................................................................. 7 2.1.3. DEFINICIÓN DE INFORMACIÓN ........................................................................................................ 7 2.1.4. DEFINICIÓN DE UN SISTEMA DE INFORMACIÓN ............................................................................... 8 2.1.5. ORIGEN DE LOS SISTEMAS DE INFORMACIÓN .................................................................................. 8 2.1.6. CARACTERÍSTICAS DE LOS SISTEMAS DE INFORMACIÓN ................................................................... 9 2.1.7. CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIÓN .............................................. 9 2.1.8. DEFINICIÓN DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIÓN ...................... 9 2.1.8.1. INVESTIGACIÓN PRELIMINAR ........................................................................................................ 10 2.1.8.2. ACLARACIÓN DE LA SOLICITUD ..................................................................................................... 10 2.1.8.3. ESTUDIO DE FACTIBILIDAD ........................................................................................................... 10 2.1.8.3.1.LA FACTIBILIDAD TÉCNICA .......................................................................................................... 11 2.1.8.3.2.FACTIBILIDAD ECONÓMICA ......................................................................................................... 11 2.1.8.3.3.LA FACTIBILIDAD OPERACIONAL .................................................................................................. 11 2.1.8.4. APROBACIÓN DE LA SOLICITUD .................................................................................................... 12 2.1.9. DETERMINACIÓN DE LOS REQUERIMIENTOS DEL SISTEMA .............................................................. 12

v

2.1.10. DISEÑO DEL SISTEMA .................................................................................................................. 13 2.1.11. DESARROLLO DE SISTEMAS ......................................................................................................... 14 2.1.12. PRUEBAS DEL SISTEMA ............................................................................................................... 15 2.1.13. IMPLANTACIÓN Y EVALUACIÓN ..................................................................................................... 15

2.2. TEORÍA DE LA ADMINISTRACIÓN DE PROYECTOS. .................................................................. 17

2.2.1. ¿QUÉ ES UN PROYECTO? ........................................................................................................... 17 2.2.2. ¿QUE ES LA DIRECCIÓN DE PROYECTOS? .................................................................................... 17 2.2.3. ÁREAS DE CONOCIMIENTO DE LA DIRECCIÓN DE PROYECTOS ......................................................... 18 2.2.4. PROCESOS Y CARACTERÍSTICAS DE LA GESTIÓN DEL ALCANCE DEL PROYECTO ............................. 21 2.2.4.1. PLANIFICACIÓN DEL ALCANCE ..................................................................................................... 21 2.2.4.2. DEFINICIÓN DEL ALCANCE ........................................................................................................... 21 2.2.4.3. CREACIÓN DE LA WBS (EDT) .................................................................................................... 22 2.2.4.4. VERIFICACIÓN DEL ALCANCE ....................................................................................................... 22 2.2.4.5. CONTROL DEL ALCANCE ............................................................................................................. 22 2.2.5. PROCESOS Y CARACTERÍSTICAS DE LA GESTIÓN DEL TIEMPO DEL PROYECTO ............................... 23 2.2.5.1. DEFINICIÓN DE LAS ACTIVIDADES ................................................................................................ 23 2.2.5.2. ESTABLECIMIENTO DE LA SECUENCIA DE LAS ACTIVIDADES ........................................................... 23 2.2.5.3. ESTIMACIÓN DE RECURSOS DE LAS ACTIVIDADES ......................................................................... 23 2.2.5.4. ESTIMACIÓN DE LA DURACIÓN 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 CARACTERÍSTICAS DE LA GESTIÓN DE LOS RIESGOS DEL PROYECTO ........................ 24 2.2.6.1. PLANIFICACIÓN DE LA GESTIÓN DE RIESGOS ................................................................................ 24 2.2.6.2. IDENTIFICACIÓN DE RIESGOS ...................................................................................................... 24 2.2.6.3. ANÁLISIS CUALITATIVO DE RIESGOS ............................................................................................ 24 2.2.6.4. ANÁLISIS CUANTITATIVO DE RIESGOS .......................................................................................... 25 2.2.6.5. PLANIFICACIÓN DE LA RESPUESTA A LOS RIESGOS ....................................................................... 25 2.2.6.6. SEGUIMIENTO Y CONTROL DE RIESGOS ....................................................................................... 25 2.2.7. PROCESOS Y CARACTERÍSTICAS DE LA GESTIÓN DE LA CALIDAD DEL PROYECTO ........................... 25

vi

2.2.7.1. PLANIFICACIÓN DE CALIDAD ........................................................................................................ 26 2.2.7.2. REALIZAR ASEGURAMIENTO DE CALIDAD ..................................................................................... 26 2.2.7.3. REALIZAR CONTROL DE CALIDAD ................................................................................................ 26

3. MARCO METODOLÓGICO ............................................................................................. 29

3.2.1. SECUENCIA DE ACTIVIDADES ....................................................................................................... 31 3.2.2. ESTIMACIÓN DE LA DURACIÓN DE LAS ACTIVIDADES ...................................................................... 31 3.3.2. TÉCNICA DE DIAGRAMACIÓN DE CAUSA Y EFECTO ........................................................................ 33

4. DESARROLLO .................................................................................................................... 37

4.1. SELECCIÓN DEL PROYECTO PILOTO ........................................................................................ 37

4.2. LA GESTIÓN DEL ALCANCE EN EL DESARROLLO DE SISTEMAS DE INFORMACIÓN ………….38

4.3. LA GESTIÓN DEL TIEMPO EN EL DESARROLLO DE SISTEMAS DE INFORMACIÓN ..................... 42

4.3.1. CREACIÓN DEL DIAGRAMA DE RED.............................................................................................. 42

4.3.2. ESTIMACIÓN DEL TIEMPO ........................................................................................................... 44

4.3.3. TÉCNICA PERT ........................................................................................................................... 49

4.4. LA GESTIÓN DEL RIESGO EN EL DESARROLLO DE SISTEMAS DE INFORMACION .................... 56

4.4.1. IDENTIFICACIÓN DE RIESGOS ................................................................................................... 56

4.4.1.1. TORMENTA DE IDEAS .................................................................................................................. 56 4.4.1.2. TÉCNICA DELPHI ........................................................................................................................ 57 4.4.1.3. ENTREVISTAS ............................................................................................................................. 57 4.4.1.4. REVISIÓN DE LOS SUPUESTOS O HIPÓTESIS .................................................................................. 57 4.4.1.5. DIAGRAMAS DE CAUSA Y EFECTO ................................................................................................. 57 4.4.2. PRIORIDAD DE LOS RIESGOS ..................................................................................................... 59

4.4.3. ANÁLISIS CUALITATIVO DE RIESGOS ....................................................................................... 59

4.4.3.1. CÓDIGO 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

vii

4.4.4. ANÁLISIS CUANTITATIVO DE RIESGOS .................................................................................... 65

4.4.4.1. ENFOQUE PERT ........................................................................................................................ 66 4.4.4.2. ANÁLISIS DEL VALOR MONETARIO ESPERADO (EVM) ................................................................... 66 4.4.4.3. ANÁLISIS MEDIANTE ÁRBOL DE DECISIONES .................................................................................. 67 4.4.4.4. EVALUACIÓN DEL ÁRBOL DE DECISIONES ...................................................................................... 68 4.4.4.5. SIMULACIÓN MONTE CARLO ........................................................................................................ 68 4.4.4.5.1 PASOS BÁSICOS DEL MÉTODO MONTE CARLO ............................................................................ 69

4.4.5. PLANIFICACIÓN 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 GESTIÓN DE CALIDAD EN PROYECTOS DE DESARROLLO DE SIST. DE INFORMACIÓN ........ 79

4.5.1. REPASO DE LOS PRINCIPALES CONCEPTOS TEÓRICOS .................................................................. 79 4.5.2. NECESIDAD DE USAR LOS PROCESOS DE CALIDAD EN LOS PROYECTOS DE SISTEMAS .................... 79 4.5.3. PROCEDIMIENTO RECOMENDADO PARA GESTIONAR LA CALIDAD EN EL PROYECTO .......................... 81 4.5.3.1. FORMULARIOS UTILIZADOS .......................................................................................................... 81 4.5.3.2. INSTRUCTIVO RELACIONADO ........................................................................................................ 82 4.5.3.3. DESCRIPCIÓN 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. GUÍA DE USO DE LA METODOLOGÍA PROPUESTA .................................................................... 93

4.6.1. GESTIÓN DEL ALCANCE .............................................................................................................. 94 4.6.2. GESTIÓN DEL TIEMPO ................................................................................................................. 95 4.6.3. GESTIÓN DEL RIESGO ................................................................................................................. 96 4.6.4. GESTIÓN DE LA CALIDAD ............................................................................................................. 98

5. CONCLUSIONES .................................................................................................................... 101

viii

6. RECOMENDACIONES ............................................................................................................ 103

7. BIBLIOGRAFÍA ....................................................................................................................... 105

8. ANEXOS ................................................................................................................................ 106

ix

INDICE DE CUADROS Y FIGURAS

PáginaCuadros

Cuadro 1: Matriz de Probabilidad e Impacto 35

Cuadro 2: Descomposición 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 Automatización de Actas 53

Cuadro 7: Cronograma del Proyecto de Automatización de Actas 55

Cuadro 8: Probabilidad de ocurrencia del Riesgo 61

Cuadro 9: Impacto si ocurre el Riesgo 61

Cuadro 10: Descripción del impacto según la escala 62

Cuadro 11: Marcadores de riesgo 63

Cuadro 12: Análisis cualitativo del sistema de automatización de actas 64

Cuadro 13: Aplicación del Análisis 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 análisis de las 100 repeticiones 72

Cuadro 17: Cálculo de reserva para contingencias 76

Cuadro 18: Respuesta a los riesgos en el Proyecto de Automatización de Actas 77

Cuadro 19: Plan de Contingencias en el Proyecto de Automatización de Actas 78

Cuadro 20: Detalle de Productos Entregables de la Metodología 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

x

Figura 4: Diagrama de red del Sistema de Automatización de Actas 44

Figura 5: Org. del equipo de trabajo para el Sistema de Automatización de Actas 45

Figura 6: Ruta Crítica 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 automatización de Actas. 73

Figura 11: Flujo del desarrollo de Software 87

Figura 12: Solicitud de un Nuevo Sistema 88

Figura 13: Bitácora de problemas encontrados 89

Figura 14: Diagrama general de la Metodología 93

Figura 15: Guía de uso de la metodología en la Gestión del Alcance. 94

Figura 16: Guía de uso de la metodología en la Gestión del Tiempo 95

Figura 17: Guía de uso de la metodología en la Gestión del Riesgo 96

Figura 18: Guía de uso de la metodología en la Gestión de la Calidad 98

xi

RESUMEN EJECUTIVO Hace aproximadamente 30 años que los sistemas de información se han venido desarrollando y perfeccionado más día a día. En la actualidad la mayoría de empresas cuentan con sistemas de información. En estos días la tecnología se ha convertido en un factor clave para el desarrollo de las naciones y del planeta. El avance de la tecnología ha contribuido a que la Computación esté desarrollándose aceleradamente y este avance está relacionado directamente con el funcionamiento de los sistemas de información. Sin embargo, el campo de los sistemas está acompañado de problemas que se relacionan mucho con el perfil técnico de los profesionales de esta área. Estas personas tienden a concentrarse más en las áreas técnicas, como consecuencia descuidan las áreas administrativas; esto ha provocado una imagen problemática alrededor de los proyectos informáticos. En los proyectos informáticos existen fases o actividades que son propias de este campo, tales como: Levantamiento de requerimientos iniciales, análisis de la situación actual, diseño del nuevo sistema, programación e implementación. La propuesta de esta investigación 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 análisis de la situación actual, aparte de obtener lo que dicta la metodología de sistemas, también se obtendrá la definición de la estructura detallada del trabajo (EDT), lo que permitirá tener una visión más clara del trabajo a ejecutar. De manera similar se obtendrán los otros productos que identifican las áreas del conocimiento utilizadas, y por consiguiente se aumentará la probabilidad de éxito en los proyectos informáticos. Paralelamente a las actividades adicionales que se recomiendan, se usarán una serie de plantillas que servirán de guía al Informático en el momento de realizar las actividades relacionadas con la administración de proyectos. Esta investigación pretende plantear una alternativa que provea al Informático de instrumentos destinados a evitar deficiencias en la administración de proyectos. Esta alternativa disminuye el riesgo de que los Informáticos se concentren solamente en las áreas técnicas, y por consiguiente descuiden las actividades relacionadas con la administración del proyecto. Desafortunadamente es común que el personal técnico reste importancia al valor de las funciones administrativas y esto provoca que los proyectos informáticos no presenten una buena planeación en las definiciones de alcance, cronograma de trabajo, control del riesgo y control de calidad. El objetivo de esta investigación es ofrecer una metodología que le permita al Profesional de Informática usar técnicas de Administración de Proyectos, a través 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 asociación entre las fases típicas del desarrollo de sistemas, y las actividades relacionadas con las áreas del conocimiento utilizadas en éste desarrollo.

xii

Las áreas de conocimiento que involucra este trabajo son: La Gestión del Alcance, la Gestión del Tiempo, la Gestión de Riesgos, y la Gestión 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 Administración Profesional de Proyectos. La estrategia que se utilizó en esta investigación consistió en agregar actividades extra a las fases del ciclo de vida del desarrollo de Sistemas de Información. Las actividades adicionales se incluyeron de forma que no confundan al profesional informático, esto se logró a través de una retroalimentación 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 metodología corresponden a los recomendados por el PMI como productos generados para cada una de las cuatros áreas del conocimiento que se cubrieron en esta investigación. Otro aspecto importante que se detecta como consecuencia de la investigación y que se sugiere como recomendación es la necesidad del apoyo de la alta dirección 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 participación directa de la alta gerencia. Una forma de disminuir la resistencia podría ser que el uso de la metodología se haga en forma gradual, esto para darle oportunidad a la organización de ir asimilando los nuevos procedimientos en forma progresiva, de esta forma se logrará que la introducción en la Administración Profesional de Proyectos sea gradual y por lo tanto se minimice el impacto en el personal. Al final del desarrollo se podrá encontrar una guía en la cual se resumen los productos utilizados en cada una de las cuatro áreas cubiertas. Este resumen le permitirá al profesional informático en forma rápida detectar cuales serán los componentes que deberá usar u obtener, así como la interacción entre ellos dentro de las áreas de estudio.

1

1. INTRODUCCIÓN

1.1. Problemas de los proyectos de desarrollo de Sistemas de Información

El profesional de informática es entrenado académicamente para conceptualizar los componentes técnicos que darán forma a un sistema de información. Parte de su entrenamiento está relacionado con técnicas para extraer información necesaria para la modelación de los sistemas. Además se le brinda educación para conceptualizar un sistema como un proyecto que estará formado por diferentes etapas. Sin embargo surgen problemas cuando el profesional de informática se orienta más a las ramas técnicas que a las administrativas, esto provoca que se le reste valor a las actividades de planeación, definición y control. Y como consecuencia de esta problemática surgen problemas relacionados con falta de definición en el alcance, planeación deficiente de los tiempos del proyecto, carencia de procedimientos, falta de definición de las responsabilidades, ausencia de mecanismos de control de calidad, ausencia de planes para la contingencia de riesgos potenciales. El problema se manifiesta más cuando en las etapas de planeación de los sistemas de información no se invierte suficiente tiempo para la planeación del proyecto, porque al haber un estereotipo técnico, el medio ambiente espera ver al personal al frente de una estación de trabajo ejecutando funciones técnicas como lo son la programación, la configuración de equipo de comunicaciones, administración de bases de datos etc. Esta idea de sentarse lo más pronto posible a ejecutar funciones técnicas descuidando las funciones de planeación trae problemas que se repiten día a día relacionados con el alcance, el tiempo, el control de la calidad y los riesgos.

1.1.1. Justificación del proyecto

Ante este problema se pretende plantear una alternativa que provea al profesional de informática con instrumentos que le permitan evitar caer en los problemas planteados. Se considera que es

2

necesario que se le brinde a los profesionales del área alternativas que les permita lograr un trabajo más eficiente y eficaz. Con la preparación adquirida en la maestría de Administración de Proyectos se puede visualizar donde se encuentran las debilidades de los Ingenieros de Sistemas en el campo de la Administración de Proyectos, y se considera muy importante brindarle a estos profesionales herramientas que fortalezcan estas debilidades. Además, es importante que este desarrollo sea llevado a cabo por personas que conozcan el campo de la Ingeniería de Sistemas y a la vez que tengan preparación académica formal en el campo de Administración de Proyectos, porque esto permitirá amoldar el trabajo adicional a las fases clave del desarrollo de sistemas, y además será bastante transparente para el profesional de Informática.

1.1.2. Objetivos del proyecto Objetivo General Desarrollar una metodología que incorpore los estándares del Project Management Institute (PMI) en los proyectos de desarrollo de Sistemas de Información. Objetivos Específicos

• Crear instrumentos que le permitan a los Profesionales de Tecnologías de Información identificar, cuantificar y documentar el trabajo necesario para el desarrollo e implementación de proyectos de desarrollo de Sistemas de Información.

• Desarrollar procedimientos que le permitan al Profesional Informático hacer uso de las

herramientas para la administración del tiempo en el desarrollo de Sistemas de Información.

• Desarrollar métodos que le permitan al Profesional de Tecnologías de Información protegerse ante la presencia de los riesgos típicos del área de Sistemas de Información.

3

• Desarrollar los procedimientos que deberá seguir el profesional informático para trabajar en el desarrollo de sistemas bajo un entorno de Gestión de Calidad.

• Aplicar la metodología propuesta en un proyecto piloto para validar su aplicación.

4

2. MARCO TEÓRICO

2.1. Marco Referencial 2.1.1. Aspectos teóricos relacionados con los Sistemas de Información

Para hacer una introducción a los sistemas de información es recomendable hacer una definición de este concepto: Un sistema de información se refiere a una serie de componentes interrelacionados que capturan, almacenan, procesan y distribuyen la información para apoyar la toma de decisiones, el control, análisis y visión en una institución (Rodríguez, 2003).

Existen tres actividades de un sistema de información que producen la información que la institución requiere para la toma de decisiones, para el control de las operaciones, el análisis de los problemas y la creación de nuevos productos y servicios. Estas actividades son las de insumo, procesamiento y producto. Las actividades de insumo están relacionadas con la captura o recolección de datos primarios dentro de la Institución o de su entorno para procesarlos en un sistema de información. Las actividades de procesamiento se relacionan con la conversión del insumo de forma que sea más comprensible para los seres humanos, y las de producto se refieren a la distribución de información procesada a las personas o en las actividades en donde será usada.

Los sistemas de información hacen uso del hardware y software de computadora para el procesamiento y la distribución de la información.

Existen clasificaciones en los sistemas, alguna de ellas son:

1. Sistema de nivel operativo: Sistemas de información que hacen el seguimiento de las actividades y las transacciones elementales de la organización.

5

2. Sistemas de nivel de conocimiento: Sistemas de información en los que se apoyan los trabajadores del conocimiento y de la información en una institución.

3. Sistemas de nivel gerencial: Son sistemas de información 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 estratégico: Sistemas de información, que apoyan a las actividades de planificación a largo plazo de los niveles de dirección de la institución.

Elementos de un sistema Es lo que compone un sistema. Sin alguno de estos elementos simplemente no existiría el sistema. Los elementos de un sistema son: Conceptos: Definiciones de cosas o actividades. Objetos: Pueden ser por ejemplo, una máquina de escribir compuesta de varias partes. Sujetos: Como puede ser los integrantes de un equipo de fútbol. Todo sistema cuenta con estos elementos. Por tanto también se dice que un sistema es un agregado de entidades que están 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 más fases, pero de acuerdo a Rodríguez (2003) las más comunes son: 1. Fase conceptual. 2. Fase de definición. 3. Fase de adquisición o de producción. 4. Fase operacional. 5. Fase de obsolescencia

6

2.1.2.1. Fase conceptual La fase conceptual es aquella en la que la idea se concibe y se le hace una evaluación preliminar. En esta fase se realizan pronósticos, se evalúan los objetivos y alternativas, se realiza una evaluación por primera vez de costos y aspectos relacionados con el tiempo que tardará el desarrollo, se hace la estrategia básica de la organización y los requerimientos de recursos. El propósito fundamental de la fase conceptual es hacer un estudio sobre papel de todos los requerimientos, para proporcionar la base de una evaluación detallada que posteriormente se hará en la etapa siguiente. Siempre hay un alto porcentaje de sistemas potenciales que no serán 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 prácticos desde el punto de vista técnico, económico y del ambiente.

2.1.2.2. Fase de definición El propósito principal de esta fase es definir lo más pronto posible y exacto, los costos, los programas, la realización y los requerimientos de recursos y si todos estos elementos concordarán económica y técnicamente. La fase de definición solo narra con mayor detalle qué es lo que se quiere hacer, cuándo se desea hacerlo, cómo se ejecutará y cuánto costará.

2.1.2.3. Fase de adquisición o de producción El propósito de esta fase de adquisición o de producción es adquirir y probar los elementos del sistema y el sistema total mismo utilizando los estándares que se desarrollaron durante las fases precedentes. El proceso de adquisición involucra aspectos tales como la implantación real del

7

sistema, la fabricación del equipo, la asignación de autoridad y de responsabilidad, la construcción de las instalaciones y la conclusión de la documentación 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 económico y el gerente trata de poner más atención 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 declinación 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. Definición de información La información se refiere a todos aquellos datos transformados o modificados que tienen valor para aquellos usuarios que hacen uso de ellos (O' Brien, 2001).

8

Los datos están constituidos por los registros de los hechos, acontecimientos, transacciones, etc. Por el contrario, la información implica que los datos estén 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 información. Con lo anterior se llega a la conclusión de que la información corresponde a datos procesados con un valor para aquel usuario que la necesita.

2.1.4. Definición de un sistema de información De acuerdo a Rodríguez (2003), un sistema de información 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 información importantes en la toma de decisiones. El objetivo de un sistema de información es ayudar al desempeño de las actividades que desarrolla la empresa, suministrando la información adecuada, con la calidad requerida, a la persona o departamento que lo solicita, en el momento y lugar especificados con el formato más útil para el receptor. El sistema de información está al servicio de los objetivos de la empresa. Para lograr dichos objetivos la empresa y sus individuos adoptan procedimientos y prácticas de trabajo que resultan más útiles y eficaces.

2.1.5. Origen de los sistemas de información Cuando una empresa crece la supervisión 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 sería 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 información y verificar las realizaciones que resultaban adecuados cuando la empresa era pequeña, se vuelven demasiado numerosos y exigen

9

mucho tiempo. En otras palabras, el administrador propietario se encuentra sumergido en una red compleja de deberes relacionados recíprocamente, que debe cumplir. En esta situación es cuando el propietario debe decidir la implantación de un sistema de información para la empresa con el fin de cubrir todas las necesidades que han nacido con el crecimiento de la empresa.

2.1.6. Características de los sistemas de información Todo sistema necesita tener interacción 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 interactúan con su medio se les llama sistemas cerrados; en realidad, estos sistemas no existen, solo están como conceptos, solo existen los sistemas abiertos.

2.1.7. Ciclo de vida para el desarrollo de sistemas de información Anteriormente se había descrito el ciclo de vida de desarrollo de sistemas, ahora se describirá el ciclo de vida pero para el desarrollo de sistemas de información, la mayoría de las etapas son similares solo cambian en el nombre de ellas, o varían por el hecho de que estas son orientadas a sistemas de información, la idea principal es conocer las etapas y saberlas aplicar dependiendo del problema a solucionar.

2.1.8. Definición del ciclo de vida para el desarrollo de sistemas de información

Es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información. A continuación se describen las etapas del ciclo de vida de desarrollo de sistemas.

10

2.1.8.1. Investigación preliminar La investigación preliminar es la primera etapa dentro del ciclo de vida para el desarrollo de sistemas de información. Esta comienza con la formulación 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 investigación preliminar consta de tres partes:

a. Aclaración de la solicitud b. Estudio de factibilidad c. Aprobación de la solicitud

2.1.8.2. Aclaración de la solicitud

Muchas solicitudes que provienen de usuarios o gerentes de departamentos (por ejemplo: ventas, producción, contabilidad, etc.) no están 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 precisión lo que realmente el usuario desea.

2.1.8.3. Estudio de factibilidad Después de haber realizado la aclaración de la solicitud es necesario saber si es factible lo que se desea realizar, el estudio de factibilidad cuenta con tres aspectos:

• Factibilidad técnica

• Factibilidad económica

• Factibilidad operacional

11

2.1.8.3.1. La factibilidad técnica Se refiere a que el proyecto pueda realizarse con los recursos técnicos con que cuenta la empresa como son: el equipo con que se cuenta, la tecnología existente de software y el personal disponible; se hacen cuestionamientos ¿Se necesita más tecnología de software?, ¿Cuál es la posibilidad de desarrollar el proyecto?, ¿Qué tiempo se llevará el proyecto hasta su implantación?

2.1.8.3.2. Factibilidad económica La factibilidad económica se refiere a los beneficios que traerá la realización del proyecto. Se deben de hacer una serie de cuestionamientos para poder saber si es factible el desarrollo del sistema económicamente ¿Los beneficios que se obtienen serán suficientes para cubrir los costos?, ¿Los costos asociados con la decisión de no crear el sistema son tan grandes que se debe aceptar el proyecto? Sin duda este aspecto es el más importante en las empresas ya que los gerentes muchas veces no están dispuestos a solventar estos costos cuando no existen los suficientes fundamentos que los convenzan de que es necesario la realización del proyecto por los beneficios ya sea tanto económicos como de calidad y rapidez en la ejecución de actividades que se podrán 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 disminución de los posibles beneficios de la aplicación? El estudio de factibilidad es realizado por lo regular por una o dos personas que tienen conocimiento en técnicas de sistemas de información y casi siempre son analistas de sistemas.

12

2.1.8.4. Aprobación 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 aprobación de la solicitud de proyecto éste puede comenzar inmediatamente, aunque lo común 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 más importancia para la empresa y en qué orden se desarrollarán. En las grandes empresas los planes para el desarrollo de sistemas de información se hacen con un especial cuidado, casi igual que los programas de fabricación o expansión de sus instalaciones. Después de aprobar la solicitud de proyecto se estima su costo y el tiempo necesario para hacerlo así como también las necesidades de personal para realizarlo.

2.1.9. Determinación 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. ¿Cómo se hace? 3. ¿Con que frecuencia se presenta? 4. ¿Qué tan grande es el volumen de transacciones o de decisiones? 5. ¿Cuál es el grado de eficiencia con el que se efectúan las tareas? 6. ¿Existe algún problema? 7. Si existe un problema, ¿Qué tan serio es? 8. Si existe un problema, ¿cuál es la causa que lo origina?

13

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 información, 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 observación directa de las actividades y en algunos casos, formas y documentos para comprender mejor el proceso en su totalidad. Conforme se va reuniendo la información, los Analistas van identificando los requerimientos y características que debe tener el nuevo sistema, junto con características operacionales tales como controles de procesamiento, tiempos de respuesta y métodos de entrada y salida.

2.1.10. Diseño del sistema En esta etapa el Analista usa la información recolectada anteriormente para realizar el diseño lógico del sistema de información. Los especialistas en sistemas se refieren con frecuencia, a esta etapa como diseño lógico en contraste con la etapa de desarrollo de software a la que denominan diseño físico. El Analista diseña procedimientos precisos para la captura de datos a fin de que los datos que van a entrar al sistema sean correctos. Además, el Analista también proporciona entrada efectiva para el sistema de información mediante el uso de técnicas para el buen diseño de formas y pantallas. Parte del diseño del sistema de información es la interfaz de usuario. La interfaz conecta al usuario con el sistema, es el puente de comunicación y por lo tanto es extremadamente importante realizar un buen diseño. Un ejemplo de interfaz de usuario incluye un teclado para introducir preguntas y respuestas, menús en pantalla para elegir comandos del usuario y un ratón para seleccionar

14

opciones. Dentro de la fase de diseño se incluye el diseño 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 diseñada da como resultado unos datos bien organizados, lo que constituye el fundamento para todos los sistemas de información. En esta etapa el Analista también trabaja con los usuarios para diseñar la salida de información de las bases de datos, estas pueden ser en pantalla o impresas, según como se satisfaga mejor las necesidades de información. Por último, el Analista debe diseñar procedimientos de control y respaldo para proteger el sistema y los datos. Los documentos que contengan las especificaciones de diseño se representarán por medio de diagramas de flujo, tablas, símbolos especiales, árboles, gráficas, etc. Los diseñadores son los responsables de dar a los programadores, las especificaciones del sistema de información completas y claramente delineadas. Una vez comenzada la fase de programación, los diseñadores contestarán las preguntas y dudas que tengan los programadores, cuando utilicen las especificaciones de diseño, por eso es recomendable que el diseño sea lo más 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 apoyándose en el diseño de sistemas. Los programadores tienen un papel principal en esta etapa ya que son los encargados de la codificación de los módulos correspondientes, así como también de la verificación de sintaxis en el código para encontrar errores y resolverlos. El programador también valida cada uno de los módulos programados y realiza pruebas integrales a cada módulo. Los programadores son responsables de la documentación 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

15

explicación de la forma de programar los módulos así como también todo lo concerniente a los procedimientos empleados en la programación de cada módulo. Esta documentación 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 después se examinan sus salidas o resultados. Muchas veces se permite a los usuarios finales (aquellos usuarios que usarán el sistema constantemente) utilizar el sistema como ellos lo usarían, 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 difícil hacer pruebas al sistema y no encontrar ningún error, ya que los errores nos ayudan a mejorar nuestros sistemas, si no tuviéramos errores realmente no sabríamos si todo está bien.

2.1.13. Implantación y evaluación La implantación es el proceso de instalar y verificar un nuevo equipo, capacitar a los usuarios que usarán el nuevo sistema de información. Se debe de hacer una conversión del viejo sistema al nuevo, verificando que los usuarios no encuentren inconvenientes en el uso del nuevo sistema; esta conversión incluye la de archivos de formatos antiguos a nuevos o simplemente la construcción de una base de datos.

16

En ocasiones se propone usar los dos sistemas de información, el nuevo y el viejo con el objetivo de comparar las mejoras del nuevo contra el viejo así como también que los usuarios se familiaricen con el nuevo sistema en forma periódica, ya que pueden usar los dos sistemas y comparar cuáles son las ventajas del nuevo sobre el viejo sistema de información. Aparentemente, una vez terminada la etapa de implantación y evaluación del sistema de información, solo queda brindar mantenimiento al sistema de información dado que los sistemas de las empresas junto con el ambiente de las empresas experimentan cambios de manera continua y constante. Los sistemas de información deben mantenerse siempre al día, en este sentido se puede decir que la implantación es un proceso de constante evolución.

17

2.2. Teoría de la Administración de Proyectos.

2.2.1. ¿Qué es un proyecto? Según 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 organización. Un proyecto puede involucrar a una sola persona o a muchas y podrían requerirse menos de cien horas para completarse o miles de ellas. Y podría involucrarse a una sola unidad de una organización o cruzar muchas fronteras organizacionales como en el caso de las corporaciones. El término temporal se refiere a que cada proyecto tiene un inicio y una terminación 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 duración; muchos proyectos duran varios años. El término refiere más a que la duración del proyecto es finita, es decir, existe un inicio y un final. Los proyectos están relacionados con la creación de algo que no se ha hecho antes, por lo tanto es de características únicas. La presencia de repetición de elementos no cambia la característica fundamental de ser único.

2.2.2. ¿Que es la dirección de proyectos? Según el PMBOK (PMI, 2004): “La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto.”

18

La dirección de proyectos consiste en aplicar e integrar los procesos de dirección de proyectos de inicio, planificación, ejecución, seguimiento y control, y cierre. El Director del Proyecto es el responsable de lograr los objetivos del proyecto. La dirección de un proyecto incluye:

• Identificación 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 adaptación 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 dirección de proyectos

La dirección 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 investigación cubrirá 4 de estas áreas, sin embargo se describirán todas para tener un panorama más global de la composición de un proyecto. Gestión de la Integración del Proyecto Especifica los procesos y actividades que forman los elementos de la dirección de proyectos, que se identifican, definen, combinan, unen y coordinan dentro de los Grupos de Procesos de Dirección de Proyectos. Esta área esta compuesta por los siguientes procesos: Desarrollar el Acta de Constitución del Proyecto, Desarrollar el Enunciado del Alcance del Proyecto (Preliminar), Desarrollar el Plan de Gestión del Proyecto, Dirigir y Gestionar la Ejecución del Proyecto, Supervisar y Controlar el Trabajo del Proyecto, Control Integrado de Cambios y Cerrar Proyecto.

19

Gestión del Alcance del Proyecto Muestra los procesos necesarios para asegurar que el proyecto incluye todo el trabajo requerido, y sólo el trabajo requerido, para completar el proyecto en forma satisfactoria. Está compuesta por los siguientes procesos: Planificación del Alcance, Definición del Alcance, Crear EDT, Verificación del Alcance y Control del Alcance. Gestión del Tiempo del Proyecto Identifica los procesos relacionados con la puntualidad en la conclusión del proyecto. Se compone de los siguientes procesos: Definición de las Actividades, Establecimiento de la Secuencia de las Actividades, Estimación de Recursos de las Actividades, Estimación de la Duración de las Actividades, Desarrollo del Cronograma y Control del Cronograma. Gestión de los Costos del Proyecto Identifica los procesos relacionados con planificación, estimación, presupuesto y control de costos de tal forma que el proyecto se complete dentro del presupuesto acordado. Se compone de los siguientes procesos: Estimación de Costes, Preparación del Presupuesto de Costes y Control de Costes. Gestión 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:

20

Planificación de Calidad, Realizar Aseguramiento de Calidad y Realizar Control de Calidad. Gestión 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: Planificación de los Recursos Humanos, Adquirir el Equipo del Proyecto, Desarrollar el Equipo del Proyecto y Gestionar el Equipo del Proyecto. Gestión de las Comunicaciones del Proyecto Identifica los procesos relacionados con la creación, recolección, distribución, almacenamiento y destino final de la información del proyecto en tiempo y forma. Se compone de los siguientes procesos: Planificación de las Comunicaciones, Distribución de la Información, Informar el Rendimiento y Gestionar a los Interesados. Gestión 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 gestión de riesgos de un proyecto. Se compone de los siguientes procesos: Planificación de la Gestión de Riesgos, Identificación de Riesgos, Análisis Cualitativo de Riesgos, Análisis Cuantitativo de Riesgos, Planificación de la Respuesta a los Riesgos, y Seguimiento y Control de Riesgos.

21

Gestión de las Adquisiciones del Proyecto Identifica los procesos relacionados con las compras o adquisición de productos, servicios o resultados, así como la contratación de procesos de dirección. Se compone de los siguientes procesos: Planificar las Compras y Adquisiciones, Planificar la Contratación, Solicitar Respuestas de Vendedores, Selección de Vendedores, Administración del Contrato y Cierre del Contrato. A continuación se hace un desarrollo más amplio sobre las áreas que se cubrirán en esta investigación:

2.2.4. Procesos y características de la Gestión 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 gestión del alcance se define todo lo que se incluirá en el proyecto, así como lo que no se incluirá. Según el PMBOK (PMI, 2004) los procesos de la Gestión del Alcance son los siguientes:

2.2.4.1. Planificación del Alcance Se cubren los tópicos necesarios para crear un plan de gestión del alcance del proyecto que muestre cómo se definirá, verificará y controlará el alcance del proyecto, así como los pasos necesarios para la creación de la Estructura de Desglose del Trabajo (EDT).

2.2.4.2. Definición 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.

22

2.2.4.3. Creación de la WBS (EDT) Descompone los productos entregables más importantes del proyecto en componentes más pequeños y más fáciles de manejar.

2.2.4.4. Verificación 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 también con los procesos de las demás Áreas del Conocimiento. Dentro del contexto de proyectos, el significado de alcance es el siguiente:

• Alcance del producto. Las características 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 características especificadas.

El enunciado del alcance del proyecto detallado y aprobado, y su EDT y el diccionario de la EDT relacionados, forman la línea 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 gestión 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.

23

2.2.5. Procesos y características de la Gestión del Tiempo del proyecto La Gestión del Tiempo del Proyecto comprende los procesos necesarios para lograr que el proyecto se complete a tiempo. Los procesos que incluye la Gestión del tiempo son los siguientes:

2.2.5.1. Definición de las Actividades Se identifican las actividades específicas 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. Estimación 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. Estimación de la Duración 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 ejecución de los seis procesos de Gestión del Tiempo del Proyecto está precedido por una planificación previa de parte del equipo de dirección del proyecto.

24

Esta tarea de planificación es parte del proceso Desarrollar el Plan de Gestión 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 gestión 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 características de la Gestión de los Riesgos del Proyecto La Gestión de los Riesgos del Proyecto comprende los procesos relacionados con la planificación de la gestión de riesgos, la identificación y el análisis de riesgos, las respuestas a los riesgos, y el seguimiento y control de riesgos de un proyecto. Loa objetivos de esta gestión 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 Gestión de los Riesgos del Proyecto son los siguientes:

2.2.6.1. Planificación de la Gestión de Riesgos Se planifica la ejecución de las actividades de gestión de riesgos para el proyecto.

2.2.6.2. Identificación de Riesgos Se analizan los riesgos que pueden afectar al proyecto y se documentan sus características.

2.2.6.3. Análisis Cualitativo de Riesgos Consiste en establecer la prioridad de los riesgos para realizar otros análisis o acciones posteriores, se trata de evaluar la probabilidad ocurrencia y su impacto.

25

2.2.6.4. Análisis Cuantitativo de Riesgos Analiza matemáticamente el efecto de los riesgos identificados dentro del plan del proyecto.

2.2.6.5. Planificación de la Respuesta a los Riesgos Se evalúan 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, además supervisa los riesgos residuales, e identifica los nuevos que podrían aparecer, ejecuta planes de respuesta en caso de que los riesgos se conviertan en realidad. Un riesgo en un proyecto es un evento o condición no predecible, que en caso de producirse tiene un efecto positivo o negativo sobre al menos un objetivo del proyecto, y los objetivos están estrechamente relacionados con el tiempo, el costo, el alcance o la calidad. Las condiciones de riesgo dentro del proyecto se pueden ver afectadas por prácticas deficientes de dirección de proyectos, la falta de sistemas de gestión integrados, múltiples proyectos concurrentes o por depender de participantes externos que no pueden ser controlados.

2.2.7. Procesos y características de la Gestión de la Calidad del Proyecto En los procesos de Gestión de la Calidad del Proyecto se incluye todo lo necesario para que la organización ejecutante determine las políticas, 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 gestión de calidad se implementa por medio de políticas, procedimientos y procesos de planificación 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

26

Los procesos de Gestión de la Calidad del Proyecto son los siguientes:

2.2.7.1. Planificación de Calidad Consiste en Identificar las normas de calidad que son relevantes para el Proyecto y determina cómo satisfacerlas.

2.2.7.2. Realizar Aseguramiento de Calidad Es la aplicación 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 métodos para eliminar las causas de un rendimiento no satisfactorio. El enfoque usado por el PMI (2004) en la gestión de calidad es compatible con la Organización Internacional de Normalización (Internacional Organization for Standardization, ISO). El enfoque también es compatible con enunciados de calidad propiedad exclusiva correspondientes a Deming, Juran, Crosby y otros. Y también es compatible con enfoques que no son de propiedad exclusiva, tales como Gestión de la Calidad Total (TQM), Six Sigma, Análisis de Modos de Fallo y Efectos, Revisiones del Diseño, Opinión del Cliente, Coste de la Calidad (COQ) y Mejora Continua. La Gestión de la Calidad del Proyecto cubre tanto la gestión del proyecto como el producto del proyecto. Mientras que la Gestión de la Calidad del Proyecto se aplica a todos los proyectos, sin tomar en cuenta la naturaleza de su producto, las medidas y técnicas de calidad del producto son específicas del tipo de producto. La calidad es el grado en el que un conjunto de características inherentes cumple con los requisitos (PMI, 2004). La conversión de las necesidades, o expectativas en requisitos se hace por medio del análisis de los interesados, que se realiza durante la Gestión del Alcance del Proyecto.

27

Existe una diferencia entre la calidad y el grado. El grado es una categoría asignada a productos o servicios que tienen el mismo uso pero se les asignan diferentes características técnicas. No hay equivalencia entre precisión y exactitud. La precisión es la forma en que se agrupan valores de mediciones repetidas y se obtiene poca dispersión. 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 dirección del proyecto determinar qué grado de exactitud o precisión, o de ambas, se requiere. La gestión de calidad actual complementa la dirección de proyectos. Ambas disciplinas reconocen la importancia de:

• Satisfacción 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 prevención sobre la inspección Los costos de prevenir errores son mucho menores que los costos de corregirlos cuando estos se detectan por una inspección.

• Responsabilidad de la dirección Es necesario que sea la dirección quien proporcione los recursos necesarios para lograr el éxito.

28

• 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 garantía y de retiros de productos.

1Según la definición de Shewhart, modificada por Deming, en el Manual de la ASQ, páginas 13–14, American Society for Quality, 1999.

29

3. MARCO METODOLÓGICO

3.1. Primer objetivo planteado “Crear instrumentos que le permitan a los Profesionales de Tecnologías de Información identificar, cuantificar y documentar el trabajo necesario para el desarrollo e implementación de proyectos de desarrollo de Sistemas de Información” Este objetivo está relacionado con el área de la gestión del alcance de la administración de proyectos del PMI. Para lograr el objetivo planteado se hará uso de plantillas que servirán para guiar el desarrollo de la estructura detallada del trabajo (EDT o WBS). Las mismas se pueden encontrar en los anexos 5 y 6. Además se usará la técnica de descomposición que consiste en lo siguiente: Subdivisión de los productos entregables de un proyecto en componentes más pequeños y fáciles 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 más 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 según el tamaño y la complejidad del proyecto. Diferentes productos entregables pueden tener diferentes niveles de descomposición. Para llegar a un esfuerzo de trabajo fácil de manejar (es decir, un paquete de trabajo), para algunos productos entregables el trabajo sólo debe dividirse hasta el nivel siguiente, mientras que otros requieren mayor nivel de descomposición. La descomposición de todo el trabajo de un proyecto regularmente cubre las siguientes actividades:

• Identificar los productos entregables y el trabajo correspondiente

30

• Estructurar y organizar la EDT

• Dividir los niveles superiores de la EDT en componentes más detallados de nivel inferior

• Verificar que el grado de descomposición del trabajo es el necesario y el suficiente para identificar los paquetes de trabajo.

El objetivo de la descomposición consiste en lograr una separación del trabajo hasta poder identificar las actividades necesarias para obtener los paquetes de trabajo, en la figura 1 se muestra en forma jerárquica la descomposición correspondiente:

Figura 1: Estructura Detallada del Trabajo

31

3.2. Segundo objetivo planteado “Desarrollar procedimientos que le permitan al Profesional Informático hacer uso de las herramientas para la administración del tiempo en el desarrollo de Sistemas de Información”

Se hará uso de las siguientes técnicas:

3.2.1. Secuencia de actividades Una de las técnicas que se recomendarán utilizar será el establecimiento de la secuencia de las actividades que consiste en identificar y documentar las relaciones lógicas entre las actividades del plan de trabajo. Las actividades del plan pueden estar ordenadas de forma lógica con relaciones de precedencia adecuadas, así como también 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 metodología propuesta es el diagrama de red del proyecto, el cual será parte del secuenciamiento de las actividades de un Proyecto.

3.2.2. Estimación de la duración de las actividades En el proceso Estimación de la Duración 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 períodos laborables requeridos para completar la actividad del plan de trabajo. Como técnica para calcular la duración de las actividades se hará uso de la estimación por tres valores, o técnica PERT que consiste en lo siguiente:

32

La exactitud de la estimación de la duración de la actividad puede afinarse teniendo en cuenta la cantidad de riesgo de la estimación original. La estimación por tres valores consiste en determinar tres tipos de estimaciones:

• Más probable. La duración de la actividad del plan de trabajo, teniendo en cuenta los recursos que serán 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 duración de la actividad se basa en el mejor escenario posible.

• Pesimista. La duración de la actividad se basa en el peor escenario posible. Se puede obtener una estimación de la duración de la actividad utilizando un promedio de las tres duraciones estimadas. Este promedio con frecuencia suministra una estimación de la duración de la actividad más precisa que la estimación de valor único.

El objetivo es desarrollar un análisis científico como el que se muestra en el anexo 7, el cual muestra el cálculo de duración de un proyecto haciendo uso de los tres tiempos posibles para cada actividad. Otro instrumento que se utilizará en la metodología propuesta será el Cronograma del Proyecto, el cual se podrá crear después de haber explicado el secuenciamiento de actividades, el diagrama de red del proyecto y la necesidad de recursos dentro del proyecto.

33

3.3. Tercer objetivo planteado “Desarrollar métodos que le permitan al Profesional de Tecnologías de Información protegerse ante la presencia de los riesgos típicos del área de Sistemas de Información” Este objetivo está relacionado con el área de conocimiento de la gestión del riesgo del PMI (2004), para lograrlo se hará uso de las siguientes técnicas: El primer paso para cubrir este objetivo consistirá en identificar los riesgos posibles que pueden presentarse en un proyecto informático. Como técnicas para esta identificación se proponen las siguientes:

1. Tormenta de ideas. 2. Técnica de diagramación 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. Técnica de diagramación de causa y efecto Se usa para identificar las causas raíz de los problemas, y así tomar las acciones correctivas. Se enfoca más hacia las causas que a los síntomas.

34

Una vez identificados los riesgos se hará uso de la técnica del análisis cualitativo de riesgos para analizar el impacto de riesgos en el proyecto. El Análisis Cualitativo de Riesgos evalúa 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 análisis de probabilidad de los riesgos consiste en investigar la probabilidad de ocurrencia de cada riesgo específico. El análisis 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 evaluación 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 calificación de los riesgos como de prioridad baja, moderada o alta, pueden emplearse términos descriptivos o valores numéricos 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:

35

Cuadro 1: Matriz de Probabilidad e Impacto

Después de que se haya hecho el análisis cualitativo se procederá a realizar un Análisis Cuantitativo que consistirá en detectar las actividades que pueden causar más impacto en el proyecto en caso de haber algún tipo de atraso en su ejecución. Los métodos que se mostraran serán conceptos basados en principios probabilísticas y matemáticos y además se mostrará el uso de herramientas de Software en este tipo de análisis. 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 Análisis Cualitativo y Cuantitativo.

36

3.4. Cuarto objetivo planteado “Desarrollar los procedimientos que deberá seguir el profesional informático para trabajar en el desarrollo de sistemas bajo un entorno de Gestión de Calidad” Para lograr este objetivo se hará uso de las siguientes técnicas:

1. Definición de procedimientos para el desarrollo de nuevos sistemas de información, o para el mantenimiento de los que ya están en producción.

2. Definición de instructivos de trabajo que apoyen los procedimientos de desarrollo y mantenimiento de sistemas.

3. Creación de diagramas de flujo que permitan identificar gráficamente el procedimiento de desarrollo y mantenimiento de sistemas.

4. Creación de los documentos que se deberán usar para el desarrollo y mantenimiento de sistemas de información.

3.5. Quinto objetivo planteado

“Aplicar la metodología propuesta en un proyecto piloto para validar su aplicación” Para aplicar la metodología propuesta se hará uso de un sistema de información que se implementará en la entidad encargada de supervisar los recursos destinados a las pensiones de los costarricenses. Usando este proyecto se mostrarán los procedimientos propuestos para cubrir las áreas del Alcance, Tiempo, Riesgos y Gestión de la calidad en los proyectos de desarrollo de software.

37

4. DESARROLLO

4.1. Selección del proyecto piloto Para mostrar la aplicación de la metodología que se propone para integrar el desarrollo de sistemas de información con estándares 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 información 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 información se conoce como el Sistema de Actas Electrónicas y va a controlar la creación de las actas de los Comités de Inversiones de las Operadoras de Pensiones. Estas actas se crearán 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 decisión de las operadoras se observe en línea 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, además el producto a desarrollar aportará mucho valor para la misión de la Superintendencia. Es por esto que se usará como plan piloto para el desarrollo de esta metodología, porque al ser un producto de valor para la organización los aportes que se puedan transmitir haciendo uso de estándares del PMI serán analizados para proyectos futuros en la Supen, es decir el uso de este proyecto como base para la metodología servirá como estrategia para mercadear el beneficio del uso de estándares del PMI. Además para los lectores Informáticos será de mucho beneficio entender como los métodos expuestos en la Metodología desarrollada se pueden aplicar a los Sistemas de Información que son la base central de cualquier Departamento de Tecnologías de Información.

38

4.2. La gestión del alcance en el desarrollo de Sistemas de Información Como paso inicial para incluir la gestión 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 deberán detectar productos como el sistema de información, manuales de usuario, manuales técnicos, planes de prueba, planes de capacitación, planes de comunicaciones etc. Para cada uno de estos productos que se deben entregar a lo largo del proyecto se deberán identificar las actividades que se requiere ejecutar para obtener los productos esperados, y luego se debe continuar con esta descomposición 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 descomposición es identificar todo el trabajo necesario para lograr un producto entregable del proyecto. Esta descomposición se puede agrupar en una plantilla de tal forma que se muestre la relación del trabajo y los entregables. En el Sistema de Automatización de Actas que se está usando como proyecto piloto esta plantilla quedaría de la forma en que se muestra en el cuadro 2.

39

Cuadro 2: Descomposición del trabajo a ejecutar

Desglose del trabajo a ejecutar NOMBRE DEL PROYECTO: Sistema de actas electrónicas DIRECTOR DEL PROYECTO: Ing. Efraín Gómez Quirós PATROCINADOR: Superintendente de Pensiones Entrega Actividad Tarea/ Subtareas Descripción 1. Sistema de información para supervisar las Operadoras de Pensiones

1.1 Analizar el Sistema Actual 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 requerimientos

El objetivo es documentar las necesidades de información para el nuevo sistema.

1.2 Diseñar el nuevo Sistema 1.2.1 Analizar interfaces Detectar con que sistemas se podría compartir información.

1.2.2 Analizar entradas y salidas

Detectar la forma en se alimentará el sistema y como desplegará la información.

1.2.3 Diseñar módulos de proceso

Consiste en definir los programas que se encargarán de procesar la información.

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 jerárquica 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 próximo 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.

40

Con respecto al proyecto piloto que se está usando como ejemplo en esta metodología 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 jerarquía muestra actividades en dos niveles en los cuales se puede notar la descomposición de tareas y sub-tareas. En el anexo 9 se puede observar toda la estructura detallada del trabajo correspondiente al proyecto de automatización de actas electrónicas.

Figura 2: Estructura detallada del trabajo (EDT)

Otro componente que se recomienda usar en relación con la gestión del alcance es el diccionario de cada actividad de la Estructura Detallada de Trabajo (EDT), el objetivo es hacer una descripción 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. Además se establece el responsable de ejecutarla, y se puede aprovechar para empezar a medir el tiempo y el costo de la actividad. A continuación se muestra la descripción detallada de una de las actividades de la EDT correspondiente al proyecto de actas. La actividad se describió como “Analizar el Sistema Actual“.

41

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

Diccionario de cada actividad de la Estructura Detallada de Trabajo (EDT) Información General de la actividad Id: 2 EDT #: 1.1 Nombre de la actividad:

Analizar el Sistema Actual

Descripción: Consiste en entender como funciona el entorno actual, en el cual se desea implementar un nuevo sistema automatizado. Además se trata de documentar los requerimientos de los usuarios para el nuevo sistema de información.

Entradas: Documentos usados actualmente en el área en que funcionará el nuevo sistema.

Salidas: Documento desarrollado por el Ingeniero a cargo del desarrollo del sistema, el mismo tiene el registro de las necesidades planteadas para el nuevo sistema.

Responsable (s): Ingeniero a cargo del desarrollo del nuevo sistema

Estimaciones de la actividad

Duración: 1 mes

Costo Final: $ 27540

Fecha Inicio: 25 / 11 / 2003 Fecha Término: 06 / 01 / 2004

42

4.3. La gestión del tiempo en el desarrollo de Sistemas de Información 4.3.1. Creación 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 técnica se le conoce como secuenciamiento de las actividades. Es recomendable crear un diagrama de red el cual permita observar el orden de precedencia lógico 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 relación de precedencia lógica entre si, se deben plantear algunas preguntas con relación a cada actividad individual:

1. ¿Qué actividades se tienen que terminar inmediatamente antes de que se pueda iniciar la siguiente?

2. ¿Cuáles actividades se pueden hacer de manera simultánea? 3. ¿Qué actividades no se pueden iniciar hasta que se termine la actual?

Contestándose 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.

43

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. Además de la técnica expuesta existen otras que quedan fuera del alcance de esta investigación y que también 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 más usado por los productos de software orientado a administración de proyectos, como es el caso del producto Microsoft Project. El diagrama de red se puede construir usando algún tipo de software que permita establecer relaciones entre un conjunto de tareas o actividades, como ejemplo para esta investigación se usó un programa conocido como el Pert Chart Expert , este software permite interactuar con el Microsoft Project. En el caso del Sistema de Automatización 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 Gestión del Alcance. Una muestra del diagrama obtenido se observa en la siguiente

44

figura y en el anexo 10 encontrará el diagrama de red entero que se construyo para el sistema de automatización de actas.

Figura 4: Diagrama de red del Sistema de Automatización de Actas

4.3.2. Estimación 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 cálculos relacionados con la duración 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 descripción de roles, o se podría utilizar una plantilla para registrar lo anterior. En el ejemplo siguiente se muestra como se utilizarían ambos productos para el Sistema de Automatización Actas, y en el anexo 11 se adjunta la plantilla para registrar las responsabilidades del equipo de trabajo.

45

Figura 5: Organización del equipo de trabajo para el Sistema de Automatización de Actas

La descripción de las responsabilidades de cada miembro del equipo de trabajo en el proyecto de Automatización de Actas quedaría de la siguiente forma: Director del Proyecto Le corresponderá la coordinación de todas las actividades, y de las tareas relacionadas con el área de Informática, además será su responsabilidad directa el análisis de la información, el diseño del nuevo sistema, la programación del sistema y la implementación del mismo. También será el encargado de mantener comunicados en forma continua a todos los participantes del proyecto. Le corresponderá la creación del manual del sistema y de la documentación necesaria para retroalimentar al equipo de trabajo con todos los términos relacionados con un Sistema de Computación, y se encargará de preparar la capacitación en el uso del nuevo sistema. Se encargará también de coordinar todas las tareas y actividades relacionadas con las telecomunicaciones.

Automatización del Libro de Actas

Abogada encargada dela Normativa en

la Supen

Director de la División legal

Analistas de Operadoras

Directora de la Divisiónde Operadoras

Encargado de Telecomunicacionesde la Supen

Director del proyectoEncargado del área

de Automatización deOficinas

46

Equipo del proyecto

Se encargará de definir los requerimientos para el nuevo sistema, y además 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á también de conseguir cualquier documentación que el Director del Proyecto considere necesaria para la ejecución del proyecto.

Encargada de la Normativa Se encargará de desarrollar las disposiciones legales que regularán el uso del nuevo sistema por parte de las Operadoras de Pensiones. Deberá estudiar el manual del usuario creado por Informática para que las disposiciones legales correspondan directamente a los términos que componen al nuevo sistema. Y la plantilla para registrar las responsabilidades en el proyecto de Actas se usaría de la forma en que se muestra en el cuadro 4.

47

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 duración 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 duración de las actividades del proyecto, esta acción se puede ejecutar haciendo uso de algún software para apoyar el manejo de proyectos, uno de los más comunes en el Microsoft Project. Una de las grandes ventajas que agrega este producto es que es capaz de identificar la ruta crítica del proyecto, esta es la ruta de actividades más larga del proyecto, y por lo tanto es la que requiere más tiempo. Este tipo de trabajo se puede hacer manualmente y consiste en encontrar las actividades que tienen la menor

48

holgura, entendiéndose por holgura la cantidad de tiempo que una actividad puede ser retrasada sin afectar la fecha de terminación del proyecto. A continuación se muestra como el programa Microsoft Project representa la ruta crítica de un proyecto:

Figura 6: Ruta Crítica del proyecto

En la imagen se puede observar una gráfica de Gantt con dependencias entre las actividades que componen el proyecto. Las actividades que están marcadas con color rojo son las que pertenecen a la ruta crítica 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 están en la ruta crítica, y por lo tanto tienen holgura para manejar algún tipo de atraso.

49

4.3.3. Técnica Pert Un aspecto importante en la etapa de gestión del tiempo es el efecto que crea la asignación de recursos al cronograma del proyecto, ya que esta acción puede alterar la ruta crítica debido a la disponibilidad de los recursos. Este efecto provoca que la ruta crítica se convierta en la cadena crítica, y la podemos definir como la alteración de la ruta critica por el efecto de la asignación de los recursos al proyecto (PMI, 2004). Cuando exista incertidumbre sobre la duración de algunas actividades de la ruta crítica en el proyecto se podrá hacer uso de una técnica que permite aplicar cálculos probabilísticas para estimar la duración de las actividades. Este método se basa en el uso de tres tipos de estimaciones:

• Más probable: Es aquel en que se completara con más frecuencia una actividad en particular en condiciones normales. Se hace el calculo de la duración de las actividades teniendo en cuenta los recursos que probablemente serán 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 cálculo de la duración de las actividades basándose en el mejor escenario posible de lo que se describe en la estimación más 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 cálculo de la duración de las actividades basándose en el peor escenario posible de lo que se describe en la estimación más probable.

El método es conocido como la técnica PERT (Técnica de Evaluación y Revisión de Programas) Y debido a que establecen tres evaluaciones de tiempo hace posible tomar en cuenta la incertidumbre

50

a la hora de estimar cuanto durará una actividad, y también permite calcular la probabilidad de que el proyecto se complete antes de la fecha estimada de finalización del proyecto. Para usar esta técnica se deberá hacer uso de la siguiente formula:

Aplicando la formula se obtiene el que corresponde al tiempo estimado de finalización de la actividad (partiendo del hecho de que los tres tiempos mantienen un comportamiento de distribución

Beta). , y corresponden a los tres tiempos estimados para completar una actividad (ver explicación anterior). Otro cálculo que se deberá efectuar es obtener la Varianza (de la distribución beta) para cada actividad en la que existe incertidumbre. Para obtener el cálculo se deberá aplicar la siguiente formula:

= Varianza.

y corresponden a los estimados pesimista y optimista. Sumando los tiempos esperados de cada actividad y también sumando las varianzas de cada una podremos encontrar el tiempo promedio para todo el proyecto y también la varianza para todo el proyecto. Teniendo estos dos valores se procede a obtener la desviación estándar usando la siguiente formula:

51

De acuerdo a Clements y Gido (2003), la formula lo que indica es que la desviación estándar corresponde a la raíz cuadrada de la suma de las varianzas de las actividades del proyecto. Con el cálculo de la desviación estándar y el promedio de duración del proyecto se podrá saber que tiempos de finalización corresponden a un 68% de probabilidad, cuales pertenecen a un 95% y cuales pertenecen a un 99%. Esto se debe a tener relación directa con la teoría de la distribución normal. De acuerdo a esta teoría se obtiene lo siguiente:

El 68% corresponde al tiempo promedio de duración +/- una desviación estándar.

El 95% corresponde al tiempo promedio de duración +/- dos desviaciones estándar.

El 99% % corresponde al tiempo promedio de duración +/- tres desviaciones estándar. A continuación se muestra un ejemplo con estos cálculos: Cuadro 5: Uso de tiempos estimados y probabilidades

52

Se observa que en las columnas Te y VAR corresponde a los cálculos del tiempo estimado y de la varianza haciendo uso de las formula antes descritas. También se observa las sumatorias de ambas columnas y el valor DE corresponde a la desviación estándar de la varianza. Analizando la información anterior se puede deducir que el tiempo medio de duración será de 105 días y aplicando la teoría de la distribución normal deducimos que existe un 68 % de terminar el proyecto entre 100 y 109 días, que existe un 95% de terminar entre 96 y 114 días y que existe un 99% de terminar entre 91 y 118 días. Y por ultimo teniendo los datos anteriores (Tiempo estimado de duración y la Desviación estándar) 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 cálculo se hace por medio de la función de Distribución Normal que usa estos dos valores como parámetros y emite la probabilidad correspondiente:

De la tabla anterior se deduce que para terminar el proyecto en 110 días se tiene un 86.12 % de probabilidad de finalización en ese tiempo, mientras que para terminar en 90 días apenas se tiene un 0.033% de probabilidad.

53

Seguidamente se muestra como se aplicaría este conocimiento al proyecto de Automatización de Actas: Cuadro 6: Uso del Pert en el Proyecto de Automatización de Actas

Y la tabla de probabilidades quedaría de esta forma:

54

De igual forma que en el ejemplo anterior, el análisis seria el mismo, para finalizar el proyecto en 120 se tiene un 48.97% de probabilidad y para terminar el proyecto en 136 días se tiene un 99.89% de probabilidad. En el anexo 12 se muestra la implementación completa del análisis PERT en el proyecto de Automatización de Actas. En el momento en que se tenga claridad en la duración 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 propósitos 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 investigación, 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 también 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 ejecutarán las actividades del proyecto. A Continuación se presenta una muestra del cronograma que se usará en el proyecto de Automatización de Actas.

55

Cuadro 7: Cronograma del Proyecto de Automatización de Actas

Y en el anexo 13 se muestra el cronograma completo del proyecto de Automatización de Actas.

56

4.4. La gestión del riesgo en el desarrollo de Sistemas de Información 4.4.1. Identificación de riesgos

Otro aspecto muy importante que se debe vigilar en la creación de un plan para un proyecto informático 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 están relacionados con eventos que pueden afectar los objetivos del proyecto. Se debe tener presente que los objetivos del proyecto están relacionados con tres factores, que son: El tiempo, el costo y el desempeño; y al referirse a un efecto negativo lo que significa es que algún evento podría provocar atrasos en el tiempo, aumentos en los costos del proyecto, y disminución 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 definición del alcance del proyecto, esto quiere decir que no se puede pensar en planificación de riesgos si no se tiene bien definido el alcance del proyecto. En la primera sección de este capitulo de desarrollo se cubrió el tema del alcance del proyecto. Analizando la definición del alcance se podrán detectar riesgos posibles que estén relacionados con las actividades, y/o productos entregables del proyecto. El análisis se puede hacer usando diferentes técnicas, 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 dirección de un moderador. En esta técnica no se debe hacer ninguna restricción sobre las ideas que se manifiesten en las reuniones del equipo. Posteriormente el equipo podrá hacer un filtrado, pero en

57

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

4.4.1.2. Técnica Delphi Se trata de buscar un consenso de expertos referente a los riesgos del proyecto. Ellos participan de forma anónima. 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 técnica 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 información y una lista de supuestos. Los entrevistados identifican los riesgos basados en sus experiencias.

4.4.1.4. Revisión de los supuestos o hipótesis Cada proyecto es concebido y planificado basado en un conjunto de hipótesis, escenarios, suposiciones, premisas o creencias, que se consideran verdaderos, reales o ciertos, sin necesidad de contar con evidencia o demostración, por lo tanto es recomendable medir riesgos posibles que podría presentarse en relación con los supuestos o hipótesis.

4.4.1.5. Diagramas de causa y efecto Estos diagramas también 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

58

horizontal y luego se trazan flechas que apuntan al eje horizontal con un ángulo de inclinación con respecto al eje central. Cada una de estas flechas serán categorías de riesgos que pueden afectar al proyecto, y luego para cada categoría 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 después de la identificación de riesgos dentro del proyecto se haga una agrupación de tal forma que se puedan crear categorías en donde se pueda representar en forma jerárquica una estructura que desglose los riesgos posibles del proyecto. Esta estructura se conoce como RBS (Estructura de desglose del riesgo) y en la siguiente página se muestra un ejemplo.

59

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 serán una gran cantidad se debe pensar en cuales deben recibir la mayor atención, evidentemente los riesgos que deben recibir la mayor atención son los que tendrían 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 técnica que se conoce como el Análisis Cualitativo de Riesgos y se complementa con otra que se conoce como Análisis Cuantitativo de Riesgos. Seguidamente se explican en que consisten ambos y como usarlos.

4.4.3. Análisis Cualitativo de Riesgos El análisis 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 causaría la ocurrencia del evento de riesgo, también se usa la escala de 0 a 1. Luego se obtiene el producto de ambos valores y dependiendo del valor obtenido

60

se ubicará al riesgo como Alto, Moderado o Bajo. La escala que se podrá usar para esta clasificación 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 análisis cualitativo de riesgos se deben registrar los riesgos y se recomienda trabajar con una hoja electrónica con al menos las siguientes columnas:

4.4.3.1. Código identificador del riesgo El código de identificación permite trabajar de forma estandarizada y ser incluido en una base de datos de riesgos. Este podría tener, por ejemplo, la estructura RX999, donde 999 es un consecutivo y la “X” es la categoría del Riesgo: RA- Riesgo de Administración de Proyectos RE- Riesgo Externo RO- Riesgo Organizacional RT- Riesgo Técnico

4.4.3.2. Causa Las causas se podrán tomar de la RBS (Estructura de desglose del riesgo) y se relacionan con las categorías de riesgos previamente analizadas (PMI, 2004). Evento o condición del riesgo: El evento que causa el riesgo. Consecuencia o descripción: Descripción del riesgo.

61

Relación o dependencia con otro riesgo: En el caso que aplique se indica el código de otro riesgo que esté relacionado con el actual, a continuación se muestra un ejemplo: Código Causa Evento Descripción del

riesgo RE001 Presencia de asbesto Enfermedades del personal

producto de la presencia de asbesto

Atraso en el calendario por incapacidades.

Una vez que se tiene el Registro de Riesgos con el detalle de todos los riesgos identificados, se procede a ordenarlos según un criterio de prioridad, para luego enfocarse en los más importantes. El criterio que se utiliza en este tipo de análisis es por rango o calificación y para obtenerlo se debe ubicar la probabilidad y el impacto en las escalas respectivas usando el criterio de un equipo de gestión de riesgos que podrá ser el mismo que trabajó en la identificación de riesgos. Las escalas a utilizar se deben especificar en el apartado de gestión de riesgos del plan del proyecto general y con ellas se crea la matriz PxI. A manera de ejemplo se podrán 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

62

Para ubicar el impacto de cada riesgo en la escala se podrían utilizar los siguientes criterios: Cuadro 10: Descripción del impacto según la escala Objetivo del proyecto

Muy Bajo 0.05

Bajo 0.1

Moderado 0.2

Alto 0.4

Muy Alto 0.8

Costo Insignificante Incremento del costo

Incremento del costo < 5%

Incremento del costo entre el 5 – 10%

Incremento del costo entre el 10 – 20%

Incremento del costo > 20%

Tiempo Insignificante variación del calendario

Variación del calendario < 5%

Desviación general del proyecto 5 – 10%



Alcance Reducción del alcance apenas perceptible

Áreas menores del alcance son afectadas

Áreas mayores del alcance son afectadas

Reducción del alcance inaceptable para el cliente

El producto final del proyecto es inservible

Calidad Degradación de la calidad apenas perceptible

Solo aplicaciones muy especificas son afectadas

La reducción de la calidad demanda la aprobación del cliente

Reducción de la calidad inaceptable para el cliente

El producto final del proyecto es inservible

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

63

Cuadro 11: Marcadores de riesgo Impacto Probabilidad

Muy Bajo 0.05

Bajo 0.1

Moderado 0.2

Alto 0.4

Muy Alto 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

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 usarán 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 continúa con la creación de la hoja electrónica en donde se documentará el análisis 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.

64

4.4.3.5. Rango (PxI) Es el producto de la multiplicación de la Probabilidad por el Impacto (PxI). A cada riesgo (fila en la hoja de cálculo) se le puede asignar un color (Rojo, Amarillo o verde) según su rango de calificación 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 calificación del riesgo general del proyecto. En el caso del Sistema de Automatización de Actas el resultado del análisis cualitativo se muestra en el siguiente cuadro: Cuadro 12: Análisis cualitativo del sistema de automatización de actas

65

4.4.4. Análisis Cuantitativo de Riesgos Una vez que se tiene el análisis cualitativo se puede usar el análisis cuantitativo de riesgos para obtener más información sobre las tareas que presentan mayor prioridad de atención por presentar riesgos más altos. El proceso de análisis cuantitativo ayuda a analizar numéricamente 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 análisis se puede obtener lo siguiente:

• Evaluación 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 atención cuantificando sus contribuciones relativas al riesgo del proyecto.

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

• Determinar la mejor decisión de dirección de proyectos cuando algunas condiciones o resultados son inciertos.

Existen diferentes técnicas que se pueden usar para realizar un análisis cuantitativo, algunas de ellas son:

1. Enfoque PERT 2. Análisis mediante un árbol de decisiones 3. Simulación Montecarlo

66

4.4.4.1. Enfoque PERT En la sección de gestión del tiempo se estudió esta técnica 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 crítica, las cuales fijan la fecha de terminación del proyecto. Los cálculos que se hacen con la técnica PERT requieren de tres valores de tiempo, los valores optimistas, los más 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 duración de cada actividad y también es posible obtener la desviación estándar del tiempo promedio. Usando la distribución normal como distribución de probabilidades es posible calcular la probabilidad de finalizar el proyecto para un período determinado. Esta técnica puede ayudar a obtener diferentes escenarios del proyecto haciendo análisis con las actividades que manifiestan mayor probabilidad de riesgo en el análisis cualitativo. Con los resultados que se obtengan del análisis PERT se tendrá más criterio para planificar las respuestas a los riesgos.

4.4.4.2. Análisis del Valor Monetario Esperado (EVM) Es un concepto estadístico que calcula el resultado promedio cuando el futuro incluye escenarios que pueden ocurrir o no (es decir, análisis 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 técnica se recomienda para usarse como reservas de contingencia en riesgos de poco impacto. A continuación se muestra un ejemplo:

67

Cuadro 13: Aplicación del Análisis del Valor Monetario Esperado

Evento de Riesgo Impacto $ Prob. % VME 1 5.500 20% 1.100 2 2.800 10% 420 3 10.750 15% 1.613 4 825 70% 578 Totales 19.875 3.710

4.4.4.3. Análisis mediante árbol de decisiones

Un árbol de decisiones es un diagrama que describe una decisión bajo las consideraciones e implicaciones de la selección 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 decisión 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 cuál es la decisión que se necesita tomar. (Los recuadros representan decisiones). Al final de cada línea se debe estimar cuál puede ser el resultado, Si el resultado es incierto, se puede dibujar un pequeño círculo (nodo de posibilidad o chance). Si el resultado es otra decisión que necesita ser tomada, se debe dibujar otro recuadro (nodo de decisión). Si se completa la solución al final de la línea, se puede dejar en blanco. Desde los círculos se deben dibujar líneas que representen las posibles consecuencias. También se debe hacer una pequeña inscripción sobre las líneas 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.

68

Figura 9: Ejemplo de un árbol de decisiones

4.4.4.4. Evaluación del árbol de decisiones El análisis 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 evalúan los nodos de decisión, se debe calcular el costo total basado en los valores de los resultados que ya se han calculado. Este cálculo dará un valor que representa el beneficio de tal decisión. Cuando ya se haya calculado el valor de estas decisiones, se debe elegir la opción que tiene el beneficio más importante como la decisión tomada.

4.4.4.5. Simulación Monte Carlo Esta técnica 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 distribución estadística de las fechas de conclusión posibles. Para implementar esta técnica es necesario el uso de algún software de computadora orientado a este tipo de análisis, la cantidad de operaciones y de repeticiones no se podrían ejecutar

69

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

4.4.4.5.1. Pasos básicos del Método Monte Carlo 1. Se definen las variables de entrada y las de salida. 2. Se determina cuáles entradas en el modelo son inciertas, y se representan usando rangos de

valores con funciones de distribución de la probabilidad. 3. Se corre la simulación con el número 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 Automatización del Libro de Actas se utilizó el software @Risk para ejecutar el análisis cuantitativo. Una característica 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 cálculos probalísticos. La forma en que se implementó este análisis fue la siguiente: Primero se seleccionaron actividades que se relacionan con los eventos de riesgo de mayor prioridad de atención, estas actividades se pueden definir como actividades con incertidumbre, pues son las que podrían causar impactos en el proyecto. Luego se establecieron tres valores para las fechas de inicio y la duración de cada una de las actividades seleccionadas. Estos tres valores se usaron como entrada a dos funciones de distribución probabilística que usa el @Risk como instrumentos de trabajo, una función es la función Triangular y la otra es la distribución

70

Uniforme. Estas dos funciones tienen principios comunes a los explicados en el cálculo del tiempo estimado de la técnica PERT que usando tres valores pueden emitir un valor promedio que resulta útil en análisis donde haya incertidumbre. En el siguiente cuadro se muestran las actividades escogidas y los tres valores de fecha y duración que se le dieron al @Risk para que hiciera los cálculos de iteración: 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 probabilísticas 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 técnicas probabilísticas que nos dicen que después de muchas repeticiones de un evento se pueden hacer predicciones, y el @Risk utiliza estos principios matemáticos para emitir sus resultados. Una muestra de los resultados de estas 100 repeticiones para dos de las actividades seleccionadas se observa en cuadro 15.

71

Cuadro 15: Repeticiones con tres valores

Después de que se ejecutan las 100 repeticiones se obtiene información de las actividades evaluadas, así como de todo el proyecto. La información emitida se basa en tres valores: Un mínimo, un promedio, y un máximo, esto como producto de las 100 repeticiones. La información resultante del análisis se muestra en el cuadro 16.

72

Cuadro 16: Resultado del análisis de las 100 repeticiones

Con la información anterior se puede ajustar el tiempo de proyecto y las fechas de las actividades en una forma más científica, por ejemplo si se observa la parte superior del cuadro anterior se podrá notar que el análisis está emitiendo fechas posibles de finalización y tiempo posible de finalización del proyecto con fundamentos matemáticos. Un gráfico de mucho valor que se puede obtener en este tipo de análisis es el gráfico de Tornado, en él se muestran las actividades de mayor impacto en el proyecto. Estas actividades estarán en la ruta crítica y son las que hay que ponerles mayor atención durante el proyecto. En la figura 10 se muestra el gráfico de Tornado para el análisis practicado en el proyecto de Automatización de Actas; se puede notar que la actividad de mayor impacto es “Documentar y diagramar el nuevo sistema”.

73

Figura 10: Grafico de Tornado del proyecto de automatización de Actas

4.4.5. Planificación 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 planeación 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 función de la prioridad de estos, incorporando recursos y actividades en el presupuesto, cronograma y en el plan de gestión del proyecto, según sea necesario. Esto implica hacer variaciones en el alcance, lo cual provoca cambios en los parámetros base del proyecto (PMI, 2004).

Se debe utilizar para cada riesgo la estrategia o combinación de estrategias adecuada (efectiva) y desarrollar acciones específicas para implementar dicha estrategia. Es de buena práctica 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.

74

Como reacción 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 pérdida 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 comparación, 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 administración, 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 garantías, y los contratos.

75

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 "tamaño" del riesgo para hacerlo más aceptable. Mitigar la amenaza implica reducir la probabilidad de ocurrencia y/o consecuencias a un umbral aceptable. Existen métodos diferentes que se pueden emplear para mitigar el riesgo, algunos de ellos son: A. Mitigación mediante separación La separación 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 pérdidas individuales sean más pequeñas y predecibles, un ejemplo es la división de un proyecto en varias fases. B. Mitigación mediante duplicidad La duplicidad involucra una reproducción completa de los bienes u operaciones para mantenerlos en reserva. El duplicado no se utiliza a menos que el original se dañe (o viceversa). Se utiliza en riesgos que de suceder serán catastróficos. Como ejemplo de esta estrategia se pueden usar los respaldos de una base de datos, o de Software. C. Mitigación mediante elementos redundantes No es una duplicidad completa del elemento, sino que se diseña otra variante, por si el original falla. Se trata de reducir el impacto de riesgos técnicos, 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 común tanto para las amenazas como para las oportunidades, el equipo del proyecto decide no modificar el plan de gestión 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.

76

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 también las posibles desconocidas. (Implica actuar como un asegurador, con aplicación de técnicas de control de riesgos, financiamiento de pérdidas 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: Cálculo de reserva para contingencias

Descripción del Evento de Riesgo

Probabilidad de Ocurrencia

Costo Estimado De Consecuencias

Exposición al Riesgo

Evento No.1 Prob. P1 Costo C1 P1xC1 Evento No.2 Prob. P2 Costo C2 P2xC2 Evento No.3 Prob. P3 Costo C3 P3xC3 Evento No.n Prob. Pn Costo Cn PnxCn Contingencia Estimada del Proyecto ∑ (Pi x Ci) 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, además se hace un cálculo 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 debería de usarse solo en eventos que en el caso de cumplirse no sean catastróficos para el proyecto. Se debe tener presente que los costos se deberán tratar como un componente más del plan del proyecto. En esta investigación esta área no será cubierta, sin embargo se aclara que los costos representan uno de los componentes más importantes del proyecto.

77

Volviendo al proyecto de Automatización del Libro de Actas las acciones que se tomarán como respuesta a los riesgos que se detectaron se muestran en el cuadro 18. Cuadro 18: Respuesta a los riesgos en el Proyecto de Automatización 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 explicación anterior, en donde se indicó la necesidad de establecer una frecuencia y un costo. El resultado de este análisis en el proyecto de Actas se observa en el cuadro 19.

78

Cuadro 19: Plan de Contingencias en el Proyecto de Automatización de Actas

Con las respuestas anteriores se debe volver a revisar la definición del alcance y del tiempo, porque al haberse incluido más 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 distribución de recursos. En el caso del proyecto de Actas se crearon las siguientes actividades adicionales, las cuales también 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 estrés.

• Contratar experto en redes.

• Compra de servidor redundante.

• Contratar asesor legal externo. • Contratar asesor de definición de requerimientos.

Total ($)

79

4.5. La gestión de calidad en los proyectos de desarrollo de Sistemas de Información

4.5.1. Repaso de los principales conceptos teóricos

Haciendo una revisión de los conceptos teóricos más importantes de la gestión de calidad tenemos lo siguiente: La Gestión de Calidad incluye todas las actividades relacionadas con políticas, objetivos y responsabilidades de modo tal que el proyecto satisfaga las necesidades por las cuales se ejecutó. La Gestión de Calidad se implementa a través de políticas, procedimientos y los procesos de Planificación 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, según corresponda. Los procesos de la Gestión de Calidad incluyen lo siguiente: Planificación de Calidad: Identifica qué normas de calidad son relevantes para el proyecto y determina cómo 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 específicos 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 recomendación para tener éxito en los proyectos de desarrollo de sistemas se presentan las siguientes herramientas que estarán relacionadas con el proceso de Planificación de la Calidad. El Aseguramiento y el Control de la Calidad sólo se podrán poner en práctica hasta que se implemente el proyecto, por lo tanto en esta investigación se brindarán instrumentos relacionados con la Planificación de Calidad que permitirán que los proyectos de desarrollo de sistemas se puedan

80

implementar bajo un entorno de calidad, y por consecuencia estarán 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 información 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 estándares que regulen la información desde el inicio hasta la implementación de los sistemas. El problema nace desde el inicio del proyecto cuando los creadores de los sistemas de información no entienden cuáles son las necesidades del cliente y por lo tanto a lo largo del proceso serán incapaces de satisfacerlas. Los proyectos atienden a especificaciones que no responden a las necesidades mínimas del cliente y entran en estados fluctuantes provocados por cambios constantes que afectan tanto los recursos materiales como humanos, generando fracasos frecuentes en los procesos de Administración del Proyecto y en los Productos del Proyecto. Lo que se propone en este capítulo es desarrollar un estándar de Calidad que permita ordenar y controlar el desarrollo de sistemas, de tal forma que se cumpla con el objetivo de la Administración de Calidad, que consiste en asegurar que el proyecto satisfaga las necesidades para las cuales inició, identificar los estándares de calidad relevantes al proyecto y determinar cómo satisfacer dichos estándares (Chamoun, 2002). El estándar propuesto consiste en un procedimiento para el desarrollo de sistemas, compuesto por pasos que se deberán seguir durante el desarrollo, así como por formularios que se deberán usar en conjunto con el procedimiento, y por instrucciones de trabajo que servirán para detallar como hacer las cosas. Además se adjunta un diagrama de flujo para representar gráficamente el procedimiento recomendado.

81

Este procedimiento será parte de la Gestión de Calidad que se requiere en todo proyecto de desarrollo de sistemas, de tal forma que se pueda tener garantía de que los productos entregables satisfacen los requerimientos iniciales. Los formularios que se usarán servirán para el aseguramiento de la calidad, puesto que una vez que se ponga en marcha la implementación del proyecto se convertirán en registros, los cuales se podrán revisar para ejecutar el Aseguramiento de la Calidad, y si se detectan malas prácticas, o problemas en el proyecto se podrán hacer los ajustes necesarios para alinearlo. Con lo anterior se estará ejecutando el proceso de Control de Calidad y además, se estará trabajando bajo un ambiente de mejora continua, el cual es el ciclo actual con que se trabaja en la Gestión de la Calidad. A continuación 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 cómo realizar ciertas acciones específicas que requiere el procedimiento. A continuación se identifican los componentes que se utilizarán, así como el procedimiento y más adelante se ampliará más sobre el contenido de los componentes.

4.5.3.1. Formularios utilizados FO-01 Solicitud de un nuevo sistema FO-02 Bitácora de problemas encontrados FO-03 Solicitud de cambios FO-04 Informe del avance del proyecto FO-05 Aceptación del producto o servicio FO-06 Informe de lecciones aprendidas FO-07 Requerimientos del sistema

82

4.5.3.2. Instructivo relacionado IT-01 Desarrollo de Sistemas

4.5.3.3. Descripción de Participantes Usuario = Persona que solicita el desarrollo de un nuevo Sistema de Información.

Jefe de T.I. = Funcionario a cargo del Departamento de Tecnologías de Información.

Ingeniero de Sistemas = Funcionario del Departamento de Tecnologías de Información encargado de desarrollar el Software o servir como contraparte en caso de contratación externa. Jefe del Usuario = Superior directo de la persona que solicita el Sistema de Información

Procedimiento para la solicitud de un Nuevo Sistema

RESPONSABLE PASO DESCRIPCIÓN USUARIO 1 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 envía al Jefe de T.I.

JEFE DE T.I. 2 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 (contratación) o interno.

83

RESPONSABLE PASO DESCRIPCIÓN SI ES POR CONTRATACIÓN EXTERNA INGENIERO DE

SISTEMAS 1 Analiza, investiga y elabora los términos de referencia para

el desarrollo del proyecto y lo remite al JEFE DE T.I. para su análisis y discusión.

JEFE DE T.I. 2 Recibe los términos 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. 3 Recibe los términos de referencia aprobados para el desarrollo del proyecto e inicia el proceso de contratación, usando el procedimiento IT-02 selección y valoración de proveedores.

INGENIERO DE

SISTEMAS 4 Coordina con la empresa adjudicataria una reunión para

analizar y discutir el alcance del proyecto. INGENIERO DE

SISTEMAS 5 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 consecución.

INGENIERO DE 6 Establecen los medios de control para ir valorando el

84

RESPONSABLE PASO DESCRIPCIÓN SISTEMAS Y EL

JEFE DE T.I.

avance del proyecto y usan el formulario FO-04 Informe de Avance del Proyecto para dar seguimiento a las diferentes etapas de la ejecución del proyecto por parte de la Empresa Adjudicataria.

INGENIERO DE

SISTEMAS 7 Recibe de la Empresa Adjudicataria, los informes o

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

JEFE DE T.I. 8 Comunica la disponibilidad del sistema desarrollado y coordina con el JEFE DEL USUARIO que requiere de dicho sistema la respectiva capacitación instructivo IT-03 y autoriza la Instalación del Sistema. FIN DE CONTRATACION EXTERNA

SI NO ES CONTRATACIÓN EXTERNA

INGENIERO DE

SISTEMAS 1 Recibe la solicitud de desarrollo de nuevo sistema

(Formulario FO-01), Convoca a una reunión 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 Desarrollo de Sistemas.

85

RESPONSABLE PASO DESCRIPCIÓN

INGENIERO DE

SISTEMAS 2 Confecciona periódicamente el Informe de Avance del

Proyecto, formulario FO-04 y lo remite al JEFE DE T.I. para su aprobación. Se debe utilizar en todo el proceso el formulario FO-02 Bitácora de Problemas encontrados, para llevar documentados los problemas que se le presenten.

JEFE DE T.I. 3 Recibe el Informe de Avance del Proyecto, lo analiza y

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

JEFE DE T.I. 4 Recibe la nota de aceptación del sistema por parte del usuario (FO-05 Aceptación de Producto o Servicio) y comunica, la disponibilidad del sistema desarrollado. Coordina con el Jefe del Usuario, para que inicie la respectiva capacitación. Autoriza la instalación del sistema.

INGENIERO DE

SISTEMAS 5 Prepara un informe con todos los problemas encontrados en

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

INGENIERO EN

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

pruebas del sistema.

86


INGENIERO DE

SISTEMAS 7 Prepara el ambiente informático 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 estándar del Calidad planteado para el desarrollo de sistemas consiste en un diagrama de flujo que representa gráficamente la secuencia establecida en el procedimiento anterior. Esta herramienta permite percibir algún tipo de error que exista en el procedimiento y que textualmente sea más difícil detectar. En la figura 11 se presenta el diagrama de flujo que equivale al procedimiento anterior.

87

Figura 11: Flujo del desarrollo de sistemas

88

4.5.3.5. Uso de formularios El formulario correspondiente a la solicitud de un nuevo sistema tendrá el siguiente formato:

Estandarización del Proceso de Desarrollo de Sistemas

Pagina 1de 1

Solicitud de un Nuevo Sistema FO-01

Fecha de aprobación:

Espacio para ser llenado por el Usuario Gestor del Proyecto:

Nombre de la persona que ideó el proyecto ( usuario )

Definición del Problema:

Defina el problema

Antecedentes:

Digite los antecedentes del problema

Objetivos Objetivo General Digite el objetivo general del Problema Objetivos específicos

1. Digite un objetivo especifíco

2. Digite un objetivo especifíco 3. Digite un objetivo especifíco 4. Digite un objetivo especifíco 5. Digite un objetivo especifíco Factores críticos del Éxito:

Digite los factores que puedan atentar contra el exito del proyecto.

Productos o Servicios:

Indique los productos o servicios esperados

Beneficios:

Digite los beneficios que se esperan obtener

Usuario Responsable: 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 Bitácora de Problemas Encontrados tendrá el formato que se presenta en la figura 13.

89

Bitácora de PROBLEMAS ENCONTRADOS EN UN PROYECTO (FORMULARIO FO-02) PROYECTO: ____________________________________________

FECHA PROBLEMA SOLUCION

Fecha: ______________ __________________________ ____________________ Nombre del Responsable Firma Figura 13: Bitácora de problemas encontrados El resto de documentos que usa el procedimiento recomendado se pueden encontrar en el anexo 16.

90

4.5.3.6. Instructivo de Trabajo El instructivo de trabajo IT-01 estaría compuesto por los siguientes pasos:

Estandarización del Proceso de Desarrollo de Sistemas

Pagina 1 de 2

Instructivo Desarrollo de Sistemas IT-01



INGENIERO DE SISTEMAS

1 Convoca a una reunión al usuario y analiza y discute más a fondo con él el sistema a desarrollar, así como los requerimientos del mismo. (FO-08 Requerimientos del Sistema)

INGENIERO DE

SISTEMAS 2 Elabora un diagrama de flujo del sistema, si fuese

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

INGENIERO DE

SISTEMAS 3 Genera el documento de Análisis 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 4 Transforma lo establecido en el análisis del sistema, en

estructuras de datos que puedan ser implementadas en un lenguaje de programación, elabora el modelo de entidad de relación y procede a desarrollar el Script de la base de datos.

INGENIERO DE

SISTEMAS 5 Elabora la programación en un lenguaje computacional

apropiado según sea el sistema, diseña las pantallas, así como el código de validación de datos. Elabora la lógica de la programación y realiza las pruebas de analistas con la finalidad de comprobar el buen funcionamiento del sistema.

USUARIO 6 Elabora los escenarios de pruebas para aplicarlos en el

91

Estandarización del Proceso de Desarrollo

de Sistemas

Pagina 1 de 2

Instructivo Desarrollo de Sistemas IT-01



ambiente de pruebas, en el cual se evalúan datos validos así como datos erróneos para analizar los resultados y con éstos la funcionalidad del sistema.

INGENIERO DE

SISTEMAS 7 Revisa en conjunto con el usuario los escenarios de pruebas

definidos y los documenta.

USUARIO 8 Aplica los escenarios de pruebas previamente definidos y revisados.

INGENIERO DE

SISTEMAS 9 Elabora en conjunto con el usuario un análisis 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 aceptación (FO-06 Aceptación 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 Bitácora de Problemas encontrados, para llevar documentados los problemas que se le presenten.

INGENIERO DE

SISTEMAS 13 Efectúa las modificaciones necesarias a la base de datos del

ambiente de producción.

INGENIERO DE SISTEMAS

14

Hace el pase del nuevo sistema al ambiente de producción.

FIN DEL INSTRUCTIVO

92

Con las herramientas anteriores se pretende minimizar los problemas de comunicación y además se intenta eliminar el desconocimiento que existe alrededor de las actividades informáticas. Estos detalles crean insatisfacción entre los stakeholders que interactúan en el desarrollo de sistemas, y es probable que si se implementa el estándar recomendado se aprovecharán 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 Automatización de Actas Electrónicas este será el estándar que se usará para la implementación del proyecto.

93

4.6. Guía de uso de la Metodología propuesta A continuación se muestra en forma grafica como se debería de usar la metodología propuesta en los capítulos anteriores relacionados con proyectos de desarrollo de sistemas. La forma en que se dará la explicación 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 capítulos anteriores En el diagrama siguiente se muestra en forma general la metodología 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. Figura 14: Diagrama general de la Metodología

Estudio de Prefactibilidad

GESTION DEL

ALCANCE

WBS y Otros Componentes

GESTION DEL

TIEMPO

Cronograma y Otros

Componentes

GESTION DEL

RIESGO

Análisis Cualitativo

Análisis Cuantitativo

Plan de Respuesta a los Riesgos y

otros Componentes

GESTION DE

CALIDAD

Procedimiento “Estándar de

Calidad

Formularios

Otros Componentes

WBS

94

4.6.1. Gestión del Alcance

Figura 15: Guía de uso de la metodología en la Gestión del Alcance.

Para trabajar en la Gestión 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 estaría hablando de productos como reportes, pantallas, manuales, paginas de Internet, Interfaces etc. Estos productos tendrán que haberse detectado en alguna fase de prefactibilidad que debe anteceder a la planeación del proyecto. En el esquema relacionado con la Gestión del Alcance se pueden observar los productos que se deberán obtener después de descomponer los productos entregables en actividades que permitan establecer los costos, el tiempo y asignar un responsable. Se deberán obtener 3 productos, los cuales son:

A. Plantilla con el Diccionario de la Estructura Detallada del Trabajo (EDT).

95

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 sección de anexos de esta investigación y en el capitulo de desarrollo correspondiente al Alcance.

4.6.2. Gestión del Tiempo

Figura 16: Guía de uso de la metodología en la Gestión del Tiempo

De acuerdo a la figura 16 de la Gestión del Tiempo se observa que la WBS que se obtuvo como producto de salida de la Gestión del Alcance se usa como elemento de entrada en la Gestión del Tiempo para calcular la duración de las actividades y la secuencia en que se hará el trabajo, además se deberán 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 también contar con la Plantilla de Responsabilidades del Equipo del Trabajo. Como instrumentos de trabajo para calcular los tiempos de duración se pueden usar la Técnica Pert y Software de Administración de Proyectos, en este desarrollo se utilizó el Microsoft Project y el Pert Chart Expert.

GESTION DEL TIEMPO

Estructura Detallada del Trabajo (WBS)

Técnica Pert Estructura del Equipo de Trabajo

Plantilla: Responsabilidades del

Equipo de Trabajo Software de Adm.

De Proyectos

Diagrama de Red del Proyecto

Cronograma del Proyecto

Organización del equipo de Trabajo

96

Como productos de salida de esta etapa se tendrán 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 sección de anexos de esta investigación y en el capitulo de desarrollo correspondiente al Tiempo.

4.6.3. Gestión del Riesgo

Figura 17: Guía de uso de la metodología en la Gestión del Riesgo

Mirando la figura 17 de la Gestión 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 Gestión del Alcance.

97

Analizando la WBS se podrá obtener un detalle de los riesgos detectados haciendo uso de las técnicas 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 podrán obtener elementos como: Una Estructura de Desglose de Riesgos y una Hoja Electrónica con los Riesgos identificados. Con estos dos productos se podrá crear el Análisis 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 Análisis Cualitativo se podrán usar otras herramientas para hacer un análisis más matemático del comportamiento del proyecto, a esto se le conoce como Análisis Cuantitativo de Riesgos en el Proyecto y consiste en usar técnicas como: El Análisis Pert, Árbol de Decisiones, Análisis del Valor Monetario Esperado y la Simulación Montecarlo (entre otros) para detectar el comportamiento en actividades que manifiestan algún tipo de incertidumbre. Con los resultados del Análisis Cuantitativo se podrán 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, además 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 sección de anexos de esta investigación y en el capitulo de desarrollo correspondiente al Riesgo.

98

4.6.4. Gestión de la Calidad

Figura 18: Guía de uso de la metodología en la Gestión de la Calidad

En la figura 18 de la Gestión de la Calidad vemos que para obtener el Estándar 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 Gestión de la Calidad, para el Estándar 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 cuáles serán los insumos que se necesitan para hacer el trabajo y cuáles serán los productos que se deberán obtener. Como elementos de salida de este proceso tenemos el procedimiento “Estándar” que se deberá usar y un diagrama de flujo del procedimiento que muestra gráficamente como se ejecuta el procedimiento.

Gestión 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

Aceptación del Producto

o Servicio FO-05

Requerimientosdel Sistema

FO-07

Diagrama deFlujo

PROCEDIMIENTO “ESTANDAR DE

CALIDAD”

Instrucciones de trabajo

Bitácora de Problemas

Encontrados FO-02

Rol de Participantes

99

Muestras de todos los productos de entrada y salida de esta fase del proyecto se encuentran en la sección de anexos de esta investigación y en el capitulo de desarrollo correspondiente al la Calidad. A continuación se presenta un resumen de los productos entregables que se deben generar en cada una de las etapas de cubiertas en la metodología. Cuadro 20: Detalle de Productos Entregables de la Metodología

Área Productos Entregables Gestión del Alcance Plantilla del Diccionario de la WBS Plantilla de Desglose del Trabajo a Realizar Estructura Detallada del Trabajo (WBS) Gestión del Tiempo Diagrama de Red del Proyecto Cronograma del Proyecto Organización del Equipo de Trabajo del Proyecto Gestión del Riesgo Estructura de Desglose del Riesgo Hoja Electrónica con Riesgos Identificados Gráfico de Tornado Actividades de Mayor Impacto en el Proyecto Cambios en el Cronograma Plan de Respuesta a los Riesgos Hoja Electrónica con Análisis Cualitativo Plan de Contingencias Escala de Probabilidad del Riesgo Cambios en el Alcance del Proyecto Escala de Impacto de los Riesgos Análisis del Valor Monetario Esperado Técnica Pert Árbol de Decisiones Simulación Montecarlo Gestión de la Calidad Diagrama de Flujo equivalente al Procedimiento

Desarrollado Procedimiento “Estándar de Calidad” Instrucciones de Trabajo Bitácora de Problemas Encontrados FO-02 Rol de Participantes

100

Á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 Aceptación del Producto o Servicio FO-05 Requerimientos del Sistema FO-07

101

5. Conclusiones

5.1. Después de haber desarrollado los capítulos anteriores relacionados con la Gestión 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 Información con las áreas del conocimiento del PMI.

5.2. El trabajo se desarrolló buscando un método que le permita a un Profesional de Informática

interactuar con otras actividades que no son comunes en el área de desarrollo de sistemas. Sin embargo, la metodología empleada trató de usar guías que ubiquen al Informático en otras tareas que permitirían que los proyectos de desarrollo de sistemas cumplan con estándares del PMI relacionados con la Administración Profesional de Proyectos.

5.3. Al haber implementado una metodología de trabajo que crea un vínculo entre la Informática

y la Administración 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 informáticos no utilizan técnicas de Administración 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 relación entre los requerimientos de los sistemas y la

definición 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 técnicas recomendadas todos los involucrados tendrán 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 permitirán calcular los tiempos de

los proyectos de software en una forma más científica. Estas técnicas no son comunes en

102

la Informática y si se utilizan en los proyectos de software se obtendrá más certeza en los cálculos de los tiempos.

5.6. Un área que se explota poco en los proyectos de desarrollo de sistemas es la Gestión de

los Riesgos y desafortunadamente es donde más afectan. De igual forma que en los capítulos anteriores, se mostraron herramientas que un Informático puede usar en el desarrollo de sistemas y que le proporcionarán más seguridad en sus proyectos. El trabajo se realizó de tal forma que el Profesional de Tecnologías sienta que cuenta con una guía que le lleva a la creación de un plan de riesgos sin necesidad de ser un experto en la Administración de Proyectos.

5.7. Finalmente, se creó un estándar que le permitirá al Informático 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 diseñados y que nada de lo que se haga quede fuera del estándar. Con lo anterior se podrá tener mucha seguridad de éxito en los proyectos de software, así como contar con registros históricos que muestren como se están llevando a cabo los proyectos.

5.8. Con las herramientas desarrolladas en esta investigación se cumple con el compromiso de

crear una metodología que le permita a un Profesional de Tecnologías de Información, trabajar bajo un entorno de Administración de Proyectos dentro del desarrollo de sistemas, sin ser un experto en el campo de la Administración Profesional de Proyectos.

103

6. Recomendaciones

6.1. Para finalizar con esta investigación se recomienda al lector investigar sobre las otras áreas

del conocimiento (9 en total) que son el estándar del Project Management Institute (PMI). Conociendo sobre las otras áreas de la Administración de Proyectos se tendrá un panorama más completo sobre el campo de los proyectos y con respecto a la investigación realizada se podrá explotar de una mejor forma.

6.2. La investigación realizada corresponde a un requisito académico, es por este motivo que no

se incluyeron las 9 áreas dentro de la metodología propuesta, debido a que se hubiera necesitado más tiempo para cubrir la Administración de Proyectos en forma total. Sin embargo, el objetivo fue desarrollar una metodología 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 orígenes son los fondos públicos.

6.3. Se recomienda al Profesional Informático tener presente los resultados de esta

investigación en los momentos en que le corresponda desempeñarse dentro de un proyecto de desarrollo de sistemas, porque es probable que si usan las técnicas expuestas en este trabajo, los resultados sean bastante exitosos y desafortunadamente no existe mucha presencia de este tipo de técnicas en el campo de los proyectos informáticos.

6.4. Esta investigación podrá servir como complemento a la formación de los profesionales en

Informática, porque cubre tópicos que no son cubiertos en las carreras de Computación y por lo tanto provoca que haya una deficiencia en la administración de los proyectos de desarrollo de sistemas. Al trabajar con una metodología como la desarrollada se garantiza mucha probabilidad de éxito en los proyectos informáticos.

104

6.5. Un aspecto importante que se debe considerar en el momento de aplicar una metodología es la importancia del apoyo de la alta gerencia. La experiencia ha demostrado que si no se cuenta con apoyo de la alta dirección es difícil implementar nuevas técnicas en cualquier área, sobre todo en el campo de Tecnologías de Información en donde se tiene contacto con toda la organización. Para implementar una metodología 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 recomendación adicional es tratar de ir introduciendo estas técnicas en forma

progresiva, esto para darle oportunidad a la organización de ir asimilando los nuevos procedimientos en una forma pausada, y con esto se logrará que la organización entre en etapas de maduración progresivas en el campo de la Administración Profesional de Proyectos y el impacto en el personal se podrá minimizar.

105

7. Bibliografía Chamoun, Yamal. Administración Profesional de Proyectos La Guía. México: McGraw Hill Interamericana, 2002. Gido, Jack; Clements, James. Administración Exitosa de Proyectos. México: Edamsa Impresiones, S.A. de C.V., 2003. Gordon, Davis; Olson, Margrethe. Sistemas de Información Gerencial. Colombia: Editorial Nomos Ltda., 1987. Laudon, Kenneth. Administración de los Sistemas de Información. México: Prentice Hall Hispoamericana S, A., 1996. Levine , Guillermo. Computación Moderna. México: Educación de México, S.A. de C.V., 2001. Martin, James; Odell, James. Análisis y Diseño orientado a objetos. México: Prentice May Hispanoamericana, S.A., 1992. Murdick, Robert. Sistemas de Información Administrativa. Primera edición. Mexico: Prentice-Hall., 1998. O’Brien, James. Sistemas de Información Gerencial. Colombia: McGraw-Hill. Interamericana S, A., 2001. PMI (Project Management Institute). Guía de los Fundamentos de la Dirección de Proyectos. PMBOK Guide. Tercera edición. Newton Square, Pennsylvania, E.U.A. 2004. Presuman, Roger. Ingeniería del Software. Cuarta edición. España: Edígrafos, S.A., 1997. Rodríguez, José de Jesús. Administración de Proyectos. 2003. Disponible en http://www.gestiopolis.com/recursos2/documentos/fulldocs/ger/adproysisinf.htm. Consultado el 10 de Octubre del 2005. Senn, James. Análisis y Diseño de Sistema de Información. Segunda edición. Mexico: Mc Graw-Hill, 1995.

106

8. ANEXOS

Taller de proyectos

Documents

Transcript of Taller de proyectos