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!