PROPUESTA “GUÍA PARA LA GESTIÓN DE PROYECTOS DE...
128
PROPUESTA “GUÍA PARA LA GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE EN EL GRUPO DE RESIDENCIA EN LÍNEA DE INVESTIGACIÓN” Autores: JUAN SEBASTIAN SANTACRUZ PAREJA ANDRES DAVID RIOS LOPEZ Director: Luis Eduardo Peláez Valencia UNIVERSIDAD CATÓLICA POPULAR DEL RISARALDA PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES PEREIRA, COLOMBIA 2010
Transcript of PROPUESTA “GUÍA PARA LA GESTIÓN DE PROYECTOS DE...
PROPUESTA “GUÍA PARA LA GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE
EN EL GRUPO DE RESIDENCIA EN LÍNEA DE INVESTIGACIÓN”
Autores:
JUAN SEBASTIAN SANTACRUZ PAREJA
ANDRES DAVID RIOS LOPEZ
Director: Luis Eduardo Peláez Valencia
UNIVERSIDAD CATÓLICA POPULAR DEL RISARALDA
PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
PEREIRA, COLOMBIA
2010
PROPUESTA “GUÍA PARA LA GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE
EN EL GRUPO DE RESIDENCIA EN LÍNEA DE INVESTIGACIÓN”
Autores:
JUAN SEBASTIAN SANTACRUZ PAREJA
ANDRES DAVID RIOS LOPEZ
Informe Final
Director: Luis Eduardo Peláez Valencia
Acompañamiento: Grupo de Investigación TICs
UNIVERSIDAD CATÓLICA POPULAR DEL RISARALDA
PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
PEREIRA, COLOMBIA
2010
3
A nuestras familias por su total entrega y apoyo durante el transcurso de la
carrera.
A nuestros docentes a quienes expresamos nuestras más sinceras gracias por el
conocimiento impartido durante estos 5 años de estudios.
A nuestros amigos y compañeros por su compañía y aliento en cada momento.
4
AGRADECIMIENTOS
Los autores expresan sus agradecimientos a:
A Dios Por ser el guía en nuestro camino. A nuestros padres por su amor, comprensión y apoyo incondicional. A nuestros hermanos/as por alentarnos a alcanzar nuestras metas. A nuestros mentores y en especial a nuestro asesor por su orientación y aporte a nuestra formación.
5
CONTENIDO Pág.
RESUMEN ............................................................................................................ 18 INTRODUCCIÓN .................................................................................................. 20 1. JUSTIFICACIÓN .............................................................................................. 23 2. PLANTEAMIENTO DEL PROBLEMA ............................................................. 25 3. DEFINICIÓN DEL PROBLEMA ....................................................................... 26 4. OBJETIVOS ..................................................................................................... 27
4.1 Objetivo general ......................................................................................... 27
4.2 Objetivos específicos ................................................................................. 27
5. ALCANCES ...................................................................................................... 28 6. METODOLOGÍA ............................................................................................... 29 7. CONTEXTUALIZACIÓN .................................................................................. 31
7.1. Guías para la gestión de proyectos ............................................................ 31
7.1.1.PMBOK (Project Management Body Of Knowledge) .......................... 31
6
7.1.2.SWEBOK (Software Engineering Body of Knowledge) ...................... 32 7.1.3.Metodología TENSTEP ...................................................................... 32
7.2. Organizaciones relacionadas con la gestión de proyectos. ........................ 34
7.2.1 PMI (Project Management Institute) .................................................... 34
7.2.2 IEEE (Institute of Electrical and Electronics Engineers) ...................... 35
7.2.2.1.IEEE Standards association (IEEE-SA). ...................................... 37 7.2.2.2.IEEE Computer society. ............................................................... 37
7.2.2.3.The IEEE Technical Council on Software Engineering (TCSE). ... 37
7.2.2.4.Software & Systems Engineering Standards Committee (S2ESC).38
7.2.3 Ten Step ............................................................................................. 38
7.3. Conceptualización ...................................................................................... 40
7.3.1.Proyecto .............................................................................................. 41
7.3.2.Gestión de proyectos ........................................................................... 42
7.3.3.Guía ..................................................................................................... 43
8. PRESENTACIÓN Y ANÁLISIS INDIVIDUALIZADO DE RESULTADOS ........ 44
7
8.1. Propuesta para la gestión de proyectos software. ...................................... 44
8.1.1.Gestión de integración ......................................................................... 46
8.1.1.1.Desarrollar El Acta De Constitución Del Proyecto ........................ 46
Gestión de la Integración: Entradas ......................................................... 47
Gestión de la Integración: Herramientas y Técnicas ................................ 48
Gestión de la Integración: Salidas ............................................................ 48
8.1.2.Gestión Del Alcance ............................................................................ 49
8.1.2.1.Definir El Alcance ......................................................................... 50
Definir el Alcance: Entradas ..................................................................... 50
Definir el Alcance: Herramientas y Técnicas ............................................ 50
Definir el Alcance: Salidas ........................................................................ 50
8.1.2.2 Crear La EDT ............................................................................... 51
Crear la EDT: Entradas ............................................................................ 52
Crear la EDT: Herramientas y Técnicas ................................................... 52
Crear la EDT: Salidas ............................................................................... 52
8
8.1.2.3.Verificar El Alcance ...................................................................... 53
Verificar el Alcance: Entradas .................................................................. 54
Verificar el Alcance: Herramientas y Técnicas ......................................... 54
Verificar el Alcance: Salidas ..................................................................... 55
8.1.2.4.Controlar El Alcance ..................................................................... 55
Controlar el Alcance: Entradas ................................................................. 55
Controlar el Alcance: Herramientas y Técnicas ....................................... 56
Controlar el Alcance: Salidas ................................................................... 56
8.1.3 Gestión Del Tiempo Del Proyecto ........................................................ 57
8.1.3.1.Definir Las Actividades ................................................................. 58
Definir las Actividades: entradas .............................................................. 58
Definir las Actividades: Herramientas y Técnicas .................................... 58
Definir las Actividades: Salidas ................................................................ 59
8.1.3.2.Secuenciar Las Actividades ......................................................... 59
Secuenciar las Actividades: Entradas ...................................................... 59
9
Secuenciar las Actividades: Herramientas y Técnicas ............................. 60
Secuenciar las Actividades: Salidas ......................................................... 61
8.1.3.3.Estimar Los Recursos De Las Actividades ................................... 61
Estimar los Recursos de las Actividades: Entradas ................................. 61
Estimar los Recursos de las Actividades: Herramientas y Técnicas ........ 62
Estimar los Recursos de las Actividades: Salidas .................................... 62
8.1.3.4.Estimar La Duración De Las Actividades ..................................... 63
Estimar la Duración de las Actividades: Entradas .................................... 63
Estimar la Duración de las Actividades: Herramientas y Técnicas ........... 63
Estimar la Duración de las Actividades: Salidas ...................................... 64
8.1.3.5.Desarrollar El Cronograma ........................................................... 64
Desarrollar el Cronograma: Entradas ....................................................... 64
Desarrollar el Cronograma: Herramientas y Técnicas.............................. 64
Desarrollar el Cronograma: Salidas ......................................................... 65
8.1.3.6.Controlar El Cronograma ............................................................. 66
10
Controlar el Cronograma: Entradas ......................................................... 67
Controlar el Cronograma: Herramientas y Técnicas ................................ 67
Controlar el Cronograma: Salidas ............................................................ 67
8.1.4.Gestión Del Costo ............................................................................... 68
8.1.4.1.Estimar Los Costos ...................................................................... 69
Estimar los Costos: Entradas ................................................................... 69
Estimar los Costos: Herramientas y Técnicas .......................................... 70
Estimar los Costos: Salidas ...................................................................... 70
8.1.4.2.Determinar El Presupuesto .......................................................... 70
Determinar el Presupuesto: Entradas ...................................................... 71
Determinar el Presupuesto: Herramientas y Técnicas ............................. 72
Determinar el Presupuesto: Salidas ......................................................... 72
8.1.4.3.Controlar Los Costos .................................................................... 73
Controlar los Costos: Entradas ................................................................ 73
Controlar los Costos: Herramientas y Técnicas ....................................... 74
11
Controlar los Costos: Salidas ................................................................... 75
8.1.5.Gestión Del Recurso Humano ............................................................. 76
8.1.5.1.Planificación De Los Recursos Humanos .................................... 77
Planificación de los Recursos Humanos: Entradas .................................. 77
Planificación de los Recursos Humanos: Herramientas y técnicas .......... 77
Planificación de los Recursos Humanos: Salidas .................................... 78
8.1.5.2.Adquirir El Equipo Del Proyecto ................................................... 79
Adquirir el Equipo del Proyecto: Entradas ................................................ 79
Adquirir el Equipo del Proyecto: Herramientas y Técnicas ....................... 79
Adquirir el Equipo del Proyecto: Salidas .................................................. 80
8.1.5.3.Desarrollar El Equipo Del Proyecto .............................................. 80
Desarrollar el Equipo del Proyecto: Entradas ........................................... 80
Desarrollar el Equipo del Proyecto: Herramientas y Técnicas ................. 81
Desarrollar el Equipo del Proyecto: Salidas ............................................. 81
8.1.5.4.Gestionar El Equipo Del Proyecto ................................................ 82
12
Gestionar el Equipo del Proyecto: Entradas ............................................. 82
Gestionar el Equipo del Proyecto: Herramientas y Técnicas ................... 83
Gestionar el Equipo del Proyecto: Salidas ............................................... 83
8.1.6.Gestión Del Riesgo .............................................................................. 84
8.1.6.1.Planificación De La Gestión De Riesgos ...................................... 85
Gestión de los Riesgos Entradas ............................................................. 85
Gestión de los Riesgos Herramientas y Técnicas .................................... 85
Gestión de los Riesgos Salidas ................................................................ 86
8.1.6.2.Identificación De Riesgos ............................................................. 87
Identificación de Riesgos Entradas .......................................................... 88
Identificación de Riesgos Herramientas y Técnicas ................................. 88
Identificación de Riesgos Salidas ............................................................. 89
8.1.6.3.Análisis Cualitativo De Riesgos .................................................... 89
Análisis Cualitativo de Riesgos Entradas ................................................. 90
Análisis Cualitativo de Riesgos Herramientas y técnicas ......................... 90
13
Análisis Cualitativo de Riesgos Salidas .................................................... 90
8.1.6.4.Análisis Cuantitativo De Riesgos .................................................. 91
Análisis Cuantitativo de Riesgos Entradas ............................................... 91
Análisis Cuantitativo de Riesgos Herramientas y Técnicas ...................... 92
Análisis Cuantitativo de Riesgos Salidas ................................................. 92
8.1.6.5.Planificación De La Respuesta A Los Riesgos............................. 92
Planificación de la Respuesta a los Riesgos Entradas ............................ 93
Planificación de la Respuesta a los Riesgos Herramientas y Técnicas ... 93
Planificación de la Respuesta a los Riesgos Salidas ............................... 94
8.1.6.6.Seguimiento Y Control De Riesgos .............................................. 94
Seguimiento y Control de Riesgos Entradas ............................................ 94
Seguimiento y Control de Riesgos Herramientas y Técnicas ................... 95
Seguimiento y Control de Riesgos Salidas .............................................. 95
ENFOQUE SOFTWARE ....................................................................................... 97
8.1.7 Gestión De La Documentación ............................................................ 97
14
8.1.7.1.Determinar El Repositorio De Documentos .................................. 98
8.1.7.2.Determinar Los Tipos De Documentos Que Van A Ser Incluidos En El Plan De Gestión De Documentos ................................................... 98
8.1.7.3.Definir Una Estructura Física Y Lógica Para Almacenar Documentos ............................................................................................. 98
8.1.7.4.Definir Estándares De Denominación ........................................ 101 8.1.7.5.Determinar Si Algunos Documentos Necesitan Manejarse Con Versiones ............................................................................................... 101 8.1.7.6.Determinar Si Se Registrará (Y Como) La Situación En El Ciclo De Vida De Documentos ........................................................................ 101
8.1.7.7.Definir Formatos Estándares De Documentos ........................... 102
8.1.7.8.Utilizar Herramientas Estándares Para Documentar .................. 102
8.1.8.Gestión De La Configuración............................................................. 103
8.1.8.1.Identificación De La Configuración ............................................. 104
8.1.8.2.Control De Cambios ................................................................... 105
8.1.8.3.Generación De Informes ............................................................ 106
8.1.9.Gestión De La Calidad ...................................................................... 107
8.1.9.1.Planificación De La Calidad Del Software .................................. 108
15
8.1.9.2.Control De La Calidad Del Software ........................................... 108
8.1.9.3.Pruebas De Bajo Nivel ............................................................... 109
8.1.9.5.Pruebas De Alto Nivel ................................................................ 110
8.1.9.6.Aseguramiento De Calidad Del Software ................................... 112
8.2. Análisis De Resultados............................................................................. 113
8.2.1.Resultados......................................................................................... 115
8.2.2.Conclusiones - Análisis ..................................................................... 119
9. CONCLUSIONES Y RECOMENDACIONES ................................................. 121 10. BIBLIOGRAFÍA .......................................................................................... 123 11. WEBGRAFÍA ............................................................................................. 127
16
LISTA DE FIGURAS
Pág.
Figura 1. PMI - Imagen corporativa ....................................................................... 34
Figura 2. IEEE - Imagen corporativa ..................................................................... 35
Figura 3.Ten Step - Imagen corporativa. .............................................................. 38
Figura 4. EDT - Estructura divisoria del trabajo .................................................... 53
Figura 5. Método de diagramación por precedencia ............................................. 61
Figura 6. Diagrama de hitos .................................................................................. 65
Figura 7. Diagramas de red del cronograma del proyecto .................................... 66
Figura 8. Línea base de costo, gastos y requisitos de financiamiento. ................. 73
Figura 9. Organigramas y descripciones de cargos .............................................. 77
Figura 10. Estructura de desglose del riesgo ........................................................ 87
Figura 11. Estructura de directorios para el proyecto X ...................................... 100
Figura 12. Resultados de la encuesta - Pregunta 3 ............................................ 115
Figura 13. Resultados de la encuesta - Pregunta 4 ............................................ 115
Figura 14. Resultados de la encuesta - Pregunta 5 ............................................ 116
Figura 15. Resultados de la encuesta - Pregunta 5 ............................................ 116
Figura 16. Resultados de la encuesta - Pregunta 7 ............................................ 116
Figura 17. Resultados de la encuesta - Pregunta 8 ............................................ 116
Figura 18. Resultados de la encuesta - Pregunta 9 ............................................ 117
Figura 19. Resultados de la encuesta - Pregunta 10 .......................................... 117
17
Figura 20. Resultados de la encuesta - Pregunta 11 .......................................... 117
Figura 21. Resultados de la encuesta - Pregunta 12 .......................................... 117
Figura 22. Resultados de la encuesta - Pregunta 13 .......................................... 118
Figura 23. Resultados de la encuesta - Pregunta 14 .......................................... 118
Figura 24. Resultados de la encuesta - Pregunta 15 .......................................... 118
Figura 25. Resultados de la encuesta - Pregunta 15 .......................................... 118
Figura 26. Resultados de la encuesta - Pregunta 16 .......................................... 119
Figura 27. Resultados de la encuesta - Pregunta 17 .......................................... 119
18
RESUMEN
La gestión de proyectos es la aplicación de habilidades, conocimientos, herramientas y técnicas para satisfacer los requisitos de un proyecto; constituye por sí misma, una disciplina que propende por la administración y organización de recursos, de tal forma que, la formulación de un proyecto –de software, para el caso que nos ocupa-, pueda ejecutarse en el marco de los alcances establecidos y tiempo y costos definidos.
El trabajo presentado a continuación, es la construcción de un documento guía para la gestión de proyectos software, en el cual, se tomaron como base metodologías aceptadas y reconocidas mundialmente en gestión de proyectos donde se muestran aspectos importantes, que en la actualidad no se tienen en cuenta en el desarrollo de la mayoría de los proyectos software, tales como: tiempos, costos, recursos humanos, calidad, riesgos y alcance entre otros. De esta manera no solo se pretende aumentar los índices de la calidad del software, sino también brindar un soporte y control durante todo el desarrollo del proyecto.
El documento guía fue probado con uno de los proyectos de grado de la Universidad Católica Popular del Risaralda y posteriormente entregado a un tercero sin experiencia para que realizara la gestión de un proyecto software tomando como guía el instrumento elaborado. Finalmente se muestran los resultados y conclusiones de la práctica realizada. Palabras Clave: Gestión de proyectos, Ingeniería del software, calidad, Planificación, PMBOK, Ten Step, SWEBOK.
19
ABSTRACT Project management is the application of skills, knowledge, tools and techniques to meet a project requirements, it constitutes, itself, a discipline that aims for the resources administration and organization so that, in order to develop a software project for the present case, it might be carried out within the scope, time and cost defined.
The following document is the construction of a guidance document for software project management; in this work were taken as base globally accepted and recognized methodology in project management, on the other hand the project is showing significant aspects that currently this elements haven´t taken into account in most software projects, such as time, cost, human resources, quality, risks, scope, among others. In this way not only would ensure software quality, but just as provide support and control throughout the project development.
The guidance document was tested with one of the graduation projects of the Universidad Católica Popular del Risaralda and later and later this document is handed over to another party without experience to undertake a project management software making the instrument developed as a guide. Finally this project presents the results and conclusions of the practices. Key words: Project Management, Software Engineering, Quality, Planning, PMBOK, Ten Step, SWEBOK.
20
INTRODUCCIÓN
El recorrido del tiempo ha dado a la ingeniera del software un sinfín de definiciones o aproximaciones que han buscado esbozar su objetivo como disciplina. Zelkovitz, Bohem, Bauer, Pressman, Sommerville, Jacobson y Lewis ha sido un influyente grupo de autores que definieron de manera más clara y precisa esta disciplina. A continuación, algunos ejemplos;
La Ingeniería del Software es el establecimiento y uso de principios sólidos de la ingeniería para obtener económicamente un software confiable y que funcione de modo eficiente en maquinas reales. (Bauer, 1972)
Ingeniería del software es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de computadora y la documentación asociada requerida para desarrollar y operar (funcionar) y mantenerlos. Así como también desarrollo de software o producción de software. (Bohem, 1976)
Ingeniería del Software es el estudio de los principios y metodologías para desarrollo y mantenimiento de sistemas de software. (Zelkovitz, 1979)
La Ingeniería de Software es una disciplina de la ingeniería que comprende todos los aspectos de la producción de software desde las etapas iníciales de la especificación del sistema hasta el mantenimiento de este después que se utiliza. (Sommerville, 2004)
La Ingeniería de Software es una disciplina que integra el proceso, los métodos, y las herramientas para el desarrollo de software de computadora. (Pressman R. S., 2004)
Una definición más clara y que logra integrar en su contexto las anteriores mencionadas es la siguiente: La ingeniera del software es un conjunto de actividades estandarizadas y aceptadas mundialmente que nos llevan a la aplicación de un enfoque sistemático, disciplinado en la construcción de software de calidad. Este conjunto de actividades están determinadas por la necesidad, el entorno, los requerimientos técnicos, requerimientos humanos, recursos financieros, tiempo y funcionalidad. (Peláez, 2008)
21
Partiendo de la anterior definición se puede inferir que esta disciplina está compuesta por un amplio conjunto de actividades que ayudan a cumplir de manera sistemática el objetivo de lograr software de calidad. Una de estas actividades es la gestión de proyectos software, que sirve de base para el desarrollo correcto de un proyecto. Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único. La naturaleza temporal hace indispensable que este tenga un principio y un final definidos. El final de los proyectos está determinado por 4 situaciones; cuando se logran los objetivos del proyecto o bien cuando se termina el proyecto porque sus objetivos no se cumplirán o no pueden ser cumplidos, o cuando ya no existe la necesidad que dio origen al proyecto.
La gerencia de proyectos es la ciencia y el arte de administrar, dirigir y coordinar el talento humano, los recursos económicos, los recursos físicos y los recursos logísticos e informáticos para lograr objetivos y resultados previamente determinados, mediante la ejecución de un proyecto específico. (EIA, 2010) La gestión de proyectos software es una actividad indispensable y necesaria cuando se construyen sistemas y productos basados en ordenadores. Ésta involucra la planificación, supervisión y control del personal, y los eventos que ocurren mientras el software evoluciona desde un concepto preliminar (idea) hasta una implementación operativa (Pressman R. S., 2005). La construcción de software es una labor compleja, en particular porque involucra a mucha gente que trabaja durante un tiempo relativamente largo, es por esto que los proyectos del software necesitan ser gestionados.
En este orden de ideas la dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para cumplir con los requisitos del mismo. Se logra mediante la aplicación e integración adecuada de los procesos de la dirección de proyectos, agrupados lógicamente, que conforman los grupos de procesos. Estos 5 grupos de procesos son: iniciación, planificación, ejecución, seguimiento y control y cierre.
22
La propuesta que se presenta a continuación surge de la labor de recopilación y análisis de información de varios enfoques específicos en la gestión de proyectos, que se han adaptado específicamente a la gestión de proyectos software, buscando hacer una propuesta lo suficientemente robusta que pueda ser aplicada a cualquier tipo de desarrollo de aplicaciones software, y buscando también desde el conocimiento adquirido en la carrera universitaria, corregir algunas de las falencias que una u otra propuesta pueden presentar.
La propuesta ha adoptado la forma general de algunas guías y metodologías (SWEBOK, PMBOK, Ten Step) para la gestión de proyectos, dividendo la misma en grupos de procesos, áreas del conocimiento y actividades.
23
1. JUSTIFICACIÓN
La globalización de las economías, la apertura de los mercados y la necesidad de mejorar la competitividad de las organizaciones obligan a crear y administrar proyectos empresariales con criterios científicos y técnicos que buscan la satisfacción de las necesidades de los clientes en términos de calidad, oportunidad, eficiencia y eficacia. Una de las ramas de proyectos más innovadores son los programas controlados por computadora (software) en los cuales se ha creado una gran controversia respecto a su calidad. Es común encontrar un amplio catálogo de proyectos desarrollados por empresas públicas y privadas, que han exigido tiempos superiores de ejecución comparados con los pronosticados o estimados, de igual manera han consumido recursos financieros significativamente mayores y que finalmente han causado perjuicios y frustraciones notables a los interesados, reflejados en incrementos significativos costos, tiempo y alcance. Igualmente, no son pocos los proyectos de desarrollo empresarial, de sistemas de información y diseño de software que colapsan por falta de dirección y liderazgo de sus gestores, que dado su esencia no tangible no dejan huella material, pero sus efectos se perciben con la misma intensidad de los proyectos tangibles. Finalmente muchos de estos proyectos, pasan largas temporadas en los tribunales de justicia y conciliación, derivados de la incapacidad, negligencia, ignorancia o tolerancia ética de los asesores y funcionarios que estructuran los contratos, de ahí la presencia de fuertes equipos jurídicos en las empresas contratistas y muy precarios equipos humanos al frente de las obras y responsabilidades técnicas. Tal situación, revela vacíos de dirección, deficiencias en los estudios de pre factibilidad en los diseños técnicos, y por sobre todo la incapacidad de gestión y liderazgo de quien asume la responsabilidad de la gerencia del proyecto; improvisación y precipitación en la toma de decisiones, falta de planificación en los procesos, desorganización y negligencia en la ejecución, desconocimiento del entorno y de la normatividad, entre otras externalidades no advertidas, todo lo anterior compromete la prospectiva financiera y el control ejercido sobre alcance, tiempo, desempeño, costos y resultados acordes a la calidad prevista.
24
Es pues la otra cara de la moneda donde es notable que los proyectos considerados como exitosos que dan respuesta adecuada y oportuna a las expectativas tanto de sus propietarios como de sus clientes, cumplen con requisitos de calidad al dejar satisfechos a sus usuarios, que logran cumplir con las previsiones presupuestales y que obviamente responden a los compromisos de tiempo y oportunidad. Sin duda, estos resultados son la consecuencia de la aplicación de procesos válidos y confiables de planeación, programación, organización, trabajo en equipo, adecuada comunicación e información, documentación anticipada de riesgos y limitaciones, de estudios jurídicos, técnicos y financieros que dan salida a contratos inequívocos y transparentes, y principalmente, de un liderazgo que combina adecuadamente conocimiento, experiencia, compromiso y ética profesional y, la precisa comprensión de la responsabilidad por parte de quienes asumen la ejecución de los proyectos.1 (DNP, 2009)
1 Las rutas de la mayoría de los países emergentes y el paisaje urbano y rural de sus ciudades, grandes y
pequeñas, está saturado de humillantes ejemplos de “elefantes blancos” que contaminan la vista y dejan el triste testimonio de las obras inconclusas que no sirven para nada, que han enterrado gran cantidad de recursos con costos de oportunidad incalculables que ha tenido que pagar la sociedad, debido a la incompetencia e improbidad de funcionarios y contratistas. En Bogotá (Colombia) la puesta en marcha del sistema de transporte masivo denominado “Transmilenio” es ejemplo de la capacidad de la ingeniería nacional y la apropiación de modelos financieros adecuados y de la voluntad, decisión y liderazgo de las últimas administraciones que asumieron el reto de convertir a Bogotá en una ciudad más amable y competitiva. Este modelo se ha convertido en referencia obligatoria en todo el mundo en cuanto a la solución del transporte colectivo en ciudades intermedias. Maloka es el nombre de otro proyecto exitoso. El Festival Iberoamericano de Teatro que se celebra en Bogotá cada dos años es otra ilustración de liderazgo, adecuada planeación y de compromiso asumida por sus organizadores.
25
2. PLANTEAMIENTO DEL PROBLEMA
Desde su aparición, el software ha sido utilizado en una extensa variedad de áreas de aplicación, razón por la cual se ha convertido en una herramienta fundamental e indispensable para el crecimiento de la sociedad a nivel económico, industrial, tecnológico y cultural, entre otros. Su inclusión en la vida del hombre, ha provocado que la realización de sus labores diarias dependa en gran medida de la utilización de éste tipo de aplicaciones.
Conocidos estudios afirman que el 84% de los proyectos software en el mundo fracasan, 30% son cancelados y 75% de las empresas de software han sido calificadas como caóticas. (DNP, 2009) Estas cifras han motivaron a las empresas y organizaciones a cambiar las metodologías tradicionales y buscar alternativas para la utilización de metodologías que de alguna u otra manera avalen la calidad de los desarrollos.
La ingeniería del software es sin duda alguna una de las más importantes y debe servir como pilar fundamental en cualquier sistema que implemente sistemas de información. Pero aún así los proyectos software siguen fracasando, ya que la mayoría de las metodologías pasan por alto aspectos importantes del entorno del proyecto que son relevantes y pueden motivar al éxito del proyecto o al fracaso total sin importar que tan bien se desarrolle una buena ingeniería del software. Concluye el problema entonces, en el desinterés o la indiferencia que se muestra históricamente por planear, gerenciar, administrar y controlar todas las actividades que conllevan a un producto software, lo que permite seguirlo creando con un alto nivel de errores; errores que, en muchas ocasiones, generan traumas organizacionales, y hasta personales, a quienes lo utilizan.
26
3. DEFINICIÓN DEL PROBLEMA
La mayoría de los programas software creados en Colombia son considerados de “baja calidad”, pues la mayoría de estos productos presentan falencias en los índices que miden la calidad del mismo, tres de esos índices son el tiempo, costo y alcance. Por ello es necesario tener una guía que sirva de soporte a la gestión del proyecto desde que se inician los estudios de pre factibilidad hasta la creación del mismo. La industria de software en Colombia se encuentra bastante desarticulada. Falta camino por recorrer, aun cuando se está trabajando para el fortalecimiento de la agremiación de las empresas de software. La desarticulación no sólo está presente entre las empresas locales sino entre el Estado y las federaciones de software y entre éstas y las empresas. Existen principalmente dos federaciones: una es Business Software Alliance (BSA), que tiene fuertes nexos con las compañías internacionales y que concentra su trabajo en la lucha contra la piratería y la segunda es la Federación Colombiana de la Industria de Software (Fedesoft), que representa principalmente a las pequeñas empresas locales de software. La falta de sincronía, de acción conjunta y, especialmente, de comunicación son las debilidades más grandes que tiene esta industria en el país, pues hacen que el sector no sea explotado de acuerdo con su potencial. (CEPAL, 2009) Con base en lo anterior, también las falencias en la gestión del proyecto, en la mayoría de las ocasiones están desarticuladas y falta alto camino por recorre en su implementación, pues nuestra cultura empresarial, se centra en la codificación del programa, y olvida por completo otras actividades que están totalmente ligadas a la ingeniería del software, este es el caso de la gestión de proyectos informáticos. Es por ello que se hace necesario proponer una guía que posea diferentes capas de gestión, en las cuales se especifican una serie de actividades que sirvan de herramienta al gerente del proyecto para mitigar las falencias en cuanto a “costo tiempo y alcance” del proyecto.
27
4. OBJETIVOS
4.1 Objetivo general
Desarrollar un marco guía para la gestión de proyectos software tomando como base, metodologías y buenas prácticas mundialmente reconocidas en gestión de proyectos, el cual servirá de apoyo para aumentar el índice de calidad del software en las pymes de Colombia.
4.2 Objetivos específicos
Explorar, analizar y sistematizar las mejores prácticas y metodologías aceptadas mundialmente en gestión de proyectos.
Seleccionar las actividades pertinentes de cada una de las metodologías indagadas, que permitan construir el marco guía para la gestión de proyectos software y que pueda ser aplicada por las pymes desarrolladoras de software en Colombia.
Evaluar el marco guía, aplicándola en un proyecto que carezca de dicha gestión, y teniendo como intermediarios personas fóraneas al proyecto y a la guía, de tal manera que se pueda validar su funcionalidad.
Comparar los resultados obtenidos en los proyectos evaluados, contrastando la gestión de proyectos aplicada antes y después de hacer uso del marco guía elaborado.
28
5. ALCANCES
Se pretende realizar una investigación exploratoria y aplicada acerca de la gestión de proyectos informáticos, de la cual se partirá para la construcción de una propuesta que sirva de guía a los interesados en construcción de proyectos software para su aplicación. Esta propuesta busca no solo ser un instrumento de apoyo para planificar los proyectos, sino también ser un aporte en el aumento de los índices de calidad del software de esta clase de proyectos, pues es bien sabido que la calidad de un programa informático también se puede medir en cuanto a tiempo, costo y alcance estimado.
La exploración contempla la búsqueda de información que comparten las asociaciones que agremian el sector de la gestión de proyectos y de igual forma algunas de las propuestas guías existentes en el campo de la gerencia de proyectos.
29
6. METODOLOGÍA
La metodología utilizada consiste en realizar un estudio exploratorio sobre la importancia de la gestión de proyectos software usando una propuesta, metodología o guía que permita tener unas fases y actividades claramente dirigidas, contemplando dentro de éste las organizaciones, los estándares, las métricas, las técnicas y demás prácticas comúnmente utilizadas en gestión de proyectos software. La propuesta “guía para la gestión de proyectos de desarrollo de software en el grupo de residencia en línea de investigación” se ha desarrollado en una serie de etapas que describiremos a continuación. El desarrollo de cada una de las mismas ha sido dirigida por los asesores asignados para apoyar la intervención del desarrollo del proyecto, estableciendo las actividades necesarias que se debían desarrollar para tener un documento final que sirviese de apoyo a las personas interesadas en aplicar gestión de proyectos, anexo a ello es un complemento al proyecto general del grupo de investigación, que actualmente está enfocado en realizar estudios y propuestas para aumentar la calidad del software en Colombia.
Etapa 1: Se definió la ruta a seguir durante todo el desarrollo del proyecto, estableciendo los requerimientos, el alcance del proyecto. Una vez definida la ruta se creó el cronograma y la lista de entregables para el primer semestre del año 2010. El principal entregable fue la propuesta marco guía, en la cual se especificaron las fases, entradas, herramientas y salidas de cada una de las áreas del conocimiento, previo a la elaboración de dicho documento se realizó un análisis minucioso de las diferentes metodologías, extrayendo de cada una de ellas las etapas pertinentes que en cierta medida aportaron para la realización adecuada de una gestión de proyectos software.
Etapa 2: Una vez analizada la propuesta marco, se elaboró una serie de herramientas y tutoriales que sirven de complemento a la aplicación de la propuesta, donde el interesado en aplicar la gestión de proyectos podrá complementar su aplicación con herramientas software creadas especialmente para dicha área. Del mismo modo se crearon varias plantillas que permiten una adecuada documentación en las diferentes etapas de la gestión de proyectos.
Etapa 3: Una vez creada la propuesta con sus herramientas, se depuraron algunas actividades que después de un análisis se consideraron no necesarias. Posteriormente, después de la reunión con todo el grupo de investigación se creó un documento que indicara las actividades necesarias para la aplicación de la
30
propuesta, en tres tipos de proyectos, (nivel 1, nivel 2 y nivel 3), cada uno con características especiales.
Etapa 4: Para el proyecto fue necesaria realizar una evaluación del instrumento realizado, el cual se evaluó con una persona externa y sin conocimientos en gestión de proyectos, con el fin de determinar la usabilidad y claridad del documento. Se asigno al estudiante Jorge Alberto Franco para la aplicación del instrumento en uno de los proyectos con enfoque software.
31
7. CONTEXTUALIZACIÓN
7.1. Guías para la gestión de proyectos
7.1.1. PMBOK (Project Management Body Of Knowledge) 2
La Guía de los Fundamentos para la Dirección de Proyectos propuesta por el PMI (Project Management Institute) (guía del PMBOK) es una norma reconocida en la profesión de la dirección de proyectos. Por norma se hace referencia a un documento formal que describe normas, métodos, procesos y prácticas establecidos. La guía del PMBOK proporciona pautas para la dirección de proyectos tomados de forma individual. Define la dirección de proyectos y otros conceptos relacionados, y describe el ciclo de vida de la dirección de proyectos y los procesos conexos. El PMBOK reconoce 5 grupos de procesos básicos y 9 áreas de conocimiento (KA) comunes a casi todos los proyectos. Los procesos se traslapan e interactúan a través de un proyecto o fase. Los procesos son descritos en términos de: entradas (documentos, planes, diseños, etc.), herramientas y técnicas (mecanismos aplicados a las entradas) y salidas (documentos, productos, etc.) (PMBOK, 2009)
Las nueve áreas del conocimiento mencionadas en el PMBOK son: 1. Gestión de la integración 2. Gestión del alcance 3. Gestión del tiempo 4. Gestión de la calidad 5. Gestión de costos 6. Gestión del riesgo 7. Gestión de recursos humanos 8. Gestión de la comunicación 9. Gestión de las compras y adquisiciones
2 A guide to the Project Management Body Of Knowledge (PMBOK)(4ª Edition), Introduction pg. 3-14 2009
32
7.1.2. SWEBOK (Software Engineering Body of Knowledge) 3
SWEBOK por sus siglas en español es un guía del “Cuerpo de Conocimientos de la Ingeniería de Software” desarrollada en conjunto por la IEEE Computer Society y la Association for Computing Machinery, la creación del cuerpo de conocimientos es un paso esencial hacia el desarrollo de una profesión debido a que representa un acuerdo general con respecto al contenido de la disciplina. SWEBOK busca reunir en un solo texto las competencias que debe tener todo ingeniero de software para desempeñarse competentemente en el mercado. Es un proyecto para clasificar y definir todo lo que es Ingeniería de Software (IS), pero antes de llegar a ésta guía fueron 5 años de trabajo. La idea fue que los expertos en IS del mundo dieran sus opiniones sobre la disciplina, sus fortalezas, debilidades y diferencias y para ello fue necesario llegar a un consenso. La Guía de SWEBOK organiza el cuerpo de conocimientos en varias Áreas de Conocimiento (KA). En total se tienen 10 KA. Asimismo considera ocho disciplinas relacionadas (SWEBOK, 2004) Áreas del conocimiento 1. Requerimientos de Software 2. Diseño de Software 3. Construcción de Software 4. Prueba del Software 5. Mantenimiento del Software 6. Gestión de la Configuración Software 7. Gestión de la Ingeniería de Software 8. Proceso de Ingeniería de Software 9. Herramientas y Métodos en Ingeniería de Software 10. Calidad del Software
7.1.3. Metodología TENSTEP 4
La Metodología TenStep de dirección de proyectos ha sido creada para proporcionar toda la información y documentación necesarias para gestionar con éxito proyectos de cualquier tipo. La metodología TenStep de dirección de proyectos (TenStep) es una metodología para gestionar todos aquellos trabajos no
3 Guide to the Software Engineering Body of Knowledge (SWEBOK) (2004 edition) CHAPTER 1: Introduction to the guide
4 Metodología TenStep de Dirección de Proyectos (España) Pagina Oficial: http://www.tenstep.es
33
repetitivos u operativos como proyectos. Está diseñada para ser tan flexible como es necesario para gestionar cualquier tipo y dimensión de proyecto. Por ejemplo, puede que no tenga mucho sentido dedicar gran cantidad de tiempo a gestionar el riesgo en un proyecto cuya duración será de 500 horas y es parecido a muchos otros que se han realizado con anterioridad. Esto no implica que se ignoren los riesgos potenciales – solo que no requerirá tanto tiempo como podría necesitar otro proyecto – por ejemplo que implique la implantación de nueva tecnología en toda la organización. Este enfoque flexible y escalable es lo más singular del proceso TenStep, y es un aspecto que diferencia esta metodología de otras que se han desarrollado por entes privados o públicos (TenStep, 2009). Dirección de proyectos se refiere a la definición y planificación, y en consecuencia al seguimiento, control y terminación de un proyecto. Antes de iniciar, se debería reconocer que todos los proyectos necesitan algún nivel de gestión. Entre más grande es el proyecto y más complicado sea éste, mas será necesario el uso de un proceso formal y estandarizado. Se puede ser capaz de gestionar un proyecto de 200 horas y dos personas, usando las técnicas de gestión de memoria.
Áreas del conocimiento de TenStep: 1. Definición del trabajo 2. Elaboración del plan de trabajo y del presupuesto 3. Gestión del plan de trabajo y del presupuesto 4. Gestión de incidencias y problemas 5. Gestión del alcance 6. Gestión de las comunicaciones 7. Gestión de los riesgos 8. Gestión de la documentación 9. Gestión de la calidad 10. Gestión de los indicadores de rendimiento
34
7.2. Organizaciones relacionadas con la gestión de proyectos.
7.2.1 PMI (Project Management Institute) 5
Figura 1. PMI - Imagen corporativa
Fuente: Project Management Institute.
Es una organización internacional sin fines de lucro que asocia a profesionales para la gestión de proyectos. Actualmente, es la más grande del mundo en su sección; dado que se encuentra integrada por más de 260.000 miembros alrededor de 171 países. La oficina central se encuentra en la localidad de Newtown Square, en la periferia de la ciudad de Filadelfia en Pennsylvania, Estados Unidos.
Sus principales objetivos son:
1) Formular estándares profesionales, 2) Generar conocimiento a través de la investigación y 3) Promover la gestión de proyectos como profesión a través de sus programas de certificación. El PMI se fundó en 1969 por cinco voluntarios. Su primer seminario se celebró en Atlanta (EE.UU), al cual acudieron más de 80 personas. En la década de los 70 se realizó el primer capítulo, lo que permitió realizar fuera de EEUU el primer seminario. A finales de 1970 ya casi 2000 miembros formaban parte de la organización. En la década de los 80 se realizó la primera evaluación para la certificación como profesional en gestión de proyectos (PMP por sus siglas en inglés), además de esto se implantó un código de ética para la profesión. A principios de los años 1990 se publicó la primera edición de la Guía del PMBOK, el cual se convirtió en un pilar básico para la gestión y dirección de proyectos. Ya en
5 PROJECT MANAGEMENT INSTITUTE. About Us. Organización líder en el mundo que prepara y publica guías para la
gestión de proyectos. Disponible en: http://www.pmi.org/
35
el año 2000 el PMI estaba formado por más de 40.000 personas como miembros activos, 10.000 PMP certificados y casi 300.000 copias vendidas del PMBOK. 7.2.2 IEEE (Institute of Electrical and Electronics Engineers) 6
Figura 2. IEEE - Imagen corporativa
Fuente: IEEE.
Creado en Nueva York en 1884, es una asociación internacional sin ánimo de lucro con sede principal en la ciudad de Piscataway en los Estados Unidos y subsedes en más de 190 países del mundo, con alrededor de 380.000 miembros, entre profesionales y estudiantes de ingeniería, diseño, derecho, administración, medicina, biología y ciencias afines. Su misión es fomentar la prosperidad global para beneficio de la humanidad y las profesiones, mediante la promoción de los procesos de ingeniería, en la creación, desarrollo, integración, participación y aplicación del conocimiento de la informática, la ciencia electromagnética y la electrotecnología. Organización interna: El Instituto está conformado por una división técnica y otra geográfica. La división técnica está compuesta por 39 diferentes sociedades, cada una de ellas orientada a un tema macro del conocimiento tecnológico. La división geográfica comprende 10 regiones a nivel mundial, compuestas a su vez por 329 secciones locales. Colombia pertenece al IEEE Región 9 (Latino América) y a la Sección Colombia.
6 THE INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS. ¿Qué es el IEEE?. Disponible en:
http://www.ieeetadeo.org/ieee.html
36
Además, se tienen diferentes tipos de membresía, clasificados básicamente en dos grandes grupos: Miembros Profesionales y Miembros Estudiantiles. IEEE cuenta con 1.784 capítulos integrados por miembros locales con similares intereses técnicos, 38 sociedades y 7 consejos técnicos, 1.616 ramas estudiantiles en colegios y universidades en 80 países, y 452 capítulos en la rama estudiantil. Su misión es fomentar la prosperidad global para beneficio de la humanidad y las profesiones, mediante la promoción de los procesos de ingeniería, en la creación, desarrollo, integración, participación y aplicación del conocimiento de la informática, la ciencia electromagnética y la electrotecnología. Miembros: Hay más de 365.000 miembros del IEEE en más de 160 países de todo el mundo, entre los que se encuentran ingenieros, científicos y profesionales cuyos intereses técnicos se basan en eléctrica y ciencias de la computación, ingeniería y disciplinas afines. Estándares: El IEEE es un desarrollador líder de las normas internacionales que sustentan muchas de las telecomunicaciones de hoy en día, la tecnología de la información y los productos de la generación de energía y servicios. Es a menudo la fuente principal para la normalización en una amplia gama de tecnologías emergentes. Desarrolla sus estándares a través de una de sus entidades, la IEEE Standards Association (IEEE-SA). Asimismo, este desarrollo se potencia mediante otras entidades técnicas abarcadas por el Instituto, la IEEE Computer Society (IEEE-CS) y el IEEE Technical Council on Software Engineering (TCSE), las cuales participan de esta actividad mediante un comité, el Software & Systems Engineering Standards Committee (S2ESC).
37
7.2.2.1. IEEE Standards association (IEEE-SA).
La IEEE Standards Association (IEEE-SA) produce las normas que respondan a las necesidades globales de la industria, el gobierno y el público para una amplia gama de tecnologías e industrias. Cuenta con una cartera de alrededor de 900 normas activas y más de 400 normas en preparación. 7.2.2.2. IEEE Computer society.
Computer Society es la más grande de las sociedades organizadas en el IEEE y el organismo líder en proveer información técnica y servicios a estudiantes y profesionales de la computación, la informática y los sistemas a nivel mundial. Con cerca de 85.000 miembros, la IEEE Computer Society es la organización líder en el mundo de profesionales de la informática. Fundada en 1946, y la mayor de las 38 sociedades del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE), se dedica a avanzar la teoría y aplicación de la informática y tecnología de la información de procesamiento. En el año 2004 la IEEE Computer Society publicó la Guía SWEBOK, en la cual se establece por primera vez una línea de base para el cuerpo de conocimiento en el ámbito de la ingeniería de software, cumpliendo parcialmente con la responsabilidad de promover el adelanto de la teoría y la práctica en este campo. Cabe señalar que la Guía no pretende definir el conjunto de conocimientos, sino más bien servir como un compendio y guía para el desarrollo y la evolución de los mismos. 7.2.2.3. The IEEE Technical Council on Software Engineering (TCSE).
El Consejo Técnico IEEE de Ingeniería del Software (TCSE) alienta a la aplicación de métodos de ingeniería y principios para el desarrollo de programas de computadora, y trabaja para incrementar los conocimientos profesionales de las técnicas, herramientas y datos empíricos para mejorar la calidad del software. TCSE participa en las múltiples formas en que el software es diseñado, desarrollado, administrado y mantenido.
38
7.2.2.4. Software & Systems Engineering Standards Committee (S2ESC).
Es el Comité de normas para software e ingeniería de sistemas del IEEE cuya misión es desarrollar y mantener una familia de software y sistemas de normas de ingeniería que sea pertinente, coherente, completa y eficaz. Estas normas son implementadas por profesionales, organizaciones y educadores con el fin de mejorar la eficacia y eficiencia de los procesos de ingeniería de software, la comunicación entre compradores y proveedores, y la calidad del software entregado.
7.2.3 Ten Step 7
Figura 3.Ten Step - Imagen corporativa.
Fuente: TenStep consulting and training.
TenStep es una firma de servicios de consultoría y formación, con presencia en más de 35 países alrededor del mundo y en más de 25 idiomas. Posee un amplio portafolio de productos y servicios para ayudar a individuos y organizaciones de todo tipo a mejorar sus resultados de negocio con énfasis en planeación estratégica, dirección de proyectos y mejora de procesos. Esto incluye la implementación exitosa de prácticas sólidas de gestión de proyectos, creación y funcionamiento de Oficinas de Proyectos (OGP) el establecimiento de procesos de gestión de carteras, y mucho más. Las organizaciones pueden utilizar nuestra gama completa de servicios de consultoría y nuestro extenso currículum de cursos de capacitación. [TenStep,2009] Sus servicios son un conjunto de productos que abarca la metodología de gestión de proyectos, OAP (oficina de administración de proyectos), gestión de cartera,
7 TEN STEP. Global Project Management Consulting, Training and Methodology . Disponible en: http://www.tenstep.com/
39
ciclo de vida de desarrollo y entre otros. También puede soportar otras metodologías comprados o los que se han desarrollado “in-house”. Continuando con la contextualización que sirve de base para entender la gestión de proyectos como un área del conocimiento importante en el desarrollo de un proyecto, se deben analizar las ventajas que puede tener la adopción de una metodología, guía o propuesta que dirija el rumbo del desarrollo de los proyectos.
Existen algunas compañías que han obtenido su buena reputación a través de su habilidad para gestionar sus proyectos de manera efectiva y eficiente8. Sin embargo, en la gran mayoría de las organizaciones de todo tipo, la reputación de acabar proyectos en el plazo y costos definidos es bastante cuestionable.
Una buena metodología, guía o propuesta para la dirección de proyectos es la forma en que una organización se puede sobreponer a estos problemas. Tener habilidades en dirección de proyectos, no quiere decir que no se tendrán problemas. No significa que los riesgos simplemente desaparezcan, o que no surjan inconvenientes.
Los procesos y técnicas de dirección de proyectos son utilizados para coordinar los recursos con el fin de alcanzar resultados predecibles. Sin embargo, se debe entender que la dirección de proyectos no es enteramente una ciencia, así que nunca existirá una garantía total de que haya resultados 100% exitosos. Dado que la ejecución de proyectos involucra gente, siempre existirá un factor de complejidad e incertidumbre que no podrá controlarse en su totalidad. La dirección de proyectos es parcialmente un arte que requiere flexibilidad y creatividad, especialmente en lo que a la gestión de los recursos humanos se refiere.
Una buena metodología de dirección de proyectos proporciona el esquema de trabajo, los procesos, normas y técnicas para gestionar a la gente y la cantidad de trabajo asociado; por lo que ésta incrementa las probabilidades de tener éxito, y
8 Covey, Steven, Los siete hábitos de la gente altamente efectiva, Prologo pg. 9-15 Paidós Plural
La Eficiencia significa hacer bien las cosas. (cuando una empresa mantiene estables o disminuidos los
costos de sus insumos y la producción sin sacrificar su nivel de calidad, y así está siendo eficiente)
La Eficacia o efectividad significa hacer lo que se tiene que hacer. (implica la habilidad para determinar y alcanzar los objetivos organizacionales mediante la toma de decisiones, se es efectivo con la gente o las decisiones)
40
en consecuencia proporciona valor a la organización, al proyecto y al Jefe del Proyecto.
Habiendo conocido un poco la importancia de la aplicación de una metodología para el seguimiento de proyectos, es importante saber cómo se debe hacer la elección para el uso de una de ellas; existen dos fuentes principales para poder obtenerla:
Elaborar una: Se puede elaborar una metodología adaptada a la propia organización que refleje perfectamente la filosofía y mejores prácticas de la compañía. Una gran cantidad de empresas continúan haciendo esto hoy en día. Sin embargo, los costos y tiempos son generalmente muy elevados.
Comprar una: Si se construye una metodología, es probable que exista algún grado de sorpresa al descubrir que, a final de cuentas, ésta se ve muy similar a otras metodologías de dirección de proyectos que la gente usa. No importa cómo se estructure, siempre será necesario planificar, elaborar el plan de trabajo, gestionar el alcance, riesgos e incidencias, comunicar, etc. En consecuencia, una gran cantidad de empresas eligen la opción de comprar una licencia o una metodología preexistente. En cualquier caso, éstas habitualmente contienen todo lo que una organización necesita para una dirección de proyectos eficiente.
También existe la opción híbrida de comprar una metodología y adecuarla a las necesidades específicas de la organización. Esto de alguna forma, proporciona los beneficios de la opción 1, a la vez que toma menos tiempo, lo que representa la mayor ventaja de la opción 2.
7.3. Conceptualización
Con el fin de presentar una visión más clara de los conceptos relacionados con la gerencia de proyectos, se considera importante definir de acuerdo a algunos autores reconocidos y organizaciones que tratan la disciplina, aquellos conceptos inherentes al tema.
41
7.3.1. Proyecto
Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único. La naturaleza temporal de los proyectos indica un principio y un final definidos. El final se alcanza cuando se logran los objetivos del proyecto o cuando se termina el proyecto porque sus objetivos no se cumplirán o no pueden ser cumplidos, o cuando ya no existe la necesidad que dio origen al proyecto. Temporal no necesariamente significa de corta duración. En general, esta cualidad no se aplica al producto, servicio o resultado creado por el proyecto; la mayor parte de los proyectos se emprenden para crear un resultado duradero. Por ejemplo, un proyecto para construir un monumento nacional creará un resultado que se espera que perdure durante siglos. Por otra parte, los proyectos pueden tener impactos sociales, económicos y ambientales que durarán mucho más que los propios proyectos.
Todo proyecto crea un producto, servicio o resultado único. Aunque puede haber elementos repetitivos en algunos entregables del proyecto, esta repetición no altera la unicidad fundamental del trabajo del proyecto. Por ejemplo, los edificios de oficinas son construidos con materiales idénticos o similares, o por el mismo equipo, pero cada ubicación es única: con un diseño diferente, en circunstancias diferentes, por contratistas diferentes, etcétera. Un esfuerzo de trabajo permanente es por lo general un proceso repetitivo, puesto que sigue los procedimientos existentes de una organización. En contraposición, debido a la naturaleza única de los proyectos, puede existir incertidumbre respecto de los productos, servicios o resultados que el proyecto genera. Las tareas del proyecto pueden ser nuevas para el equipo del proyecto, lo que hace necesario planificar con mayor dedicación que si se tratara de un trabajo de rutina. Además, los proyectos se llevan a cabo en todos los niveles de una organización. Un proyecto puede involucrar a una sola persona, una sola unidad o múltiples unidades dentro de la organización. [SWEBOK, 2004].
42
7.3.2. Gestión de proyectos
La gestión de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para cumplir con los requisitos del mismo. [PMI,2003] Se logra mediante la aplicación e integración adecuadas de los 42 procesos de la dirección de proyectos, agrupados lógicamente, que conforman los 5 grupos de procesos. Estos 5 grupos de procesos son:
Iniciación,
Planificación,
Ejecución,
Seguimiento y Control, y
Cierre. Dirigir un proyecto por lo general implica:
Identificar requisitos,
Abordar las diversas necesidades, inquietudes y expectativas de los interesados según se planifica y efectúa el proyecto,
Equilibrar las restricciones contrapuestas del proyecto que se relacionan, entre otros aspectos, con: el alcance, la calidad, el cronograma, el presupuesto, los recursos y el riesgo.
El proyecto específico influirá sobre las restricciones en las que el director del proyecto necesita concentrarse. La relación entre estos factores es tal que si alguno de ellos cambia, es probable que al menos otro se vea afectado. Por ejemplo, un adelanto en el cronograma a menudo implica aumentar el presupuesto, a fin de añadir recursos adicionales para completar la misma cantidad de trabajo en menos tiempo. Si no es posible aumentar el presupuesto, se puede reducir el alcance o la calidad, para entregar un producto en menos tiempo por el mismo presupuesto. Los interesados en el proyecto pueden tener opiniones diferentes sobre cuáles son los factores más importantes, lo que crea un desafío aún mayor.
43
Cambiar los requisitos del proyecto puede generar riesgos adicionales. El equipo del proyecto debe ser capaz de evaluar la situación y equilibrar las demandas a fin de entregar un proyecto exitoso. Dada la posibilidad de sufrir cambios, el plan para la dirección del proyecto es iterativo y su elaboración es gradual a lo largo del ciclo de vida del proyecto. La elaboración gradual implica mejorar y detallar constantemente un plan, a medida que se cuenta con información más detallada y específica, y con estimados más precisos. La elaboración gradual permite a un equipo de dirección del proyecto dirigir el proyecto con un mayor nivel de detalle a medida que éste avanza.
7.3.3. Guía
“Una guía es un documento que contiene las directrices sobre cómo realizar los procesos” (García, Garzás, & Piattini, pág. 3).
44
8. PRESENTACIÓN Y ANÁLISIS INDIVIDUALIZADO DE RESULTADOS
Previo al comienzo de exposición de los resultados generados durante el tiempo de estudio, recolección de información y demás actividades que fueron necesarias para concluir el trabajo, se explica la forma en la cual se expondrán los resultados en este capítulo. En primer lugar se expone la propuesta planteada para la gestión de proyectos software, el cual es el documento base que el lector interesado en aplicar la propuesta deberá seguir. En el encontrara cada una de las fases con sus respectivas actividades, del mismo modo encontrará también una serie de herramientas que ayudaran a realizar cada una de las etapas. En segundo lugar encontrará los resultados obtenidos una vez se realizo la encuesta a los involucrados en el proyecto software “sistema de gestión documental para el departamento de prácticas profesionales de la universidad católica popular del Risaralda”. 8.1. PROPUESTA PARA LA GESTIÓN DE PROYECTOS SOFTWARE9
Como se menciono anteriormente, la propuesta consta de 3 componentes que conforman su esencia: los grupos de procesos, las áreas del conocimiento (KA) y finalmente los procesos.
Los grupos de procesos se forman por medio de procesos inherentes a cada una de las áreas del conocimiento, las cuales a su vez forman líneas transversales aplicadas a los diferentes grupos de procesos, es decir, todas las áreas del conocimiento o también llamadas áreas de gestión se deben aplicar en todos los grupos e procesos, existen casos en que estas áreas de gestión solo aporten unos cuantos procesos en cada uno de los grupos de gestión, esto se debe a que los procesos solo son necesarios aplicarlos en dicho grupo. A continuación se expone una tabla que permite detallar los diferentes procesos distribuidos en las áreas de gestión y en los grupos de procesos.
Es importante resaltar que el documento presente es la integración de las diferentes metodologías anteriormente mencionadas, fue un proceso arduo de investigación, en el cual se logró como resultado final la fusión de todas las guías y metodologías estudiadas según el criterio y conocimiento de los autores, lográndolas adaptar al caso de estudio particular.
9 Propuesta basada en: PMBOK, TENSTEP, SWEBOK. Adaptada y traducida por: SANTACRUZ, Juan, y RIOS, Andrés.
45
Tabla 1: Grupo de procesos para la gestión de proyectos.
Fuente: Elaboración propia.
Áreas del conocimiento
Grupos de procesos para la gestión de proyectos
Grupo de procesos de
inicio
Grupo de procesos de planeación
Grupo de procesos de
ejecución
Grupo de procesos de
monitoreo y control
Grupo de procesos
de cierre
1. Gestión de integración
1.1 Desarrollar acta de constitución del proyecto
1.2 Plan de gestión del proyecto 1.3 Dirección y gestión del plan de ejecución del proyecto
1.4 Plan de monitoreo y control de procesos
1.5 Cierre de proyecto o de etapa.
2. Gestión del alcance
2.1 Definir el alcance 2.2 Desarrollar la EDT
2.3 Verificar alcance 2.4 Controlar alcance
3. Gestión del tiempo
3.1 Definir actividades 3.2 Secuenciar actividades 3.3 Estimar recursos para cada actividad 3.4 Estimar tiempo por actividad 3.5 Crear cronograma
3.6 Controlar cronograma
4. Gestión del costo 4.1 Estimar costos 4.2 Estimar presupuesto
4.3 Controlar costos
5. Gestión del
recurso humano
5.1 Desarrollar plan de recursos humanos
5.2 Adquirir el equipo del proyecto 5.3 Desarrollar equipo del proyecto 5.4 Dirigir equipo del proyecto
6. Gestión del riesgo
6.1 Plan de gestión de riesgo 6.2 Identificar riesgos 6.3 Análisis cualitativo de riesgo 6.4 Análisis cuantitativo de riesgo 6.5 Plan de respuestas al riesgo
6.6 Monitorear y controlar riesgos
7. Gestión de la documentación
7.1 Determinar repositorio de documentos 7.2 Definir tipos de documentos 7.3 Definir estructura física y lógica de documentos 7.4 Definir estándares de denominación 7.5 Determinar documentos que necesitan manejarse con versiones: 7.6 Determinar si se registrará la situación en el ciclo de vida de documentos: 7.7 Definir formatos estándares de documentos: 7.8 Definir herramientas estándares de documentación
7.9 Desarrollo de actas en las diferentes etapas
7.10Control de documentación.
7.11 Acta de cierre del proyecto
Gestión de la calidad
8.1 Planificación de la Calidad del Software 8.2 Control de la Calidad del Software 8.3 Aseguramiento de Calidad del Software
Gestión de la configuración
9.1 Identificación de la configuración 9.2 Control de cambios 9.3 Generación de informes
46
8.1.1. Gestión de integración10
La integración, en el contexto de la dirección de un proyecto, consiste en tomar decisiones sobre dónde concentrar recursos y esfuerzos cada día, anticipando las posibles polémicas de modo que puedan ser tratadas antes de que se conviertan en polémicas críticas y coordinando el trabajo para el bien del proyecto en general.
La necesidad de integración en la dirección de proyectos se hace evidente en situaciones en las que los procesos individuales interactúan. Por ejemplo, una estimación de costos necesaria para un plan para contingencias implica la integración de los procesos de planificación que se describen con más detalle en los procesos de gestión de los costos del proyecto, los procesos de gestión del tiempo del proyecto y los procesos de gestión de los riesgos del proyecto. Cuando se identifican riesgos adicionales asociados con las distintas alternativas de personal, se deben revisar uno o más de dichos procesos.
La mayoría de los practicantes de la dirección de proyectos con experiencia saben que no hay una única manera de gestionar un proyecto. Éstos aplican los conocimientos, habilidades y procesos de dirección de proyectos con diferentes órdenes y grados de rigor para alcanzar el rendimiento deseado del proyecto.
8.1.1.1. Desarrollar el acta de constitución del proyecto
El acta de constitución del proyecto es el documento que autoriza formalmente un proyecto.
Constituir un proyecto vincula el proyecto al trabajo en curso de la organización. En algunas organizaciones, un proyecto no se constituye e inicia formalmente hasta no haber completado una evaluación de las necesidades, un estudio de viabilidad, un plan preliminar o alguna otra forma equivalente de análisis que se haya iniciado por separado. Desarrollar el acta de constitución del proyecto se relaciona principalmente con la documentación de las necesidades de negocio, la justificación del proyecto, la comprensión efectiva de los requisitos del cliente, y del nuevo producto, servicio o resultado destinado a satisfacer dichos requisitos.
10
Gestión de la integración, PMBOK, 4ta edición. Página 70. Adaptada y traducida por: SANTACRUZ, Juan, y RIOS,
Andrés.
47
El acta de constitución del proyecto, ya sea de forma directa o mediante referencia a otros documentos, debe comprender la siguiente información:
Requisitos que satisfacen las necesidades, deseos y expectativas del cliente, el patrocinador y demás interesados
Finalidad o justificación del proyecto
Director del proyecto nombrado y nivel de autoridad
Resumen del cronograma de hitos
Influencias de los interesados
Organizaciones funcionales y su participación
Gestión de la integración: entradas
Contrato (cuando corresponda): Un contrato de la organización del cliente es una entrada si el proyecto se realiza para un cliente externo.
Enunciado del trabajo del proyecto: El enunciado del trabajo (SOW) es una descripción narrativa de los productos o servicios que deben ser suministrados por el proyecto. El SOW indica:
Una necesidad de negocio: la necesidad de negocio de una organización puede deberse a una necesidad de formación, a una demanda del mercado, a un avance tecnológico, a un requisito legal o a una norma gubernamental.
Una descripción del alcance del producto: documenta los requisitos y las características del producto o servicio que el proyecto deberá crear. Los requisitos del producto generalmente estarán menos detallados durante el proceso de iniciación, y más detallados en los procesos posteriores, a medida que las características del producto se van elaborando gradualmente. Aunque la forma y el contenido del documento de requisitos del producto pueden variar, siempre deberá ser lo suficientemente detallado para que sirva de apoyo a la planificación posterior del proyecto.
48
Factores ambientales de la empresa: Al desarrollar el acta de constitución del proyecto, se deben tener en cuenta todos y cada uno de los factores ambientales de la empresa y de los sistemas de la organización que estuvieran relacionados con el éxito del proyecto o pudieran influir sobre él de alguna manera. Esto incluye, entre otros, conceptos tales como:
Recursos humanos existentes (por ejemplo, habilidades, disciplinas y conocimientos, tales como diseño, desarrollo, legales, contrataciones y compras)
Sistemas de información de la gestión de proyectos (por ejemplo, los conjuntos de herramientas automatizadas, tales como las herramientas de software para la elaboración de cronogramas, los sistemas de gestión de la configuración, los sistemas de recogida y distribución de información, o las interfaces web con otros sistemas automatizados en línea).
Gestión de la integración: herramientas y técnicas
Metodología de dirección de proyectos: La metodología de dirección de proyectos define un conjunto de grupos de procesos de dirección de proyectos, sus procesos relacionados, y las funciones de control relacionadas que se consolidan y combinan en un todo funcional y unificado. La metodología de dirección de proyectos puede ser o no una elaboración de una norma de dirección de proyectos.
Juicio de expertos: El juicio de expertos se usa generalmente para evaluar las entradas requeridas para desarrollar el acta de constitución del proyecto. Se aplica ese juicio y experiencia a todos los detalles técnicos y de gestión durante este proceso. Esta experiencia es proporcionada por cualquier persona o grupo de personas con conocimientos o formación especializada, y puede obtenerse de numerosas fuentes, incluidas:
Consultores
Interesados, incluidos los clientes o patrocinadores
Gestión de la integración: salidas
Acta de Constitución del Proyecto (Ver CD Apéndice B )
49
8.1.2. Gestión Del Alcance11
La gestión del alcance contiene todos los procesos necesarios que garantiza que el proyecto cuente con todo el trabajo necesario para cumplir el objetivo y éxito del proyecto. Su objetivo principal es definir y controlar qué se incluye y qué no se incluye en el proyecto. Definir el alcance: Es el proceso en el cual se busca desarrollar una descripción clara y detallada del proyecto y del producto. Crear la EDT: Es el proceso que en donde se subdividen los entregables y el trabajo del proyecto en componentes más pequeños y más fáciles de manejar. Verificar el alcance: Es el proceso que consiste en formalizar la aceptación de cada uno de los entregables del proyecto que se han terminado. Controlar el alcance: Es el proceso que consiste en monitorear el estado del alcance del proyecto y del producto.
Los procesos usados para gestionar el alcance del proyecto, así como las herramientas y técnicas asociadas, varían según el área de aplicación y normalmente se definen como parte del ciclo de vida del proyecto. La declaración del alcance del proyecto detallada y aprobada, y su EDT asociada junto con el diccionario de la EDT, constituyen la línea base del alcance del proyecto. Esta línea base del alcance se monitorea, se verifica y se controla durante todo el ciclo de vida del proyecto.
11
Gestión del alcance, PMBOK 4ta edición. Página 95. Adaptada y traducida por: SANTACRUZ, Juan, y RIOS, Andrés.
50
8.1.2.1. Definir El Alcance
Definir el alcance es el proceso que consiste en desarrollar una descripción detallada del proyecto y del producto. La preparación de una declaración detallada del alcance del proyecto es fundamental para su éxito, y se elabora a partir de los entregables principales, los supuestos y las restricciones que se documentan durante el inicio del proyecto.
Definir el alcance: entradas
Acta de constitución del proyecto: el acta de constitución del proyecto proporciona una descripción del proyecto y las características del producto. Contiene además los requisitos para la aprobación del proyecto.
Definir el alcance: herramientas y técnicas
Análisis del producto: para proyectos cuyo entregable es un producto, a diferencia de un servicio o resultado, el análisis del producto puede constituir una herramienta eficaz. Cada área de aplicación cuenta con uno o varios métodos generalmente aceptados para traducir en entregables tangibles las descripciones de alto nivel del producto.
Identificación de alternativas: la identificación de alternativas es una técnica que se emplea para generar diferentes enfoques para la ejecución y desarrollo del trabajo del proyecto. Puede utilizarse una variedad de técnicas de gestión, tales como la tormenta de ideas, el pensamiento lateral, la comparación entre pares, etc.
Definir el alcance: salidas
Declaración del alcance del proyecto (ver CD apéndice b): la declaración del alcance del proyecto proporciona un entendimiento común del alcance del proyecto entre los interesados en el proyecto. Esto permite al equipo del proyecto realizar una planificación más detallada, sirve como guía del equipo de trabajo durante la ejecución y proporciona la línea base para evaluar si las solicitudes de
51
cambio o de trabajo adicional se encuentran dentro o fuera de los límites del proyecto.
La declaración detallada del alcance del proyecto incluye lo siguiente:
Una descripción del alcance del producto: Elabora gradualmente las características del producto, servicio o resultado descrito en el acta de constitución del proyecto
Los criterios de aceptación del producto: Definen el proceso y los criterios para la aceptación de los productos, servicios o resultados completados.
Los entregables del proyecto: Incluyen tanto las salidas, que abarcan el producto o servicio del proyecto, como los resultados auxiliares, tales como los informes y documentación generados por el proceso de dirección del proyecto.
Las exclusiones del proyecto: Por lo general, identifican lo que está excluido del proyecto. Establecer explícitamente lo que está fuera del alcance del proyecto ayuda a gestionar las expectativas de los interesados.
Las restricciones del proyecto: Enumera y describe las restricciones específicas asociadas con el alcance del proyecto que limitan las opciones del equipo, como por ejemplo, un presupuesto predeterminado, o fechas o hitos del cronograma impuestos por el cliente o la organización ejecutante.
8.1.2.2. Crear la EDT
Crear la EDT es el proceso que consiste en subdividir los entregables del proyecto y el trabajo del proyecto en componentes más pequeños y más fáciles de manejar. La estructura de desglose del trabajo (EDT) es una descomposición jerárquica, basada en los entregables del trabajo que debe ejecutar el equipo del proyecto para lograr los objetivos del proyecto y crear los entregables requeridos, con cada nivel descendente de la EDT representando una definición cada vez más detallada del trabajo del proyecto. La EDT organiza y define el alcance total del proyecto y representa el trabajo especificado en la declaración del alcance del proyecto aprobada y vigente
52
Crear la EDT: entradas
Declaración del Alcance del Proyecto
Crear la EDT: herramientas y técnicas
Descomposición: La descomposición es la subdivisión de los entregables del proyecto en componentes más pequeños y más manejables, hasta que el trabajo y los entregables queden definidos al nivel de paquetes de trabajo. El nivel de paquetes de trabajo es el nivel más bajo en la EDT, y es aquél en el que el costo y la duración de las actividades del trabajo pueden estimarse y gestionarse de manera más confiable. Esta técnica se denomina a veces planificación gradual. La EDT representa todo el trabajo necesario para realizar el producto o el proyecto. El total del trabajo en los niveles inferiores de la EDT debe corresponder al cúmulo de los niveles superiores, de modo que no se omita nada y que no se efectúe ningún trabajo innecesario. Crear la EDT: salidas
EDT: La EDT es una descomposición jerárquica, basada en los entregables del trabajo que debe ejecutar el equipo del proyecto para lograr los objetivos del proyecto y crear los entregables requeridos, con cada nivel descendente de la EDT representando una definición cada vez más detallada del trabajo del proyecto. Diccionario de la EDT: El diccionario de la EDT es un documento generado por el proceso Crear la EDT, cuya función es respaldar la EDT. El diccionario de la EDT proporciona una descripción más detallada de los componentes de la EDT, incluyendo los paquetes de trabajo. La información del diccionario de la EDT incluye, entre otros:
La descripción del trabajo
La organización responsable
Una lista de hitos del cronograma
Las actividades asociadas del cronograma
53
Los recursos necesarios
Los estimados de costo
Los requisitos de calidad
Los criterios de aceptación
Figura 4. EDT - Estructura divisoria del trabajo
Fuente: PMBOK.
8.1.2.3. Verificar el alcance
Verificar el alcance es el proceso que consiste en formalizar la aceptación de los entregables del proyecto que se han completado. Verificar el alcance incluye revisar los entregables con el cliente para asegurarse de que se han completado satisfactoriamente y para obtener de ellos su aceptación formal.
54
Verificar el alcance: entradas
Plan para la dirección del proyecto: El plan para la dirección del proyecto (Gestión de integración) contiene la línea base del alcance. Los componentes de la línea base del alcance incluyen:
La declaración del alcance del proyecto: La declaración del alcance del proyecto incluye la descripción del alcance del producto y los entregables del proyecto, y define los criterios de aceptación establecidos por el usuario del producto.
La EDT: La EDT define cada entregable y su descomposición en paquetes de trabajo.
El diccionario de la EDT: El diccionario de la EDT contiene una descripción detallada del trabajo y documentación técnica acerca de cada elemento de la EDT.
Documentación de requisitos (Ingeniera de requisitos): La documentación de requisitos enumera todos los requisitos del proyecto y del producto, los requisitos técnicos y de otra índole que deben contemplarse para el proyecto y el producto, junto con sus criterios de aceptación.
Verificar el alcance: herramientas y técnicas
Inspección: La inspección incluye actividades tales como medir, examinar y verificar para determinar si el trabajo y los entregables cumplen con los requisitos y los criterios de aceptación del producto. Las inspecciones se denominan también, según el caso, revisiones, revisiones del producto, auditorías y revisiones generales.
55
Verificar el alcance: salidas
Entregables aceptados (ver CD Apéndice B): Los entregables que cumplen con los criterios de aceptación son formalmente firmados y aprobados por el cliente o el patrocinador. La documentación formal recibida del cliente o del patrocinador reconociendo la aceptación formal de los entregables del proyecto por parte de los interesados es transferida al proceso cerrar proyecto o fase.
8.1.2.4. Controlar el alcance
Controlar el alcance es el proceso por el que se monitorea el estado del alcance del proyecto y del producto. Controlar el alcance: entradas
Plan para la dirección del proyecto: El plan para la dirección del proyecto descrito contiene la siguiente información que se utiliza para controlar el alcance:
La línea base del alcance: La línea base del alcance se compara con los resultados reales para determinar si es necesario implementar un cambio, o una acción preventiva o correctiva. El plan para la gestión del alcance del proyecto: El plan para la gestión del alcance del proyecto describe la manera en que se gestionará y controlará el alcance del proyecto.
El plan de gestión de la configuración: El plan de gestión de la configuración define los elementos que son configurables, los que requieren un control formal de cambios, y el proceso para controlar los cambios a estos elementos.
El plan de gestión de requisitos: El plan de gestión de requisitos puede incluir el modo en que se realizará la planificación, el seguimiento y la comunicación de las actividades relacionadas con los requisitos, y el modo en
56
que se iniciarán los cambios a los requisitos del producto, servicio o resultado. También describe cómo se analizarán los impactos y los niveles de autorización requeridos para aprobar estos cambios. Información sobre el desempeño del trabajo: Se refiere a la información sobre el avance del proyecto, tal como los entregables que han sido iniciados, su avance y los entregables que han sido terminados.
Controlar el alcance: herramientas y técnicas
Análisis de variación: Las mediciones del desempeño del proyecto se utilizan para evaluar la magnitud de la variación respecto de la línea base original del alcance. Los aspectos importantes del control del alcance del proyecto incluyen la determinación de la causa y del grado de variación con relación a la línea base del alcance y la decisión acerca de la necesidad de aplicar acciones preventivas o correctivas. Controlar el alcance: salidas
Mediciones del desempeño del trabajo: Las mediciones pueden incluir el desempeño técnico planificado con respecto al real u otras mediciones del desempeño del alcance. Esta información se documenta y se comunica a los interesados.
57
8.1.3 Gestión del tiempo del proyecto 12
La gestión del tiempo del proyecto incluye los procesos requeridos para administrar la finalización del proyecto a tiempo. Definir las actividades: Es el proceso que consiste en identificar las acciones específicas a ser realizadas para elaborar los entregables del proyecto.
Secuenciar las actividades: Es el proceso que consiste en identificar y documentar las interrelaciones entre las actividades del proyecto.
Estimar los recursos de las actividades: Es el proceso que consiste en estimar el tipo y las cantidades de materiales, personas, equipos o suministros requeridos para ejecutar cada actividad.
Estimar la duración de las actividades: Es el proceso que consiste en establecer aproximadamente la cantidad de períodos de trabajo necesarios para finalizar cada actividad con los recursos estimados.
Desarrollar el cronograma: Es el proceso que consiste en analizar la secuencia de las actividades, su duración, los requisitos de recursos y las restricciones del cronograma para crear el cronograma del proyecto. Controlar el cronograma: Es el proceso por el que se da seguimiento al estado del proyecto para actualizar el avance del mismo y gestionar cambios a la línea base del cronograma.
12
Gestión del tiempo, PMBOK, 4ta edición. Página 116. Adaptada y traducida por: SANTACRUZ, Juan, y RIOS, Andrés.
58
8.1.3.1. Definir las actividades
Definir las actividades es el proceso que consiste en identificar las acciones específicas a ser realizadas para elaborar los entregables del proyecto. El proceso crear la EDT identifica los entregables en el nivel más bajo de la estructura de desglose del trabajo (EDT), denominado paquetes de trabajo. Los paquetes de trabajo del proyecto se descomponen normalmente en componentes más pequeños llamados actividades, que representan el trabajo necesario para completar los paquetes de trabajo. Las actividades proporcionan una base para la estimación, planificación, ejecución, seguimiento y control del trabajo del proyecto Definir las actividades: entradas
Línea base del alcance: Los entregables, restricciones y supuestos del proyecto están documentados en la línea base del alcance del proyecto
Definir las actividades: herramientas y técnicas
Descomposición: La técnica de descomposición, consiste en subdividir los paquetes de trabajo del proyecto en componentes más pequeños y más fáciles de manejar, denominados actividades. Las actividades representan el esfuerzo necesario para completar un paquete de trabajo.
Plantillas: Una lista de actividades estándar o una parte de una lista de un proyecto previo, puede utilizarse a menudo como plantilla para un nuevo proyecto. La información relacionada con los atributos de las actividades de las plantillas también puede incluir otra información descriptiva útil para la definición de las actividades. Las plantillas también pueden utilizarse para identificar hitos típicos del cronograma.
59
Definir las actividades: salidas
Lista de actividades: La lista de actividades es una lista exhaustiva que abarca todas las actividades del cronograma necesarias para el proyecto. La lista de actividades incluye el identificador de la actividad y una descripción del alcance del trabajo para cada actividad, con el nivel de detalle suficiente para que los miembros del equipo del proyecto comprendan el trabajo que deben realizar.
Atributos de la actividad: Los atributos de la actividad amplían la descripción de la actividad, identificando los múltiples componentes relacionados con cada una de ellas. Estos atributos incluyen el identificador de la actividad, el nombre de la actividad, los códigos de la actividad, la descripción de la actividad, las actividades predecesoras, las actividades sucesoras, los requisitos de recursos, las fechas impuestas, las restricciones y los supuestos, la persona responsable de ejecutar el trabajo, la zona geográfica donde debe realizarse el trabajo Los atributos de la actividad se utilizan para el desarrollo del cronograma y para seleccionar, ordenar y clasificar las actividades del cronograma planificadas de diferentes maneras dentro de los informes. La cantidad de atributos varía según el área de aplicación.
Lista de hitos: Un hito es un punto o evento significativo dentro del proyecto. Una lista de hitos identifica todos los hitos e indica si éstos son obligatorios, como los exigidos por contrato, u opcionales, como los basados en la información histórica.
8.1.3.2. Secuenciar las actividades
Secuenciar las actividades es el proceso que consiste en identificar y documentar las relaciones entre las actividades del proyecto. La secuencia de actividades se establece mediante relaciones lógicas. La secuencia puede establecerse utilizando un software de gestión de proyectos o empleando técnicas manuales o automatizadas. Secuenciar las actividades: entradas
Lista de actividades
60
Lista de hitos: La lista de hitos puede incluir fechas programadas para hitos específicos.
Declaración del alcance del proyecto: Contiene la descripción del alcance del producto, que incluye las características del producto que pueden afectar el establecimiento de la secuencia de las actividades. Aunque estos efectos a menudo son visibles en la lista de actividades, por lo general la descripción del alcance del producto se revisa para corroborar su exactitud. Secuenciar las actividades: herramientas y técnicas
Método de diagramación por precedencia (PDM): El método de diagramación por precedencia (PDM) es utilizado en el método de la ruta crítica (CPM) para crear un diagrama de red del cronograma del proyecto que utiliza casillas o rectángulos, denominados nodos, para representar las actividades, que se conectan con flechas que muestran sus relaciones lógicas. El método de diagramación por precedencia incluye cuatro tipos de dependencias o relaciones lógicas.
Final a Inicio (FI): El inicio de la actividad sucesora depende de la finalización de la actividad predecesora.
Final a Final (FF): La finalización de la actividad sucesora depende de la finalización de la actividad predecesora.
Inicio a Inicio (II): El inicio de la actividad sucesora depende del inicio de la actividad predecesora.
Inicio a Final (IF): La finalización de la actividad sucesora depende del inicio de la actividad predecesora.
61
Figura 5. Método de diagramación por precedencia
Fuente: PMBOK.
Secuenciar las actividades: salidas
Diagramas de red del cronograma del proyecto: Los diagramas de red del cronograma del proyecto son una representación esquemática de las actividades del cronograma del proyecto y de sus relaciones lógicas, también denominadas dependencias. La elaboración de un diagrama de red del cronograma del proyecto puede hacerse en forma manual o mediante la utilización de un software de gestión de proyectos. Puede incluir todos los detalles del proyecto o contener una o más actividades resumen.
8.1.3.3. Estimar los recursos de las actividades
Estimar los recursos de las actividades es el proceso que consiste en estimar el tipo y las cantidades de materiales, personas, equipos o suministros requeridos para ejecutar cada actividad.
Estimar los recursos de las actividades: entradas
Lista de actividades: Identifica las actividades que necesitarán recursos.
62
Estimar los recursos de las actividades: herramientas y técnicas
Estimación ascendente: El trabajo dentro de esa actividad se descompone a un nivel mayor de detalle. Se estiman las necesidades de recursos. Estos estimados se suman luego en un total para cada uno de los recursos de la actividad.
Software de gestión de proyectos: El software de gestión de proyectos tiene la capacidad de ayudar a planificar, organizar y gestionar los grupos de recursos, y de desarrollar estimados de los mismos. En función de la complejidad del software, pueden definirse las estructuras de desglose de recursos, su disponibilidad y sus costos, así como diversos calendarios, para ayudar en la optimización del uso de recursos. Estimar los recursos de las actividades: salidas
Requisitos de recursos de la actividad: La salida del proceso estimar los recursos de las actividades identifica los tipos y la cantidad de recursos necesarios para cada actividad de un paquete de trabajo. Estos requisitos pueden sumarse para determinar los recursos estimados para cada paquete de trabajo. El nivel de detalle y especificidad de las descripciones de los requisitos de recursos puede variar según el área de aplicación. La documentación de los requisitos de recursos para cada actividad puede incluir la base de la estimación de cada recurso, así como los supuestos considerados al determinar los tipos de recursos que se aplican, su disponibilidad y en qué cantidad se utilizan.
Estructura de desglose de recursos: La estructura de desglose de recursos es una estructura jerárquica de los recursos, identificados por categoría y tipo de recurso. Algunos ejemplos de categorías de recursos son la mano de obra, el material, los equipos y los suministros. Los tipos de recursos pueden incluir el nivel de habilidad, el nivel de formación u otra información apropiada para el proyecto. La estructura de desglose de recursos es útil para organizar y comunicar los datos del cronograma del proyecto, incluyendo la información sobre utilización de recursos.
63
8.1.3.4. Estimar la duración de las actividades
Estimar la duración de las actividades es el proceso que consiste en establecer aproximadamente la cantidad de períodos de trabajo necesarios para finalizar cada actividad con los recursos estimados. El proceso estimar la duración de las actividades requiere que se estime la cantidad de esfuerzo de trabajo requerido y la cantidad de recursos para completar la actividad; esto permite determinar la cantidad de periodos de trabajo (duración de la actividad) necesarios para completar la actividad. Se documentan todos los datos y supuestos que respaldan el estimado de la duración para cada estimado de duración de la actividad. Estimar la duración de las actividades: entradas
Lista de actividades Atributos de la actividad
Declaración del alcance del proyecto: Las restricciones y supuestos de la declaración del alcance del proyecto se tienen en cuenta al estimar la duración de las actividades. Estimar la duración de las actividades: herramientas y técnicas
Juicio de expertos: El juicio de expertos, guiado por la información histórica, puede proporcionar información sobre el estimado de la duración o las duraciones máximas recomendadas, procedentes de proyectos similares anteriores. El juicio de expertos también puede utilizarse para determinar si es conveniente combinar métodos de estimación y cómo conciliar las diferencias entre ellos.
Estimación análoga: La estimación análoga utiliza parámetros de un proyecto anterior similar, tales como la duración, el presupuesto, el tamaño, la carga y la complejidad, como base para estimar los mismos parámetros o medidas para un proyecto futuro. Por lo general, la estimación análoga es menos costosa y requiere menos tiempo que las otras técnicas, pero también es menos exacta
64
Estimar la duración de las actividades: salidas
Estimados de la duración de la actividad: Los estimados de la duración de las actividades son valoraciones cuantitativas de la cantidad probable de periodos de trabajo que se necesitarán para completar una actividad.
8.1.3.5. Desarrollar cronograma
Desarrollar el cronograma es el proceso que consiste en analizar el orden de las actividades, su duración, los requisitos de recursos y las restricciones para crear el cronograma del proyecto. La incorporación de las actividades, duraciones y recursos a la herramienta de planificación genera un cronograma con fechas de inicio, finalización e hitos planificados para completar las actividades del proyecto.
Desarrollar el cronograma: entradas
Lista de actividades
Atributos de la actividad
Diagramas de red del cronograma del proyecto
Requisitos de recursos de la actividad
Estimados de la duración de la actividad
Declaración del alcance del proyecto
Desarrollar el cronograma: herramientas y técnicas
Herramienta de planificación: Las herramientas automatizadas de planificación aceleran el proceso de planificación, generando fechas de inicio y finalización basadas en las entradas de actividades, los diagramas de red, los recursos y las duraciones de las actividades. Una herramienta de planificación puede utilizarse conjuntamente con otro software de gestión de proyectos, así como con métodos manuales.
65
Desarrollar el cronograma: salidas
Cronograma del proyecto: El cronograma del proyecto debe contener, como mínimo, una fecha de inicio y una fecha de finalización programadas para cada actividad. Si la planificación de recursos se realiza en una etapa temprana, entonces el cronograma mantendrá su carácter preliminar hasta que se hayan confirmado las asignaciones de recursos y se hayan establecido las fechas de inicio y finalización planificadas. Por lo general, este proceso se lleva a cabo antes de la conclusión del plan para la dirección del proyecto.
Diagramas de hitos: Estos diagramas son similares a los diagramas de barras, pero sólo identifican el inicio o la finalización programada de los principales entregables y las interfaces externas clave.
Figura 6. Diagrama de hitos
Fuente: PMBOK.
Diagramas de red del cronograma del proyecto: Estos diagramas, con la información de la fecha de las actividades, normalmente muestran la lógica de la red del proyecto y las actividades del cronograma que se encuentran dentro de la ruta crítica del proyecto.
66
Figura 7. Diagramas de red del cronograma del proyecto
Fuente: PMBOK.
8.1.3.6. Controlar cronograma
Controlar el cronograma es el proceso por el que se da seguimiento al estado del proyecto para actualizar el avance del mismo y gestionar cambios a la línea base del cronograma. Controlar el cronograma consiste en:
Determinar el estado actual del cronograma del proyecto
Influir en los factores que generan cambios en el cronograma
Determinar que el cronograma del proyecto ha cambiado
Gestionar los cambios reales conforme suceden
67
Controlar el cronograma: entradas
Plan para la dirección del proyecto
Cronograma del proyecto: Se trata de la versión más reciente del cronograma del proyecto, con anotaciones que indican las actualizaciones, las actividades terminadas y las actividades iniciadas a la fecha
Controlar el cronograma: herramientas y técnicas
Revisiones del desempeño: Las revisiones del desempeño permiten medir, comparar y analizar el desempeño del cronograma, en aspectos como las fechas reales de inicio y finalización, el porcentaje completado y la duración restante para el trabajo en ejecución. Una parte importante del control del cronograma es decidir si la variación del cronograma requiere acciones correctivas. Por ejemplo, un retraso importante en una actividad que está fuera de la ruta crítica puede tener un efecto mínimo en el cronograma total del proyecto, mientras que un retraso menor en una actividad crítica o casi crítica puede requerir una acción inmediata.
Software de gestión de proyectos: El software de gestión de proyectos para la elaboración de cronogramas permite hacer un seguimiento de las fechas planificadas en comparación con las fechas reales, y de proyectar los efectos de los cambios al cronograma del proyecto.
Herramienta de planificación: Los datos del cronograma se actualizan y compilan en el cronograma para reflejar el avance real del proyecto y el trabajo que queda pendiente. La herramienta de planificación y los datos de apoyo del cronograma se utilizan conjuntamente con métodos manuales u otro software de gestión de proyectos para realizar el análisis de la red del cronograma y generar un cronograma actualizado del proyecto.
Controlar el cronograma: salidas
Mediciones del desempeño del trabajo: Los valores calculados de la variación del cronograma (SV) y del índice de desempeño del cronograma (SPI) para los componentes de la EDT, en particular los paquetes de trabajo y las cuentas de control, se documentan y comunican a los interesados.
68
8.1.4. Gestión del Costo13
La gestión de los costos del proyecto incluye los procesos involucrados en estimar, presupuestar y controlar los costos de modo que se complete el proyecto dentro del presupuesto aprobado. Estimar los costos: Es el proceso que consiste en desarrollar una aproximación de los recursos financieros necesarios para completar las actividades del proyecto. Determinar el presupuesto: Es el proceso que consiste en sumar los costos estimados de actividades individuales o paquetes de trabajo para establecer una línea base de costo autorizada. Controlar los costos: Es el proceso que consiste en monitorear la situación del proyecto para actualizar el presupuesto del mismo y gestionar cambios a la línea base de costo.
13
Gestión de los costos del proyecto, PMBOK 4ta edición. Página 146. Adaptada y traducida por: SANTACRUZ, Juan, y
RIOS, Andrés.
69
8.1.4.1. Estimar los costos
Estimar los costos es el proceso que consiste en desarrollar una aproximación de los recursos monetarios necesarios para completar las actividades del proyecto. La estimación de costos es una predicción basada en la información disponible en un momento dado. Incluye la identificación y consideración de diversas alternativas de cómputo de costos para iniciar y completar el proyecto. La estimación de costos debe refinarse durante el transcurso del proyecto para reflejar los detalles adicionales a medida que éstos se hacen disponibles. La exactitud de la estimación del costo de un proyecto aumenta conforme el proyecto avanza a lo largo de su ciclo de vida. Los costos se estiman para todos los recursos que se asignarán al proyecto. Esto incluye, entre otros, el trabajo, los materiales, el equipo, los servicios y las instalaciones, así como categorías especiales tales como una asignación por inflación o un costo por contingencia. Estimar los costos: entradas
Línea base del alcance.
Enunciado del alcance: El enunciado del alcance proporciona la descripción del producto, los criterios de aceptación, los entregables claves, los límites del proyecto, los supuestos y las restricciones del proyecto. Uno de los supuestos básicos que es necesario establecer cuando se estiman los costos de un proyecto, es si los estimados se limitarán únicamente a los costos directos del proyecto o si incluirán además los costos indirectos. Los costos indirectos son aquéllos que no pueden asignarse a un proyecto específico y que, por lo tanto, se acumularán y distribuirán equitativamente entre varios proyectos por medio de algún procedimiento contable aprobado y documentado. Una de las restricciones más comunes para muchos proyectos es un presupuesto limitado.
Cronograma del proyecto: El tipo y la cantidad de recursos, así como la cantidad de tiempo que dichos recursos se aplican para completar el trabajo del proyecto, son los factores principales para determinar el costo del proyecto. Los recursos de la actividad del cronograma y sus respectivas duraciones se usan
70
como entradas clave para este proceso. Los estimados de la duración de las actividades afectará las estimaciones del costo de cualquier proyecto donde el presupuesto del proyecto incluya una asignación para el costo de financiamiento (incluyendo los cargos por intereses) y donde los recursos se apliquen por unidad de tiempo a lo largo de la duración de la actividad. Estimar los costos: herramientas y técnicas
Juicio de expertos
Análisis de reserva: Las estimaciones de costos pueden incluir reservas para contingencias (llamadas a veces asignaciones para contingencias) para tener en cuenta la incertidumbre del costo. La reserva para contingencias puede ser un porcentaje del costo estimado, una cantidad fija, o puede calcularse utilizando métodos de análisis cuantitativos. A medida que se dispone de información más precisa sobre el proyecto, la reserva para contingencias puede utilizarse, reducirse o eliminarse.
Software de estimación de costos para la dirección de proyectos: Las aplicaciones de software de estimación de costos, las hojas de cálculo computarizadas, y las herramientas de simulación y estadísticas son cada vez más utilizadas para asistir en el proceso de estimación de costos. Estimar los costos: salidas
Estimaciones de costos de las actividades: Las estimaciones de costos de las actividades son evaluaciones cuantitativas de los costos probables que se requieren para completar el trabajo del proyecto. Pueden presentarse de manera resumida o detallada. Los costos se estiman para todos los recursos que se aplican a la estimación de costos de las actividades. Esto incluye, entre otros, el trabajo directo, los materiales, el equipo, los servicios, las instalaciones, la tecnología de la información y categorías especiales, tales como una asignación por inflación o una reserva para contingencias de costo.
8.1.4.2. Determinar presupuesto
Determinar el presupuesto es el proceso que consiste en sumar los costos estimados de actividades individuales o paquetes de trabajo para establecer una
71
línea base de costo autorizada. Esta línea base incluye todos los presupuestos autorizados, pero excluye las reservas de gestión. Los presupuestos del proyecto constituyen los fondos autorizados para ejecutar el proyecto. El desempeño de los costos del proyecto se medirá con respecto al presupuesto autorizado. Determinar el presupuesto: entradas
Estimaciones de costos de las actividades: Las estimaciones del costo de cada actividad dentro de un paquete de trabajo se suman para obtener una estimación de costos de cada paquete de trabajo. Base de las estimaciones Línea base del alcance
Enunciado del alcance: Las limitaciones formales periódicas en cuanto a los gastos de fondos del proyecto pueden ser impuestas por la organización, por contrato o por otras entidades, tales como las agencias gubernamentales. Estas restricciones de financiamiento se reflejan en el enunciado del alcance del proyecto.
Estructura de desglose del trabajo. Diccionario de la EDT: El diccionario de la EDT y los enunciados detallados del trabajo relacionados proporcionan una identificación de los entregables y una descripción del trabajo en cada componente de la EDT necesario para producir cada entregable.
Cronograma del proyecto: El cronograma del proyecto, como parte del plan para la dirección del proyecto, incluye las fechas de inicio y finalización programadas de las actividades del proyecto, los hitos, los paquetes de trabajo, los paquetes de planificación y las cuentas de control. Esta información puede utilizarse para sumar los costos a los periodos del calendario en los cuales se ha planificado incurrir en dichos costos.
72
Calendarios de recursos: Los calendarios de recursos proporcionan información sobre qué recursos se han asignado al proyecto y para qué periodo. Esta información puede utilizarse para indicar el costo de los recursos durante el proyecto. Determinar el presupuesto: herramientas y técnicas
Suma de costos: Las estimaciones de costos se suman por paquetes de trabajo, de acuerdo con la EDT. Las estimaciones de costos de los paquetes de trabajo luego se suman para los niveles superiores de componentes de la EDT, tales como las cuentas de control, y finalmente para todo el proyecto. Juicio de expertos: Un juicio que se brinda sobre la base de la experiencia en un área de aplicación, un área de conocimiento, una disciplina, una industria, etc., según resulte apropiado para la actividad que se está desarrollando, y que debe utilizarse para determinar el presupuesto. Dicha experiencia puede ser proporcionada por cualquier grupo o persona con una educación, conocimiento, habilidad, experiencia o capacitación especializada. Determinar el presupuesto: salidas
Línea base del desempeño de costos: La línea base del desempeño de costos es un presupuesto hasta la conclusión (BAC) aprobado y distribuido en el tiempo, que se utiliza para medir, monitorear y controlar el desempeño global del costo del proyecto. Se establece sumando los presupuestos aprobados por periodo de tiempo y normalmente se representa como una curva S, tal como se ilustra en el siguiente gráfico. En la técnica de gestión del valor ganado, la línea base del desempeño de costos se conoce como línea base para la medición del desempeño (PMB).
73
Figura 8. Línea base de costo, gastos y requisitos de financiamiento.
Fuente: PMBOK.
8.1.4.3. Controlar Los Costos
Controlar los costos es el proceso por el que se monitorea la situación del proyecto para actualizar el presupuesto del mismo y gestionar cambios a la línea base de costo. Controlar los costos: entradas
Plan para la dirección del proyecto: El plan para la dirección del proyecto contiene la siguiente información que se utiliza para controlar los costos:
Línea base del desempeño de costos. La línea base del desempeño de costos se compara con los resultados reales para determinar si es necesario implementar un cambio, o una acción preventiva o correctiva.
Plan de gestión de costos: El plan de gestión de costos describe la forma en que se gestionarán y controlarán los costos del proyecto.
Información sobre el desempeño del trabajo: La información sobre el desempeño del trabajo incluye información sobre el avance del proyecto, tal como los entregables iniciados, su avance y los entregables terminados. La información
74
también incluye los costos autorizados y aquéllos en los que se ha incurrido, y estimaciones para completar el trabajo del proyecto. Controlar los costos: herramientas y técnicas
Gestión del valor ganado: La gestión del valor ganado (EVM) es un método que se utiliza comúnmente para la medición del desempeño. Integra las mediciones del alcance del proyecto, costo y cronograma para ayudar al equipo de dirección del proyecto a evaluar y medir el desempeño y el avance del proyecto. Es una técnica de dirección de proyectos que requiere la constitución de una línea base integrada con respecto a la cual se puede medir el desempeño durante la ejecución del proyecto. La EVM establece y monitorea tres dimensiones clave para cada paquete de trabajo y cada cuenta de control:
Valor planificado: El valor planificado (PV) es el presupuesto autorizado asignado al trabajo que debe ejecutarse para completar una actividad o un componente de la estructura de desglose del trabajo. Incluye el trabajo detallado autorizado, así como el presupuesto para dicho trabajo autorizado, que se asigna por fase durante el ciclo de vida del proyecto. El total del PV se conoce a veces como la línea base para la medición del desempeño (PMB). El valor planificado total para el proyecto también se conoce como presupuesto hasta la conclusión (BAC).
Valor ganado: El valor ganado (ev) es el valor del trabajo completado expresado en términos del presupuesto aprobado asignado a dicho trabajo para una actividad del cronograma o un componente de la estructura de desglose del trabajo. Es el trabajo autorizado que se ha completado, más el presupuesto autorizado para dicho trabajo completado. El ev medido debe corresponderse con la línea base del pv (pmb) y no puede ser mayor que el presupuesto aprobado del pv para un componente. El término ev se usa a menudo para describir el porcentaje completado de un proyecto. Deben establecerse criterios de medición del avance para cada componente de la EDT, con objeto de medir el trabajo en curso.
Costo real: El costo real (AC) es el costo total en el que se ha incurrido realmente y que se ha registrado durante la ejecución del trabajo realizado para una actividad o componente de la estructura de desglose del trabajo. Es el
75
costo total en el que se ha incurrido para llevar a cabo el trabajo medido por el EV. El AC debe corresponderse, por su definición, con lo que haya sido presupuestado para el PV y medido para el EV (p.ej., sólo horas directas, sólo costos directos o todos los costos, incluidos los costos indirectos). El AC no tiene límite superior; se medirán todos los costos en los que se incurra para obtener el EV. Los tres parámetros (valor planificado, valor ganado y costo real) pueden monitorearse e informarse, por periodos (normalmente semanalmente o mensualmente) y de forma acumulativa.
Controlar los costos: salidas
Mediciones del desempeño del trabajo: Los valores calculados del CV, SV, CPI y SPI para los componentes de la EDT, en particular los paquetes de trabajo y las cuentas de control, se documentan y comunican a los interesados.
76
8.1.5. Gestión del recurso humano14
La gestión de los recursos humanos del proyecto incluye los procesos que organizan y dirigen el equipo del proyecto. El equipo del proyecto está compuesto por las personas a quienes se les han asignado roles y responsabilidades para concluir el proyecto. La participación temprana de los miembros del equipo aporta experiencia durante el proceso de planificación y fortalece el compromiso con el proyecto. El tipo y la cantidad de miembros del equipo del proyecto a menudo pueden cambiar, a medida que avanza el proyecto.
Los procesos de gestión de los recursos humanos del proyecto incluyen lo siguiente:
Planificación de los recursos humanos: identificar y documentar los roles del proyecto, las responsabilidades y las relaciones de informe, así como crear el plan de gestión de personal.
Adquirir el equipo del proyecto: obtener los recursos humanos necesarios para concluir el proyecto.
Desarrollar el equipo del proyecto: mejorar las competencias y la interacción de los miembros del equipo para lograr un mejor rendimiento del proyecto.
Gestionar el equipo del proyecto: hacer un seguimiento del rendimiento de los miembros del equipo, proporcionar retroalimentación, resolver polémicas y coordinar cambios a fin de mejorar el rendimiento del proyecto.
14
Gestión de los recursos humanos, PMBOK 4ta edición. Página 188. Adaptada y traducida por: SANTACRUZ, Juan, y
RIOS, Andrés.
77
8.1.5.1. Planificación de los recursos humanos
La planificación de los recursos humanos determina los roles del proyecto y las responsabilidades y crea el plan de gestión de personal. Los roles del proyecto pueden designarse para personas o grupos. El plan de gestión de personal puede incluir cómo y cuándo se adquirirán los miembros del equipo del proyecto, los criterios para eximirlos del proyecto, la identificación de las necesidades de formación, los planes relativos a recompensas y reconocimiento, consideraciones sobre cumplimiento, polémicas de seguridad y el impacto del plan de gestión de personal sobre la organización.
Planificación de los recursos humanos: entradas
Plan de gestión del proyecto: el plan de gestión del proyecto incluye los requisitos de recursos de las actividades y las descripciones de las actividades de dirección de proyectos, tales como aseguramiento de calidad, gestión de riesgos y adquisición, que ayudarán al equipo de dirección del proyecto a identificar todos los roles y las responsabilidades necesarios.
Planificación de los recursos humanos: herramientas y técnicas
Organigramas y descripciones de cargos: Existen diversos formatos para documentar los roles y las responsabilidades de los miembros del equipo. La mayoría de los formatos corresponde a uno de estos tres tipos: Figura 9. Organigramas y descripciones de cargos
Fuente: PMBOK.
78
Diagramas de tipo jerárquico: Se puede usar la estructura de organigrama tradicional para mostrar los cargos y las relaciones en un formato gráfico descendente. Las estructuras de desglose del trabajo (EDT), que están diseñadas principalmente para mostrar cómo los productos entregables del proyecto se subdividen en paquetes de trabajo, se convierten en una forma de mostrar áreas de responsabilidad de alto nivel. La estructura de desglose de la organización (OBS) es similar a la EDT, pero en lugar de estar ordenada según un desglose de los productos entregables del proyecto, está ordenada según los departamentos, las unidades o los equipos existentes de una organización.
Diagramas basados en una matriz: Una matriz de asignación de responsabilidades (RAM) se usa para ilustrar las conexiones entre el trabajo que debe realizarse y los miembros del equipo del proyecto. El formato matricial, a veces denominado tabla, permite a una persona ver todas las actividades asociadas con una persona o ver todas las personas asociadas con una actividad. Las personas pueden mostrarse individualmente o como grupos.
Formatos orientados al texto: Las responsabilidades de los miembros del equipo que requieran descripciones detalladas pueden especificarse en formatos orientados al texto. Generalmente en forma de resumen, los documentos proporcionan información como, por ejemplo, responsabilidades, autoridad, competencias y calificaciones. Estas descripciones y estos formularios constituyen excelentes plantillas para proyectos futuros, especialmente cuando la información se actualiza en todo el proyecto actual aplicando las lecciones aprendidas.
Planificación de los recursos humanos: salidas
Organigramas del proyecto: Un organigrama del proyecto es una representación gráfica de los miembros del equipo del proyecto y sus relaciones de informe. Puede ser formal o informal, muy detallado o ampliamente esbozado, dependiendo de las necesidades del proyecto.
Plan de gestión del personal: El plan de gestión de personal describe cuándo y cómo se cumplirán los requisitos de recursos humanos. El plan se actualiza continuamente durante el proyecto, para dirigir la adquisición continua de miembros del equipo y las acciones de desarrollo. La información del plan de gestión de personal varía según el área de aplicación y el tamaño del proyecto, pero los conceptos que deben tenerse en cuenta incluyen:
79
Adquisición de personal. Al planificar la adquisición de miembros del equipo del proyecto surgen varias preguntas. Por ejemplo, ¿los recursos humanos provendrán de la organización misma o de fuentes externas contratadas? ¿Los miembros del equipo deberán trabajar en un lugar centralizado o podrán trabajar desde lugares distantes? ¿Cuáles son los costos asociados con cada nivel de experiencia necesario para el proyecto?
Horarios. El plan de gestión de personal describe los plazos necesarios para los miembros del equipo del proyecto, ya sea de forma individual o colectiva, así como también cuándo deberían iniciarse las actividades de adquisición. El diagrama puede incluir una línea horizontal que represente la cantidad máxima de horas disponibles de un recurso en particular.
8.1.5.2. Adquirir el equipo del proyecto
Adquirir el equipo del proyecto es el proceso de obtener los recursos humanos necesarios para completar el proyecto.
Adquirir el equipo del proyecto: entradas
Organigramas del proyecto: Los organigramas del proyecto proporcionan una descripción general acerca de la cantidad de personas necesarias para el proyecto.
Plan de gestión de personal: El plan de gestión de personal, junto con el cronograma del proyecto, identifica los períodos durante los cuales se necesitará a cada miembro del equipo del proyecto y otra información importante para la adquisición del equipo del proyecto. Adquirir el equipo del proyecto: herramientas y técnicas
Adquisición: Cuando la organización ejecutante carece del personal interno necesario para concluir el proyecto, los servicios requeridos pueden adquirirse de fuentes externas. Esto puede implicar contratar consultores individuales o subcontratar trabajo a otra organización.
80
Adquirir el equipo del proyecto: salidas
Asignaciones del personal del proyecto: Se considera que el proyecto está dotado de personal cuando se han asignado las personas apropiadas para trabajar en él. La documentación puede incluir un directorio del equipo del proyecto, memorandos a los miembros del equipo y que los nombres se incluyan en otras partes del plan de gestión del proyecto, tales como los organigramas y cronogramas del proyecto.
Disponibilidad de recursos: la disponibilidad de recursos documenta los períodos de tiempo que cada miembro del equipo del proyecto puede trabajar en el proyecto. La creación de un cronograma final fiable depende de tener una buena comprensión de los conflictos de cronograma de cada persona, incluidas las vacaciones y los compromisos con otros proyectos.
8.1.5.3. Desarrollar el equipo del proyecto
Desarrollar el equipo del proyecto mejora las competencias e interacciones de los miembros del equipo a fin de mejorar el rendimiento del proyecto. Los objetivos incluyen:
Mejorar las habilidades de los miembros del equipo a fin de aumentar su capacidad de completar las actividades del proyecto
Mejorar los sentimientos de confianza y cohesión entre los miembros del equipo a fin de incrementar la productividad a través de un mayor trabajo en equipo.
Desarrollar el equipo del proyecto: entradas
Asignaciones del personal del proyecto: El desarrollo del equipo comienza con una lista de los miembros del equipo del proyecto. Los documentos de asignación de personal del proyecto identifican a las personas que integran el equipo.
81
Plan de gestión de personal: El plan de gestión de personal identifica las estrategias y los planes de formación para desarrollar el equipo del proyecto. A medida que el proyecto avanza, elementos como las recompensas, la retroalimentación, la formación adicional y las acciones disciplinarias se añaden al plan como resultado de las evaluaciones continuas de rendimiento del equipo y otras formas de gestión del equipo del proyecto
Disponibilidad de recursos: La información de disponibilidad de recursos identifica cuándo los miembros del equipo del proyecto pueden participar en las actividades de desarrollo del equipo. Desarrollar el equipo del proyecto: herramientas y técnicas
Habilidades de dirección general: Al comprender los sentimientos de los miembros del equipo del proyecto, prever sus acciones, reconocer sus inquietudes y hacer un seguimiento de sus polémicas, el equipo de dirección del proyecto puede reducir en gran medida los problemas y aumentar la cooperación. Las habilidades como la empatía, la influencia, la creatividad y la facilitación del grupo son activos valiosos al gestionar el equipo del proyecto. Desarrollar el equipo del proyecto: salidas
Evaluación del rendimiento del equipo: Se espera que las estrategias y actividades de desarrollo del equipo efectivas mejoren el rendimiento del equipo, lo cual aumenta la probabilidad de cumplir con los objetivos del proyecto. La evaluación de la efectividad de un equipo puede incluir indicadores tales como:
Mejoras en las habilidades que permiten a una persona realizar las actividades asignadas de forma más efectiva
Mejoras en las competencias y los sentimientos que ayudan al equipo a mejorar su rendimiento como grupo
82
8.1.5.4. Gestionar el equipo del proyecto
Gestionar el equipo del proyecto implica hacer un seguimiento del rendimiento de los miembros del equipo, proporcionar retroalimentación, resolver polémicas y coordinar cambios a fin de mejorar el rendimiento del proyecto. Como consecuencia de gestionar el equipo del proyecto, se actualiza el plan de gestión de personal, se presentan solicitudes de cambio, se proporciona una entrada a las evaluaciones de rendimiento de la organización y las lecciones aprendidas se añaden a la base de datos de la organización.
Gestionar el equipo del proyecto: entradas
Asignaciones del personal del proyecto: las asignaciones del personal del proyecto proporcionan una lista de los miembros del equipo del proyecto que debe ser evaluada durante este proceso de seguimiento y control.
Roles y responsabilidades: Una lista de los roles y las responsabilidades del personal se utiliza para supervisar y evaluar el rendimiento.
Organigramas del proyecto: Los organigramas del proyecto proporcionan una imagen de las relaciones de informe entre los miembros del equipo del proyecto.
Plan de gestión de personal: El plan de gestión de personal detalla los períodos durante los cuales se espera que los miembros del equipo trabajen en el proyecto, junto con información como planes de formación, requisitos de certificación y polémicas de cumplimiento.
Evaluación del rendimiento del equipo: El equipo de dirección del proyecto realiza evaluaciones formales o informales constantes del rendimiento del equipo del proyecto. Al evaluar continuamente el rendimiento del equipo del proyecto, pueden llevarse a cabo acciones para resolver polémicas, modificar la comunicación, tratar los conflictos y mejorar la interacción del equipo.
83
Gestionar el equipo del proyecto: herramientas y técnicas
Evaluaciones del rendimiento del proyecto: Los miembros del equipo del proyecto reciben retroalimentación de las personas que supervisan su trabajo del proyecto. También puede recogerse información de evaluación de las personas que interaccionan con los miembros del equipo del proyecto utilizando los principios de retroalimentación de 360 grados. El término “360 grados” significa que la persona que está siendo evaluada recibe retroalimentación sobre el rendimiento de muchas fuentes, incluidos los superiores, colegas y subordinados.
Gestionar el equipo del proyecto: salidas
Acciones correctivas recomendadas: La acción correctiva correspondiente a la gestión de recursos humanos incluye elementos tales como cambios en el personal, formación adicional y acciones disciplinarias. Los cambios en el personal pueden consistir en transferir personas a diferentes asignaciones, externalizar algunos trabajos y reemplazar a los miembros del equipo que abandonan el proyecto. Acciones preventivas recomendadas: Las acciones preventivas pueden incluir formación cruzada para reducir los problemas durante las ausencias de miembros del equipo del proyecto, aclaración adicional de los roles para asegurar que se cumplan todas las responsabilidades, y tiempo personal adicional en previsión del trabajo extra que puede ser necesario en el futuro cercano para cumplir con los plazos del proyecto.
84
8.1.6. Gestión del riesgo15
Los objetivos de la gestión de los riesgos del proyecto son aumentar la probabilidad y el impacto de los eventos positivos, y disminuir la probabilidad y el impacto de los eventos adversos para el proyecto. Los procesos de gestión de los riesgos del proyecto incluyen lo siguiente:
Planificación de la gestión de riesgos: decidir cómo enfocar, planificar y ejecutar las actividades de gestión de riesgos para un proyecto.
Identificación de riesgos: determinar qué riesgos pueden afectar al proyecto y documentar sus características.
Análisis cualitativo de riesgos: priorizar los riesgos para realizar otros análisis o acciones posteriores, evaluando y combinando su probabilidad de ocurrencia y su impacto.
Análisis cuantitativo de riesgos: analizar numéricamente el efecto de los riesgos identificados en los objetivos generales del proyecto.
Planificación de la respuesta a los riesgos: desarrollar opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto.
Seguimiento y control de riesgos: realizar el seguimiento de los riesgos identificados, supervisar los riesgos residuales, identificar nuevos riesgos, ejecutar planes de respuesta a los riesgos y evaluar su efectividad a lo largo del ciclo de vida del proyecto.
15
Gestión de los riesgos del proyecto, PMBOK 4ta edición. Página 70. Adaptada y traducida por: SANTACRUZ, Juan, y
RIOS, Andrés.
85
8.1.6.1. Planificación de la gestión de riesgos
Una planificación cuidadosa y explícita mejora la posibilidad de éxito de los otros cinco procesos de gestión de riesgos. La planificación de la gestión de riesgos es el proceso de decidir cómo abordar y llevar a cabo las actividades de gestión de riesgos de un proyecto. La planificación de los procesos de gestión de riesgos es importante para garantizar que el nivel, el tipo y la visibilidad de la gestión de riesgos sean acordes con el riesgo y la importancia del proyecto para la organización, a fin de proporcionar recursos y tiempo suficientes para las actividades de gestión de riesgos, y para establecer una base acordada para evaluar los riesgos. Un riesgo de un proyecto es un evento o condición inciertos que, si se produce, tiene un efecto positivo o negativo sobre al menos un objetivo del proyecto, como tiempo, coste, alcance o calidad (es decir, cuando el objetivo de tiempo de un proyecto es cumplir con el cronograma acordado; cuando el objetivo de coste del proyecto es cumplir con el coste acordado; etc.). Si ocurre alguno de estos eventos inciertos, puede haber un impacto sobre el coste, el cronograma o el rendimiento del proyecto.
Gestión de los riesgos entradas
Enunciado del alcance del proyecto Plan de gestión del proyecto
Gestión de los riesgos herramientas y técnicas
Reuniones de planificación y análisis: En estas reuniones se definen los planes básicos para llevar a cabo las actividades de gestión de riesgos. Se desarrollarán los elementos de coste del riesgo y las actividades del cronograma para incluirlos en el presupuesto y el cronograma del proyecto, respectivamente. Se asignarán las responsabilidades respecto al riesgo. Las plantillas generales de la organización para las categorías de riesgo y las definiciones de términos como los niveles de riesgo, la probabilidad por tipo de riesgo, el impacto por tipo de objetivo, y la matriz de probabilidad e impacto se adaptarán para el proyecto específico. Las salidas de estas actividades se resumirán en el plan de gestión de riesgos.
86
Gestión de los riesgos salidas
Plan de gestión de riesgos: El plan de gestión de riesgos describe cómo se estructurará y realizará la gestión de riesgos en el proyecto. Pasa a ser un subconjunto del plan de gestión del proyecto .El plan de gestión de riesgos incluye lo siguiente:
Metodología. Define los métodos, las herramientas y las fuentes de información que pueden utilizarse para realizar la gestión de riesgos en el proyecto.
Roles y responsabilidades. Define el líder, el apoyo y los miembros del equipo de gestión de riesgos para cada tipo de actividad del plan de gestión de riesgos, asigna personas a estos roles y explica sus responsabilidades.
Categorías de riesgo. Proporciona una estructura que garantiza un proceso completo de identificación sistemática de los riesgos con un nivel de detalle uniforme, y contribuye a la efectividad y calidad de la Identificación de Riesgos. Una estructura de desglose del riesgo (RBS) es uno de los métodos para proporcionar dicha estructura, pero también se puede utilizar un listado de los diversos aspectos del proyecto.
87
Figura 10. Estructura de desglose del riesgo
Fuente: PMBOK.
8.1.6.2. Identificación de riesgos
La identificación de riesgos determina qué riesgos pueden afectar al proyecto y documenta sus características.
La identificación de riesgos es un proceso iterativo porque se pueden descubrir nuevos riesgos a medida que el proyecto avanza a lo largo de su ciclo de vida. La frecuencia de la iteración y quién participará en cada ciclo variará de un caso a otro. El proceso identificación de riesgos suele llevar al proceso análisis cualitativo de riesgos. Como alternativa, puede llevar directamente al proceso análisis cuantitativo de riesgos. En algunas ocasiones, simplemente la identificación de un riesgo puede sugerir su respuesta, y esto debe registrarse para realizar otros
88
análisis y para su implementación en el proceso planificación de la respuesta a los riesgos
Identificación de riesgos entradas
Plan de gestión de riesgos: Las entradas clave del plan de gestión de riesgos al proceso identificación de riesgos son las asignaciones de roles y responsabilidades, la contemplación de actividades de gestión de riesgos en el presupuesto y el cronograma, y las categorías de riesgo, que a veces se expresan en una RBS.
Plan de gestión del proyecto: El proceso Identificación de Riesgos también requiere la comprensión del cronograma, el coste y los planes de gestión de calidad del plan de gestión del proyecto. Las salidas de los procesos de otras áreas de conocimiento deberían ser revisadas para identificar posibles riesgos en todo el proyecto.
Identificación de riesgos herramientas y técnicas
Revisiones de documentación: Se puede realizar una revisión estructurada de la documentación del proyecto, incluidos planes, asunciones, archivos de proyectos anteriores y otra información. La calidad de los planes, así como la consistencia entre esos planes y con los requisitos y asunciones del proyecto, pueden ser indicadores de riesgos en el proyecto.
Técnicas de recopilación de información: Algunos ejemplos de técnicas de recopilación de información utilizadas para identificar los riesgos son: Tormenta de ideas: La meta de la tormenta de ideas es obtener una lista completa de los riesgos del proyecto.
Entrevistas: Entrevistar a participantes experimentados del proyecto, interesados y expertos en la materia puede servir para identificar riesgos. Las entrevistas son una de las principales fuentes de recopilación de datos para la identificación de riesgos.
89
Identificación de riesgos salidas
Por lo general, las salidas de una identificación de riesgos se encuentran en un documento que puede denominarse registro de riesgos.
Registro de riesgos: Las principales salidas de la identificación de riesgos son las entradas iníciales en el registro de riesgos, que se convierte en un componente del plan de gestión del proyecto. La preparación del registro de riesgos comienza en el proceso identificación de riesgos con la siguiente información, y luego está disponible para la gestión de otros proyectos y otros procesos de gestión de los riesgos del proyecto.
Lista de riesgos identificados: Se describen los riesgos identificados, incluidas las causas y las asunciones inciertas del proyecto.
Lista de posibles respuestas: Se pueden identificar posibles respuestas a un riesgo durante el proceso identificación de riesgos. Estas respuestas, si son identificadas, pueden ser útiles como entradas al proceso planificación de la respuesta a los riesgos.
Causas de los riesgos: Son las condiciones o eventos fundamentales que pueden dar lugar al riesgo identificado.
8.1.6.3. Análisis cualitativo de riesgos
El análisis cualitativo de riesgos incluye los métodos para priorizar los riesgos identificados para realizar otras acciones, como análisis cuantitativo de riesgos o planificación de la respuesta a los riesgos. El análisis cualitativo de riesgos evalúa la prioridad de los riesgos identificados usando la probabilidad de ocurrencia, el impacto correspondiente sobre los objetivos del proyecto si los riesgos efectivamente ocurren, así como otros factores como el plazo y la tolerancia al riesgo de las restricciones del proyecto como coste, cronograma, alcance y calidad.
90
Análisis cualitativo de riesgos entradas
Plan de gestión de riesgos: algunos elementos clave del plan de gestión de riesgos para el análisis cualitativo de riesgos incluyen los roles y responsabilidades para la gestión de riesgos, presupuestos, y actividades de gestión de riesgos del cronograma, categorías de riesgo, definición de probabilidad e impacto, la matriz de probabilidad e impacto, y las tolerancias al riesgo revisadas de los interesados. Estas entradas normalmente se adaptan al proyecto durante el proceso planificación de la gestión de riesgos. Si no están disponibles, pueden desarrollarse durante el proceso análisis cualitativo de riesgos.
Registro de riesgos: Un elemento clave del registro de riesgos para el análisis cualitativo de riesgos es la lista de riesgos identificados. Análisis cualitativo de riesgos herramientas y técnicas
Evaluación de probabilidad e impacto de los riesgos: La evaluación de probabilidad de los riesgos investiga la probabilidad de ocurrencia de cada riesgo específico. La evaluación del impacto de los riesgos investiga el posible efecto sobre un objetivo del proyecto, como tiempo, coste, alcance o calidad, incluidos tanto los efectos negativos por las amenazas que implican, como los efectos positivos por las oportunidades que generan. Evaluación de la urgencia de los riesgos: Los riesgos que requieren respuestas a corto plazo pueden ser considerados como más urgentes. Entre los indicadores de prioridad pueden incluirse el tiempo para dar una respuesta a los riesgos, los síntomas y señales de advertencia, y la calificación del riesgo.
Análisis cualitativo de riesgos salidas
Registro de riesgos (actualizaciones): el registro de riesgos se inicia durante el proceso identificación de riesgos. El registro de riesgos se actualiza con información del análisis cualitativo de riesgos y el registro de riesgos actualizado se incluye en el plan de gestión del proyecto. Las actualizaciones del registro de riesgos provenientes del análisis cualitativo de riesgos incluyen:
91
Lista de prioridades o clasificaciones relativas de los riesgos del proyecto. La matriz de probabilidad e impacto puede usarse para clasificar los riesgos según su importancia individual. La prioridad de los riesgos puede establecerse para el coste, el tiempo, el alcance y la calidad por separado, ya que es posible que las organizaciones valoren un objetivo más que otro.
Riesgos agrupados por categorías. La categorización de riesgos puede revelar causas comunes de riesgos o áreas del proyecto que requieren particular atención. Descubrir las concentraciones de riesgos puede mejorar la efectividad de las respuestas a los riesgos.
Lista de riesgos que requieren respuesta a corto plazo. Los riesgos que requieren una respuesta urgente y los que pueden ser tratados posteriormente pueden incluirse en grupos diferentes.
8.1.6.4. Análisis cuantitativo de riesgos
El análisis cuantitativo de riesgos se realiza respecto a los riesgos priorizados en el proceso análisis cualitativo de riesgos por tener un posible impacto significativo sobre las demandas concurrentes del proyecto. El proceso análisis cuantitativo de riesgos analiza el efecto de esos riesgos y les asigna una calificación numérica.
Análisis cuantitativo de riesgos entradas
Plan de gestión de riesgos: Algunos elementos clave del plan de gestión de riesgos para el análisis cuantitativo de riesgos incluyen los roles y responsabilidades para la gestión de riesgos, presupuestos, y actividades de gestión de riesgos del cronograma, categorías de riesgo, la RBS y las tolerancias al riesgo revisadas de los interesados. Registro de riesgos: Algunos elementos clave del registro de riesgos para el análisis cuantitativo de riesgos incluyen la lista de riesgos identificados, la lista de prioridades o clasificaciones relativas de los riesgos del proyecto y los riesgos agrupados por categorías.
92
Análisis cuantitativo de riesgos herramientas y técnicas
Técnicas de recopilación y representación de datos
Entrevistas. La información necesaria depende del tipo de distribuciones de probabilidad que se vayan a usar. Por ejemplo, para algunas distribuciones comúnmente usadas, la información se podría recopilar agrupándola en escenarios optimistas (bajo), pesimistas (alto) y más probables, y en media y desviación estándar para las otras distribuciones.
Juicio de expertos. Expertos en la materia internos o externos a la organización, como expertos en ingeniería o en estadística, validan los datos y las técnicas.
Análisis cuantitativo de riesgos salidas
Registro de riesgos (actualizaciones): El registro de riesgos es un componente del plan de gestión del proyecto. Las actualizaciones incluyen los siguientes componentes principales: Análisis probabilístico del proyecto. Se realizan estimaciones de los posibles resultados del cronograma y los costos del proyecto, listando las fechas de conclusión y costos posibles con sus niveles de confianza asociados.
Lista priorizada de riesgos cuantificados. Esta lista de riesgos incluye aquellos riesgos que representan la mayor amenaza o presentan la mayor oportunidad para el proyecto. Se incluyen los riesgos que requieren la mayor contingencia de costos y aquellos que tienen más probabilidad de influir sobre el camino crítico.
8.1.6.5. Planificación de la respuesta a los riesgos
La planificación de la respuesta a los riesgos es el proceso de desarrollar opciones y determinar acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. Se realiza después de los procesos análisis cualitativo de riesgos y análisis cuantitativo de riesgos.
93
Planificación de la respuesta a los riesgos entradas
Plan de gestión de riesgos: entre los componentes importantes del plan de gestión de riesgos se incluyen los roles y responsabilidades, las definiciones del análisis de riesgos, los umbrales de riesgo para los riesgos bajo, moderado y alto, y el tiempo y el presupuesto necesarios para la ejecución de las actividades. Registro de riesgos: El registro de riesgos se desarrolla por primera vez en el proceso identificación de riesgos, y se actualiza durante los procesos análisis cualitativo de riesgos y análisis cuantitativo de riesgos. Es posible que el proceso planificación de la respuesta a los riesgos tenga que remitirse a los riesgos identificados, las causas de los riesgos, las listas de posibles respuestas, los propietarios de los riesgos, los síntomas y las señales de advertencia para desarrollar las respuestas a los riesgos. Planificación de la respuesta a los riesgos herramientas y técnicas
Hay disponibles varias estrategias de respuesta a los riesgos. Para cada riesgo, se debe seleccionar la estrategia o la combinación de estrategias con mayor probabilidad de ser efectiva.
Estrategias para riesgos negativos o amenazas: Existen tres estrategias que normalmente se ocupan de las amenazas o los riesgos que pueden tener impactos negativos sobre los objetivos del proyecto en caso de ocurrir. Estas estrategias son evitar, transferir o mitigar:
Evitar. Evitar el riesgo implica cambiar el plan de gestión del proyecto para eliminar la amenaza que representa un riesgo adverso, aislar los objetivos del proyecto del impacto del riesgo o relajar el objetivo que está en peligro, por ejemplo, ampliando el cronograma o reduciendo el alcance. Algunos riesgos que surgen en las etapas tempranas del proyecto pueden ser evitados aclarando los requisitos, obteniendo información, mejorando la comunicación o adquiriendo experiencia.
Mitigar. Mitigar el riesgo implica reducir la probabilidad y / o el impacto de un evento de riesgo adverso a un umbral aceptable. Adoptar acciones tempranas para reducir la probabilidad de la ocurrencia de un riesgo y / o su impacto sobre
94
el proyecto a menudo es más efectivo que tratar de reparar el daño después de que ha ocurrido el riesgo.
Planificación de la respuesta a los riesgos salidas
Registro de riesgos (actualizaciones): El registro de riesgos se desarrolla en la identificación de riesgos, y se actualiza durante el análisis cualitativo de riesgos y el análisis cuantitativo de riesgos. En el proceso planificación de la respuesta a los riesgos, se eligen y acuerdan las respuestas apropiadas, y se incluyen en el registro de riesgos. El registro de riesgos debe ser escrito con un nivel de detalle que se corresponda con la clasificación de prioridades y la respuesta planificada. A menudo, los riesgos altos y moderados se tratan en detalle. Plan de gestión del proyecto (Actualizaciones): El plan de gestión del proyecto se actualiza a medida que se añaden actividades de respuesta después de la revisión y disposición a través del proceso control integrado de cambios.
8.1.6.6. Seguimiento y control de riesgos
El seguimiento y control de riesgos es el proceso de identificar, analizar y planificar nuevos riesgos, realizar el seguimiento de los riesgos identificados y los que se encuentran en la lista de supervisión. El proceso seguimiento y control de riesgos aplica técnicas, como el análisis de variación y de tendencias, que requieren el uso de datos de rendimiento generados durante la ejecución del proyecto. El proceso seguimiento y control de riesgos, así como los demás procesos de gestión de riesgos, es un proceso continuo que se realiza durante la vida del proyecto.
Seguimiento y control de riesgos entradas
Plan de gestión de riesgos: Este plan tiene entradas clave que incluyen la asignación de personas, incluidos los propietarios de los riesgos, de tiempo y otros recursos para la gestión de los riesgos del proyecto.
Registro de riesgos: El registro de riesgos tiene entradas clave que incluyen los riesgos identificados y los propietarios de los riesgos, las respuestas a los
95
riesgos acordados, las acciones de implementación específicas, los síntomas y las señales de advertencia de riesgos, los riesgos residuales y secundarios. Solicitudes de cambio aprobadas: Las solicitudes de cambio aprobadas pueden incluir modificaciones, por ejemplo, a los métodos de trabajo, los términos del contrato, el alcance y el cronograma. Los cambios aprobados pueden generar riesgos o cambios en los riesgos identificados, y esos cambios deben ser analizados para detectar los efectos que pueden tener sobre el registro de riesgos, el plan de respuesta a los riesgos o el plan de gestión de riesgos. Todos los cambios deberían documentarse formalmente. Todo cambio discutido oralmente, pero no documentado, no debería procesarse o implementarse.
Información sobre el rendimiento del trabajo: La información sobre el rendimiento del trabajo, incluidos el estado de los productos entregables del proyecto, las acciones correctivas y los informes de rendimiento, son entradas importantes al seguimiento y control de riesgos. Seguimiento y control de riesgos herramientas y técnicas
Reevaluación de los riesgos: El proceso seguimiento y control de riesgos a menudo requiere la identificación de nuevos riesgos y la reevaluación de los riesgos, mediante la utilización de los procesos descritos en este capítulo según corresponda. Las reevaluaciones de los riesgos del proyecto deben ser programadas con regularidad. La gestión de los riesgos del proyecto debe ser un punto del orden del día en las reuniones sobre el estado del equipo del proyecto. Seguimiento y control de riesgos salidas
Registro de riesgos (Actualizaciones): Un registro de riesgos actualizado contiene: Resultados de las reevaluaciones, auditorías y revisiones periódicas de los riesgos. Estos resultados pueden incluir actualizaciones de la probabilidad, impacto, prioridad, planes de respuesta, propiedad y otros elementos del registro de riesgos. Los resultados también pueden incluir cerrar los riesgos que ya no sean aplicables.
96
Los resultados reales de los riesgos del proyecto, y de las respuestas a los riesgos que pueden ayudar a los directores de proyecto en la planificación de riesgos para toda la organización, así como en proyectos futuros.
Acciones correctivas recomendadas: Las acciones correctivas recomendadas incluyen los planes para contingencias y los planes de soluciones alternativas. Las soluciones alternativas deben estar correctamente documentadas.
Acciones preventivas recomendadas: Las acciones preventivas recomendadas se usan para hacer que el proyecto cumpla con el plan de gestión del proyecto.
97
ENFOQUE SOFTWARE
8.1.7 Gestión de la documentación16
Esta área de gestión describe el almacenamiento y el uso compartido tanto de documentos electrónicos como de aquellos impresos. Cuanto más grande sea un proyecto, más difícil se torna compartir información de manera fluida con todos los miembros del equipo y los grupos de interés. Esto es particularmente cierto cuando son varias las personas que trabajan en los entregables. Si el Jefe de Proyecto no piensa preactivamente los procesos de gestión de la documentación el proyecto tendrá grandes dificultades para localizar información relevante y será frustrante tener que lidiar con formatos de entregables inconsistentes; es probable que todo esto derive en confusiones y se deba volver a realizar trabajos que ya se consideraban finalizados.
Cuanto mayor sea el proyecto, más disciplina y estructura serán necesarias para gestionar la documentación del proyecto. Se puede terminar con un gran desastre tratando de guardar y encontrar documentos si no se diseña por adelantado el plan de gestión de la documentación. Se aconseja considerar los siguientes elementos, sin importar la secuencia :
Plan de Gestión de la documentación contiene toda la información generada en las herramientas y técnicas descritas en la sección anterior en un solo documento, el cual sirve como guía para el tratamiento de la documentación generada en cada uno de los procesos de toda la propuesta.
16
Gestión de la documentación, Guía TENSTEP. Adaptada y traducida por: SANTACRUZ, Juan, y RIOS, Andrés.
98
8.1.7.1. Determinar el repositorio de documentos
Esto puede ser un área o directorio común para los miembros del equipo de trabajo, una aplicación para la administración de documentos, un archivo de documentos físicos, etc. El jefe de proyecto debe estar atento de no almacenar documentos en lugares dispersos debido a las preferencias de los miembros del equipo. Si eso sucede, el equipo tendrá dificultades para encontrar documentos importantes cuando sean necesarios especialmente si hay rotación entre los miembros del equipo.
8.1.7.2. Determinar los tipos de documentos que van a ser incluidos en el plan de gestión de documentos
Los miembros del equipo necesitan determinar qué tipo de documentos serán agregados al repositorio de documentos. Es posible que el repositorio pueda guardar un mismo documento registrando las diversas fases de su ciclo de vida, incluyendo borradores y trabajos preliminares provenientes del área de trabajo individual. Sin embargo, también es común que cada persona en el equipo tenga un área para sus propios documentos y que en el repositorio del proyecto sólo se mantengan versiones finales de los documentos ya aprobados.
8.1.7.3. Definir una estructura física y lógica para almacenar documentos
Una vez que se sabe donde serán almacenados los documentos, se deberá determinar la estructura del repositorio. Esto dirá a los miembros del equipo donde guardar los documentos y ayudará a que éstos sean encontrados rápidamente cuando sean necesarios. El primer paso es definir una estructura lógica de la forma en que deben ser guardados los documentos. Se puede, por ejemplo diseñar la estructura y circular el diseño al equipo para obtener su opinión. Una vez consensuada la estructura, será necesario realizar el resultado utilizando las herramientas correspondientes. La estructura resultante debe ser fácil de entender y fácil de usar cuando se necesita información relevante.
99
Ejemplo
Información Necesaria
Entregable: Formato en envío de documentos
Esta forma es utilizada para enviar documentos al repertorio. Si la biblioteca
puede ser utilizada por cada miembro del equipo, esta forma no tendrá sentido.
Sin embargo, esta será requerida si un bibliotecario controla el acceso al
repertorio.
Título del documento: ¿Cuál es el nombre del documento?
Resumen del documento: Una breve descripción del documento. Utilizada
para la gente que hace búsquedas, con el fin de que pueda determinar si el
documento es relevante o no.
Autor: ¿Quién escribió el documento?
Fecha de aprobación: La fecha en que el documento fue aprobado (sí es
aplicable)
Palabras Clave: ¿Qué palabras o frases podrían ser buscadas por una persona
para encontrar este documento? En muchos casos, la lista de palabras podría
ser estandarizada.
Documento: El documento en sí mismo deberá se anexado o acompañar al
formato.
Entregables de Proyecto: Directorio para almacenar todos los productos
relacionados con el proyecto. Este es segmentado en varias carpetas de modo
que sirva de guía para almacenar documentos específicos.
Entregables de Gestión del Proyecto: Directorio para almacenar todos los
documentos de gestión del proyecto. Este es segmentado en varias carpetas de
100
modo que sirva de guía para almacenar documentos específicos.
Referencia: Directorio para cualquier documento que agregue valor y que sea
usado como entrada para el proyecto, como la definición de la arquitectura,
organización del cliente, material de entrenamiento, gráficas, etc. (Los
entregables creados por le proyecto no se colocan en este directorio).
Área de trabajo: (opcional) Directorio para cada miembro del equipo que use o
genere productos de trabajo
Estructura de directorios para el proyecto X
Figura 11. Estructura de directorios para el proyecto X
Fuente: Elaboración propia
101
8.1.7.4. Definir estándares de denominación
Un estándar común para la denominación de archivos hará más fácil la búsqueda de archivos. Un ejemplo puede ser los informes del estado del avance del proyecto. Una convención podría ser “20071201 informe del estado del avance de Juan Pérez”. En este esquema, todos los informes del estado del avance para un periodo determinado se ordenarán en orden cronológico. Por el contrario, “Juan Pérez 20071201 informe del estado del avance” agrupará los informes por persona. El jefe de proyecto debe asegurarse que todos en el equipo están usando el mismo esquema de denominación. Tener un estándar común para la denominación de documentos relacionados será muy valioso en la medida en que el equipo de trabajo genere docenas y quizás cientos de documentos conforme el proyecto avanza.
8.1.7.5. Determinar si algunos documentos necesitan manejarse con versiones
El jefe de proyecto determina si han de guardarse diversas versiones o sólo la última versión de los documentos del proyecto. Algunos documentos como la definición del proyecto deberían constar en sus diversas versiones aprobadas. Para este tipo de documentos la nomenclatura deberá contar con un código de versión. Por ejemplo la primera versión puede llamarse "ABC definición de proyecto v1". Una versión posterior se llamaría "ABC definición de proyecto v2". Los interesados podrán así consultar una versión anterior si es necesario. Otros documentos como por ejemplo el registro de incidencias sólo tienen una versión y los registros históricos son guardados allí. La versión actual del registro de incidencias siempre reemplaza a la versión anterior y no hay motivos para guardar diversas versiones. 8.1.7.6. Determinar si se registrará (y como) la situación en el ciclo de vida de documentos
Cuando los documentos necesitan ser aprobados y particularmente si el proceso de aprobación es extenso, es muy importante señalar el estado de aprobación del documento. Por ejemplo: Es trascendental saber si el documento que se está revisando es una versión aprobada o es un borrador. El contar con directorios
102
separados para almacenar los documentos en sus diferentes etapas de aprobación ayudará a saberlo. Los indicadores típicos para el ciclo de vida de la documentación son: “borrador” “trabajo en progreso” y “final”. Cuando el documento es creado está en calidad de “borrador”, cuando es circulado para su aprobación, entonces se considera “trabajo en progreso”. Una vez aprobado, el documento se mueve a la carpeta “final”.
8.1.7.7. Definir formatos estándares de documentos
En el transcurso del tiempo es más fácil leer y crear documentos si estos siguen un formato estándar que defina por ejemplo el tipo y tamaño de letra que será usado. Además, se pueden definir encabezados, pies de página, carátulas y tablas de índices. Esto dará a toda la documentación una imagen similar.
8.1.7.8. Utilizar herramientas estándares para documentar
El equipo necesita contar con un conjunto común y estándar para editar documentos. Normalmente esto no es un problema si el equipo de trabajo proviene de la misma área. Sin embargo, la falta de herramientas comunes puede ser un verdadero problema si el equipo está integrado con personas de diferentes organizaciones, o incluso países o diferentes empresas. Por ejemplo, algo tan simple como un procesador de textos estándar por lo general no es problema. Sin embargo sí hay proveedores en el equipo, puede resultar que algunos estén usando Microsoft – Word y otros estén usando WordPad. De la misma forma, todos los miembros del equipo deberían utilizar el mismo tipo de herramientas para procesar hojas de cálculo. Además de la herramienta en sí, es necesario contar la misma versión de la misma.
103
8.1.8. Gestión de la configuración17
La gestión de configuraciones del software (GCS) es un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida. La GCS es una actividad de garantía de calidad de software que se aplica en todas las fases del proceso de ingeniería del software. La GCS da respuesta a las siguientes cuestiones:
¿Cómo identifica y gestiona una organización las muchas versiones existentes de un programa de forma que se puedan introducir cambios eficientemente?
¿Cómo controla la organización los cambios antes y después de que el software sea distribuido al cliente?
¿Cómo podemos asegurar que los cambios se han llevado a cabo adecuadamente?
Plan de la configuración Se describen las actividades de gestión de configuración de software que deben ser llevadas a cabo durante el proceso de desarrollo del proyecto. Se definen tanto los productos que se pondrán bajo control de configuración como los procedimientos que deben ser seguidos por los integrantes del equipo de trabajo.
17
PRESSMAN. Roger. Ingeniería del Software: un enfoque práctico; McGraw Hill. Madrid, 1993. 3ª
Edición. Adaptada por: SANTACRUZ, Juan, y RIOS, Andrés.
104
8.1.8.1. Identificación de la configuración
La tarea de identificación de la gestión de configuraciones software tiene tres objetivos:
1. Definir una estructura de documentación organizada de un modo inteligible y predecible. (Es decir, dar un formato)
2. Proporcionar métodos para revisiones y añadir los cambios conforme se producen (Identificar cada documento para la revisión y los cambios).
3. Relacionar los cambios con “quién, qué, cuándo, porqué, cómo” para facilitar el control. El proceso de identificación de la configuración es el siguiente:
Definición de los elementos de la configuración software, el formato, los contenidos y los mecanismos de control para toda la documentación se plasman los identificadores apropiados a todos los programas, documentos y periféricos, usando un esquema numerado que proporciona información sobre el elemento de la configuración software.
A continuación se describe una guía para un sistema de numeración de documentos:
1) Un identificador único de proyecto 2) Un identificador del elemento de la configuración 3) Un número del nivel de revisión 4) Un código del atributo.
Nº de referencia del documento: XXX-YYY-Z-RL-NNN Donde: XXX-YYY es un identificador común para cada proyecto XXX es el identificador de la empresa de software YYY es el identificador del proyecto
105
Z es un identificador del elemento P Plan R Especificación de Requisitos D Documento de diseño S Listado fuente T Documentación de prueba U Manual del usuario I Guía de instalación M Manual de mantenimiento RL es el nivel de revisión NNN es un código de atributo (por ejemplo, la fecha) definido por el desarrollador del software para reflejar cierta información importante del elemento de la configuración.
EJEMPLO:
SPC-001-P-0-3/80 Este es el plan del proyecto 1 de la empresa "IDra". Es el documento original. Puesto bajo control de cambios en Marzo de 1980. SPC-001-P-1-5/80 Esta es la revisión 1 al plan. Puesta bajo control de cambios en Mayo de 1980. SPC-005-R-3-9/81 Esta es la revisión 3 de la especificación de requerimientos para el proyecto número 5 de SPCC. Puesto bajo control de cambios en Septiembre de 1981.
8.1.8.2. Control de cambios
El control de cambios es un mecanismo para la evaluación y aprobación de los cambios hechos a elementos de la configuración software durante el ciclo de vida.
Pueden establecerse tres distintos tipos de control: 1) Control individual, antes de aprobarse un nuevo elemento. 2) Control de Gestión (u organizado), conduce a la aprobación de un nuevo elemento. 3) Control formal, se realiza durante el mantenimiento.
106
1. Control individual (o informal). Cuando un elemento de la configuración está bajo control individual, el técnico responsable cambia la documentación como se requiere. Aunque se mantiene un registro informal de revisiones, tales registros no se ponen generalmente en el documento. El control individual se aplica durante las etapas más importantes del desarrollo del documento y se caracteriza por los cambios frecuentes.
2. Control de gestión. Implica un procedimiento de revisión y aprobación para cada cambio propuesto en la configuración. Como en el control individual, el control a nivel de proyecto ocurre durante el proceso de desarrollo pero es usado después de que haya sido aprobado un elemento de la configuración software. Este nivel de control de cambios se caracteriza por tener menos cambios que el control individual. Cada cambio es registrado formalmente y es visible para la gestión.
3. Control de cambios formal. Ocurre durante la fase de mantenimiento del ciclo de vida software (el producto ya está implantado). A menudo se ordena que se establezcan mecanismos de arreglo rápido (quick-fix). El procedimiento de cambios quick-fix no debe usarse para involucrar otros niveles de control de cambios, pero sí para proporcionar significados temporales para modificación rápida de la configuración software en situaciones de emergencia.
8.1.8.3. Generación de informes
La generación de informes de estado de la configuración (GIEC) responde a las preguntas: ¿Qué pasó? ¿Quién lo hizo? ¿Cuándo pasó? ¿Qué más se vio afectado? Debe construirse un documento donde se especifique el cambio realizado, quien se encargo, fecha de lo sucedido y que otros aspectos afectó el cambio realizado.
107
8.1.9. Gestión de la calidad18
La gestión de la calidad de software (ISO 9000) es un conjunto de actividades de la función general de la Dirección que determina la calidad, los objetivos y las responsabilidades. El propósito de la gestión de la calidad del software es entender las expectativas del cliente en términos de calidad, y poner en práctica un plan para satisfacer esas expectativas.
18
Calidad del software, SWEBOK. Edición 2004. Adaptada y traducida por: SANTACRUZ, Juan, y RIOS, Andrés.
108
8.1.9.1. Planificación de la calidad del software
El objetivo es modelar y remodelar los negocios y productos de la empresa, de manera que se combinen para producir un desarrollo y utilidades satisfactorias. Los aspectos a considerar en la Planificación de la CS son: Modelos/Estándares de CS a utilizar, Costos de la CS, recursos humanos y materiales necesarios, etc. El plan de calidad define los atributos de calidad más importantes del producto a ser desarrollado y define el proceso de evaluación de la calidad. En la Planificación de la CS se debe determinar: (1) Preparación de un Plan de CS (2) Implementación de un Plan de CS (3) Preparar un Manual de Calidad.
8.1.9.2. Control de la calidad del software
Son las técnicas y actividades de carácter operativo, utilizadas para satisfacer los requisitos relativos a la calidad. Está formado por actividades que permiten evaluar la calidad de los productos de software desarrollados. El aspecto a considerar en el Control de la CS es la “prueba del software”. La prueba es el proceso de ejecutar un programa con intención de encontrar defectos. Es un proceso destructivo que determina el diseño de los casos de prueba y la asignación de responsabilidades. La prueba exitosa es aquella que descubre defectos. El “caso de prueba bueno” es aquel que tiene alta probabilidad de detectar un defecto aún no descubierto. El “caso de prueba exitoso” es aquel que detecta un defecto aún no descubierto. La prueba demuestra hasta qué punto las funciones del software parecen funcionar de acuerdo con las especificaciones y parecen alcanzarse los requisitos de rendimiento. Además, los datos que se van recogiendo a medida que se lleva a cabo la prueba proporcionan una buena indicación de la confiabilidad del software e indican la calidad del software como un todo. Pero, la prueba no puede asegurar
109
la ausencia de defectos; sólo puede demostrar que existen defectos en el software. Una estrategia Tradicional de prueba del software debe incluir pruebas de bajo nivel que verifiquen que todos los pequeños segmentos de código fuente se han implementado correctamente, así como pruebas de alto nivel que validen las principales funciones del sistema frente a los requisitos del cliente.
8.1.9.3. Pruebas de bajo nivel
Pruebas Unitarias (por modulo) La prueba de unidad hace un uso intensivo de las técnicas de prueba de caja blanca, ejercitando caminos específicos de la estructura de control del módulo para asegurar un alcance completo y una detección máxima de errores. La prueba de unidad centra el proceso de verificación en la menor unidad del diseño del software: el componente de software o módulo. Se prueba la interfaz del módulo para asegurar que la información fluye de forma adecuada hacia y desde la unidad de programa que está siendo probada. Se examinan las estructuras de datos locales para asegurar que los datos que se mantienen temporalmente conservan su integridad durante todos los pasos de ejecución del algoritmo. Se prueban las condiciones límite para asegurar que el módulo funciona correctamente en los límites establecidos. Se ejercitan todos los caminos independientes de la estructura de control con el fin de asegurar que todas las sentencias del módulo se ejecutan por lo menos una vez. Y, finalmente, se prueban todos los caminos de manejo de errores. Antes de iniciar cualquier otra prueba es preciso probar el flujo de datos de la interfaz del módulo. Si los datos no entran correctamente, todas las demás pruebas no tienen sentido. Prueba de Integración A continuación, se deben ensamblar o integrar los módulos para formar el paquete de software completo. La prueba de integración es una técnica sistemática que permite construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción. El objetivo es juntar los módulos probados mediante la prueba de unidad y construir
110
una estructura de programa que esté de acuerdo con lo que dicta el diseño. Se combinan todos los módulos por anticipado. Se prueba todo el programa en conjunto. Se encuentra un gran conjunto de errores. Una vez que se corrigen esos errores aparecen otros nuevos y el proceso continúa en lo que parece ser un ciclo sin fin.
8.1.9.5. Pruebas de alto nivel
Prueba de validación
Después que el software se ha integrado, se deben comprobar los criterios de validación establecidos durante el análisis de requisitos. La prueba de validación proporciona una seguridad final que el software satisface todos los requisitos funcionales, de comportamiento y de rendimiento. Durante la validación se usan exclusivamente técnicas de prueba de caja negra.
Prueba de sistema
El software, una vez validado, se debe combinar con otros elementos del sistema. La prueba del sistema verifica que cada elemento se ajusta de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total. La prueba del sistema está constituida por una serie de pruebas diferentes cuyo propósito primordial es ejercitar profundamente el sistema basado en computadora. Aunque cada prueba tiene un propósito diferente, todas trabajan para verificar que se ha integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.
Prueba de regresión
La prueba de regresión es volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse que los cambios no han propagado efectos colaterales no deseados. Este tipo de prueba es la actividad que ayuda a asegurar que los cambios no introduzcan un comportamiento no deseado o errores adicionales. A medida que progresa la prueba de regresión, el número de pruebas de regresión puede crecer demasiado. Por lo tanto, el conjunto de pruebas de regresión debería diseñarse para incluir sólo aquellas pruebas que traten una o más clases de errores en cada una de las funciones
111
principales del programa. No es práctico ni eficiente volver a ejecutar cada prueba de cada función del problema después de un cambio.
Prueba de aceptación
Cuando se construye un software a medida para un cliente, se llevan a cabo una serie de pruebas de aceptación para permitir que el cliente valide todos los requisitos. Estas pruebas las realiza el usuario final en lugar del responsable del desarrollo de sistema. Una prueba de aceptación puede ir desde un informal paso de prueba hasta la ejecución sistemática de una serie de pruebas bien planificadas.
El diseño de casos de prueba para el software o para otros productos de ingeniería puede requerir tanto esfuerzo como el propio diseño inicial del producto. Se deben diseñar pruebas que tengan la mayor probabilidad de encontrar el mayor número de errores con la mínima cantidad de esfuerzo y tiempo posible. Cualquier producto de ingeniería puede probarse de una de estas 2 formas:
Técnicas de prueba de caja negra
Cuando se considera el software de computadora, la prueba de caja negra se refiere a las pruebas que se llevan a cabo sobre la interfaz del software. Los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce un resultado correcto, así como que la integridad de la información externa se mantiene.
Técnicas de prueba de caja blanca
La prueba de caja blanca del software se basa en el minucioso examen de los detalles procedimentales. Se comprueban los caminos lógicos del software proponiendo casos de prueba que ejerciten conjuntos específicos de condiciones y/o bucles. Para este tipo de prueba, se deben definir todos los caminos lógicos y desarrollar casos de prueba que ejerciten la lógica del programa.
112
8.1.9.6. Aseguramiento de calidad del software
Es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza que el software satisfará los requisitos dados de calidad. Este aseguramiento se diseña para cada aplicación antes de comenzar a desarrollarla y no después; tiene asociado 2 constitutivos diferentes: los Ingenieros de Software que realizan el trabajo técnico y un grupo de SQA (Software Quality Assurance) que tiene la responsabilidad de la planificación de aseguramiento de la calidad, supervisión, mantenimiento de registros, análisis e informes. Las Actividades del grupo de SQA son: (1) Revisión de las actividades de ingeniería del software para verificar su ajuste al proceso de software definido (2) Registrar lo que no se ajuste a los requisitos e informar a sus superiores.
Además de estas actividades, el grupo de SQA coordina el control y la gestión de cambios y; ayuda a recopilar y analizar las métricas del software. Las métricas son escalas de unidades sobre las cuales puede medirse un atributo cuantificable. Los atributos son características observables del producto o del proceso de software, que proporciona alguna información útil sobre el estado del producto o sobre el progreso del proyecto. Los valores de las métricas no se obtienen sólo por mediciones. Algunos valores de métricas se derivan de los requisitos del cliente o de los usuarios y, por lo tanto, actúan como restricciones dentro del proyecto. Sin mediciones es imposible perseguir objetivos comerciales normales de una manera racional.
113
8.2. Análisis de resultados
Tomando como punto de partida las dos pruebas realizadas del documento guía de gestión de proyectos software, en dos proyectos de la UCPR: “CAPSOFT” y “SISTEMA DE GESTIÓN DOCUMENTAL PARA EL DEPARTAMENTO DE PRÁCTICAS PROFESIONALES DE LA UNIVERSIDAD CATÓLICA POPULAR DEL RISARALDA, se hizo necesario contrastar estos resultados mediante una encuesta, en la cual se pretendiera conocer la manera en que actualmente se estaban llevando la gestión de proyectos software en la facultad. De esta manera confrontar los resultados arrojados de la encuesta con la experiencia obtenida de la práctica realizada. Instrumento de recolección de datos Encuesta El siguiente formato de encuesta, está basado en 17 preguntas cerradas y 1 abierta. El contenido de las preguntas tiene como objetivo conocer si las personas que han o están involucradas en proyectos tipo software toman los aspectos más sobresalientes y básicos que se deben tener en cuenta en la gestión de proyectos software.
UCPR - Gestión de Proyectos de Software
Salir de esta encuesta
1. Sobre la gestión de proyectos de software
Si Ud. ha estado involucrad@ en la gestión de proyectos de software, desde el grupo
TICs de la Universidad Católica Popular del Risaralda agradecemos su colaboración
respondiendo las siguientes preguntas:
1. Información personal:
Información personal: Nombres
Nombre del proyecto en el que ha
participado
114
2. ¿Qué es para usted la gestión de proyectos software? (No intente consultar un manual o un sitio web, solo lo que se le venga a la cabeza)
3. ¿Utiliza alguna metodología, guía o modelo propio o de un tercero que sea reconocido?
4. ¿Conoce guías, metodologías o modelos para llevar a cabo la gestión de un proyecto de software?
5. ¿Considera que los procesos de gestión del software que realizó en su proyecto son suficientes para llegar al software de calidad?
6. ¿Utilizó algún método o estrategia para tener un control del tiempo en las actividades en su proyecto?
7. ¿El equipo de trabajo conocía desde un principio las labores de cada uno en el desarrollo del proyecto?
8. ¿Se definió el alcance que iba a existir en el desarrollo del proyecto?
9. ¿Tenían estipulados puntos de control en los cuales se hicieran entregas sobre los avances generados a lo largo del proyecto?
10. ¿Conocía los recursos (personas, materiales) y cuáles eran los costos de cada uno para la ejecución del proyecto?
11. ¿Conocía cuánto tiempo seria el desarrollo o ejecución de cualquier actividad a lo largo del proyecto?
12. ¿Tiene conocimiento sobre el costo promedio que tendría el proyecto al ser finalizado y tuvo en cuenta presupuestos de reserva?
13. ¿Cada integrante del equipo de trabajo tenía un cargo y unas tareas definidas que realizaría de acuerdo a sus competencias
14. ¿Había un horario de trabajo definido para cada miembro del equipo de trabajo?
15. ¿Existe un plan de contingencia ante posibles riesgos o incumplimientos que se podrían haber presentado en el transcurso del proyecto?
16. ¿El proyecto cuenta con informes de control en el cual se documenten los cambios presentados en el transcurso del mismo?
17. ¿Cuenta con un informe detallado sobre la gestión de la calidad del
115
software en el cual se documente estándares a emplear en el proyecto?
18. ¿Cuenta con un plan de pruebas para aplicar y comprobar la funcionalidad y el cumplimiento de las expectativas del proyecto?
8.2.1. Resultados
El análisis y los resultados de las encuestas fueron obtenidos con 8 personas que dieron respuesta a esta, todos ellos involucrados en proyectos software. Lo que se pudo obtener fue los siguientes resultados:
Figura 12. Resultados de la encuesta - Pregunta 3 Figura 13. Resultados de la encuesta - Pregunta 4
75%
25%
3. ¿Utiliza alguna metodología, guía o modelo propio o de un tercero que sea reconocido?
Si
No 75%
25%
4. ¿Conoce guías, metodologías o modelos para llevar a cabo la gestión de un proyecto de software?
Si
No
116
Figura 14. Resultados de la encuesta - Pregunta 5 Figura 15. Resultados de la encuesta - Pregunta 6
Figura 16. Resultados de la encuesta - Pregunta 7 Figura 17. Resultados de la encuesta - Pregunta 8
38%
63%
5. ¿Considera que los procesos de gestión del software que realizó en su proyecto son suficientes para llegar al software de calidad?
Si
No
50%50%
6. ¿Utilizó algún método o estrategia para tener un control del tiempo en las actividades en su proyecto?
Si
No
88%
13%
7. ¿El equipo de trabajo conocía desde un principio las labores de cada uno en el desarrollo del proyecto?
Si
No
88%
13%
8. ¿Se definió el alcance que iba a existir en el desarrollo del proyecto?
Si
No
117
Figura 18. Resultados de la encuesta - Pregunta 9 Figura 19. Resultados de la encuesta - Pregunta 10
Figura 20. Resultados de la encuesta - Pregunta 11 Figura 21. Resultados de la encuesta - Pregunta 12
78%
22%
9. ¿Tenían estipulados puntos de control en los cuales se hicieran entregas sobre los avances generados a lo largo del proyecto?
Si
No
50%50%
10. ¿Conocía los recursos (personas, materiales) y cuáles eran los costos de cada uno para la ejecución del proyecto?
Si
No
25%
75%
11. ¿Conocía cuánto tiempo seria el desarrollo o ejecución de cualquier actividad a lo largo del proyecto?
Si
No
13%
88%
12. ¿Tiene conocimiento sobre el costo promedio que tendría el proyecto al ser finalizado y tuvo en cuenta presupuestos de reserva?
Si
No
118
Figura 22. Resultados de la encuesta - Pregunta 13 Figura 23. Resultados de la encuesta - Pregunta 14
Figura 24. Resultados de la encuesta - Pregunta 16 Figura 25. Resultados de la encuesta - Pregunta 17
87%
13%
14. ¿Cada integrante del equipo de trabajo tenía un cargo y unas tareas definidas que realizaría de acuerdo a sus competencias?
Si
No
13%
88%
15. ¿Había un horario de trabajo definido para cada miembro del equipo de trabajo?
Si
No
13%
87%
16. ¿Existe un plan de contingencia ante posibles riesgos o incumplimientos que se podrían haber presentado en el transcurso del proyecto?
Si
No
50%50%
17. ¿El proyecto cuenta con informes de control en el cual se documenten los cambios presentados en el transcurso del mismo?
Si
No
119
Figura 26. Resultados de la encuesta - Pregunta 18 Figura 27. Resultados de la encuesta - Pregunta 19
8.2.2. Conclusiones - Análisis
La información recolectada de las encuestas revela el panorama actual de la gestión de proyectos software y el conocimiento de la personas acerca de la forma de planear ejecutar y monitorear los diferentes aspectos de la gestión de proyectos. Con los datos obtenidos puede llegarse a diferentes conclusiones:
1. Existe una confusión entre modelos o guías de gestión de proyectos software y guías de ingeniería de software.
Aclaración: Las guías de Ingeniería de software están generalmente enfocadas en ofrecer métodos y técnicas para desarrollar y mantener software, mientras que la gestión de proyectos se retroalimenta de la ingeniería del software para permitir controlar aspectos externos a este: como controlar los recursos del proyecto, cumplimiento de tiempos de cronograma, asignación de recursos humanos, definición de alcances y responsables, monitoreo y respuesta ante cambios imprevistos, etc.
38%
63%
18. ¿Cuenta con un informe detallado sobre la gestión de la calidad del software en el cual se documente estándares a emplear en el proyecto?
Si
No
38%
63%
19. ¿Cuenta con un plan de pruebas para aplicar y comprobar la funcionalidad y el cumplimiento de las expectativas del proyecto?
Si
No
120
2. Un alto porcentaje de los encuestados afirma que no existe una documentación de las actividades realizadas en el proyecto como cambios imprevistos, pruebas de software etc.
Aclaración: La documentación es un aspecto importante durante todo el tiempo de planeación ejecución y monitoreo de un proyecto, ya que dentro de este se encuentra todo el historial de vida del proyecto. Cuando se remite a la documentación se pueden encontrar fallas, inconsistencias, cambios y la creación de lecciones aprendidas que evita cometer los mismos errores en un proyecto con similares características.
3. Carecen los planes de contingencia ante cambios o riesgos, colchones en presupuesto y cronogramas de actividades.
Aclaraciones: Los planes de contingencia permiten tener un método de acción ante posibles cambios o riesgos previamente identificados, con esto se evita nuevos cambios y retraso del cronograma planteado del proyecto, de la misma manera no contar con un cronograma de actividades y un estimado de presupuesto, ocasiona que el proyecto no lleve un control del tiempo estimado de las actividades, lo cual producirá retrasos que a su vez repercutirán en el presupuesto estimado.
4. Evidentemente los métodos actuales de gestión de proyectos utilizados por los encuestados carecen de una estructura de planeación y control previa, todavía se presentan procesos intuitivos y otros que son pasados por alto y que pueden afectar al proyecto de forma positiva y negativa. Debe recordarse que la ingeniería de software es un proceso que ayuda a llegar al software de calidad, pero existen factores adicionales que estas metodologías no toman y deben ser tratados con otras que apoyen este proceso, que de la misma forma apuntan al objetivo de alcanzar proyectos software de calidad.
121
9. CONCLUSIONES
En la exploración realizada a los involucrados en los proyectos evaluados, no se evidencia una guía que permita a los fabricantes de software aplicar una gestión del proyecto de manera estándar debido a la escases del conocimiento en la temática.
La investigación da a conocer que las empresas que implementan metodologías reconocidas en gestión de proyectos son más exitosas que aquellas que no lo hacen, catalogando estas últimas como empresas caóticas, cuyos procesos y proyectos no tiene un orden definido que les proporcione un grado de seguridad para alcanzar el éxito y la culminación de sus objetivos.
El seguimiento de las diferentes actividades de la ingeniería de software si bien, es un proceso que ayuda a disminuir la incertidumbre de llevar al software de calidad, no obstante es importante e indispensable tener en cuenta diferentes actividades que rodean un proyecto y que generalmente no son analizadas ni controladas en las organizaciones.
Seguir una metodología y buenas prácticas en gestión de proyectos no garantiza que el proyecto sea exitoso o no; como tal, permite tener un control sobre el proyecto, evitando que este sea un fracaso, de la misma forma permite al director del proyecto crear lecciones aprendidas y recomendaciones para un futuro proyecto con similares características para contar con datos históricos que le proporcionen las bases y fundamentos en el futuro y de esta manera evitar incurrir en errores del pasado
La gestión de proyectos implica que cada proyecto sea único, no existe una metodología que deba seguirse estrictamente y tampoco nadie quien la califique, es entonces responsabilidad del director de proyectos establecer las actividades a realizar en el proyecto según sea su criterio y su método de trabajo.
122
A manera de hipótesis, se considera que uno de los factores que ha llevado a contar con software (en proceso y producto) de mala calidad, es la carencia en la gestión de proyectos, pues en la actualidad, pocas prácticas dan cuenta de la medición, gerencia, administración y control de todas las actividades que encierra la construcción de software. Esto ha llevado a contar con productos de funcionalidad baja, altos costos y tiempos de desarrollo exageradamente diferentes a los presupuestados.
123
10. BIBLIOGRAFÍA
BAUER, F. L. (1972). Software Engineering, An Advanced Course, Reprint of the
First Edition.
BOHEM, B. W. (1976). Software Engineering.
BSI. (s.f.). British Standards Institution. Recuperado el 20 de Febrero de 2010, de
British Standards Institution: http://www.bsigroup.com/en/
CEPAL. (2009). Desafíos y oportunidades de la industria del software en América
Latina. (P. Bastos Tigre, & F. Silveira Marquez.) Colombia: Mayol Ediciones S.A.
DNP. (2009). Departamento Nacional de Planeación - El desafío de la gerencia de
proyectos. Bogotá, Colombia.
EIA. (2010). Escuela de Ingeniería de Antioquia. Recuperado el 05 de 09 de 2010,
de Especialización en Gerencia de Proyectos “Gestión efectiva de proyectos”:
http://www.eia.edu.co/site/Postgrados/Especializaciones/GerenciadeProyectos/tabi
d/91/Default.aspx
FEDESOFT. (2009). Federación Colombiana de la Industria del Software.
Recuperado el 10 de Noviembre de 2009, de Federación Colombiana de la
Industria del Software: http://www.fedesoft.org
GARCÍA, M. C., Garzás, J., & Piattini, M. (s.f.). La Mejora de Proceso en
Pequeñas Empresas y la ISO/IEC 29110. Recuperado el 05 de Febrero de 2010,
de Kybele Consulting:
http://www.kybeleconsulting.com/.../MCGarcia_MejoraProcesos_ISO29110.pdf
IEEE. (2010). Guide to the Software Engineering Body of Knowledge (SWEBOK).
Recuperado el 18 de Febrero de 2010, de IEEE Computer Society:
http://www.computer.org/portal/web/swebok
IEEE. (2010). IEEE Colombia. Recuperado el 10 de Octubre de 2009, de The
Institute of Electrical and Electronics Engineers, Inc.: www.ieee.org.co
IEEE. (2009). IEEE Computer Society. Recuperado el 18 de 10 de 2009, de IEEE
Technical Council on Software Engineering (TCSE):
http://www.computer.org/portal/web/tcse
124
IEEE. (2007). IEEE Computer Society Colombia. Recuperado el 16 de Enero de
2010, de IEEE Computer Society Colombia:
http://ewh.ieee.org/r9/colombia/computer/home.php
IEEE. (2009). IEEE Publications & Standards. Recuperado el 18 de 10 de 2009, de
IEEE Standards Association: http://www.ieee.org/web/standards/home/index.html
IEEE. (2009). IEEE Software & Systems Engineering Standards Collection.
Recuperado el 18 de 10 de 2009, de IEEE Computer Society:
http://standards.computer.org/sesc/s2esc_geninfo/infondex.htm
IEEE. (2010). Publications & Standards. Recuperado el 18 de 10 de 2009, de The
Institute of Electrical and Electronics Engineers, Inc:
http://www.ieee.org/web/standards/home/index.html
PELÁEZ, L. E. (2008). Introducción a la ingeniería del software. Pereira.
PMBOK. (2009). A guide to the Project Management Body Of Knowledge (4ª
Edition).
PRESSMAN, R. S. (2004). Software Engineering: A Practitioner's Approach.
McGraw-Hill.
PRESSMAN, R. S. (2005). Software Engineering: A Practitioner's Approach.
McGraw-Hill.
PRESSMAN, Roger S, Ingeniería del Software. Un enfoque práctico. (6ª edición). Capitulo 21: Conceptos de gestión de proyectos pg. 640-645. Editorial McGraw Hill, 2005
SOMMERVILLE. (2004). Software engineering. Addison Wesley.
SOMMERVILLE, I. (2005). Ingeniería del Software. Madrid: Pearson Education
S.A.
SWEBOK. (2004). A Guide to the Software Engineering Body of Knowledge (2004
edition).
TENSTEP. (2009). Metodología Tenstep de Dirección de Proyectos.
The IEEE Computer Society. (s.f.). Recuperado el 16 de Enero de 2010, de
www.computer.org
125
The Software Engineering Technical Committee of the Computer Society of the
IEEE. (1988). IEEE Standard for Software Project Management Plans.
Recuperado el 02 de Abril de 2010, de Kybele -
WEITZENFELD, A. (2002). INGENIERIA DE SOFTWARE ORIENTADA A
OBJETOS. México: Thomson.
ZELKOVITZ, M. V. (1979). Principles of Software Engineering and Design.
Prentice Halls.
SCRUM MANAGER. Gestión de Proyectos, Manual de gestión de proyectos ágil, 2009 GEDPRO. Consultores de Gestión de Proyectos (Project Management), 2010 HORINE, Gregory M. Gestión De Proyectos. 1ª Edición. Madrid. Anaya Multimedia. 2005. 400 págs. ISBN: 9788441519176 COVEY, Steven. Los siete hábitos de la gente altamente efectiva. 1ª Edición. Barcelona. Paidós. 1989 ROBERTS, Paul. Guía de gestión de proyectos. 1ª Edición. Barcelona. The Economist. 2008. 320 págs. ISBN: 978-84-9875-013-3. GUERRA PEÑA, Luis. Gestión integral de proyectos. Fundación Confemetal. 501 págs. ISBN: 8495428482 ISBN-13: 9788495428486 GRAY, Clifford F. / LARSON, Erik W. Administración De Proyectos. 1ª Edición. México. McGraw Hill. 2009. 280 págs. ISBN: 978-970-10-7235-6 GIDO, Jack. / CLEMENTS, James P. Administración Exitosa de Proyectos. 3ª Edición. Ediciones Thomson. 2008. 426 págs. ISBN: 978-970-686-713-1 MCCONNELL, Steve. Desarrollo y gestión de proyectos informáticos. 1. ed.(11/1997) McGraw-Hill / Interamericana de España, S.A. 720 páginas. ISBN: 8448112296 ISBN-13: 9788448112295 CASAL Otero, Lorena. Gestión de proyectos. Elementos básicos a tener en cuenta como punto de partida para realizar eficazmente su proyecto. Ideaspropias Editorial (Pontevedra, España) 20/11/2009. 121 páginas. ISBN: 9788498393255
126
SERER Figueroa, Marcos. Gestión integrada de proyectos Ediciones UPC2009-07-01. 448 Páginas. ISBN: 848301887X. ISBN-13: 9788483018873 SAPAG Puelma, José Manuel. Evaluación de proyectos Guía de ejercicios, Problemas y soluciones. 348 págs. ISBN: 9701043251 KEONTZ, Harold y Weihrich, Heinz. Administración: Una Perspectiva Global. Mcgrawhill12ª edición.
127
11. WEBGRAFÍA ACIS- Desarrollar proyectos de software y “evitar” el fracaso ? Recuperado el 20 de Nomviembre de 2010: Http://www.acis.org.co/fileadmin/Curso_Memorias/CONCLUSIONES.pDF Sociedad Chilena de Software y Servicios A.G. (GECHS). (s.f.). Historia. Recuperado el 14 de Noviembre de 2009, de GECHS Software y Servicios Chile A.G: http://www.gechs.cl/content/view/32439/Historia.html
Sociedad SOFTEX. (s.f.). MPS.BR - Mejora de Proceso del Software Brasileño. Guía de Adquisición. Recuperado el 08 de Febrero de 2010, de SOFTEX: http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Gu%C3%ADa_de_Adquisici%C3%B3n_2009.pdf
Sociedad SOFTEX. (s.f.). MPS.BR - Mejora de Proceso del Software Brasileño. Guía General. Recuperado el 08 de Febrero de 2010, de SOFTEX: http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Gu%C3%ADa_General_2009.pdf System Concepts. (2009). System Concepts. Recuperado el 11 de Mayo de 2010, de Usability, Ergonomics, Health and Safety Consultants: http://www.system-concepts.com/articles/usability-and-ergonomics-standards/three-new-accessibility-and-web-design-standards-iso-9241-parts-20-151-and-171.html The IEEE Computer Society. (s.f.). Recuperado el 16 de Abril de 2010, de www.computer.org The Software Engineering Technical Committee of the Computer Society of the IEEE. (1988). IEEE Standard for Software Project Management Plans. Recuperado el 02 de Abril de 2010, de Kybele - Grupo de investigación de la Universidad Rey Juan Carlos: http://www.kybele.etsii.urjc.es/docencia/IS3/2009-2010/Material/%5BIS3-0910%5DIEEE-1058.1.pdf
128
The Project Management Institute. About Us. Recuperado el 15 de agosto de 2010: http://www.pmi.org/ GEDPRO compañía global de consultoría de Gestión de Proyectos. Recuperado el 15 de agosto de 2010:http://www.gedpro.com/Acercadegedpro.aspx
