SPAI: EGit2

Descripción del proyecto

Se parte de un proyecto ya desarrollado, y se pretende realizar una ampliación del mismo.

En la actualidad, el proyecto consta de cuatro clases:

• NumeroEntero, maneja números enteros, ofreciendo diversas funcionalidades
• Persona, almacena el nombre y apellido, controlando el formato del mismo y mostrando diferentes representaciones
• ColeccionDecimales, maneja una colección de valores decimales de tipo double
• Fraccion, maneja fracciones matemáticas

Se acompañan los test de las clases, pero se deberán cambiar para la nueva versión.

####Las posibles ampliaciones podrían ser las siguientes:####

NumeroEntero

• Limitar los límites posibles: 0..100, -10..+10 ...
• Los métodos incrementar y decrementar podrán aceptar un parámetro con la cantidad
• Incluir el métodos sumar, multiplicar...

Persona

• Presentar el nombre en mayúsculas
• Incluir métodos con otras formas de presentar el nombre completo
• Permitir nombres compuestos, separados por blancos y controlar las mayúsculas y minúsculas

ColeccionDecimales

• Incluir métodos como menor, multiplicar, tamaño, media...

Fracciones

• Incluir métodos como isPropia, isImpropia. Las fracciones propias son aquellas cuyo numerador es menor que el denominador, y las fracciones impropias el resto
• Incluir el método isEquivalente. Dos fracciones son equivalentes cuando el producto de extremos es igual al producto de medios
• Incluir métodos para comparar fracciones: mayor, menor
• Incluir métodos para sumar, restar, multiplicar o dividir fracciones

Se pueden realizar otras, pero cuidado!!! es responsabilidad del Arquitecto finalizar la ampliación del proyecto :-o.

####Tickets Los tickets se publicarán con el título: issuesXxx#n (siendo Xxx un identificador: Dev: develop, Bug: bugs... y n un número correlativo) y una pequeña descripción del mismo, tendrán un enlace a una página wiki, con el mismo nombre, que lo describe con detalle. Deberán tener plazos temporales y estimaciones de tiempo (1 unidad equivale a 5 minutos). Cuando un Programador finalice, incluirá el tiempo real utilizado.

No olvidéis, si con tanto cambio se produce descontrol y pánico!!! enfocar un commit estable, hacer reset mediante el menú contextual y marcar Hard

Pasos a seguir

Fase 1. Integrantes de los proyectos

Sorteo para asignar a cada Arquitecto su equipo de tres Programadores

Fase 2. Preparar proyecto en el repositorio

El Arquitecto deberá preparar una copia del proyecto en su cuenta de GitHub

1. Clonará el repositorio (https://github.com/miw-upm/EGit2.git) en su cuenta, con el botón Fork de la Web de GitHub
2. Le cambiará el nombre del repositorio copiado a EG2Arquitecto
3. Añadirá como colaboradores del proyecto a su la lista de Programadores
4. Importará este proyecto en su equipo local, y le cambiará el nombre del proyecto (Refactor>Rename): EG2Arquitecto
5. Publicará en la plataforma de la moodle.upm los datos del proyecto, en el apartado GitHubs de la asignatura

Fase 3. Preparar proyectos en equipos locales

Los Programadores importarán este proyecto en sus equipos. Recordar establecer las llaves SSH

Fase 4. Planificación de la ampliación por parte de Arquitecto

El Arquitecto establecerá las ampliaciones que pretende acometer, y la distribución de tareas mediante tickets. Recordar que no podrá realizar ninguna modificación directa del software, pero si puede realizar tareas de preparación de ramas, fusiones, generaciones de Tags, generación del Jar...

Fase 5. Programar los test

1. El Arquitecto mandará tickets a cada Programador para explicar las ampliaciones que se deben acometer, y el test asignado: NumeroEnteroTest, PersonaTest, ColeccionDecimalesTest y FraccionTest. Los programadores tendrán que realizar los test e incluir el método público en las clases.
2. Los Programadores cerrarán los tickets cuando hayan finalizado

Fase 6. Programar las clases

1. El Arquitecto mandará tickets para implementar las clases, el programador que hace el test no puede implementar la clase, excepto Fraccion, que se asignará un método a cada Programador
2. El Programador realizará los tickets con agilidad y corrección. Una vez que termine, deberá cerrarlo indicando el tiempo real ocupado

Fase 7. Comprobación final del proyecto

1. EL Arquitecto comprobará el buen funcionamiento de la ampliación. Si tuviera errores, creará nuevos tickets.
2. Finaliza la ampliación, creando una versión beta para publicar

Evaluación

La nota de este ejercicio sólo se tendrá en cuenta el rol de Arquitecto, y no olvidéis que queda todo registrado, con las cuentas de los integrantes. Si un Programador no cumple con sus obligaciones, el Arquitecto deberá buscar alternativas entre el resto del personal.

Será fundamental acabar el proyecto para obtener un 5, y el resto de la nota, se obtendrá viendo el desarrollo de equipo, teniendo en cuenta la dificultad del mismo, uso adecuado de las ramas, el uso de los tickets, de la wiki, la coordinación...

Suerte chic@s!!!