Reporte inicial. Metodología

Transcripción

1 Reporte inicial Este reporte inicial expondrá las decisiones que tomamos al momento de selección de metodología, plantillas y métodos de recabado de evidencia y por qué tomamos dichas decisiones. Metodología En lo que respecta a la metodología, elegimos utilizar Kanban mezclado con algunas prácticas de Scrum. Las opciones que evaluamos previo a nuestra elección final fueron Extreme Programming, Scrum y Kanban. + Extreme Programming fue descartado porque, aunque vimos que sus prácticas son más sencillas al momento de creación de documentación, las de construcción del software son algo más estrictas y complicadas para llevar a cabo. Así como que casi todo el proceso de verificación y validación se hace durante la construcción y no queríamos empezar a programar durante este proceso inicial de especificación del software. Además, no estamos familiarizados con la metodología y no es fácil de aplicar. Por ejemplo: preferimos trabajar los tres al mismo tiempo al momento de programar y no tener dos personas frente a la misma computadora. No solo porque no nos parece muy efectivo para un programa de este nivel de complejidad (sencillo), si no que somos solo tres personas y haría falta una más para cumplir el proceso correctamente. Por eso preferimos irnos por una metodología más liviana, pues quisimos explorar nuestra propia forma de interactuar como equipo antes de adoptar un sistema más serio. + Descartamos Scrum por el hecho de que, aunque se parece bastante a Kanban, exige que se trabaje en Sprint. Como la construcción del proyecto no nos tomará demasiado tiempo (decidimos acabarla en un día, dos como máximo), es complicado estar preparando Sprints de algunas horas y haciendo reuniones cada vez que acabe uno. Scrum es bastante flexible y sencillo, pero aun nos impone ciertas prácticas que resultarían incómodas más que beneficiosas a la hora de realizar el trabajo. La práctica que tomaremos para unir con Kanban será la de, al momento de construcción del software, hacer pequeñas reuniones, tipo Daily Scrum o Scrum de Scrum, para comunicar al grupo cómo va el trabajo que se está haciendo. + Kanban es la metodología más abierta y flexible de las tres que vimos. Lo elegimos por el hecho de que no nos ofrece criterios o prácticas tan sólidamente definidos y aun así nos da el mínimo necesario para nuestro proyecto. Kanban nos da más libertad a la hora de decidir cómo vamos a hacer el trabajo. Esta metodología exige entre sus criterios que se tenga una pizarra donde se vaya marcando el proceso de desarrollo de las actividades y sea visible en cada momento en qué punto de desarrollo se encuentra el equipo. Esto nos llamó

2 la atención porque así tendremos mayor control y conocimiento de las actividades que estamos desarrollando. Seguimiento de tareas Para el seguimiento de las tareas de nuestro proyecto, y llevar un récord de las actividades que se fueran creando, decidimos emplear algún mecanismo que nos permitiera hacerlo de forma sencilla y sin necesidad de muchos recursos. Quisimos contar con algún modo fácil y a la vez efectivo de llevar un historial de nuestras acciones como equipo y cumplir con el criterio de la pizarra de actividades de Kanban. Para esta tarea hicimos una lluvia de ideas para considerar qué características debería tener la herramienta que utilizaríamos. La herramienta debe ofrecer: una forma sencilla de marcar las nuevas actividades y presentar el desarrollo de esta por etapas, la posibilidad de hacer lista de actividades (checklists) para tener un conteo de ciertos puntos específico que necesitaría cada actividad para cumplirse y que podamos tener un historial de cómo se trabajó para que luego fuera más fácil retroalimentarnos de qué estábamos haciendo bien y qué puede mejorar. Luego de un análisis de estas opciones llegamos a la conclusión de utilizar alguna herramienta digital para que cumpla con dichas características. No quisimos utilizar pizarras o papel, por ejemplo, porque es más tedioso y se gastan muchos recursos. Además, como estudiantes de Ingenieros de Software apoyamos el uso de aplicaciones que nos permitan trabajar con menos esfuerzo. Encontramos una aplicación web denominada Trello, que simula tarjetas de actividades y checklists agrupadas en tableros que pueden ser fácilmente compartidos con otros usuarios. La aplicación nos pareció excelente para cubrir nuestras necesidades de seguimiento de tareas ya que proporciona los recursos que necesitábamos, además de un ambiente gráfico muy sencillo de usar, pero a la vez muy poderoso. No nos tomamos la molestia de ver otras opciones porque en realidad no nos pareció necesario emplear mucho tiempo en esto. Creamos una pizarra llamada Tennis Game Board sobre la cual trabajaremos 1. Requerimiento Plantillas de especificación de software En lo que respecta a la creación de la plantilla de especificación de requerimientos, la desarrollamos de la siguiente forma: 1 Pizarra de actividades en Trello:

3 + La especificación la dividimos por etapas porque sabíamos que durante el proceso de creación de arquitectura y diseño los requerimientos podrían variar. Por lo que definimos un esquema ligero y luego utilizando como guía la plantilla Volere, levantamos los requerimientos mas estructurados. + Utilizamos una simplificación de la Volere porque responde correctamente las necesidades que teníamos: un rango de importancia de los requerimientos para luego crear el log de actividades en el tablero de Kanban, tipo de clasificación del requerimiento, una codificación para luego reconocerlos más fácilmente en otros documentos y tres espacios para definir claramente qué se busca resolver con dicho requerimiento. + Decidimos hacer los casos de uso como parte de los requerimientos luego de que nos dimos cuenta de que la arquitectura puede ser validada al ser comparada con dichos casos de uso. Además, el modelo de vista 4+1 necesita una serie de escenarios que pueden ser fácilmente sacados de estos casos de uso. Utilizamos como referencia la plantilla de Larman, pero la recortamos un poco, ya que el sistema que vamos a desarrollar no necesita tantas especificaciones. + El análisis de los requerimientos lo haremos elaborando modelos conceptuales. Aunque existen métodos formales, son demasiado complicados para lo que queremos desarrollar y la mayoría no conoce dichos métodos. Arquitectura En cuanto a la plantilla de especificación, validación y verificación de la arquitectura, tomamos estos criterios para elaborarla: + Decidimos elaborar la arquitectura con el modelo de vista 4+1. La decisión de utilizar modelo de vista 4+1 se basa en qué, después de leer sobre las diversas formas de elaborar la arquitectura, esta era una forma sencilla, representa diversos puntos de vista de la arquitectura y además se puede realizar con diagramas UML, con los que estamos familiarizados. En la especificación de la arquitectura también decidimos llevarlo por etapas e ir guardando las modificaciones que se hacían. + En la verificación decidimos, aunque no es tan necesario, consultar con personas que conocen del tema para verificar nuestra arquitectura. Luego de buscar un tiempo encontramos una lista de puntos específicos que debía cumplir la arquitectura para considerarse bien realizada. Tomamos elementos de dicha lista como forma de verificación porque preguntaba sobre los diversos criterios de arquitectura y envuelve la información esencial que debe contener una arquitectura. + Como validación de la arquitectura la compararemos con los requerimientos, para ver si los módulos especificados cumplen con las necesidades que ya habíamos descrito. Además, ya que utilizamos el "modelo de vista 4+1", también compararemos con los casos

4 de uso que elaboramos como parte de los requerimientos. Otro método es otra lista de puntos específicos que leímos debe incluir la arquitectura y que van acorde con el proceso de validación. Decidimos hacerlo así porque es rápido (ya tendremos los requerimientos y casos de uso ya elaborados) y nos permitirá evaluar la coherencia entre todas las vistas y lo que ya habíamos planteado en como sería el programa. Diseño En lo que respecta a la plantilla de especificación, validación y verificación del diseño, decidimos hacer lo siguiente: + Para la especificación del diseño, decidimos hacer nuestro diseño usando UML y utilizamos la herramienta Astah (Community Edition) pues ya la conocíamos y es gratuita (además de que está para muchas plataformas). Usaremos diagramas de clase para especificar nuestro diseño y algunos diagramas de secuencia. + Para la verificación del diseño, consideramos inicialmente presentarle nuestro diseño a desarrolladores profesionales para obtener retroalimentación y luego pensamos que sería mejor comparar nuestro diseño con líneas de guía conocidos sobre qué se puede considerar como un buen diseño. Así podremos hacer un análisis objetivo de nuestro diseño sin depender en opiniones particulares de desarrolladores. + Para la validación del diseño, decidimos comparar los elementos que lo conforman con los elementos que conforman la arquitectura para ver si se corresponden y por tanto el diseño implementa correctamente a la arquitectura. Estrategias de recabado de evidencias Decidimos guardar la documentación relevante al proyecto usando el mismo sistema de control de versiones que utilizaremos para nuestro código e incluso el mismo repositorio. Decidimos hacer esto porque provee visibilidad en lo que respecta a la presencia y evolución de la documentación y la "evidencia" que se va acumulando a medida que transcurre el proceso de creación del software. La presencia misma de un historial del repositorio muestra que hubo un desarrollo gradual de todo lo que constituyen los entregables. El sistema de control de versiones que fue escogido fue Git, pues aunque vimos a las alternativas Mercurial y SVN, consideramos que no había ninguna ventaja significativa para nuestros fines y necesidades, y ya había experiencia previa usando Git. Para el repositorio elegimos usar los servicios de SourceForge, pues nos ofrecían ciertas ventajas como un correo interno que planeamos utilizar, característica que no existe en las otras 2 opciones que vimos, dígase GitHub y BitBucket.

5 Las evidencias de cada proceso y de que se cumplió las especificaciones de cada plantilla tendrá el siguiente formato: + Requerimientos: existirá un documento de texto para los requerimientos y los casos de uso. Se evidenciará su evolución y desarrollo por el historial del repositorio. + Arquitectura: cada etapa de la arquitectura será representada por diversas imágenes sacadas de la herramienta que utilizamos para elaborarla. La especificación tendrá un documento de texto aparte donde describa todas sus partes y las diferentes vistas. Evidencia de la verificación y validación también estará en el documento donde se presentará la lista de puntos tomados en cuenta y una breve especificación de los cambios que generaron dichos procesos. Evidencia de la retroalimentación se verá en varias capturas de pantalla de las conversaciones y respuestas obtenidas. + Diseño: las etapas del diseño también se verá por las diferentes imágenes subidas al repositorio. La especificación también tendrá un documento de texto que la describa brevemente. Evidencia de la verificación y validación también estará en el documento de texto con los puntos tomados en cuenta y los resultados obtenidos. Los documentos de texto se guardaron en formato.txt en el repositorio para que no hubiera ningún problema en lectura de los datos por parte de la plataforma. Los reportes serán subidos a los archivos del repositorio en formato.pdf para mejor lectura.