UNIVERSIDAD DE ATACAMA FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERIA INFORMATICA Y CIENCIAS DE LA COMPUTACION
APLICACIÓN DE UNA PLATAFORMA TECNOLOGICA OPEN SOURCE DE APOYO A LA GESTION DE PROYECTOS DE SOFTWARE.
ORLANDO A. BOLADOS TORREJÓN 2010
UNIVERSIDAD DE ATACAMA FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERIA INFORMATICA Y CIENCIAS DE LA COMPUTACION
APLICACIÓN DE UNA PLATAFORMA TECNOLOGICA OPEN SOURCE DE APOYO A LA GESTION DE PROYECTOS DE SOFTWARE.
"TRABAJO DE TITULACION PRESENTADO EN CONFORMIDAD A LOS REQUISITOS PARA OBTENER EL TITULO DE INGENIERO CIVIL EN COMPUTACIÓN E INFORMÁTICA”.
PROFESOR GUÍA: HÉCTOR CORNIDE REYES.
ORLANDO A. BOLADOS TORREJÓN 2010
Resumen.
El presente trabajo de titulación consiste en la aplicación de una plataforma tecnológica Open Source, que apoye la gestión del proyecto que se realiza cada año en la asignatura de Ingeniería de Software, del Departamento de Informática y Cs. De la Computación en la Universidad de Atacama. Dicho apoyo será medido a través de KPI del ingles Key Performance Indicators o Indicadores clave de Rendimiento, con los cuales se medirá el impacto asociado a la gestión del proyecto haciendo uso de una plataforma de gestión de proyectos.
En el capítulo 1 se presenta la justificación y los objetivos de este trabajo de titulo. El capítulo 2 está dedicado por completo a la gestión de proyectos de software, donde vera entre otros el “éxito y fracaso en los proyectos de software”. El capítulo 3 hace referencia al desempeño de un equipo de trabajo y cuáles son los desafíos habituales a los que se enfrentan, los equipos de alto desempeño. Luego en el capítulo 4 se investiga y selecciona una herramienta tecnológica y en el capítulo 5 se definen una serie de KPI que servirán para realizar seguimiento y control a la plataforma. Luego en el capítulo 6 se verá el resultado del seguimiento y control realizado en la plataforma, para finalmente en el capítulo 7 entregar las conclusiones de este trabajo de título.
Índice de Contenidos Contenidos Páginas
Capítulo 1. Introducción...... 1 1.1. Preámbulo...... 1 1.2. Objetivos del Trabajo de Titulación...... 2 1.3. Síntesis de Contenidos...... 3 Capítulo 2. Gestión de Proyectos de Software...... 4 2.2. Definición de Gestión de Proyectos de Software...... 5 2.2.1. Las Cuatro P’s en la Gestión de Proyectos...... 6 2.3. Fases de la Gestión de Proyectos...... 11 2.4. Fases del desarrollo de Software...... 14 2.5. Éxito y fracaso en los Proyectos de Software...... 17 2.5.1. Las cinco máximas de satisfacción...... 18 2.5.2. Pasos básicos para lograr una gestión eficiente...... 18 2.5.3. Aspectos críticos que contribuyen al fracaso de proyectos...... 19 Capítulo 3.- Desempeño del Equipo de Trabajo...... 22 3.1.Introducción ...... 22 3.2.Factores que influyen en el desempeño del equipo de trabajo...... 23 3.2.1. Tamaño del equipo...... 24 3.2.2. Las habilidades de los miembros...... 25 3.2.3. La asignación de roles...... 25 3.2.4. Tener un compromiso y un propósito común...... 26 3.2.5. Establecimiento de metas específicas...... 26 3.2.6. Liderazgo y estructura...... 27 3.3.La cohesión en los equipos de trabajo...... 27 3.3.1. La sociometría: Análisis de la interacción de grupos...... 30 3.4.La toma de decisiones...... 33 3.4.1. Técnicas para la toma de decisión...... 34 Capítulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos………………………………………………………………………………...36 4.1.Introducción...... 36
4.2.Las TIC en la Gestión de Proyectos...... 37 4.2.1.La Gestión de Portafolios...... 38 4.2.2.Outsourcing...... 38 4.2.3.El desarrollo a distancia...... 39 4.2.4.Seguimiento y control de los proyectos...... 39 4.3.Modelo de Gestión de Proyectos de Software...... 39 4.4.Herramientas Tecnológicas de apoyo a la Gestión de Proyectos...... 43 4.5.Selección de la herramienta más adecuada...... 47 4.6.Metodología de Trabajo...... 56 4.7.Observaciones Generales...... 58 Capítulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión...... 59 5.1.Introducción...... 59 5.2.Mecanismos de evaluación...... 59 5.2.1.Necesidad de información...... 61 5.2.2.Selección del indicador...... 62 5.3.Determinación de Indicadores Clave de Rendimiento (KPI’s)...... 63 KPI – Porcentaje de uso de la plataforma de gestión...... 67 KPI – Porcentaje de uso módulo comunicación instantánea...... 68 KPI – Porcentaje distribución de la carga horaria...... 69 KPI – Porcentaje de tareas realizadas...... 71 KPI – Porcentaje de uso módulo mensajes...... 72 KPI – Porcentaje de archivos de documentación ...... 74 KPI – Porcentaje de archivos de desarrollo...... 75 5.4.Observaciones Generales...... 76 Capítulo 6.- Seguimiento y Control de la Plataforma de Gestión...... 77 6.1. Introducción...... 77 6.2. Implementación de los KPI...... 77 6.2.1. Porcentaje de uso de la plataforma de gestión...... 78 6.2.2. Porcentaje de uso del módulo de comunicación instantánea...... 80 Jefe de Proyecto ...... 82 Jefe de Análisis...... 85
Jefe de Diseño ...... 88 Jefe de Desarrollo ...... 90 6.2.4. Porcentaje de tareas realizadas...... 93 6.2.5. Porcentaje de uso del módulo mensajes...... 96 6.2.7. Porcentaje de Archivos de Desarrollo...... 100 6.3. Apreciaciones Generales...... 102 Capítulo 7.- Conclusiones...... 103 7.1. Del Trabajo de Titulo...... 103 7.2. De la Experiencia Personal...... 104 7.3. De los Trabajos Futuros...... 105 Referencias Bibliográficas……………………………………………………………..106
Anexos...... 108
Índice de Figuras Figuras Páginas Figura 2.1. Gestión de Proyectos de Software: Las 4Ps...... 7 Figura 2.2. Organigramas de Equipo...... 8 Figura 2.3. Función de Ámbito y Objetivos...... 9 Figura 2.4. Fases de la Gestión de Proyectos...... 12 Figura 2.5. Fases Genéricas del Desarrollo de Software...... 16 Figura 3.1. Diferencias entre grupo de trabajo y equipo de trabajo...... 24 Figura 3.2. Relación entre normas, cohesión y productividad...... 29 Figura 3.3. Diagrama de Red Social o Sociograma...... 32 Figura 4.1. Modelo de Selección-Integración Plataforma de Gestión...... 40 Figura 4.2. Desarrollo de Software sin Plataforma de Gestión...... 41 Figura 4.3. Desarrollo de Software con Plataforma de Gestión...... 43 Figura 5.1 Concepto de Métrica...... 60 Figura 6.1.- Representación grafica KPI %UPG...... 79 Figura 6.2.- Representación grafica KPI %UMCI...... 82 Figura 6.3.- Representación grafica KPI %DCH- Jefe de Proyecto...... 84 Figura 6.4.- Representación grafica KPI %DCH- Jefe de Análisis...... 87 Figura 6.5.- Representación grafica KPI %DCH- Jefe de Diseño...... 90
Figura 6.6.- Representación grafica KPI %DCH- Jefe de Desarrollo...... 92 Figura 6.7.- Representación grafica KPI %TR...... 95 Figura 6.8.- Representación grafica KPI %UMM...... 97 Figura 6.9.- Representación grafica KPI %ADD...... 99 Figura 6.10.- Representación grafica KPI %ADDS...... 102
Índice de Tablas Tablas Páginas Tabla 2.1. Diferencia entre Metodología de Gestión de Proyectos y Desarrollo de Software...... 6 Tabla 2.2. Ejemplo de Organigrama de Equipo según factor...... 8 Tabla 2.3. Actitud acción, frente a las señales de fracaso...... 11 Tabla 2.4. ¿Por qué fallan los proyectos? ...... 21 Tabla 3.1. Términos claves para Analizar un sociograma...... 31 Tabla 4.1. Plataformas seleccionadas preliminarmente...... 47 Tabla 4.2. Selección de la Plataforma...... 48 Tabla 4.3. Escala de notas-Plataforma Completa...... 49 Tabla 4.4. Escala de notas-Integración con servidor...... 50 Tabla 4.5. Escala de notas-Configuración...... 50 Tabla 4.6. Escala de notas-Documentación en el sitio WEB...... 51 Tabla 4.7. Escala de notas-Documentos oficiales en español...... 52 Tabla 4.8. Escala de notas-Manual de Instalación-Usuario...... 52 Tabla 4.9. Escala de notas-Usabilidad...... 53 Tabla 4.10. Escala de notas-Operatividad...... 53 Tabla 4.11. Escala de notas-Simplicidad...... 54 Tabla 4.12. Escala de notas-Adecuación...... 54 Tabla 4.13. Escala de notas-Fiabilidad...... 55 Tabla 4.14. Escala de notas-Seguridad...... 55 Tabla 4.15. Evaluación de las Plataformas...... 56 Tabla 5.1. Indicadores y su objeto...... 62 Tabla 5.2.- Porcentaje de uso de la plataforma de gestión...... 67
Tabla 5.3.- Porcentaje de uso de la plataforma de gestión...... 68 Tabla 5.4.- Porcentaje distribución de la carga horaria...... 69 Tabla 5.5.- Porcentaje de tareas realizadas...... 71 Tabla 5.6.- Porcentaje de tareas realizadas...... 72 Tabla 5.7.- Porcentaje de archivos de documentación...... 74 Tabla 5.8.- Porcentaje de archivos de desarrollo...... 75 Tabla 6.1.- Periodo de las muestras...... 77 Tabla 6.2.- Valor Muestra KPI %UPG...... 78 Tabla 6.3.- Valor Muestra KPI %UMCI...... 81 Tabla 6.4.- Valor Muestra KPI %DCH-Jefe de Proyecto...... 83 Tabla 6.5.- Valor Muestra KPI %DCH- Jefe de Análisis...... 85 Tabla 6.6.- Valor Muestra KPI %DCH-Jefe de Diseño...... 88 Tabla 6.7.- Valor Muestra KPI %DCH-Jefe de Desarrollo...... 90 Tabla 6.8.- Valor Muestra KPI %TR...... 94 Tabla 6.9.- Valor Muestra KPI %UMM...... 96 Tabla 6.10.- Valor Muestra KPI %ADD...... 98 Tabla 6.11.- Valor Muestra KPI %ADDS...... 100
Capitulo 1.- Introducción
Capítulo 1. Introducción.
1.1. Preámbulo.
La gestión eficaz de un proyecto de software se centra en las 4P’s. La única manera conocida de gestionar la complejidad es a través de la gestión del proyecto, junto con la necesidad de contar con personal altamente preparado y motivado, que conozca los objetivos y ámbitos del producto y que en base a un proceso de desarrollo de software, garantice el éxito en el desarrollo del mismo. Sin embargo, este éxito está sujeto al desempeño del equipo de desarrollo, si éste no cuenta con el personal idóneo en la tarea designada, es casi inevitable evitar el fracaso del proyecto.
De la experiencia de años anteriores en la asignatura de Ingeniería de Software, se puede concluir que los alumnos no tienen el mejor de los desempeños a nivel grupal en el desarrollo de proyectos de software, ya que cumplen con las expectativas, pero no logran la cohesión deseada para obtener un producto final de calidad, derivado de la sinergia de su trabajo. El seguimiento y control dentro del equipo de desarrollo es prácticamente nulo, lo que conlleva a doblegar esfuerzos en sacar adelante la tarea, disminuyendo en algunos casos el rendimiento de algunos integrantes del equipo en otras asignaturas de la especialidad. Este problema no ésta presente solo en la asignatura citada, ya que según un artículo en la web 1, señala que Dwolatzky Barry, director de la Escuela de Johannesburgo de Ingeniería de Software en la Universidad Wits de Sudáfrica, cita un estudio de Standish Group, que dice que el 65% de los proyectos de desarrollo de software a gran escala fracasan debido a su mala gestión, además de que los clientes o usuarios de la misma manera se muestran insatisfechos con la calidad de los sistemas de software. Es por esto que no es de sorprender que las organizaciones de desarrollo de software busquen activamente nuevas
1 Senne, D http://ezinearticles.com/?7-Reasons-Your-Software-Development-Company-Should-Work-on-Getting-a-CMMI- Rating&id=739367 , última visita diciembre de 2010
1
Capitulo 1.- Introducción maneras de mejorar su desempeño y con ello la calidad del producto software.
Ante estas deficiencias, las organizaciones desarrolladoras de software han visto en las TIC la clave para combinar de manera eficiente y eficaz las 4P’s: Persona, Producto, Proceso, Proyecto. Es decir, utilizar una plataforma tecnológica de apoyo a la gestión de proyectos, que permita realizar un seguimiento y control de las tareas asignadas al Personal, medir el grado de avance del Producto, mejorar la gestión del Proceso y evaluar el estado del Proyecto, todo esto para contribuir a una mejora continua en el desarrollo del proyecto aplicando acciones correctivas que permitan obtener un software de calidad, en un tiempo deseado y con las personas desempeñando tareas adecuadas. Esto último es lo que motiva el estudio e implantación de una plataforma tecnológica Open Source que apoye a la gestión del proyecto de software, que se desarrolla en la asignatura de Ingeniería de Software I, con el fin de mejorar tanto el desempeño personal y grupal de los alumnos que cursan la asignatura, como la calidad del producto software entregado, en base a las nuevas formas de gestión de proyectos que se utilizan hoy en día en las organizaciones.
1.2. Objetivos del Trabajo de Titulación.
Los objetivos se dividen en: generales y específicos , y son estos últimos los que marcan la pauta para este trabajo de título.
• Objetivo General. Aplicar una Plataforma Tecnológica que sirva de Apoyo a la Gestión de Proyectos de Software.
• Objetivos Específicos. 1. Investigar las variables que inciden en la gestión de un proyecto de software.
2
Capitulo 1.- Introducción
2. Investigar sobre las plataformas Open Source existentes que apoyen la gestión de proyectos.
3. Seleccionar la plataforma que más se ajuste a la problemática.
4. Definir un modelo para asegurar la mejora en la gestión de un proyecto de software.
5. Aplicar la plataforma y el modelo al taller que se realiza en la asignatura de Ingeniería de Software.
1.3. Síntesis de Contenidos.
En el capítulo 2 se define la gestión de proyectos, se describen las diferentes fases que contemplan tanto la gestión de proyectos como el desarrollo de software y se listan algunos de los factores que influyen en el fracaso de los proyectos de desarrollo de software. Luego en el capítulo 3 se establecen las diferencias entre un equipo de trabajo y un grupo de trabajo, se mencionan los factores que influyen en el desempeño de los equipos de trabajo y como la cohesión influye en el desempeño de estos, para finalmente abordar la toma de decisiones en el equipo de trabajo. En el Capítulo 4, se destaca la gran influencia que han tenido las TIC’s (tecnologías de la información y comunicación) en la gestión de proyectos, además se investigan las plataformas tecnológicas Open Source existentes y se selecciona la mejor a partir de criterios de selección estructurados y bien definidos, para finalizar con la definición de un modelo de gestión que ilustra cómo será la integración entre la plataforma seleccionada y el modelo de desarrollo de software utilizado por el equipo de desarrollo. Ya en el Capítulo 5 se evalúan los diferentes mecanismos de evaluación para usar con la plataforma de gestión y finalmente se definen siete indicadores que permitirán llevar a cabo el seguimiento y control de ésta. En el capítulo 6 se muestran los resultados obtenidos al realizar seguimiento y control, utilizando los indicadores clave de rendimiento y finalmente en el capítulo 7 se describen las conclusiones de este trabajo de titulación.
3
Capitulo 2.- Gestión de Proyectos de Software
Capítulo 2. Gestión de Proyectos de Software.
2.1. Introducción.
Un proyecto de desarrollo de software no es como cualquier proyecto, en él se conjugan un sin número de variables que van desde el entendimiento del problema, el uso de metodologías de diseño y hasta el lenguaje de programación. Pero quizás la diferencia más importante para la mayoría de los gestores de proyectos de software está en que éste, es un producto intangible que no se fabrica, sino que se desarrolla, puede tener errores y estos no serán visibles ante ojo humano, a diferencia de los productos tangibles, en donde los errores son visibles de principio a fin.
La gestión de proyectos busca siempre maximizar la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para satisfacer los requerimientos de este. La gestión de proyectos se logra mediante la aplicación e integración de las fases de gestión de proyectos: inicio, planificación, ejecución, seguimiento y control, y finalización.
La gestión de un proyecto incluye:
• Identificar los requisitos. • Establecer objetivos claros y posibles de realizar. • Equilibrar las demandas concurrentes de calidad, alcance, tiempo y costos. • Adaptar las especificaciones, los planes y el enfoque a las diversas inquietudes y expectativas de los diferentes interesados.
El gestor del proyecto es la persona responsable de alcanzar los objetivos del proyecto. Por lo tanto, dependerá en gran medida de la gestión de éste, el éxito o fracaso alcanzado por el proyecto. Un proyecto mal planificado tardará en realizarse tres veces más del tiempo previsto. Un proyecto bien planificado que
4
Capitulo 2.- Gestión de Proyectos de Software tenga en consideración los criterios básicos para lograr el éxito y los aspectos que contribuyen al fracaso de los proyectos, permite afirmar que el proyecto estará cercano a los objetivos y tiempos estimados inicialmente.
2.2. Definición de Gestión de Proyectos de Software.
En palabras simples una buena gestión de un proyecto es la que permite reducir al mínimo las posibilidades de fracaso de éste, durante el transcurso del mismo. Entendiéndose como fracaso, la no consecución de los objetivos del proyecto, la inviabilidad económica del mismo, la insatisfacción del cliente, etc. Formalmente se entiende que “La gestión de proyectos implica la planificación, supervisión y control del personal, del proceso y los eventos que ocurren mientras evoluciona el software desde la fase preliminar a la implementación operacional” 2. La gestión de proyectos se ha constituido en una disciplina en sí misma, pues ha desarrollado un cuerpo de conocimiento y posee un lenguaje específico, es decir, se ha ido formando y evolucionando durante su existencia. Esta evolución ha traido consigo nuevas metodologias y/o modelos tanto para la gestion de proyectos de software, como para el desarrollo del mismo, debido a la alta complejidad que han llegado a presentar algunos proyectos.
Es importante establecer una distinción entre una metodología de gestion de proyectos y una metodología de desarrollo de software. La importancia de distinguir entre ambos conceptos radica en que una organización debe contar con una metodología de administración de proyectos consistente a cualquiera que sea la naturaleza del proyecto que se desarrolla. Las diferencias entre ambos conceptos se listan en la Tabla 2.1.
2 Pressman, R., “Ingeniería del Software, un enfoque practico”, 5ta edición, McGraw-Hill, 2002, pág. 37.
5
Capitulo 2.- Gestión de Proyectos de Software
Tabla 2.1. Diferencia entre Metodología de Gestión de Proyectos y Desarrollo de Software. Fuente: NEVILLE, T. Project management and software development methodology .
Metodología de Gestión de Metodología de Desarrollo de Proyectos Software
Establece que los proyectos deben ser Establece cuáles son las fases y que divididos en fases y antes de iniciar actividades involucra. cada una de ellas debe existir un plan. Define roles y responsabilidades. Define cuáles son los roles y responsabilidades que corresponden a cada fase. Establece que un presupuesto debe Define qué medidas deben emplearse ser definido y administrado. para contabilizar el desarrollo en la organización.
Como se mencionó anteriormente en el desarrollo de un producto software, son muchas variables las que inciden, para algunos autores unas más importantes que otras, lo cierto es que éstas siempre estarán presentes haciendo que los proyectos de software necesiten ser gestionados en torno al personal, al producto, al proceso y al proyecto.
2.2.1. Las Cuatro P’s en la Gestión de Proyectos.
Un buen gestor sabe que para lograr una gestión eficaz de un proyecto de software debe centrarse en las cuatro P’s: personal, producto, proceso y proyecto. Tal como lo muestra la Figura 2.1 el gestor que olvide que el desarrollo de un software depende en gran manera de las capacidades y habilidades del personal , pondrá en riesgo la gestión del proyecto, a su vez si éste presta poca atención al proceso, corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacio, lo que provocará que el proyecto tenga una planificación deficiente de las actividades del proceso y por ende se arriesga a obtener un producto software elegante para un problema equivocado, es decir, un software visualmente aceptable, pero que no resuelve la problemática del cliente.
6
Capitulo 2.- Gestión de Proyectos de Software
Proceso Personas
Pro yecto
Producto
Figura 2.1. Gestión de Proyectos de Software: Las 4Ps. Fuente: Pressman, R., “Ingeniería del Software, un enfoque practico”, 5ta edición.
2.2.1.1. Personas.
La selección del personal lo suficientemente capacitado y motivado, es un aspecto clave en la gestión de proyectos de software, ya que son estos los autores de un proyecto de software. Gestores superiores, gestores del proyecto, profesionales, clientes y usuarios finales están involucrados en todo el ciclo de vida de un producto software. El gestor del proyecto (jefe de equipo) debe ser capaz de organizar al equipo de desarrollo de manera tal que pueda maximizar las habilidades y capacidades de cada integrante del equipo.
El jefe de equipo puede influir de manera positiva o negativa al equipo de desarrollo de software, la manera en que éste influya dependerá en mayor parte de su capacidad de resolución de problemas, de su habilidad para motivar e incentivar al equipo de desarrollo y de sus dotes de gestión.
La estructura del equipo depende del estilo de gestión de la organización, pero existe evidencia de que la estructura más productiva es aquella en que:
• A una determinada cantidad de individuos los organiza en t equipos, a éstos se les asignan una o más tareas funcionales. Cada equipo tiene una estructura específica que se define para todos los equipos que
7
Capitulo 2.- Gestión de Proyectos de Software
trabajan en el proyecto, la coordinación es controlada por el equipo y por el gestor de proyectos de software.
La manera en que se organice el equipo de desarrollo puede ser considerando uno de los tres organigramas presentados en la Figura 2.2, la elección del más adecuado dependerá del jefe del e quipo.
• No tiene jefe • Tiene un jefe que • El jefe de equipo permanente coordina tareas coordina y resuelve • Se nombran específicas problemas coordinadores de • Toma de desición • La comunicacion tarea a corto plazo grupal vertical • Toma de desicion • Soluciones grupal desarrolladas por • Comunicacion subgrupos
horizontal. • Comunicacion Controlado Centralizado
Descentralizado Controlado Descentralizado horizontal y vertical Descentralizado Democratico Descentralizado
Figura 2.2. Organigramas de Equipo. Fuente: Pressman, R., “Ingeniería del Software, un enfoque practico”, 5ta edición.
En la Tabla 2.2 se muestra un resumen de los factores que pueden influir en la elección del organigrama del equipo.
Tabla 2.2. Ejemplo de Organigrama de Equipo según factor. Fuente: Pressman, R., “Ingeniería del Software, un enfoque practico”, 5ta edición. Factor Organigrama Problema sencillo Descentralizado Controlado o Centralizado Controlado Problema difícil Descentralizado Democrático Proyecto muy grande Descentralizado Controlado o Centralizado Controlado Proyecto de más de 1 año Descentralizado Democrático Modularidad baja Descentralizado Democrático Modularidad alta Descentralizado Controlado o Centralizado Controlado
8
Capitulo 2.- Gestión de Proyectos de Software
Se pueden aplicar varias técnicas de coordinación y comunicación para apoyar el trabajo del equipo. En general , las revisiones formales y comunicaciones informales persona a persona son las más valiosas para los profesionales.
2.2.1.2. Producto.
Antes de planificar un proyecto de desarrollo de software, el gestor debe establecer el ámbito y los objetivos del producto (ver Figura 2.3), de esta forma se podrán identificar dificultades técnicas y de gestión.
•Identifica datos cuantitativos, •Identifican las metas generales funciones y comportamiento del producto que se desea
Ámbito que caracterizan al producto . obtener sin conocer como Objetivos conseguirlas.
Figura 2.3. Función de Ámbito y Objetivos. Fuente: Pressman, R., “Ingeniería del Software, un enfoque practico”, 5ta edición.
Otra actividad importante es la descomposición del problema, para desarrollar una planificación razonable se debe descomponer funcionalmente el problema a resolver. Esta descomposición se aplica en dos áreas principales:
• La funcionalidad que debe entregarse. • El proceso que se emplear á para entregarlo.
El objetivo de la descomposición es hacer más fácil la planificación, basándose en el popular “divide y vencerás”.
2.2.1.3. Proceso.
“El gestor del proyecto debe decidir qué modelo de proceso es el más adecuado para los clientes que han solicitado el producto y la gente que realizara
9
Capitulo 2.- Gestión de Proyectos de Software el trabajo; las características del proyecto en sí, y el entorno del proyecto en el que trabaja el equipo de desarrollo” 3.
Un proceso de software proporciona el marco de trabajo desde el cual se puede establecer un plan detallado para el desarrollo del software. Un pequeño número de actividades del marco de trabajo es aplicable a todos los proyectos de software, sin importar su tamaño o complejidad. Algunos conjuntos de tareas diferentes (tareas, hitos, productos de trabajo y puntos de control de calidad) permiten que las actividades del marco de trabajo se adapten a las características del proyecto de software, así como a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras como control de calidad, la gestión de configuración y la medición, cubren el modelo del proceso. Las actividades protectoras son independientes de cualquier actividad del marco de trabajo y ocurren durante todo el proceso.
2.2.1.4. Proyecto.
“Para Gestionar un proyecto de software con éxito, debemos comprender que puede ir mal y cómo hacerlo bien” 4. A continuación, se enlistan las 10 señales que indican que un proyecto está en peligro:
1. El personal de software no entiende las necesidades de sus clientes. 2. El ámbito del producto está más definido. 3. Los cambios se gestionan mal. 4. La tecnología elegida cambia. 5. Las necesidades comerciales cambian. 6. Los plazos de entrega no son realistas. 7. Los usuarios se resisten. 8. Se pierde el patrocinio.
3 Pressman, R., “Ingeniería del Software, un enfoque practico”, 5ta edición, McGraw-Hill, 2002, pág. 46. 4 Pressman, R., “Ingeniería del Software, un enfoque practico”, 5ta edición, McGraw-Hill, 2002, pág. 48.
10
Capitulo 2.- Gestión de Proyectos de Software
9. El equipo de proyecto carece de personal con las habilidades apropiadas. 10. Los gestores evitan las mejores prácticas y las lecciones aprendidas.
Estas señales son claves para reordenar el curso de las acciones y evaluar acciones correctivas. La Tabla 2.3 describe lo que un gestor de proyectos de software debe hacer si desea evitar los problemas señalados.
Tabla 2.3. Actitud acción, frente a las señales de fracaso. Fuente: Pressman, R., “Ingeniería del Software, un enfoque practico”, 5ta edición. Actitud ¿Cómo? Empezar con el pie derecho Se debe comprender bien el proyecto, con el fin de definir objetivos claros y precisos. Se debe dar al equipo autonomía, autoridad, y tecnología. Mantenerse Se debe proporcionar incentivos. Los gestores deben estar fuera del camino del equipo de desarrollo. Seguimiento del progreso Se debe hacer revisiones técnicas formales. Establecer medidas que muestren el progreso. Tomar decisiones inteligentes Debe primar siempre la simplicidad. Es recomendable utilizar software o componentes ya desarrollados. Realizar un análisis de Es recomendable utilizar métricas en el resultados proceso de desarrollo. Registrar los hallazgos.
2.3. Fases de la Gestión de Proyectos.
Para facilitar la gestión, los gestores de proyectos o la organización pueden dividir los proyectos en fases, con los enlaces correspondientes a las operaciones de la organización ejecutante. El conjunto de estas fases se conoce como ciclo de vida del proyecto. Muchas organizaciones identifican un conjunto de ciclos de vida específico para usarlo en todos sus proyectos.
11
Capitulo 2.- Gestión de Proyectos de Software
La Figura 2.3 presenta las cinco fases distinguibles en la gestión de proyectos de software. Es importante resaltar que n o todos los proyectos pasan por cada una de las fases de la gestión de proyectos , ya que los proyectos pueden ser terminados antes de que alcancen la etapa de finalización (abandono). Algunos proyectos pro bablemente no tienen planificación y/o control y algunos proyectos pasarán por 2, 3 y 4 varias veces.
Figura 2.4. Fases de la Gestión de Proyectos. Fuente: Delgado, J., “Administración de proyectos -Ciclo de vida del proyecto”, http://www.monografias.com/trabajos38/ciclo -vida-proyecto/ciclo-vida-proyecto.shtml , última consulta diciembre de 2010.
Según Delgado 5, cada fase consiste pri ncipalmente en:
1. Iniciación del proyecto : En esta etapa se comienza con el análisis del problema, se evalúan eventuales requerimientos explícitos e implícitos, se define el propósito, el alcance y el marco de referencia para el proyecto, se determinan los resultados esperados en base a la definic ión de objetivos, el gestor de proyecto define la metodología de trabajo, la participación del
5 Delgado, J., “Administración de proyectos -Ciclo de vida del proyecto”, http://www.monografias.com/trabajos38/ciclo -vida-proyecto/ciclo-vida-proyecto.shtml , úl tima consulta diciembre de 2010
12
Capitulo 2.- Gestión de Proyectos de Software
usuario. Se definen los roles que tendrán cada uno dentro del ciclo de vida del proyecto y finalmente se diseña el plan general de implementación.
2. Planificación del Proyecto: Se sabe que la planeación es la definición clara y precisa de objetivos y las actividades que se ejecutarán para lograrlos, es decir un plan de acción aplicable que describa: lo que hay que hacer, en el orden necesario y con los medios de que se dispone para alcanzar los objetivos.
Las acciones a realizar en la planificación de proyectos son:
• Identificación de Actividades o Tareas. • Secuenciación de Actividades. • Estimación de la duración/esfuerzo de las Actividades. • Estimación de las necesidades de recursos. • Estimación de los costos de las Actividades. • Representación gráfica del flujo de Actividades (Diagrama de Gantt). • Optimización de la planificación.
3. Ejecución del proyecto: Esta etapa se compone de los recursos necesarios para llevar a cabo la planificación. Como parte de la ejecución del proyecto se recoge información sobre el estado de los productos, a fin de garantizar que el producto utilice todos los procesos necesarios para satisfacer los requerimientos.
Se selecciona el recurso humano necesario y se desarrollan sus competencias y habilidades para tener la mejor de las interacciones a fin de lograr el mejor rendimiento en el ciclo de vida del proyecto
4. Supervisión y Control del Proyecto: Las mayores desviaciones que se producen en un proyecto son debidas a deficiencias en el control del
13
Capitulo 2.- Gestión de Proyectos de Software
mismo. Para asegurar la eficacia de la ejecución es necesario que el gestor del proyecto realice como mínimo las siguientes actividades:
• Seguimiento técnico. • Seguimiento económico. • Recoger datos. • Seguimiento de los riesgos. • Informar. • Tomar medidas asegurándose de que la decisión se puede justificar con datos. • Replanificación.
5. Finalización del Proyecto: Una buena finalización del proyecto requiere realizar una serie de tareas para las que se recomienda reservar tiempo en la planificación. Estas tareas son las siguientes:
• La actualización de datos. • Revisar toda la documentación del proyecto. • El archivo del proyecto.
La finalización del proyecto también implica la realización de las tareas correspondientes para modificar su estado dentro del sistema de activo a cerrado, así como su archivo tanto físico como en la gestión documental que soporta el sistema.
2.4. Fases del desarrollo de Software.
Cuando se habla de fases del desarrollo de software necesariamente tiene que hablarse de ciclo de vida del software, no porque se tenga que explicar el modelo de ciclo de vida, sino porque las fases son cada unas de las etapas que comprenden este ciclo de vida. Hoy en día existe una gran cantidad de modelos
14
Capitulo 2.- Gestión de Proyectos de Software de proceso de desarrollo de software, de entre los cuales se destacan los siguientes:
1. Modelo lineal secuencial. 2. Modelo de prototipos. 3. Modelo de desarrollo rápido de aplicaciones. 4. Modelo incremental. 5. Modelo en espiral. 6. Modelo basado en componentes. 7. Modelo de desarrollo concurrente. 8. Modelo de métodos formales. 9. Modelo de técnicas de cuarta generación.
Los modelos para el desarrollo de software son una forma sistemática de gestionar un proyecto de software, estos permiten dividir un gran proyecto en módulos más pequeños llamados fases, cada una de éstas tiene entradas y salidas que permiten normalizar la manera en que se gestionan los proyectos. Entonces una metodología de desarrollo de software es un conjunto de procesos sistemáticos para idear, implementar y mantener un producto software desde que surge la necesidad de éste, hasta que se cumple el objetivo por el cual fue creado.
De esta forma se puede determinar de manera genérica las fases que involucra el desarrollo de software, tal como se observa en la Figura 2.4. Cada una de estas fases son detalladas por Cantone 6, como sigue:
1. Captura de Requerimientos: Esta fase tiene como objetivo armar el documento de requerimientos de software, en el cual se reflejan los requerimientos y funcionalidades que ofrecerá el sistema a implementar al usuario.
6 Cantone, D., “Implementación y Debugging”, 1ra edición, USERS, 2006, pág. 19.
15
Capitulo 2.- Gestión de Proyectos de Software
Figura 2.5. Fases Genéricas del Desarrollo de Software. Fuente: elaboración propia.
2. Especificación y Análisis : En esta fase se formalizan los requerimientos y se determinan los elementos que interviene n en el sistema a desarrollar, su estructura, r elaciones, funcionalidades, se debe tener una descripción clara de qué producto se va a desarrollar, qu é funcionalidades aportar á y qué comportamiento tendrá.
3. Diseño: En esta fase se determina c ómo se debe desarrollar el sistema, se define en detalle entidades y relaciones de las bases de datos, se selecciona el lenguaje que se utilizar á, el sistema gestor de base de datos, etc.
4. Implementación: En esta fase se empieza a codificar los modelos y estructuras definidos en la etapa anterior, con el correspondiente lenguaje de programación. En muchos proyectos se pasa directamente a esta etapa, son proyectos muy arriesgados que adoptan un modelo de ciclo de vida llamado code & fix, donde se eliminan las etapas de captura, análisis y especificación de requerimientos y diseño, obteniendo como resultado la pérdida de control sobre la gestión del proyecto.
16
Capitulo 2.- Gestión de Proyectos de Software
5. Depuración: Esta fase tiene por objetivo garantizar que el producto software no contenga errores de diseño o codificación. En esta etapa no se desea saber si el software realiza lo que solicitó el usuario, esa tarea corresponde a la fase de implementación, en esta fase se desea encontrar la mayor cantidad de errores.
6. Validación: Esta fase tiene como objetivo la verificación de que el sistema desarrollado cumple con los requerimientos expresados inicialmente por el cliente y que han dado lugar proyecto. En muchos proyectos las etapas de depuración y validación se realizan en paralelo, esto por la estrecha relación que llevan, sin embargo, debido a sus objetivos, no se deberían considerar como una etapa única.
7. Documentación: Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales técnicos, etc., todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.
8. Mantenimiento y Evolución: Esta fase se encarga de las tareas de corrección de errores que surgen a medida que el sistema está en uso, esto es posible debido a que se filtren errores de las fases de depuración y validación. También esta fase se hace cargo de agregar nuevas funcionalidades al sistema que ha pedido el cliente, esto se conoce como evolución del software.
2.5. Éxito y fracaso en los Proyectos de Software.
Si bien es cierto que, un software no tiene ni el éxito ni el fracaso asegurado hasta que no se tenga el producto final entregado y funcionando correcta o incorrectamente, es conveniente y la experiencia lo dice, tomar medidas para
17
Capitulo 2.- Gestión de Proyectos de Software mitigar posibles efectos devastadores que podrían derrumbar el prestigio y tradición de una empresa de desarrollo de software.
Cabe destacar que no existe una receta mágica que lleve al éxito a los gestores de proyectos de software, más bien existen guías o procedimientos o mejor dicho experiencias de exitosos gestores, que recomiendan por lo menos tenerlas en consideración para lograr no el éxito, sino que una muy buena gestión que traiga resultados satisfactorios para el cliente.
2.5.1. Las cinco máximas de satisfacción.
Según Boyd 7 existen cinco máximas de satisfacción en el desarrollo de un producto software y que no dependen ni de la envergadura, ni del alcance, ni de la duración del proyecto de desarrollo. Estas son las siguientes:
• Entregar el producto que el cliente desea o necesita. • Entregar la calidad de manera acorde con el precio. • Entregar el producto en el espacio de tiempo que el cliente desea o necesita. • Entregar el nivel de retroalimentación que el cliente desea. • Contar con un sistema de resolución de conflictos justo para el cliente y el equipo de desarrollo.
Es el gestor entonces quien se encargará de afianzar lazos con los clientes y fortalecer el clima organizacional a modo de fortalecer y/o pavimentar el camino hacia las 5 máximas.
2.5.2. Pasos básicos para lograr una gestión eficiente.
Hoy en día es cada vez más común encontrarse con profesionales prácticamente de todas las áreas, interesados en controlar de forma más eficiente
7 Boyd, A., “The five maxims project satisfaction”, review Aslib Proceedings, año 2001, pág. 423.
18
Capitulo 2.- Gestión de Proyectos de Software las actividades, recursos y productos involucrados en el desarrollo de un proyecto. Sin embargo, muchas veces no es claro por dónde empezar o qué es importante administrar. Según Toledo 8, existen doce pasos básicos esenciales para lograr una administración eficiente:
1. Nunca iniciar sin un objetivo bien definido. 2. Fragmentar el proyecto. 3. Invertir tiempo en la planeación. 4. Involucrar al equipo de trabajo en la planeación y el control. 5. Fomentar la cohesión del equipo de trabajo. 6. Prevenir problemas. 7. Antes de ejecutar, establecer líneas base. 8. Mantener claro el objetivo del proyecto. 9. Establecer un proceso para monitorear y controlar. 10. Atender los puntos críticos primordialmente. 11. Tomarse el tiempo necesario para cerrar el proyecto. 12. Utilizar una metodología para todos los proyectos.
2.5.3. Aspectos críticos que contribuyen al fracaso de proyectos.
Cuando se habla de fracaso siempre se atribuye a una derrota o al incumplimiento de un objetivo y siempre se busca un culpable, que de hecho existe, ya que esa tarea u objetivo tenía asignado un responsable y éste a su vez tiene un sin número de escusas o argumentos, que de cierta manera tratan de justificar lo injustificable. Esta situación se da en todo ámbito y no está ajena al desarrollo de software, son muchos los autores que han identificados aspectos dentro del equipo de desarrollo y su entorno que atentan contra el proyecto y terminan llevándolo al fracaso. Las malas prácticas siempre están presentes en las organizaciones y por mucho que reconocidos gestores de proyectos y profesionales del software se esmeren en construir lineamientos o guías para
8 Toledo, R., “Administre mejor sus proyectos, 12 pasos básicos para el éxito”, http://www.project-am.net/panama/content/view/8/1/ , última consulta diciembre de 2010
19
Capitulo 2.- Gestión de Proyectos de Software evitar el fracaso en el desarrollo, en ocasiones es inevitable que gestores e integrantes del equipo desarrollador incurran en estos.
Según Caballero 9 existen seis aspectos críticos que contribuyen al fracaso de los proyectos de TI:
• Falta de visión clara y establecimiento adecuado de requerimientos. • Expectativas irreales. • Falta de descomposición del proyecto • Políticas inadecuadas de selección del personal y conflictos en el equipo de desarrollo. • Falta de involucramiento y enfoque hacia el cliente. • Falta de enfoque estratégico y apoyo administrativo.
Otro estudio realizado en la web 10 en 2007, recopiló y contrastó las opiniones de autores diferentes, sobre cuáles son las principales causas que hacen fracasar a los proyectos de software. Como se aprecia en la Tabla 2.4 se realizó un cruce simple de la información y se tomó de cada autor las cinco razones que considera más importantes, y finalmente del conjunto las cinco que más se repiten.
Este estudio arrojo como resultado que los cinco aspectos críticos que contribuyen al fracaso de proyectos son:
• Requisitos incompletos / Falta de una visión clara. • Implicación insuficiente de los usuarios. • Expectativas poco realistas. • Falta de soporte ejecutivo / estructura organizativa inapropiada. • Planificación mala o deficiente.
9 Caballero, O., “TIC y herramientas de gestión de proyectos”, Vol. 6, DGSCA-UNAM, año 2006, pág. 6. 10 Navegapolis., “¿Por qué fracasan los proyectos?”, http://www.navegapolis.net/content/view/701/49/ , última consulta diciembre de 2010
20
Capitulo 2.- Gestión de Proyectos de Software
Tabla 2.4. ¿Por qué fallan los proyectos? Fuente: http://www.navegapolis.net/content/view/701/49/
StandishGroup Watts Humphrey S. Focused Perfomance ColeyConsulting CrossTalk DatabaseDesign RamSharma SorayaNeto Requisitos incompletos / Falta de una visión X X X X X X clara Implicación insuficiente de los usuarios X X X X X X Falta de recursos X Expectativas poco realistas X X X X Falta de soporte ejecutivo / estructura X X X X organizativa inapropiada Gestión inadecuada en entornos multi- X proyecto Planificación mala o deficiente X X X X Visión y gestión de un ámbito parcial del X X proyecto Gestión mala o inadecuada de las personas X X Modificación de requisitos / requisitos X X X X crecientes Mala gestión de las modificaciones de X requisitos Personal técnico incompetente o inadecuado X X X Estimación mala o deficiente X
De estos dos estudios presentados con resultados muy similares, se observa claramente la opinión que tienen los expertos en la gestión de proyectos de software, con respecto a cuáles son los factores que influyen o afectan directamente el desarrollo de un producto software.
Tanto los pasos básicos para realizar una buena gestión de proyectos, como los aspectos críticos que provocan fracasos en el proceso de desarrollo, deben de ser contemplados y corregidos, de acuerdo a la forma de trabajar del equipo de desarrollo. De esta manera se busca mejorar el proceso de desarrollo de los proyectos de software, tomando en cuenta las fallas que son habituales.
21
Capitulo 3.- Desempeño del Equipo de Trabajo
Capítulo 3.- Desempeño del Equipo de Trabajo.
3.1. Introducción.
En el capítulo 2 se menciona la importancia que tienen las personas en el desarrollo de un producto software, el como una persona puede influir de manera positiva o negativa ante el resto de los miembros de un equipo de trabajo, y la manera en que estos equipos pueden estructurarse y organizarse.
Sin embargo, para el gestor muchas veces resulta difícil de entender el porqué de ciertas situaciones negativas dentro del equipo de trabajo, que conllevan a no cumplir con los objetivos y metas propuestas en la etapa de planificación, estas situaciones están marcadas por características que son diferentes de las habilidades y capacidades de una persona, algunas de ellas pueden ser: gustos y preferencias, rasgos psicológicos, capacidad de relacionarse, etc. Éstas pueden influir de manera positiva o negativa en el desempeño global del equipo, por tanto, es muy importante para el gestor conocer estas características y/o factores que influyen en el comportamiento del equipo y que afectan directamente el desempeño del mismo.
Por otra parte, es importante que el gestor tenga la capacidad de distinguir o prever el desempeño del equipo, en base a ciertos rasgos característicos del comportamiento de un grupo humano y no sólo en base a capacidades cognitivas y habilidades técnicas y/o de gestión, sobre todo si el equipo está en la etapa de formación, en estos casos nunca esta demás realizar un análisis de interacción del grupo, que permita tomar la mejor decisión a la hora de conformar el equipo de desarrollo.
Mientras se avanza en el ciclo de vida de un proyecto de cualquier índole, ocurren situaciones anómalas que muchas veces ponen en jaque a las personas, debido a que éstas deben tomar decisiones para no perjudicar el correcto andar
22
Capitulo 3.- Desempeño del Equipo de Trabajo del proyecto. En el caso del desarrollo de software, independiente del organigrama que haya adoptado el equipo, los integrantes tendrán que tomar decisiones relacionadas con la manera en que se desarrolla la tarea asignada. Ésta decisión puede tener un impacto positivo o negativo en el desarrollo del proyecto y estará dada por el grado de pertenencia que tenga el decisor con respecto equipo, mientras más cohesionado esté el grupo es más difícil que alguno de sus integrantes tome una decisión errónea que retrase la consecución del objetivo.
3.2. Factores que influyen en el desempeño del equipo de trabajo.
Antes de conformar el equipo de trabajo es importante considerar aquellos factores que podrían influir en el desempeño de un equipo de trabajo. Un antecedente relevante, es que los alumnos han pasado gran parte de su vida desarrollando trabajos grupales, donde en algunos casos los esfuerzos no son equilibrados y lamentablemente unos trabajan más que otros, ahora se enfrentan a la necesidad de trabajar como equipo donde el esfuerzo de cada uno es significativo para el desarrollo del proyecto. En la Figura 3.1 se aprecia la diferencia que existe entre un grupo de trabajo y un equipo de trabajo, en palabras simples la diferencia radica en que según la teoría un equipo de trabajo siempre va a generar una sinergia positiva, en cambio un grupo de trabajo puede generar sinergia positiva y negativa, por las razones mencionadas anteriormente.
Cabe destacar que el objetivo de la asignatura es la conformación de un equipo de trabajo o comúnmente conocido como equipo de desarrollo de software, según la teoría y experiencia de años anteriores, la asignatura desde el punto de vista sistémico, se ha visto integrada por subsistemas de grupos de trabajo o grupos de desarrollo, es decir, la asignatura ha tenido grupos de trabajos con sinergia positiva y negativa a lo largo del tiempo. Ahora si centra la atención en el objetivo de la asignatura, para efectos prácticos, un equipo de desarrollo es un
23
Capitulo 3.- Desempeño del Equipo de Trabajo equipo de trabajo . Bajo esta premisa es importante describir aquellos factores que influyen en el desempeño global de un equipo de desarrollo.
•Un grupo de trabajo es •Un equipo de trabajo genera aquel que interactúa una sinergia positiva por principalmente para medio de un esfuerzo compartir información y coordinado. Sus esfuerzos tomar decisiones, a fin de individuales en conjunto, dan ayudar a cada miembro a como resultado un nivel de desarrollarse dentro de su desempeño mayor que la área de responsabilidad . suma de los aportes individuales. Equipo de Trabajo Equipo de Grupo Trabajo Figura 3.1. Diferencias entre grupo de trabajo y equipo de trabajo. a Fuente: Robbins Stephen. “ Comportamiento Organizacional” . 10 Edición.
3.2.1. Tamaño del equipo.
Según Robbins 11 los mejores equipos de trabajo tienden a ser pequeños, por lo general menos de 10 personas. Cuando tienen más de 10 o 12 miembros, es difícil que puedan realizar mucho trabajo. Aparecen los problemas de interacción y se hace casi nulo el consenso sobre temáticas que conciernen al proyecto y al grupo . Cuando se trata de un gran número de personas , por lo general, no se puede desarrollar la cohesión, el compromiso y la responsabilidad mutua necesaria, para lograr un alto desempeño. De manera que al diseñar equipos eficientes lo ideal es que estos estén compuestos por menos de 12 miembros. Si un ge stor se ve en la necesidad de conformar un equipo con más de 12 miembros y se desea un esfuerzo de equipo, conviene considerar la división del equipo en sub-equipos.
11 Robbins Stephen. “Comporta miento Organizacional”. 10a Edición, Prentice -Hall, 2004, pág. 311 .
24
Capitulo 3.- Desempeño del Equipo de Trabajo
3.2.2. Las habilidades de los miembros.
Para desarrollarse efectivamente, un equipo requiere de tres tipos diferentes de habilidades 12 :
• En primer lugar, necesita personas con experiencia técnica. • En segundo lugar, necesita personas con habilidades para resolver problemas y tomar decisiones, capaces de identificar los problemas, generar alternativas, evaluar estas alternativas, y tomar las soluciones adecuadas. • Por último, los equipos necesitan personas que tengan la capacidad de ser buenos oyentes, proporcionar retroalimentación, solucionar conflictos y otras habilidades interpersonales.
Según lo anterior se entiende que un equipo no logrará alcanzar un desempeño máximo sin contar con los tres tipos de habilidades. Es fundamental que el gestor logre establecer una mezcla equilibrada de las tres, ya que demasiado de una habilidad en desmedro de las otras dará como resultado un desempeño inferior del equipo.
3.2.3. La asignación de roles.
Shakespeare dijo13 : todo el mundo es un escenario y todos los hombres y mujeres son simplemente actores , al igual que esta metáfora los miembros de un equipo de trabajo son actores que deben desempeñar un rol dentro éste, se entiende por rol el conjunto de patrones esperados de comportamiento que se atribuyen a alguien que ocupa una posición determinada en una unidad social. La comprensión del comportamiento se simplificaría si se escogiese el rol y se actuase con regularidad y consistencia.
12 Robbins Stephen. “Comportamiento Organizacional”. 10a Edición, Prentice-Hall, 2004, pág. 312. 13 Robbins Stephen. “Comportamiento Organizacional”. 10a Edición, Prentice-Hall, 2004, pág. 271.
25
Capitulo 3.- Desempeño del Equipo de Trabajo
Uno de los aspectos importantes en la comprensión del comportamiento es darse cuenta del papel que desempeña la persona dentro del equipo, considerando los siguientes aspectos 14 :
• Identificación con el rol: ciertas actitudes y comportamientos reales y consistentes con un rol a desempeñar. • Percepción del rol: visión de un individuo respecto de cómo se supone que actúe en una situación dada. • Expectativas del rol: la manera en cómo otras personas creen, que debería actuar otro rol, en una situación determinada. • Conflicto de roles: el conflicto surge cuando una persona encuentra que el cumplimiento con un papel puede hacer más difícil el cumplimiento con otro, es decir, situaciones donde dos o más expectativas de roles son mutuamente contradictorias.
3.2.4. Tener un compromiso y un propósito común.
“Los equipos eficientes tienen un propósito común y significativo que proporciona dirección, impulso y compromiso a sus miembros”15 , por ejemplo el equipo de desarrollo de Apple Computer, que diseñó la Macintosh, estaba comprometido con la creación de una máquina amigable con el usuario, que vendría a revolucionar la forma en que la gente utilizaba las computadoras.
3.2.5. Establecimiento de metas específicas.
“Los equipos exitosos traducen su propósito común en metas de desempeño realistas, medibles y específicas, las metas llevan a los individuos a un mejor desempeño, también dan energía a los equipos” 16 . Las metas
14 Robbins Stephen. “Comportamiento Organizacional”. 10a Edición, Prentice-Hall, 2004, pág. 271. 15 Robbins Stephen. “Comportamiento Organizacional”. 10a Edición, Prentice-Hall, 2004, pág. 313. 16 Robbins Stephen. “Comportamiento Organizacional”. 10a Edición, Prentice-Hall, 2004, pág. 314.
26
Capitulo 3.- Desempeño del Equipo de Trabajo específicas facilitan una comunicación clara. También ayudan a los equipos a mantenerse enfocados en obtener resultados.
3.2.6. Liderazgo y estructura.
“Los miembros del equipo deben estar de acuerdo en qué es lo que debe hacer cada quien, y asegurarse de que todos los miembros lleven igual carga de trabajo”17 . Además, el equipo necesita determinar la forma en que se fijarán los programas, las habilidades técnicas que necesitan desarrollarse y la forma en que el grupo resolverá los conflictos y tomará y modificará las decisiones. Ponerse de acuerdo sobre los aspectos específicos del trabajo y cómo éstos se ajustan entre sí para integrar habilidades técnicas específicas, requiere de liderazgo y estructura de equipo.
3.3. La cohesión en los equipos de trabajo.
De la experiencia de años anteriores en Ingeniería de Software I, se podría decir que los grupos donde existen diferencias internas y carencia de espíritu de equipo y/o cooperación serían menos eficaces para terminar las tareas que aquellos equipos donde los integrantes generalmente están de acuerdo, cooperan y se agradan unos con otros. Este supuesto encuentra sustento en el concepto de la cohesión, que “es el grado en que los integrantes de un equipo se ven atraídos unos con otros y están motivados para permanecer en él” 18 . La pregunta es ¿Cómo saber si un integrante de un equipo se siente parte de él?, para esto existen algunos factores que permiten determinar si los miembros de un equipo se sienten atraídos unos con otros, es decir permiten mediante un diagnostico simple, evaluar si la cohesión en el equipo puede verse afectada por 19 :
17 Robbins Stephen. “Comportamiento Organizacional”. 10a Edición, Prentice-Hall, 2004, pág. 314. 18 Robbins Stephen. “Comportamiento Organizacional”. 10a Edición, Prentice-Hall, 2004, pág. 290. 19 Robbins Stephen. “Comportamiento Organizacional”. 10a Edición, Prentice-Hall, 2004, pág. 291.
27
Capitulo 3.- Desempeño del Equipo de Trabajo
• El tiempo que pasan juntos influye en la cohesión, ya que cuando las personas pasan más tiempo juntas logran desarrollar la amistad, comienzan a hablar y responder, gesticular e involucrarse con naturalidad en otras interacciones. Estas interacciones llevan al descubrimiento de intereses comunes y a una mayor atracción.
• La severidad de la iniciación o integración de un agente externo al grupo, es un factor que permite medir cuan cohesionado se encuentra éste, puesto que mientras más difícil es ingresar a un grupo, mas cohesión tiene.
• El tamaño del grupo afecta directamente la cohesión de éste, ya que al aumentar el número de integrantes, se vuelve más difícil la interacción de todos sus miembros, en algunos casos se forman subgrupos que tienden a disminuir la cohesión global.
• El sexo de los miembros también influye en la cohesión del equipo. Las mujeres son menos competitivas y/o más cooperativas con las personas que consideran amigos, colegas o miembros del equipo, en cambio los hombres son todo lo contrario, por esto se cree que las mujeres reportan una mayor cohesión que los hombres.
• Las amenazas externas tienden a incrementar la cohesión de un grupo si éste sufre ataques de fuentes externas.
• Los éxitos anteriores son sin duda la carta de presentación de un equipo. Aquel que posea un historial de éxitos, logra una fuerte imagen de unidad, lo que atrae y unifica a sus miembros.
De lo anterior se desprende que la cohesión aumenta cuando los miembros de un equipo:
• Pasan más tiempo juntos. • Pasan por una severa iniciación. • Cuando el grupo es pequeño y predominantemente femenino. • Cuando existen amenazas externas.
28
Capitulo 3.- Desempeño del Equipo de Trabajo
• Cuando el grupo tiene un historial de éxitos anteriores.
Ahora cabe preguntarse ¿es deseable que exista una mayor cohesión en el equipo?, es decir, ¿está relacionada con una mayor productividad? La investigación 20 ha demostrado por lo general que los grupos con alta cohesión son más eficaces que los que no la tienen. Sin embargo, la relación es muy compleja como para afirmar que es buena una alta cohesión, lo que se puede afirmar con seguridad es que una alta cohesión es la causa y resultado de la alta productividad y que esta relación entre ambas esta moderada por las normas de desempeño. Como se aprecia en la Figura 3.2, mientras más cohesión tenga el grupo, mejor seguirán las metas planificadas por los miembros. Si las normas de desempeño planteadas por él gestor son altas (por ejemplo, alto rendimiento, trabajo de calidad, cooperación con personas fuera del grupo), el equipo cohesivo será más productivo que otro con menor cohesión.
Figura 3.2. Relación entre normas, cohesión y productividad. Fuente: Robbins Stephen. “ Comportamiento Organizacional” . 10 a Edición .
Por tanto, el equipo de desarrollo que quisiera lograr una cohesión deseable, debe considerar algunos modelos de calidad del software los cuales incluyen métricas para evaluar diferentes atributos o características del producto así como también del proceso.
20 Robbins Stephen. “Comportamiento Organizacional”. 10a Edición, Prentice-Hall, 2004, pág. 292.
29
Capitulo 3.- Desempeño del Equipo de Trabajo
Los modelos actuales están enfocados a la mejora del proceso, ya que la calidad del producto, comienza desde el inicio del proyecto y el hecho de tener mejores procesos conlleva a un mejor resultado.
Algunos modelos de calidad son:
• Norma ISO 9000-2000. • Norma ISO/IEC TR 15504. • Modelo CMM (Modelo de Capacidad y Madurez). • Modelo SPICE (Mejora de Procesos de Software y capacidad de determinación). • Modelo PROSOFT. • Modelo MOPROSOFT.
3.3.1. La sociometría: Análisis de la interacción de grupos.
Una herramienta que permite predecir patrones de comunicación e interacción es la sociometría, es decir, “trata de encontrar lo que le gusta y disgusta a las personas y con quién desearía trabajar o no”21 . La forma más conocida o utilizada para obtener esta información es por medio de entrevistas o cuestionarios realizados al grupo humano a estudiar. Por ejemplo, se podría preguntar:
• ¿Con que persona del curso le gustaría trabajar en el desarrollo de un proyecto? • Nombre algunas personas del curso con los que a usted le gustaría pasar parte de su tiempo libre.
Se puede utilizar esta información para crear un sociograma, que es una representación gráfica de las interacciones sociales preferidas que se obtienen de
21 Robbins Stephen. “Comportamiento Organizacional”. 10a Edición, Prentice-Hall, 2004, pág. 266.
30
Capitulo 3.- Desempeño del Equipo de Trabajo los cuestionarios o entrevistas. En la Tabla 3.1 se definen algunos términos claves que permiten discutir y analizar un sociograma.
Tabla 3.1. Términos claves para Analizar un sociograma. a Fuente: Robbins Stephen. “ Comportamiento Organizacional” . 10 Edición.
Terminología Descripción
Redes Conjunto específico de vínculos entre un conjunto sociales. definido de individuos. Racimos. Grupos que existen dentro de las redes sociales. Racimos Grupos formales como departamentos, equipos de prescritos. trabajo, fuerzas de trabajo o comités. Racimos Grupos informales, no oficiales. emergentes Coaliciones. Racimos de individuos que se agrupan de manera temporal para alcanzar un propósito específico. Camarillas. Grupos informales relativamente permanentes que involucran amistad. Estrellas. Individuos con el mayor número de vínculos en una red. Enlaces Individuos de una red social que conectan dos o más racimos, pero que no son miembros de ninguno de ellos. Puentes. Individuos en una red social que sirven como vínculos al pertenecer a dos o más racimos. Aislados Individuos que no están conectados a una red social.
La Figura 3.3 representa un ejemplo de un sociograma, de él se obtiene la siguiente información: A es la estrella, G es un aislado y D es un puente. Ahora con esta información se pueden predecir patrones de comunicación, por ejemplo D puede que actúe como conducto de información entre los racimos azul y verde. De
31
Capitulo 3.- Desempeño del Equipo de Trabajo manera similar se puede observar que G es la persona con menos aptitudes sociales dentro del racimo azul y finalmente si se necesitara elegir un responsable de las actividades globales la persona más indicada sería A.
Figura 3.3. Diagrama de Red Social o Sociograma. a Fuente: Robbins Stephen. “ Comportamiento Organizacional” . 10 Edición.
Esta herramienta es muy útil a la hora de conformar equipos de alta competencia, puesto que privilegia las interacciones sociales y determina las relaciones afectivas y de respeto dentro de un grupo humano, de la misma manera permite observar las personas que eventualmente podrían afectar de manera negativa el rendimiento del equipo, debido a su nula interacció n. De esta manera el gestor podría adelantarse a eventuales problemas de comunicación dentro del equipo y llevar a cabo acciones preventivas a favor del equipo. La utilización o no de esta herramienta, dependerá exclusivamente del objetivo que tenga la org anización o el gestor con un determinado proyecto, en general las organizaciones utilizan la sociometría para descubrir eventuales nuevos líderes que influyen en el comportamiento del personal, ya qu e a través de é stos, se podrían alcanzar las metas en los plazos establecidos.
32
Capitulo 3.- Desempeño del Equipo de Trabajo
3.4. La toma de decisiones.
Cuando se trabaja en equipo siempre se pretende que el accionar de éste siga cierto conducto preestablecido por el equipo, como se mencionó en el Capítulo 2 los grupos pueden adoptar su propio sistema de organización, el cual define la manera en que se tomarán las decisiones, sin embargo, suele suceder que los gestores se olvidan de que no sólo ellos toman decisiones con respecto al desarrollo del proyecto, sino que también lo hacen las personas involucradas en el proceso, al ser decisores de sus propias tareas.
La comunicación también juega un rol importante en el proceso de decisión, ya que como se mencionó en la sección anterior si se logra que el equipo alcance la cohesión deseada, los integrantes del equipo tendrán claridad en las metas y podrían dilucidar la mejor solución de su problema en favor del desarrollo global del proyecto. Por tanto, el gestor del proyecto debe prestar atención a estos factores, o más bien centrar su atención en lograr cohesión en el equipo, para de esta manera mejorar implícitamente la comunicación.
De los tres organigramas de equipo presentados en la Figura 2.2 del Capítulo 2, y según la experiencia de los alumnos de ingeniería de software el más utilizado se asemeja a un organigrama Descentralizado Controlado, se asemeja porque la comunicación vertical no es parte del equipo, siempre primó la comunicación horizontal, así como también la estructura formal del equipo compuesto por un jefe definido, el cual controla las tareas asignadas a los integrantes del equipo. Este antecedente es muy importante puesto que permite inferir el comportamiento que tendrán los equipos venideros en la asignatura con respecto a la toma de decisiones.
Existe un fenómeno que afecta la habilidad del equipo para evaluar las alternativas en forma objetiva y llegar a tomar buenas decisiones, este fenómeno es denominado pensamiento de grupo y se relaciona con las normas. Describe
33
Capitulo 3.- Desempeño del Equipo de Trabajo situaciones en que las presiones del grupo para lograr la conformidad de las partes, impiden que el grupo efectúe una evaluación crítica de puntos de vista minoritarios o individuales. El pensamiento de grupo es una enfermedad que ataca a muchos equipos en formación y puede obstaculizar en gran medida su desempeño.
3.4.1. Técnicas para la toma de decisión.
Considerando la teoría decisora de grupos, el equipo de desarrollo forma parte de los grupos interactuantes, que son grupos típicos en que los miembros interactúan unos con otros cara a cara. No obstante la teoría y la práctica concuerdan en que estos grupos frecuentemente caen en el pensamiento de grupo, por lo cual los expertos han propuesto 22 :
• Tormentas de ideas: tienen como propósito vencer las presiones que buscan la conformidad del grupo interactuante y que retrasan el desarrollo de alternativas creativas, utiliza un proceso de generación de ideas que estimula específicamente todas las alternativas, mientras frena cualquier crítica respecto de las mismas.
• Técnica de grupo nominal: en ésta, los miembros se reúnen como grupo y cada miembro presenta una idea al grupo y éstas son anotadas, después de que cada integrante haya dado su idea se procede a discutirlas en busca de claridad, luego cada miembro califica las ideas en forma independiente y se determina la decisión final con la idea que tenga la mayor calificación global.
• Técnica Delphi: en ésta, los miembros proporcionan soluciones potenciales por separado, mediante cuestionarios, luego se agrupan los cuestionarios y los miembros los revisan y dan su opinión, este proceso se realiza de forma sistemática hasta lograr el consenso.
22 Robbins Stephen. “Comportamiento Organizacional”. 10a Edición, Prentice-Hall, 2004, pág. 287.
34
Capitulo 3.- Desempeño del Equipo de Trabajo
• Reuniones electrónicas: en su tiempo se realizaban especies de chat o twitter donde las personas escribían en un computador sus ideas y otros inmediatamente les respondían, hoy es más común ver que los grupos utilizan las video conferencias para la rápida discusión y pronta toma de decisión, en palabras simples las reuniones electrónicas son un híbrido de los grupos nominales y las TIC.
De las técnicas señaladas anteriormente, la que más fomenta el desarrollo de la cohesión del grupo es la tormenta de ideas, donde la solución propuesta tiene una alta orientación al problema, minimizando costos y conflictos al interior del equipo. De igual manera las otras presentan ciertas características por ejemplo la técnica de Delphi reduce al mínimo los conflictos interpersonales y las reuniones electrónicas procesan rápidamente las ideas. Por tanto, la mejor decisión sobre la técnica a utilizar la define el equipo en consenso, fomentando desde un principio (elección de la técnica) la cohesión.
35
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
Capítulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos.
4.1. Introducción.
En el capítulo 3 se mencionan aquellos factores que afectan el desempeño del equipo de desarrollo, se describe la manera en que pueden conformarse equipos de desarrollo de alto desempeño y cómo éstos pueden eventualmente tomar decisiones con respecto al ciclo de vida del proyecto.
Sin embargo, todo lo anterior es teórico y si no se aplica no es del todo valido, por suerte la evolución de las TIC’s ha traído consigo un sin número de beneficios para diferentes áreas, entre ellas la gestión de proyectos, a tal punto llega ésta evolución que las herramientas tecnológicas de gestión de proyectos son verdaderas auditorias en tiempo real, que están constantemente validando el ciclo de vida del proyecto. También se destaca la capacidad de estas herramientas de responder a los cambios que ha sufrido la gestión de proyectos de software y cómo ha logrado dar soporte a las nuevas necesidades de los equipos de desarrollo considerando en un menor o mayor tamaño, algunas de las incidencias mencionadas en el capítulo 3.
Producto de esta evolución han aparecido un sin número de herramientas que vienen a potenciar el desarrollo de un proyecto, bajo el concepto de gestión, algunas de éstas son aplicaciones de escritorio y otras (en su gran mayoría) son aplicaciones diseñadas para funcionar en la WEB. De la misma manera existen las privativas y las de código abierto, estas últimas son el objeto de análisis de este capítulo.
Algo muy importante a tener en cuenta es que a la hora de escoger una herramienta se debe tener presente cuales son las necesidades del equipo y/o organización, ya que la selección de una herramienta sin previo análisis puede traer consigo problemas mayores a los que ya se tienen por no utilizarlas, puesto que las bondades de estas herramientas son muchas y en algunos casos pueden
36
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos llegar a ser mal utilizadas. Por tanto, se requiere del diseño de un modelo que permita ver de manera simple y objetiva al gestor del proyecto de software, las etapas que deberían considerar al momento de querer implementar estas herramientas y cómo a través de éstas se dará soporte a las siempre tediosas y mal realizadas tareas de seguimiento y control.
4.2. Las TIC en la Gestión de Proyectos.
El uso de TIC en la gestión de proyectos no es nueva, desde hace aproximadamente 20 años se utilizan herramientas útiles para ordenar ideas, registrar, consultar y analizar información, las más comunes son: Diagramas Gantt, Ruta crítica, Plan de riesgos, Plan de calidad, etc ., sin embargo, en un comienzo el uso de estas herramientas fue desvirtuado por algunos gestores, quienes por el simple hecho de utilizarlas creían que el éxito de su proyecto de software estaba asegurado, olvidando que su misión como gestores de proyectos era garantizar el seguimiento y control del proyecto por medio de estas herramientas. Sin embargo, esta situación ha cambiado, la evolución que han tenido las TIC a nivel mundial ha llegado a todo ámbito y la gestión de proyectos no escapa de esta realidad, tan grande ha sido la evolución que ha tenido la gestión de proyectos que ya no sólo las herramientas son consideradas un medio para, sino que ahora son consideradas un fin en sí mismas, ya que permiten al gestor llevar a cabo prácticamente todas las actividades de gestión de manera rápida y eficiente. En la actualidad existen un sin número de herramientas que las empresas utilizan de manera formal para la gestión de sus proyectos.
La evolución de las TIC en la gestión de proyectos ha sido fuertemente marcada por algunas tendencias que han nacido dentro de las organizaciones desarrolladoras de software, producto de un aumento en la competitividad de éstas, algunas de estas tendencias son 23 :
• Gestión de portafolios.
23 Caballero, O., “TIC y herramientas de gestión de proyectos”, Vol. 6, DGSCA-UNAM, año 2006, pág. 6.
37
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
• Outsourcing. • El desarrollo a distancia. • Seguimiento y control en los proyectos.
4.2.1. La Gestión de Portafolios.
Un portafolio es una colección de proyectos individuales que necesitan ser gestionados de manera eficiente, para balancear los recursos dentro y a través de éste, para reaccionar efectivamente ante cambios inesperados durante el ciclo de vida de desarrollo. En un portafolio, los proyectos tienen vínculos unos con otros, comparten recursos, información y tecnología, además deben priorizar sus recursos diariamente para la consecución de los objetivos individuales y de la organización. Es por esto que se requiere de herramientas eficientes para gestionar la alineación de proyectos dentro del portafolio, mantener el control y comunicación entre las partes responsables, y gestionar adecuadamente el aprendizaje y el conocimiento obtenido para evitar caer en errores y acelerar el proceso de desarrollo.
4.2.2. Outsourcing.
La evolución de las TIC en la gestión de proyectos han traído consigo un cambio en la manera de pensar de los gestores de proyectos, ya que éstos cada vez más tienden a externalizar, sobre todo cuando se trata de proyectos cortos en los cuales se requiere de personal especializado y contratarlos no es muy conveniente económicamente. La externalización de proyectos de software se debe fundamentalmente a que empresas externas cuentan con:
• Personal especializado que se requiere. • Mayor experiencia en proyectos similares. • Mayor eficiencia en este tipo de proyectos.
38
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
En base a lo anterior se puede decir que las TIC facilitan el proceso de comunicación y colaboración entre las empresas involucradas.
4.2.3. El desarrollo a distancia.
Existen empresas que se enfrentan al reto de coordinar a sus equipos de desarrollo más allá de los límites geográficos de la misma, ante esto se generó la necesidad de contar con herramientas de colaboración diseñadas para la integración de los equipos de desarrollo que se encuentran físicamente apartados. Por medio de herramientas tecnológicas que utilizan la web, ahora es posible lograr esta integración y mantener la comunicación, el seguimiento y el control efectivo entre las partes involucradas.
4.2.4. Seguimiento y control de los proyectos.
Una de las tareas principales que debe llevar a cabo el gestor de un proyecto es el seguimiento y control de éste, con requerimientos cada vez mayores y tiempos de espera menores de parte del cliente, las TIC han brindado un conjunto de herramientas que permiten obtener información fidedigna del estado actual del proyecto, para llevar a cabo acciones preventivas y/o correctivas dependiendo de los datos obtenidos y lograr así disminuir el riesgo asociado al desarrollo del proyecto.
4.3. Modelo de Gestión de Proyectos de Software.
El modelo de gestión de proyectos de software pretende ilustrar como se integra una plataforma tecnológica de apoyo a la gestión de proyectos de software, con un determinado modelo de desarrollo de software, la idea central es verificar gráficamente como se coordina de manera eficiente el seguimiento y el control durante el ciclo de vida del proyecto.
39
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
La Figura 4.1 resume lo que se ha realizado hasta ahora e ilustra la manera en que se integra la plataforma a seleccionar con un modelo de desarrollo cualquiera. Además la Figura 4.1 permite observar que tanto el seguimiento y control representan un flujo de datos (flecha lila hacia la plataforma) e información (flecha lila hacia la gestión del proyecto), queda claro que tanto el seguimiento y control hacia la gestión del proyecto de software, dependerá de los datos almacenados en la plataforma por el equipo de desarrollo y que en base a esos datos se generara información que permitirá realizar las tareas de control necesarias para corregir cualquier acción anómala, que ponga en riesgo el curso normal del proyecto de desarrollo.
Figura 4.1. Modelo de Selección-Integración Plataforma de Gestión.
Fuente: Elaboración Propia.
40
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
Cabe recordar que la utilización de la plataforma tiende a minimizar los riesgos que tiene el desarrollo del producto software en la asignatura de Ingeniería de Software, dados por la poca madurez de trabajo en equipo, lo que hace prácticamente nulo el seguimiento y el control al interior del equipo de desarrollo. La Figura 4.2 ilustra gráficamente lo que ocurre al desarrollar un software sin la plataforma de gestión seleccionada, se puede ver que las tareas de control se realizan verificando manualmente si se cumplió o no, con lo planificado.
Figura 4.2. Desarrollo de Software sin Plataforma de Gestión.
Fuente: Elaboración Propia .
Para que la etapa de implementación del modelo presentado en la Figura 4.1 sea eficiente, la plataforma a seleccionar debe tener medios de feedback continuos y rápidos, que permitan de manera directa llevar a cabo acciones correctivas en el caso que sea necesario para no poner en riesgo la ejecución del proyecto.
De la experiencia de años anteriores se identifican ciertas actividades que son críticas para el seguimiento y el control al interior del equipo de desarrollo:
• Gestión de tareas y dependencias. o Seguimiento y Control de las tareas por responsable. o Seguimiento de las dependencias de las tareas.
• Gestión de horarios y cargas de trabajo.
41
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
o Control de los tiempos de las tareas. o Seguimiento de las horas trabajadas.
• Gestión documental. o Control de los ficheros programables y entregables. o Depuración y validación de ficheros en tiempo real. o Seguimiento del progreso global de: La documentación. La implementación.
En base a lo anterior se logra identificar cuatro componentes básicos de estas plataformas, que dan soporte a las actividades críticas mencionadas anteriormente:
• Colaborativo: que permita a los integrantes del equipo trabajar de manera eficiente y controlada, sin la necesidad de tener que juntarse, ya que pueden trabajar de manera conjunta a través de internet.
• Programación de tareas: que permita al equipo tener un autocontrol de las tareas más críticas, que identifiquen la interacción entre estas y fechas límites para terminar las mismas.
• Gestión de recursos: que permita la asignación de tareas a los integrantes del equipo y la distribución equitativa de los tiempos de trabajo.
• Seguimiento: que sea capaz de generar información en tiempo real, permitiendo realizar seguimiento y control a través de mecanismos de evaluación, ya sea mediante métricas del equipo y/o indicadores de la organización.
La Figura 4.3 representa como las actividades críticas mencionadas anteriormente, se ven favorecidas por la implementación de una plataforma
42
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos tecnológica de gestión de proyectos que integra al menos los cuatro componentes básicos mencionados anteriormente.
Figura 4.3. Desarrollo de Software con Plataforma de Gestión
Fuente: Elaboración Propia.
Con los componentes básicos que debe tener la plataforma de gestión de proyectos ya definidos y entendiéndose como será la integración entre la plataforma y el modelo de desarrollo adoptado por el equipo, solo falta seleccionar la herramienta más adecuada de entre las tantas que existen, como se verá en la siguiente sección.
4.4. Herramientas Tecnológicas de apoyo a la Gestión de Proyectos.
Como se mencionó en la sección 4.2, tal es la evolución que ha tenido la gestión de proyectos que ha traído consigo un sin número de herramientas que vienen a facilitar las tareas de gestión, ya que dan soporte a cada una de las
43
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos etapas que comprende un proyecto. “El software de gestión de proyectos, es un término que cubre muchos tipos de software, incluso programación, asignación de recursos, software de colaboración, comunicación y sistemas de documentación, que están acostumbrados al trato con la complejidad de proyectos grandes”24 .
De manera genérica se puede decir que estas plataformas cubren principalmente las siguientes necesidades:
• Soporte a la Planeación. • Gestión de Cronogramas y Calendarios. • Gestión del Conocimiento. • Entorno Colaborativo. • Control de Tiempos. • Control de Costos. • Control de Facturación. • Gestión de Portafolio de Proyectos. • Generación de Informes. • Cuadro de Mando.
Además las expectativas que los gestores tienen frente a estas plataformas no son menores, puesto que las características esperadas de estas son:
• Poco Mantenimiento • Gran Soporte • Control de Acceso • Seguridad de la Información • Fácil Instalación y Administración • Facilidad de uso • Licenciamiento • Personalización • Integración
24 Caballero, O., “TIC y herramientas de gestión de proyectos”, Vol. 6, DGSCA-UNAM, año 2006, pág. 10.
44
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
A continuación se describen algunas de las herramientas tecnológicas Open Source de apoyo a la gestión de proyectos que permiten gestionar el alcance, la programación de tareas, el seguimiento y control de proyectos a través de la web. Éstas son:
• Dotproject: Plataforma web que ofrece un marco completo para la planificación, gestión y seguimiento de múltiples proyectos para clientes diferentes, quienes pueden disponer también de acceso para monitorizar la evolución del desarrollo.
• TeamWork: Herramienta de entorno web que permite registrar y gestionar los tiempos de diferentes equipos de trabajo en sus respectivos proyectos. Gestión completa de informes de tiempos y costos. Combina gestión de documentos, de equipos y de proyectos.
• Phprojekt: es una completa plataforma para la gestión de proyectos permite la coordinación de actividades grupales e individuales, y además compartir información y documentos vía Intranet e Internet .
• Egroupware: es una completa herramienta colaborativa o groupware, que integra el trabajo en un solo proyecto con muchos usuarios concurrentes que se encuentran en varias estaciones de trabajo, conectadas a través de una red (internet o intranet).
• Trac: Plataforma web que permite la comunicación, gestión y seguimiento de proyectos, que integra un wiki, interfaz de subversión para la gestión de versiones, seguimiento de proyecto y sistema de tickets para gestionar y registrar tareas, bugs, etc.
• TUTOS: Herramienta web para la gestión de pequeños grupos de trabajo o departamentos. Incluye calendario, gestión de equipos, directorio de personas, gestión de incidencias, registros de tiempo, listas de seguimiento, etc.
45
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
• Mindquarry: Sistema basado en web para la gestión de grupos de trabajo, entornos colaborativos y proyectos. Mindquarry quiere ser la alternativa Opensource de soluciones propietarias como Basecamp o Sharepoint .
• Project2Manage: Basado en web, con funcionalidades simples pero que pueden ser suficientes para el registro y la comunicación de actividades entre los miembros de un equipo de trabajo.
• Collabtive: Es una completa plataforma para gestión de proyectos y colaboración de equipos de trabajo.
• RedMine: Sistema multi-plataforma, programado con Ruby on Rails, posee unas funcionalidades asombrosas para gestión de proyectos.
• IceScrum: Puede ser la mejor opción, en equipos distribuidos, o como herramienta de registro y respaldo en la intranet de la oficina.
• Feng Office: Sistema web para gestión de equipos de trabajo. Desde el área de administración se pueden ajustar los permisos de cada usuario, de forma individual o por grupos, y para cada área de trabajo, incluso para que no resulte visible.
Y otras herramientas como: Project Dune, XPWeb, Solodox, Google Sites, Clocking IT, Pivotal Tracker, WebCollab, AgileTrack, PPTS, Endeavour Software Project Management, Feng Office Community Edition, KForge, Launchpad, MantisBT, phpGroupWare, Project-Open y Project.net.
Cabe destacar que por muy potente que sea la plataforma de gestión de proyecto, de nada servirá, si el equipo de desarrollo no la utiliza adecuadamente, es por esto que de las 29 plataformas web presentadas, se han seleccionado 12 en base a los siguientes criterios:
• Primero : que sean genéricas, es decir que puedan soportar cualquier modelo de desarrollo de software.
46
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
• Segundo: que presenten características de diseño, que disminuyan de manera subjetiva, la resistencia al uso de la herramienta.
La Tabla 4.1 muestra las plataformas seleccionadas preliminarmente en base a los criterios ya mencionados.
Tabla 4.1. Plataformas seleccionadas preliminarmente. Fuente: Elaboración Propia.
Genérico Interfaz Facilidad de Multilenguaje Amigable Uso Clocking IT
Collabtive
Dotproject
eGroupWare
phpGroupWare
Phprojekt
Pivotal Tracker
Project.net
Project2Manage
Project -Open
RedMine
WebCollab
4.5. Selección de la herramienta más adecuada.
Como se aprecia en la sección anterior, existe gran variedad de plataformas Open Source para la gestión de proyectos, se puede decir que el principal problema no es encontrar la plataforma, sino identificar cuál es la que mejor plataforma que se adapta a l as necesidades del taller de Ingeniería de Software (Anexo A). Como se puede apreciar en la sección anterior algunas de estas herramientas cubren diferentes necesidades funcionales: gestión de tareas y actividades, gestión de recursos, calendarios, gestió n documental, administración de portafolios, gestión de riesgos, etc.
47
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
Como se mencion ó en la sección 4.3 e n la asignatura en estudio se requiere principalmente que la plataforma incluya o permita tener:
• Entorno Colaborativo. • Programación de tareas . • Gestión de recursos . • Realizar Seguimiento .
La Tabla 4.2 muestra la clasificación de las plataformas en base a las características descritas anteriormente.
Tabla 4.2. Selección de la Plataforma.
Fuente: Elaboración Propia.
Programación Gestión de Colaborativo Seguimiento de Tareas Recursos Clocking IT
Collabtive
Dotproject
eGroupWare
phpGroupWare
Phprojekt
Pivotal Tracker
Project.net
Project2Manage
Project -Open
RedMine
WebCollab
Este análisis arroja como resultado que existen seis plataformas tecnológicas que cubren las necesidades de la asignatura:
1. Clocking IT 2. Collabtive 3. Phprojekt 4. Project-Open
48
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
5. RedMine 6. WebCollab
La elección de la plataforma a implementar, deberá considerar criterios que sean adecuados para su futura implantación y adecuación al caso práctico que se desarrolla en la asignatura en estudio (ver Anexo A). Los criterios que se evaluarán se describen a continuación.
1. Facilidad de instalación: siempre es deseable que cualquier producto software sea fácil de instalar, es decir que no presente mayores inconvenientes para quedar operativo sobre algún entorno. La importancia que tiene este criterio es de un 15% y está dividido en tres subcriterios:
• Plataforma completa, sin descarga adicional: se refiere básicamente que al momento de querer dejar operativo el producto software no se requiera de la instalación de algún paquete adicional, éste subcriterio tiene un peso de 30%. La Tabla 4.3 lista la escala de notas junto con su significado.
Tabla 4.3. Escala de notas-Plataforma Completa.
Fuente: Elaboración Propia. Notas Significado 1 Si la plataforma se instala a partir de un conjunto de paquetes. 4 Si la plataforma se instala con dos paquetes para quedar operativa. 7 Si la plataforma se instala con un solo paquete.
• Se integra con facilidad al servidor local: se refiere básicamente a que el producto software esta desarrollado considerando los requerimientos mínimos para operar en un servidor web, es decir que no requiera la actualización de algún paquete presente en el servidor
49
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
web que eventualmente alteraría el correcto funcionamiento de éste. El subcriterio tiene un peso de 30%. La Tabla 4.4 lista la escala de notas junto con su significado.
Tabla 4.4. Escala de notas-Integración con servidor.
Fuente: Elaboración Propia. Notas Significado 1 Actualización de la distribución. 2 Instalación de nuevos paquetes y edición de ficheros de configuración. 3 Requiere de a lo mas cuatro actualizaciones y edición de ficheros de configuración. 4 Requiere de a lo mas tres actualizaciones y edición de ficheros de configuración. 5 Requiere de a lo mas dos actualizaciones y edición de ficheros de configuración. 6 Requiere de una actualización y/o edición de ficheros de configuración. 7 No requiere de actualización alguna, ni edición de ficheros.
• Configuración: atributo básico de la facilidad de instalación es la configuración, ya que ésta debe ser fácil de llevar a cabo y debe ser intuitiva, lo que permita que una persona con conocimientos básicos de computación, logre llevar a cabo la instalación sin mayor problema. Éste subcriterio tiene un peso de 40%. La Tabla 4.5 lista la escala de notas junto con su significado.
Tabla 4.5. Escala de notas-Configuración.
Fuente: Elaboración Propia. Notas Significado 1 Se requiere de un experto para llevar a cabo la configuración. 4 La configuración requiere del ingreso de a lo más doce atributos (usuario servidor, password servidor, etc...) continúa página siguiente… 50
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
5 La configuración requiere del ingreso de a lo más diez atributos. 6 La configuración requiere del ingreso de a lo más ocho atributos. 7 La configuración requiere del ingreso de a lo más seis atributos.
2. Soporte al usuario: es fundamental para todo producto software contar con información idónea para su producto, la cual incluya la solución de los potenciales problemas que el usuario pudiese tener al momento del administrar el producto software. La ponderación de este criterio es de un 30% y está dividido en cuatro subcriterios:
• Documentación en el sitio WEB del producto: algo muy básico pero que en algunas ocasiones nos sorprende es la documentación asociada al producto software en la web del proveedor, este subcriterio tiene un peso de 25%. La Tabla 4.6 lista la escala de notas junto con su significado.
Tabla 4.6. Escala de notas-Documentación en el sitio WEB.
Fuente: Elaboración Propia. Notas Significado 1 No existe documentación asociada al producto en la web del fabricante. 4 Existe solo documentación de usuario y ninguna información técnica. 7 Toda la documentación asociada al producto.
• Documentos oficiales en español: como el producto software es multilenguaje es prácticamente una obligación, tener a disposición de sus clientes documentación oficial en su sitio web en los diferentes idiomas que soporta el producto. Este subcriterio tiene una ponderación de 25%. La Tabla 4.7 lista la escala de notas junto con su significado.
51
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
Tabla 4.7. Escala de notas-Documentos oficiales en español.
Fuente: Elaboración Propia. Notas Significado 1 No existe documentación en español en la web del fabricante. 4 Existe solo documentación en español, en foros oficiales e información parcial por parte del fabricante. 7 Toda la documentación oficial, está en español.
• Manual de instalación: todo paquete instalador de un producto software debe contener entre sus archivos un manual de instalación, para facilitar dicho proceso. Este subcriterio tiene una ponderación de 25%. La Tabla 4.8 lista la escala de notas junto con su significado.
Tabla 4.8. Escala de notas-Manual de Instalación-Usuario.
Fuente: Elaboración Propia. Notas Significado 1 No tiene un manual. 4 Existe solo en foros oficiales y fue hecho por usuarios. 7 Contiene un manual.
• Manual de Usuario: un producto software que no incluya un manual de usuario es difícilmente un producto terminado. Este subcriterio tiene una ponderación de 25%. La Tabla 4.8 lista la escala de notas junto con su significado.
3. Facilidad de uso: cuando se habla de facilidad de uso se refiere básicamente a que la aplicación no presente mayores inconvenientes al momento de usarse. Éste criterio tiene una ponderación de un 30% y está dividido en tres subcriterios 25 :
25 Pressman, R., “Ingeniería del Software, un enfoque practico”, 5ta edición, McGraw-Hill, 2002, pág. 324.
52
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
• Usabilidad: tiene que ver con cuán fácil es aprender a usar el sistema. Este subcriterio tiene una ponderación de 30%. La Tabla 4.9 lista la escala de notas junto con su significado.
Tabla 4.9. Escala de notas-Usabilidad.
Fuente: Elaboración Propia . Notas Significado 1 Necesita Capacitación. 3 Necesita asistencia personalizada y presencial. 5 Necesita asistencia web y/o telefónica. 7 No necesita asistencia alguna.
• Operatividad: tiene que ver netamente con la operación del producto software, es decir la facilidad con la que puede ser operado el sistema. Este subcriterio tiene una ponderación de 40%. La Tabla 4.10 lista la escala de notas junto con su significado.
Tabla 4.10. Escala de notas-Operatividad.
Fuente: Elaboración Propia. Notas Significado 1 El sistema es inestable. 4 Existen módulos inestables. 7 No presenta problemas de operatividad.
• Simplicidad: se refiere a que tan fácil es por medio de la abstracción comprender cómo opera el sistema. Este subcriterio tiene una ponderación de 30%. La Tabla 4.11 lista la escala de notas junto con su significado.
53
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
Tabla 4.11. Escala de notas-Simplicidad.
Fuente: Elaboración Propia. Notas Significado 1 No se entiende el sistema, la lectura del manual no mejora el entendimiento. 3 No se entienden algunos módulos, la lectura del manual no mejora el entendimiento. 5 Es necesario leer el manual para entender. 7 Es fácil de entender.
4. Funcionalidad: se refiere básicamente a que el producto software sea capaz de realizar sus funciones tal cual como fueron definidas con el cliente o como fueron descritas por el proveedor. La ponderación de este criterio es de un 25% y está dividido en tres subcriterios 26:
• Adecuación: tiene que ver con la facilidad que se puede modificar o editar el entorno. Este subcriterio tiene una ponderación de 30%. La Tabla 4.12 lista la escala de notas junto con su significado.
Tabla 4.12. Escala de notas-Adecuación.
Fuente: Elaboración Propia. Notas Significado 1 No se puede modificar. 3 Modificación a través de código web. 5 Modificación solo de algunos módulos. 7 Permite modificación completa del sistema.
• Fiabilidad: tiene que ver con las expectativas generadas por el producto software, es decir hasta donde se puede esperar que el producto lleve a cabo la función con la exactitud requerida. Este subcriterio tiene una ponderación de 40%. La Tabla 4.13 lista la escala de notas junto con su significado.
26 Pressman, R., “Ingeniería del Software, un enfoque practico”, 5ta edición, McGraw-Hill, 2002, pág. 325.
54
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
Tabla 4.13. Escala de notas-Fiabilidad.
Fuente: Elaboración Propia. Notas Significado 1 No realiza las operaciones. 4 La operación se lleva a cabo, pero el sistema queda inestable. 7 Realiza correctamente la operación.
• Seguridad: tiene que ver básicamente con que el producto software cuente con los mecanismos necesarios para la protección de la información almacenada. Este subcriterio tiene una ponderación de
30%. La Tabla 4.14 lista la escala de notas junto con su significado.
Tabla 4.14. Escala de notas-Seguridad.
Fuente: Elaboración Propia. Notas Significado 1 No brinda protección. 7 La información está protegida.
La Tabla 4.15 muestra el resultado de la evaluación a la cual fueron sometidas las seis plataformas seleccionadas. Resultado que arrojó como ganadora a la plataforma de gestión de proyectos Collabtive.
Cabe destacar que Collabtive resultó ser la mejor evaluada, puesto que es una de las más modernas, y con ello lógicamente trae muchas mejoras a los problemas presentes aún, en otras plataformas evaluadas, sobre todo en lo que respecta a la facilidad de uso y la funcionalidad.
Por otra parte cada uno de los ítems evaluados en esta sección han sido cuidadosamente seleccionados, con el fin de brindar una selección de nivel, para garantizar el correcto funcionamiento de la plataforma tecnológica.
55
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
Tabla 4.15. Evaluación de las Plataformas.
Fuente: Elaboración Propia.
4.6. Metodología de Trabajo.
Para llevar a cabo la gestión del trabajo se utilizo como referencia la metodología de gestión de proyectos denominada Scrum, que es una metodología para gestionar proyectos de software, que toma su nombre y principios de los estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los años ochenta (Ikujiro & Takeuchi, 1986).
Aunque surgió como práctica en el desarrollo de productos tecnológicos, resulta válido en los entornos que trabajan con requisitos inestables, y necesitan rapidez y flexibilidad, es decir, situaciones habituales que se dan en el desarrollo de algunos productos software.
56
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos
Los elementos básicos de Scrum son:
• Una lista con las funcionalidades de la aplicación, ordenadas de mayor a menor importancia. Esta lista se llama product backlog. No hace falta que esta lista contenga todas las funcionalidades inicialmente. • De la lista anterior, se toman las primeras funcionalidades, se descomponen en tareas y son anotadas en una lista que se llama sprint backlog. Estas tareas serán realizadas en el siguiente mes.
Además de estos elementos existen ciertas reglas básicas que deben seguirse:
• Una vez que se pasan las tareas más prioritarias del product backlog al sprint backlog, estas no se pueden cambiar, esto quiere decir, que el trabajo de un mes queda fijado. Esta es la regla más importante de todas. • Al final del mes, este periodo se le llama Sprint, se tiene que tener un ejecutable con las funcionalidades del sprint backlog. • Todo el mundo puede añadir funcionalidades al product Backlog, pero sólo una persona puede ordenarlo. A esta persona se le denomina product owner. Es el responsable del producto final. • Cada día se hace una reunión de menos de 15 minutos, en la que se reúne todo el equipo: ingenieros y gestor (llamado scrum master) en la que cada miembro del equipo expone sólo los siguientes temas: o ¿Qué es lo que se hizo el día anterior? o ¿Qué es lo que se va a hacer hoy? o ¿Qué impedimentos tengo para realizar mi trabajo? • Al final del mes, es decir, al final del Sprint, se presenta el producto y se toma del product backlog ordenado las funcionalidades para cubrir en el siguiente mes.
La duración del Sprint se puede modificar. Hay gestores que prefieren sprints más largos al comienzo, mes y medio o dos meses, ya que al principio cuesta más obtener un ejecutable y al final sprints más cortos, una semana o dos,
57
Capitulo 4.- Plataformas Tecnológicas de Apoyo a la Gestión de Proyectos cuando se está en la fase final de refinamiento. Pero básicamente el proceso es el mismo de principio a fin.
4.7. Observaciones Generales.
A través de este capítulo se pudo apreciar la diversa variedad de plataformas disponibles para la gestión de proyectos, sin embargo la selección de la más adecuada debe responder a ciertos atributos o características que son únicas para cada caso. El modelo presentado en la sección 4.3 ejemplifica la manera en que se llevará a cabo el seguimiento y control. En el siguiente capítulo serán analizados los mecanismos más adecuados para llevar a cabo el seguimiento y control de la plataforma.
58
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
Capítulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión.
5.1. Introducción.
Una vez que la plataforma de gestión de proyectos esta operativa, se empieza a generar una gran cantidad de datos que se encuentran almacenados en la base de datos de ésta. De la teoría de algunos tópicos de base de datos, se sabe que en estos datos existe gran cantidad de información que está esperando por ser descubierta y a través de la cual poder tomar decisiones.
Para llevar a cabo dicho descubrimiento, es necesario conocer primero lo que se desea seguir y controlar, es decir generar una necesidad la cual pueda ser expresada en razón de algunos datos, para los cuales la plataforma genere en tiempo real valores cuantitativos para dichos datos y poder tomar decisiones respecto al resultado obtenido. Para ello entonces se debe definir cuál es el mecanismo de evaluación más adecuado para realizar seguimiento y control del uso de la plataforma.
Por otra parte se debe comprender las diferencias entre una métrica y un indicador, para ver cuál de las dos se ajusta mejor a lo que se desea medir y finalmente definir el conjunto de mecanismos de evaluación que permitirán realizar seguimiento y control en la plataforma.
5.2. Mecanismos de evaluación.
Una de las actividades más complejas para cualquier profesional, es la creación de un mecanismo de evaluación, puesto que debe primero existir la necesidad de medir algo y a partir de ello, diseñar un mecanismo tal que sea capaz de reflejar dicha necesidad en datos cuantificables.
59
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
Se sabe que la plataforma almacena información en su base de datos, lo cual nos permite aseverar, que existe un conjunto de datos a partir de los cuales se puede obtener información, o dicho de otra forma existe una fuente de datos confiable, que permitirá alimentar el mecanismo de control.
Como la ingeniería es por naturaleza una disciplina cuantitativa, es fácil entonces asimilar el concepto de métrica, según Fenton 27 una métrica es la correspondencia de un dominio empírico (mundo real) a un mundo formal, matemático. La medida incluye al valor numérico o nominal asignado al atributo de un ente por medio de dicha correspondencia. La Figura 5.1 ejemplifica lo descrito anteriormente. Según la ISO 14598-1:1999 una métrica es un método de medición con escala de medición definida.
Mundo Real Sistema Numérico
M
75 70
Hombre más alto que mujer M ( hombre ) > M ( mujer ) Relación Empírica preservada bajo M como Relación Numérica.
Figura 5.1 Concepto de Métrica. Fuente: Elaboración Propia.
Lamentablemente las métricas por si solas no pueden representar un concepto medible. Según la ISO- 15939 se entiende por concepto medible una relación abstracta entre atributos de una o más entidades, a partir de una
27 Fenton, N, “Software Metrics: a Rigorous and Practical Approach”, 2da edición, PWS PublishingCompany, 1997, pág. 167.
60
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión necesidad de información. Ejemplos de concepto medible son: calidad, costo, accesibilidad, calidad de uso, confiabilidad, etc.
En base a esta falencia que presentan las métricas, surge la necesidad de analizar un concepto mucho más amplio, los indicadores . En palabras simples un indicador es un método de cálculo con escala definida, posee una estructura propia la que incluye criterios de decisión con el fin de proveer una evaluación o estimación de un concepto medible con respecto a una necesidad de información.
De lo anterior se concluye que un indicador es el mecanismo ideal para realizar seguimiento y control al uso de la plataforma de gestión de proyectos.
Ahora solo queda definir la necesidad, es decir lo que se desea medir, para éste trabajo de título se desea medir el correcto uso de los componentes básicos con los cuales fue seleccionada la plataforma de gestión de proyectos de software.
5.2.1. Necesidad de información.
Como se menciona en la sección anterior debe existir una necesidad de información, a continuación se listan las necesidades de información asociados a los indicadores:
• Medir el uso de la plataforma en la gestión del proyecto de software.
• Medir el grado de “correcta” utilización del módulo de comunicación instantánea.
• Determinar el porcentaje de participación activa en el desarrollo de las actividades.
• Verificar el número de tareas que se concluyen por semana.
• Verificar si el módulo “mensajes” es un aporte real a la gestión del proyecto.
61
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
• Verificar si el módulo “archivos” es un aporte real a la gestión del proyecto.
Antes de transformar la necesidad de información en un concepto medible, se debe decidir el tipo de indicador que se utilizara para realizar seguimiento y control al uso de la plataforma de gestión de proyectos.
5.2.2. Selección del indicador.
Si se analiza el trasfondo de cada una de las necesidades listadas en la sección anterior, se puede ver que lo que se desea medir es el trabajo realizado sobre la plataforma, es decir se quiere verificar la correcta utilización de la plataforma de gestión de proyectos, en base a una meta previamente establecida. Por tanto, solo queda decidir qué tipo de indicador es el que más se ajusta a esta necesidad.
De la investigación exploratoria realizada se puede ver que existe una gran cantidad de indicadores, cada uno definido para un uso en particular. A continuación se presenta la Tabla 5.1, la cual contiene una lista con una serie de indicadores que fueron analizados y comparados con nuestra necesidad de medición.
Tabla 5.1. Indicadores y su objeto Fuente: Elaboración propia. Indicadores Objetivo de Indicar el grado de cumplimiento de tareas. Cumplimiento de Evaluación Identificar fortalezas, debilidades y oportunidades de mejora. de Eficiencia Indican el tiempo invertido en la consecución de tareas.
de Eficacia Indican capacidad o acierto en la consecución de tareas y/o trabajos. de Gestión Comparar el escenario obtenido con las metas u objetivos organizacionales.
62
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
KPI o Clave de Medir el desempeño de un proceso, comparando el Rendimiento estado actual v/s la meta buscada
De la Tabla 5.1 se concluye que el indicador que más se ajusta a lo que se desea medir es el indicador clave de rendimiento o KPI. Un KPI básicamente permite al gestor del proyecto responder interrogantes del tipo: ¿Dónde estamos?, ¿Cómo vamos?, en base a indicadores, que permiten identificar aquellas variables que inciden en el rendimiento de lo planificado. Estos son definidos para medir el progreso de diversas actividades en función de metas previamente establecidas y poder así tomar cursos de acción en el caso de que sea necesario. Otra de las características y la más importante es que permiten medir en tiempo real.
5.3. Determinación de Indicadores Clave de Rendimiento (KPI’s).
Un KPI debe tener ciertas características, según Wayne Eckerson, al momento de definir un KPI se deben considerar diez características básicas, las cuales se describen a continuación 28 :
1. Un KPI refleja guías estratégicas de valor: Los indicadores de valor mueven la organización en la dirección correcta, para alcanzar sus metas financieras y organizacionales previamente establecidas. Un ejemplo de esto, podría ser "alta satisfacción del cliente" o "Excelente calidad del producto."
2. Un KPI está definido por los Ejecutivos: Los "Ejecutivos" definen los indicadores de valor en las sesiones de planeamiento que determina la dirección estratégica en el corto y largo plazo de la organización. Para obtener lo mejor de estos indicadores de valor, los ejecutivos necesitan definir cómo desean medir el funcionamiento de sus organizaciones contra estos indicadores.
28 Eckerson, W., “Diez características básicas de un buen KPI” http://www.gi.com.do/pdf/kpi.pdf , última consulta diciembre de 2010.
63
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
3. La cascada de los KPI a través de la Organización: los indicadores de valor y KPI de cada grupo están atados a los niveles superiores, y así sucesivamente hasta el nivel del CEO. Es decir, todo el KPI se basa en una cascada a través de una organización. De esta manera, los datos capturados por el KPI del nivel inferior ruedan verticalmente a todo lo ancho de los KPI’s corporativos.
4. Los KPI están basados en estándares corporativos: Es sumamente necesario que los KPI’s se estandaricen, para así poder realizar benchmarking.
5. Los KPI’s están basados en datos validos: La mayoría de las industrias tienen ya un sistema común de métrica para el éxito futuro que prevén evaluar. Desafortunadamente, saber que medir y realmente hacer la medición. Por ende, la validez de los datos es fundamental, para realizar mediciones validas.
6. Un KPI debe ser fácil de entender: el KPI debe ser comprensible. Los empleados deben saber que se está midiendo; cómo se está calculando, y lo más importante, qué él debe hacer (y no debe hacer) para afectar positivamente el KPI.
7. Los KPI’s son siempre relevantes: Para asegurarse continuamente del óptimo funcionamiento del KPI se necesita revisar periódicamente el KPI para determinar su uso e importancia. Si un KPI no se está observando, probablemente debe ser desechado o ser revisado. En la mayoría de los casos, el KPI tiene un ciclo de vida natural.
8. Un KPI proporciona el contexto: La métrica siempre muestra un número que refleja el funcionamiento. Pero un KPI pone este funcionamiento en contexto. Evalúa el desempeño acorde las expectativas. Se proporciona el contexto usando: los umbrales (es decir, rangos superiores y más bajos de funcionamiento aceptable), o los blancos (es decir, ganancias predefinidas, tales como, ganar 10% más
64
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
de clientes en cada cuarto de año) o los patrones del sector, que se pueden basar en medidas de la industria en general o varias metodologías, tales como, Six - Sigma.
9. Un KPI otorga poder al usuario: Para ser eficaz, el KPI se debe reforzar con incentivos. Casi el 49% de las organizaciones examinadas por TDWI, dijeron haber reestructurado sus sistemas de incentivos al poner un KPI en ejecución. Sin embargo, es importante no ligar incentivos al KPI hasta tanto el KPI sea revisado completamente. A menudo, un KPI debe ser afinado o modificado antes de obtener el efecto deseado.
10. Un KPI carga la acción positiva: Finalmente, un KPI debe generar una acción mejorada del funcionamiento previsto. Desafortunadamente, muchas organizaciones permiten que los grupos creen KPI en aislamiento. Esto conduce a KPI’s que se minan unos a otros.
De lo anterior se desprende que mientras una organización tenga cientos de métricas, debería solamente tener alguna docena de KPI’s que se centren en las actividades dominantes que aportan la mayoría del valor a la organización. Además se puede agregar que los KPI tienen un alto impacto comunicacional, puesto que permiten a los ejecutivos superiores comunicar la misión y el foco de la organización y afianzar la atención de los empleados.
De esta manera entonces, la determinación de los indicadores clave de rendimiento es una tarea que depende en gran parte de la experticia del evaluador, puesto que se deben definir valores objetivos, de aceptación y esperados, basados en experiencias pasadas, por tanto los valores que se han definido para los KPI’s, han sido validados por el académico a cargo de las asignaturas de Ingeniería de Software I y II.
65
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
A continuación se presentarán los KPI’s que se utilizarán para realizar seguimiento y control a la plataforma, éstos serán mostrados bajo el siguiente formato:
1. Información General.
a. Nombre del KPI b. Descripción: consiste en explicar en qué consiste el KPI. c. Responsable: menciona quien es el encargado de realizar el seguimiento y control. d. Objetivo: describe para que fue diseñado el KPI. e. Interrogantes: lo que resuelve específicamente el KPI.
2. Información Técnica.
a. Calculo: Fórmula matemática para la obtención de la muestra. b. Valor aceptado. c. Valor objetivo. d. Obtención de datos: de donde se obtendrán los datos para alimentar la formula. e. Frecuencia de medición: indica la frecuencia con la cual se obtendrán los datos. f. Representación: la manera en la cual serán visibles los resultados.
3. Observaciones.
Tiene que ver con información general acerca del KPI, ya sea la manera de calcular el valor objetivo y/o criterio de aceptación o simplemente algún alcance que se quiera hacer con respecto al KPI.
4. Interpretación de los datos.
Este punto depende, de la manera en la cual serán interpretados los datos del KPI, se sabe que existen dos tipos de retroalimentación: positiva y negativa. La primera no toma acción alguna respecto a la medida obtenida
66
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
y la segunda toma acciones a partir de la medición obtenida. Con esto se quiere decir que en los KPI que se definen a continuación hay algunos que cuentan con éste punto por ser interpretados los datos de manera negativa.
1. KPI – Porcentaje de uso de la plataforma de gestión.
Tabla 5.2.- Porcentaje de uso de la plataforma de gestión. Fuente: Elaboración propia.
Información General Nombre del KPI Porcentaje de uso de la plataforma de gestión Descripción Mide el porcentaje de uso de la plataforma en un periodo determinado. Responsable Administrador de la Plataforma. Objetivo Verificar el uso de la plataforma en la gestión del proyecto de software Interrogantes ¿El uso de la plataforma es clave en la productividad del equipo?
Información Técnica Calculo
Valor aceptado 75% Valor objetivo 100% Obtención de Modulo de Actividad Plataforma de Gestión de datos Proyectos Collabtive. Frecuencia de Semanal medición Representación Gráfica
Observaciones Cabe destacar que el valor asignado al criterio de aceptación variará dependiendo de la cantidad de integrantes del equipo de desarrollo, la
67
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
manera de calcularlo es la siguiente:
La retroalimentación en este caso será tomada de forma negativa, por lo cual se debe considerar a la hora de interpretar los datos las siguientes acciones:
• Acciones Correctivas: si el valor del %UPG es menor o igual al criterio de aceptación, se procede a determinar las causas del no uso de la plataforma por algunos integrantes del equipo. Si las causas son endógenas, se debe recordar al jefe de equipo y los responsables de tareas, que debe existir equitatividad de tareas. Por el contrario si las causas son exógenas se debe idear un plan de acción que permita que el usuario interactué con la plataforma.
• Acciones Preventivas: La realización de Talleres que fomenten la interacción de los alumnos con la plataforma, antes del inicio del proyecto.
2. KPI – Porcentaje de uso módulo comunicación instantánea.
Tabla 5.3.- Porcentaje de uso de la plataforma de gestión. Fuente: Elaboración propia.
Información General Nombre del KPI Porcentaje de uso módulo de comunicación instantánea Descripción Mide el porcentaje de uso asociado a la gestión del proyecto del módulo de comunicación instantánea en un periodo determinado. Responsable Administrador de la Plataforma. Objetivo Medir el grado de “correcta” utilización del módulo.
68
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
Interrogantes ¿Es adecuado el módulo para el desarrollo del proyecto?, ¿Da soporte a la colaboración dentro del equipo?
Información Técnica
Calculo continúa página siguiente… Valor aceptado 50% Valor objetivo 80% Obtención de Base de datos Plataforma de Gestión Collabtive tabla datos “chat”. Frecuencia de Semanal medición Representación Gráfica
Observaciones La retroalimentación en este caso será tomada de forma positiva, por lo cual se esperara hasta el final del ciclo de muestras para tomar una decisión al respecto.
3. KPI – Porcentaje distribución de la carga horaria.
Tabla 5.4.- Porcentaje distribución de la carga horaria. Fuente: Elaboración propia.
Información General Nombre del KPI Porcentaje distribución de la carga horaria. Descripción Mide el porcentaje de distribución de la carga horaria por cada integrante del equipo de desarrollo en un periodo determinado. Responsable Administrador de la Plataforma. Objetivo Determinar el porcentaje de participación activa en el
69
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
desarrollo de las actividades. Interrogantes ¿La asignación de tareas fue realizada de forma equitativa?
Información Técnica Calculo continúa página siguiente…
Valor aceptado Valor objetivo
Obtención de Plataforma de Gestión Collabtive Modulo de control de datos tiempo Frecuencia de Semanal medición Representación Gráfica
Observaciones El indicador pretende verificar que la carga de trabajo sea equitativa desde el comienzo del desarrollo, de esta manera se pretende validar la planificación realizada por el jefe de equipo en la distribución de las actividades. Cabe destacar que tanto el criterio de aceptación y el valor objetivo están en función del número de integrantes del equipo de desarrollo.
Interpretación de los datos La retroalimentación en este caso será tomada de forma negativa, por lo cual se debe considerar a la hora de interpretar los datos las siguientes acciones:
• Acciones Correctivas: si el valor de %DCH se encuentra fuera del rango del criterio de aceptación, se procede a determinar las causas del ¿por qué? tan baja participación en el desarrollo del producto software. Una vez determinadas las causas se procede a elaborar un
70
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
plan de acción que permita al o los individuos integrarse a alguna actividad realizada por sus compañeros de equipo. • Acciones Preventivas: si el valor de %DCH se encuentra bordeando los límites del rango del criterio de aceptación, se debe revisar la planificación con el jefe de equipo para elaborar un plan de acción que permita al o los individuos integrarse a alguna actividad realizada por sus compañeros de equipo.
4. KPI – Porcentaje de tareas realizadas.
Tabla 5.5.- Porcentaje de tareas realizadas . Fuente: Elaboración propia.
Información General Nombre del KPI Porcentaje de tareas realizadas Descripción Mide el porcentaje de tareas realizadas en un periodo determinado. Responsable Administrador de la Plataforma. Objetivo Verificar el número de tareas que se concluyen por semana. Interrogantes ¿Qué factores influyen en la no consecución de las tareas?
Información Técnica Calculo
Valor aceptado 75 %(equivalente a ¾ de las tareas) Valor objetivo 100% Obtención de Plataforma de Gestión Collabtive Modulo lista de tareas datos Frecuencia de Semanal medición
71
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
Representación Gráfica
Observaciones El indicador buscar medir la cantidad de tareas terminadas en la semana con respecto a lo planificado, e identificar los factores extrínsecos y/o intrínsecos que influyen en la no consecución de las tareas.
Interpretación de los datos La retroalimentación en este caso será tomada de forma negativa, por lo cual se debe considerar a la hora de interpretarcontinúa los datos página las siguiente… siguientes acciones:
• Acciones Correctivas: si el valor del %TR es menor o igual al criterio de aceptación, se procede a identificar el tipo de factor que influye en la finalización de las tareas. Si los factores fuesen extrínsecos se procede chequear la planificación del equipo en busca de una replanificación o mejor distribución de esfuerzos por tarea, en caso contrario se procede a discutir como equipo el ¿por qué? del no cumplimiento de las tareas.
• Acciones Preventivas: si el valor del %TR es cercano al criterio de aceptación se debe proceder como si se tratase de una acción correctiva.
5. KPI – Porcentaje de uso módulo mensajes.
Tabla 5.6.- Porcentaje de tareas realizadas . Fuente: Elaboración propia.
Información General Nombre del KPI Porcentaje de uso módulo mensajes Descripción Mide el porcentaje de uso del módulo mensajes, centrando su atención en el numero de mensajes respondidos, en un periodo determinado
72
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
Responsable Administrador de la Plataforma. Objetivo Verificar si el módulo “mensajes” es un aporte real a la gestión del proyecto. Interrogantes ¿El módulo da soporte a la colaboración?, ¿el equipo de desarrollo utiliza el módulo como bandeja de correo?
Información Técnica Calculo
Valor aceptado 50% Valor objetivo 80% Obtención de Plataforma de Gestión Collabtive Modulo de mensajes datos Frecuencia de Semanal medición Representación Gráfica
Observaciones
Interpretación de los datos La retroalimentación en este caso será tomada de forma positiva, por lo cual se esperara hasta el final del ciclo de muestras para tomar una decisión al respecto al buen uso del módulo.
73
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
6. KPI – Porcentaje de archivos de documentación
Tabla 5.7.- Porcentaje de archivos de documentación . Fuente: Elaboración propia.
Información General Nombre del KPI Porcentaje de archivos de documentación Descripción Mide el porcentaje de archivos de documentación que son alojados en la plataforma en un periodo determinado Responsable Administrador de la Plataforma. Objetivo Verificar si el módulo “archivos” es un aporte real a la gestión del proyecto. Interrogantes ¿El módulo da soporte a la colaboración?, ¿el equipo de desarrollo utiliza el módulo para tener una documentación idónea, a tiempo y equitativa a lo largo del desarrollo?
Información Técnica Calculo
Valor aceptado 50% Valor objetivo 80% Obtención de Base de datos de la Plataforma de Gestión de datos Proyectos Collabtive tabla “files” Frecuencia de Semanal medición Representación Gráfica
Observaciones
Interpretación de los datos
74
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
La retroalimentación en este caso será tomada de forma positiva, por lo cual se esperará hasta el final del ciclo de muestras para tomar una decisión al respecto al buen uso del módulo.
7. KPI – Porcentaje de archivos de desarrollo.
Tabla 5.8.- Porcentaje de archivos de desarrollo . Fuente: Elaboración propia.
Información General Nombre del KPI Porcentaje de archivos de documentación Descripción Mide el porcentaje de archivos de desarrollo que son alojados en la plataforma en un periodo determinado Responsable Administrador de la Plataforma. Objetivo Verificar si el módulo “archivos” es un aporte real a la gestión del proyecto. Interrogantes ¿El módulo da soporte a la colaboración?, ¿el equipo de desarrollo utiliza el módulo para depurar y validar los archivos asociados al desarrollo?
Información Técnica Calculo
Valor aceptado 50% Valor objetivo 80% Obtención de Base de datos de la Plataforma de Gestión de datos Proyectos Collabtive tabla “files” Frecuencia de Semanal medición Representación Gráfica
Observaciones
75
Capitulo 5.- Mecanismos de Evaluación de la Plataforma de Gestión
Interpretación de los datos La retroalimentación en este caso será tomada de forma positiva, por lo cual se esperará hasta el final del ciclo de muestras para tomar una decisión al respecto al buen uso del módulo.
5.4. Observaciones Generales.
Cada uno de los KPI presentados en la sección anterior, han sido definidos cuidadosamente a partir de las necesidades de información listadas en la sección 5.2.1. Cabe destacar que los valores de aceptación y objetivo, se han estimado en base a la experiencia del profesor de la asignatura de Ingeniería de Software y a la del autor del trabajo de título, tomando como referencia las experiencias anteriores obtenidas en los proyectos de la asignatura.
Como se recordará, uno de los objetivos específicos de este trabajo es aplicar la plataforma y el modelo al taller que se realiza en la asignatura de ingeniería de software. El fin detrás de este objetivo es obtener un producto de calidad, es decir que entregue un valor agregado al producto software, derivado de la sinergia, la cohesión, el seguimiento y el control. Para lograr esto, se definieron mecanismos de evaluación que dan soporte al seguimiento y control mostrado en la figura 4.1, utilizando como medio la plataforma seleccionada. Por otra parte, el taller consiste en implementar un sistema web de control y seguimiento de trabajos de título, el cual permitirá obtener información acerca de las memorias del año en curso, junto con un compendio de las memorias de años anteriores. (Para mayor información véase el Anexo A).
76
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
Capítulo 6.- Seguimiento y Control de la Plataforma de Gestión.
6.1. Introducción.
En el capítulo 5 se presentaron los siete indicadores clave de rendimiento con los que se llevará a cabo, el seguimiento y control sobre la plataforma. En el presente capítulo se mostrará el resultado de ocho semanas de seguimiento (toma de muestras) y control (acciones correctivas), con el fin de verificar, que tan incidente es la utilización de una plataforma tecnológica en la gestión del proyecto de software de la asignatura.
6.2. Implementación de los KPI.
Cuando se definieron los KPI’s, se indicó que la muestra sería tomada semanalmente, la Tabla 6.1 lista los periodos a los cuales corresponden las muestras obtenidas para su análisis, junto con el día en que se tomaron dichas muestras.
Tabla 6.1.- Periodo de las muestras . Fuente: Elaboración propia.
Muestras Periodo Toma de muestra Muestra 1 07/10/10 al 14/10/10 14 de Octubre Muestra 2 15/10/10 al 21/10/10 21 de Octubre Muestra 3 22/10/10 al 28/10/10 28 de Octubre Muestra 4 29/10/10 al 04/11/10 04 de Noviembre Muestra 5 05/11/10 al 11/11/10 11 de Noviembre Muestra 6 12/11/10 al 18/11/10 18 de Noviembre Muestra 7 19/11/10 al 25/11/10 25 de Noviembre Muestra 8 26/11/10 al 02/12/10 02 de Diciembre
77
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
A continuación se comienza con el análisis de los siete indicadores clave de rendimiento, cabe destacar que solo se mostrará el último grafico, ya que en éste se concentran todas las muestras y se puede tener mejor impresión acerca de lo que ocurrió entre las 8 semanas, analizadas.
6.2.1. Porcentaje de uso de la plataforma de gestión.
La Tabla 6.2 contiene cada uno de los valores asociados a las muestras que se tomaron para éste KPI, en base a la Ecuación 6.1 y que fue definida en la sección 5.3.
ªúûÈÅ º» ËÉË·È¿ÅÉ ¹ÅÄ ·¹Ê¿Ì¿º·º %̛̖̍ = × ̊̉̉ ªúûÈÅ ÊÅÊ·Â º» ËÉË·È¿ÅÉ º»Â ÆÈÅÏ»¹ÊÅ
Ecuación 6.1.- Ecuación %UMCI . Fuente: Elaboración propia.
Tabla 6.2.- Valor Muestra KPI %UPG . Fuente: Elaboración propia.
Muestras Calculo Valor Muestra 1 ̍ %̛̖̍ = × ̊̉̉ %̛̖̍ = ̊̉̉ % ̍ Muestra 2 ̍ %̛̖̍ = × ̊̉̉ %̛̖̍ = ̊̉̉ % ̍ Muestra 3 ̍ %̛̖̍ = × ̊̉̉ %̛̖̍ = ̊̉̉ % ̍ Muestra 4 ̍ %̛̖̍ = × ̊̉̉ %̛̖̍ = ̊̉̉ % ̍ Muestra 5 ̍ %̛̖̍ = × ̊̉̉ %̛̖̍ = ̊̉̉ % ̍ Muestra 6 ̍ %̛̖̍ = × ̊̉̉ %̛̖̍ = ̊̉̉ % ̍ Muestra 7 ̋ %̛̖̍ = × ̊̉̉ %̛̖̍ = ̎̉ % ̍ Muestra 8 ̍ %̛̖̍ = × ̊̉̉ %̛̖̍ = ̊̉̉ % ̍
78
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
La Figura 6.1 muestra gráficamente los resultados obtenidos en la Tabla 6.2 representados por la curva muestra, también se distinguen otras tres curvas que son la curva esperada, objetivo y aceptación.
KPI - %UPG 110
100
90
80
70
60
50
40
30
20
10
0 muestra1 muestra2 muestra3 muestra4 muestra5 muestra6 muestra7 muestra8
Muestra Objetivo Aceptación Esperado
Figura 6.1.- Representación grafica KPI %UPG . Fuente: Elaboración propia.
De la Figura 6.1 se puede interpretar lo siguiente:
1. Se alcanzó el valor objetivo una semana antes de lo esperado, esto se debió fundamentalmente a la aplicación de las acciones preventivas definidas para este KPI.
2. Se logró mantener un nivel de usabilidad constante durante cuatro semanas, el cual se vió fuertemente afectado con una caída de 50 puntos porcentuales en la muestra 7, se realizó el control definido y se encontró que la causa se debe a la sobrecarga de pruebas y
79
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
entrega de talleres finales, en las asignaturas de la carrera, debido principalmente a la participación de parte del equipo de desarrollo en INFONOR 2010. Si bien este evento se llevó a cabo en la muestra 6, el impacto que produjo la nueva planificación de certámenes y talleres, se ve fuertemente reflejado en el tiempo que disponen los alumnos para desarrollar todas sus actividades académicas al final del periodo lectivo.
3. En la muestra 8 se aprecia que la acción correctiva cursada causó un efecto inmediato en el equipo de desarrollo, alcanzando nuevamente el valor objetivo en la última muestra.
Si bien, al momento de planificar las actividades el equipo de desarrollo no consideró, que existiría una semana en la cual las actividades academicas serian suspendidas, motivo por lo cual el curso normal del desarrollo del software se vería afectado, ademas si se considera que al momento de tomar la muestra 8, al software le quedaban aun 2 semanas para finalizar su desarrollo y considerando el ultimo avance mostrado por el equipo de desarrollo, se concluye que el uso de la plataforma de gestion es proporcional a la productividad del equipo, puesto que el no uso de la plataforma, refleja inminentes atrasos en las tareas ya programadas.
6.2.2. Porcentaje de uso del módulo de comunicación instantánea.
La Tabla 6.3 contiene cada uno de los valores asociados a las muestras que se tomaron para éste KPI, en base a la Ecuación 6.2 y que fue definida en la sección 5.3.
ªúûÈÅ º» ¹ÅÄÌ»ÈÉ·¹¿ÅÄ»É ·ÉŹ¿·º·É ·Â ÆÈÅÏ»¹ÊÅ %̛̓̉̏ = × ̊̉̉ ªúûÈÅ ÊÅÊ·Â º» ¹ÅÄÌ»ÈÉ·¹¿ÅÄ»É
Ecuación 6.2.- Ecuación %UMCI . Fuente: Elaboración propia. Tabla 6.3.- Valor Muestra KPI %UMCI .
80
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
Fuente: Elaboración propia.
Muestras Calculo Valor Muestra 1 ̉ %̛̓̉̏ = × ̊̉̉ %̛̓̉̏ = ̉% ̌ Muestra 2 ̉ %̛̓̉̏ = × ̊̉̉ %̛̓̉̏ = ̉% ̋ Muestra 3 ̉ %̛̓̉̏ = × ̊̉̉ %̛̓̉̏ = ̉% ̊ Muestra 4 ̉ %̛̓̉̏ = × ̊̉̉ %̛̓̉̏ = ̉% ̉ Muestra 5 ̉ %̛̓̉̏ = × ̊̉̉ %̛̓̉̏ = ̉% ̉ Muestra 6 ̉ %̛̓̉̏ = × ̊̉̉ %̛̓̉̏ = ̉% ̉ Muestra 7 ̉ %̛̓̉̏ = × ̊̉̉ %̛̓̉̏ = ̉% ̉ Muestra 8 ̉ %̛̓̉̏ = × ̊̉̉ %̛̓̉̏ = ̉% ̉
La Figura 6.2 muestra gráficamente los resultados obtenidos en la Tabla 6.3 representados por la curva muestra, también se distinguen otras tres curvas que son la curva esperada, objetivo y aceptación.
De la Figura 6.2 se puede interpretar lo siguiente:
1. Se aprecia claramente que el equipo utilizó otros medios de comunicación externos a la plataforma.
Como se recordará de la definición del KPI, la retroalimentación de éste sería considerada como positiva. Por tanto, se puede decir que el módulo no es adecuado para el desarrollo del proyecto, puesto que el equipo de desarrollo utilizó, otros mecanismos para comunicarse, como las mensajerías instantáneas tradicionales, celular y persona a persona, esta última fue la que primó debido a sus extensas horas presenciales en la Universidad de Atacama. Por tanto, se concluye que el módulo no da soporte a la colaboración dentro del equipo de
81
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión desarrollo, puesto que, a pesar de existir conversaciones, éstas no están en el contexto del desarrollo mismo.
KPI - %UMCI 90
80
70
60
50
40
30
20
10
0 muestra1 muestra2 muestra3 muestra4 muestra5 muestra6 muestra7 muestra8
Muestra Objetivo Aceptación Esperado
Figura 6.2.- Representación grafica KPI %UMCI . Fuente: Elaboración propia.
6.2.3. Porcentaje de distribución de la carga horaria.
El análisis de éste KPI será dividido en los cuatro integrantes del equipo de desarrollo, al igual que en los dos anteriores las muestras tomadas alimentan la Ecuación 6.3 que fue definida en la sección 5.3.
·ÄÊ¿º·º º» ¾ÅÈ·É /¾ÅøȻ %̊̉̎ = × ̊̉̉ ·ÄÊ¿º·º ÊÅÊ·Â º» ¾ÅÈ·É
Ecuación 6.3.- Ecuación %DCH . Fuente: Elaboración propia.
1. Jefe de Proyecto
82
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
La Tabla 6.4 contiene cada uno de los valores asociados a las muestras que se tomaron de éste integrante para el KPI.
Tabla 6.4.- Valor Muestra KPI %DCH-Jefe de Proyecto . Fuente: Elaboración propia.
Muestras Calculo Valor Muestra 1 ̏, ̎ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̍̒ % ̊̌ , ̊̏ Muestra 2 ̋, ̒ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̋̉ % ̊̋ , ̎̒ Muestra 3 ̌̍ , ̒̍ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̎̌ % ̏̏ , ̍̊ Muestra 4 ̊̊ , ̊̎ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̎̉ % ̋̋ , ̎̋ Muestra 5 ̒, ̋̎ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̌̐ % ̋̎ , ̉̑ Muestra 6 ̊, ̎ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̊̊ % ̊̌ , ̋̐ Muestra 7 ̉, ̎ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̎̉ % ̊ Muestra 8 ̋ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̊̉ % ̊̒ , ̎̒
La Figura 6.3 muestra gráficamente los resultados obtenidos en la Tabla 6.4 representados por la curva muestra, también se distinguen otras cuatro curvas que son la curva esperada, objetivo y aceptación (representada por dos curvas).
De la Figura 6.3 se puede interpretar lo siguiente:
1. La primera muestra, es totalmente opuesta a lo esperado, esto debido a que ya existe un sistema (ver Anexo A), por tanto esta semana consistió en un fuerte análisis de la documentación existente y realizar la planificación de las actividades asociadas al proyecto.
83
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
KPI - %DCH (Jefe de Proyecto) 55
50
45
40
35
30
25
20
15
10
5
0 muestra1 muestra2 muestra3 muestra4 muestra5 muestra6 muestra7 muestra8
Muestra Objetivo Aceptación Aceptación Esperado
Figura 6.3.- Representación grafica KPI %DCH- Jefe de Proyecto . Fuente: Elaboración propia.
2. La segunda semana, nuevamente se obtiene un resultado distinto al esperado, y es lógico que así suceda, puesto que ya en la segunda semana las tareas se repartieron de forma más equitativa y el Jefe de equipo delego responsabilidades a los demás miembros del equipo de desarrollo.
3. De la muestra 3 a la muestra 6 se puede notar un decaimiento en las horas invertidas en el desarrollo por parte del jefe de proyecto, cosa que se esperaba sucedería, pero de manera brusca, como se puede ver en la curva esperada de la muestra 3 a la muestra 4. Ya en la muestra 6 el valor obtenido se debe al viaje a la INFONOR, actividad que no estaba dentro de la planificación del equipo de desarrollo.
84
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
4. Las dos últimas muestras obtenidas son resultado directo del problema de planificación no previsto, puesto que el cierre del periodo lectivo y la semana perdida, afectaron la participación de este miembro en las actividades del desarrollo.
Como se recordará de la definición del KPI en la sección 5.3, la retroalimentación de los datos sería tomada de forma negativa, para llevar a cabo la primera acción se esperó hasta la tercera muestra, para tener una visión más global acerca de lo que estaba sucediendo, se procedió a determinar las causas de tanta sobre carga para este usuario, y la causa principal según el propio usuario es producto de las habilidades propias para desempeñar la tarea, ya que según él, existen tareas que demandan más tiempo para llevarlas a cabo, debido al desconocimiento de una herramienta en particular o simplemente porque existen muchas cosas dentro del desarrollo del proyecto, que son nuevas para éste y que demandan un estudio previo.
Las apreciaciones de las interrogantes del KPI y objetivo serán abordados al final del análisis del KPI.
2. Jefe de Análisis.
La Tabla 6.5 contiene cada uno de los valores asociados a las muestras que se tomaron de éste integrante para el KPI.
Tabla 6.5.- Valor Muestra KPI %DCH- Jefe de Análisis . Fuente: Elaboración propia.
Muestras Calculo Valor Muestra 1 ̉ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̉% ̊̌ , ̊̏ Muestra 2 ̍ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̌̋ % ̊̋ , ̎̒
85
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
Muestra 3 ̒ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̊̍ % ̏̏ , ̍̊ Muestra 4 ̉ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̉% ̋̋ , ̎̋ Muestra 5 ̌ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̊̋ % ̋̎ , ̉̑ Muestra 6 ̊, ̎ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̊̊ % ̊̌ , ̋̐ Muestra 7 ̉ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̉% ̊ Muestra 8 ̋ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̊̉ % ̊̒ , ̎̒
La Figura 6.4 muestra gráficamente los resultados obtenidos en la Tabla 6.5 representados por la curva muestra, también se distinguen otras cuatro curvas que son la curva esperada, objetivo y aceptación (representada por dos curvas).
De la Figura 6.4 se puede interpretar lo siguiente:
1. Las primeras dos muestras concuerdan con lo que se esperaba de éste miembro del equipo de desarrollo. De hecho la segunda muestra arroja un resultado que, si bien se encuentra fuera del rango aceptación, responde al fuerte análisis que debió llevar este integrante para el desarrollo del producto software.
2. Las siguientes muestras (muestra 3 a muestra 8), si bien se encuentran muy por debajo del rango de aceptación, era de esperarse una disminución en la participación de este integrante, puesto que su fuerte es el análisis y este está situado en la primera etapa del desarrollo.
86
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
KPI - %DCH (Jefe de Análisis) 35
30
25
20
15
10
5
0 muestra1 muestra2 muestra3 muestra4 muestra5 muestra6 muestra7 muestra8
Muestra Objetivo Aceptación Aceptación Esperado
Figura 6.4.- Representación grafica KPI %DCH- Jefe de Análisis . Fuente: Elaboración propia.
Como se recordará de la definición del KPI en la sección 5.3, la retroalimentación de los datos sería tomada de forma negativa, al igual que el miembro anterior, para llevar a cabo la primera acción se esperó hasta la tercera muestra, para tener una visión más global acerca de lo que estaba sucediendo, en resumen se llevaron cinco acciones correctivas de las cuales se obtuvieron dos causas:
o Con respecto a las dos muestras en cero, la causa se debió a una mala distribución del tiempo del miembro en las otras asignaturas de la carrera, lo que gatilló que se debiera priorizar los certámenes y/o talleres de otras asignaturas en vez del desarrollo del producto software.
87
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
o Con respecto a la pendiente negativa entre las muestras 3 y 8, la causa principal se debe a que las actividades desarrolladas por este miembro en la etapa de desarrollo (muestra 3 en adelante) son de apoyo, ya que, como se mencionó anteriormente su rol principal se encuentra en el desarrollo del documento de requerimientos de software. Por tanto, al ser actividades de apoyo demandan de menos horas de participación en esta etapa.
3. Jefe de Diseño
La Tabla 6.6 contiene cada uno de los valores asociados a las muestras que se tomaron de éste integrante para el KPI.
Tabla 6.6.- Valor Muestra KPI %DCH-Jefe de Diseño . Fuente: Elaboración propia.
Muestras Calculo Valor Muestra 1 ̍, ̌̌ %̊̉̎ = × ̊̉̉ %̊̉ = ̌̌ % ̊̌ , ̊̏ Muestra 2 ̋, ̒̋ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̋̌ % ̊̋ , ̎̒ Muestra 3 ̊̒ , ̒̐ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̌̉ % ̏̏ , ̍̊ Muestra 4 ̊̉ , ̌̐ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̍̏ % ̋̋ , ̎̋ Muestra 5 ̑, ̌̌ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̌̌ % ̋̎ , ̉̑ Muestra 6 ̍, ̋̐ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̌̋ % ̊̌ , ̋̐ Muestra 7 ̉ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̉% ̊ Muestra 8 ̌, ̊̑ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̊̏ % ̊̒ , ̎̒
88
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
La Figura 6.5 muestra gráficamente los resultados obtenidos en la Tabla 6.6 representados por la curva muestra, también se distinguen otras cuatro curvas que son la curva esperada, objetivo y aceptación (representada por dos curvas).
De la Figura 6.5 se puede interpretar lo siguiente:
1. Al igual que el jefe de desarrollo como ya existe un sistema (ver Anexo A). La participación de este miembro en la primera semana es completamente opuesta a lo esperado, producto del fuerte análisis requerido para entender el sistema actual.
2. De la muestra 2 a la muestra 5 el comportamiento de la curva muestra es similar al de la curva esperado, a pesar de estar fuera del rango de aceptación, era de esperarse esta fuerte participación puesto que es el encargado de diseñar la arquitectura del sistema.
3. En las últimas muestras (muestra 6 a muestra 8) este miembro pierde protagonismo y se dedica a las actividades de apoyo en la programación del sistema.
Como se recordará de la definición del KPI en la sección 5.3, la retroalimentación de los datos sería tomada de forma negativa, para llevar a cabo la primera acción se esperó hasta la tercera muestra, para tener una visión más global acerca de lo que estaba sucediendo, se procedió a determinar las causas de la sobre carga para este usuario, y la causa principal según el propio usuario es el nivel de detalle con el que le gusta trabajar, su filosofía de trabajo es “no importa cuánto tarde en terminar la tarea, lo importante es terminarla bien” . Una segunda causa de su bajo desempeño al final del periodo de muestras (muestra 6 a muestra 8) fue producto del fin de la etapa de análisis y su paso a desarrollar actividades de apoyo en la programación.
89
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
KPI - %DCH (Jefe de Diseño) 50
45
40
35
30
25
20
15
10
5
0 muestra1 muestra2 muestra3 muestra4 muestra5 muestra6 muestra7 muestra8
Muestra Objetivo Aceptación Aceptación Esperado
Figura 6.5.- Representación grafica KPI %DCH- Jefe de Diseño . Fuente: Elaboración propia.
4. Jefe de Desarrollo
La Tabla 6.7 contiene cada uno de los valores asociados a las muestras que se tomaron de éste integrante para el KPI.
Tabla 6.7.- Valor Muestra KPI %DCH-Jefe de Desarrollo . Fuente: Elaboración propia.
Muestras Calculo Valor Muestra 1 ̋, ̌̌ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̊̑ % ̊̌ , ̊̏
90
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
Muestra 2 ̌, ̊̐ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̋̎ % ̊̋ , ̎̒ Muestra 3 ̋, ̎ %̊̉̎ = × ̊̉ %̊̉̎ = ̍% ̏̏ , ̍̊ Muestra 4 ̊ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̍% ̋̋ , ̎̋ Muestra 5 ̍, ̎ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̊̑ % ̋̎ , ̉̑ Muestra 6 ̏ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̍̎ % ̊̌ , ̋̐ Muestra 7 ̉, ̎ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̎̉ % ̊ Muestra 8 ̊̋ , ̌̍ %̊̉̎ = × ̊̉̉ %̊̉̎ = ̏̌ % ̊̒ , ̎̒
La Figura 6.6 muestra gráficamente los resultados obtenidos en la Tabla 6.7 representados por la curva muestra, también se distinguen otras cuatro curvas que son la curva esperada, objetivo y aceptación (representada por dos curvas).
De la Figura 6.6 se puede interpretar lo siguiente:
1. Nuevamente producto del sistema existente (ver Anexo A), se obtiene una medida diferente de lo esperado en las primeras dos muestras.
2. De la muestra 3 a las muestra 8 la participación de este miembro va aumentando considerablemente, de hecho a partir de la muestra 6 asume control total sobre las acciones dentro del desarrollo ya que es el encargado de integrar y a su vez desarrollar también los módulos programados.
91
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
KPI - %DCH (Jefe de Desarrollo) 65 60 55 50 45 40 35 30 25 20 15 10 5 0 muestra1 muestra2 muestra3 muestra4 muestra5 muestra6 muestra7 muestra8
Muestra Objetivo Aceptación Aceptación Esperado
Figura 6.6.- Representación grafica KPI %DCH- Jefe de Desarrollo. Fuente: Elaboración propia.
Como se recordará de la definición del KPI en la sección 5.3, la retroalimentación de los datos sería tomada de forma negativa, para llevar a cabo la primera acción se esperó hasta la tercera muestra, para tener una visión más global acerca de lo que estaba sucediendo, se procedió a determinar las causas de la poca participación en las primeras muestras de este usuario, y la causa principal según el propio miembro es que su participación en las actividades de apoyo es considerable, pero que las termina en un tiempo ínfimo en comparación con los otros miembros, aseveración que fue validada por el jefe de desarrollo, con respecto a la sobre carga de trabajo en la última etapa donde él es el responsable, asegura que el hecho de encargarse de la integración de códigos es lo que
92
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión conlleva a aparecer con más tiempo que los demás, pero que, si se evaluará solamente los tiempos de programación debería disminuir su carga horaria.
Según las interrogantes de este KPI y el objetivo planteado en su definición se concluye que la asignación de tareas se realizo equitativamente, pero que las habilidades de los miembros, gatillaron diferencias sustanciales en cuanto al tiempo invertido en el desarrollo de la actividad, en lo que respecta al objetivo la participación activa promedio se describe a continuación:
• Jefe proyecto: 35%.
• Jefe de Análisis: 10%.
• Jefe de Diseño: 27%.
• Jefe de Desarrollo: 28%.
A modo de resumen se puede decir que tanto el Jefe de Diseño como el Jefe de Desarrollo obtuvieron resultados promedio, que se encuentran dentro del rango de aceptación y los otros dos miembros obtienen diferencias sustanciales debido al factor “habilidad de los miembros”, mencionado con anterioridad.
6.2.4. Porcentaje de tareas realizadas.
La Tabla 6.8 contiene cada uno de los valores asociados a las muestras que se tomaron para éste KPI, en base a la Ecuación 6.4 y que fue definida en la sección 5.3.
ªúûÈÅ ÊÅÊ·Â º» Ê·È»·É ¼¿Ä·Â¿Ð·º·É %̘̚ = × ̊̉̉ ªúûÈÅ º» Ê·È»·É ÆÈÅÆË»ÉÊ·É Æ·È· · ɻ÷ķ
Ecuación 6.4.- Ecuación %TR . Fuente: Elaboración propia.
93
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
Tabla 6.8.- Valor Muestra KPI %TR . Fuente: Elaboración propia.
Muestras Calculo Valor Muestra 1 ̉ %̘̚ = × ̊̉̉ %̘̚ = ̉% ̉ Muestra 2 ̉ %̘̚ = × ̊̉̉ %̘̚ = ̉% ̉ Muestra 3 ̒ %̘̚ = × ̊̉̉ %̘̚ = ̊̉̉ % ̒ Muestra 4 ̏ %̘̚ = × ̊̉̉ %̘̚ = ̊̉̉ % ̏ Muestra 5 ̒ %̘̚ = × ̊̉̉ %̘̚ = ̊̉̉ % ̒ Muestra 6 ̎ %̘̚ = × ̊̉̉ %̘̚ = ̊̉̉ % ̎ Muestra 7 ̋ %̘̚ = × ̊̉̉ %̘̚ = ̊̉̉ % ̋ Muestra 8 ̋ %̘̚ = × ̊̉̉ %̘̚ = ̋̋ % ̒
La Figura 6.7 muestra gráficamente los resultados obtenidos en la Tabla 6.8 representados por la curva muestra, también se distinguen otras tres curvas que son la curva esperada, objetivo y aceptación.
De la Figura 6.7 se puede interpretar lo siguiente:
1. A pesar, de que las dos primeras muestras advierten que no se llevaron a cabo tareas, esto no es del todo cierto, puesto que, las tareas fueron planificadas para ser finalizadas desde la tercera semana en adelante. Se puede apreciar también, que se logró alcanzar el valor objetivo una semana antes de lo esperado.
2. Durante cinco semanas, el equipo de desarrollo logró un desempeño excelente, terminando a cabalidad las tareas planificadas. Sin embargo, la última muestra arroja un resultado paupérrimo que
94
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
rompe con la tendencia y que lamentablemente pone en riesgo la fecha de finalización del proyecto.
KPI - %TR 110 100 90 80 70 60 50 40 30 20 10 0 muestra1 muestra2 muestra3 muestra4 muestra5 muestra6 muestra7 muestra8
Muestra Objetivo Aceptación Esperado
Figura 6.7.- Representación grafica KPI %TR . Fuente: Elaboración propia.
Como se describe en la definición del KPI, se debe realizar una acción correctiva para corregir el resultado de la última muestra, como ya se había mencionado antes, un factor que parece tener incidencia es la sobrecarga de talleres y certámenes que fueron planificados nuevamente producto del viaje a INFONOR, si bien el viaje se realizo en la semana 6, los efectos de la participación de dos de los integrantes del equipo de desarrollo a este evento se ven reflejados recién en la muestra 8, puesto que, han tenido que dedicar más del tiempo que pensaban, en las demás asignaturas que están cursando. Por otra parte se puede decir que existe un factor extrínseco que influye en la no consecución de las tareas en la última semana, por lo que el equipo debe volver a planificar sus
95
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión actividades finales y solicitar una prórroga en la entrega del taller. Dicho esto se concluye que el modulo de programación de tareas es uno de los más importantes, ya que permite validar en tiempo real el grado de avance del equipo de desarrollo y permite validar entre otros, los problemas que surgen en la no consecución de las tareas definidas para la semana.
6.2.5. Porcentaje de uso del módulo mensajes.
La Tabla 6.9 contiene cada uno de los valores asociados a las muestras que se tomaron para éste KPI, en base a la Ecuación 6.5 y que fue definida en la sección 5.3.
ªúûÈÅ º» ûÄÉ·À»É ÈÉÆÅĺ¿ºÅÉ %̛̓̓ = × ̊̉̉ ªúûÈÅ º» ûÄÉ·À»É
Ecuación 6.5.- Ecuación %UMM . Fuente: Elaboración propia.
Tabla 6.9.- Valor Muestra KPI %UMM . Fuente: Elaboración propia.
Muestras Calculo Valor Muestra 1 ̉ %̛̓̓ = × ̊̉̉ %̛̓̓ = ̉% ̊ Muestra 2 ̉ %̛̓̓ = × ̊̉̉ %̛̓̓ = ̉% ̋ Muestra 3 ̉ %̛̓̓ = × ̊̉̉ %̛̓̓ = ̉% ̌ Muestra 4 ̊ %̛̓̓ = × ̊̉̉ %̛̓̓ = ̌̌ % ̌ Muestra 5 ̉ %̛̓̓ = × ̊̉̉ %̛̓̓ = ̉% ̉ Muestra 6 ̉ %̛̓̓ = × ̊̉̉ %̛̓̓ = ̉% ̉ Muestra 7 ̉ %̛̓̓ = × ̊̉̉ %̛̓̓ = ̉% ̊
96
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
Muestra 8 ̉ %̛̓̓ = × ̊̉̉ %̛̓̓ = ̉% ̉
La Figura 6.8 muestra gráficamente los resultados obtenidos en la Tabla 6.9 representados por la curva muestra, también se distinguen otras tres curvas que son la curva esperada, objetivo y aceptación.
KPI - %UMM 90
80
70
60
50
40
30
20
10
0 muestra1 muestra2 muestra3 muestra4 muestra5 muestra6 muestra7 muestra8
Muestra Objetivo Aceptación Esperado
Figura 6.8.- Representación grafica KPI %UMM . Fuente: Elaboración propia.
De la Figura 6.8 se puede interpretar lo siguiente:
1. Si bien, la muestra 4 arrojo un valor significativo comparado con los anteriores, el sistema siguió comportándose de la misma forma, durante el resto de los periodos de evaluación.
Como se recordará de la definición del KPI, la retroalimentación de éste sería considerada como positiva. Por tanto, se concluye que el módulo no da
97
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión soporte a la colaboración, ya que utilizó otros mecanismos para colaborar, el equipo no utilizó el módulo como una bandeja de correo, sino que la utilizo como una especie de foro.
6.2.6. Porcentaje de Archivos de Documentación.
La Tabla 6.10 contiene cada uno de los valores asociados a las muestras que se tomaron para éste KPI, en base a la Ecuación 6.6 y que fue definida en la sección 5.3.
ȹ¾¿ÌÅÉ º» ºÅ¹ËûÄÊ·¹¿ óÄ %̇̊̊ = × ̊̉̉ ȹ¾¿ÌÅÉ °Åʷ»É
Ecuación 6.6.- Ecuación %ADD . Fuente: Elaboración propia.
Tabla 6.10.- Valor Muestra KPI %ADD . Fuente: Elaboración propia.
Muestras Calculo Valor Muestra 1 ̉ %̇̊̊ = × ̊̉̉ %̇̊̊ = ̉% ̉ Muestra 2 ̊ %̇̊̊ = × ̊̉̉ %̇̊̊ = ̌̌ % ̌ Muestra 3 ̐ %̇̊̊ = × ̊̉̉ ̑ %̇̊̊ = ̑̑ % Muestra 4 ̌ %̇̊̊ = × ̊̉̉ %̇̊̊ = ̏̉ % ̎ Muestra 5 ̊ %̇̊̊ = × ̊̉̉ %̇̊̊ = ̎̉ % ̋ Muestra 6 ̉ %̇̊̊ = × ̊̉̉ %̇̊̊ = ̉% ̋ Muestra 7 ̉ %̇̊̊ = × ̊̉̉ %̇̊̊ = ̉% ̊ Muestra 8 ̊ %̇̊̊ = × ̊̉̉ %̇̊̊ = ̎̉ % ̋
98
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
La Figura 6.9 muestra gráficamente los resultados obtenidos en la Tabla 6.9 representados por la curva muestra, también se distinguen otras tres curvas que son la curva esperada, objetivo y aceptación.
KPI - %ADD 100 90 80 70 60 50 40 30 20 10 0 muestra1 muestra2 muestra3 muestra4 muestra5 muestra6 muestra7 muestra8
Muestra Objetivo Aceptación Esperado
Figura 6.9.- Representación grafica KPI %ADD . Fuente: Elaboración propia.
De la Figura 6.9 se puede interpretar lo siguiente:
1. Si bien, las primeras dos semanas las medidas obtenidas estuvieron por debajo de lo esperado, de la tercera a la quinta se estuvo por sobre lo esperado, para finalizar la toma de muestras en el criterio de aceptación.
2. Se observa que en la muestra 3, la medida obtenida esta por sobre el valor objetivo, esto producto de que en esa semana se debía entregar el DERS (documento de especificación de requerimientos de software) y en las dos semanas restantes la medida obtenida debería acercarse nuevamente al valor objetivo.
99
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
Como se recordará de la definición del KPI, la retroalimentación de éste sería considerada como positiva. Por tanto, se concluye que el módulo da soporte a la colaboración, ya que permite compartir información asociada al desarrollo en tiempo real. Los documentos alojados son repartidos de manera ordenada en diferentes directorios que identifican cada una de las fases del desarrollo del producto software, lo cual nos permite afirmar que la información es idónea, está a tiempo y es repartida equitativamente.
6.2.7. Porcentaje de Archivos de Desarrollo.
La Tabla 6.11 contiene cada uno de los valores asociados a las muestras que se tomaron para éste KPI, en base a la Ecuación 6.7 y que fue definida en la sección 5.3.
ȹ¾¿ÌÅÉ º» º»É·ÈÈÅÂÂÅ %̙̇̊̊ = × ̊̉̉ ȹ¾¿ÌÅÉ °Åʷ»É
Ecuación 6.7.- Ecuación %ADDS . Fuente: Elaboración propia.
Tabla 6.11.- Valor Muestra KPI %ADDS . Fuente: Elaboración propia.
Muestras Calculo Valor Muestra 1 ̉ %̙̇̊̊ = × ̊̉̉ %̙̇̊̊ = ̉% ̉ Muestra 2 ̋ %̙̇̊̊ = × ̊̉̉ %̙̇̊̊ = ̏̏ % ̌ Muestra 3 ̊ %̙̇̊̊ = × ̊̉̉ %̙̇̊̊ = ̋̋ % ̑ Muestra 4 ̋ %̙̇̊̊ = × ̊̉̉ %̙̇̊̊ = ̍̉ % ̎ Muestra 5 ̊ %̙̇̊̊ = × ̊̉̉ %̙̇̊̊ = ̎̉ % ̋
100
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
Muestra 6 ̋ %̙̇̊̊ = × ̊̉̉ %̙̇̊̊ = ̊̉̉ % ̋ Muestra 7 ̊ %̙̇̊̊ = × ̊̉̉ %̙̇̊̊ = ̊̉̉ % ̊ Muestra 8 ̊ %̙̇̊̊ = × ̊̉̉ %̙̇̊̊ = ̎̉ % ̋
La Figura 6.10 muestra graficamente los resultados obtenidos en la Tabla 6.11. representados por la curva muestra, tambien se distinguen otras tres curvas que son la curva esperada, objetivo y aceptación.
De la Figura 6.10 se puede interpretar lo siguiente:
1. De la muestra uno a la cinco el comportamiento es similar a lo esperado, excepto por la medida dos, que se encuentra sobre el criterio de aceptación, la causa de esta medida es que ya existe un sistema y junto con él una base de datos la cual fue objeto de análisis esa semana.
2. Tanto la muestra 6 como la muestra 7 registran el valor más alto a alcanzar y se sitúan por sobre el valor objetivo, describiendo gráficamente el alto nivel de programación necesitado en las ultimas semanas de desarrollo.
Como se recordará de la definición del KPI, la retroalimentación de éste sería considerada como positiva. Por tanto, se concluye que el módulo da soporte a la colaboración, ya que permite compartir los archivos asociados al desarrollo en tiempo real y depurar y validar los mismos a través de ésta.
101
Capitulo 6.- Seguimiento y Control de la Plataforma de Gestión
KPI-%ADDS 120
100
80
60
40
20
0 muestra1 muestra2 muestra3 muestra4 muestra5 muestra6 muestra7 muestra8
Muestra Objetivo Aceptación Esperado
Figura 6.10.- Representación grafica KPI %ADDS. Fuente: Elaboración propia.
6.3. Apreciaciones Generales.
En líneas generales la aplicación de los siete indicadores clave de rendimiento fue exitosa, puesto que todos permitieron dar respuesta a las interrogantes que fueron definidas, y si además se considera que tanto los valores esperados, como los valores objetivo y de aceptación fueron determinados en base a la experiencia del profesor de la asignatura y el autor de éste trabajo, la curva real en la mayoría de los casos mostró un comportamiento similar al esperado, lo cual habla muy bien del nivel que tienen los alumnos para desempeñarse a futuro en organizaciones altamente competitivas y que demandan de un gran esfuerzo colectivo.
102
Capitulo 7.- Conclusiones
Capítulo 7.- Conclusiones.
7.1. Del Trabajo de Titulo.
En el presente trabajo de título se ha presentado una de las problemáticas que más afecta el desarrollo de software, tanto en las organizaciones de desarrollo del mismo, como en la asignatura de Ingeniería de Software que se dicta en la carrera de Ingeniería Civil en Computación e Informática de la Universidad de Atacama, y como a través de una plataforma tecnológica de Gestión de Proyectos Open Source, se logra minimizar el impacto o aparición de dicha problemática. Para ello fue necesario realizar una investigación que permitiese validar dicha hipótesis. La investigación de las variables que influyen en la gestión de un proyecto de software fue clave, ya que, permitió validar la moción de los expertos acerca de que el principal problema en el desarrollo de productos software se basa en la mala gestión que se tiene con éstos.
La investigación, análisis y comprensión del funcionamiento de las diferentes plataformas de gestión de proyectos Open Source, fue fundamental a la hora de seleccionar la herramienta tecnológica más adecuada para implementar en la asignatura de Ingeniería de Software, ya que, en primera instancia permitió la creación de un modelo de integración el cual ilustra la manera en que una plataforma de gestión de proyectos se integra con un modelo de desarrollo de software, para posteriormente escoger una herramienta genérica que de soporte a dicha integración, con cualquiera de los diferentes modelos de desarrollo de software vigentes.
Para llevar a cabo la aplicación de la plataforma tecnológica de gestión de proyectos, el autor debió realizar una investigación sobre las metodologías actuales de descubrimiento de datos y reportabilidad JIT, obteniendo como resultado el concepto de KPI, a través del cual y por medio de un grupo de KPI’s, se logró implementar de manera exitosa la plataforma tecnológica de gestión de
103
Capitulo 7.- Conclusiones proyectos. Garantizando de esta manera, obtener los factores reales que inciden en la no consecución de los objetivos planteados por el equipo de desarrollo, en el proyecto de Ingeniería de Software. En base a lo anterior se da por satisfecho el objetivo general de este trabajo de título el que consistía en aplicar una plataforma tecnológica Open Source que sirviera de apoyo a la gestión del proyecto de software que se realiza en la asignatura de Ingeniería de Software. De la misma manera se dan por cumplidos los objetivos específicos de este trabajo de título que consistían en la investigación de las variables que inciden en la gestión de un proyecto de software, las diferentes plataformas de gestión de proyectos Open Source y la selección de una de estas. Además de la creación de un modelo de integración de la plataforma seleccionada con un modelo de desarrollo de software y finalmente aplicar la plataforma y el modelo al proyecto de la asignatura de Ingeniería de Software.
7.2. De la Experiencia Personal.
Se han fortalecido los conocimientos adquiridos en los dos últimos años de carrera, que están enfocados particularmente al área de gestión, puesto que se ha debido trabajar con un equipo humano, al cual se debió motivar e incentivar a usar la plataforma de gestión de proyectos, sin la intervención directa del académico a cargo de la asignatura.
Otro aspecto importante a destacar es lo que respecta, a la creación de mecanismos de evaluación sólidos y consistentes, para determinar específicamente cuál era la mejor plataforma tecnológica a utilizar en la asignatura, actividad (mecanismos de evaluación) que es común para ingenieros en ejercicio, lo que lo transformó en un desafío atractivo y que fue superado a cabalidad y con excelentes resultados, puesto que sirvió de guía para un trabajo de título paralelo.
104
Capitulo 7.- Conclusiones
Sin embargo, se destaca la importancia que tuvo el inmiscuirse en el fantástico mundo de la reportabilidad “Justo a Tiempo” , puesto que para lograr realizar seguimiento y control del uso de la plataforma tecnológica, se debió recurrir a mecanismos validados ya por la Inteligencia de Negocios, como lo son los indicadores clave de rendimiento (KPI), que presentaron todo un desafío, puesto que se debió crear un grupo de KPI’s, para los cuales se debió realizar un análisis de la base de datos de la plataforma, de manera de obtener datos confiables que diesen sustento a los KPI’s definidos.
Al final lo más grato de este trabajo de título, fue la oportunidad de trabajar en un área tan fascinante del mundo informático que es “el desarrollo de software”.
7.3. De los Trabajos Futuros.
Con respecto a futuras aplicaciones de la plataforma de gestión en el taller de la asignatura de Ingeniería de Software, se recomienda realizar un ajuste de las curvas esperadas para cada uno de los KPI’s definidos en este trabajo de título, para de esta forma tener curvas esperadas en base a antecedentes históricos de la asignatura. Así como también un cambio en el enfoque, ya sea objetivo u interrogantes que se definieron para los KPI %UMCI y %UMM, en caso contrario se recomienda no realizar seguimiento a la plataforma con estos KPI’s, puesto que de este trabajo de título se concluyo que no son un aporte a la colaboración dentro de gestión del proyecto de desarrollo de software.
105
Referencias Bibliográficas
Referencias Bibliográficas
Libros
1. Pressman, R., “Ingeniería del Software, un enfoque práctico”, 5ta Edición, Editorial McGraw-Hill, año 2002.
2. Robbins Stephen. “Comportamiento Organizacional”. 10 ma Edición, Editorial Prentice-Hall, año 2004.
3. Cantone, D., “Implementación y Debugging”, 1 ra edición, Editorial USERS, año 2006.
4. Fenton, N, “Software Metrics: a Rigorous and Practical Approach”, Editorial PWS PublishingCompany, año 1997.
Sitios web
1. Senne, D http://ezinearticles.com/?7-Reasons-Your-Software- Development-Company-Should-Work-on-Getting-a-CMMI- Rating&id=739367 , última visita diciembre de 2010.
2. Delgado, J., “Administración de proyectos-Ciclo de vida del proyecto”, http://www.monografias.com/trabajos38/ciclo-vida-proyecto/ciclo-vida- proyecto.shtml , última consulta diciembre de 2010.
3. Toledo, R., “Administre mejor sus proyectos, 12 pasos básicos para el éxito”, http://www.project-am.net/panama/content/view/8/1/ , última consulta diciembre de 2010.
4. Navegapolis., “¿Por qué fracasan los proyectos?”, http://www.navegapolis.net/content/view/701/49/ , última consulta diciembre de 2010.
5. Eckerson, W., “Diez características básicas de un buen KPI” http://www.gi.com.do/pdf/kpi.pdf , última consulta diciembre de 2010.
106
Referencias Bibliográficas
Otros Artículos
1. Boyd, A., “The five maxims project satisfaction”, revista Aslib Proceedings, año 2001.
2. Caballero, O., “TIC y herramientas de gestión de proyectos”, Volumen 6, Editorial DGSCA-UNAM, año 2006.
107
Anexos
Anexo A - Informe de requisitos para de implementación del Sistema Web de Control y Seguimiento de Trabajos de Titulo (SWT).
1. Objetivos del Documento
1.1. Propósito y Alcances
El presente documento constituye el informe preliminar base correspondiente a la etapa de Análisis del Proyecto Sistema Web de Control y Seguimiento de Trabajos de Titulo (SWT) . Esta información se toma como punto de partida para que el equipo de desarrollo pueda realizar el análisis, diseño y construcción del sistema mencionado.
1.2. Objetivo General
El presente documento tiene por finalidad entregar al equipo de desarrollo la idea general y condiciones que deberán tener en cuenta para el desarrollo del proyecto de Sistema Web de control y Seguimiento de Trabajos de Títulos.
2. Antecedentes Generales
2.1. Situación Actual
Actualmente el DIICC cuenta con un sistema de control de los trabajos de titulación, desarrollado en una aplicación de escritorio, con base de datos Access que mantiene el registro y control de todos los trabajos de títulos desarrollados para los alumnos de Ingeniería Ejecución e Ingeniería Civil en Computación e Informática.
A través de este sistema, el Coordinador de Trabajos de Titulo, mantiene el seguimiento de los eventos más importantes dentro de la realización de los respectivos trabajos de título, entre estos es posible mencionar:
108
Anexos
1. Fecha y comentarios de la revisión del anteproyecto por parte del Comité de trabajos de Titulación. 2. Fecha y notas que la Comisión evaluadora le asigna luego de haber revisado el documento escrito. 3. Fecha, lugar, hora, notas y comentarios del examen de grado del alumno. Si bien el sistema existente cumple satisfactoriamente con lo requerido, desde su desarrollo (2005) hasta el momento han surgido una serie de nuevos requerimientos para mejorar la gestión de los procesos de fin de estudios de los alumnos de la carrera.
Dentro de los nuevos requerimientos que es necesario incorporar a la aplicación están:
1. Diseñar perfiles de acceso (Administrador, profesor guía, Comisión, académico y alumno) 2. Mantener bitácoras que registren el trabajo de los alumnos con sus profesores guías permitiendo adjuntar los documentos relacionados. 3. Generar automáticamente algunos documentos del proceso, tales como: cartas de revisión por parte de la comisión, carta con la evaluación realizada por la comisión, protocolo del examen de grado, etc. Finalmente, todo el proceso antes descrito se encuentra formalizado en el Reglamento de finalización de estudios de la carrera.
2.2. Aplicaciones Futuras
La idea de implementar este sistema radica en tener disponible una fuente de información confiable que esté disponible por todos los actores involucrados en el desarrollo de los trabajos de título y permita cierta independencia de esta información al Coordinador de Trabajos de Titulo.
109
Anexos
3. Requerimientos de Usuario
Los requerimientos de información que a continuación se detallan, fueron definidos a partir de experiencias, ideas y sugerencias aportadas durante todo el tiempo en que el otro sistema se ha encontrado funcionando.
3.1. Información de Entrada
A continuación se presentan algunos requerimientos de información de entrada:
• Ingreso de Información de los alumnos. • Ingreso de académicos • Ingreso de Carreras. • Ingreso de Anteproyectos de Trabajo de título. • Ingreso de Fechas importantes del proceso. • Ingreso de Comentarios en cada etapa del proceso. • Ingreso de Notas en las distintas etapas del proceso. • Etc.
3.2. Información de Salida
Los informes, reportes y consultas que se deseen obtener a partir de la información de entrada, tendrán un formato que el cliente especificará en las distintas entrevistas que para ese efecto se realicen.
A continuación se presentan algunos requerimientos de información de salida:
• Listados de carreras • Listado de alumnos por carrera • Reporte de Proyectos de Trabajo de título según criterios.
110
Anexos
• Reporte con la información relativa a cada etapa del proceso. • Cartas formales relativas al proceso. • Protocolo de examen de grado • Etc.
3.3. Requerimientos de Control
El objetivo del Control, es mantener información relevante e importante para proporcionar y actualizar la información necesaria en la toma de decisiones.
Las necesidades de información son:
• Mantener información actualizada e histórica, debidamente procesada. • Obtener información consolidada. • Obtener información resumida de gestión administrativa, generada con el sistema. • Etc.
3.4. Requerimientos Operacionales
El sistema deberá:
• Ser implementada en una plataforma Web con control de acceso. • Considerar una interfaz amigable y de fácil uso para el usuario. • Proveer un ambiente de consultas dinámicas • Permitir llevar los datos a otra herramienta de escritorio (Word, Excel, etc.). • Manejar una Base de Datos robusta. • Etc.
111
Anexos
3.5. Requerimientos Administrativos
El sistema deberá:
• Permitir la actualización (ingreso, modificación y eliminación) de la información. • Permitir la generación de resultados en forma automática (Informes, Consultas, Reportes etc.). • Permitir el acceso a las aplicaciones en forma restringida (crear perfiles de usuario).
3.6. Requerimientos de Manejo del Sistema
El sistema de información requerido debe considerar los siguientes aspectos:
• Facilidad de uso para los usuarios. • Registrar información en una base de datos integrada y segura. • Controlar la calidad de la información de entrada al sistema computacional, realizando las validaciones correspondientes. • Capacidad de realizar consultas en línea de la información, permitiendo la obtención de resultados en pantalla e impresora.
4. Formas de Trabajo y Evaluación
4.1. Grupo de Trabajo
Los alumnos formarán un equipo de trabajo que deberá desarrollar un proyecto software web durante los meses restantes del semestre. A cada equipo, se le asignará un “Jefe de Equipo” quién deberá liderar y gestionar los recursos para cumplir las metas impuestas.
112
Anexos
4.2. Lenguajes y motor de BD
El proyecto será desarrollado como una aplicación WEB utilizando PHP como lenguaje de programación y MySQL como motor de base de datos.
Los códigos fuentes deberán ser entregados junto a la documentación el mismo día de la entrega de cada una de las etapas.
4.3. Fechas importantes del proyecto
Las fechas importantes a considerar en el desarrollo del software son los siguientes:
• 07-10-2010: Inicio del proyecto y entrega del documento preliminar de requisitos. • 28-10-2010 : Entrega del Documento “Especificación de Requisitos de software” + “Documentación del proyecto” • 18-11-2010 : Exposición primer avance + muestra del prototipo de solución. • 02-12-2010 : Exposición segundo avance + muestra del prototipo de solución instalado en los servidores DIICC. • 16-12-2010 : Entrega del Sistema completo + Documentación asociada (Informe general del proyecto + Manual de usuario + Manual de Instalación del sistema) + Código fuente + script de la base de datos.
113
Anexos
Anexo B.- Instalación y uso de la Plataforma de Gestión de Proyectos .
8.1. Instalación de la plataforma .
Para comenzar con la instalación se requiere alojar los archivos de instalación en el servidor. Una vez que se han cargado los archivos de instalación en el servidor y dados los permisos correspondientes , se procede a iniciar la instalación de la plataforma , escribiendo en el navegador la dirección http://www.gproyectos.inf.uda.cl/install.php , tal como se aprecia en la Figura B.1.
Figura B.1. - Dirección de instalación en el navegador. Fuente: http://www.gproyectos.inf.uda.cl.
Luego de escoger el idioma español, el instalador de la plataforma comprobara si el servidor tiene instalado PHP versión 5 y si los archivos del directorio de la plataforma tienen permiso de escritura, si todo esta correcto el navegador mostrara una imagen similar a la de la Figura B.2.
Figura B.2.- Requisitos de la instalación. Fuente: http://www.gproyectos.inf.uda.cl.
114
Anexos
Junto con los requisitos de la instal ación se encuentra la configuración de la base de datos, en este punto en particular se requiere previamente la creación de una base de datos en el servidor, utilizando el motor de base de datos MySQL . Luego se procede a ingresar el nombre del servidor, el nombre de la base de datos, el usuario de la base de datos y la contraseña de este último, tal como lo muestra la Figura B.3.
Figura B.3. - Configuración de la Base de Datos. Fuente: http://www.gproyectos.inf.uda.cl.
Hecho esto se procede a indicar el no mbre del administrador de la plataforma tecnológica, junto con la contraseña asociada a éste. La Figura B.4 ilustra lo mencionado anteriormente.
Figura B .4.- Cuenta de Administrador. Fuente: http://www.gproyectos.inf.uda.cl.
115
Anexos
Finalmente el instalador de l a plataforma, informa que la instalación se realizo exitosamente, tal como se aprecia en la Figura B.5 y se está en condiciones de iniciar sesión por primera vez en la plataforma. Puesto que solo existe la cuenta de administrador, son los datos de éste lo s que se deben proporcionar en la interfaz de inicio de sesión que se muestra en la Figura B.6.
Figura B.5. - Finalizando la Instalación. Fuente: http://www.gproyectos.inf.uda.cl.
Figura B.6.- Iniciar Sesión. Fuente: http://www.gproyectos.inf.uda.cl.
Una vez iniciada la sesión en la plataforma, el administrador podrá observar el escritorio de administración, el cual es similar al que se muestra en la Figura B.7.
116
Anexos
Figura B.7. - Escritorio de Administración. Fuente: http://www.gproyectos.inf.uda.cl.
8.2. Descripción de la plataforma .
La descripción de la plataforma será dividida en dos partes:
• Interfaz o escritorio de Administración. • Interfaz o escritorio de Usuario.
8.2.1. Escritorio de Administración .
La única diferencia entre ambos escritorios es el control Administración del menú principal, que solo aparece en la interfaz del usuario Administrador, por cual en esta sección se explicara el menú que se muestra en la Figura B.8.
Figura B.8.- Menú principal. Fuente: http://www.gproyectos.inf.uda.cl.
117
Anexos
El menú de la Figura B.8 se compone de cuatro controles que se describen en la Tabla B.1.
Tabla B.1.- Menú principal. Fuente: http://www.gproyectos.inf.uda.cl. Ícono control
Escritorio
Mi Cuenta
Administración
Cerrar Sesión.
Escritorio: al hacer clic sobre el control Escritorio, la plataforma muestra una interfaz similar a la Figura B.7.
Mi Cuenta: al hacer clic sobre el control Mi cuenta, la interfaz cambiará a una interfaz similar a la que se muestra en la Figura B.9. En la Figura B.9 se distingue un tabcontrol que se describe en la Tabla B.2.
En el tabpage “Mi cuenta” de la Figura B.9 se puede ver la información asociada al usuario, así como también la posibilidad de ver los proyectos en los que está participando y la cantidad de horas trabajadas del usuario “Administrador” por proyecto. Para editar la información del usuario, se debe hacer clic en el tabpage “ Editar” de la Figura B.9 y se verá el formulario que se muestra en la Figura B.10.
118
Anexos
Figura B.9.- Mi cuenta. Fuente: http://www.gproyectos.inf.uda.cl.
Tabla B.2.- tabcontrol Mi cuenta. Fuente: http://www.gproyectos.inf.uda.cl. Ícono tabpage
Mi Cuenta.
Editar
119
Anexos
Figura B.10.- tabpage Editar. Fuente: http://www.gproyectos.inf.uda.cl.
Administración: al pasar el puntero del mouse sobre el control Administración, se despliega el submenú que se muestra en la Figura B.11.
Figura B.11.- Submenú administración. Fuente: http://www.gproyectos.inf.uda.cl.
El submenú de la Figura B.11 se compone de tres controles , los cuales se describen en la Tabla B.3.
120
Anexos
Tabla B.3.- Submenú administración. Fuente: http://www.gproyectos.inf.uda.cl. Ícono control
Administrar proyectos
Administrar usuarios
Configuración del sistema
Para que la plataforma pueda dar soporte a la gestión del proyecto de desarrollo de software de la asignatura de Ingeniería de Software se necesita que se realicen en primera instancia las siguientes tareas:
• Creación de papeles (roles) a desempeñar dentro del equipo. • Creación de los integrantes del equipo de desarrollo. • Creación del proyecto de desarrollo.
8.2.1.1. Creación de papeles a desempeñar dentro del equipo.
Para comenzar con la creación de los roles se debe hacer clic en el control Administrar usuarios de la Figura B.11 y se despliega en pantalla un nuevo tabcontrol que contiene tres tabpage con las mismas opciones del submenú de la Tabla B.2, la Figura B.12 muestra el tabpage Administrar usuarios en donde se distinguen los módulos:
• Administrar usuarios. • Papeles (roles).
Se puede notar que el módulo Administrar usuario solo contiene al Administrador y que el módulo Papeles trae por defecto los roles de Cliente, Usuario y Administrador .
121
Anexos
Figura B.12.- tabpage Administrar Usuarios. Fuente: http://www.gproyectos.inf.uda.cl.
Por tanto se procede entonces a hacer clic en el botón Añadir papel del módulo Papeles , luego de ello se despliega el formulario que se muestra en la Figura B.13, a través del cual se podrá añadir un nuevo rol y cuáles serán las diferentes autorizaciones (Añadir- Editar- Borrar- Cerrar) que podrá realizar dicho rol, sobre los diversos módulos que presenta la plataforma, el hecho de no seleccionar ninguna autorización significa que no tiene derechos a utilizar dicho módulo.
Una vez que se añaden los roles, el tabpage Administrar usuarios en su módulo Papeles mostrara los roles recién añadidos a la plataforma, tal como se aprecia en la Figura B.14.
122
Anexos
Figura B.13.- Añadir nuevo rol. Fuente: http://www.gproyectos.inf.uda.cl.
Figura B.14.- Listado de roles. Fuente: http://www.gproyectos.inf.uda.cl.
123
Anexos
8.2.1.2. Creación de los integrantes del equipo de desarrollo.
Siguiendo en el tabpage Administrar usuarios de la Figura B.12, se procede a crear un nuevo usuario en la plataforma, para ello se debe hacer clic en el control Añadir Usuario del módulo Administrar usuarios luego de ello se despliega el formulario que se muestra en la Figura B.15, donde se procede a registrar en la plataforma a los integrantes del equipo de desarrollo. Se puede notar que no existe ningún control asociado al Label Proyectos , esto se debe a que aún no se ha creado ningún proyecto. De la misma manera se distingue a primera vista el conjunto de RadioButton que contienen los roles registrados anteriormente, más los roles por defecto que trae la plataforma.
Cabe destacar que cuando los usuarios inicien sesión podrán editar su cuenta, proporcionando nuevos datos y aumentando el nivel de seguridad de su cuenta al cambiar la contraseña, tal como se vio en la Figura B.10.
Figura B.15.- Añadir un Nuevo Usuario. Fuente: http://www.gproyectos.inf.uda.cl.
124
Anexos
Una vez que se ha terminado de añadir los integrantes del equipo de desarrollo en la plataforma, el tabpage Administrar usuarios de la Figura B.12, habrá cambiado por completo y se verá como el de la Figura B.16.
Figura B.16.- tabpage Administrar Usuarios final. Fuente: http://www.gproyectos.inf.uda.cl.
8.2.1.3. Creación del proyecto de desarrollo.
Para crear un proyecto se debe hacer clic en el control Administrar proyectos de la Figura B.11, la Figura B.17 muestra el tabpage Administrar proyectos , donde se destaca el módulo Proyectos Activos, el cual contiene los siguientes controles:
125
Anexos
• Añadir proyecto: permite agregar un nuevo proyecto a la plataforma. • Proyectos completados: muestra una lista de los proyectos finalizados.
Figura B.17.- tabpage Administrar proyectos. Fuente: http://www.gproyectos.inf.uda.cl.
Luego entonces se hace clic sobre el control Añadir proyecto y se procede a registrar el proyecto de desarrollo, la Figura B.18 muestra el formulario contenido en el módulo Proyectos activos, a modo de ejemplo se ha creado un proyecto ficticio, sobre el cual se irá describiendo la plataforma en las siguientes secciones.
Cerrar sesión: al hacer clic sobre el control Cerrar Sesión, la plataforma finaliza la sesión y retorna a la interfaz de inicio de sesión de la Figura B.6.
126
Anexos
Figura B.18.- Añadir proyecto. Fuente: http://www.gproyectos.inf.uda.cl.
8.2.2. Escritorio de Usuario.
Como se menciono en la sección anterior, el menú principal del Escritorio de Usuario no contiene el control Administración de la Figura B.8, tal como se muestra en la Figura B.19.
Figura B.19.- Menú principal usuario. Fuente: http://www.gproyectos.inf.uda.cl.
La funcionalidad de los tres controles sigue siendo la misma que se explico en la sección anterior, por tanto una vez iniciada la sesión de usuario, éste podrá observar una interfaz similar a la Figura B.20, donde destacan estos tres módulos:
127
Anexos
• Mis proyectos. • Mis tareas. • Mis Mensajes.
Figura B.20.- Interfaz de usuario. Fuente: http://www.gproyectos.inf.uda.cl.
Cabe destacar que el proyecto que se creó anteriormente y al cual pertenece el usuario Orlando Bolados, es ficticio y las tareas e hitos que se han creado no representan la realidad, solo serán objeto de estudio para describir de mejor forma la plataforma. Como se aprecia en la Figura B.20 el proyecto lleva un avance del 44%, ya que han sido ingresados la mayoría de hitos y tareas, así como también el control del tiempo de cada integrante del equipo que trabaja sobre una determinada tarea.
128
Anexos
Por otra parte los módulos mencionados anteriormente están contenidos en el tabcontrol que se muestra en la Figura B.21. Éste tabcontrol está compuesto de cuatro tabpage que se describen en la Tabla B.4. Cabe destacar que el tabcontrol escritorio es el mismo para el Administrador.
Figura B.21.- tabcontrol escritorio. Fuente: http://www.gproyectos.inf.uda.cl.
Tabla B.4.- tabpage del tabcontrol escritorio. Fuente: http://www.gproyectos.inf.uda.cl. Ícono tabpage
Escritorio
Mis proyectos
Mis tareas
Mis mensajes
Escritorio: al hacer clic sobre éste tabpage, se despliega en pantalla el contenido de la Figura B.20.
Mis Proyectos: al hacer clic sobre éste tabpage, se muestra en pantalla todo su contenido, la Figura B.22 muestra el tabpage Mis proyectos .
Cabe destacar que el módulo proyectos activos, contiene los proyectos en los cuales está participando y participó el usuario, si se hace clic sobre el nombre del proyecto, se accede a un módulo especial que contiene toda las actividades de gestión asociadas al proyecto, la sección 1.3.3 describe en profundidad dicho módulo.
129
Anexos
Figura B.22.- tabpage Mis proyectos. Fuente: http://www.gproyectos.inf.uda.cl.
Mis tareas: al hacer clic sobre éste tabpage, se muestra en pantalla todo su contenido, la Figura B.23 muestra el tabpage Mis tareas .
Figura B.23.- tabpage Mis tareas. Fuente: http://www.gproyectos.inf.uda.cl.
En la Figura B.23 se puede distinguir que el módulo contenido tiene el nombre del proyecto “Sistema de Control de Pacientes”, esto es porque éste módulo pertenece al módulo de la sección 1.3.3, por tanto el tabpage Mis tareas muestra solamente las tareas asociadas al usuario, en los diferentes proyectos en los que puede estar participando. En éste módulo no se recomienda añadir tareas ya que las tareas deben pertenecer a una lista de tareas. En la sección 1.3.3 se explicara la manera de añadir tareas y como cerrarlas una vez que se ha concluido con dicha tarea.
Mis mensajes: al hacer clic sobre éste tabpage, se muestra en pantalla todo su contenido, la Figura B.24 muestra el tabpage Mis mensajes .
130
Anexos
Figura B.24.- tabpage Mis mensajes. Fuente: http://www.gproyectos.inf.uda.cl.
Al igual que el tabpage anterior el módulo contenido “Sistema de Control de Pacientes” es parte de un módulo mayor, detallado en la siguiente sección.
A diferencia del tabpage anterior desde éste módulo se pueden enviar menajes al resto de los miembros del proyecto, para ello se debe hacer clic en el control Añadir mensaje y se despliega en pantalla un formulario contenido en el módulo “Sistema de Control de Pacientes”, similar al de la Figura B.25.
Como se aprecia en la Figura B.25, el mensaje enviado puede contener archivos adjuntos, puede llevar una etiqueta que lo asocie a un proyecto, para de esta manera tener un mejor control, sobre todo si se participa en más de un proyecto a la vez. Finalmente el mensaje puede estar asociado a un hito. Luego de hacer clic en el control Enviar, el tabpage Mis mensajes muestra el nuevo mensaje enviado, tal como se aprecia en la Figura B.26.
131
Anexos
Figura B.25.- Formulario mensajes. Fuente: http://www.gproyectos.inf.uda.cl.
Figura B.26.- tabpage Mis mensajes. Fuente: http://www.gproyectos.inf.uda.cl.
En la siguiente sección veremos cómo un mensaje puede enviarse a un usuario en particular y no a todos los miembros como en este caso.
8.2.3. Modulo de gestión del proyecto.
Como se menciono en la sección anterior al hacer clic en el nombre del proyecto, que está contenido en el módulo Mis proyectos de la Figura B.20, se puede acceder al módulo de gestión del proyecto, la Figura B.27 muestra dicho procedimiento.
132
Anexos
Figura B.27.- Accediendo al módulo de gestión del proyecto. Fuente: http://www.gproyectos.inf.uda.cl.
El módulo de gestión del proyecto contiene un tabcontrol, que se muestra en la Figura B.28.
Figura B.28.- tabcontrol módulo de gestión del proyecto. Fuente: http://www.gproyectos.inf.uda.cl.
Éste tabcontrol contiene siete tabpage, que se detallan en la Tabla B.5.
Tabla B.5.- tabpage del tabcontrol módulo de gestión del proyecto. Fuente: http://www.gproyectos.inf.uda.cl.
Ícono tabpage
Proyecto
Hitos
Lista de tareas
Mensajes
Archivos
Usuario
Control de tiempo
133
Anexos
En las siguientes sub secciones se describirán cada uno de los tabpage mencionados en la Tabla B.5, con sus respectivos módulos.
8.2.3.1. tabpage Proyecto.
Una vez que el usuario ha ingresado al módulo de gestión de proyectos, la interfaz de usuario cambia y se podrá observar en pantalla una interfaz similar a la que se muestra en la Figura B.29.
En la Figura B.29 se puede observar que existen tres módulos contenidos en el tabpage Proyecto:
• Calendario. • Control de Tiempo. • Actividad.
Además de un tablero o panel de control, donde se describe el proyecto actual y los días que faltan para finalizar dicho proyecto, además de un control visual que permite ver el grado de avance del proyecto en porcentaje.
134
Anexos
Figura B.29.- Modulo de gestión del proyecto. Fuente: http://www.gproyectos.inf.uda.cl.
135
Anexos
8.2.3.1.1. Modulo Calendario.
El calendario muestra las tareas e hitos pendientes, resaltando la fecha actual (3 de agosto de 2010) de un color celeste, como se aprecia en la Figura B.29. La Tabla B.5 describe los dos controles que se muestran en el calendario.
Tabla B.5.- Controles del Calendario. Fuente: http://www.gproyectos.inf.uda.cl. Ícono Acción
Representa las tareas a finalizar en el día.
Representa los hitos a finalizar en el día.
En la Figura B.29 se puede ver que el día 2 de agosto, debía finalizar una tarea, para recordar de que se trata se debe hacer clic sobre él ícono, y se despliega en pantalla un cuadro de dialogo con el contenido de dicha tarea atrasada, tal como se observa en la figura B.30.
Figura B.30.- Detalle tareas en el calendario. Fuente: http://www.gproyectos.inf.uda.cl.
La fuente de la tarea de la Figura B.30 está con color rojo, ya que se encuentra atrasada, la manera de mostrar las otras tareas presentes en el calendario es similar, el color de la fuente vuelve a ser azul siempre y cuanto los días para finalizar la tareas sean mayores o iguales a cero.
136
Anexos
De la misma manera en que se puede ver el detalle de una tarea en el calendario, se puede hacer con un hito, la Figura B.31 muestra el detalle del hito presente en el calendario el día 27 de agosto.
Figura B.31.- Detalle hitos en el calendario. Fuente: http://www.gproyectos.inf.uda.cl.
8.2.3.1.2. Modulo Control de tiempo.
En este módulo los usuarios podrán registrar el tiempo que invierten diariamente para el desarrollo de una tarea. A modo de ejemplo, supondremos que la tarea del día 2 de agosto (ver Figura B.30) finalizara este día (3 de agosto) y el usuario responsable de dicha tarea (Diseñador) hará uso del módulo Control de tiempo para registrar el tiempo invertido en la tarea.
Cuando otros usuarios inicien sesión en la plataforma (como en este caso) la interfaz que verán es la misma que la de la Figura B.20, con la diferencia de que el módulo Mis Tareas contiene las tareas asociadas a cada usuario en particular. Como se puede apreciar en la Figura B.32, el módulo contiene las tareas del Diseñador, en cambio en la Figura B.20 el módulo contiene las tareas del Jefe de Equipo.
Figura B.32.- Mis tareas: los usuarios pueden visualizar solo sus tareas. Fuente: http://www.gproyectos.inf.uda.cl.
137
Anexos
Siguiendo con el ejemplo anterior, el usuario Diseñador tiene una tarea atrasada en 1 día (ver Figura B.32) y como se menciono ya la ha terminado, por tanto es hora de registrar el tiempo invertido en dicha tarea. Para ello entonces el Diseñador debe llevar a cabo el procedimiento mostrado en la Figura B.27, para ingresar los datos. La Figura B.32 muestra el uso de dicho módulo por este usuario.
Figura B.33.- Control de tiempo en tarea Interfaz de Usuario . Fuente: http://www.gproyectos.inf.uda.cl.
En la Figura B.33 se pueden ver dos registros de control de tiempo:
• día 2 de agosto de 2010. El usuario Diseñador ingreso el tiempo que invirtió en la tarea Interfaz de Usuario , agregando un comentario que es opcional
138
Anexos
en donde describe que aún le falta un 20% para terminar la tarea que finaliza el día 2 de agosto. • día 3 de agosto de 2010. El usuario Diseñador ingreso el tiempo que invirtió en la tarea Interfaz de Usuario , y con ello debe dar por finalizada la tarea, más adelante se verá la manera de cerrar las tareas que se terminaron.
La idea de mostrar dos registros en la Figura B.33 es porque el control del tiempo es independiente del día que debe finalizar la tarea, es decir que un usuario puede tener más de un día (dia.mes.año) de trabajo asociado a una tarea específica, ya que los involucrados en terminar la tarea, más el responsable de ésta, deben comenzar al menos una semana antes de que finalice la tarea y estos tiempos deben ser registrados.
8.2.3.1.3. Modulo Actividad.
En este módulo los usuarios podrán ver las actividades relacionadas al proyecto y quien realizo dicha acción, la Figura B.34 muestra el registro de las últimas actividades asociadas al proyecto incluyendo los dos registros de la Figura B.33.
Figura B.34.- Modulo Actividad. Fuente: http://www.gproyectos.inf.uda.cl.
139
Anexos
8.2.3.2. tabpage Hitos.
Para acceder al tabpage Hitos se debe hacer clic sobre él y se podrá observar su contenido en pantalla, tal como se aprecia en la Figura B.35. Una vez dentro se puede ver el módulo llamado Hitos. En este módulo se puede distinguir tres litas de Hitos:
• Hitos. Contiene la lista con Hitos que no han ocurrido. • Hitos retrasados. Contiene la lista con los Hitos retrasados. • Hitos completados. Contiene la lista con hitos ocurridos.
Figura B.35.- tabpage Hitos. Fuente: http://www.gproyectos.inf.uda.cl.
140
Anexos
Además se distinguen los controles:
• Añadir hito.
Al hacer clic sobre el control, se despliega el formulario de la Figura B.36. • Hitos completados. Al hacer clic sobre el control, se cierra o se abre la lista con hitos completados, que se muestra en la Figura B.35.
8.2.3.2.1. Añadir hito.
Para agregar un nuevo Hito , existen dos formas de hacerlo:
• A través del módulo Calendario del tabpage Proyectos. Al hacerlo de esta manera, se debe hacer clic sobre el numero (día) del calendario donde se desea agregar el nuevo Hito y presionar la opción “ Añadir Hito ”, tal como se muestra en la Figura B.36.
Figura B.36.- Añadir Hito al proyecto. Fuente: http://www.gproyectos.inf.uda.cl.
• Haciendo clic en el control Añadir hito de la Figura B.35
141
Anexos
Luego de hacer clic en el control “ Añadir Hito ”, se despliega el formulario asociado para ingresar el nuevo hito. La figura B.38 muestra dicho formulario.
Figura B.38.- Añadir Hito al proyecto. Fuente: http://www.gproyectos.inf.uda.cl.
Como se recordará en la Figura B.25, el jefe de equipo envió un mensaje a los miembros del equipo solicitando su opinión con respecto a realizar actividades de integración, suponiendo que el equipo está de acuerdo con dichas actividades, el jefe de equipo ha añadido el Hito Coffe Break para el día 7 de agosto de 2010.
Luego de añadir el hito, éste será visible para todos los usuarios a través del tabpage Proyectos en el módulo Calendario (ver día 7 de agosto de 2010) y el módulo Actividad, tal como lo muestra la Figura B.39.
142
Anexos
Figura B.39.- Nuevo hito en el módulo Calendario y Actividad. Fuente: http://www.gproyectos.inf.uda.cl.
No debe olvidarse que todas las actividades asociadas a datos, ya sea ingresar datos, editar, cerrar y borrar actividades, se registran en el módulo Actividad del tabpage Proyecto, tal como se muestra en la Figura B.39.
143
Anexos
8.2.3.2.2. Cerrar hito.
Antes de comenzar a describir como cerrar un hito se deben describir los controles que permiten abrir, cerrar, editar y borrar hitos. La Tabla B.6 describe dichos controles.
Tabla B.6.- Controles especiales sobre Hitos. Fuente: http://www.gproyectos.inf.uda.cl.
Ícono Control Acción Cerrar Cierra algún hito. Editar Edita algún hito. Borrar Borra algún hito.
Abrir Abre un hito cerrado.
Por tanto una vez que el evento planificado ha concluido, éste debe cerrarse, en la Figura B.35 (módulo Hitos) se puede ver que existe un hito retrasado, para cerrar éste hito se procede a hacer clic en el control Cerrar (descrito en la Tabla B.6) de dicha Figura. La Figura B.40 ilustra lo descrito anteriormente.
Figura B.40.- Cerrar hito BD Funcional. Fuente: http://www.gproyectos.inf.uda.cl.
144
Anexos
Luego de ello el hito BD Funcional aparecerá en la lista de Hitos completados, como se muestra en la Figura B.41.
Figura B.40.- Lista de Hitos completados BD Funcional . Fuente: http://www.gproyectos.inf.uda.cl.
8.2.3.3. tabpage Listas de tareas.
Para acceder al tabpage Listas de tareas se debe hacer clic sobre él y se podrá observar su contenido en pantalla, tal como se aprecia en la Figura B.41. En esta Figura se pueden distinguir los siguientes módulos:
• Listas de tareas. Cada lista de tarea es mostrada como un módulo por separado, las listas de tareas activas son: • Implementación. • Depuración. • Validación. • Documentación. • Listas de tareas realizadas Es un módulo que contiene las listas de tareas ya concluidas, en el ejemplo las listas concluidas son: • Documento de requerimientos. • Diseño del sistema.
145
Anexos
Figura B.41.- tabpage Lista de tareas. Fuente: http://www.gproyectos.inf.uda.cl .
Si se desea ver con mayor detalle la lista de tareas, se debe hacer clic sobre el nombre de la lista, como se muestra en la Figura B.42, para que se despliegue en pantalla la lista de tareas con más detalle, como lo muestra la Figura B.43.
Figura B.42.- Acceso a Lista de tarea Implementación. Fuente: http://www.gproyectos.inf.uda.cl.
146
Anexos
Figura B.43.- Detalle Lista de tareas Implementación. Fuente: http://www.gproyectos.inf.uda.cl.
Como se observa en la Figura B.43, una lista de tareas en un conjunto de tareas agrupadas que tienen algo en común, la lista de tareas Implementación ilustra lo descrito anteriormente.
Las actividades asociadas al tabpage Listas de tareas son las siguientes: • Añadir Lista de tareas. • Añadir tareas. • Cerrar tareas. • Cerrar Lista de tareas.
8.2.3.3.1. Añadir Lista de tareas.
Al igual que en la sección anterior antes de comenzar a describir como añadir una lista de tareas se deben describir los controles que permiten abrir,
147
Anexos cerrar, editar y borrar listas de tareas y tareas. La Tabla B.7 describe dichos controles.
Tabla B.7.- Controles especiales sobre Lista de tareas. Fuente: http://www.gproyectos.inf.uda.cl. Ícono Control Acción Cerrar lista Cierra alguna lista de tareas. Editar lista Edita alguna lista de tareas. Borrar lista Borra alguna lista de tareas. Cerrar tarea Cierra alguna tarea. Editar tarea Edita alguna tarea. Borrar tarea Borrar alguna tarea Añadir tarea Añade una tarea. Añadir lista Añade una lista. Abrir Abre alguna lista o tarea
Para añadir una lista de tareas se debe hacer clic en el control Añadir lista , que se muestra en la Tabla B.7. Cabe destacar que la lista de tareas pueden o no estar asociadas a un hito, en este caso la lista de tareas estará asociada al hito “Coffe Break” que se creó anteriormente, luego de hacer clic sobre el control se despliega el formulario que se muestra en la Figura B.44, donde se da un nombre a la lista de tareas, una descripción de ésta, para finalmente asociar la lista de tareas a un Hito (Milestone) del conjunto que se muestran en el Listbox , en este caso en particular se elije “Coffe Break” y se presiona el control Añadir . La Figura B.45 muestra el resultado de dicha acción, donde se destaca la nueva lista de tarea.
148
Anexos
Figura B.44. - Añadir lista de tareas . Fuente: http://www.gproyectos.inf.uda.cl.
Figura B.45.- tabpage Lista de tareas Reuniones de Integración. Fuente: http://www.gproyectos.inf.uda.cl.
149
Anexos
8.2.3.3.2. Añadir tareas.
Una vez creada la lista que contendrá las tareas, se procede a hacer clic sobre el control Añadir tarea de la tabla B.7 o en el control presente en el módulo destacado en la Figura B.45, denominado Añadir tarea. Hecho esto se despliega el formulario que se muestra en la Figura B.46, en el cual se ingresa el nombre de la tarea, una pequeña descripción de la t area, la fecha de vencimiento y el responsable de que la tarea se ejecute correctamente.
Una vez que se agregan todas las tareas asociadas a la lista de tareas “Reuniones de Integración” y que permiten la ejecución del Hito “Coffe Break” , se podrá observar un resultado similar al de la Figura B.47.
Figura B.46.- Añadir tarea. Fuente: http://www.gproyectos.inf.uda.cl.
Figura B.47.- Añadir tarea. Fuente: http://www.gproyectos.inf.uda.cl.
150
Anexos
8.2.3.3.3. Cerrar tareas.
Como se menciono en el módulo Control de tiempo (sección 1.3.3.1.2), el Diseñador tiene la tarea Interfaz de Usuario atrasada en un día (ver Figura B.32) y se sabe que ésta finalizo el día 3 de agosto de 2010. Por tanto se está en condiciones de cerrar dicha tarea, para ello el usuario Diseñador (ya que él es el responsable de la tarea) procede a cerrar la tarea terminada haciendo clic sobre el control Cerrar tarea que se muestra en la Tabla B.7.
La Figura B.48.a muestra el procedimiento anterior realizado desde el módulo Mis tareas de la Interfaz de usuario (ver Figura B.20). En cambio la Figura B.48.b muestra el procedimiento realizado desde la lista de tareas Implementación.
Figura B.48.a.- Cerrar tarea. Fuente: http://www.gproyectos.inf.uda.cl.
Figura B.48.b.- Cerrar tarea. Fuente: http://www.gproyectos.inf.uda.cl.
151
Anexos
Finalmente la Figura B.49 muestra como la tarea recién cerrada, aparece como tarea realizada.
Figura B.49. Tarea Interfaz de Usuario finalizada. Fuente: http://www.gproyectos.inf.uda.cl.
8.2.3.3.4. Cerrar Listas de tareas.
Para cerrar una Lista de tareas se debe tener el cuidado de que las tareas contenidas por la lista, hayan sido cerradas absolutamente todas, si éste es el caso entonces se debe hacer clic sobre el control Cerrar lista que se muestra en la Tabla B.7. La Figura B.50 ilustra lo descrito anteriormente.
Figura B.50. Cerrar lista de tareas. Fuente: http://www.gproyectos.inf.uda.cl.
Como la lista de tareas Implementación aún contiene tareas por finalizar se a simulado el cierre de estas junto con el de la lista, con el propósito de facilitar el entendimiento de esta sección, aclarado esto entonces se puede decir que la Figura B.51 muestra la Lista de tareas Implementación recién cerrada.
152
Anexos
Figura B.51. Lista de tareas cerr adas. Fuente: http://www.gproyectos.inf.uda.cl.
Una vez que se han realizado todas las modificaciones sobre el tabpage Listas de tareas, el porcentaje de avance del proyecto ha variado, la Figura B.52 muestra el nuevo porcentaje de avance del proyecto.
Figura B.52. Porcentaje de avance del proyecto. Fuente: http://www.gproyectos.inf.uda.cl.
8.2.3.4. tabpage Mensajes .
Para acceder al tabpage Mensajes se debe hacer clic sobre él y se podrá observar su contenido en pantalla, tal como se aprecia en la Figura B.53. E n esta Figura se puede distinguir el módulo Mensajes que es el que contiene todos los mensajes asociados al proyecto.
Figura B.53. Tabpage Mensajes. Fuente: http://www.gproyectos.inf.uda.cl.
153
Anexos
Las tareas a realizar en el tabpage Mensajes son las siguientes:
• Añadir mansaje. • Editar mensaje. • Borrar mensaje. • Responder mensaje.
8.2.3.4.1. Añadir Mensaje.
Antes de continuar se deben describir los controles que permiten añadir, editar, borrar y responder mensajes. La Tabla B.8 describe dichos controles.
Tabla B.8.- Controles especiales sobre Mensajes. Fuente: http://www.gproyectos.inf.uda.cl. Ícono Control Acción Añadir Añade un nuevo mensaje. Responder Responder algún mensaje. Editar Editar algún mensaje. Borrar Borrar algún mensaje.
Para añadir un mensaje se debe hacer clic sobre el control mostrado en la Tabla B.8 o sobre el control Añadir mensaje que se muestra en la Figura B.53, luego de ello se despliega en el formulario que se muestra en la Figura B.54.
En la Figura B.54 el Jefe del equipo ha enviado un mensaje a todos los miembros recordando que no olviden sus responsabilidades en las tareas asociadas el hito “Coffe Break” . Además al observar la Figura B.54 se puede notar la posibilidad de adjuntar archivos y de asociar el mensaje a un hito determinado, para de esta manera tener un mejor seguimiento. En la Figura B.55 se puede ver el mensaje en lista contenida en el módulo.
154
Anexos
Figura B.54. Formulario Mensajes. Fuente: http://www.gproyectos.inf.uda.cl.
Figura B.55. Modulo mensajes. Fuente: http://www.gproyectos.inf.uda.cl.
8.2.3.4.2. Editar Mensaje.
Para editar un mensaje basta con hacer clic en el control Editar (ver Tabla B.8) de la Figura B.55 y se despliega el formulario que se muestra en la Figura B.56.
155
Anexos
Figura B.56. Modulo mensajes. Fuente: http://www.gproyectos.inf.uda.cl.
8.2.3.4.3. Borrar Mensaje.
Para borrar un mensaje basta con hacer clic en el control Borrar (ver Tabla B.8) de la Figura B.55 y se despliega un cuadro de dialogo que advierte de dicha operación, tal como se muestra en la Figura B.57.
Figura B.56. Borrar mensaje. Fuente: http://www.gproyectos.inf.uda.cl.
156
Anexos
8.2.3.4.4. Responder Mensaje.
Para responder un mensaje basta con hacer clic en el control Responder (ver Tabla B.8) de la Figura B.57 y se despliega el formulario que dar respuesta a un determinado mensaje, tal como se muestra en la Figura B.58.
Figura B.57. Responder mensaje. Fuente: http://www.gproyectos.inf.uda.cl.
Figura B.58. Formulario responder mensaje. Fuente: http://www.gproyectos.inf.uda.cl.
Como se muestra en la Figura B.59, si se quiere ver con mayor detalle el mensaje, basta con hacer clic sobre el nombre del mensaje.
Figura B.59. Formulario responder mensaje. Fuente: http://www.gproyectos.inf.uda.cl.
157
Anexos
La Figura B.60 muestra el detalle de un mensaje junto con sus respuestas, si es que éste tuviese alguna respuesta, en caso contrario el módulo Respuestas de la Figura B.60 no estará presente.
Figura B.60. Detalle mensaje. Fuente: http://www.gproyectos.inf.uda.cl.
8.2.3.5. tabpage Archivos.
Para acceder al tabpage Archivos se debe hacer clic sobre él y se podrá observar su contenido en pantalla, tal como se aprecia en la Figura B.61. En esta Figura se puede distinguir el módulo Carpeta raíz que donde se almacenaran los archivos asociados al proyecto, además se puede notar que existe la opción de crear un directorio dentro del raíz, esto muy importante ya que permitirá al equipo
158
Anexos de desarrollo mantener un orden con respecto a los archivos que se están almacenando en la plataforma.
Las actividades asociadas al tabpage Archivos son: • Añadir directorio. • Añadir archivo.
Figura B.61. Tabpage Archivos. Fuente: http://www.gproyectos.inf.uda.cl.
8.2.3.5.1. Añadir directorio.
Para añadir un directorio basta con hacer clic en el control Añadir directorio de la Figura B.61 y se despliega el formulario de la Figura B.62, donde se debe dar un nombre al directorio y una pequeña descripción, luego se dan los permisos correspondientes y finalmente se hace clic en Añadir.
Figura B.62. Añadir Directorio. Fuente: http://www.gproyectos.inf.uda.cl.
159
Anexos
Una vez añadido el directorio la Figura B.61 cambia y aparece el directorio creado anteriormente, la Figura B.63 ilustra este cambio.
Figura B.63. Nuevo Directorio. Fuente: http://www.gproyectos.inf.uda.cl.
El módulo carpeta raíz permite realizar dos acciones con los directorios contenidos: • Exportar los directorios contenidos en formato Zip. • Borrar el directorio.
Para exportar un directorio se debe hacer clic sobre el control que se destaca en la Figura B.64.
Figura B.64. Exportar Directorio. Fuente: http://www.gproyectos.inf.uda.cl.
Luego de ello se podrá descargar el directorio en formato Zip a la maquina local, tal como se aprecia en la Figura B.65
160
Anexos
Figura B.65. Descargar Directorio. Fuente: http://www.gproyectos.inf.uda.cl.
Finalmente para borrar un directorio basta con hacer clic en el control que se destaca en la Figura B.66.
Figura B.66. Borrar Directorio. Fuente: http://www.gproyectos.inf.uda.cl.
8.2.3.5.2. Añadir archivo.
Para añadir un archivo se debe hacer clic en el control Añadir archivo de la Figura B.63 y se despliega en pantalla el formulario de la Figura B.67.
En este formulario se distingue que el tamaño máximo de los archivos no debe ser superior a 8MB, además de la posibilidad de subir simultáneamente hasta 10 archivos, también se puede elegir el directorio donde se quiere alojar el archivo, también se debe dar un nombre al archivo (Titulo) para que no sea alojado como un documento sin título, cabe destacar que los formatos office soportados corresponden a versiones anteriores a office 2007 ( 97-2003). El formulario también provee la facultad de elegir que rol dentro del equipo, tendrá acceso al archivo, el primer Listbox de la Figura B.67 muestra esta característica, mientras que en el segundo Listbox se elige a que miembros del equipo de
161
Anexos desarrollo se les informara de dicha acción en el módulo chat, por medio de una etiqueta.
Figura B.67. Añadir archivo. Fuente: http://www.gproyectos.inf.uda.cl.
Una vez que el archivo se ha añadido, se puede ver su contenido por medio de la plataforma, tal como se muestra en la Figura B.68.
Figura B.68. Añadir archivo. Fuente: http://www.gproyectos.inf.uda.cl.
162
Anexos
Si se hace clic sobre él, se podrá descargar a la maquina local. Como se parecía en la Figura B.69.
Figura B.69. Añadir archivo. Fuente: http://www.gproyectos.inf.uda.cl.
Para borrar un archivo bastara solo con hacer clic en el control que se destaca en la Figura B.70.
Figura B.70. Borrar archivo. Fuente: http://www.gproyectos.inf.uda.cl.
8.2.3.6. tabpage Usuarios.
Para acceder al tabpage Usuarios se debe hacer clic sobre él y se podrá observar su contenido en pantalla, tal como se aprecia en la Figura B.71. En esta Figura se puede distinguir el módulo Miembros que contiene a todos los miembros asociados a un proyecto, al hacer clic sobre un usuario en particular, permite ver la información asociada a éste, tal como se muestra en la Figura B.72
163
Anexos
Figura B.71. Borrar archivo. Fuente: http://www.gproyectos.inf.uda.cl.
Figura B.72. Borrar archivo. Fuente: http://www.gproyectos.inf.uda.cl.
Por otro lado si el usuario que está en sesión pulsa sobre su propia cuenta en la Figura B.71, además de ver su Perfil de usuario , podrá visualizar el módulo informe visto en la sección 1.3.1 (ver Figura B.9) y el tabpage Editar (ver Figura B.10).
164
Anexos
Figura B.73. Borrar archivo. Fuente: http://www.gproyectos.inf.uda.cl.
8.2.3.7. tabpage Control de tiempo.
Para acceder al tabpage Control de tiempo se debe hacer clic sobre él y se podrá observar su contenido en pantalla, tal como se aprecia en la Figura B.74. En ésta Figura se puede distinguir el módulo Informe que lista las horas trabajadas diariamente por cada usuario, cada uno de estos tiempo puede ser editado, así
165
Anexos como también eliminados de la plataforma. Además el módulo permite exportar el informe a Excel y PDF.
Figura B.74. Borrar archivo. Fuente: http://www.gproyectos.inf.uda.cl.
Otra funcionalidad que presenta el módulo es la posibilidad de filtrar el informe, la Figura B.75 muestra la manera de acceder a dicha funcionalidad.
166
Anexos
Figura B.75. Acceso a filtro. Fuente: http://www.gproyectos.inf.uda.cl.
Después de hacer clic en el control se despliega el formulario que se presenta en la Figura B.76, donde se debe indicar la fecha inicial y final o sea desde donde hasta donde se desea filtrar una determinada tarea, en este caso en particular se escogió la tarea Interfaz de Usuario, y una vez que se hace clic en el control Filtrar aparece en pantalla el módulo informe con el total de horas trabajadas en esa tarea en particular, la Figura B.77 muestra dicho filtro.
Figura B.76. Acceso a filtro. Fuente: http://www.gproyectos.inf.uda.cl.
167
Anexos
Figura B.77. Acceso a filtro. Fuente: http://www.gproyectos.inf.uda.cl.
8.2.4. Modulo de Comunicación Instantánea y buscador.
Como se observa en la Figura B.78, existe un componente en la plataforma, que contiene dos módulos: • Buscador. • Comunicación instantánea.
Figura B.78. Acceso a filtro. Fuente: http://www.gproyectos.inf.uda.cl.
Este componente es visible para los usuarios de la plataforma durante toda la sesión (ver Figura B.7), por tanto cualquiera de los dos módulos que contiene éste componente, pueden ser usados en cualquier instante.
168
Anexos
8.2.4.1. Buscador.
Este módulo sirve para buscar proyectos, hitos y tareas rápidamente desde donde se encuentre el usuario. La Figura B.79 muestra un ejemplo en donde se quiere buscar alguna tarea, hito y/o proyecto que contenga la palabra prueba, la Figura B.80 muestra el resultado de la búsqueda.
Figura B.79. Acceso a filtro. Fuente: http://www.gproyectos.inf.uda.cl.
Figura B.80. Acceso a filtro. Fuente: http://www.gproyectos.inf.uda.cl.
Si se desea ver en detalle alguno de los resultados basta con hacer clic sobre él y se despliega en pantalla en detalle de (en esta caso) la tarea.
8.2.4.2. Comunicación Instantánea.
En la Figura B.80 se puede notar el segundo módulo que se menciono anteriormente, en él se puede ver que existen dos usuarios haciendo uso de la plataforma, la manera de comunicarse es muy simple solo se debe hacer clic en el
169
Anexos control llamada que se encuentra a la derecha del nombre, la Figura B.81 muestra la manera de iniciar la comunicación. Una vez que se hace clic se despliega en pantalla una ventana flotante con la cual ya se puede iniciar la conversación con el otro miembro del equipo. Las Figuras B.82 y B.83 muestra una conversación entre dos miembros.
Figura B.81. Acceso a filtro. Fuente: http://www.gproyectos.inf.uda.cl.
Figura B.82. Orlando habla a Valentina. Fuente: http://www.gproyectos.inf.uda.cl.
170
Anexos
Figura B.83. Valentina responde a Orlando Fuente: http://www.gproyectos.inf.uda.cl.
171