AI11 Práctica.

Modelo de diagrama de caso (ArgoUML)

Se desea realizar el análisis y diseño para implementar un desarrollo en web que permita
administrar el trabajo que se lleva de manera manual en un equipo de desarrolladores de software,
mediante la filosofía de trabajo vista en el curso.

En esta actividad se busca la obtención de una serie de actividades con las cuales deberás
obtener, el análisis y diseño (casos de uso, diagramas de clase, diagramas de secuencia) del caso
de uso.

En el siguiente guion se describen los pasos que pretenden la sistematización de un servicio web,
que cómo veras es programación, esa etapa no se implementa en este curso, como resultado de
esta actividad deberás entregar el análisis y diseño.

Enunciado del problema:

Guion

En un equipo de desarrollo los colaboradores se pueden asociar a grupos de trabajo que se definirán
en el sistema, pero esto lo hace el administrador del grupo que se denomina Scrum Master, este
puede crear un grupo y se encarga de su gestión (alta y baja de usuarios en el grupo y eliminación
del grupo).

Los usuarios se pueden asociar a grupos de trabajo que se definirán en el sistema, pero esto lo hace
el administrador del grupo que se denomina Scrum Master, este puede crear un grupo y se encarga
de su gestión (alta y baja de usuarios en el grupo y eliminación del grupo).

Cada miembro del equipo (Scrum Team) tiene acceso a un área de trabajo personal. Ésta, consta
de un calendario, una lista de historias de usuario que deberá de realizar durante la semana o
quincena y un área para realizar anotaciones, un área para reportar el avance de la historia de
usuario de manera diaria, además de opciones gráficas que permitan visualizar el avance de manera
global del sistema de información que se está construyendo. Esta debe demostrar el valor ganado
de las actividades realizadas de manera individual y en equipo.

Los ítems son seleccionados por el Scrum Team, el Scrum Master y el Product Owner en la Sprint
Planning Meeting a partir de la priorización de los ítems y los objetivos que se marcaron para ese
Sprint. A partir de los objetivos a cumplir durante el Sprint, el Scrum Team determina qué tareas
debe desempeñar para cumplir el objetivo. De esto surge el Sprint Backlog.

Es importante destacar que es el equipo quien se organiza para alcanzar el objetivo. El Manager no
asigna tareas a los individuos y tampoco toma decisiones por el equipo. El equipo puede agregar
nuevas tareas o remover tareas innecesarias en cualquier momento, si lo considera pertinente para
cumplir el objetivo. Pero el Sprint Backlog solo puede ser modificado por el equipo. Las estimaciones
se actualizan cada vez que aparece nueva información.
El calendario permite ver por días y/o semanas, la finalización de cada una de sus actividades o
módulos a entregar y, en meses, la finalización del proyecto.

Los resultados que se obtienen de los reportes individuales se deben de concentrar en información
que sirva al product owner y al scrum master a tomar decisiones sobre el desarrollo del proyecto.
Para ello, se deben visualizar datos como son las gráficas de valor ganado, obtener métricas de
productividad de cada uno de los integrantes y observar principalmente en el cumplimiento en tiempo
y forma de los compromisos planeados en determinada fecha.

Las entradas son alimentadas por el programador del sistema en cuestión. Cada entrada tiene un
identificador de la historia de usuario que desarrolla, la prioridad de esta (alta, mediana, baja), la
fecha de inicio y termino de la historia de usuario, avance porcentual de cada una de ellas y
comentarios que puedan tener los programadores.

Las entradas pueden ser públicas (cualquier usuario puede verlas), otros grupos de desarrollo no
podrán visualizar los avances. Solamente el scrum master podrán ver los avances del proyecto que
tengan con el equipo. El sistema deberá validar que los integrantes del equipo no sean asignados a
otros proyectos.

El calendario también ofrece la posibilidad de sacar una lista de todos los requerimientos, con varias
opciones, por ejemplo, entre dos fechas, a partir de una fecha, las relacionadas con el equipo de
desarrollo, etc.

En la lista de historias de usuario, cada una consta de una fecha de terminación, un título, un texto
descriptivo y una prioridad. También tiene un indicador de hasta qué punto se ha cumplido el
porcentaje, que cuando llega a 100 es que se ha completado. Se podrán crear, consultar (de varias
maneras, por nombre, estado y fecha de terminación), modificar o borrar elementos de esta lista. La
fecha de terminación se verá reflejada en el calendario dependiendo, del periodo de fecha de término
pactada en la iteración del desarrollo.

Se debe contar con una agenda que controle las reuniones que se realizan en el Scrum como son:
Sprint Planning Meeting, Sprint Backlog, Daily Scrum Meetings y Sprint Review Meeting. Para ello,
al desarrollador se le deberá avisar de manera automática el día de reunión y los compromisos que
se acordaron para su entrega. Omitir lo anterior para la Daily Scrum.

Cada reunión tendrá un título, descripción de objetivos y la agenda de la reunión, así como lugar,
fecha y duración. Para decidir la fecha, el usuario que propone la reunión indicará un rango de fechas
y el sistema proporcionará una lista de las más convenientes para todos, según sus agendas. El
promotor de la reunión podrá elegir una fecha entre éstas o pedir al sistema que permita votar (en
un tiempo límite) a los invitados a la reunión por una fecha, en cuyo caso se elegirá la fecha más
votada. Cada invitado recibirá la solicitud de voto cuando se conecte al sistema. La fecha de la
reunión final se apuntará en la agenda de todos los usuarios invitados a la reunión.

1. Realizarás un proceso de analisis y diseño en ArgoUML, para una aplicación web que
pueda servir para gestionar el seguimiento de actividades del caso mencionado.
2. Para tener mayor referencia del funcionamiento de Scrum se sugiere hacer lectura del
siguiente documento: https://fi.ort.edu.uy/innovaportal/file/2021/1/scrum.pdf

3. Realiza un diagrama de casos de uso con las siguientes características:

a. Nomenclatura de los casos de uso: con verbos adecuados al contexto del caso
planteado.
b. Nomenclatura de los actores: con sustantivos adecuados al contexto del caso planteado.
c. Los casos de uso deben de cubrir las funciones del enunciado.
d. Las relaciones entre los casos de uso deben ser las correctas según el enunciado.
e. No colocar casos de uso en los que solamente se debe apretar un botón.

4. Considera lo siguiente:
a. Todos los casos tienen una especificación de caso de uso ligada a él.
b. Existe coherencia entre el diagrama de caso de uso y las especificaciones.
c. El objetivo de un caso de uso se obtiene del enunciado.
d. Las precondiciones, postcondiciones y secuencia normal, son coherentes para la
realización del objetivo. La secuencia normal debe reflejar el diálogo entre un usuario
y la interfaz del sistema.
e. Debe presentar un caso alternativo por cada caso de uso, que corresponda a la
secuencia de acciones cuando el usuario pulse “cancelar”. Se valora positivamente
otros flujos alternativos, siempre que sean coherentes con el caso de uso que se
implementa.

5. La especificación deberá ser llenada en el formato de plantilla, revisada en el contenido

de la Unidad 2.