K2BIM Informe Final de Configuración Versión 1.0

Transcripción

1 K2BIM Informe Final de Configuración Versión 1.0 Historia de revisiones Fecha VersiónDescripción Autor 15/11/ Creación del documento Yasim Zeballos

2 Contenido 1. Resultados Finales de SCM Planificado vs. Realizado Cantidad de errores encontrados [Elemento de configuración X] Actividades de Control de Configuración Actividades de Revisión del estado de la Configuración y Auditorias Evaluación Final Fase Inicial Primera Iteración Fase de Elaboración Primera Iteración... 0

3 1. Introducción (Resultados Finales de SCM) Se comentarán las actividades realizadas por el Responsable de SCM, sobretodo contrastando contra lo planificado en el Plan de Configuración. En términos generales el Plan de Configuración no se siguió de forma muy estricta, el dinamismo que permite la edición de documentos en Google Docs, así como las ventajas de la descentralización del control de documentos, primaron sobre hacer un seguimiento estricto de los elementos de configuración. Se optó porque cada integrante fuera responsable de dejar los productos de forma consistente. Debido al tamaño del producto y con una buena modularización de las actividades a realizar, no se suscitaron problemas de relevancia, en particular, se suscitaron muy pocos problemas. El tener un ambiente de desarrollo estable desde el principio, y una estructura de documentación entendible y funcional, fueron ingredientes suficientes para un correcto manejo de la configuración autónoma y efectiva por parte del grupo. El enfoque se debe más que nada a una idiosincrasia de laissez faire, laissez passer del Responsable de SCM, y a su poca vocación por controlar. 1.1 Planificado vs. Realizado Se hace una tabla para contrastar la práctica con la planificación, los detalles se encuentran en la siguiente sección. Lo planificado fue: Identificar los elementos de la línea base del proyecto. Definición de la línea base. Fijar una política de nomenclatura de los elementos de configuración para facilitar la identificación y ubicación de éstos en el proyecto. Llevar a cabo el control de la configuración, estableciendo estándares y procedimientos a seguir con respecto a los cambios para permitir un control de los mismos Realizar auditorías y revisiones de configuración. Seguimiento de la línea base. Realización de backups. Definición del ambiente controlado. Lo que se hizo fue: Se hicieron 4 definiciones de la línea base [Ver detalle de LIN_BASE] Se realizó desde el comienzo del proyecto, de forma clara y exitosa [Ver detalle en NOMENCLA] Se definieron los procedimientos. Y se creó documentación asociada. [Ver detalle en FAIL_CAMBIOS] No se realizaron. No se hizo un seguimiento estricto de la línea base. Se realizaron backups de la documentación. Se realizaron backups del código. [Ver detalle en BKP_COD] Se realizó con éxito al comienzo del proyecto. No surgieron inconvenientes por parte del equipo de desarrollo.

4 Realización de Informe de línea base del proyecto. Se realizaron de forma aperiódica. Se realizaron 3 informes. No parecieron reportarle beneficios al grupo Detalle de Planificado vs. Realizado LIN_BASE: Se llegó a una línea base de tamaño razonable recién en la etapa de construcción del software aproximadamente en la semana 7, debido a que fue particularmente difícil llegar a documentos de requerimientos estables. Se alteró el MUM y se creó la Fase de construcción de productos de investigación. Nuevamente hubo muchos documentos relevantes nuevos, que llegaron a ser estables cerca del final del proyecto. NOMENCLA: Se hizo énfasis en tener los documentos con un nombre descriptivo, y que las referencias sean consistentes en toda la documentación. Hubo muchas correcciones de nombre, así como discusiones de cual es el mejor nombre para cada cosa. No se registraron las correcciones porque se consideró que era improductivo registrarlo, y que bastaba con la acción correctiva de renombrar los documentos. FAIL_CAMBIOS: No se hizo un seguimiento de los cambios. La única vez que se trató de hacer vía documentación, trajo más problemas que soluciones. Un integrante del grupo realizó el cambio que estaba documentado, pero como no había sido revisado por el experto en el tema, se realizaron cambios que perjudicaron la documentación. Más adelante en el proyecto experto en el tema revirtió los cambios perjudiciales y realizó los cambios correctamente. Tampoco hubo cambios que tuvieran gran impacto. La documentación de requerimientos fue estable y acertada, y el desarrollo del producto fue estable y sin cambios relevantes. BKP_COD: El manejo de la documentación con google docs, prácticamente no requiere de una intervención explícita sobre el manejo de los documentos y sus versiones. Se hizo énfasis en que los documentos tuvieran nombres que los identifiquen, así como se trató de seguir los nombres estándares del MUM siempre que fuese posible. Respecto a la parte del código, el desarrollo en GeneXus implica manejarse con archivos ".xpz", ya que tal vez por inercia de como se hacían las cosas, se optó por no trabajar con GxServer que es un programa de gestión de código de GeneXus. Se almacenó el código en la cuenta de 200 MB de la Facultad de Ingeniería. Si bien en principio resultó ser una cantidad más que suficiente, en el punto que empezaron a haber deploys de los productos más grandes, el espacio resultó ser insuficiente. Y se optó por empezar a borrar archivos que se consideraban viejos. Esto introdujo inestabilidad en la gestión del código y de su respaldo, pero se aplicaron acciones correctivas que aseguraron la disponibilidad de los fuentes. En este aspecto la estructura de directorios que se creó al principio, así como las políticas, dieron resultados funcionales, pero es un poco confusa la organización de los archivos.xpz. 1.2 Cantidad de errores encontrados Los errores de configuración fueron manejados de manera informal, efectiva y autónoma por parte de los integrantes del grupo.

5 1.3 Actividades de Control de Configuración Únicamente se trató de procesar un cambio de manera formal. Los detalles del evento se pueden ver en > FAIL_CAMBIOS. 1.4 Actividades de Revisión del estado de la Configuración y Auditorias No se realizarón auditorías. Se realizaron informes sobre la línea base. Como se dice en la tabla de la sección 1.1, no pareció generar utilidad al grupo. Como autocrítica al plan de configuración, se puede señalar que cuando los documentos referencien a otro documento, mencionen a que versión del documento se refieren. Esto a veces se hizo y a veces no. Desde la parte de calidad se observó este hecho, pero no se suscitaron otros problemas debido a la falta del número de versión en las referencias. 2. Evaluación Final Una visión general del proyecto ya se vió en la introducción (sección 1). Se detallará el proyecto desde el punto de vista de la gestión de la configuración. Lo único que resta agregar, es que nunca se llegó a un criterio claro de cuándo debía un elemento incorporarse a la línea base. Tampoco se crearon documentos de descripción del producto, sin embargo, sí se creó el documento de Notas de la versión. 2.1 Fase Inicial Se comenzó estableciendo el manejo del ambiente controlado, se logra avanzar y obtener un ambiente estable, creándose una máquina virtual para distribuir al miembro del equipo que quiera. También se creó documentación interna al grupo con la especificación de todas las versiones de todo el software necesario para poder instalar el ambiente controlado en caso de que no se quiera simular con una máquina virtual. Esto se debió a que el IDE de GeneXus recomienda su uso con al menos 2GB de RAM, y las máquinas virtuales son programas que son "pesados", pues deben simular todo un sistema operativo. Se trataron de obtener todas las licencias para operar con el producto, hubo algunas complicaciones pero todos los integrantes terminaron obteniendo las licencias que necesitaban por parte del Cliente. Se creó un grupo de Google para centralizar la comunicación. Se tomó la acertadísima decisión de usar Google Docs para el manejo de documentos. El manejo de Google Docs probó bastante rápido ser una herramienta cómoda y eficaz para la gestión de documentos para un grupo de 14 personas. Se crea la nomenclatura de elementos, tomando la buena decisión de no codificar los nombres sino de orientarse a que "cada documento es lo que es" y se ponía el título del documento como nombre del archivo, a pesar de que resultara un poco largo. Tampoco se puso la versión del documento en el nombre del archivo, sino que la versión se ponía dentro del documento. Esto gracias a que existía un único documento que se encontraba "en la nube".

6 Se crearon algunas páginas web en la página del grupo de google para almacenar información que se considerase importante. Si bien al principio tuvo cierta actividad, ya al final del proyecto cayó en desuso. Probablemente porque para visitar una página del grupo son necesarios más o menos 3 o 4 clicks, frente a la inmediatez de comunicar cosas por correo electrónico, o hacer una búsqueda en la casilla de correo. 2.2 Fase de Elaboración Se fue estabilizando el documento del Plan de Configuración, de todos modos resultaba un poco confuso cómo se iba a implementar el control de cambios, así como qué criterio era el correcto para determinar la línea base. Se establecieron las políticas de backup y se fueron creando la estructura de directorios adecuada. 2.3 Fase de Construcción de productos de software. Se definió la línea base. Se estabilizó el documento del plan de configuración. Se realizaron informes sobre la línea base. Se realizan liberaciones del producto. Una liberación incluye el código fuente y el producto ejecutable. Incluye el código fuente porque la idea del producto es que sea una prueba de concepto que el Cliente potencialmente seguirá desarrolando en el futuro. Se llega a una versión bastante estable del producto, restando algunos ajustes de calidad. 2.4 Fase de Construcción de productos de investigación. Se comienzan a gestionar los documentos de investigación. Se incorporan a la línea base ya al final del proyecto. Se realizan ajustes mínimos al producto de software principal (K2BIM) Se crea documentación que indica la forma de instalar el producto. No se cumple con la realización de backups que debe realizarse de forma manual, ya que no se encontró forma de hacer backups automáticos de Google Docs. Debido a que el Responsable de SCM asumió el rol de investigador. Se crea el informe final de configuración (este mismo documento).