Mejoramiento del proceso de planeación y seguimiento de proyectos de desarrollo de software en pequeñas empresas

Texto completo

(1)PROYECTO DE GRADO. MEJORAMIENTO DEL PROCESO DE PLANEACIÓN Y SEGUIMIENTO DE PROYECTOS DE DESARROLLO DE SOFTWARE EN PEQUEÑAS EMPRESAS. Camilo José Rincón Figueredo 200013277 Sergio Ricardo Rodríguez Castro 200021781 Asesor: Rubby Casallas. Universidad de los Andes, Bogotá Colombia. 2005.

(2) AGRADECIMIENTOS Para el grupo Changeset por su gran aporte en todos los aspectos. En especial aquellos que trabajaron durante el segundo semestres de 2004 y primer semestre del 2005: Rubby Casallas, Ángela Lozano, Juan Pablo Quiroga, Saulo Daza, Manuel Pedraza, Carlos Duran, Eduard Zambrano, Andres Rubio, Luis Ballesteros y Diego Ramírez. También a las empresas que nos colaboraron durante esta experiencia. Igualmente a todos los que nos apoyaron durante este tiempo, nuestras familias y amigos..

(3) 1 1 2. TABLA DE CONTENIDO. Tabla de contenido ....................................................................................................... 3 INTRODUCCIÓN........................................................................................................ 5 2.1 QualDev – Changeset......................................................................................... 5 2.2 Trabajo con las empresas .................................................................................. 6 2.3 Objetivos y alcance del trabajo con las empresas ......................................... 7 3 MARCO GENERAL.................................................................................................... 8 3.1 Planes de mejoramiento de Procesos.............................................................. 8 3.2 Modelo IDEAL ...................................................................................................... 8 3.2.1 Fase de Inicialización .................................................................................. 9 3.2.2 Fase de Diagnóstico.................................................................................... 9 3.2.3 Fase de Establecimiento .......................................................................... 10 3.2.4 Fase de Ejecución ..................................................................................... 10 3.2.5 Fase de Aprendizaje ................................................................................. 11 3.3 El proceso de planeación y seguimiento ....................................................... 11 4 LEVANTAMIENTO DE INFORMACIÓN DE LOS PROCESOS ACTUALES EN LAS EMPRESAS......................................................................................................... 13 4.1 Empresa 1........................................................................................................... 13 4.1.1 Proceso de Planeación ............................................................................. 13 4.1.2 Proceso de Seguimiento........................................................................... 14 4.1.3 ¿Qué expectativas tienen?....................................................................... 14 4.2 Empresa 2........................................................................................................... 14 4.2.1 Características del trabajo encontrado................................................... 14 4.2.2 Herramientas de planeación y seguimiento utilizadas actualmente.. 14 4.2.3 Metodología ................................................................................................ 14 4.2.4 Seguimiento ................................................................................................ 15 4.2.5 Reportes ...................................................................................................... 16 4.2.6 Fallas encontradas .................................................................................... 16 5 DEFINICIÓN TRABAJO CON LAS EMPRESAS ................................................ 17 5.1 Cronograma general ......................................................................................... 17 5.1.1 Objetivos ..................................................................................................... 17 5.2 Nivel 1 .................................................................................................................. 17 5.3 Nivel 2 .................................................................................................................. 17 5.4 Nivel 3 .................................................................................................................. 18 5.5 Actividades iniciales .......................................................................................... 18 6 CASOS DE ESTUDIO ............................................................................................. 21 6.1 Empresa 1........................................................................................................... 21 6.2 Empresa 2........................................................................................................... 23 7 RESULTADOS.......................................................................................................... 26 7.1 Empresa 1........................................................................................................... 26 7.2 Empresa 2........................................................................................................... 26 8 CONCLUSIONES..................................................................................................... 28.

(4) 9. BIBLIOGRAFÍA......................................................................................................... 29.

(5) 2 INTRODUCCIÓN 2.1 QualDev – Changeset Changeset es un proyecto de desarrollo de software desarrollado en la Universidad de los Andes en Bogotá, Colombia. El proyecto tiene como fin desarrollar un software de apoyo a la administración de configuraciones, utilizando tecnología de punta y realizando un proceso de desarrollo con énfasis en calidad. Changeset ha sido desarrollado por un equipo de profesores, estudiantes de maestría y de pregrado de la Universidad de los Andes. Dada la heterogeneidad del grupo se obtienen como resultado diferentes puntos de vista, habilidades, metas y niveles de escolaridad que son fusionados para constituir un conjunto cuyas capacidades grupales exceden la suma de sus miembros individuales. Dentro del equipo se dividen todas las tareas del ciclo de desarrollo de software, desde análisis de requerimientos hasta postmortem. Esta división permite balancear la carga de trabajo entre todos los miembros y de esta forma todos participan en las labores de los diferentes niveles. Es importante resaltar que la rotación de los miembros del grupo es alta y esto nos permite el estudio y la aplicación de metodologías ágiles para equipos dinámicos. El proyecto Changeset empezó en Agosto del año 2003. Se usó como línea base una aplicación desarrollada para el curso de maestría “Calidad de software”. La aplicación, cuya funcionalidad era suficiente, carecía de una arquitectura robusta y flexible por lo cual se reorganizó dicha arquitectura en varias capas: vista, lógica y datos. Posteriormente se empezó a modificar la lógica para adecuar algunos de los patrones J2EE más importantes. En los últimos ciclos de desarrollo, desde marzo del 2004, se ha venido trabajando en la implementación de los nuevos requerimientos que añaden funcionalidad al sistema. Es importante recalcar que se hace énfasis en mantener un proceso efectivo, dinámico y que permita el trabajo de personas que se encuentran geográficamente dispersas de la mejor manera posible. Para lograr este objetivo, el equipo se apoya en herramientas que ayudan a mantener la información en línea para que se pueda consultar desde cualquier lugar vía Internet. El equipo utiliza una gran gama de herramientas dentro de las cuales se pueden resaltar las siguientes: CVS (Concurrent Version System) para el manejo del control de versiones de las fuentes del proyecto; Eclipse más una gran variedad de plug-ins, para la codificación de las fuentes del proyecto; DotProject, una herramienta web para la planeación y el seguimiento de las actividades del proyecto; y una Wiki, un sitio web en donde se consigna todo el conocimiento y las decisiones del equipo. Una de las herramientas más importantes que se utilizan para el desarrollo del proyecto es un sistema de generación de código fuente (ChangesetGeneration). Dicho software es usado para generar las fuentes y los descriptores necesarios del proyecto Changeset. El propósito es ocultar la complejidad que se encuentra detrás de las aplicaciones J2EE a los nuevos programadores. Cabe resaltar que.

(6) dicho sistema también fue desarrollado por el grupo y se desarrolló en el segundo semestre del 2004. Aunque la mayoría del tiempo es dedicado al desarrollo del producto, podemos decir que en Changeset contamos con un espacio en donde se experimenta con nuevas tecnologías, en especial con nuevas arquitecturas y herramientas. Es un espacio para que los estudiantes y profesores del equipo puedan aprender y poner a prueba dichas tecnologías desarrollando un producto innovador y de buena calidad. El presente documento recoge la experiencia del grupo Changeset de la Universidad de los Andes al migrar parte de su proceso de desarrollo de software a empresas pequeñas y medianas de Bogotá. El ejercicio fue muy interesante pues tanto las empresas como el grupo aprendieron muchas cosas. En el desarrollo del documento lo primero que vamos a hacer es los objetivos del trabajo que se realizó con las empresas. Después de esto vamos a explicar la metodología que utilizamos para la implantación de los procesos. En este caso nos basamos en el modelo IDEAL creado por el Instituto de Ingeniería de Software de la universidad Carnegie Mellon. Lo siguiente que vamos a presentar son los casos de estudio, estos se llevaron a cabo en dos empresas locales. Finalmente hacemos un análisis de los resultados obtenidos en cada una de las empresas y terminamos el documento con las conclusiones generales de esta nueva experiencia para el grupo.. 2.2 Trabajo con las empresas El trabajo con las empresas es una experiencia nueva para el equipo. El proyecto comienza en el mes de Abril del año 2005. Durante este semestre, después de probar y documentar nuestro proceso, nace la idea de ayudar a las empresas pequeñas y medianas de software de la industria nacional. Se consiguieron varias empresas interesadas en participar de esta nueva experiencia. Inicialmente se contaba con la participación de cuatro empresas, pero por motivos de fuerza mayor dos empresas no continuaron con el proceso. En este documento nos vamos a centrar en la experiencia que se obtuvo con las dos empresas restantes. El proceso de desarrollo de Changeset puede ayudar a estas empresas dado que se cuenta con un buen grado de automatización de varias actividades que suelen ser costosas. El objetivo principal del trabajo con las empresas es el de implementar nuestros procesos de forma que les sea útil y les ayude a mejorar la calidad y eficiencia de sus procesos actuales. No podríamos decir que nuestro proceso cumple con el 100% de metodologías como TSP (Team Software Process), XP (eXtreme Programming) o RUP (Rational Unified Process), sin embargo, nuestro proceso se parece mucho al de que propone Watts Humphrey con TSP. También tiene rasgos de XP pues el tiempo de cada iteración es corto y estos tienen como fin agregar nueva funcionalidad al producto. Nuestro proceso es una combinación entre TSP, XP y RUP con ciertas adaptaciones a nuestro entorno en particular. La diferencia radica en que se agregan y/o modifican procesos como: Administración de conocimiento, Administración de la.

(7) configuración, Administración del riesgo, Estabilización ambiente de desarrollo, entre otros. El uso de herramientas para soportar el proceso es lo que garantiza el éxito del mismo. Dichas herramientas se convierten en un factor fundamental para la automatización de actividades. Las herramientas, por lo general software y plantillas, ayudan a reducir los tiempos que están directamente relacionados con las tareas del proceso. Es importante resaltar que la gran mayoría de herramientas que usamos son libres. De esta forma hemos adaptado las herramientas a nuestras necesidades y hemos podido experimentar con una gran variedad de éstas. Como las herramientas son libres resultan ser muy apreciadas por las empresas pues ahorran dinero al no tener que comprar licencias costosas. Un aspecto muy importante que podemos resaltar de nuestro proceso es que contamos con un tiempo de aprendizaje relativamente corto. Manejamos un proceso de administración de conocimiento que nos ayuda a mitigar el impacto generado por este aspecto. Los estudiantes están a lo sumo un año trabajando en el grupo y tienen que aprender y asimilar el proceso en pocas semanas. Al igual que el uso de herramientas, esto es muy bueno para las empresas pues muchas veces estas empresas pequeñas tiene una población “flotante” (Según los proyectos actuales, la cantidad de recursos, etc.) de desarrolladores y estos deben adaptarse rápidamente a los procesos que se tienen. El grupo esta muy interesado en trabajar con las empresas pues uno de los temas que más nos llama la atención es la retroalimentación que estas empresas puedan darnos de nuestro proceso. Somos conscientes que nuestro ambiente es muy diferente al ambiente en el que trabajan dichas empresas y es por esto que nos interesa aprender de la realidad de estas empresas. De esta forma, lo que buscamos es crear una relación en ambos sentidos. Nosotros como equipo aportamos nuestro conocimiento en procesos y herramientas y las empresas nos acercan nuestro proceso a contextos reales dentro de la industria del software.. 2.3 Objetivos y alcance del trabajo con las empresas Como se mencionó anteriormente, el objetivo principal del trabajo con las empresas es implantar el proceso que se está llevando en Changeset en empresas pequeñas y medianas de software de la industria nacional. De esta forma estamos creando una relación en dos sentidos. Por una parte buscamos la retroalimentación de nuestro proceso y por otro lado buscamos ayudar a dichas empresas a mejorar la calidad de sus procesos. La primera fase del trabajo con las empresas, enmarcada en este documento, se centró en el mejoramiento del proceso de planeación y seguimiento. Se seleccionó este proceso pues consideramos que es uno de los mejores procesos que ejecutamos dentro de Changeset. Además, contamos con las herramientas para el soporte de dicho proceso..

(8) 3 MARCO GENERAL 3.1 Planes de mejoramiento de Procesos Al emprender un plan de mejoramiento de procesos de software, se deben tener en cuenta ciertos aspectos relevantes a la hora de tomar la decisión de incurrir en este esfuerzo. Se debe comprender que este mejoramiento no llegará a darse sin los suficientes esfuerzos por parte de todas las personas involucradas, tanto en el proceso por mejorar como en el plan de mejoramiento. Significa un compromiso constante con el trabajo emprendido por parte de todos los miembros del equipo. De la misma manera, hay que tener en cuenta que el mejoramiento de un proceso debe darse poco a poco, sin intentar cubrir todas las fases del proceso en un solo paso, sino que por el contrario se deben desarrollar estrategias que permitan manejar progresivamente las diferentes fases del proceso. También es importante anotar que incurrir en el esfuerzo del mejoramiento de un proceso, no significa directamente hacer el esfuerzo por adquirir una herramienta, sino que ésta puede llegar a ser parte de la solución que se de para este mejoramiento, el cuál al ser finalizado, debe mantener la esencia del proceso. Una vez comprendidos estos aspectos, se debe definir un marco metodológico que sirva como guía global de actividades por realizar para el mejoramiento del proceso. Algunas de las metodologías usadas con este propósito, pueden ser: El proceso de mejoramiento creado por Watts Humphrey (“Haga el plan y siga el plan”) [3], Plan-Do-Check-Act desarrollado en un principio por Walter Shewhart y popularizado por Edwards Deming (Calidad Total) [3] o el modelo IDEAL desarrollado por el SEI [2]. Este último es el modelo utilizado en el contexto de mejoramiento de procesos de software basado en CMM, por lo cuál decidimos adoptarlo como guía general del presente trabajo, utilizando herramientas que han sido probadas en contextos de mejoramiento similares al nuestro. 3.2. Modelo IDEAL. Desarrollado por el Instituto de Ingeniería de Sofware (SEI por sus siglas en inglés) en la Universidad de Carnegie Mellon, el modelo IDEAL [2] identifica las fases y los pasos necesarios de ser seguidos para conseguir un trabajo efectivo a la hora de emprender planes de mejoramiento de procesos de desarrollo de software. El modelo IDEAL es llamado de esta manera por sus diferentes fases de trabajo: Initiating, Diagnosis, Establishing, Acting y Learning. Cada una de estas fases consiste de diferentes actividades o pasos por desarrollar. Hay que tener en cuenta, que el trabajo realizado por medio de esta metodología, contempla, lo anteriormente dicho, manejar el mejoramiento de una manera progresiva. El modelo está diseñado como un modelo cíclico, en el cuál una vez se han terminado de ejecutar las diferentes fases y actividades que éste involucra, se debe volver a iniciar el ciclo de mejoramiento, llevando a cabo las mismas actividades pero definiendo nuevos objetivos para el ciclo que comienza..

(9) Ilustración 1 Modelo Ideal. Tomado de http://www.sei.cmu.edu/ideal/ideal.gif. 3.2.1 Fase de Inicialización En la fase de Inicialización (Initiating) es en donde se identifica la necesidad general para ser tenida en cuenta dentro del plan de mejoramiento; tiene por lo tanto como entrada, el estimulo al cambio, al mejoramiento, por parte de la organización dueña del proceso. Una vez se tiene identificada esta necesidad de mejora, y existe un compromiso gerencial para buscarla, la gerencia de la organización debe fijar el contexto para el trabajo que será realizado, identificando en qué áreas de la organización serán concentrados los esfuerzos y qué puntos de la estrategia de negocio se quieren llegar a mejorar. Además, se debe definir la infraestructura con la cuál se llevará a cabo el trabajo, incluyendo los grupos de personas con que se contarán, las personas involucradas dentro de la empresa con el plan de mejoramiento, las personas externas a la organización que ayudarán con el plan y las responsabilidades de cada una de las personas involucradas.. 3.2.2 Fase de Diagnóstico La fase de Diagnóstico (Diagnosing) es aquella en la que se realiza un entendimiento más completo del trabajo por llevar a cabo. Durante esta fase, se deben desarrollar dos caracterizaciones de la organización: el estado actual y el estado deseado. Luego, con la caracterización de estos dos aspectos, se desarrollan recomendaciones que sugieran una manera de proceder durante las siguientes etapas y actividades de la metodología..

(10) 3.2.3 Fase de Establecimiento La tercera fase, o fase de Establecimiento (Establishing), es la fase durante la cuál se establece el plan detallado de trabajo. En ella se deben priorizar las actividades por desarrollar que fueron sugeridas durante la fase de diagnostico, teniendo en cuenta las operaciones a mejorar y las condiciones más apremiantes de cambio que tenga la organización. Se desarrolla luego una primera aproximación estratégica de trabajo en donde ya se especifica la disponibilidad de los recursos a utilizar, los cuales fueron tenidos en cuenta en la fase de inicialización. Además, se deben establecer los grupos de trabajo, los roles y responsabilidad, así como los factores técnicos necesarios de ser instalados y los factores no técnicos para ser considerados como lo son la cultura de la organización, fuentes probables de la resistencia al cambio, niveles del patrocinio, entre otros. Al finalizar esta fase, se debe contar con un plan de acción en el cuál se incluyan las actividades, los hitos, los entregables y responsabilidades obtenidas además de las tres fases previas.. 3.2.4 Fase de Ejecución La fase de Ejecución (Acting) es la fase en la cuál se utiliza la mayoría de tiempo del ciclo normal de trabajo bajo la metodología IDEAL. Esta fase comienza con el desarrollo de una solución con la cuál se buscará mejorar el proceso seleccionado para el ciclo de trabajo. Dicha solución puede utilizar diferentes elementos para mejorar el proceso. Estos elementos pueden ser herramientas existentes, procesos alternos, adquisición de conocimientos y habilidades nuevas o ayudas externas. Como podemos ver, las herramientas no son el único medio de mejorar los procesos, sino que una solución puede ser aún más compleja utilizando la combinación de diferentes elementos. Una vez se tenga planteada la mejor solución posible, ésta debe ser probada en el ambiente real de la organización, por lo cuál se debe realizar una prueba piloto de ésta, tal y como ha sido planeada, con el objetivo de irla mejorando con los resultados obtenidos de la prueba piloto. Puede suceder que se realice más de un ciclo de prueba de la posible mejor solución, dado que se deben dar tantas pruebas como sean necesarias para que esta solución se convierta en una solución satisfactoria para el equipo de trabajo. Una vez se cuenta con esta solución satisfactoria, esta puede ser implementada en el proceso de la organización. La implementación de la solución puede tener en cuenta diferentes aproximaciones como comenzar a implementarla por los niveles más altos de la organización (si se trata de una mejora estratégica empresarial) o una implementación sobre la acción de la empresa, implementándola, por ejemplo, proyecto por proyecto en el momento adecuado del ciclo de vida de estos mismos. Es importante tener en cuenta que cada una de las actividades desarrolladas durante la fase de Ejecución deben llevar consigo un seguimiento por parte de la gerencia de la organización en conjunto con el equipo que esté llevando a cabo el mejoramiento, con el propósito de mantener controlado el plan realizado y verificando que las condiciones identificadas para cada una de las fases se estén presentando tal y como la gerencia y el equipo lo esperan..

(11) 3.2.5 Fase de Aprendizaje La fase de Aprendizaje (Learning) es la fase que completa el ciclo de mejoramiento. Durante las diferentes etapas del ciclo de mejoramiento IDEAL, se debieron documentar cada una de las decisiones y actividades llevadas a cabo, con el fin de realizar en este momento un análisis del trabajo realizado y obtener y documentar las lecciones aprendidas a través del mismo. Es en esta fase final donde se valida si los objetivos planteados para el ciclo fueron logrados, si con el esfuerzo utilizado se lograron las metas previstas, y se analiza cómo la organización puede mejorar el trabajo con lo obtenido del análisis del ciclo finalizado. En general, utilizar esta metodología de trabajo en el mejoramiento de procesos de desarrollo llevado a cabo dentro del grupo Changeset, ofrece grandes ventajas a la hora de organizar la labor de mejoramiento durante varios semestres con las mismas empresas. Al tener en cuenta la alta rotación de los integrantes del grupo, se pueden establecer objetivos concretos sobre el mejoramiento de una fase del proceso de desarrollo o de una fase del proceso de soporte al desarrollo, por estudiante durante un semestre. En esta ocasión, como se explica a continuación, el trabajo se concentró en el proceso de soporte al desarrollo de software que involucra la planeación y seguimiento de los proyectos.. 3.3 El proceso de planeación y seguimiento El proceso de planeación y seguimiento es uno de los procesos más importantes en la gerencia de proyectos. La planeación y el seguimiento se pueden considerar como procesos separados, sin embargo, éstos se complementan y son dependientes en muchos aspectos. Gran parte del éxito o fracaso de los proyectos de desarrollo de software son atribuidos al proceso de planeación y seguimiento. El proceso de planeación que tenemos actualmente en Changeset, se puede dividir en dos grandes fases. La planeación general del ciclo, en donde se obtiene un cronograma general del proyecto y se tiene un primer estimativo de la duración y de las actividades que se deben realizar para cumplir con los objetivos del ciclo. En esta fase de la planeación se usan históricos de tiempos para calcular la duración y el esfuerzo que se requieren en las diferentes actividades. La segunda parte del proceso de planeación, es la planeación semanal. Dicha planeación es la que permite, con base en el plan general, repartir las tareas y sus responsables en cada semana. Para poder llevar a cabo esta planeación es indispensable hacer una reunión de seguimiento semanal. En dicha reunión se debe hacer el seguimiento de las tareas de la semana pasada y se deben planear las de la semana siguiente. En esta fase del proceso, las herramientas nos han ayudado en la publicación de las tareas de la semana. En cuanto al proceso de seguimiento es importante resaltar que es aquí donde se obtienen los datos para hacer la planeación de los próximos ciclos. Es por esto que los procesos se encuentran entrelazados y no se pueden separar. El proceso de seguimiento es una cuestión de disciplina, que al igual que el de planeación si.

(12) no se cuenta con una buena herramienta es muy difícil y costoso mantener. Cabe resaltar que la misma herramienta que utilizamos para publicar las tareas la usamos para hacer el seguimiento. Los miembros del equipo entran a la aplicación y registran sus tiempos. Al final de la semana podemos ver el consolidado de tiempos de todos los integrantes del equipo y mirar el estado del proyecto. Con un buen proceso de planeación y seguimiento se puede estimar un buen cronograma inicial del proyecto; tener el conocimiento del estado del proyecto, saber sí se está o no atrasado en él; mejorar las estimaciones para futuros proyectos; en fin, son procesos que entregan información muy valiosa a la hora de ejecutar un proyecto. La primera fase del trabajo con las empresas se centró en el mejoramiento del proceso de planeación y seguimiento. Se seleccionó este proceso pues consideramos que es uno de los mejores procesos que ejecutamos dentro de Changeset. Además, contamos con las herramientas para el soporte de dicho proceso..

(13) 4 LEVANTAMIENTO DE INFORMACIÓN DE LOS. PROCESOS ACTUALES EN LAS EMPRESAS Como pudimos ver en la introducción, la fase de inicialización, según la metodología seleccionada de trabajo (IDEAL), ya se ha cumplido. En esta sección, continuando con las fases de la metodología y siguiendo con la fase de diagnóstico, contemplaremos la actividad de caracterizar la situación actual de los procesos de planeación y seguimiento en la que se encuentran las diferentes organizaciones con las que trabajamos y los estados en los cuales quieren las organizaciones que se encuentren en un futuro sus procesos, así como las recomendaciones de trabajo establecidas por cada una de las empresas.. 4.1 Empresa 1 4.1.1 Proceso de Planeación En la empresa 1 se pueden resaltar los siguientes aspectos del proceso de planeación antes de implementar las nuevas actividades y herramientas: ● Se cuenta con dos grandes fases de planeación para cualquier proyecto. ● Planeación antes del firmar un contrato: Ayuda a estimar el costo del producto. Es en esta fase en donde se hace el cronograma general y se marcan las fechas y entregables importantes. ● Planeación una vez se ha firmado el contrato: Es en donde se define el cronograma detallado por iteración de desarrollo. Esta fase es la más parecida a la que realizamos actualmente en Changeset. ● La entrada para hacer la planeación general es una lista de requerimientos aprobados por el cliente. De estos requerimientos se plantea una estrategia y se reparten en diferentes iteraciones. Por cada iteración se hace un cronograma. También se hace una repartición de roles y se asignan los recursos al proyecto. ● Para hacer el estimativo de tiempos se clasifican los requerimientos según la complejidad y estiman un tiempo por nivel de complejidad. De esta forma se obtiene un total de tiempo para el desarrollo. ● Se tienen definidas un conjunto de actividades por cada tipo de requerimiento. Por cada una de estas se hace la estimación de tiempo y se asigna un responsable. ● El día se usa como unidad de tiempo. ● En el último año se analizaron métricas de los tiempos para mejorar las estimaciones. Faltaría incluir métricas de valor ganado. Actualmente hacen las estimaciones con la tabla que resulto de dicho análisis. ● La planeación general es un proceso que cuesta aproximadamente 2 días de un Ingeniero para sacar el cronograma de una iteración de 4 semanas. ● Es importante tener en cuenta que se realizan diferentes tipos de proyectos. Y las actividades que se tienen en cuenta en la planeación son diferentes en cada tipo..

(14) 4.1.2 Proceso de Seguimiento Para el seguimiento de las actividades en la empresa 1 se pueden resaltar los siguientes aspectos: ● Una vez se ha completado la planeación esta se imprime y se publica en un lugar en donde los ingenieros van marcando sobre el papel las tareas que van terminado, existe una persona que está encargada de asegurar que el cronograma este siendo actualizado periódicamente. ● El tiempo que se gasta en cada actividad también se consigna en el cronograma, y se usa para mejorar estimaciones del siguiente proyecto. De hecho, la tabla con la que estimaron este año se obtuvo de los datos reales de los proyectos del año pasado.. 4.1.3 ¿Qué expectativas tienen? En general las expectativas que logre identificar en esta primera visita fueron: ● El enfoque que se quieren profundizar es el proceso de la planeación general y el seguimiento de tareas, y de la implementación de la herramienta DotProject para hacer esto. ● Les interesa que el proceso involucre la utilización de la herramienta para que sea más fácil de seguir y se puedan tener mejores resultados.. 4.2 Empresa 2 4.2.1 Características del trabajo encontrado Grupo: 4 desarrolladores Los tiempos estimados por requerimiento incluyen planeación, desarrollo, pruebas, documentación técnica y del manual del usuario, y capacitación de la nueva funcionalidad desarrollada. Los ciclos iterativos comprenden un periodo de 2 semanas y el trabajo ha desempeñar en cada uno se determina de acuerdo con el nivel de prioridad asignado a los requerimientos y el dimensionamiento de los mismos.. 4.2.2 Herramientas de planeación y seguimiento utilizadas actualmente Xplanner: OpenSource, Ant, MySQL, JDK1.4, Contenedor Web (que soporte Servlets 2.3). Excel. Permite llevar control de las tareas realizadas que no fueron planeadas y las tareas que no se terminaron durante el ciclo. Cada una de las situaciones presentadas es justificada por cada uno de los desarrolladores.. 4.2.3 Metodología La organización en el aplicativo XPlanner del trabajo programado sigue los siguientes patrones:.

(15) ●. Proyecto: hace referencia a proyectos independientes que se trabajan en la empresa.. ●. Iteración: Permite separar y llevar control de los ciclos programados.. ●. Historias: Se crean historias por cada requerimiento que se trabaja durante la iteración vigente. Dichas historias son llamadas de acuerdo con el nombre asignado al requerimiento correspondiente.. ●. Tareas: Hace referencia a las actividades especificas para desarrollar el requerimiento planeado.. Cada tarea e historia creada en el XPlanner cuenta con información referente a los tiempos estimados en el dimensionamiento del requerimiento, responsable de la ejecución y responsable del seguimiento y control de lo planeado. Los pasos seguidos en un ciclo normal de planeación son los siguientes:. i.. La primera versión de un requerimiento es levantada por el líder funcional conjuntamente con los clientes, quienes exponen sus necesidades y expectativas de la funcionalidad a desarrollar.. ii.. El requerimiento documentado es comunicado al líder de desarrollo con el fin de determinar la viabilidad técnica y hacer una primera estimación de los tiempos de planeación, desarrollo, pruebas y puesta en marcha de la solicitud recibida.. iii.. Una vez se han analizado las implicaciones técnicas y funcionales de un requerimiento en particular, se emite una estimación final de los tiempos de desarrollo y se selecciona el miembro del equipo que trabajara en el mismo.. iv.. La asignación de tareas se realiza de acuerdo con la disponibilidad de los desarrolladores, conocimiento de las funcionalidades a desarrollar y prioridad en los requerimientos.. v.. Cada desarrollador es responsable de ingresar sus tareas en el XPlanner de acuerdo con la estimación final y actualizar diariamente los tiempos de trabajo dedicado a las mismas.. 4.2.4 Seguimiento El seguimiento de las actividades es realizado casi a diario por parte de la líder. Esta revisión es llevada a cabo sobre las tareas de cada uno de los miembros del grupo de desarrollo en aras de encontrar inconvenientes en el desarrollo del trabajo que afecten el proyecto y fallas en la planeación de los tiempos para las diferentes actividades. Si durante esta revisión se presentan anomalías con el desarrollo de tareas individuales, se realiza un contacto personal, por parte de la.

(16) líder del grupo, con el miembro que está presentando dichos inconvenientes para conocer la situación, y si es necesario se lleva a cabo una replaneación de las tareas sobre las cuales sea necesario, esta replaneación genera una modificación sobre los tiempos estimados registrados inicialmente sobre XPlanner. Si al finalizar un ciclo existen tareas que aun no han sido terminadas, estas son exportadas al siguiente ciclo con el tiempo faltante para ejecutarlas.. 4.2.5 Reportes Los reportes que se utilizan de la herramienta son aproximadamente el 40% de ellos, entre los que se encuentran: El reporte de los tiempos planeados versus los tiempos ejecutados (Real vs. Planeado), el reporte diario de registros por persona, tiempo total destinado por proyecto. Se generan reportes para conocer el estado del proyecto, tareas al 100%, tiempos ejecutados. Estos últimos son discutidos aproximadamente cada dos semanas con el Gerente para analizar principalmente el desempeño del grupo.. 4.2.6 Fallas encontradas Dos de las fallas que manejan hoy en día con la herramienta son: Primero, conocer el tiempo invertido por requerimiento es muy complicado dado que un requerimiento puede tener actividades repartidas en varias iteraciones y es necesario consultar cada una para generar un total de horas. Y segundo, el traslape en la planeación de diferentes tareas no puede ser controlado y en ocasiones puede presentarse que se planeen tareas a realizar en el mismo intervalo de tiempo..

(17) 5 DEFINICIÓN TRABAJO CON LAS EMPRESAS Con el fin de identificar objetivos y actividades en común, la fase de establecimiento fue ejecutada en conjunto con todas las empresas. De esta manera se pudo establecer globalmente qué se debía realizar al continuar con el mejoramiento, de tal forma que estas actividades pudieran ser seguidas de similar manera con todas las empresas. Se establecieron los siguientes aspectos.. 5.1 Cronograma general Se decidió, que dado el tiempo restante del semestre académico, se llevaría a cabo sólo un ciclo de trabajo, que incluiría dos meses de trabajo y en el cuál se tendría en cuenta el llevar a cabo la estimación - planeación- y seguimiento con las empresas, así como una evaluación inicial de dicho proceso.. 5.1.1 Objetivos Los objetivos inicialmente planteados para el trabajo durante el ciclo de trabajo establecido, fueron organizados por niveles (3 niveles), en donde los objetivos de cada nivel son complementarios y se comenzaría a trabajar con los objetivos de los niveles más bajos. La organización por niveles fue presentada de la siguiente manera: •. Nivel 1: Objetivos a largo plazo. o Nivel 2: Objetivos a corto/mediano plazo. . Nivel 3: Hacer acciones concretas.. Y los objetivos que se presentaron como propuesta inicial de trabajo para la fase de establecimiento fueron los siguientes:. 5.2 Nivel 1 ●. Mejorar el costeo de los proyectos.. ●. Mejorar la noción de avance de los proyectos.. ●. Integrar el proceso de planeación y seguimiento con el proceso de a. ●. administración de conocimiento.. 5.3 Nivel 2 ●. Mejorar el proceso de estimación.. ●. Mejorar el proceso de seguimiento..

(18) ●. Implantación de una fase de análisis y retroalimentación del proceso (postmortem).. ●. Mantenimiento de la base de datos de históricos.. 5.4 Nivel 3 ●. Identificar la clasificación de requerimientos. (correcciones, nuevos desarrollos, modificaciones, etc.). ●. Identificar las fases y sus artefactos por requerimientos. (Análisis, diseño, implementación, implantación, etc.). ●. Identificar las actividades necesarias por fase. (Elaboración de documento x., reunión de diseño, implementación jsp mediano, etc.). ●. Identificar la unidad de medida por actividad (KLOC, minuto, horas, días, semanas, etc.). ●. Identificar la unidad de medida del grado de complejidad (pequeños: x horas o pequeño x LOCs, mediano: x días, grande: meses, etc). ●. Construcción de históricos iniciales por actividades teniendo en cuenta la complejidad. (Concepto de expertos). ●. Definición y / o adaptación de la herramienta de trabajo.. Durante la reunión de establecimiento, se decidió que los primeros objetivos por enfrentar son el objetivo 1 y el objetivo 2 del primer nivel. El objetivo 3 de este nivel se conseguirá una vez se hayan completado los objetivos 1 y 2 dado que involucran postmortem, seguimiento e históricos. Además, por el tiempo con que se dispone para el trabajo de este ciclo, se definió que los objetivos por completar serían todos aquellos del nivel 3, pudiendo dar cumplimiento al primer objetivo del nivel 1 y al primer y segundo objetivos del nivel 2. Las métricas de cumplimiento de los objetivos del nivel 3, será su realización o no, dado que son objetivos que involucran actividades concretas, que se llevan a cabo o no.. 5.5 Actividades iniciales Dentro de la fase de establecimiento se identificaron algunas actividades iniciales que debían ser llevadas a cabo por las personas involucradas en el mejoramiento de los procesos de las empresas, con un seguimiento hecho nosotros..

(19) Las actividades iniciales que se identificaron fueron las relacionadas con la obtención de los datos necesarios para obtener una primera tabla de históricos. En esta tabla es en donde se relacionan las diferentes etapas de desarrollo llevadas a cabo por cada una de las empresas. También las actividades asociadas a dichas etapas y la estimación de tiempo para la realización de esas actividades, dependiendo de diferentes tamaños y caracterizaciones de los requerimientos. El ejemplo de entregables ofrecido por parte del grupo fue el siguiente: •. Tabla de planeación general: Tabla de etapas de desarrollo, actividades asociadas a las etapas y entregables de cada etapa. ETAPA. ACTIVIDAD. ENTREGABLE. Etapa 1. Actividad 1. Entregable 1. Actividad 2 ..... •. •. •. .... .... Caracterización de los entregables. ENTREGABLE. DESCRIPCIÓN. Entregable 1. Descripción 1. ..... .... Caracterización de los requerimientos. REQUERIMIENTO. CARACTERÍSTICAS FUNCIONALES. Requerimiento simple. Una pagina web sencilla, con involucramiento básico de modelo lógico.. ...... ...... Clasificación de los requerimientos por esfuerzo: Por cada tipo de requerimiento se describe el trabajo que requiere o la funcionalidad que lo caracteriza. Clasificación. Req. Simple. Req. Mediano. Req. Complejo.

(20) Etapa. Actividad. Entregable Mins. s. Mins.. Mins.. Etapa 1. Actividad 1. Entregable 10 1. 20. 30. ...... ..... ..... ..... ..... ..... Dado el ejemplo, se estableció que cada empresa trabajaría sobre la obtención de la tabla inicial de tiempos de planeación, ya fuera siguiendo los ejemplos ofrecidos u obteniendo los datos de la manera que fuera más conveniente para cada uno de ellos, pero siendo concientes de que el resultado final de esta actividad sería la misma para todos..

(21) 6 CASOS DE ESTUDIO 6.1 Empresa 1 En la empresa 1 se hicieron las tablas con los históricos de los diferentes tipos de proyectos. En total se realizaron tres tablas. También se involucraron más personas al proceso, expertos que trabajan en los diferentes tipos de proyecto dentro de la empresa. Se hizo una reunión con todos ellos y miramos las tablas de cada uno. El trabajo que esperábamos era el resultado de un Delphi, pero por motivos de recursos este no se pudo llevar a cabo. Los expertos en cada tipo de proyecto son pocos, generalmente una sola persona, y no valía la pena hacer un Delphi para obtener las tablas de históricos. Se hizo una tabla para los proyectos implementados en PHP y otra para los proyectos desarrollados en J2EE. Las tablas que nos entregaron fueron muy similares a las que usamos en Changeset. Se hicieron algunas observaciones que se discutieron desde ambos puntos de vista, el nuestro y el de ellos. Es claro que nuestro ambiente es muy diferente al que ellos manejan. En particular, a la disponibilidad que tienen los diferentes miembros del equipo de trabajo, ellos cuentan con recursos de tiempo completo y nosotros solamente tenemos miembros que trabajan 12 horas a la semana. Uno de los puntos claves de la discusión fue el manejo de la unidad de tiempo que se utiliza para las tareas. Ellos manejan el día como unidad de tiempo y la recomendación que les dimos fue que trataran de cambiar esta unidad por la hora. Creemos que es más conveniente y fácil hacerle seguimiento a tareas de varias horas en lugar de varios días. Por otra parte, para llevar los históricos de tiempo es mejor llevarlos en horas que en días. Ellos argumentaban que era innecesario hacerlo en horas y que les era más conveniente hacerlo en días. Uno de los trabajos que se realizó fue el de dividir las tareas que fueran de más de un día para que se pueda hacer un mejor seguimiento. Se lograron identificar las actividades que componían dichas tareas grandes y se dividieron en más pequeñas. Las tablas de los proyectos J2EE y PHP están muy completas y además de tener todo lo que se había sugerido se creó otra clasificación dependiendo del grado de experiencia del ingeniero (Junior y Experto) que va a desarrollar la actividad. Esto nos puede servir en Changeset pues también contamos con estos niveles de experiencia dentro del proyecto. Esta clasificación nos podría ayudar a estimar mejor el tiempo de las actividades de los nuevos integrantes que entran cada semestre. El inconveniente que puede tener es que se debe llevar el control de dos tablas por aparte. El tercer tipo de proyecto son proyectos de implantación de la herramienta Mondrian (Proyectos de Datawarehouse). Estos proyectos consisten de un levantamiento de información en donde esta se migra y se centralizan en una base de datos. La herramienta, que es libre, sirve para organizar diferentes reportes muy importantes para la gerencia de las empresas. Las actividades de este tipo de proyecto difieren mucho de los dos primeros tipos, pues la unidad de medida que.

(22) se utiliza no son los requerimientos. Nos explicaron bien como funcionaban estos proyectos y se lograron identificar las unidades de medida para la planeación (Estrellas y Reportes). Estas unidades equivaldrían a los requerimientos en los proyectos de desarrollo normal. Se definió este tipo de proyecto para trabajar durante las siguientes fases, pues tanto ellos como nosotros consideramos que es en donde se tiene una menor experiencia y se pueden obtener mejores resultados. Por otra parte es donde se quiere mejorar al corto y mediano plazo el proceso de planeación y seguimiento. A la tabla se le hicieron unas pequeñas correcciones, las actividades quedaron clasificadas en tres grandes categorías: Una categoría que agrupa las actividades relacionadas con las estrellas, otra con las actividades relacionadas con los reportes, y finalmente una con actividades de seguimiento que se hace en este tipo de proyectos. Una vez se terminó la tabla de los proyectos Mondrian, el siguiente paso fue crear una política para manejar la codificación de las actividades de la tabla. Se propuso que se creara una jerarquía simple con las diferentes fases y actividades. Los códigos tienen dos números separados por un punto (xx.zz donde xx se refiere al código de la categoría en este caso estrellas, reportes o seguimiento; y el zz el número de la actividad). Es importante hacer esta definición pues dicha codificación es muy útil a la hora de sacar los reportes de la base de datos de donde se esté guardando la información, en nuestro caso en DotProject. Se pude determinar, por ejemplo, que porcentaje del total del tiempo se emplea en actividades de seguimiento o cuanto tiempo se gastaron haciendo estrellas. En fin, el código le da orden al proceso y lo simplifica a la hora de hacer reportes. En cuanto a las herramientas con las que trabajamos, se realizaron varias actividades de capacitación y de revisión de algunas que ya tenían instaladas. En la empresa ya habían instalado el DotProject, inclusive ya se estaban manejando algunos proyectos dentro de la herramienta. Por otra parte, se les hizo entrega del script para subir las tareas a DotProject. La función del script es básicamente tomar la información de un archivo de texto plano separado por comas (.csv) y la carga en una estructura en memoria, luego se conecta a la base de datos de DotProject insertando la información de las tareas a un nuevo proyecto. Se hizo una demostración y se subieron varios proyectos de prueba. Se le hicieron cambios a las fuentes del proyecto. Fueron cambios pequeños para adaptar mejor la herramienta al entorno de la empresa. El cambio más importante fue abrir la posibilidad de dejar que el script subiera las tareas a un mismo proyecto para no tener que tener muchos proyectos como lo hacemos en actualmente en Changeset. También se les hizo entrega del módulo de los reportes que usamos en Changeset. El módulo es una aplicación en PHP que se integra con el DotProject para mostrar los reportes. Los reportes con los que contamos actualmente son lo siguientes: reporte de tiempo planeado por participante, tiempo real por participante, tiempo y porcentaje de avance por tarea. En general son reportes para hacer el seguimiento semanal del grupo. En cuanto al proceso de seguimiento no se logro medir ningún avance por motivos de tiempo. Se les dieron las herramientas y se espera que las personas las usen para empezar a llevar las métricas. Lo que hicimos fue tratar de crear conciencia.

(23) de la importancia de hacer un buen proceso de seguimiento. Se sabe que es un proceso de disciplina y en donde la gerencia debía estar presente motivando a la gente a ser participe del proceso.. 6.2 Empresa 2 El trabajo realizado en esta empresa se llevó a cabo por parte de la líder funcional de la organización con la colaboración de los desarrolladores de la empresa, y contó con un seguimiento del trabajo por parte de un integrante de Changeset a través de reuniones en conjunto. Durante las reuniones, se desarrollaron actividades de seguimiento del trabajo realizado en la empresa y se acordaron las tareas que cada una de las partes debería realizar. Durante la primera reunión de trabajo, se hizo seguimiento de las primeras actividades que se habían dejado que incluía comenzar por desarrollar la tabla de históricos que incluyera las fases, las actividades, los requerimientos y los tiempos involucrados en dichas actividades. El trabajo se centró en la producción de las tablas de fases, actividades y entregables y su posterior uso en generar la tabla de tiempos históricos, llenando ésta, en un principio, con tiempos ya obtenidos por la empresa. La tabla de históricos fue generada de la siguiente manera. Primero se tuvieron en cuenta las fases de desarrollo de software, dentro de estas fases se incluyeron las actividades globales por realizar y dentro de estas actividades se especificaron finalmente las tareas sobre las cuales se registrarían los tiempos estimados, estas actividades son específicas y algunas de ellas tienen entregables concretos, los cuales están asociados a la descripción de la actividad, como por ejemplo “Creación de un JSP”. En esta etapa del proceso, la captura de tiempos de cada una de las tareas no se llevó a cabo como un proceso personalizado, al estilo Wideband Delphi, sino que se tomaron tiempos históricos (tiempos ejecutados) ya registrados en la herramienta de seguimiento que utiliza la empresa (XPlanner). Se buscaron por desarrollador, requerimientos que incluyeran la mayoría de las tareas de la nueva tabla (entre 3 y 4 requerimientos), para con los tiempos en ellos registrados, alimentar los históricos iniciales de la tabla de históricos. Es decir que por cada desarrollador se obtuvieron sus tiempos históricos, de entre tres y cuatro requerimientos, y de ellos se obtuvieron los tiempos reales utilizados para las diferentes tareas que se llevaron a cabo. Estos tiempos fueron registrados en la nueva tabla de históricos, obteniendo de esta manera, un consolidado de estimativos de tiempos para las tareas, tanto por desarrollador como para la tarea en general (promediando en los dos casos). Este aspecto es importante tenerlo en cuenta, dado que la empresa desea manejar la tabla de históricos, de manera tal, que pueda ser relacionada con las características de experiencia del desarrollador. En general lo que se vio, fue que como se quiso construir la tabla de históricos con datos más reales (con los datos ya registrados del trabajo diario) se tuvieron que seleccionar bien los requerimientos para tener en cuenta sus tiempos, escogiéndolos únicamente por el criterio de aquellos que más tareas de las registradas en la tabla de tareas incluyeran en su ejecución..

(24) Al tomar requerimientos ya trabajados y registrados en XPlanner, muchas de las tareas planeadas en la tabla, no existían en estos requerimientos. Por esta razón varias de las tareas de la tabla de históricos aún no tenían tiempo tomado de los históricos, para lo cual se debería hacer el proceso completo de Wideband Delphi o, como se comenzó a hacer en ese momento, buscar estos tiempos dentro de los registros, asociándolos con tareas realizadas que se asemejen a las que se necesitan tener en cuenta. Esta situación trajo complicaciones posteriores al querer obtener tiempos sobre actividades que nunca hubieran sido tenidas en cuenta por separado y por lo tanto se tendrían tareas sin tiempos históricos. Además, las tareas antes registradas no cuentan con un trabajo enfocado en estimaciones o registros sobre una unidad de medida específica por tarea. Otro inconveniente en este punto fue que aún no se contaba con una unidad de medida de complejidad para clasificar los requerimientos y poder seleccionar de una mejor manera los tiempos registrados para ser tenidos en cuenta dentro de la tabla de históricos. Fue por esto que se acordó que en el transcurso de 15 días se seguiría afinando la tabla de históricos, vinculando principalmente la clasificación de los requerimientos dentro de los mismos y consiguiendo la información de los tiempos estimados para las tareas que aun no contaban con esta información. Se buscaba, la manera de definir claramente la unidad de medida de complejidad a utilizar. Para ello la empresa se comprometió en definir esta unidad de medida para los requerimientos y actividades y, posteriormente, terminar la tabla de históricos. Para ese momento, ya se había comenzado a aplicar el trabajo dentro de la organización. La planeación inicial de un nuevo proyecto de desarrollo de una aplicación Web se llevó a cabo utilizando la tabla de fases y actividades anteriormente definidas. El objetivo era realizar una planeación en términos de las fases y actividades establecidas y poder comparar los tiempos obtenidos para la tabla de históricos inicial con una estimación de un proyecto de desarrollo normal, para que luego en el proceso de seguimiento, se comenzara a retro alimentar la tabla de históricos con estas nuevas estimaciones. Es decir que los tiempos reales obtenidos de este proyecto fueron controlados desde el principio bajo parámetros de fases y actividades definidas en el mejoramiento del proceso de planeación y seguimiento. En una segunda reunión, se hizo seguimiento sobre la definición de la unidad de medida de complejidad para tener en cuenta al estimar los tiempos de las diferentes actividades. En ese momento no se contaba aún con la definición de una unidad de complejidad que cobijara las diferentes actividades. Por esta razón, se decidió seleccionar diferentes unidades de medida, aplicables a diferentes actividades o fases de las identificadas en la tabla de históricos. Esto con el fin de abrir las posibilidades de selección de la unidad de complejidad, de tal forma que se pudiera tener en cuenta una medida específica para cada una de las actividades y fueran mucho más fáciles de estimar. Este aspecto nos hizo caer en cuenta, de que los datos obtenidos inicialmente para la tabla de históricos no reflejaban ni la caracterización especial de actividades definida, ni mucho menos iban a ser tiempos que tuvieran en cuenta esfuerzos y estimaciones referentes con.

(25) la unidad de complejidad seleccionada para tales actividades. Fue por esta razón, que los tiempos obtenidos inicialmente de los registros de ejecución de proyectos anteriores con que contaba la empresa fueron hechos a un lado. Se comenzó a trabajar en obtener tiempos de estimación de nuevas planeaciones que tuvieran en cuenta las diferentes actividades establecidas y sus unidades de medida de complejidad, tal y cómo ya se había comenzado a hacer, al utilizar la tabla de fases y actividades en la planeación inicial del nuevo proyecto de desarrollo Web. Con esta decisión se pospuso la completitud de la tabla de históricos, o estimación inicial, para la cuál la empresa planea continuar obteniendo más datos con el siguiente ciclo de trabajo sobre el mismo proyecto. Con esta información, se espera obtener un histórico por actividad que permita estimar tiempos de desarrollo por requerimiento asociado a la experiencia del desarrollador que lo tendrá a cargo, dado que fue de esta manera como se hizo la planeación del nuevo proyecto. En esta misma reunión se puso en consideración la adaptación de la herramienta de trabajo sobre la cuál se está soportando el registro de tiempos, con el fin de brindar facilidades de trabajo a la hora de registrar tanto la planeación general como las planeaciones semanales, que se realizarán durante un proyecto en ejecución. Este trabajo fue analizado desde el punto de vista de realizar una modificación sobre la herramienta Xplanner, con el fin de automatizar dichas labores. Pero una vez analizada esta labor en el contexto de trabajo de empresa, se vio que en realidad la manera de trabajo actual de la empresa no requería tanto de esta funcionalidad, pues la cultura inculcada respecto al registro de labores en la herramienta ya se encuentra muy bien establecida y controlada por parte de la empresa, dado que este trabajo se encuentra distribuido en todos los miembros del equipo de desarrollo y no es responsabilidad única del líder funcional o de planeación. Sin embargo, sí se vio la necesidad de llegar a adaptar la herramienta Xplanner con el fin de modificar los informes que actualmente la herramienta ofrece, de tal manera que tenga en cuenta las nuevas clasificaciones dadas de fases y de actividades. De esta manera se facilita la labor de retroalimentación de las tablas previamente generadas..

(26) 7 RESULTADOS Los resultados obtenidos son la evaluación de los objetivos que se propusieron en la etapa de Inicialización. Estos objetivos fueron: 1. 2. 3. 4. 5. 6.. Identificar la clasificación de requerimientos. Identificar las fases y sus artefactos por requerimientos. Identificar las actividades necesarias por fase. Identificar la unidad de medida por actividad. Identificar la unidad de medida del grado de complejidad. Construcción de históricos iniciales por actividades teniendo en cuenta la complejidad. 7. Definición y / o adaptación de la herramienta de trabajo. Como se puede apreciar la medición de estos objetivos se hace evaluando si se hicieron o no las actividades que propone cada objetivo.. 7.1 Empresa 1 Los primeros 6 objetivos se cumplieron en su totalidad en la empresa. Básicamente estos objetivos se cumplieron en la actividad del desarrollo de las tablas con los históricos de tiempo. Como se mencionó anteriormente, estas tablas quedaron muy completas pues además de identificar los tipos de proyectos, sus fases y entregables, las actividades por fase, la unidad de medida y el grado de complejidad se hizo una clasificación con 2 grados de experiencia. En las tablas se discrimina a los ingenieros junior e ingenieros avanzados. En cuanto al objetivo 7, también se cumplió en un 100% pues se les hizo entrega de las herramientas que usamos en Changeset. Estas herramientas fueron probadas en conjunto con ellos y se lograron resultados satisfactorios. Se le entregaron las fuentes del script para subir las tareas de DotProject, también se les entrego el módulo de reportes de seguimiento de DotProject. La empresa ya esta usando el script para subir las tareas, inclusive se reportó un defecto que tenía el script y se corrigió.. 7.2 Empresa 2 En una última reunión, se llevó a cabo una reunión de cierre de proyecto en la empresa, en donde se evaluaron los resultados obtenidos sobre los objetivos que se plantearon para este ciclo de trabajo. Recordemos que los objetivos a desarrollar durante este periodo estaban enfocados en los objetivos de nivel tres planeados para el mejoramiento del proceso de planeación y seguimiento. De ellos podemos resaltar que de los siete objetivos planteados, cinco de ellos fueron realizados al 100% y de los otros dos restantes uno se encuentra en un 85% de completitud y el otro en 10%. Como ya lo pudimos ver dentro del desarrollo del caso de estudio de la empresa, el objetivo que al final terminó en un estado más lejano de lo esperado fue el de la.

(27) consecución de la tabla inicial de históricos, lo cuál se vio retrasado por el momento en el cuál fueron definidos finalmente la unidad de medida de complejidad que iría asociada a las actividades y por lo tanto la medida con que serían miradas las estimaciones de tiempo sobre cada una de ellas. El objetivo sobre el cuál se avanzó pero no se llegó a conseguir una totalidad en su porcentaje de trabajo fue el de definición y adaptación de la herramienta. Finalmente la adaptación definida sobre la misma no fue desarrollada durante este ciclo, sin embargo, el porcentaje refleja el estudio llevado a cabo para soportar la decisión de continuar utilizando la herramienta con la que se venía trabajando y el estudio de la herramienta para dar certeza de la posibilidad de adaptación que se podría llevar a cabo sobre la misma para obtener los resultados adicionales de Xplanner esperados por parte de la empresa..

(28) 8 CONCLUSIONES El proceso de planeación y seguimiento es muy importante en las empresas de software. Cualquier ayuda que mejore los tiempos y la eficiencia de este proceso es bien recibida por las empresas. El uso de herramientas es uno de los puntos claves para el mejoramiento de este proceso. Las herramientas deben automatizar la mayoría de actividades del proceso para que la administración de éste sea más fácil. Es importante tener en cuenta los recursos asociados al proceso de mejoramiento y la prioridad que este proyecto tiene dentro del trabajo de los mismos, dado que de ello depende que el ritmo de trabajo que se maneje no se vea tan afectado por la disposición del recurso y afecte finalmente la consecución de los objetivos planteados. Al realizar el trabajo en las empresas nos dimos cuenta que nos hizo falta establecer un estándar o esquema para el levantamiento de información en cada empresa. Dado que con cada empresa trabajó una persona diferente los resultados del levantamiento de información no contemplaron la misma organización. Ambas partes levantaron la información necesaria pero no se llevó una guía para poder comparar los resultados obtenidos en cada empresa. La recomendación por seguir es establecer plantillas para que dicho levantamiento de información sea llevado de igual manera por todos los miembros participantes del proyecto con las empresas. Vale resaltar que esta recomendación no sólo aplica para el levantamiento de información sino que se debería tener en cuenta para el resto del proceso. La metodología de trabajo utilizada durante este proyecto no fue desarrollada con la formalidad requerida. La investigación que se hizo del modelo Ideal se hubiese podido hacer más profunda para tener más claridad durante el desarrollo del proyecto. Esto nos dejó como enseñanza que se debe formalizar el proceso desde la fase planeación. De esta forma podemos vincular las diferentes etapas del modelo en el cronograma de trabajo, siendo más conscientes de que el trabajo se está llevando a cabo bajo un modelo establecido. Para que esto no vuelva a suceder es importante tener en cuenta es estudio previo del modelo por parte de los nuevos integrantes del proyecto con las empresas. Para finalizar, creemos que es importante formalizar la documentación del trabajo con las empresas teniendo en cuenta la metodología. La propuesta es que en el sitio del proyecto (Wiki) se tengan las plantillas necesarias para las diferentes actividades que involucra el modelo Ideal. Esta información debería estar organizada por las diferentes fases del modelo, logrando distinguir claramente los entregarles de cada una de éstas y de esta manera llevar el proceso de mejoramiento al estado de formalización deseado..

(29) 9 BIBLIOGRAFÍA ●. [1] The IDEALSM Model. http://www.sei.cmu.edu/ideal/. Recuperado 10 de Junio de 2005.. ●. [2] The IDEALSM Model: A Practical Guide for Improvement. Jennifer Gremba, Chuck Myers. Artículo publicado en Bridge, publicación del Software Engineering Institute (SEI), 1997. http://www.sei.cmu.edu/ideal/ideal.bridge.html. Recuperado el 10 de Junio de 2005.. ●. [3] Mejoramiento de procesos de software. Rubby Casallas. Departamento de Ingeniería de sistemas – Universidad de los Andes. Presentación de clase..

(30)