Metrocarrier Informe Postmortem Revision de Servicio de Video Para Grupo Posadas Ángela Archila, Edison Molano, Enrique Kook, Gustavo Gutiérrez, Jesús Larrota 24/08/2010 Contenido 1 2 3 Introducción .......................................................................................................................... 5 1.1 Alcance .......................................................................................................................... 5 1.2 Descripción del Documento .......................................................................................... 5 1.3 Definiciones, Siglas y Abreviaturas................................................................................ 5 1.4 Referencias .................................................................................................................... 5 Contexto ................................................................................................................................ 6 2.1 Objetivos del Proyecto .................................................................................................. 6 2.2 Requerimientos de Ciclo ............................................................................................... 6 2.3 Equipo ........................................................................................................................... 6 2.4 Planeación ..................................................................................................................... 7 2.5 Compromisos ................................................................................................................ 7 Reporte de Proyecto ............................................................................................................. 9 3.1 Reporte de Actividades ................................................................................................. 9 3.1.1 Actividad 1: Estudiar la Arquitectura Actual del Banco......................................... 9 3.1.2 Actividad 2: Modelar los Procesos Actuales.......................................................... 9 3.1.3 Actividad 3: Ajustar los Nuevos Procesos a la Infraestructura Actual................... 9 3.1.4 Actividad 4: Identificar Entidades de Negocio ...................................................... 9 3.1.5 Actividad 5: Identificar Actores ........................................................................... 10 3.1.6 Actividad 6: Identificar Funcionalidades de Negocio .......................................... 10 3.1.7 Actividad 7: Aplicaciones Legado ........................................................................ 10 3.1.8 Actividad 8: Matrices de Análisis......................................................................... 10 3.1.9 Actividad 9: Requerimientos no Funcionales ...................................................... 11 3.1.10 Actividad 10: Contratos ....................................................................................... 11 3.1.11 Actividad 11: Creación de Cuentas de Usuario y Cambio de Contraseñas ......... 11 3.1.12 Actividad 12: Instalación Básica del Ambiente de Desarrollo ............................. 11 3.1.13 Actividad 13: Creación de las Bases de Datos ..................................................... 11 3.1.14 Actividad 14: Montaje de las Aplicaciones Legado ............................................. 11 3.1.15 Actividad 15: Puesta en Ejecución del Proceso ................................................... 11 3.1.16 Actividad 16: Modificaciones al Proceso ............................................................. 11 3.2 Avance Frente a Metas del Ciclo ................................................................................. 11 3.2.1 Meta 1.1 – Determinar Componentes ................................................................ 11 3.2.2 Meta 1.2 – Determinar Brechas .......................................................................... 12 3.2.3 Meta 1.3 – Análisis de Arquitectura Actual ......................................................... 12 3.2.4 Meta 1.4 – Identificación de Servicios ................................................................ 12 3.2.5 Meta 1.5 – Análisis de Aplicaciones .................................................................... 12 3.2.6 Meta 1.6 – Atributos de Calidad ......................................................................... 12 3.2.7 Meta 1.7 – Diseños de Arquitectura ................................................................... 12 3.2.8 Meta 1.8 – Puesta en Marcha del Proceso Actual .............................................. 13 3.2.9 Meta 1.9 – Modificaciones al Proceso ................................................................ 13 3.3 4 Informe de Riesgos ...................................................................................................... 13 3.3.1 Riesgo 1 – Errores de Diseño ............................................................................... 13 3.3.2 Riesgo 2 – Retrasos en Actividades ..................................................................... 13 3.3.3 Riesgo 3 – Inasistencia a Reuniones .................................................................... 13 3.3.4 Riesgo 4 – Poca o Nula Disponibilidad de Equipos.............................................. 14 3.3.5 Riesgo 5 – Desarrollo Inadecuado de Competencias .......................................... 14 3.3.6 Riesgo 6 – Errores de Estimación ........................................................................ 14 3.3.7 Riesgo 7 – Errores de Comunicación con el Cliente ............................................ 15 3.3.8 Riesgo 8 – Problemas de Infraestructura ............................................................ 15 Reporte de Producto ........................................................................................................... 17 4.1 Calidad de Entregables ................................................................................................ 17 4.1.1 5 6 Informe de Defectos............................................................................................ 18 Reporte de Proceso ............................................................................................................. 20 5.1 Avance frente a Metas del Ciclo.................................................................................. 20 5.2 Avance frente a Planeación ......................................................................................... 20 5.2.1 Estado Actual ....................................................................................................... 20 5.2.2 Valor Ganado ....................................................................................................... 21 5.2.3 Tiempos frente a Planeación ............................................................................... 21 5.3 Seguimiento ................................................................................................................ 21 5.4 Equipo ......................................................................................................................... 22 5.4.1 Líder del Grupo .................................................................................................... 23 5.4.2 Líder de Planeación ............................................................................................. 23 5.4.3 Líder de Desarrollo .............................................................................................. 23 5.4.4 Líder de Calidad ................................................................................................... 23 5.4.5 Líder de Soporte .................................................................................................. 23 Resumen .............................................................................................................................. 24 6.1 Logros Alcanzados ....................................................................................................... 24 6.2 Problemas Encontrados .............................................................................................. 24 6.3 Lecciones Aprendidas .................................................................................................. 24 6.4 Oportunidades de Mejora ........................................................................................... 25 1 Introducción 1.1 Alcance Este documento abarca el proceso de Postmortem del Ciclo 1 de desarrollo del proyecto de automatización del proceso de originación de crédito del Banco de los Alpes. 1.2 Descripción del Documento En el capítulo 1 se hace una breve introducción a este documento, indicando su propósito, su alcance, describiendo su contenido y declarando las definiciones, siglas, abreviaturas y referencias a que haya lugar. En el capítulo 2 se presenta un contexto general de lo estipulado en el lanzamiento y la estrategia del proyecto, incluyendo objetivos, requerimientos del ciclo, equipo de trabajo, planeación inicial y compromisos del grupo. En el capítulo 3 se presenta el reporte de actividades y avance respecto a metas del proyecto, incluyendo los riesgos del mismo y los eventos que se han presentado respecto a cada uno de ellos y a sus estrategias de mitigación. En el capítulo 4 se hace un reporte de avance en la elaboración del producto, describiendo su avance en términos de casos de uso, y el nivel de calidad con que ha sido desarrollado. En el capítulo 5 se hace un reporte del proceso en términos de sus metas, el avance frente a lo planeado, cómo se ha realizado el seguimiento y cómo ha funcionado el equipo. 1.3 Definiciones, Siglas y Abreviaturas BPMN – Business Process Modelling Notation. ISO – International Standards Organization TI – Tecnología Informática. TSP – Team Software Process. 1.4 Referencias Wiki del Proyecto – Grupo Neotect http://backus1.uniandes.edu.co/~csof5104a04/dokuwiki/doku.php Documento de Arquitectura por Componentes 2 Contexto 2.1 Objetivos del Proyecto Automatizar el proceso de originación de crédito (segmentación del mercado, validación del riesgo, estudio de crédito, apertura de productos, realce y activación) del Banco de los Alpes. Construir una solución automatizada de acuerdo a los requerimientos del Banco de los Alpes y respetando aspectos como la arquitectura de TI, restricciones de tecnología, tiempo, alcance y costo. Adaptar y desarrollar el diseño para los nuevos procesos que satisfaga la estructura establecida por el Banco de los Alpes en términos de arquitectura actual de TI, portafolio de servicios y aplicaciones legado existentes. Analizar y diseñar la arquitectura de software que permita la construcción de los servicios identificados en la arquitectura de solución. Correcto funcionamiento de la actual y nueva implementación del proceso de originación de crédito del Banco de los Alpes en el ambiente de desarrollo. Para cada uno de estos objetivos las metas se encuentran planteadas dentro de la estrategia planteada para el Ciclo 1, documentada en la Wiki del proyecto. 2.2 Requerimientos de Ciclo Dado que el presente ciclo no tiene entregables de partes de software, este no contemplará el desarrollo de requerimientos funcionales del producto, por consiguiente dichos entregables de la siguiente manera: Realizar el estudio de la arquitectura actual del banco de los Alpes. Adaptar la arquitectura objetivo desarrollada por Neotect a la arquitectura actual del banco de los Alpes entregada. Incluir los servicios de la arquitectura objetivo elaborada por Neotect al portafolio de servicios existente en el banco de los Alpes. Estudio de los productos sobre los cuales se va a hacer la implementación, los editores que los soportan y el proceso de despliegue. Poner a funcionar, en el ambiente de desarrollo de cada grupo, la implementación actual del banco. Configurar los ambientes de desarrollo del proyecto 2.3 Equipo Se dio un cambio de roles con respecto a lo que se venía manejando el semestre pasado. Excepto por el Líder de Calidad, a todos los demás miembros del equipo les fue asignado un rol diferente al que anteriormente ocupaban. Líder de Edison José Grupo Molano Líder de Wolfgand Planeación Enrique Kook Líder de Jesús Andrés Conducir al grupo asegurarse de que todos los integrantes reportan sus datos y terminan su trabajo como se planeó. Dar soporte y guía al grupo en las tareas de planeación y seguimiento del proyecto. Liderar y guiar el grupo en la definición, diseño, desarrollo y Desarrollo Larrota pruebas del producto. Líder de Ángela Archila Dar soporte al grupo en la determinación, obtención y Calidad Rincón administración de las herramientas necesarias para desarrollar el producto. Líder de Gustavo Adolfo Definir las necesidades del proceso, hacer el plan de calidad Soporte Gutiérrez y hacer seguimiento al proceso y a la calidad del producto. 2.4 Planeación Debido a las características específicas del proyecto, las actividades planteadas para TSP no aplicaban específicamente para el ciclo. Sin embargo, se procuró realizar un ajuste de las mismas para efectuar la planeación, lo cual dio lugar a la siguiente distribución. Actividad Lanzamiento Estrategia Planeación Requerimientos Plan de pruebas del sistema Diseño de Alto Nivel Diseño Detallado Implementación Pruebas Postmortem Tareas Administrativas Total Horas % Estimado 9% 15% 15% 22% 0% 7% 0% 9% 9% 7% 7% Horas 12 20 20 30 0 10 0 12 12 10 10 136 2.5 Compromisos Establecer un sitio de Reuniones (apartamento líder de calidad) y además ser puntual y participar activamente en ellas. Cumplir con los compromisos adquiridos para llevar a cabo el proyecto. De lo contrario se incurrirá en el sistema de multas. Cumplir con la disponibilidad propuesta para el desarrollo del proyecto por cada uno de los miembros del grupo. Realizar aportes al grupo para producir un producto de calidad. Mantener actualizado el wiki con todos los artefactos necesarios luego de pasar por las revisiones e inspecciones. Mantener comunicación continua con los miembros del grupo de trabajo por cualquiera de los medios existentes (teléfono, Chat, correo, wiki, skype). En caso de no asistir a alguna de las reuniones ya establecidas, el miembro del grupo debe comunicar al líder y enviar un informe del estado de avance del proyecto, si es en la reunión de entregas para inspección, debe adjuntar los artefactos junto con la lista de chequeo de los documentos. Y luego de la reunión el líder debe entregar a ese miembro del grupo sus nuevas responsabilidades. Cada miembro del grupo debe registrar en la planeación el tiempo en que demoro realizando cada tarea Cada uno debe velar por el cumplimiento de sus objetivos en cada ciclo En caso de no cumplir con los objetivos y metas propuestas el líder debe estar enterado las razones del atraso y tomar medidas pertinentes en compañía del líder de planeación y calidad. Se debe manejar un ambiente de armonía y compañerismo dentro del grupo. 3 Reporte de Proyecto 3.1 Reporte de Actividades 3.1.1 Actividad 1: Estudiar la Arquitectura Actual del Banco Debido a que la solución propuesta por Neotect LTDA, tiene como restricción alinearse con la estructura actual del Banco y además debe integrarse con los desarrollos y aplicaciones existentes, la descripción de estas propiedades se encuentra descrita en el Documento “AnalisisDisenoActual.pdf” proporcionado por el Banco de Los Alpes. La actividad anterior se cumplió en un 100%, logrando este objetivo para el ciclo presente, para ello los analistas de Neotect LTDA, realizaron el estudio correspondiente a la estructura actual del banco, encontrando fuertes impactos sobre la solución propuesta en meses anteriores lo cual tendrá que ser mitigado y resuelto en el siguiente ciclo del proyecto. 3.1.2 Actividad 2: Modelar los Procesos Actuales Como segunda actividad del producto para este ciclo, se hizo imperativo realizar el modelamiento de los procesos actuales del Banco de los Alpes dadas sus características en arquitectura de TI, entendiendo que los procesos aquí expuestos son la base para la automatización que finalmente es lo que se busca con este proyecto. Esta actividad se cumplió en un 100%, logrando este objetivo para el ciclo presente, el equipo de analistas de Neotect LTDA modeló los procesos en forma BPMN bajo la estructura definida actualmente por el Banco de los Alpes. 3.1.3 Actividad 3: Ajustar los Nuevos Procesos a la Infraestructura Actual La tercera actividad requerida fue el ajuste de los procesos que se modelaron de forma previa por los analistas de Neotect LTDA. Esto se debe a que el Banco exige que las nuevas implementaciones se integren con los desarrollos anteriores al igual que las aplicaciones existentes. Esta actividad fue cumplida en un 100%, logrando este objetivo para el ciclo presente. Luego de las restricciones proporcionadas por el Banco de los Alpes, y de la información suministrada de sus procesos actuales, el equipo de Neotect, vio la necesidad de ajustar su propuesta de solución, enfocándola en la estructura actual del Banco, con el firme propósito de cumplir las nuevas expectativas y condiciones surgidas recientemente. 3.1.4 Actividad 4: Identificar Entidades de Negocio La cuarta actividad consistió en identificar las entidades de negocio existentes en el Banco de los Alpes y alinearlas con las que fueron propuestas por el equipo de Neotect en su solución previa de cara a la automatización de su proceso de originación de crédito. La actividad en mención fue culminada en un 100%, en donde se identificaron las entidades existentes por cada una de la aplicaciones legado del Banco y se contrastaron con las entidades que se encontraban en la propuesta de solución del grupo de Neotect. 3.1.5 Actividad 5: Identificar Actores La quinta actividad correspondió con la identificación de los actores involucrados, tanto en los procesos existentes del Banco y sus correspondientes aplicaciones, como con los actores identificados en la propuesta solución realizada por Neotect. Esta actividad se realizó en un 100%, para lo cual se estableció una comparación directa entre los procesos existentes y los procesos ajustados con los cuales se identificaron los actores correspondientes. 3.1.6 Actividad 6: Identificar Funcionalidades de Negocio La sexta actividad se enfoca en identificar aquellas funcionalidades de negocio que fueron elaboradas por Neotect y que actualmente no existen en el Banco de los Alpes. Esta actividad se realizó en un 100%. Algunas funcionalidades ya se encontraban al interior de los procesos del banco y otras pueden ser construidas con las herramientas proporcionadas por la entidad (portafolio de servicios). No se identificaron funcionalidades que deban ser desarrolladas desde un punto vacio. 3.1.7 Actividad 7: Aplicaciones Legado La séptima actividad para este ciclo, corresponde a la identificación, estudio y entendimiento de las aplicaciones legado que existen en el Banco de los Alpes. Esta actividad posee un alto nivel de importancia debido a que la automatización del proceso de originación de crédito tiene su base en estas aplicaciones y son ellas las que nos indican el alcance de lo que se puede implementar. Esta actividad se realizó en un 100%. Se identificaron las aplicaciones Legado y se hizo un análisis de las mismas, incluidas sus características y su funcionamiento. Se establecieron las responsabilidades dentro del proceso y se hizo un mapeo de cada aplicación con las funcionalidades que soporta. 3.1.8 Actividad 8: Matrices de Análisis Entidades vs. Actividades: Se establecieron todas las relaciones entre las entidades existentes en el sistema y las actividades que se desarrollan en los diferentes procesos. Durante del desarrollo del análisis de la arquitectura empresarial y de solución realizadas durante el proyecto de primer semestre, se encontraron varias de las entidades mencionadas en este nuevo documento de análisis y diseño, sin embargo se fue necesario realizar algunos ajustes al análisis inicial, con el fin de satisfacer las necesidades expresadas por el Banco de los Alpes. Funcionalidades vs. Procesos: Se identificó y dedujo la relación entre funcionalidades y procesos del sistema según el documento provisto por el banco. Entidades vs. Aplicaciones Legado: Al igual que en el análisis de entidades por actividades, fue sencillo identificar varias de las entidades ya consignadas en el análisis de arquitectura empresarial y sus correspondientes dueños representados en aplicaciones legado que actualmente las administran. Funcionalidades vs. Aplicaciones: Se identificó y dedujo la relación entre funcionalidades y procesos del sistema según el documento provisto por el banco. 3.1.9 Actividad 9: Requerimientos no Funcionales Fue abordado el tema de los requerimientos no funcionales de acuerdo a los conocimientos adquiridos en los cursos de análisis y diseño y arquitectura por componentes, y se establecieron los requerimientos no funcionales requeridos por el Banco de los Alpes. Se creó un árbol de utilidad soportado por el documento de Arquitectura por Componentes, que detalla mejor los compromisos adquiridos por Neotect en el desarrollo de dicha arquitectura. 3.1.10 Actividad 10: Contratos Se identificaron los contratos de servicio y se procedió a la creación de contratos para aquellos que no se encontraban ya disponibles en el Banco. Se estimaron 4 iteraciones, de acuerdo a los métodos de identificación de servicios, sin embargo aún no se ha terminado una de las iteraciones, y por tanto es posible que algunos servicios no hayan sido identificados. En total, estimamos un avance del 58% con respecto a la totalidad de las subtareas que componen esta actividad. 3.1.11 Actividad 11: Creación de Cuentas de Usuario y Cambio de Contraseñas Se ingresó al ambiente replicado por el Banco de los Alpes y se crearon apropiadamente las cuentas de usuario con sus respectivas contraseñas. Se cambió la contraseña del usuario administrador. 3.1.12 Actividad 12: Instalación Básica del Ambiente de Desarrollo Se montó el ambiente de desarrollo sobre Eclipse, de acuerdo a lo estipulado en la guía de montaje dada por el Banco. Aún no se ha podido acceder al ambiente de desarrollo por vía remota. 3.1.13 Actividad 13: Creación de las Bases de Datos Se crearon las Bases de Datos para cada una de las aplicaciones legado, de acuerdo a la guía de montaje proporcionada por el Banco. Se verificó sobre el explorador de la Base de Datos phpmyadmin la correcta instalación y carga de datos en cada una de las Bases de Datos creadas. 3.1.14 Actividad 14: Montaje de las Aplicaciones Legado Se realizó el montaje de las aplicaciones legado a través de la herramienta ant, con ayuda de la herramienta anexa de Eclipse para este fin, y de acuerdo a la guía de montaje de aplicaciones proporcionada por el Banco. Sólo una de las aplicaciones montadas generó errores al realizarse el montaje de la misma, y aún nos analizando el problema. 3.1.15 Actividad 15: Puesta en Ejecución del Proceso El proceso aún no ha sido puesto en ejecución. 3.1.16 Actividad 16: Modificaciones al Proceso No se ha realizado modificación alguna sobre el proceso actual del Banco. 3.2 Avance Frente a Metas del Ciclo 3.2.1 Meta 1.1 – Determinar Componentes Determinar los componentes del proceso actual con su funcionamiento y establecer a partir de allí la cantidad a modificar y crear requerida para el mejoramiento de sus procesos. Estado: Se han determinado los componentes del proceso actual a nivel conceptual y se ha creado un entorno replicado sobre el cual se ha verificado su funcionamiento, sin haberlo detallado completamente aún. Los componentes a modificar y crear han sido identificados a nivel conceptual (El “Qué”), pero no a nivel técnico (El “Cómo”). 3.2.2 Meta 1.2 – Determinar Brechas Determinar las brechas en los procesos actual y requerido, estableciendo los proyectos para cerrar cada una de ellas. Estado: Meta lograda al 100%. 3.2.3 Meta 1.3 – Análisis de Arquitectura Actual Descubrir, identificar y estudiar la arquitectura actual de TI del Banco de los Alpes con el propósito de establecer el impacto y las restricciones a tener en cuenta para el desarrollo del nuevo diseño de procesos de la originación de crédito. Estado: El grupo se encuentra aún en proceso de conocer mejor las tecnologías específicas con el fin de establecer claramente el alcance en términos de impacto y restricciones. 3.2.4 Meta 1.4 – Identificación de Servicios Descubrir e identificar los servicios que no se encuentran incluidos en el portafolio actual del banco y desarrollarlos, además de estudiar y utilizar los existentes. Estado: Falta una iteración de las 5 planeadas para la identificación de servicios. 3.2.5 Meta 1.5 – Análisis de Aplicaciones Descubrir, identificar y estudiar (procesos de despliegue) las aplicaciones legado existentes en el Banco de los Alpes y sobre las cuales se apoyaran e implementaran los nuevos procesos de automatización de originación de crédito. Estado: Las aplicaciones han sido desplegadas adecuadamente y en el momento el grupo se encuentra en proceso de estudiar su construcción y funcionamiento. 3.2.6 Meta 1.6 – Atributos de Calidad Identificar los atributos de calidad más importantes desde la percepción del Banco para tomar acciones certeras sobre las características de la solución a desarrollar. Estado: Se han establecido los atributos de calidad y sus métricas asociadas, y se ha creado el árbol de utilidad correspondiente. Se ha realizado una evaluación completa de los atributos de calidad. La meta se ha logrado al 100%. 3.2.7 Meta 1.7 – Diseños de Arquitectura Elaborar los diseños técnicos requeridos que permitan tener bosquejos de arquitectura de software con el fin de probar conceptualmente los criterios de calidad establecidos en el proyecto. Estado: Se ha elaborado el modelo conceptual y a primer nivel describiendo en forma general la arquitectura de la aplicación. 3.2.8 Meta 1.8 – Puesta en Marcha del Proceso Actual Funcionamiento del 100% del proceso actual del proceso de originación de crédito. Estado: El proceso se ha puesto en funcionamiento adecuadamente de acuerdo a la implementación actual dada por el Banco. Cumplimiento al 100%. 3.2.9 Meta 1.9 – Modificaciones al Proceso Funcionamiento del 100% del proceso actual con pequeñas modificaciones de mejoramiento. Estado: Aún no se han realizado las modificaciones indicadas por el Banco. 3.3 Informe de Riesgos 3.3.1 Riesgo 1 – Errores de Diseño Errores de diseño presentes en la arquitectura de solución propuesta. Estado: En este momento el riesgo no ha tenido probabilidad de materializarse. Estrategia de Mitigación: Neotect usará las tácticas/técnicas de análisis y diseño aprendidas en los diferentes cursos de la especialización, todo sustentado en la disciplina requerida por las metodologías de trabajo en equipo usadas para el desarrollo del presente proyecto. Dentro de las acciones a tomar en pro de evitar la capitalización de este riesgo, se encuentra por ejemplo las revisiones por pares de ingenieros, durante las cuales se detectarán los posibles errores inyectados. Estado de la Estrategia: Implantada y seguida al 100%. 3.3.2 Riesgo 2 – Retrasos en Actividades Retraso de alguno de los miembros del equipo en la entrega de las actividades asumidas al inicio de la planeación. Estado: El riesgo se ha materializado en varias oportunidades, pero su impacto ha sido minimizado por la labor de los otros integrantes del grupo. La probabilidad de materialización del riesgo sigue vigente. Estrategia de Mitigación: Para mitigar este riesgo es fundamental el compromiso de cada una de las partes del equipo con la entrega a tiempo (según lo planeado) de los artefactos completos, aún más cuando de la realización y completitud de estos dependen otras tantas actividades del ciclo asignadas a otros compañeros. Estado de la Estrategia: Se ha comprobado que la estrategia no es suficiente, por lo que se ha establecido un esquema de multas ante retrasos con las entregas, y una redistribución de cargas para minimizar el impacto. Asimismo, se ha establecido como compromiso de cada miembro del equipo avisar con anticipación cualquier sobrecarga de trabajo que le impida cumplir a tiempo con las tareas asignadas. 3.3.3 Riesgo 3 – Inasistencia a Reuniones Inasistencia de uno de los miembros del equipo a alguna de las reuniones de seguimiento. Estado: El riesgo se ha materializado en varias oportunidades, pero su impacto ha sido minimizado por la labor de los otros integrantes y la comunicación del grupo. La probabilidad de materialización del riesgo sigue vigente. Estrategia de Mitigación: Implementar y hacer uso del plan de comunicaciones para que por medio de este se establezcan acciones a tomar para dar a conocer a los integrantes del grupo el horario de las reuniones además de generar compromiso con respecto a la asistencia a las mismas. Es importante el sentido de deber de cada uno de los participantes citados a la reunión, para dar un correcto manejo a su agenda de tal manera que sus actividades cotidianas no interfieran con la agenda de reuniones. Estado de la Estrategia: En forma adicional se ha extendido el esquema de multas para los retrasos sin previo aviso a las reuniones; se ha procedido con las reuniones normalmente, y se han tomado decisiones por mayoría. Se ha expandido el plan de comunicaciones para informar a los miembros del equipo que no participen de la reunión de las decisiones que se toman en la misma. 3.3.4 Riesgo 4 – Poca o Nula Disponibilidad de Equipos Poca o nula disponibilidad de alguno de los computadores del equipo de trabajo. Estado: Se han presentado fallas menores, pero en ningún momento han impedido las labores del equipo de trabajo. Estrategia de Mitigación: Se procura el uso adecuado de las máquinas destinadas al desarrollo del proyecto, tomando precauciones mínimas de uso de antivirus, firewall y diferentes herramientas que apoyan el uso seguro de los sistemas de producción del proyecto. Estado de la Estrategia: Se encuentra en funcionamiento y ha funcionado efectivamente. 3.3.5 Riesgo 5 – Desarrollo Inadecuado de Competencias Desarrollo inadecuado de las competencias requeridas para la utilización de las herramientas de software provistas para el progreso del proyecto. Estado: Hasta el momento, éste no ha sido un problema dentro de la ejecución del proyecto. Estrategia de Mitigación: El grupo de trabajo se encuentra en proceso de adquisición de las competencias necesarias para el uso correcto de estas herramientas, necesarias para el desarrollo del proyecto. Cada miembro del equipo ha decidido hacerse cargo del aprendizaje de la configuración y manejo de cada uno de los sistemas requeridos como parte del soporte de la solución propuesta en el proyecto. Estado de la Estrategia: Se ha visto insuficiente. Aún el conocimiento de las herramientas es mínimo, la documentación insuficiente, y el apoyo del equipo técnico del Banco inexistente. Las alternativas para dar solución a este problema latente se encuentran aún en discusión. 3.3.6 Riesgo 6 – Errores de Estimación Errores en la estimación de tiempos asignados para la realización de tareas correspondientes a los ciclos. Estado: El riesgo se ha materializado constantemente. Sin embargo, fallas en las estimaciones por exceso han tendido a compensarse con fallas en estimaciones por defecto, lo cual ha tendido a subsanar los problemas. Estrategia de Mitigación: Neotect se ha preocupado por afinar sus métodos de estimación a través de las técnicas aprendidas en los cursos de la especialización y de la concienzuda utilización de los postmortem obtenidos de los diferentes talleres y ejercicios realizados en lo que va corrido del postgrado. Es por esto que confiamos en la correcta utilización de estos mecanismos en el desarrollo del presente proyecto. Estado de la Estrategia: Se ha visto insuficiente, pues si bien las técnicas aprendidas en los demás cursos permiten estimar fácilmente el tamaño y el esfuerzo asociado al desarrollo de Software, muchas de las tareas no son específicamente asociadas al desarrollo. Se ha buscado retroalimentación a partir de semanas anteriores, lo cual ha venido dando resultados paulatinamente, pero se estima que aún faltan varias iteraciones antes de realizar un ajuste que se aproxime a la realidad. 3.3.7 Riesgo 7 – Errores de Comunicación con el Cliente Errores en la comunicación entre el grupo de desarrollo y el cliente del proyecto. Estado: El riesgo se ha materializado constantemente. Ha habido retrasos y problemas que no han sido informados por el cliente, y preguntas que no han sido contestadas. El cliente ha procurado dar plazos a las entregas para compensar por estos problemas, pero esto no ha logrado compensar los tiempos y costos para Neotect. Estrategia de Mitigación: Neotect ha implementado un plan para la gestión de las comunicaciones, de cuya correcta utilización depende el éxito del intercambio de información entre él y el cliente del proyecto. Se estimaron los medios existentes para ser utilizados como canales apropiados de transferencia de la información y las actividades a seguir para la correcta comunicación entre las partes. Estado de la Estrategia: Se ha visto insuficiente. En este momento Neotect se encuentra evaluando alternativas que permitan mitigar este riesgo. 3.3.8 Riesgo 8 – Problemas de Infraestructura Mal funcionamiento de la infraestructura de tecnología disponible para el desarrollo del proyecto. Estado: Hasta el momento, la infraestructura tecnológica ha tenido un buen funcionamiento. Sin embargo, los miembros del equipo no se sienten aún seguros en cuanto a su capacidad para responder efectivamente a cualquier problema que se presente con esta infraestructura. Estrategia de Mitigación: Se cuenta con el personal idóneo para la utilización de esta infraestructura, personal que se encuentra en proceso de capacitación, lo que le permitirá hacer uso correcto de la misma; esto reducirá considerablemente la posibilidad de ocasionar daños o mal funcionamiento de las plataformas. Estado de la Estrategia: Se ha visto insuficiente. Se ha procurado que cada miembro del equipo se documente sobre las herramientas que componen la infraestructura, haciéndose experto en la misma, para minimizar la probabilidad de fallas debidas a error humano. 4 Reporte de Producto El producto para este ciclo en particular no tiene entregables de software por lo que no se constituyó una pieza de software probada y en ambiente de pruebas oficial. Lo estipulado para este primer ciclo se enfoca en la preparación completa y estratégica de lo que finalmente será el proyecto y cómo será la integración de la solución, con lo que actualmente posee el Banco de los Alpes. 4.1 Calidad de Entregables En este ciclo se instauro un plan de calidad basado en los resultados del grupo en la etapa de TSP desarrollada al comienzo del año, se establecieron métricas, metas, y un proceso el cual se debe tener en cuenta para el proceso de pruebas, se espera que a medida que se utilice se pueda ir mejorando y adaptando a las necesidades del grupo y del producto de nuestros clientes. Nos basamos en ISO 9126 el cual abarca características que se tuvieron en cuenta al definir las métricas, se resumen el siguiente cuadro. Para el primer ciclo el proceso mencionado no se requiere o no se tendrá en cuenta, debido a que en el primer ciclo los objetivos a cumplir no requieren de desarrollo de código del producto, sino documentos que permiten realizar el análisis del producto a construir. Sin embargo, se presenta a continuación. 4.1.1 Informe de Defectos El objetivo primario de las inspecciones es encontrar errores en el producto para evitar que se conviertan en defectos después de la entrega del software. El beneficio obvio de estas inspecciones es el descubrimiento de errores al principio para que no se propaguen al paso siguiente del proceso de desarrollo del software. Según acuerdo del equipo, y con la aprobación de líder de calidad se toma la decisión de realizar inspecciones especiales al documento de arquitectura de componentes donde se describen las necesidades del negocio, los motivadores, las restricciones y se priorizan los atributos de calidad, para establecer el enfoque que tomará el producto según las necesidades del Banco los Alpes en su proceso de originación de crédito. Específicamente, para este documento se realizan las inspecciones de la siguiente manera: se establece que todos los miembros del equipo deben realizar inspección al documento, se corrigen defectos una vez encontrados, y se maneja un control de cambios, sin embargo, las inspecciones no se realizan paralelamente, sino que se asignaron turnos, logrando así 5 iteraciones, donde la última persona que realiza la inspección tiene un documento de una muy alta calidad. Para los demás artefactos se asignan responsables para la revisión y la inspección de los documentos, se resume a continuación los hallazgos encontrados en todos los artefactos revisados: Ciclo: 1 Documento Arquitectura Modelo de procesos as-is Ajustes de proceso to-be Entidades Total Defectos Encontrados 8 5 10 4 27 Defectos Corregidos 8 5 8 4 25 Tiempo Invertido 2h 2h 4h 2h 10h Los resultados son dispersos, la tasa de inspección y corrección inmediata es de: 2.5 defectos/ hora. El grupo analiza que depende la complejidad del artefacto el tiempo invertido para detección y corrección es variable, se desea a medida que se va iterando lograr mejorar el proceso de inspección y corrección y llegar así a tomar menos tiempo invertido a las correcciones. Y culminarlas al 100% así como se define en las metas. Se instauro un sistema de multas en dos circunstancias, la primera, personas que no cumplan con sus actividades en las fechas acordadas, la segunda, personas que lleguen tarde a las reuniones establecidas con anterioridad por el grupo. Este sistema nos ha permitido cumplir con nuestra meta de menos de dos días de desfase en la planeación del proyecto. 5 Reporte de Proceso 5.1 Avance frente a Metas del Ciclo 5.1.1.1 Meta 2.1 – Informes de Inspección Se recogió la totalidad de los informes de inspección (100% de ellos) en la página control del proyecto. Estado: En un principio el proyecto avanzó sin la realización de inspecciones formales, a causa del peso que esto imponía sobre el proceso y de la premura de tiempo. Después de llegar a un acuerdo entre todo el equipo, se determinó un cambio en el proceso de calidad, que permitió la realización de inspecciones. A partir de ese punto, se recogió el 100% de los informes correspondientes. 5.1.1.2 Meta 2.2 – Brecha de Planeación en Valor Durante el desarrollo la diferencia entre el valor ganado y el valor planeado no fue mayor al 10%. Estado: En un principio, la diferencia superó el 30%. A medida que el proyecto ha avanzado, la diferencia se ha disminuido hasta un mínimo de 3%. Los detalles se encuentran en el capítulo siguiente. 5.1.1.3 Meta 2.3 – Brecha de Planeación en Tiempo La diferencia entre el tiempo planeado y el tiempo real de la duración no presenta una variación superior al 4% del total del tiempo estimado. Estado: Aunque para el plan como un todo la variación se ha mantenido constante y dentro del rango, la diferencia entre el tiempo planeado y el real de duración para las diferentes tareas sí ha presentado una diferencia bastante alta, en ocasiones hacia arriba, y en ocasiones hacia abajo, lo que ha terminado por balancear el tiempo total. 5.1.1.4 Meta 2.4 – Retrasos en Avances No se presentaron retrasos (0 en número de demoras) en la entrega de avances comprometidos como parte de entregables de mayor importancia. Estado: En un principio, se presentaron bastantes demoras. Los retrasos disminuyeron durante las siguientes semanas, y no se han presentado retrasos desde la tercera semana. 5.2 Avance frente a Planeación 5.2.1 Estado Actual En este momento se presenta un avance del 71% en el proyecto, lo que corresponde a un 89% de lo planeado a la fecha. Se han efectuado las labores planeadas correspondientes al proceso TSP en su mayor parte, y se han ejecutado varias de las tareas correspondientes al ajuste de los documentos entregados por el Banco de los Alpes a la arquitectura propuesta. 5.2.2 Valor Ganado 120% 100% 80% 60% 40% 20% 0% 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Estimado Real 5.2.3 Tiempos frente a Planeación Se presentaron bastantes retrasos en un principio, a causa de la pérdida de ritmo del grupo respecto a lo adquirido el semestre anterior. Tras la reunión de seguimiento de la primera semana se evaluó el avance y se tomaron acciones correctivas, que condujeron a una gran mejoría en las siguientes semanas. Aún teniendo esto en cuenta, es claro que el avance del equipo en las tareas del proyecto es relativamente bajo en los días entre semana, y tiene saltos evidentes en los fines de semana. A pesar del compromiso del grupo para ponerse al día en sus tareas, se presentó un retraso en las entregas de los insumos por parte del Banco, que dificultó el avance en las tareas asignadas para la última semana del ciclo. En general, algunos de los integrantes han mantenido un ritmo constante desde el inicio del proyecto. Otros, sin embargo, comenzaron a un ritmo bastante lento, y fue necesario imponer multas y otras penalidades para lograr su compromiso. 5.3 Seguimiento El plan de seguimiento realizado por el grupo para el proyecto de originación de crédito del Banco de los Alpes se dividió en tres partes principales realizadas en las semanas definidas para el mismo: La reunión de seguimiento de la primera semana partió de la evaluación de las tareas realizadas referentes a la construcción del lanzamiento y estrategia del grupo hacia el primer ciclo en el cual se revisaron los objetivos generales y específicos del mismo, se realizó revisión sobre objetivos y metas por cada uno de los integrantes del equipo de trabajo y se confirmó la disponibilidad de los integrantes frente al proyecto a realizar. Una vez realizado el lanzamiento del presente ciclo, se verificaron las estrategias de producto orientadas al manejo de la calidad de los entregables, se validaron los riesgos del equipo frente al proyecto y sus planes de mitigación y se estableció la planeación de la siguiente semana de acuerdo a todos los entregables a manejar. En este primera reunión de seguimiento se aclararon dudas en relación a la responsabilidad de los roles y se establecieron compromisos claves de comportamiento al interior del grupo de trabajo. La segunda reunión de seguimiento realizada por el equipo de trabajo fue basada en la verificación de tareas ejecutas vs las tareas planeadas haciendo incremental la adopción del proceso de TSP. En él se tomaron medidas de acción frente a los compromisos de las tareas asignadas, se aclararon entregables que se no estaban completamente detallados, se comunicó el manejo de los riesgos que fueron revelados en la semana y se determinaron planes de acción contra los mismos. Como punto principal de la reunión de seguimiento de esta semana se observó la necesidad de incluir en el proceso todos los entregables asociados o no al proyecto que el equipo debe realizar para el conjunto de materias de la especialización buscando definir mejor las actividades y responsabilidades del grupo frente a la siguiente semana. Como parte de la estrategia específica de ciclo, la semana 2 inició con la conceptualización de los documentos de la arquitectura actual del banco entendiendo el proceso actual, los servicios construidos, el esquema de construcción, las tecnologías adoptadas por el banco para la construcción de los productos y forma de atacar la siguiente semana de construcción. El seguimiento realizado de la semana 3 fue realizado haciendo énfasis en el post-mortem de proceso recuperando información de lecciones aprendidas, evaluación del grupo de trabajo, oportunidades de mejora para el siguiente ciclo, logros alcanzados, recopilación de información por cada uno de los frentes de trabajo de acuerdo a roles y responsabilidades e informe de estado actual de proyecto. Si bien el ciclo aún se encuentra en proceso y aún existen entregables y compromisos de entrega, consideramos que el equipo de trabajo ha adoptado la metodología planteada y ha desarrollado habilidades incrementales en dicho proceso realizando adaptaciones a las necesidades buscando el éxito del proyecto. 5.4 Equipo El equipo presentó fallas hacia el principio del ciclo, pues el ritmo que se venía manejando del semestre pasado se había bajado, y a algunos de los miembros les costó un poco retomarlo. En la primera reunión se dio un “jalón de orejas” al grupo, y de común acuerdo se implantó un sistema de multas que fue impuesto de inmediato, y que tuvo buenos resultados para el resto del ciclo. Todos los miembros del equipo, con la excepción del líder de Calidad, cambiaron sus roles, lo cual creó problemas, en algunos casos, en cuanto a la transmisión de conocimiento y a la apropiación de las actividades. Hacia el final del ciclo, sin embargo, todos los miembros del equipo se habían apropiado del nuevo rol, y lo ejercían en forma apropiada. Aún a pesar de los obstáculos mencionados, el equipo funcionó apropiadamente, y cada uno de sus miembros estuvo pendiente de ejecutar las tareas asignadas, y de apoyar a sus compañeros cuando así fuese necesario. 5.4.1 Líder del Grupo Tomó desde el principio el liderazgo del grupo, y supo motivarlo para el trabajo en equipo, así como manejar efectivamente los conflictos que surgieron durante este ciclo. Fue el miembro más comprometido con el cumplimiento de tiempos tanto en las tareas como en las reuniones. Faltaron algunas acciones de seguimiento, si bien estas fueron implementadas gradualmente a lo largo del ciclo. 5.4.2 Líder de Planeación Se desagregaron bien las actividades de cada uno de los miembros del equipo, y se hizo seguimiento acertado de las tareas a ejecutar y del valor ganado. Quedaron, sin embargo, algunas tareas que no se vislumbraron, y en ocasiones esto llevó a la sobrecarga de algunos miembros del equipo. 5.4.3 Líder de Desarrollo El nuevo líder de desarrollo hizo una planeación acertada de la forma en que el equipo iba a desagregar el trabajo para la creación y adaptación del documento de arquitectura, y efectuó una distribución acertada del mismo, de acuerdo con los conocimientos y roles de cada miembro del equipo. Faltó una mejor planeación, sin embargo, de la forma en que dichos esfuerzos iban a ser integrados para la generación del documento final. 5.4.4 Líder de Calidad Se mantuvo al frente de su área, que había asumido desde el principio del curso de especialización, y definió políticas claras y efectivas, adaptando el proceso de verificación para aprovechar la revisión de pares, la tecnología existente y las ventajas del control de cambios de herramientas como Microsoft Word, y estableciendo también entregas claras y verificables. 5.4.5 Líder de Soporte El nuevo líder de soporte supervisó la actualización del Wiki, y se mantuvo al frente de la provisión de herramientas para el trabajo en grupo. Si bien al parecer hubo una falla en la transición de roles, que por un tiempo lo dejó desactualizado en cuanto a las herramientas disponibles y su ubicación, lideró efectivamente todas las tareas tendientes al montaje del ambiente replicado y a la puesta en funcionamiento del proceso actual del Banco. 6 Resumen 6.1 Logros Alcanzados La planeación fue conjunta, lo cual la hizo más efectiva. Las responsabilidades de cada rol fueron asumidas muy bien y cada uno se apropio de su respectivo rol. Se definieron compromisos claros en el grupo, a través de un sistema de multas que creó conciencia en sus miembros. Se aprovecharon las herramientas disponibles para lograr una comunicación fluida entre los miembros del equipo. Se dedicó bastante tiempo al análisis del documento y al ajuste de la arquitectura. Se logró una revisión conjunta de los procesos, lo que permitió que se lograra un artefacto de alta calidad. 6.2 Problemas Encontrados Pérdida de ritmo en el grupo, en términos de seguimiento del proceso. Demoras en la ejecución de tareas y en la asistencia a reuniones. El cambio de roles produjo fallas de información en las personas que asumieron un nuevo rol. El hecho de que uno de los miembros del grupo no esté viendo una de las materias de la especialización dificulta reuniones y desbalancea en parte el grupo. Las dificultades laborales de dos de los miembros del grupo dificultaron la ejecución de las tareas que tenían asignadas, lo cual afectó bastante el avance del proyecto. La demora en la entrega de insumos clave por parte del Banco provocó un retraso en varias de las tareas críticas. 6.3 Lecciones Aprendidas Crear un sistema de multas para retrasos en las tareas y en la llegada a las reuniones funciona más como un elemento disuasivo para retrasos en dichas tareas que como elemento de lucro. Se deben implementar mecanismos claros de transferencia de conocimiento cuando se planean cambios de roles entre los miembros del equipo. No es necesaria una herramienta compleja para hacer seguimiento a las tareas. Una buena comunicación en el equipo y una herramienta básica como Google Docs pueden suplir herramientas más especializadas. De la misma manera, existen soluciones alternativas que pueden optimizar el proceso de calidad, y la revisión de pares, sumada a herramientas como el control de cambios de Word, parecen ser útiles en ese sentido. Las reuniones demasiado extensas, sin objetivos claros, sin control de tiempos y a horas muy tardías se vuelven improductivas. Un documento de Word no es suficiente para la visualización integral de matrices complejas de análisis de arquitectura empresarial. Todo análisis de este tipo debe ser apoyado por herramientas externas que permitan la visualización global de toda la problemática. 6.4 Oportunidades de Mejora Se debe adaptar el proceso a las particularidades del proyecto, puesto que TSP está orientado principalmente al desarrollo de Software, y el componente de desarrollo de Software, tanto en este ciclo como en los subsecuentes, es mínimo. Se debe buscar una forma para que cada miembro del grupo pueda visualizar más fácilmente sus actividades, y para que se facilite el seguimiento de las mismas. Se debe iterar sobre el proceso de calidad, buscando la mejor forma de hacerlo eficiente a través de la revisión de pares y el uso del control de cambios, pero sin perder la formalidad y especificidad lograda con la rigurosidad del método propuesto por TSP.