Grupo 2
Tutor Nicolás Passerini
Fernando Frezzotti moc.liamg|nadtsref#moc.liamg|nadtsref
Ariel Bullor ra.moc.oohay|11ylugle#ra.moc.oohay|11ylugle
Matías Freyre moc.liamg|eryerfm#moc.liamg|eryerfm
Matías Sulik moc.liamg|kilus.saitam#moc.liamg|kilus.saitam
Javier Capanegra ra.moc.oohay|argenapacjj#ra.moc.oohay|argenapacjj
Leandro Arakaki

Paper

Tema AOP
Entrega Entregó en fecha (S/N) Archivo Adjuntado Comentario de la Entrega
Fase 1 S S Se pidió mejorar un poco la redacción. Hablamos de extender la parte de ventajas y desventajas del AOP, separando en distintos puntos para esquematizar mejor las distintas ideas, relacionarlo con los atributos de calidad y luego agregar referencias de esa parte al ejemplo posterior.
Fase 2 S S Pongo una idea general después charlamos los detalles personalmente. 1) La introducción y origen de AOP estarían bien, sólo faltaría mejorar unos detalles de redacción. 2) En la parte de conceptos básicos habría que refinar todavía bastante la explicación, tal vez para esto conviene esperar un poco hasta que ustedes estén más duchos con AOP. 3) La parte de impacto positivo tiene varias buenas ideas, pero creo que nos faltaría relacionarlo más con los atributos de calidad. Esto podría no ser indispensable, lo digo un poco pensando en el foco original que habíamos planteado y otro poco porque me parece que podría ser un foco de análisis del que no hay mucha literatura hoy en día. 4) En el primer párrafo de ese punto, habría que desarrollar un poco más la idea, no queda claro por qué es imposible modularizar una aplicación sin utilizar aspectos. 5) El últimpo párrafo de ese punto, es bastante difuso y habría que darle otra vuelta. 6) El punto sobre las desventajas está más verde así que lo único que voy a decir es que se contradice un poco con lo anterior, porque primero hablan de los aspectos mejorando la modificabilidad y acá hablan de lo contrario. Tal vez las dos ideas están bien y es sólo una cuestión de redacción. 7) En este punto de las desventajas es donde más podrían trabajar sobre requerimientos no funcionales. 8) La conclusión es lo que menos me gusta de todo porque no dice mucho más que: "depende"… deberían detallarlo bastante más, por ejemplo: en qué casos es imposible usar aspectos, en qué otros casos podría estar bueno o mejor todavía si me mando a usarlos qué cosas tengo que hacer para no sufrir los problemas de los que se habla en las desventajas.
Fase 3
Entrega Final

TP Cuatrimestral

Descripción de la Aplicación <descripcion
relativamente breve de la app>
Entrega Entregó en Fecha (S/N) Archivo Adjuntado Comentario de la Entrega
Entrega 0 - "Selección" S S Entregaron la propuesta que están usando en proyecto. El sistema no requiere de una gran arquitectura así que acordamos manejar la complejidad incorporando requerimientos no funcionales interesantes.
Entrega 1 - "Visión y Atr. De Calidad" S S Presentaron los escenarios, en varios hubo que hacer correcciones para hacerlos más específicos. También se agregaron algunos escenarios un poco más complejos, por ejemplo cuestiones de performance. En particular se solicitó la incorporación de un requerimiento de seguridad, a saber: asegurar la seguridad en forma transversal por arquitectura sin depender de la implementación de cada caso de uso particular.
Entrega 2 - "Estrategias y Creación" S S 1) Quedan aún algunos escenarios por mejorar, en particular habría que especificar mejor el primero de los escenarios de performance, que habla de 8 usuarios pero no especifica la calidad de servicio que deberían recibir. 2) Esto también es algo que ya habíamos hablado, ya que tenemos requisitos de seguridad más o menos importantes, debería buscarse una forma de integración de seguridad con el resto de los módulos que no dependa de la programación de cada uno de los módulos para garantizar seguridad. Esto no queda claro que se cumpla con el estilo call & return (o deberían explicarlo un poco más) y también estaría bueno agregar esto como un escenario.3) Por último, en la parte de la selección del framework de streaming estaría bueno agregar algunas cuestiones más técnicas, es decir, verificar la adecuación del frameworw que están proponiendo a los requerimientos no funcionales que se definieron. También estaría bueno agregar algún framework más, porque así como está parece haber una sola opción (el otro es un framework muy inmaduro).
Entrega 3 - "Entrega Parcial 1" S S Con respecto a la propuesta de implementación, faltaría especificar lo que hablamos en clase sobre hacer un test de carga. Si no vamos a implementar nada de archivado, clustering o logging, entonces me gustaría algo más concreto en el SAD sobre el diseño de estas características (tácticas y otras cuestiones que se deban tener en cuenta). El resto de la parte de tácticas está bien, el estilo de arquitectura y los escenarios podrían mejorarse pero en líneas generales estaría bien. Lo que sí habría que mejorar todavía un poco es la selección del framework, cuando digo "la relación con las cuestiones funcionales" quiero decir asegurarse de que puedo cumplir con los escenarios, ese análisis faltaría hacer (lo que dicen de modificabilidad está bueno, performance en realidad lo vamos a testear, faltarían agregar los demás atributos).
Entrega 4 - "Entrega Parcial 2"
Entrega 5 - "Entrega Final"
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.