Este fue el comienzo del proyecto, en esta etapa se hizo una

Este fue el comienzo del proyecto, en esta etapa se hizo
una identificación primaria de los casos de uso más
importantes, los necesarios para poder realizar las
funciones principales del sistema, sin describir en
profundidad las demás acciones que se realizan.
En esta etapa se profundizo en la identificación de los casos de uso, se encontraron varios más,
se dividió al sistema en otros sub-sistemas que nos permitió separar las funcionalidades del
sistema principal (administrador de tareas) en: Administración de sprint y en evaluador, estos
no están separados si no que están relacionados por un includes ya que la evaluación se hace
siempre que se termina un sprint, y esta evaluación incorpora mas funcionalidades
dependiendo que evalúa.
Tambien se agrego relaciones de jerarquía entre casos de uso como en el caso de “crear
elemnto backLog “ que tiene como hijos a crear requerimiento y crear tarea. Lo mismo pasa
con “incluir requerimiento en elemento backLog” que es padre de “incluir requerimiento en
requerimiento” y de “incluir tarea en requerimiento”.
Algunos de los casos de usos incorporados son:





retornar tarea al backlog: aquí se identifico que una tarea que quedo
incompleta cuando finalizo un sprint, se debe retornar al repositorio para
que pueda finalizarse en otro sprint.
Incluir requerimiento en requerimiento: Interpretamos que un requerimiento
puede formar parte de otro requerimiento.
Incluir tarea en requerimiento: Los requerimiento además están formados
por tareas, y es importante agregarle sus tareas ya sea en su creación o
incluso tiempo después de que fue creado.
Comenzar sprint: Esto no es automático, la creación del sprint es
independiente al comienzo, o sea una vez que esta creado se dice cuando
comenzarlo según el criterio del lider.
Incluir tarea al sprint: cuando se asigna una tarea no se agrega
automáticamente una tarea, los pasos son al revés primero se agrega al
sprint.
Continua el diagrama con la relación <<includes>> desde el caso de uso finalizar sprint al
caso de uso “evaluar desempeño último sprint”
Este fue el primer diagrama de clases realizado, antes de la primera consulta donde teniamos
dudas sobre los roles De quien o quienes realizaban las tareas, donde se guaradaban, si tenian
una categoria, cuales eran sus estados, etc.
En esta segunda instancia y luego de introducirnos de lleno en el enunciado aparecieron
nuevas clases y dudas. Por ejemplo se introdujo una nueva jerarquia para implementar un
nuevo tipo de usuario, el lider. Es decir se introdujo la clase usuario y a esta se le agregaron
dos hijos la clase desarrollador, que es quien realiza las tareas, y la clase lider quien se encarga
de la parte administrativa ( crea y finaliza sprints, asigna tareas a usuarios, agrega tareas al
sprint, etc)
En esta instancia también se jerarquizo la tarea definiendo tareas complejas, triviales e
intermedias, las cuales dependiendo de la instancia van a poder ser resueltas por quien sea
competente.
Hasta el momento este es nuestro tercer diagrama de clases, el mismo esta sujeto a nuevas
transformaciones.
En esta insatancia fuimos entrando en detalle del modelado del sistema. Se agrego un reloj el
cual se encargara de calcular los tiempos del proyecto, de las tareas o de los sprint. Esta nueva
clase no esta decidida todavía, ya que la misma funcionalidad puede venir incorporada..
También se determino que se utilizara un patrón STATE en el estado de la tarea ya que no
puede haber dos estado en un mismo momento y el estado cambia sin que la tarea se enetere..
Otra incorporación fue la clase ElementoPendiente de la cual heredan comportamiento las
clases Requerimiento y Tarea. Aquí tambien se incorporo un patron COMPOSITE ya
que………………………..