El trabajo práctico consta de 3 entregas:
Cada una de estas entregas tiene una fecha asignada que pueden ver en el calendario.
La primera iteración se realiza utilizando un método basado en UP aunque simplificado, y la segunda iteración con SCRUM, con todas las limitaciones que implica que este no es un proyecto "real". El inicio y fin de la primera iteración están determinados por la materia. Esto también ocurre con la segunda iteración pero no es necesario tenerlo en cuenta al hacer la planificación que presentan con la primera entrega. Al entregar la planificación el docente que les corrige queda asignado como tutor del grupo y es quién les corregirá todas las entregas del trabajo. La entrega de la planificación es sin nota. Luego de la planificación y antes de la entrega de la primera iteración se debe presentar un borrador de la arquitectura ante el tutor asignado. De esta manera obtienen una opinión de quién les corrige sobre la arquitectura que están diseñando antes de la entrega. En la entrega de la primera iteración también se hace la presentación de la prueba de concepto ( Proof Of Concept (POC) ) donde se debe mostrar el sistema andando con todas la funcionalidades correspondientes a la primera iteración funcionando. Esto incluye mostrar que la aplicación cumple con un conjunto de tests dados por los docentes o que pueden surgir de ustedes o del docente al momento de hacer la POC. Al iniciarse la segunda iteración se pasa a modo SCRUM. Entre el inicio de la iteración y la fecha de la entrega deben realizarse 2 "simil" SCRUM Meetings por lo menos con el tutor, que viene a representar al product owner. Al finalizar la segunda iteración también debe hacerse una POC mostrando la funcionalidad pedida para esta entrega. Las pruebas incluyen los tests de regresión de la funcionalidad pedida en la primera iteración.
1. Lista de Casos de Uso 2. Planificación del Proyecto o "Esquema de Iteraciones" La
planificación se debe hacer teniendo en cuenta que es un proyecto que
se va a realizar con UP, ignorando que la segunda iteración se pasa a
SCRUM. Este ítem se refiere a una descripción de cuántas iteraciones tendrá el proyecto y de qué fase, y qué casos de uso se harán en cada una. 3. Planificación de la primera iteración -Tareas, dependencias entre las mismas, duración, asignación de recursos. -Les estimaciones se pueden hacer usando uno de los métodos aprendidos en clase, se debe aclarar como se realizaron las estimaciones. -Los casos de uso deben ser priorizados, los criterios usados deben ser aclarados. Se debe forzar a que los casos de uso que especifican los requerimientos pedidos para la primera entrega entren en la primera iteración.
Aquí la gestión del proyecto pasa a modo SCRUM, y por lo tanto los entregables son más simples. Unicamente se debe presentar la parte del sistema construida funcionando y un informe final cuyo detalle se describe al presentar la segunda parte del TP.
Consideramos que con la entrega del enunciado, en el ámbito del trabajo práctico, la etapa de Incepción finalizó. Por lo tanto, la primera iteración que hacen los alumnos corresponde a la fase de Elaboración. Es parte de la entrega de la planificación identificar las fases e iteraciones del proyecto completo.
Las decisiones de arquitectura y forma de implementarla son decisiones
de Ustedes. La arquitectura debe ser guiada por los atributos de
calidad y las tácticas elegidas para responder a las mismas. La
implementación debe responder a la arquitectura diseñada, se considera
un error que no lo haga. Obviamente si al momento de implementar la arquitectura se encuentra que ésta no es adecuada, se la puede modificar.
La especificación con CU no es uno de los objetivos del trabajo
práctico, el uso de CU es una necesidad para que puedan realizar la
planificación del proyecto. Esto quiere decir que no somos estrictos en
el uso de los mismos, el objetivo es que transmitan la funcionalidad
del sistema. Igualmente, se espera un uso razonable de la técnica de modelado con casos de uso.
Depende. En algunos casos, como podría ser "Google Maps", les vamos a
pedir que realmente lo utilicen y se integren. En otros casos, como por
ej. "Enviar SMS" les vamos a pedir que simulen los sistemas externos y
así poder ver que el sistema que ustedes deben construir trabaja con
estos. Entonces se podría probar, por ej., que si un sistema externo no
se comporta como se espera el sistema que ustedes construyen se
comporta adecuadamente. Ante la duda, pregunten.
No. Se
van a hacer distintos tests sobre la funcionalidad, algunos pueden ser
informados previamente y otros pueden surgir en el momento, todos deben
funcionar correctamente. La calidad del desarrollo, como por ej. que el
código este dividido en modulos (y que sean los que ustedes pusieron en
el informe), etc ... es un punto a evaluar. No se evalua solo la implementación de la funcionalidad.
Las
que ustedes crean convenientes. Es raro que sólo una dé una buena idea
de la arquitectura, probablemente necesiten usar distintos tipos de
vistas y en algunos casos expandir en otras vistas partes que se veían
como una unidad. También se asume que van a usar vistas combinadas.
Si buscan respuesta a otras preguntas (o estas no los satisfacen)
ponganse en contacto, y si lo creen conveniente, sugieranlas para esta
sección. Contacto |
Preguntas Frecuentes >