Presentación final

Hola,

Les debíamos algo más de información respecto a la organización de la presentación final del TPG. Ya les habíamos adelantado que iba a consistir en un vídeo de no más de 10 minutos y una tanda de preguntas "en vivo".

Antes de entrar en detalles, un tema importante: decidimos reprogramar las presentaciones para el lunes 13 y el jueves 16, así tienen un poco más de tiempo para prepararlas. La fecha de entrega del documento de Visión sigue de acuerdo a lo previsto en el cronograma: 30/5.


En cuanto a contenidos, los vídeos de cada grupo deben estar organizados en tres partes:

a) Prototipo de las interfaces de usuario (organizado por epopeyas/historias de usuario)

b) Tema a desarrollar

c) Lecciones aprendidas (qué aprendieron del TPG; cosas que harían nuevamente y cosas que no volverían a hacer)


En cuanto al punto b), la idea es que expliquen uno de los conceptos que vimos en la materia y que muestren cómo lo resolvieron en el TPG. Los temas los vamos a sortear la semana que viene, pero para que tengan una idea estos podrían ser los siguientes: historias de usuario, modelado del dominio, criterios de aceptación, casos de uso, etc.


Eso es todo por ahora. Nos vemos.

Equipo docente

Entrega TPG 4

Increíblemente, ya estamos a mitad de camino. Hemos comenzado a transitar las últimas ocho semanas de un cuatrimestre que está siendo muy intenso para todos y, al menos para nosotros, también muy interesante. Prácticamente hemos cubierto el 80% de los temas previstos en el plan de la materia; sólo nos restan dos unidades más y las muy esperadas charlas especiales (anteayer nos confirmaron una charla más acerca de SAFe para el 23/5)

Como les comentábamos el lunes pasado, tienen por delante las últimas dos entregas del trabajo práctico grupal. Vamos a concentrarnos por ahora en la cuarta entrega, que consiste en el documento de Visión del sistema de gestión de proyectos y servicios de PSA.

Hay muchas variantes en cuanto a contenido y formato, pero todas apuntan al mismo objetivo: describir el alcance del software a desarrollar desde el punto de vista de todos los interesados (va aquí una definición formal tomada de UPEDU).

Si bien pueden buscar en la web distintas alternativas (aquí hay una), les sugerimos las siguientes secciones para el cuerpo principal:

• Introducción (propósito del documento, audiencia, resumen, etc.)
• Antecedentes (descripción de la situación/necesidad que ha disparado el proyecto que se va a encarar)
• Usuarios e interesados
• Descripción general [del sistema] (propósito del sistema a desarrollar, funcionalidades, etc. Quizás convenga incluir algún diagrama de contexto de muy alto nivel; también hay que detallar beneficios)
• Prestaciones (descripción de las principales funciones del producto en términos entendibles para el usuario. Organizar por subsistema/módulo) 
• Otros requerimientos (requerimientos no funcionales)
• Plan de desarrollo (plan de entregas y estimación de esfuerzo; más información al respecto en las próximas clases)
• Anexos

Con respecto a los anexos, les pedimos que obligatoriamente incluyan los siguientes ítems:

Anexo: Historias de usuario
Incluyan las historias de usuario que han desarrollado a lo largo del cuatrimestre. No olviden poner toda otra información que consideren relevante: prioridad, notas aclaratorias,  criterios de aceptación, etc.

Anexo: Modelo de casos de uso
No es necesario que especifiquen todos los casos de uso del sistema. Construyan el diagrama de casos de uso y elijan al menos tres de ellos y especifíquenlos. Incluyan para esos los diagramas de secuencia del sistema y sus correspondientes diagramas de operaciones.

Anexo: Modelo de dominio
Diagrama y cualquier otra explicación complementaria que crean conveniente. Incluyan propiedades.

Anexo: Prototipo de interfaces de usuario
Incluyan las interfaces prototipadas. Organícenlas por historias de usuario. Se podría combinar este anexo con el primero.

Anexo: Estimación de esfuerzo
Hay que realizar una estimación de esfuerzo mediante user story points (ver pág.39 del cap.7) para cada una de las historias de usuario. Pueden usar la técnica planning poker (http://en.wikipedia.org/wiki/Planning_poker). Luego, intenten derivar esfuerzo (horas-persona) para el desarrollo y prueba de cada user story a partir de una equivalencia entre user story points y horas-persona.  Ya hablaremos al respecto en clase.

Anexo: Plan de entregas
Decidan cómo agrupar el desarrollo y entrega del producto en varias versiones sucesivas. Decidan qué funcionalidad (user stories) entregar en cada versión. Luego, estimen el esfuerzo y la duración de desarrollar cada versión (tiene que cerrar con el punto anterior). Consideren un 20 ó 30% adicional para las tareas no directamente relacionadas con las user stories (prueba de integración, gestión del proyecto, etc.)

Anexo: Minutas de reunión
Incluyan todas las minutas que tengan de las reuniones de relevamiento.

Anexo: Glosario
Definan todos los términos que les parezcan relevantes para comprender el resto del documento y el dominio del problema en general.

Esto es todo por ahora. Como podrán ver, una buena parte de la información contenida en el documento ya la han desarrollado o, al menos, la tienen en una versión preliminar. Si tienen dudas, lo conversamos en clase.

Próximamente, les contaremos qué esperamos de la quinta y última entrega.