Orientando Sistemas de Programas a Objetos: Un experimento docente

Tabla de contenido

2. Motivación del experimento

2.1 Los cambios respetan el objetivo general de las asignaturas.
2.2 Los cambios actualizan contenidos
 
2.2.1 Popularización de los lenguajes de programación orientados a objetos
2.2.2 Ingeniería de software orientada a objetos
2.2.3 Desarrollar software orientada a objetos es más que usar un lenguaje orientado a objetos

3.1 El programa tradicional
3.2 El programa experimental
3.3 Temas afectados del programa tradicional

4.1 ¿Por qué tareas y no exámenes?
4.2 ¿Por qué tantas tareas?
4.3 ¿Por qué tareas en grupo?

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é opina de la forma de evaluar el curso?

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 programaron en Java.

Los resultados fueron alentadores pero no definitivos. Los cursos aún requieren de ajustes importantes.

En este reporte presentaré:

1. La motivación para el experimento;
2. Los alcances del experimento;
3. Los resultados alcanzados;
4. Las recomendaciones que se derivan de la experiencia.

2. Motivación del experimento

• Respetan los objetivos generales de las asignaturas;
• Actualizan contenidos, sustituyendo técnicas más asociadas al desarrollo de software imperativo no orientado a objetos por técnicas más cónsonas con el desarrollo de software orientado por objetos. El paradigma imperativo orientada por objetos tiende claramente a ubicarse como el paradigma dominante tanto académica como industrialmente;

2.1 Los cambios respetan el objetivo general de las asignaturas

Introducir al estudiante a la problemática y a aquellas técnicas de desarrollo de software de mediana envergadura representativas del enfoque disciplinado asociado con la Ingeniería de Software. Se enfatizarán las técnicas de diseño y validación de sistemas de programas que:
1. Incrementen la productividad del desarrollador de software;
2. Permitan controlar la complejidad inherente a sistemas de mediana envergadura;
3. Introducen al estudiante al desarrollo en equipos (teams).

"...representativas del enfoque disciplinado asociado con la Ingeniería del Software"

2.2 Los cambios actualizan contenidos

1. La tecnología se ha popularizado enormemente al punto que es la tecnología más utilizada en un importante sector de la industria de producción de software;
2. La tecnología ha madurado notablemente en la última década;
3. La tecnología presenta importantes ventajas en cuanto a sus posibilidades de estructuración y reutilización;
4. Para usar bien esta tecnología se requiere de un aprendizaje considerable en cuanto a tiempo y esfuerzo. No es en absoluto cierto que las técnicas convencionales de desarrollo de software aplican al software orientado por objetos y que basta con aprender un lenguaje de programación orientado a objetos para desarrollar buen software orientado a objetos.

2.2.1 Popularización de los lenguajes de programación orientados a objetos

2.2.2 Ingeniería de software orientada a objetos

"Durante la primera mitad de los años 90, la ingeniería de software orientada a objetos se convirtió en el paradigma de elección para muchos productores de software y un creciente número de sistemas de información y profesionales de la ingeniería. A medida que pase el tiempo las tecnologías de objetos sustituirán a los enfoques clásicos de desarrollo de software."

2.2.3 Desarrollar software orientada a objetos es más que usar un lenguaje orientado a objetos

En 1997, supervisé a mis estudiantes en una búsqueda de seis patrones básicos en los proyectos de grado de la carrera de Ingeniería de Computación. No encontramos rastro de ninguno de los seis patrones, a pesar que en todos los proyectos podía haber incorporado, beneficiosamente, al menos un patrón. La revisión de estilo de programación parecía sugerir que los estudiantes programan en un lenguaje orientado a objetos ¡sin aprovechar, y en algunos casos sin dominar, los conceptos y mecanismos orientados a objetos! Algunos comentarios de pasillo de profesores de asignaturas como Lenguajes de Programación, Sistemas de Información, Bases de Datos e Interfaces con el Usuario corroboran que el estudiante tiene un dominio insatisfactoria y precario de la tecnología orientada a objetos.

La estructura del software orientado a objetos es diferente  a la estructura de software más convencional; por esta razón se requieren de técnicas de diseño diferentes a las técnicas tradicionales. Estas técnicas no son evidentes y por ende requieren ser incorporadas en cualquier programa de estudios que pretenda formar a profesionales capaces de manejar apropiadamente la tecnología orientada a objetos. No es realista pretender que el estudiante las adquiera por si sólo.
 

3. Alcance del cambio propuesto

Desde un principio fue claro que para lograr una cobertura razonable de estos elementos, algunos tópicos tradicionales en el programa debían ser recortados o eliminados.
 

3.1 El programa tradicional

1. Introducción

Los sistemas de programa de mediana y gran envergadura. Características. El ciclo de vida de un sistema de programas.
2. Diseño de sistemas de programas

Criterios de diseño: modularidad, acoplamiento, cohesión, ocultamiento de información, reutilizabilidad. Estrategia de programación en ambientes tipo Unix. Diseño estructurado. Diseño orientado a objetos.
3. Validación de sistemas de programas

Diseño de casos de pruebas: métodos caja blanca y caja negra. Planificación de pruebas. Pruebas de integración. Pruebas regresivas. Inspecciones formales.
4. Herramientas básicas para el equipo de desarrollo

Control de configuraciones.
5. Introducción a la dimensión no técnica del desarrollo del software.

3.2 El programa experimental

• Craig Larman: "Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design". Prentice-Hall, 1998.
• Murray Cantor: "Object-Oriented Project Management with UML", Wiley, 1998.

• Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides: "Design Patterns: Elements of Reusable Object-Oriented Software". Addison-Wesley, 1995.

• Roger Pressman: "Software Engineering: A Practitioner's Approach". Cuarta edición. McGraw-Hill, 1997 (la versión correspondiente en Castellano es de 1998).

1. Introducción.

Los sistemas de programas de mediana y gran envergadura. Características. Definición de Ingeniería de Software. Procesos y productos en el desarrollo de software, Factores críticos en el desarrollo de software, Elementos de gerencia de proyectos de desarrollo de software.
2. Programación orientada a objetos.

Cases, atributos, métodos, objetos y herencia.
3. Modelado orientado a objetos.

Los modelos de OMT (Object Modeling Technique) para Ingeniería de Software Orientado a Objetos. La problemática de las especificaciones informales.
1. El modelo estructural o estático:

Clases, herencia, agregación y asociación. El diagrama de relaciones estructurales entre clases, Identificación de clases.
2. El modelo dinámico:

Eventos, estados, transiciones y acciones. Trazas de eventos. Operaciones en estados. Autómatas anidados asociadas a clases. Concurrencia entre autómatas.
3. El modelo de uso:

Actores y casos de uso. Acciones y respuestas. Acciones alternas. La relación usa entre casos de uso.
4. El modelo funcional:

Actores, procesos, flujos y repositorios. Diagrama de flujo de datos (DFD). Niveles de un DFD.
4. Pruebas (Testing) de sistemas orientados a objetos.

Definición del proceso de pruebas. Barreras psicológicas, sociales y culturales. Etapas de prueba:
1. Pruebas caja blanca y caja negra de métodos de clases.
2. Pruebas unitarias de clases.
3. Pruebas de integración,
4. Pruebas de validación de requerimientos
5. Pruebas del sistema.
Planificación, ejecución y evaluación de las etapas de prueba.
5. Análisis orientado a objetos.

Requerimientos del usuario y requerimientos del patrocinante. Requerimientos funcionales y no funcionales. Uso de los modelos en el proceso de análisis.
6. Diseño orientado a objetos.

Criterios de diseño: encapsulamiento, reutilizabilidad, eficiencia, seguridad y flexibilidad. Uso de los modelos en el proceso de diseño. Patrones de diseño: Compuesto, Estrategia, Decorador, Fábrica Abstracta, Comando, Iterador.

3.3 Temas afectados del programa tradicional

1. Diseño estructurado.

El método de diseño estructurado toma como punto de partida un diagrama de flujo de datos (DFD) y, utilizando heurísticas para reducir el grado de acoplamiento y aumentar el nivel de cohesión, permite elaborar un diagrama jerárquico de  estructura  para cada uno de los programas en un sistema de programas. El diagrama de estructura indica la jerarquía entre las rutinas que conforman cada programa.
Este tópico fue eliminado.
2. Estrategia de programación en ambientes tipo Unix.

Tradicionalmente se introducía la noción de filtro y flujo (filter y pipe) para mostrar una sencilla arquitectura tipo pipeline para un sistema de programas. Este tópico también fue eliminado.
3. Inspecciones formales.

Las inspecciones formales son métodos grupales de validación de los productos asociados al desarrollo de un software, Complementan los métodos más conocidos de pruebas (testing) y se basan en inspeccionar manualmente los productos en base a listas  de revisión (checklists). Este tópico no fue cubierto por cuanto no hemos elaborado las listas de revisión para software orientado a objetos.
4. Control de configuraciones.

Este tópico también fue eliminado. Normalmente ocupaba una sesión (dos horas) de clase.
5. La dimensión no técnica del desarrollo del software.

La cobertura de este tópico se redujo. Técnicamente el tópico se cubría en una sesión de clase, pero su peso era más importante por cuanto formaba la tarea final del curso. Sin embargo, la organización del Taller de Sistemas de Programas en equipos de diez a veinte personas, obligó a que algunos de los puntos de este tópico salieran a relucir en el desarrollo del Taller.

4. Evaluación del curso

La evaluación de Sistemas de Programas se basó en seis tareas:
 

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.
 

4.1 ¿Por qué tareas y no exámenes?

Idealmente cualquier asignatura sobre diseño debe requerir de sus estudiantes  que creen y evalúen diseños. En el caso de la asignatura de Sistemas de Programas, donde se diseñan artefactos de mediana envergadura, el mecanismo de un exámen in situ de dos horas pueden evaluar cuán rápido puede un estudiante crear analizar requerimientos, crear diseños o planificar pruebas pero no cuan bien puede hacerlo.
 

4.2 ¿Por qué tantas tareas?

Por supuesto que el problema que surge es el volumen de trabajo de corrección que ello genera para el profesor de la asignatura. Para reducir este volumen se hicieron algunas experiencias no convencionales de corrección basadas en ideas del Prof. Nagib Callaos:

1. Las tareas se entregaban sólo con el número de carnet del participante;
2. Las tareas de una sección se corregían por los estudiantes de la otra sección;
3. La corrección se realizaba en una sesión de clase como parte de la discusión de soluciones;
4. Despues de la corrección el profesor de la sección revisaba las correcciones para ajustar las notas en caso que éstas no correspondieran al trabajo presentado.

4.3 ¿Por qué tareas en grupo?

Por supuesto que las tareas en grupo también reforzaba el objetivo de aprender a trabajar en equipo y daba justamente la oportunidad de discusión de alternativas de diseño o enfoques.
 

5. Resultados del curso

• 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 pa'ginas WWW;
• Java;
• Tecnología orientada por objetos;
• El efecto Hawthorne.

5.1 Logros

1. Salido motivados para trabajar en equipos medianos (4-15 personas) y con una importante experiencia positiva al respecto, básicamente gracias a la excelente labor realizado en el Taller de Sistemas de Programas. En este sentido el experimento de incrementar el número de estudiantes por equipo de trabajo en el Taller debe considerarse muy exitoso.
2. Obtenido un dominio mucho más sólido en tecnología orientada a objetos de lo que han obtenido en el pasado --los comentarios futuros de otros profesores que trabajen con este grupo de estudiantes será valioso como confirmación de esta opinión. De nuevo, esto no hubiera sido posible sin lel sacrificio de otros tópicos para poder dedicar el trimestre completo a técnicas de Ingeniería de Software Orientada a Objetos.
3. Obtenido mayor claridad sobre el rol de las asignaturas formales y las cadenas (Sistemas de Operación, Interfaces con el Usuario, Bases de Datos, Control de Proyectos y Sistemas de Información) en su formación. La tecnología orientada a objetos en general y el método OMT en particular establecen vinculaciones más fuertes con asignaturas que tradicionalmente se mostraban más independientes.
4. Mejorado su enfoque de cómo desarrollar software de envergadura mediana. No me atrevería sin embargo a indicar que la intuición (insight) que han desarrollado es superior a la desarrollada en cursos anteriores --ciertamente no la siento inferior.

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

• "Diseño y planificación de todas las partes del software".
• "Aprender algo del desarrollo sistemático de software de mediana escala."
• "Haber concientizado mi rol futuro [como] ingeniero... la aplicación de las herramientas de diseño... la evaluación del curso, tan fuerte como un taller pero con más dudas sobre qué hacer."
• "Aprender a trabajar en un equipo numeroso."
• "Aprender a realizar páginas web...[en la Teoría] aprender el valor que tienen las fases de diseño y testing."
• "Aprender a diseñar un programa grande".
• "El diseño de clases."
• "El estudio de los diferentes modelos que se pueden utilizar en el desarrollo de software."
• "Modelo estático, modelo de uso, patrones.... [En el taller trabajar] en equipos con gente desconocida (simulación de trabajo real)."
• "Modelos de uso, dinámico y estructural."
• "Casos de uso".
• "La parte de patrones..."
• "Los modelos dinámicos."
• "Casos de uso y modelo dinámico."
• "La parte del modelo estructural."
• "Programación orientada a objetos".
• "La forma de evaluar."

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

• "El trabajo en grupo."
• "La experiencia de trabajar en un equipo tan grande y con gente nueva... En realidad me pareció que el curso fue muy completo."
• "El manejo de las etapas que hay que seguir para manejar software".
• "El diseño orientado a objetos"
• "El modelo estructural y el modelo dinámico"
• "Aprender a diseñar... ver los problemas en forma más abstracta y lograr solucionarlos más metodoógicamente."
• "Todo me pareció útil".
• "Aprender a diseñar un programa, trabajar en equipo."
• "La aplicación de modelos, patrones y el análisis de dónde pueden estar los posibles errores de un programa."
• "Las formas de diseñar las pruebas."
• "El modelo de clases [sic]".
• "Aprender una metodología ingenieril para computación."
• "Herramientas formales para el diseño, desarrollo y prueba del software."
• "La metodología OMT (modelos) y las herramientas de programación orientada a objetos. No considero que ningún aspecto haya sido inútil."
• "La parte de diseño en general y de testing".
• "La programación orientada a objetos y la programación en Java."
• "La programación orientada a objetos, pasos a seguir al desarrollar un sistema."

5.2 Contratiempos y fallas

En buena medida el problema radica en el texto (y la metodología) escogida. Considero que el texto de Rumbaugh et al es muy avanzado para el nivel del estudiante y más cónsono con un curso de cuarto o incluso quinto año de la carrera. Veamos los problemas que surgen, tópico por tópico:

1. El modelo estructural.

Manejar con propiedad el modelo estructural propuesto en OMT se beneficiaría enormemente de que los estudiantes ya dominaran el modelo E-R de Bases de Datos. De hecho el modelo E-R puede verse como un modelo más simple que el estructural y como tal obliga al estudiante a clarificar conceptos importantes como relaciones sin que se vea obligado a hacer distinciones (que pueden ser bastante sutiles) entre asociaciones y agregaciones. El riesgo que se corre al introducir el modelo estructural en Sistemas de Programas antes del modelo E-R en Bases de Datos es que se confunda al estudiante y se sienten obstáculos para una comprensión cabal en Bases de Datos. Para rematar, opino que la comunidad que trabaja en bases de datos relacionales es en general mucho más formal y cuidadosa en su manejo conceptual que la comunidad que trabaja en tecnología orientada a objetos, lo que incrementa la posibilidad de sembrar confusiones futuras en el estudiante. Al respecto, será instructivo e importante ver el desempeño de este grupo de estudiantes en la asignatura de Bases de Datos.
 
2. El modelo dinámico.

El problema es análogo al del modelo estructural. En este caso OMT maneja la noción de autómatas anidados concurrentes cuando en el mejor de los casos, los estudiantes cursan en paralelo con Sistemas de Programas, la asignatura Traductores e Interpretadores donde les introducen la noción de autómata finito (secuencial). De nuevo la técnica de OMT es mucho más rica (anidación, eventos comunes, acciones asociadas a transiciones, concurrencia, acciones asociadas a estados) y en efecto puede estarse dando un fenómeno de estarle exigiendo al estudiante que "corra antes que haya aprendido a caminar."
 
3. El modelo de uso.

El modelo de uso se beneficiaría de un dominio de las nociones de eventos y de manejadores de eventos que normalmente los estudiantes obtienen despues de haber cursado Sistemas de Operación  e Interfaces Gráficas. Resulta evidente que para una proporción no despreciable de estudiantes, la narrativa informal de los casos de uso resulta demasiado soft ("paja" en su jerga). Hay que destacar que el modelo de uso no forma parte de OMT pero se incorporó al curso por lo cómodo que resulta comenzar un desarrollo orientado por objetos por este tipo de modelo relativamente informal.
 
4. El modelo funcional.

En mi opinión el modelo funcional resulta singularmente inútil y corresponde a uno de los pocos errores cometidos en OMT. Las razones que subyacen esta afirmación pueden encontrarse haciendo clic aquí.
 
5. Análisis orientado por objetos.

En el curso se trató de cubrir este tópico de la manera más escueta posible, concentrándose en aquellos aspectos necesarios para sentar la base del proceso de diseño y evitando cubrir aspectos no menos importantes usualmente trabajados en Sistemas de Información referentes a los mecanismos de interacción entre el analista, el usuario y el patrocinante, cómo involucrar a todos los interesados en el sistema, el manejo del cambio organizacional, la estimación del costo y esfuerzo del desarrollo y la implantación y finalmente el análisis de factibilidad del proyecto. En este sentido, el texto de Rumbaugh sólo adolece del  problema que no hace esfuerzos por identificar la frontera del sistema, identificar las fuentes de volatilidad de requerimientos e identificar requerimientos no funcionales, todo lo cual tiene un gran impacto en el proceso de diseño. En este sentido el capítulo que dedica al análisis se queda muy corto al analizar un sistema de cajeros automáticos, cuando para simplificar su tratamiento obvia completamente los aspectos de tiempo de respuesta, seguridad y resguardos.
 
6. Diseño orientado a objetos.

Una vez identificados los diversos modelos de OMT, Rumbaugh et al sugiere que los primeros tres pasos de diseño consisten en la selección de la arquitectura del software, la identificación y estructuración de la concurrencia existente en el sistema a desarrollar y la escogencia del enfoque para manejar los repositorios de datos. Ante estas recomendaciones el profesor de Sistemas de Programas se  topa con los siguientes problemas:
 
• El estudiante no conoce arquitecturas de software . De hecho las primeras dos  arquitecturas (por capas y en pipeline) las  verá en Sistemas de Operación, la arquitectura típica basada en manejadores de eventos la verá en Interfaces Gráficas y la arquitectura basada en reglas la verá en Lenguajes de Programación.  Es decir el tema es claramente prematuro.
• El estudiante no tiene aún nociones de concurrencia, las que se obtienen en Sistemas de Operación.
• El estudiante no tiene ningún conocimiento de cómo manejar volúmenes de datos. Estas nociones se imparten en Bases de Datos.
En resumen, para el estudiante muchos de los elementos de diseño general recomendados por Rumbaugh et resultan decididamente prematuros o desconocidos. Ello obliga al docente a obviar estos temas, lo cual deja una sensible falta de clausura en el tema  de diseño.
 
7. Pruebas orientadas a objetos.

El texto de Rumbaugh et al no trata el tópico de elaboración de pruebas ni inspecciones para software orientado a objetos. Decidimos (incorrectamente) basarnos en el libro de Pressman ("Software Engineering: A Practitioner's Approach", 1997) . El material del libro es insuficiente para el nivel de cobertura adecuado al tema. Tuve que adaptar el material dictado en cursos anteriores a software orientado a objeto, lo que me llevó a proponer dos métodos nuevos  para la generación de casos de prueba.
 
8. Patrones.

Un tema fascinante al que no le pudimos hacer justicia en esta versión experimental del curso. El problema pedagógico del tema es que se suele presentar como un catálogo exhaustivo y árido; el desafío estriba en hacer atractivo este material. Lamentablemente el material sobre patrones no fue utilizado en el Taller de Sistemas de Programas de modo que sólo se cubrió en la penúltima semana del trimestre, coincidiendo por los demás con un momento muy álgido del trimestre. Sólo es a raiz de la última tarea (entregada en la doceava y última tarea del trimestre) donde a los estudiantes se les pide que rediseñen sus trabajos del taller usando patrones es que la mayoría de los estudiantes palpa la importancia del tema.

1. Dificultades para cubrir ciertos tópicos en teoría (Sistemas de Programas) antes que fueran requeridos en el Taller de Sistemas de Programas.

 
2. Los estudiantes no hacen uso de su bagaje formal, aún cuando les hace falta. Esto salió a relucir con particular claridad en la tarea dedicada al tópico de pruebas donde los errores comunes incluyeron:

1. No distinguir entre un grafo y un multigrafo ( visto en la asignatura Algoritmos y Estructuras III);
2. Ignorar la importancia del orden en una secuencia de aplicación de métodos de generación de pruebas (Estructuras Discretas I);
3. Ignorar la posibilidad de encontrar bases alternas linealmente independientes con propiedades más cercanas a las buscadas (Estructuras Discretas II);
4. Incomprensión de las implicaciones de imponer una precondición a una rutina (Algoritmos y Estructuras II);
5. Olvidar las características básicas de la representación punto flotante (Organización del Computador).
1. Orden inadecuado de los modelos. El modelo de uso debe preceder a los demás.

 
2. Falta de ejemplos en software. Hay que enriquecer los ejemplos tratados en clase.

 
3. Lo temprano del horario del curso (a partir de las 7:30 am). Menciono este aspecto por lo tarde que entraban los estudiantes a las sesiones de clase. Según dicen los estudiantes, este problema tiene dos causas principales:

 
1. El servicio de transporte de la USB, que efectivamente parece tener cada vez menos unidades que llegan antes de las 7:30 am.
2. Trasnochos.

 
4. Tiempo perdido en la universidad. Varios estudiantes se quejaron que comenzaban clases a las 7:30 am con Sistemas de Programas y culminaban a las 7:30 pm con Traductores e Interpretadores, obliga'ndolos a permanecer hasta seis horas en los predios de la universidad sin clases y con pocos o nulos recursos computacionales.

• La primera asignatura (Sistemas de Programas propiamente dicha) es una introducción a técnicas de programación, diseño detallado (patrones)  y pruebas unitarias para software mediano orientado a objetos. Esta asignatura precede y motiva las asignaturas relacionadas de Sistemas de Operación, Interfaces Gráficas, Bases de Datos, Sistemas de Información y Control de Proyectos. Esta asignatura integra las asignaturas del segundo año de la carrera y motiva las de tercero y cuarto.

 
• La segunda asignatura (Ingeniería de Software) entraría más de lleno en tópicos más avanzados de requerimientos, arquitecturas de software, relación hardware-software, uso de CASE,  desarrollo y uso de frameworks de objetos, planificación, estimación y control de proyectos de desarrollo, pruebas de integración, validación de requerimientos y de sistemas y mantenimiento. Es una asignatura posterior a las indicadas en el párrafo anterior. Esta asignatura (o cadena de asignaturas) integrarían esas asignaturas actualmente de tercero y cuarto año.

A continuación resumiré algunos de los resultados obtenidos en la encuesta de formato libre a los estudiantes.
 

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

• "Algunas veces la teoría estaba atrasada en relación al taller..."

• "El área de patrones, ya que al principio fue un poco confuso."
• "Los patrones (tal vez se debe a que se dio en las últimas semanas de clase)".
• "No me gustó patrones."
• "Los patrones y errores se dieron muy superficialmente."
• "La parte del modelo funcional."
• "La generación de pruebas con el método ciclomático."
• "Las metodologías de pruebas."
• "Los casos de pruebas."

• "ES MUCHA MATERIA PARA UN SOLO TRIMESTRE".
• "Existen demasiados contenidos para un trimestre."
• "El contenido del curso me parece extenso y no asimilable en un trimestre."
• "Falta de tiempo. El curso fue muy apresurado para el interés que despierta (sería ideal si sólo estuviéramos viendo este curso)."
• "O sobra materia o falta tiempo."

• "El horario de clase."

• "La evaluación fue bastante pesada, ya que se realizaron cinco tareas extensas y difíciles."
• "La evaluación del curso, tan fuerte como un Taller, pero con más dudas sobre qué hacer."
• "Densidad y complejidad de las tareas."

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

• "En cuanto a lo menos útil, es un poco difícil , ya que todo el curso es útil de una u otra forma."
• "Todavía no lo sé".
• "Todo me pareció útil".
• "No considero que ningún aspecto haya sido inútil."

• "El modelo funcional."
• "Me pareció inútil el modelo funcional para efectos del curso."
• "No le he encontrado utilidad a los patrones... Sería agradabl expandir la información sobre los patrones."
• "El estudio de los patrones ya que no se utilizaron,.,, Debe expandirse el uso de patrones."

• "El diagrama de uso."
• "Los casos de uso parecen poco útil, no sé si porque no se ahondó mucho en el tema o porque siempre se manejó el mismo ejemplo."

 

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:

• "Este curso me pareció super-estimulante porque se le ve el queso a la tostada en todo momento; eso se refleja en el gran esfuerzo que pusimos todos."
• "Aunque sí fue un poco extenso, el curso fue motivante ya que uno descubre nuevos aspectos de la carrera".
• "Sí es motivante."
• "El curso es muy motivante y ha sido uno de los cursos de mi carrera que más me ha gustado."
• "Me abrió curiosidad sobre la materia futura, el campo laboral y las especializaciones que se pueden tomar."
• "Motivante, ahora puedo diseñar mis propios programas sin hacerlo a los golpes."
• "El curso es totalmente motivante."
• "Muy motivante"
• "Motivante."

• "En un punto medio pues es cierto que la densidad de materia nueva perturba, pero motiva el hecho de que estamos conociendo cosas nuevas e interesantes que nos van a ayudar más adelante."
• "De todo un poco. Motiva en el sentido de ser un computista. Desmotiva el gusto por el diseño al tener tantas asignaciones sobre lo mismo."
• "Ni muy motivante, pero tampoco desmotivante. Es un curso base muy importante. Nos da una primera visión acerca de lo que realmente es ser ingeniero de computación."
• "La densidad de la materia es la que lo desfavorece. ¿Sería muy radical convertirla en dos materias?

• "Desmotivante debido al gran contenido de materia nueva que no se puede asimilar completamente bien."

5.2.4 ¿Qué opina de la forma de evaluar el curso? ¿Lo modificaría? ¿Cómo?

• "Por el tipo de curso me pareció muy bien... lo modificaría tal vez mandando más tareas cortas donde se vaya más por etapas que tratar de englobar cada tema en una tarea."
• "Me parece que la forma de evaluar es muy adecuada, el dividir en items de poco peso porcentual... relaja la presión existente (en comparación con un parcial). Además permite investigar más y madurar mejor las ideas para solucionar las tareas".
• "Me gustó mucho porque te mantiene al día y no se acumula la materia pero hay que mejorar los enunciados."
• "Estoy de acuerdo con las tareas, no lo modificaría ya que me parecen que las tareas incentivan a los estudiantes. Sólo que debería haber una mejor planificación de la tarea."
• "La forma de evaluar el curso con tareas me parece perfecta porque hay que pensar bastante sobre un modelo para que quede más o menos."
• "Me parece la forma más adecuada. Por el tiempo que necesitan las tareas recomendaría más personas en la realización (3 o 4 personas por tarea).
• "Para el alumno es más cómodo el esquema de las tareas... La evaluación de la práctica [Taller] podría incluir actividades más dinámicas en clase (que no sean sólo entregar avances de proyectos)".
• "Me parece excelente, con las tareas se explota la posibilidad de aplicar la teoría a la vida diaria, lo cual es muy importante, pues nos permite establecer la utilidad de la misma. Los exámenes son un instante un día ...[despues] se olvida lo que se estudió para él. Con las tareas sucede lo contrario, pues realizarlos requiere análisis y estudio y siempre queda algo. Un aspecto a modificar serían los enunciados, estos deben ser más claros y definitivos."
• "Es ventajoso, en el sentido que el estudiante está al día con la  materia. Aunque es mucho más forzado porque todo el tiempo hay que entregar las tareas... Creo que se aprende más haciendo varias tareas que presentando dos o tres parciales."
• "Muy buena. Las tareas permiten que el alumno asimile el contenido de forma responsable.. Motiva a la investigación. Sin embargo la complejidad debería ser menor. Opino que las tareas deberían tener más contenido que mayor dificultad."

• "Modificaría el tema de las tareas para hacerlas más llamativas y acortaría la longitud de las mismas (¡son muy trabajosas!)
• "La evaluación por tareas es buena e ideal para el curso [nota mía: este es el mismo estudiante que indica que ¡lo que menos le gusta del curso es la complejidad y densidad de las tareas!] Las mismas deben ser más cortas y no se les debe cambiar el enunciado [nota mía: una queja reiterada debido a la modificación (sustancial) del enunciado de la Tarea 3].... Algunas preguntas de las tareas no se ajustaban al nivel de las clases."
• "Un poco desmotivante porque nos aplicábamos al hacer las tareas y las notas obtenidas no eran las esperadas."
• "Sería mejor colocar menos tareas, ya que las mismas consumen mucho tiempo."
• "No estoy de acuerdo con tantas tareas o que exijan tanto en cada una; deben comenzar antes y tratar de sincronizar con otros cursos de manera que no sea tan destrozante el trimestre. Integrar Scrabble (el proyecto del Taller) con [las tareas de] la teoría, al principio fue desesperante, pues organizar 20 personas del Taller que además no necesariamente ven la Teoría, resulta complicado. Exámenes es imposible. Lo más conveniente es tareas en parejas, menos tareas, menos exigencias en las tareas y un estilo de preparaduría que sirva para practicar directamente diseño, sin ser evaluado."

• "Creo que debería cambiar... [Otra] cosa que afecta psicológicamente es el hecho de llamarse tareas (una tarea me luce a una pequeña asignación fácil) y no se le toma la verdadera importancia. Quizás una opción sea hacer por lo menos dos exámenes (de bajo peso) y algunos informes grandes. La evaluación de las tareas son muy subjetivas."

6. Conclusiones y Recomendaciones

1. El nuevo contenido del curso cumple con el objetivo general de las asignaturas Sistemas de Programas y Taller de Sistemas de Programas.

 
2. El contenido de Sistemas de Programas ha sido modificado, eliminándose los temas de:
1. Diseño Estructurado,
2. Estrategia de programación en ambientes tipo Unix,
3. Inspecciones Formales y
4. Control de Configuraciones.
La cobertura del tópico de la dimensión no técnica del desarrollo de software fue reducido.
 
3. El contenido del curso tomó es más actualizado al enfocarse hacia la ingeniería de software orientada a objetos. Se extendió considerablemente la cobertura de programación orientada a objetos y diseño orientada a objetos. Se introdujo:
1. Elementos de análisis orientado a objetos,
2. El modelo estructural,
3. El modelo dinámico,
4. El modelo de uso,
5. Pruebas unitarias de clases.

 
4. El modelo funcional no encaja bien con los otros modelos orientados a objetos.
 
5. El contenido del nuevo curso es demasiado denso en términos de cantidad de material nuevo presentado.

 
6. Algunas de las técnicas se introducen de manera prematura puesto que  en asignaturas posteriores a Sistemas de Programas se introducen versiones menos sofististicadas de las mismas. Este claramente es el caso del diagrama estructural de clases y de los autómatas anidados concurrentes.

 
7. El orden de cobertura de tópicos no fue el más adecuado.

 
8. El libro de texto escogido (Rumbaugh et al) es demasiado avanzado para el curso, muestra defectos en algunos de sus ejemplos y carece de tópicos importantes como el modelo de uso y los patrones.

 
9. La evaluación en forma de seis tareas fue considerada positiva tanto por los profesores como por los estudiantes, a pesar de ciertas dificultades técnicas con el volumen de corrección requerido, el nivel de dificultad y trabajo exigido con los estudiantes. Una asignatura de diseño sólo puede evaluarse con tareas de diseño.

 
10. Hacen falta más ejemplos de diseño y software orientado a objetos que ilustren los conceptos vistos.

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

1. El enfoque orientado a objetos de la asignatura debe conservarse, realizando ajustes adicionales respecto al método de desarrollo más idóneo para el nivel de la asignatura y cambiando el orden de los tópicos .
2. Debe explorarse la posibilidad de abrirse una cadena en Ingeniería de Software para descargar el material más avanzado que se trabajó en esta instancia de Sistemas de Programas.
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. La cantidad de trabajo que exige el Taller a los estudiantes es mayor que el exigido por Sistemas de Programas. Esto debería reflejarse en el creditaje asociado a cada asignatura.
5. El contenido de la asignatura (y de la cadena) debe ajustarse 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. MIentras se ajusta el contenido de la asignatura, ésta debe permanecer previa a Bases de Datos.
7. Debe introducirse con más cuidado y en más tiempo la programación orientada por objetos. En particular debe adquirirse un mayor sentido de la bondad del  diseño de una clase. Como ejemplos puede incluirse la distinción entre la clase Date y la clase Day que se presenta en "Core Java", el libro de G. Cornell y C. Horstmann (Prentice-Hall, 1996) así como más ejemplos de librerías como Java Foundation Classes o su equivalente.
8. Introducir el modelo de uso como punto de partida del análisis/diseño. Hay que evaluar la posibilidad de incluso enseñar a usar este modelo pero no a construirlo, tal como se hacía con los DFD en la versión tradicional de la asignatura.
9. Simplificar el modelo estructural. ¿Es posible no distinguir entre asociación y agregación? ¿Es conveniente relajar la noción de asociación? C. Larman ("Applying UML and Patterns") muestra una posible simplificación.
10. Adoptar la notación UML.
11. Introducir el modelo de colaboración y eliminar el modelo funcional.
12. Estudiar si es factible eliminar el modelo dinámico de este primer curso. Si no es factible, ¿puede al menos eliminarse la concurrencia?
13. Profundizar en formas de generar pruebas para software orientada a objetos. Las formas vistas son superficiales y poco satisfactorias.
14. Incluir inspecciones formales para desarrollos orientados por objetos.
15. Evaluar la asignatura más idónea para introducir y trabajar la noción de arquitecturas de software.
16. Reforzar los tópicos relacionados con el trabajo en equipo y con la dimensión no técnica de los desarrollos. Para ello es conveniente que los profesores de las asignaturas (particularmente del Taller) tomen cursos en el área de Dinámica de Grupos.
17. Incrementar y adelantar el tópico de Patrones. Ello no va a ser fácil y debe considerarse como el desafío docente más importante por resolver en la asignatura.
18. Introducir el uso de CASE en el Taller de Sistemas de Programas.
19. Adoptar otro libro de texto. Sugiero probar el libro de C. Larman ("Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design"), a pesar de sus carencias explícitas en el área de pruebas de software.
20. Considerar seriamente la posibilidad de reducir el número máximo de estudiantes por sección de Sistemas de Programas con el objeto de poder trabajar mejor el componente práctico de diseño.
21. Mejorar y enriquecer los ejemplos usados en el curso.
22. 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.
23. 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.

Agradecimientos

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.

Finalmente, quisiera reconocerle  al Dr. Kurt Stirewalt y a su ayudante docente Gopal Kandalurajaram la inspiración que nos brindó la descripción www de su curso Software Engineering  --en particular a lo que se refiere a incorporar OMT y  a manejar equipos tan grandes de estudiantes.
 

áéíúó
ñ
ü¡¿Ñ

Esta página fue creada entre el 9 de abril y el 15 de abril de 1999.

Ultima actualización: 16 de abril de 1999.

Para comentarios favor contactar al Profesor Alejandro Teruel