Volvemos en 2016

Hola,

Ante algunas consultas que hemos recibido en las últimas semanas, les confirmamos por este medio que volveremos a dictar este curso en el primer cuatrimestre de 2016. 

Lamentablemente, hace poco hemos sido informados que vamos a tener que continuar sólo con los dos ayudantes designados que tiene el curso debido a la falta de presupuesto para cubrir los otros tres cargos adicionales que habíamos solicitado en diciembre de 2014. Vale aclarar que el equipo del primer cuatrimestre estuvo integrado, además, por cuatro colaboradores, sin los cuales hubiera sido muy difícil dictar una materia con la calidad que los alumnos de esta casa de estudios se merecen.

A pesar de estas limitaciones, seguiremos esforzándonos para darles el mejor curso que sea posible. 

Nos vemos en marzo de 2016.

¡Hasta entonces!

Los docentes.

Resultados de la Encuesta - Primer cuatrimestre 2015

Hola!

Hacia finales del pasado cuatrimestre hicimos una encuesta entre los alumnos para conocer sus opiniones respecto de la materia. En términos generales, la evaluación fue muy positiva; una muy amplia mayoría (96,9%) calificó a nuestro curso como "Excelente" o "Muy bueno" (5 y 4 en la escala, respectivamente):

También evaluamos otros aspectos relacionados con la materia: contenidos propuestos, enfoque pedagógico empleado, calidad de las clases grabadas, trabajo práctico grupal, trabajos prácticos individuales, carga de trabajo, conocimiento y apoyo de los docentes, y calidad en la atención a los alumnos. He aquí los resultados promedio, siempre en la escala de 1 a 5:

Por supuesto que estos resultados nos halagan muchísimo y nos incentivan a seguir adelante. De hecho, ya estamos trabajando sobre algunos cambios que queremos hacer para el próximo cuatrimestre; algunos de ellos son los siguientes:

• Nuevos talleres de modelado de dominio, user stories, story boarding y casos de uso.
• Ajustes a la guía de lectura y ejercicios.
• Expansión del taller de diseño de interfaces de usuario.
• Nuevo taller de herramientas de calidad/productividad (por ejemplo: diagramas de causa efecto, diagramas de afinidad, 5 porqués, análisis Pareto, etc)
• Desdoblamiento del taller de análisis y diseño.
• Nuevas charlas especiales de Togaf y Scaled Agile Framework.
• Requerimientos no funcionales.
• Sistemas de tiempo real.
• Nuevo taller de diseño de datos.
• Edición de los vídeos.

Como verán, nos espera un verano con bastante trabajo.

Esto es todo por ahora. Nos resta agradecerles la participación en la encuesta (contestaron 32 alumnos) y los numerosos comentarios alentadores que nos hicieron llegar.

Los docentes.

Firma de libretas - Primer cuatrimestre 2015

Les recordamos que la firma de libretas será el próximo lunes 3/8 a las 18:30. 

No se olviden que para poder firmar deben estar inscriptos en la fecha de final (SIU Guaraní).

Con respecto a las notas finales, las estamos cerrando y en los próximos días cada ayudante se las dará a conocer.

Aprovechamos para comentarles que recibirán, también en los próximos días, una encuesta para que puedan evaluar la calidad del curso y el desempeño del equipo docente. Les agradeceremos muchísimo que le puedan dedicar unos minutos a completarla.

Nos vemos el 3/8.

El equipo docente

Visión: temas pendientes

Hola,

Nos había quedado pendiente darles más información acerca de un par de anexos que les pedimos que incluyan en el documento de Visión que deben entregar próximamente. Aquí van nuestras aclaraciones/comentarios:

Anexo: Casos de uso

No es necesario que especifiquen todos los casos de uso del sistema. Elijan alguno de los módulos o subsistemas (como, por ejemplo, el subsistema de carga de horas, el de gestión de incidentes, el de gestión de proyectos, etc; dependerá de como hayan particionado el sistema), construyan el diagrama de casos de uso correspondiente a esa porción, y especifiquen uno de los casos de uso a elección. 

Anexo: Estimación de esfuerzo

Realicen una estimación mediante user story points (ver pág.39 del cap.7) para cada una de las user stories. 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.

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. Consideren un 20 ó 30% adicional para las tareas no directamente relacionadas con las user stories (prueba de integración, gestión del proyecto, etc.)

Una última aclaración: habíamos dicho que la entrega TPG-4 era el jueves 1/6; la fecha correcta es el jueves 4/6.

Eso es todo por ahora. Cualquier duda la vemos el próximo jueves.

Saludos,

Los docentes.

Próximas entregas del TPG

Hola,

Les comentamos cuáles son las próximas fechas importantes con respecto al trabajo práctico grupal:

• Jueves 14/5: TPG-3
• Esta entrega es simplemente un ajuste de la anterior, con los cambios/agregados que surgieron del taller de requerimientos de ayer lunes y las aclaraciones que envió hoy "Fernando" por mail. 
• Con toda seguridad, les van a surgir dudas. La idea es que un representante de cada grupo pueda entrevistar a "Fernando" el próximo lunes 11/5. Vengan preparados.
• Es importante que:
• El modelo de dominio incluya solamente entidades que sean imporantes para el dominio de la aplicación. Cada entidad representa algo que el sistema deberá "recordar". No incluyan temas de implementación.
• El modelo de dominio y las historias de usuario deben ser consistentes. Si hay entidades que no son mencionadas en las US deberían cuestionarse: a) si la entidad tiene sentido; o bien b) si no les falta una US o alguna pieza de funcionalidad en algún lado.
• Obviamente, prototipo, modelo de dominio y US también deben guardar consistencia.
• Las US que les parezcan más complejas pueden (deben?) estar complementadas con algún texto aclaratorio. Recuerden que una US no es un requerimiento en el sentido tradicional sino que es más bien un "recordatorio" de que hay algo que charlar con el usuario. Como no siempre es posible tener una usuario full-time formando parte del equipo, es apropiado registrar algo de información adicional.
• Jueves 1/6: TPG-4
• Esta entrega consiste en el documento de Visión del sistema que queremos construir. Hay muchos formatos posibles (aquí pueden consultar el propuesto por RUP), pero lo que hay que tener siempre presente es que su propósito es describir, a alto nivel, el sistema a desarrollar. Ya que sus destinatarios son los interesados/usuarios, que no son especialistas técnicos, el estilo empleado debe ser muy claro y conciso.
• Recuerden que es un documento que ayuda a "vender" el proyecto. Tiene que estar bien escrito; debe cautivar a su audiencia; debe describir las necesidades (o problemas) a resolver, los beneficios y las funcionalidades (a alto nivel) del producto a desarrollar.
• Además de los contenidos típicos de un documento de Visión, les vamos a pedir que incluyan algunos anexos que usualmente no forman parte de él:
• Minutas de las reuniones mantenidas con los usuarios.
• Lista de las US y detalle de cada uno de las US.
• Lista de casos de uso y detalle de cada uno de ellos (vamos a hablar en clase de este tema)
• Modelo de dominio.
• Prototipo de interfaces de usuario.
• Estimación de esfuerzo (vamos a hablar en clase de este tema)
• Plan de entregas (vamos a hablar en clase de este tema)
• En cuanto al cuerpo principal del documento, el formato queda a elección de ustedes. A manera de ejemplo, las secciones podrían ser las siguientes (basadas en el template mencionado más arriba):
1. Introducción (similar al template)
2. Contexto (descripción de la situación/necesidad que ha disparado el proyecto que se va a encarar; similar a la sección del mismo número en el template)
3. Usuarios e interesados.
4. Visión general [del sistema] (ídem template; aquí quizás convenga incluir algún diagrama de contexto de muy alto nivel; también hay que detallar beneficios y comentar el plan general de desarrollo que luego se detalla en los anexos)
5. Prestaciones (ídem template; descripción de las principales funciones del producto en términos entendibles para el usuario. Organizar por subsistema/módulo) 
6. Otros requerimientos (ídem secciones 9/10 del template)
7. Anexos.
• Lunes 8/6: TPG-5
• Esta entrega consistirá en una presentación en PowerPoint o similar que resuma el documento de Visión y que emplearán en las presentaciones finales que tendrán lugar los días 8/6 y 15/6. Ya les daremos más información al respecto.

Esto es todo por ahora. Como de costumbre, estamos a disposición de ustedes si tienen dudas o consultas.

Saludos,

El equipo docente

Cronograma actualizado

Hemos publicado en Google Drive una nueva versión del cronograma de la materia:

https://drive.google.com/open?id=0B-OprvtGicVBb0lnNGtVcGh1TU0&authuser=0

Vídeos de los capítulos 6 y 7

Les anunciamos que ya están disponibles en Google Drive los siguientes vídeos:

• Cap.6: Requerimientos y diseño
• Cap.7: Requerimientos en contexto (en dos partes)

Saludos,

El equipo docente.

Lunes 4/5: Taller de requerimientos

Hola,

Como les comentamos el lunes pasado, para el 4/5 tendrán que organizar y coordinar un taller de requerimientos con la gente de PSA ("Fernando" y su equipo). El objetivo es consensuar una línea base de requerimientos para la aplicación de time-tracking que se les pidió oportunamente.

La idea es que nuestros amigos "Roberto" y "Ricardo" actúen esta vez de facilitadores y coordinen el taller (no se asusten, los ayudaremos). Ya que es poco práctico que todos los alumnos participen de la actividad, cada grupo deberá nombrar un representante. De esta manera, "Roberto", "Ricardo" y los representantes de cada grupo deberán organizar y planificar el taller (los demás serán espectadores).

Para que le puedan sacar bien el jugo a esta actividad, van a continuación algunas recomendaciones:

• Repasen la técnica (cap.3 y referencias bibliográficas).
• Decidan los temas a cubrir, preparen la agenda y definan qué hará cada uno de ustedes.
• Preparen el material que vayan a usar: pueden partir de la lista de requerimientos/US de algún grupo, o de alguno de los prototipos. Recuerden traer ese material en un pendrive para poder proyectarlo.
  
• Es muy importante que al comenzar se declaren explícitamente los objetivos de la reunión y la agenda. No estaría mal mostrar al principio un slide con esa información.
• Estén preparados para hacer preguntas. Pueden tener una lista.
• Por último, recuerden que el objetivo es alcanzar consenso con respecto a cuál es la funcionalidad que debe tener la aplicación a desarrollar. Estén preparados para manejar las posibles discusiones que puedan surgir y, eventualmente, negociar (atentos al taller de negociación del 27/4)

Con respecto a nuestros becarios ("Roberto" y "Ricardo"), no hay problema si sus intérpretes le quieren pasar la posta a un par de nuevos actores.

Cualquier duda, la vemos el lunes 27/4.

Saludos,

El equipo docente.

Modelos de dominio

Hola,

Se nos ocurrió aclarar un poco de qué hablamos cuándo hablamos de modelo de dominio.

En términos generales, un modelo de dominio es una representación visual de los tipos de objetos (abstractos) más importantes que se encuentran en un dominio de problema en particular. Como puntualiza Craig Larman (ver http://www.craiglarman.cn/book_applying/domain_model_1.pdf), podemos pensar en él como si fuera un glosario o un diccionario visual que describe las clases conceptuales significativas de un dominio determinado.

Así por ejemplo, si estudiamos cómo las compañías realizan sus operaciones de venta, nos encontaremos con clases conceptuales como Cliente, Producto, Pedido de Venta, Ítem de Pedido, Factura, Ítem de Factura, etc.; cada una de ellas, por supuesto, tendrá propiedades (CUIT, razón social, etc.)

Estas clases forman parte del vocabulario del problema que estamos analizando y suelen ser la base para identificar, luego, (parte de las) clases de diseño e implementación (y también tablas y archivos).

Un tipo particular de este tipo de modelo, planteado por Ivar Jacobson en [Jacobson-1999], es el modelo de negocio, que ya hemos presentado en el capítulo 4 (ver el artículo  http://www.ibm.com/developerworks/rational/library/360.html)

¿Cuál es la diferencia entre ellos? En pocas palabras, podríamos decir que un modelo de dominio es un modelo general y simplificado de las "cosas" (las clases conceptuales) que integran un ambiente determinado, mientras que un modelo de negocio es un modelo interno de un negocio en particular que describe procesos y objetos (de negocio).

Lo que complica un poco el panorama es que muchas veces ambos términos se utilizan en forma intercambiable. No es un gran problema, porque clases conceptuales y entidades (u objetos de negocio) son prácticamente iguales: describen cosas o eventos importantes del área de estudio.   

Como si fuera poco, el Unified Process (y sus variantes) plantea el desarrollo de un modelo de análisis (http://sce.uhcl.edu/helm/RationalUnifiedProcess/) con el propósito de describir la realización de los casos de uso como colaboraciones entre  clases de análisis. Estas clases, como ya hemos explicado en el capítulo 4, pueden ser de interfaz, de control o las llamadas entidades. 

¿Qué son las clases tipo entidad? Son las "cosas" que el sistema necesita manipular para poder cumplir con el comportamiento esperado. Usualmente, se derivan de las clases de dominio o de negocio (si se construyeron los respectivos modelos) o se identifican empleando una técnica similar a la empleada para encontrar a las primeras. La diferencia fundamental entre estas clases y las de los mencionados modelos es que éstas, además de propiedades (atributos) tienen responsabilidades (operaciones).

Hay otro término (un poco más antiguo) que también se emplea como sinónimo de modelo de dominio: el modelo de datos.

Como verán próximamente en el capítulo 6, a lo largo de los años se han identificado tres tipos o niveles de modelado de  datos: el conceptual, que apunta a describir las entidades del dominio; el lógico, que describe el diseño de la base de datos que responde al modelo anterior (tablas, columnas, claves); y el físico, que detalla aspectos de implementación de la base de datos.  Claramente, el primero de los niveles es equivalente al modelo de dominio o al de objetos de negocio. 

¿Cuál de todos estos modelos construir? Bueno, dependerá de la situación. 

Un ejemplo minimalista es el que nos propone Scott Ambler en su artículo Agile/Evolutionary Data Modeling: From Domain Modeling to Physical Modeling (ver http://agiledata.org/essays/agileDataModeling.html) Allí plantea un caso en donde un sistema a desarrollar se describe mediante un conjunto de user stories y un modelo conceptual (aunque no nos dice cuáles son sus atributos). Luego se adentra en el diseño y describe cómo se obtiene la base de datos a partir del modelo conceptual. 

Una alternativa para situaciones más complejas consiste en construir un modelo de dominio, un modelo de casos de uso y un modelo de análisis para los casos de uso más significativos. Las clases de análisis tipo entidad se derivarán de las clases conceptuales del modelo de dominio.

Quedará para nosotros decidir qué enfoque emplear.

Saludos,

El equipo de docentes

Why Software Is Eating The World, toma 2

Hola,

Va aquí el artículo completo. Parece que en algunas situaciones, el sitio de WSJ bloquea el acceso.

Saludos

Why Software Is Eating The World

Hola,

Les pasamos el link a un artículo muy interesante aparecido hace ya más de tres años en el Wall Street Journal. En él, su autor (Marc Andreessen, creador de Netscape) describe cómo el software está tomando el control de porciones cada vez más grandes de la economía.

Esperamos que les guste.

Saludos,

Los docentes

Clase del jueves 16/04 y próximas entregas

Hola a tod@s,

Actualizamos las próximas entregas y temas:

Jueves 16/04  (18.30hs puntual, Laboratorio B del 4to piso)

• Primera entrega del TP Grupal. Por favor, envíenlas lo antes posible ya que vamos a trabajar en clase sobre este tema.
• Vamos a repasar y darles feedback de las Actividades 3.1, 3.2, 3.3 y 4.1, 4.2, 4.3
• También daremos feedback sobre la entrega de la lista de Historias de Usuario (US) y Casos de Uso (CU)

Lunes 20/4 (18:30 hs puntual, sala multimedia)

• Entrega de  Actividades 4.4 y 4.5. Resumen Video II Capítulo 4.
• Entrega Listado de US y CU sobre el relevamiento del Sistema de Inscripciones. Una US y un CU deben estar especificados en detalle.

¡Los esperamos!

Actividades para el lunes 15/3

Hola a todos,

Les recordamos las actividades para el próximo lunes 15/3.

Lo primero que deberían hacer es ver el video del Capítulo 1. Consideren que tiene una duración de alrededor de 50 minutos. Es llevadero y clave, ya que da un panorama general del desarrollo de software. La recomendación es que a medida que lo vean, vayan tomando notas para poder realizar el resumen.

Observamos que las actividades de este capítulo son extensas, así que decidimos dividirlas en 2 fechas de entrega, una el próximo lunes y otra en la semana del 22/3. 

Para el lunes 15/3 habría que entregar las actividades 1.1, 1.2 y 1.3. Aquí van algunos lineamientos al respecto:

Actividad 1.1

– Según [Bourque]

• ¿Cuáles son las áreas de conocimiento de la ingeniería de software? ¿Qué propósito tiene cada una de ellas?

Aquí la premisa es leer del SWEBOK solamente lo que necesiten para responder la pregunta. Hay un capítulo por cada una de las áreas de conocimiento (Knowledge Areas "KA"), así que deben leer los primeros párrafos de cada uno de ellos y así describir el propósito de cada una de ellas (son 15).

Actividad 1.2

– ¿Cuál es la tesis central de [Brooks]? ¿Cómo la demuestra?

Este paper es muy famoso y ya un clásico de la ingeniería de software. Nuestra recomendación es que lo lean completo ya que seguramente con el tiempo lo vuelvan a leer y consultar. Yendo al ejercicio, la clave comienza en la página 3, en donde se desarrollan las propiedades inherentes de los sistemas de software: la complejidad, la conformidad, la mutabilidad y la invisibilidad. Deben explicar cada uno de estos aspectos. También se habla de ello en el vídeo del capítulo 1.

Actividad 1.3

– ¿Cuáles son, según [Royce], los riesgos de desarrollar software siguiendo el ciclo de vida en cascada? ¿Qué propone para resolverlos?

Al igual que la anterior actividad, parte de esto se desarrolla en el vídeo del capítulo 1. Simple: qué riesgos hay, cómo se pueden resolver según el autor.

Las actividades 1.4, 1.5 y 1.6 se entregarán en la semana del 22/3 junto a la actividad 2.1.

Igualmente les recomendamos, si les da el tiempo, leer los papers de todas las actividades ya que la clase se basa en todos los conceptos allí mencionados.

Respecto a las entregas, las vamos a organizara para que sean TODAS DIGITALES. Deben enviarlas a la cuenta aninfo.fiuba@gmail.com como archivos adjuntos en el formato que prefieran. En el asunto del correo electrónico indiquen por favor número de padrón, ejemplo [81378], y la actividad, ejemplos [Resumen Capitulo 1], [Actividad 1.*], [Actividad 2.1, Actividad 2.2], [TP Grupal, Grupo 02]

Gracias!

¡Comenzamos el primer cuatrimestre!

¡Hola!

Bienvenidos a nuestro blog.

Como probablemente ya lo sepan, este nuevo curso de Análisis de la Información comienza este primer cuatrimestre de 2015. La idea es repetirlo una vez al año, ya que el equipo de docentes es el mismo que da la materia electiva Evaluación de Proyectos y Manejo de Riesgos, que de aquí en más se podrá cursar solamente en los segundos cuatrimestres.

En este sitio encontrarán el link a la carpeta de Google Drive en donde están las presentaciones y vídeos de las clases, la bibliografía recomendada, guías de lectura y ejercicios, etc. También hemos incluido algunos links interesantes: tutoriales, grabaciones de conferencias, etc.

Esperamos que disfruten de este cuatrimestre, que les guste la propuesta que tenemos y que nos ayuden a mejorar la materia. No se olviden, esta es la primera versión.

Nos encontramos el lunes 9/3 en la Sala Multimedia que está en el tercer piso de Paseo Colón (al fondo de la biblioteca).

¡Nos vemos!
Los docentes.