Orientando Sistemas de Programas a Objetos: Un segundo experimento docente

Tabla de contenido

2. Las nuevas condiciones del segundo experimento

2.1 Adopción de un nuevo libro de texto.
2.2 Adopción de la notación UML y de la metodología RPM.
2.3 Integración de Sistemas de Programas con su Taller.
2.4 Mayor cobertura de la Programación Orientada por Objetos.
2.5 Mayor cobertura de patrones y principios de diseño.
2.6 Atención a la evaluación de los diseños propuestos.
2.7 Explicitación de elementos de Control de Proyectos.
2.8 Cobertura débil de pruebas (testing).

3.1 Programas y calendarios.
3.2 La evaluación del curso.
3.3 Recursos.
3.4 El proyecto de desarrollo.
 

4.1 La fase de entrenamiento.
4.2 La fase de elicitación de requerimientos.
4.3 La fase del modelado de uso.
4.4 La fase del modelado estructural.
4.5 La fase de diseño de la interfaz del sistema.
4.6 La fase del modelado del comportamiento.
4.7  La fase del modelado de la interacción.
4.8 La fase de implementación.
4.9 La entrega del sistema.
4.10 Observaciones sobre la dinámica de grupos.
 

5.1 Logros

5.1.1 ¿Qué fue lo que más le gustó a los estudiantes?
5.1.2 ¿Qué fue lo que le pareció más útil a los estudiantes?

5.2 Contratiempos y fallas

5.2.1 ¿Qué fue lo que menos le gustó a los estudiantes?
5.2.2 ¿Qué fue lo que le pareció menos útil?
5.2.3 En un espectro entre motivante (por lo novedoso y útil) y desmotivante (por la densidad y quizás, superficialidad de cobertura de los tópicos) , ¿dónde ubica esta asignatura?
5.2.4  ¿Qué debe mejorarse? ¿Eliminarse? ¿Expandirse? ¿Cambiar de orden?
5.2.5 ¿Qué recomendaciones le haría al profesor para que mejore el curso?
5.2.6 Otras observaciones.

Agradecimientos

1. Introducción

Los cursos se fundamentaron sobre la metodología OMT de desarrollo de software orientado a objetos (Object Modeling Technique) enriquecida con el modelo de uso de Ivar Jacobson y patrones (patterns). En el Taller los estudiantes se agruparon en equipos de entre 10 y 20 personas y ejercitaron OMT  en el contexto del desarrollo de un proyecto programado en Java.

Los detalles de este primer experimento docente se encuentran en Orientando Sistemas de Programas a Objetos: Un Experimento Docente. En base a las recomendaciones reportadas, el profesor Alejandro Teruel llevó a cabo en el trimestre Abril-Julio de 1999 una nueva y aún experimental versión del curso, con el apoyo del preparador Pedro García.

Las características principales del nuevo curso fueron:

1. Se conservó el objetivo del primer experimento en cuanto a basar el curso en la tecnología orientada por objetos.

 
2. Se adoptó como libro de texto, el libro de C. Larman Applying UML and Patterns (Prentice-Hall, 1998).

 
3. Se adoptó la notación UML y la metodología incremental para la captura, análisis y diseño orientados a objetos  descrita en el texto antes citado. Esta metodología incluye:

 
1. La captura informal de requerimientos y su estructuración en:
• Breve descripción del sistema (system overview);
• Identificación de clientes;
• Metas;
• Funciones del sistema;
• Atributos del sistema;
• Suposiciones;
• Riesgos;
• Dependencias.

 
2. El modelo de uso;

 
3. El modelo estructural (simplificado);

 
4. El modelo de comportamiento del sistema (diagramas de secuencias de eventos del sistema y los contratos de eventos del sistema);

 
5. El modelo de interacción (diagramas de colaboración entre clases).

 
1. Se integraron conceptualmente las asignaturas Sistemas de Programas con el Taller de Sistemas de Programas a pesar que administrativamente las dos asignaturas siguieron separadas y que un porcentaje significativo de estudiantes cursaron una sola de las asignaturas.Entre los mecanismos de integración resaltaron el uso de un mismo proyecto de desarrollo para las dos asignaturas, equipos de desarrollo formado por estudiantes inscritos en ambas asignaturas y en una sola de ellas y un elevado porcentaje de evaluación conjunta para ambas asignaturas.

 
2. Se dedicó más tiempo a la programación orientada por objetos.

 
3. Se incrementó la cobertura de patrones y se introdujeron algunos principios de diseño recomendados por el texto adoptado.

 
4. Se prestó especial atención a la evaluación de los diseños propuestos.

 
5. Se explicitaron algunos elementos de control de proyectos que se han venido trabajando en el Taller de Sistemas de Programas tales como:
• Nociones básicas de trabajo en equipo, roles (miembro, coordinador de equipo, editor técnico, webmaster, coordinador de reuniones),
• Planificación,
• Control,
• Seguimiento,
• Coordinación de reuniones,
• Manejo de agenda,
• Distribución explícita de tareas,
• Identificación y manejo de riesgos,
• Confidencialidad,
• Relaciones con el cliente,
• Estimación de tiempo,
• Caminos críticos, y
• Análisis post-mortem.
6. Se debilitó la cobertura del tópico de pruebas (testing).

En balance, los ajustes realizados fueron positivos y alentadores mas no definitivos. Opino que el curso, al igual que su predecesor inmediato, resultó altamente motivante, por cuanto los estudiantes se entusiasmaron al sentirse ubicados en una tecnología de punta --o al menos percibida como tal-- en un ambiente integrador de mucha más colaboración e intercambio entre pares  y que perciben  como muy cercano a la realidad de su futura vida profesional. El curso integra los tópicos cubiertos mejor que su predecesor y los cubre a un nivel más cónsono con el nivel alcanzado por el estudiante.

En este reporte presentaré:

1. Las nuevas condiciones del segundo experimento;
2. La descripción del curso;
3. Los resultados alcanzados;
4. Las recomendaciones que se derivan de la experiencia.

2. Las nuevas condiciones del segundo experimento

2.1 Adopción de un nuevo libro de texto.

• No cubre el modelo de uso, un modelo que, a juicio de varios autores, resulta clave el el desarrollo de software orientado a objetos;
• Cubre demasiado superficialmente la problemática de la captura de requerimientos, la cual reduce al problema de hallar un enunciado del problema a resolver;
• Los diagramas propuestos para el modelo estructural resultan demasiado ricos conceptualmente para un estudiante que aún no ha visto los rudimentos de un modelo de datos E-R. En particular distinguir el concepto de generalización (distinguiéndolo de herencia) y el concepto de agregación son sutilezas que lucen prematuras para el nivel del curso.
• Los mecanismos propuestos para el modelo dinámico (autómatas anidados concurrentes)  son escesivamente sofisticados para un grupo de estudiantes que aún no han visto autómatas finitos.
• El modelo funcional es de importancia secundaria en comparación con otros modelos de comportamiento introducidos más recientemente como el modelo de colaboración entre objetos. En particular considero el uso que hace este texto de un modelo funcional basado en diagramas de flujo de datos (DFDs) es inadecuado.
En un libro más reciente de los mismos M. Blaha y W. Premerlani, titulado Object-Oriented Modeling and Design for Database Applications (Prentice-Hall, 1998), los autores abandonan DFDs y recomiendan usar varias notaciones entre las que destacan pseudo-código extendido con con una notación de navegación por objetos (ONN). Esta es una interesante opción que no he explorado aún
• La notación OMT del texto ha sido sustituida por la notación UML  por la mayoría de los autores en el área, incluyendo los autores del texto.
• El texto no cubre el tópico de patrones y su uso dentro del diseño orientado por objetos.
• La cobertura del tópico de arquitectura de software es demasiado avanzado para el nivel de los estudiantes.

El libro de C. Larman Applying UML and Patterns corrige  estos defectos y tiene un nivel  más cónsono con el nivel de los estudiantes. Su adopción como libro de texto puede considerarse exitoso en lo que se refiere a la cobertura de los tópicos de análisis y diseño de software orientado por objetos.
 

2.2 Adopción de la notación UML y de la metodología RPM

Es mucho más significativo el cambio de la metodología OMT (Object Modeling Technique) a la metodología RPM (Recommended Process and Models) presentada en el libro texto de C. Larman. El propio Larman aclara que:

This is not a new method, but a description of fairly common, recommmended process and models applied by practitioners and presented in other object-oriented analysis and design methods under varying names and with slight shifts in emphasis...

...best practices, basic activities and models in a development process for object-oriented systems based on an iterative and incremental, use case driven approach.

Larman expone una metodología incremental e iterativa que comienza por la captura de requerimientos. Esta fase se estructura en los siguientes renglones:

• Breve descripción del sistema (system overview);
• Identificación de clientes;
• Metas;
• Funciones del sistema;
• Atributos del sistema;
• Suposiciones;
• Riesgos;
• Dependencias.

Como el grueso de las metodologías orientadas a objetos, el núcleo de la metodología RPM consta de una serie de modelos que se proponen y evalúan. La multiplicidad de tipos de modelos es clave para analizar y diseñar el sistema final enfatizando diferentes criterios, así como es clave la consistencia y facilidad de interrelación entre los modelos. La analogía con los distintos tipos de planos y modelos de una obra civil (planos de fachada, planta, perfil y servicios)  o artefacto mecánico (modelo mecánico, termodinámico y eléctrico) es inmediato --un artefacto complejo no puede diseñarse bajo una sola óptica ni puede capturarse en un solo modelo.

El primer modelo que se construye en RPM es el modelo de uso, basado en los casos de uso propuestos por Ivar Jacobson. La identificación de los actores que interactúan con el sistema y la descripción informal pero estructurada de esa interacción son ejercicios importantes para el estudiante que no está acostumbrado a manejar con precisión la narrativa informal ni a analizarla.

El segundo modelo es el modelo conceptural (o estructural). Este modelo se basa en el diagrama estructural de las clases del dominio de la aplicación, donde se identifican y grafican las clases y las relaciones de herencia y asociación entre clases. Larman maneja nociones muy simples, casi operacionales, de relaciones entre clases, lo que es una ventaja importante, si se recuerda que los estudiantes del curso aún no han visto modelos de datos en general y el modelo E-R en particular en comparación con los diagramas manejados por Rumbaugh que incluyen relaciones adicionales de generalización y agregación.

Un paso simple pero muy necesario es la identificación de los eventos del sistema y sus diagramas de secuencias. En RPM este paso constituye una abstracción gráfica de los casos de uso, complementados por los contratos. Un contrato es una especificación de las responsabilidades asociadas al sistema para cada uno de los eventos exteriores que inciden sobre él. Siguiendo a Wirfs-Brocks, Larman exige que se expliciten las precondiciones, postcondiciones, excepciones  y efectos secundarios asociados a los eventos del sistema, así como exige enlazar los requerimientos a la reacción del sistema ante los eventos exteriores (requirements traceability).

Una vez explicitados los contratos, RPM sugiere que se elaboren los diagramas de colaboración entre los objetos que conforman el sistema de forma de cumplir con esos contratos respetando el modelo estructural de clases. Esta fase del diseño es sumamente rica y de manera muy natural Larman incorpora nociones de arquitectura de software, patrones orientados por objetos y principios de diseño.

En mi opinión la metodología es convincente, coherente y fluida. El texto incluye algunos tópicos "avanzados", entre los que incluye el modelo dinámico. Considero que este modelo escapa al alcance del curso.

Como metodología de desarrollo, RPM adolece de algunos defectos evidentes:

1. Como metodología de análisis y diseño que es, ignora la problemática de validación (testing);
2. No cubre adecuadamente la evaluación de opciones de diseño;
3. No cubre aspectos básicos de control de proyectos.

He revisado parcialmente la propuesta metodológica de los proponentes de UML (I. Jacobson, G. Booch y J. Rumbaugh: The Unified Software Development Process. Addison-Wesley, 1999) y  mi primera impresión es que es inferior a la propuesta de C. Larman. Parte de la razón puede atribuirse a la pomposa  y repetitiva redacción de este libro de Jacobson, Booch y Rumbaugh, parte a la ausencia de ejemplos concretos y el resto a una cobertura francamente superficial de tópicos claves. Adicionalmente el libro no parece del nivel adecuado para los estudiantes de mi curso. Del lado positivo,  hay algunos puntos innovadores que vale la pena rescatar de los escombros del libro: la identificación del actor iniciador de un caso de uso, la insistencia en incorporar la gestión del riesgo, el diagrama arquitectural del sistema y el diagrama de emplazamiento (deployment diagram).  En todo caso, la opinión definitiva queda pendiente hasta que culmine la revisión del libro.

2.3 Integración de Sistemas de Programas con su Taller

La fusión consistió en tratar ambas asignaturas como una sola, realizando sesiones de práctica, laboratorio o teoría según los requerimientos dictados por el proceso mismo de llevar a cabo  un mismo proyecto de desarrollo de software en el que intervenían tanto los estudiantes inscritos en una de las asignaturas como aquellos inscritos en ambas. Se prestó particular atención a que los equipos de desarrollo, formados por 6 a 10 personas, tuvieran un núcleo de estudiantes que cursaran ambas asignaturas y que las responsibilidades de los miembros fueran cónsonas con su inscripción. Así los estudiantes que sólo cursaron el Taller de Sistemas de Programas tuvieron responsabilidades de programación que no fueron asignadas a los estudiantes que sólo cursaban Sistemas de Programas.

Es conveniente explicitar la distribución de estudiantes en las asignaturas:

• 9 estudiantes inscribieron  las dos asignaturas;
• 4 estudiantes inscribieron sólo Sistemas de Programas;
• 4 estudiantes inscribieron sólo Taller de Sistemas de Programas.

Nótese que el número total de estudiantes es bajo respecto a los estándares de la carrera. De 80 a 100 estudiantes toman las asignaturas anualmente, pero el grueso de los estudiantes las toma en el período anterior al que realizó este experimento.

Debo admitir que la logística de las clases fue complicada y el naufragio general fue evitado gracias a un extenso horario de consultas y a la dinámica misma de los equipos de desarrollo que, en general, supieron convertirse en equipos de estudio y de desarrollo. Los estudiantes más golpeados por este esquema fueron aquellos que sólo cursaron Sistemas de Programas. Sin embargo, la experiencia mostró que el esquema es viable y sigo convencido que es necesario para enfatizar el trabajo en equipo como parte importante de la formación de nuestros Ingenieros de la Computación. Evidentemente la fusión real de las dos asignaturas previstas en el cambio de pensum, solucionará muchos de los problemas que se presentaron, a condición que la nueva asignatura se estructure en secciones integrales de teoría y laboratorio con no más de veinte estudiantes por sección.
 

2.4 Mayor cobertura de la Programación Orientada por Objetos

Aprender los elementos de un lenguaje orientado por objetos como Java es una tarea relativamente fácil ya que el lenguaje per se es pequeño. El problema, como bien lo saben los proponentes de Smalltalk, surge cuando el programador debe enfrentarse con las librerías del lenguaje y adoptar el nuevo estilo de programación. Se decía que los elementos de Smalltalk podían aprenderse en una hora pero que aprender a programar en el estilo Smalltalk aprovechando las clases de sus librerías básicas se llevaba entre tres y seis meses.

Programar una interfaz sencilla en Java implica aprovechar las clases de las librerías AWT y Swing, , las cuales se basan en un modelo de programación reactivo a eventos, elaborado para permitir y estimular una clara separación entre la capa de presentación y la del dominio de la aplicación. Ni las clases ni el estilo ni la filosofía de diseño de la librería AWT o Swing es conocida por el estudiante o de facil dominio.

Hay definitivamente un problema tipo huevo y gallina --¿qué debe enseñarse primero, las clases para construir una interfaz o la filosofía de diseño de esas clases? Debo admitir que este problema sigue sin resolver y que la programación de las interfaces del proyecto se realizaron gracias a que algunos de los estudiantes ya traían conocimientos de Java (33% de los estudiantes que cursaron el Taller) o habían construido una interfaz gráfica, típicamente en Visual Basic, Pascal o Java (66% de los estudiantes que cursaron el Taller) , pero se realizaron irrespetando el grueso de  la filosofía de diseño de estas clases.
 
 

2.5 Mayor cobertura de patrones y principios de diseño

• Experticia;
• Acoplamiento;
• Cohesión.

• Model-view-controller (MVC);
• Publish-subscribe;
• Iterador;
• Estrategia;
• Apoderado (proxy);
• Decorador;
• Fábrica abstracta y
• Compuesto.

Conviene advertir que el material del texto adoptado debe complementarse con el texto clásico en el área:

• E. Gamma, R. Helm, R. Johnson y J. Vlissides: Design Patterns. (Addison-Wesley, 1995).

2.6 Atención a la evaluación de los diseños propuestos

Esta atención está poco apoyado por parte del texto adoptado y diría que constituye la parte más dificil, característica, importante, artesanal y trabajosa del curso. Estoy convencido que el diseño se aprende analizando diseños sobresalientes, creando diseños propios y sometiéndolos a la crítica constructiva de un diseñador experto.

Para ello el aprendiz de diseño tiene que aprender a aceptar y aprovechar críticas y el maestro diseñador tiene que aprender a hacer críticas constructivas, explícitas y comprensibles. Es dificil, máxime cuando no hay una tradición crítica explícita en nuestra disciplina, salvo en lo que se refiere al criterio de eficiencia y, en menor y más reciente grado, facilidad de uso.
 

2.7 Explicitación de elementos de Control de Proyectos

Introducción al trabajo en equipo, el control de proyectos y otros aspectos de la dimensión no técnica del desarrollo de software.

• Nociones básicas de trabajo en equipo,
• Roles de un equipo de desarrollo(miembro, líder, editor técnico, webmaster, coordinador de reuniones),
• Planificación,
• Control,
• Seguimiento,
• Coordinación de reuniones,
• Manejo de agenda,
• Distribución explícita de tareas,
• Identificación y manejo de riesgos,
• Confidencialidad,
• Relaciones con el cliente,
• Estimación de tiempo,
• Caminos críticos, y
• Análisis post-mortem.

• Murray Cantor: "Object-Oriented Project Management with UML", Wiley, 1998.

Entrenamiento en dinámica de grupos
Considero que los profesores de Computación requerimos entrenamiento en el manejo de la dinámica de grupos. Con miras a cubrir esta deficiencia solicité un curso de entrenamiento al Dpto. de Ciencia y Tecnología del Comportamiento de la Universidad Simón Bolívar quienes gentilmente nos armaron el curso de Formación de Grupos y Equipos Efectivos que coordinan actualmente en el trimestre Abril-Julio del año 2000 las profesoras Belinda Bozo y Rocío Meneses. También elaboro unas notas sobre técnicas de dinámica de grupos que podrían ser de utilidad. Un libro de enfoque muy práctico sobre el tópico es Team Leader's Problem Solver de Clay Carr (Prentice-Hall, 1996) ; las profesoras B. Bozo y R. Meneses completan su curso principalmente con lecturas del libro de Stephen Robbin titulado Fundamentos de Comportamiento Organizacional: Teoría y Práctica (Prentice-Hall Hispanoamericana, 1999).

Experiencias previas de los estudiantes en trabajo en grupo
Puede ser interesante indicar que si bien las asignaturas previas de la carrera concretan experiencias de trabajo en equipos de dos personas, 33% de los estudiantes encuestados del curso indicaron que habían tenido alguna experiencia en grupos de más de dos personas:

• Un estudiante indicó que había trabajado en grupos de 4 y 5 miembros;
• Un estudiante indicó que trabajó en grupos de 4 a 6 personas en trabajos de Estudios Generales;
• Un estudiante indicó haber trabajado en un grupo de 7 personas como preparador del CIC y en un grupo de 4 personas como miembro del Laboratorio Docente de Computación (LDC).


A pesar de ello, las encuestas finales indican que el trabajo de equipo en el curso les resultó novedoso y motivante a todos los estudiantes. Sospecho que la diferencia está en que el curso exige la formación de cierta estructura en el grupo, con roles y responsabilidades separadas y claras, mientras que el grueso de las experiencias previas eran en grupos menos estructurados.

2.8 Cobertura débil de pruebas (testing)

Este sigue siendo el tema peor cubierto del curso y amerita un estudio más exhaustivo. En el trimestre Enero-Marzo del 2000, exploré el tema en el  curso recien aprobado denominado Ingeniería de Software 3.
 

3 La descripción del curso

3.1 Programas y calendarios

Introducción a los problemas y métodos para desarrollar software de mediana envergadura. El modelo de la cascada y el modelo de desarrollo incremental. Íntroducción a la captura y análisis de requerimientos. Modelado de software. Diseño de software. La prueba (testing) de software. Introducción al trabajo en equipo, el control de proyectos y otros aspectos de la dimensión no técnica del desarrollo de software.

Introducción a la Ingeniería del software: El desarrollo de software de mediana envergadura, necesidad de trabajo disciplinado en equipo, etapas en el ciclo de vida del software, modelo de la cascada, modelo de desarrollo incremental, factores críticos, definición e importancia de la IS . Software orientado a objetos.

Análisis orientado a objetos: captura de requerimientos, roles del analista, el usuario y el patrocinador. Metas, funciones y atributos del software. El modelo de uso: actores, casos de uso. Análisis de requerimientos.

Modelado orientado a objetos: Necesidad de múltiples modelos. El modelo estructural: clases, atributos,
métodos, herencia y asociaciones. Diagramas de secuencias de eventos del sistema. Contratos. Diagramas de colaboración.

Diseño orientado a objetos:  Principios de diseño: experticia, acoplamiento y cohesión. Patrones: Observador (model-view-controller, publish-subscribe), iterador, estrategia, apoderado (proxy), decorador, fábrica abstacta y compuesto. Arquitectura de capas: presentación, aplicación, almacenamiento. Evaluación de diseños según criterios como facilidad de uso, eficiencia, seguridad, complejidad, flexibilidad, auditabilidad y esfuerzo.

Pruebas (testing): Definición. Barreras psicológicas. Planificación y seguimiento del proceso de pruebas.
Pruebas unitarias. Pruebas de integración. Pruebas de sistemas.

Documentación: Elaboración de manuales. El manual de instalación. El manual del usuario.

Control de proyectos: Nociones básicas de trabajo en equipo, roles (miembro, líder, editor técnico, webmaster, coordinador de reuniones), planificación, control, seguimiento, coordinación de reuniones, manejo de agenda, distribución explícita de tareas, identificación y manejo de riesgos, confidencialidad, relaciones con el cliente, estimación de tiempo, caminos críticos y análisis post-mortem

3.2 La evaluación del curso

Para reducir el riesgo de copia de las tareas, en cada entrega de la tarea se seleccionaron varios estudiantes al azar para ser interrogados. Si no estaban presentes o no lograban explicar satisfactoriamente lo que habían escrito recibían una nota de cero por la tarea.
 

3.3 Recursos

• Hardware: Computadoras personales pues todo el software es portable y de hecho estará incluido en el CD-ROM de la carrera. Se reservan horas para el uso de Estaciones Sun del Laboratorio Docente de Computación para montar toda la documentación generado por el proyecto y cerciorarse que los desarrollos sean independientes de plataforma (al menos entre una plataforma Wintel y plataforma Solaris.)
• Software: Editores de Páginas Web (Composer  bajo Netscape 4.5 o similar), JDK 1.2, correo electrónico.
• Preparador: Apoyo para la instalación de JDK, consultas y evaluación de Java en general y de la librería Swing en particular.
• Bibliográficos:
• Craig Larman: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. Prentice-Hall, 1998. Texto.
• Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. Complemento para patrones.
• Roger S. Pressman: Ingeniería del Software: Un Enfoque práctico. Cuarta edición. McGraw-Hill, 1998. Complemento para pruebas (testing).
• Cay Horstmann y Gary Cornell: Core Java 2 : Volume I -Fundamentals. Prentice-Hall, 1999.
• WWW:
• Material preparado por el autor.
• Sitio www de apoyo al texto de R. Pressman.
• Repositorio Cetus sobre Tecnología Orientada a Objetos.
• Object Management Group (OMG).

3.4 El proyecto de desarrollo

El objetivo de Delta Pensum es permitirle al estudiante que vive un proceso de cambio de pensum determinar, a
partir de las asignaturas que tiene aprobadas en el viejo pensum:

• Las asignaturas que tiene aprobadas en el nuevo pensum;
• Las asignaturas que tiene que cursar en el nuevo pensum;
• Un plan de estudios para culminar la carrera (es decir una indicación de las asignaturas que debe cursar, por trimestre).

El único incremento desarrollado completamente en el trimestre Abril-Julio 1999 (Delta Pensum 0.1.1) le permite sólo al Coordinador de la carrera realizar una consulta relacionado únicamente con los primeros dos objetivos. También se documentaron algunos aspectos de incrementos futuros (Delta Pensum 0.1 y Delta Pensum 1.0).

El desarrollo se llevó a cabo en paralelo con el proceso final de aprobación del cambio de pensum. En la novena semana del trimestre el Consejo Directivo de la USB aprobó el nuevo pensum para que entrara en vigencia para Septiembre 1999.  Por ende, desde el principio del proyecto se vivió con una fuerte presión para culminar el proyecto para la semana 10. En un momento crítico del trimestre opté por darle mayor prioridad a los aspectos pedagógicos del proyecto a costa de la posibilidad de culminar el producto a tiempo. El proyecto efectivamente no culminó a tiempo para el cambio de pensum de Septiembre pero se espera proseguir su desarrollo en la cadena de Ingeniería de Software con miras a lograr un producto útil y robusto.

4. El desarrollo del curso

4.1 La fase de entrenamiento

Durante esta fase, los estudiantes tuvieron que desarrollar dos tareas, a saber:

• La elaboración de un sitio www;
• Programar una pequeña aplicación en Java.

4.2 La fase de elicitación de requerimientos

Este juego permitió mostrar muy gráficamente la compleja situación de elicitación de requerimientos en sus dimensiones financieras, de seguridad, competitivas, políticas y comunicacionales.

En general resultó muy popular entre los estudiantes, pero dado los objetivos limitados  del curso en cuanto a esta problemática, puede debatirse si no consumió tiempo que hubiera sido mejor invertir en el desarrollo del proyecto principal.

Este entrenamiento en la elicitación de requerimientos se intentó aprovechar para capturar (algo apresuradamente) los objetivos del proyecto Delta Pensum. Para ello invité a la Coordinadora de Computación (pregrado), la Prof. Maruja Ortega y a la Asistente de la Coordinación (Lic. Montezuma), como usuarios/patrocinantes del futuro sistema Delta Pensum. El proceso de captura de requerimientos fue relativamente pobre ya que los estudiantes se alejaron de su rol de analistas para caer en el rol de afectados por el cambio de pensum. Por ende las preguntas estuvieron dirigidas más a  conocer cómo los afectaría, en lo personal, el cambio de pensum que en las funciones y atributos del software a desarrollar.

El tipo de error más común que cometieron los estudiantes en esta parte fue:

• Redacción inadecuada, pomposa o excesivamente ambicioso.

Considere estas descripciones de una de las metas para un sistema de inventario para la juguetería mencionada previamente:
"Tener control absoluto del inventario".
"Realmente este sistema llevará un verdadero control y manejo del inventario con una seguridad del 100%".
O considere parte de la descripción del sistema de inventario:
"Otra gran ventaja del sistema es su implementación inteligente que permite, por ejemplo, notificar mediante una alerta cuando un producto está por debajo de una cantidad estipulada, marcando un umbral el cual sugiere la solicitud al distribuido encargado del producto el envío de más mercancía al local, procedimiento el cual el mismo sistema se encarga enviando un fax o un e-mail al distribuidor con la cantidad solicitada."
En ambos casos he enfatizando én letra itálica fallas de forma, contenido o ambas.

4.3 La fase del modelado de uso

• Identificar los actores del sistema;
• Identificar los casos de uso;
• Describir cada caso de uso.

• No se identifican todos los actores y para algunos actores no se identifican todos los casos en que intervienen (fallas comprensibles, pues generalmente los estudiantes no conocen bien el dominio de la aplicación);
• No se enlazan los casos de uso con las funciones y atributos capturados previamente. En general, el estudiante no verifica la consistencia entre sus modelos y en muchos casos tampoco documenta los enlaces entre los modelos. Este último caso conduce, entre otros problemas, a no perderle la traza a los requerimientos (lost requirements traces).
• Dificultad en redactar de forma precisa el diálogo entre los actores y el sistema en cada caso de uso. Esto incluye el problema de escoger nombres pobres para los casos de uso como por ejemplo llamar Introducir datos al caso de uso correspondiente a Elaborar un Plan de Estudios.
• Ignorar la notación del caso de uso, en particular en lo que concierne a las acciones optativas o alternas. En uno de los grupos, este problema persistió hasta bien entrado el trimestre.
• Introducción prematura de aspectos algorítmicos en la descripción de la reacción del sistema.

4.4 La fase del modelado estructural

Las fallas y dificultades de los estudiantes fueron las mismas que se observan cuando aprenden modelos Entidad-Interrelación (ER). Estas dificultades sugieren que este curso debe tener como requisito un curso introductorio de Bases de Datos para agilizar la cobertura de estos tópicos.

Esta es una fase muy rica para el estudiante por lo que es cuando el estudiante requiere un retroalimentación a la brevedad posible sobre sus diagramas. En el curso se enfatizó más la identificación de clases y de las asociaciones entre clases y la determinación de la multiplicidad de las asociaciones. Se trabajó superficialmente la identificación de atributos y de métodos y ello tuvo efectos negativos en el desarrollo posterior.

Conviene también indicar que en esta fase introduje los estudiantes a algunos patrones. Cometí un error interesante de diseño al insistir en que incorporaran una instancia del patrón Compuesto (en Inglés Composite), el cual se utiliza para expresar estructuras arborescentes entre clases. Despues de implementado el prototipo resultó claro que como  la instancia en cuestión siempre es una estructura de dos niveles (el pensum de una carrera está organizado por años y cad año está organizado por períodos trimestrales), la generalidad que aporta el uso del patrón no aportó beneficio alguno y complicó el desarrollo posterior.

Finalmente es interesante observar que los diseños de los estudiantes sobresimplificaban no-intencionalmente la realidad. Existen una serie de restricciones que los estudiantes no detectaron ni analizaron, ni surgían directamente del modelo de uso. Operativamente el corazón del sistema es el algoritmo de elaboración de un plan de estudios , el cuál recomienda qué asignaturas cursar en qué trimestres. El caso de uso esconde la complejidad del algoritmo bajo una línea "Elaborar un plan de estudios". El exagerado enfoque que hicimos en el curso en concebir el sistema en base a los objetos que lo componen, nos hizo omitir capturar adecuadamente los requerimientos de este algoritmo clave. Al no tener tales requerimientos en forma explícita, el análisis fue incapaz de identificar la existencia de clases adicionales importantes. Cuando en etapas posteriores se hizo evidente que faltaban clases y por ende se empezó a revelar la verdadera dimensión del problema de elaboración del algoritmo, cundió la angustia, el pánico y el desfallecimiento y al curso le costó superar ese "balde de agua fría". Ello obligó a redefinir drásticamente el alcance del proyecto, el cual de hecho no llega a plantear el algoritmo, quedando tal actividad pendiente para cursos futuros.
 

4.5 La fase de diseño de la interfaz del sistema

Preocupado por la cantidad y legibilidad de los datos que se deben mostrar del pensum (vista además clave a lo largo del sistema), yo recomendé fuertemente mostrar sólo un año del pensum en la pantalla a la vez. Afortunadamente uno de los equipos insistió en criticar mi propuesta, hizo caso omiso de mis recomendaciones y demostró que era perfectamente factible mostrar, legiblemente, el pensum completo en pantalla. Su mayor reinvindicación fue la clara preferencia del usuario potencial por su diseño de interfaz.

De nuevo hay que insistir que una buena parte de la fascinación del curso estriba en discusiones y evaluaciones como ésta, donde es importante que el profesor ocasionalmente le permita a sus estudiantes persistir en un diseño aún a riesgo de que no sea el óptimo y que mantenga la mente abierta y flexible. Por eso considero tan pedagógico el desarrollo en equipos que compiten entre si para desarrollar el mejor producto. El análisis de las diferencias entre los diseños y la comparación de los productos (y procesos!) finales suele ser uno de los aspectos más pedagógicos y motivantes del curso.

4.6 La fase del modelado del comportamiento

En un segundo paso se debe elaborar un contrato por cada evento del sistema, en el que básicamente se explicitan las precondiciones necesarias para admitir el evento, las excepciones que pueden producirse y las acciones o postcondiciones producidas en el sistema al reaccionar ante el event. Estas postcondiciones indican qué objetos y asociaciones se crean, modifican o destruyen en el sistema a raiz de la aceptación del evento.

El segundo paso causó varios problemas:

1. La nomenclatura de precondición, postcondición parecer estimular los prejuicios de los estudiantes que le huyen a los tópicos más formales como Lógica Simbólica. Este problema es menor y se logró superar rápidamente, quizás en buena parte por ser la notación muy poco formal.

 
2. Elaboración mecánica de los contratos debido a:
1. La cantidad de eventos que surgieron y para los cuáles debían escribirse contratos;
2. Escepticismo respecto a  la utilidad de escribir contratos.
Los primeros contratos típicamente eran (muy) incompletos ya que tendían a limitarse a las reacciones más inmediatas al evento aceptado.
 
3. Confusión en la relación entre precondición y excepción. Si una precondición no se cumple, ¿el evento no puede producirse, igual puede producirse pero debe disparar una excepción o igual puede producirse pero al no ajustarse el medio al contrato, el sistema tiene libertad realizar cualquier acción --incluso caerse? Esta confusión no vino a disiparse sino en cursos posteriores cuándo empecé a distinguir entre una precondición supuesta (assumed precondition) y una precondición garantizada (enforced precondition), distinción tomada de R. Marick (The Craft of Software Testing, Prentice-Hall 1995).

4.7  La fase del modelado de la interacción

En lo personal he encontrado que esta es una fase muy rica en decisiones de diseño y efectivamente donde introduzco o considero para su uso a más patrones. Sin embargo el curso se estrelló en esta fase. Los estudiantes no lograban entender cómo elaborar un diagrama de colaboración, cometían errores sintácticos y semánticos y la calidad de sus diseños era muy pobre. Tuve que explicar tres veces los diagramas y rechazar igual número de veces los diagramas propuestos por los estudiantes. Pasamos varias semanas estancados en esta fase hasta que finalmente llegamos a unos diagramas de colaboración que consideré apropiados... ¡pero que fueron en buena parte ignorados por los estudiantes cuando programaron el prototipo del sistema! Los diagramas no fueron del agrado de los estudiantes, los consideraron pesados, complejos, difíciles e irrelevantes.

Uno de mis colegas, el Prof. Víctor Theoktisto me observó que los diagramas de colaboración se basan en un paradigma de agentes que se intercambian mensajes. Como mis estudiantes no tenían cursos previos donde los hubiesen introducidos, aunque fuera rudimentariamente a elementos de este paradigma (digamos en la noción de procesos en un curso básico de Sistemas de Operación), lo que yo veía como una notación simple a ellos les resultaba un muro de confusión.

La hipótesis del Prof. Theoktisto me resultó muy convincente, por lo que esperaba que esa dificultad se subsanaría al dictarle el mismo material a estudiantes del último año en el curso Ingeniería de Software 2.  Para mi gran sorpresa, las dificultades persistieron, por lo que pienso que hay factores adicionales al hipotetizado por mi colega.

Finalmente se integró mejor el tópico de patrones de diseño orientado a objetos, gracias a la cobertura y la estrategia pedagógica del texto de C. Larman. Inspirado en dicha estrategia se trataron de cubrir con más énfasis un número reducido de patrones con incidencia directa en el proyecto desarrollado. Aún así el éxito debe considerarse relativo.

4.8 La fase de implementación

Como mencioné en el párrafo anterior, lamentablemente hicieron caso omiso de su propio diseño (detallado), por lo que su implementación final no siguió todos los parámetros del diseño. Por ejemplo, el diseño separó claramente la capa de la interfaz de la capa del dominio de la aplicación; la implementación entremezcló las dos capas. Las consecuencias de esto se vieron en los cursos posteriores que trataron, con relativamente poco éxito, de reutilizar el diseño y especialmente el software desarrollado.

Adicionalmente estuvo evidente que muchos de los estudiantes no habían recibido el entrenamiento suficiente en el uso de librerías de JDK, por los que los pocos estudiantes con un dominio más avanzado de Java estuvieron sobrecargados pues no sólo se encargaron de las tareas más delicadas de programación sino que adicionalmente tuvieron que asesorar y ayudar a sus compañeros en cuanto a estilo de programación, identificación y uso de clases de librería y depuración de programas en Java.

Respecto a las pruebas, sólo dio tiempo de presentar los estándares de la IEEE (IEEE 829-1983, ANSI/IEEE  1008-1987) respecto a la planificación y documentación de pruebas unitarias, pruebas de integración y pruebas de sistema e intentar llevarlas a cabo de manera representativa e informal. Como he comentado previamente en este reporte, este aspecto del curso fue claramente insatisfactorio y conllevó a dedicar un curso posterior (Ingeniería de Software 3) a explorar las pruebas de sistemas orientados a objetos.
 

4.9 La entrega del sistema

Si el profesor quiere conservar el material elaborado por los estudiante para su uso futuro, esta actividad debe ser planificada cuidadosamente.
 

4.10 Observaciones sobre la dinámica de grupos

El equipo InterSoft estaba constituido por seis muchachos y una muchacha. En principio, era el equipo más fuerte pues todos sus integrantes  cursaban las dos asignaturas. Dos de los estudiantes tenían buenos conocimientos de Java.

El equipo Warem Systems estaba constituido por tres muchachos y dos muchachas. Solamente dos de sus miembros cursaban las dos asignaturas, mientras que los otros tres sólo cursaban Sistemas de Programas, por lo que a estos últimos no se les podía exigir tanto trabajo de desarrollo. El grupo tenía poca experticia en Java.

El equipo Sistemas Clan-Roy  estaba constituido por cinco muchachos. Uno sólo de sus miembros cursaba las dos asignaturas; el resto cursaba sólo el Taller de Sistemas de Programas. El grupo tenía poca experticia en Java.

Una vez comenzado el curso se hizo patente que la división en equipos no estaba funcionando bien. En particular Warem Systems mostraba claras señales de que el trabajo rebasaba su capacidad de trabajo, por cuánto la mayor parte de los integrantes no tenían la disponibilidad de tiempo necesario para llevar a cabo un desarrollo. Por otro lado la dependencia de Sistemas Clan-Roy del único miembro que cursaba las dos asignaturas para poderse enterar de lo que ocurría en las sesiones de Sistemas de Programas constantemente hacía temer en fallas de comunicación. La situación la resolví, juntando estos dos equipos para formar un equipo de 10 miembros que pasó a llamarse Warem and Roy Corporation (Warem&Roy). Esta fusión fue mucho más arriesgada que lo indicado aquí pues habían ciertos prejuicios entre los dos equipos. Warem proyectaba la imagen de un equipo formado por personas tranquilas, de trato suave y muy clase media mientras que Clan-Roy proyectaba una imagen de una banda de rebeldes iconoclaustas. Afortunadamente (¡y parta suerte mía!) el proceso de fusión fue excelente. Sistemas Clan-Roy cedió la coordinación general del proyecto al coordinador de Warem, y el Coordinador de Clan-Roy desempeño un excelente rol de puente inicial entre los dos grupos. Los dos grupos lograron aprovechar su potencial conjunto a tal punto que cuando el Coordinador de Warem renunció a la Coordinación conjunta, todos estuvieron de acuerdo en que el coordinador original de Clan-Roy pasara a coordinador Warem&Roy. Al terminar el proyecto, los miembros de ambos equipos coincidieron en señalar que la experiencia de fusión les había sido altamente positiva. De hecho, la heterogeneidad del grupo le terminó aportando mayor creatividad que a InterSoft --de hecho Warem&Roy no dieron muestras de group-think , mientras que esto le ocurrió en dos ocasiones claves a InterSoft.

La dinámica de los grupos prepara muchas sorpresas para un profesor que pretende apoyarse en el trabajo en equipo. Para comenzar, la presión de los pares hace que los grupos se vuelvan "opacos"; es decir, los problemas se esconden dentro del grupo y éste presenta una fachada de control y previsión que se desmorona cuando la situación es insostenible.

Durante el curso se presentaron las siguientes situaciones:

• Asistencia irregular a las reuniones del equipo.

Los estudiantes se quejaron de las dificultades de encontrar un horario común para poder realizar reuniones fuera de las horas de clase. Adicionalmente algunos estudiantes empezaron a acumular un número significativo de inasistencias a reuniones, así como a llegar con hasta dos horas de retraso respecto a la hora fijada.
Este problema fue reducido al empezar los estudiantes a llevar minutas de sus reuniones con una clara indicación de inasistencias e impuntualidades. Se explicó a los estudiantes que las minutas era el único mecanismo que permitía "probar" el incumplimiento de un estudiante respectos a las reuniones. Por supuesto que la incompatibilidad de horarios  no se resuelve con minutas, pero el llevar minutas con listas de asistencias sí ayuda a reducir las inasistencias más flagrantes y cierto nivel de impuntualidad
 
• Manejo inadecuado de tiempo en reuniones.

Como queja general fue que las reuniones se hacían demasiado largas. Evidentemente los estudiantes deben aprender a llevar una agenda y a aprender a hacer reuniones efectivas y eficientes. Si bien se empezó a llevar agenda, hubo poca guía respecto a cómo hacer las reuniones más productivas, por lo que el problema continuó durante el resto del trimestre.
 
• Fallas de comunicación entre miembros del equipo.

A pesar del uso de correo electrónica, algunas de las fallas de comunicación que se presentaron fueron muy llamativas:
1. El editor técnico de uno de los equipos renunció pero la mayoría de los miembros de su equipo no se enteró hasta la víspera de una entrega importante, con lo que la calidad de la entrega quedó seriamente comprometida.
2. Por razones poco claras, uno de los miembros de un equipo tuvo problemas en mantener su dirección de correo electrónica en la lista de distribución del Coordinador de Reuniones. Este miembro alegó que muchas de sus inasistencias a reuniones se debieron a que sencillamente no le llegaban las notificaciones de las reuniones.
3. Un estudiante tuvo una participación bastante pobre durante casi todo el trimestre; faltaba a reuniones y no cumplía con las tareas que le encomendaban. El equipo a que pertenecía logró ocultarme esta situación durante bastante tiempo pero a costa de un creciente resentimiento contra el miembro "perezoso" del equipo. Finalmente en una reunión muy tensa, el equipo confrontó al miembro errante, sólo para enterarse que un familiar muy cercano del estudiante sufría la etapa final de un cáncer. Por supuesto que el sentimiento de furia se convirtió en un inmenso y desalentador sentimiento de culpa.
• Dedicación dispareja al proyecto.

El tiempo y esfuerzo invertido por los estudiantes fue bastante disparejo. Cada equipo debía designar los siguientes roles:
• Coordinador del equipo;
• Webmaster;
• Editor técnico;
• Coordinador de reuniones.
Los estudiantes que se encargaron de los primeros dos roles tendieron a sobrecargarse de trabajo con respecto a los demás estudiantes. Sospecho que entre dos estudiantes podía haber hasta un orden de magnitud de diferencia entre el esfuerzo y la contribución al proyecto, pero resultaba muy dificil comprobarlo.  Traté que formalizaran y explicitaran la repartición de tareas con relativo poco éxito. En cursos posteriores tuve mejor éxito al respecto, solicitando el número de minutos de dedicación a la asignatura por semana de cada estudiante, sus responsabilidades y haciendo uso de encuestas de evaluación interpares de dos a tres veces por trimestre.
 
• Sobre-especialización en roles.

Cada equipo debía determinar a quién asignar los roles mencionados previamente y sólo habían cambios en esa asignación si el responsable renunciaba. La tendencia fue que los estudiantes que ya tenían conocimientos especiales que les facilitaba desempeñar un rol son los que tomaban el rol y aprendían más sobre su realización, mientras que los estudiantes con menos experiencia (y por ende con más necesidades de aprendizaje) fueron los que menos oportunidad tuvieron de aprender a ejercer esos roles. En particular los webmaster eran estudiantes que ya traían al curso buenos conocimientos de construcción de páginas web y si bien pudieron ejercitarse en una actividad de su gusto, realmente técnicamente aprendieron muy poco adicional sobre tal actividad. En cursos posteriores experimenté con la rotación de cargos o roles entre los miembros del equipo, lo que permite a los estudiantes apreciar mejor las dificultades inherentes a un rol particular.
 
• Formación de cliques

Algunos de los estudiantes hubieran querido participar más de las decisiones pero sentían que el "poder" en el equipo estaba en manos de un grupo de tres a cinco estudiantes. En tales casos daba la impresión que el clique se formaba muy temprano en la vida del grupo y que despues se hacía difícil romperlo. Por ende la solución a este problema parece pasar por mayor cuidado en la fase de formación del grupo, mayor atención a su evolución (aquí son útiles las encuestas inter-pares) y la rotación de cargos.
 
• Manejo inadecuado de tensión.

Más de un grupo pasó por etapas de conflicto sordo innecesario. Afortunadamente, ajuzgar por las encuestas finales, las etapas fueron transitorias y como veremos en la próxima sección, los estudiantes consideraron la experiencia altamente positiva.

5. Resultados del experimento

Los estudiantes siguen gustando del curso y pienso que siguen válidos las razones indicadas para el primer experimento docente.

• El factor tradicional asociado con Sistemas de Programas, los estudiantes tienen la sensación que se trata de la primera materia de la carrera donde "le ven el queso a la tostada", es decir que les permite extrapolar sus estudios a su vida profesional para aclarar cómo y en qué trabaja el Ingeniero de Computación cuando desarrolla software.
• La sensación de estar aprendiendo tecnología de punta, o al menos herramientas y procesos mencionados  emocionadamente como novedades en la literatura popular tales como:
• Elaboración de páginas WWW;
• Java;
• Tecnología orientada por objetos;
• El efecto Hawthorne.

5.1 Logros

1. Salido motivados para trabajar en equipos medianos (4-10 personas) y con una importante experiencia positiva al respecto. En este sentido se conserva y consolida el logro reportado en el primer experimento.
2. Obtenido un dominio más sólido en tecnología orientada a objetos de lo que han obtenido en el pasado --y aquí incluyo la experiencia del primer experimento. La adopción del Larman permitió impartir una visión mucho más coherente del análisis y diseño orientado a objetos y más acorde con el nivel del estudiante. También me parece que el conocimiento logrado de la programación orientada por objetos y el uso de patrones y principios de diseño fue superior al logrado (en promedio) en el primer experimento.
3. Mejorado su enfoque de cómo desarrollar software de envergadura mediana y en particular  la utilidad de los modelos como herramienta de análisis y diseño de software y el trabajo en equipo.

5.1.1 ¿Qué fue lo que más le gustó a los estudiantes?

• "Poder desarrollar un proyecto real, lo que me permitió sentir más de cerca la responsabilidad y el compromiso de un desarrollador frente a un cliente. Otro punto importante de lo que más disfruté fue el poder compartir con otras personas de la carrera, algo a lo que la comunidad de la USB no está muy acostumbrada."
• "El trabajo en equipo y la división de roles en los grupos de trabajo."
• "La idea de las compañías [desarrolladoras de software]. Me pareció muy creativa y útil."
• "La oportunidad y experiencia de trabajar en equipos grandes donde cada quien tiene un rol y realiza sus actividades."
• "Que tratamos con un problema de la vida real, es el primer curso de la carrera en que nos preocupamos por resolver una situación que nos afecta a todos [...] La materia que más me gustó fue la primera parte: Captura de requerimientos que es algo que siempre (en los cursos anteriores) se había pasado por encima pero a mi modo de ver es de suma importancia."
• "1. [Trabajar] en un problema (proyecto) real. 2. El lenguaje de programación empleado. 3. Nos enseñó a pensar un poco más (y mejor).
• "La programación orientada a objetos".

5.1.2 ¿Qué fue lo que le pareció más útil a los estudiantes?

• "Aprender un modelo para estructurar un problema específico".
• "Sin lugar a duda, creo que este curso en su totalidad es de gran utilidad para la vida estudiantil y profesional. Es lo que realmente se espera desde que se entra en carrera."
• "Aprender a diseñar un problema para luego facilitar la codificación y además me pareció útil aprender a codificar en Java."
• "El diseño de proyectos me pareció muy útil, haberlo hecho como una compánía me pareció muy pedagógico."
• "El aprendizaje efectivo logrado en la parte de captura de requerimientos y diseño. La programación en Java y orientada a objetos."
• "La idea de trabajar en grupo de mayor cantidad de gente en el que cada uno tiene un cargo definido. La simulación de una companía me pareció excelente."
• "1. El trabajo en grupo. 2. Capturar requerimientos, funciones, atributos, etc. 3. Los modelos. 4. La orientación a objetos."

5.2 Contratiempos y fallas

5.2.1 ¿Qué fue lo que menos le gustó a los estudiantes?

• "La forma de evaluación de la materia no estuvo muy clara.".
• "Tener que compartirlo con otras materias en un trimestre."
• "El curso exige una carga de trabajo muy grande y vale muy pocos créditos (en mi caso que sólo estoy viendo el Taller)."
• "Haber tenido que recortar tanto el proyecto y en consecuencia no haber podido terminar lo  inicialmente planteado".
• "La falta de tiempo para culminar el proyecto efectivamente."
• "Es un curso muy absorbente, requiere de mucha dedicación y trabajo continuo. Otra cosa que me disgustó fue el hecho de que a mitad de trimestre se torna muy repetitivo (aunque reconozco que fue la única manera de aprender) por el hecho de que teníamos que repetir los trabajos porque su calidad no era la más óptima."
• "La constante creación de documentos."

5.2.2 ¿Qué fue lo que le pareció menos útil?

• "Nada".
• "No creo que haya nada inútil, todo es importante."
• "En realidad todo me pareció útil".
• "Todo me pareció útil".
• "Nada, creo que todos, algunos aspectos más que otros, son útiles."

5.2.3 En un espectro entre motivante (por lo novedoso y útil) y desmotivante (por la densidad y quizás, superficialidad de cobertura de los tópicos) , ¿dónde ubica esta asignatura?

A muchos les gusta el curso:

• "Motivante."
• "Motivante."
• "Motivante."
• "Me parece una materia muy importante y motivante, aunque sería un mayor estímulo si se obtuviesen calificaciones un poco mejores (relación esfuerzo-calificación)."
• "Muy motivante."

• "Un poco desmotivante pero fue porque no hay incentivo de producir o simplemente algo de apoyo moral (por parte de todos), por lo demás fue motivante."
• "Al principio del trimestre es un curso motivante, debido a que todo es nuevo y por fin es un curso que nos sirve para el futuro, ya al final del trimestre la motivación baja debido a la gran cantidad de trabajo y dedicación que requiere."

5.2.4 ¿Qué debe mejorarse? ¿Eliminarse? ¿Expandirse? ¿Cambiar de orden?

• "Debe mejorarse la enseñanza que tuvimos del lenguaje de programación usado (Java)".
• "Debe mejorarse la forma de dar las clases de Java. El hecho de que el preparador conozca el lenguaje no implica que lo sepa impartir. "

• "En la parte de Pruebas e Integración no se hizo tanto énfasis como en la parte de Diseño."
• "Hacer más énfasis en los diagramas de colaboración y la parte de planificación de pruebas."
• "Creo que la parte de los diagramas de colaboración y modelo estructural deben profundizarse. Los ejemplos del libro texto y los dados en clase no se comparan con los que tuvimos que realizar en el trabajo."
• "Debe expandirse testing y diagramas de colaboración."

• "En mi caso que sólo curso la teoría, me pareció que debía trabajar mucho a nivel práctico, aunque ese problema se eliminará al unir la teoría con la práctica."

"También creo que debido a que sólo tenemos 12 semanas de clases, no es posible hacer tantos cambios al proyecto, aunque se sabe que en la vida profesiona vamos a lidiar con cambios de requerimientos frecuentemente."

"No hacer tantos cambios de requerimientos al proyecto planteado."

• "Creo que debe comenzar la parte práctica (realización de tareas) un poco más temprano. Si vemos el desarrollo de Delta Pensum y la elaboración de la página web, ambas contaron con una duración de 15 días para su elaboración, sin embargo los niveles exigidos entre uno y otro no tienen comparación. Por otro lado considero importante que los trabajos teóricos vayan de la mano con la codificación, ya que muchas veces encontramos obstáculos a la hora de programar lo que teníamos pensado; lo que trae como consecuencia que se presenten discordancias entre el diseño y el sistema como tal."

5.2.5 ¿Qué recomendaciones le haría al profesor para que mejore el curso?

• "Explicar los defectos de cada uno (o del grupo) de una forma más clara, si es posible mostrando ejemplos concretos."
• "Me parece que el curso mejoraría si esta materia es sólo diseño y en la cadena se continúa con el resto de la materia, sería más fácil de asimilar."

El segundo  punto es muy interesante y de hecho lo tomaré en cuenta en el diseño de las asignaturas de la cadena.
 

5.2.6 Otras observaciones

• ¿Qué recomendaciones le haría al profesor para que mejore su pedagogía? ¿Qué aspectos importantes considera que él domina?

• "El profesor  conoce los comportamientos y tendencias que existen cuando se trabaja con más de 7 personas en un grupo de desarrollo de software".
• "A veces una persona del grupo de trabajo se siente motivado y quiere trabajar pero no siempre las demás personas ven este incentivo y simplemente no la dejan trabajar, luego esta persona se desmotiva y no produce lo que hubiese podido si  desde un principio le hubiesen dado la oportunidad."
• "...No pierda nunca las herramientas (tan importantes para un estudiante) como la comunicación, la comprensión y el interés por el aprendizaje."
• "Espero que conserve la terapia de los oreos, creo que dio muy buenos resultados, al igual que el humor aplicado en el ejemplo de la juguetería."
• "Me pareció excelente el feedback que recibíamos casi inmediatamente luego de una entrega, otros profesores se quedan durante semanas con los trabajos..."
• "Que fuese menos estricto en cuanto a las notas."
• "Creo que los proyectos que se asignan a este curso y la manera de evaluar deben considerar el hecho de que es un salto bastante grande en cuanto a la forma de trabajar y tiempo y dedicación requeridos [...] Sería muy ambicioso pensar que podemos rendir igual que en otros cursos cuando primero tenemos que acostumbrarnos a trabajar con tantas otras personas en un proyecto comparativamente Macro."

 6. Conclusiones y recomendaciones

En conclusión:
 
1. Los nuevos cursos resultan una mejora respecto al experimento docente anterior. En particular la adopción del texto y enfoque de C. Larman resultó acertado

 

 

2. El contenido del curso se redujo en cuánto a tópicos, eliminándose el tema de modelos dinámicos y sustituyendo el modelo funcional por el modelo de colaboración y contratos.
 
3. A los estudiantes les costó mucho lograr consistencia entre sus modelos.
 
4. El contenido del nuevo curso sigue siendo demasiado ambicioso para el tiempo disponible. No dio tiempo de cubrir pruebas de sistemas orientados a objetos de manera satisfactoria nisiquiera a nivel introductorio y el uso de patrones no logró asentarse adecuadamente (aunque sí logró integrarse al curso).

 
5. Algunas de las técnicas siguen introduciéndose prematuramente; en particular parece ser el caso de modelado conceptual y de la elaboración de los diagramas de colaboración.

 
6. El tópico técnico más dificultoso fue sin lugar a dudas la elaboración de diagramas de colaboración.

 
7. El orden de cobertura de tópicos fue adecuado y representa un avance respecto al primer experimento docente.

 
8. La integración de los dos cursos resultó positivo, sobre todo a la luz de la integración oficial que se dará en el nuevo pensum. Sin embargo me persisten dudas sobre la escalabilidad de la experiencia y recomiendo que el Departamento planifique al respecto.

 
9. El alcance del proyecto escogido fue demasiado ambicioso. Adicionalmente no se logró detectar la dimensión real del proyecto a tiempo y, como profesor, debo admitir que no manejé apropiada y oportunamente ni el aspecto iterativo ni el aspecto incremental de la metodología adoptada.

 
10. La evaluación fue continua y se centró en el proceso de diseño. El volumen de corrección es muy alto y debe planificarse un volumen alto de sesiones de evaluación y discusión de de diseños concretos del proyecto. A medida que el diseño se hace más detallado se hace más dificil presentar varios diseños y mantener el interés de más de un grupo.

 
11. Surgieron problemas interesantes en la dinámica de los equipos de estudiantes que ameritan más estudio y preparación por parte del profesor.

 
12. Los resultados del curso fueron positivos en lo que se requiere a la tasa de aprobados y la motivación suscitada entre los estudiantes.


En cuanto a las recomendaciones:
 

1. Conservar el texto y enfoque utilizados.

 
2. Es importante abrir una cadena en Ingeniería de Software para cubrir adecuadamente tópicos como arquitectura de software, patrones de diseño y testing orientado por objetos.

 
3. Integrar Sistemas de Programas con el Taller de Sistemas de Programas. Las dos asignaturas forman una unidad natural motorizada por la práctica del desarrollo (development-driven). Es decir, es el Taller quien "lleva la cachucha" pero las dos partes de la unidad necesitan fusionarse.

 
4. Planificar con mayor cuidado el alcance del proyecto, ajustándose a desarrollos incrementales  e iterativos  con horizontes de desarrollo mayores al trimestre.

 
5. Ajustar el contenido de la asignatura (y de la cadena) revisando con cuidado las relaciones que presupone o requiere con asignaturas como Sistemas de Operación, Traductores e Interpretadores, Lenguajes de Programación, Sistemas de Información, Bases de Datos, Control de Proyectos e Interfaces Gráficas.

 
6. Colocar Bases de Datos I como requisito de Sistemas de Programas.

 
7. Cubrir más detalladamente la programación orientada por objetos, especialmente en lo que se refiere a los componentes de las librerías de clases a utilizar.

 
8. Estudiar y resolver los problemas de los estudiantes en la elaboración de diagramas de colaboración.

 
9. Introducir una herramienta CASE que reduzca el esfuerzo de graficar los distintos diagramas y que ayude a validar la consistencia de y entre los modelos.

 
10. Repensar el tópico de pruebas (testing) orientado por objetos a la luz del poco tiempo disponible en el curso.

 
11. Mejorar la supervisión de la formación y evolución de los equipos de estudiantes. Para ello es conveniente buscar apoyo en un departamento como el Departamento de Ciencias y Tecnología del Comportamiento.

 
12. Formalizar los tópicos de dinámica de grupos que puedan resultarle de interés a los estudiantes.

 
13. Estudiar la posibilidad de incluir inspecciones formales para desarrollos orientados por objetos.

 
14. Revisar la cobertura del tópico de Patrones.

 
15. Extender la noción de trabajos en equipos de más de dos personas paulatinamente a otros talleres posteriores a Sistemas de Programas, de modo que al graduarse el estudiante tenga una formación y una experiencia de trabajo exitoso en grupo.

 
16. Considerar la posibilidad de incrementar el tamaño máximo de los grupos que pueden acometer un proyecto de grado. Sería una valiosísima experiencia que el trabajo final integrador de la carrera sea realizado en grupo, por cuanto estoy convencido que el grueso de los desarrollos futuros en software serán hechos en equipos de al menos cuatro personas.

Las gracias no estarían completas sin un agradecimiento muy especial a los estudiantes que participaron en el experimento. El grupo trabajó con ahinco y determinación. ¡Esperemos que el curso les haya retribuido su tiempo y esfuerzo!

También quisiera agradecerle al Departamento de Computación y Tecnología de la Universidad Simón Bolívar y en particular a su Jefe, Prof. Roger Soler, la confianza y la oportunidad de llevar a cabo este experimento y la Coordinación de Computación (pregrado) por estimularme a escribir este reporte y apoyar el proyecto Delta Pensum.
 
 

Esta página fue creada entre el 30 de agosto y el 1 de septiembre de 1999.

Ultima actualización: 14 de junio de 2000.

Para comentarios favor contactar al Profesor Alejandro Teruel