Conforme aumenta la complejidad y el tamaño del proyecto, la coordinación se dificulta debido al incremento en la comunicación entre los ingenieros de software, administradores y clientes (Fairley, 1985; Kraut y Streeter, 1995). En el ámbito educativo, las investigaciones realizadas indican que los estudiantes graduados de programas de licenciatura entienden poco el significado de "programar en grande"; es decir, aplicar los principios de la ingeniería de software al desarrollo de un producto por un equipo de personas, durante el cual la coordinación efectiva entre los participantes permite lograr un sistema de software exitoso (Upchurch y Sims-Knight, 1998).

Se utilizan diversas estrategias en la enseñanza de la ingeniería de software. Algunas de ellas se basan sólo en la revisión bibliográfica, sin llevar a la práctica el conocimiento adquirido en un proyecto (Tomayko, 1987). Otras se basan en el trabajo en equipo, y su objetivo central es que el estudiante se ejercite en el desarrollo de un producto para un cliente real, tome decisiones de acuerdo a las opciones o recursos disponibles y se enfrente con los aspectos de comunicación y coordinación típicos del trabajo en grupo (Upchurch y Sims-Knight, 1997).

Un problema recurrente es que el éxito de los proyectos en estos cursos depende de la habilidad y experiencia del instructor para dirigir proyectos. Es probable que distintos instructores logren resultados diferentes utilizando el mismo modelo; o que el mismo instructor, con otro grupo de estudiantes, obtenga resultados dispares. Además, en algunos de estos cursos sólo se presta atención a las características de una buena arquitectura e implantación, sin integrar los aspectos de aseguramiento de la calidad ni administración. Estos problemas sugieren que muchos de los proyectos de ingeniería del software sufren de deficiencias en el proceso de desarrollo de software utilizado por el instructor (Collofello, Kantipundi y Kanko 1994).

El proceso de desarrollo de software se puede definir como el conjunto de actividades, métodos, prácticas y transformaciones que los individuos emplean para desarrollar y mantener el software, así como los productos asociados (Paulk, M. C., Weber, C. V., Curtis, B. y Chrisis, M. B., 1995). Un proceso definido y efectivo disminuye el esfuerzo en el desarrollo de un producto de software, y aumenta la productividad del grupo de desarrollo (Clark, 2000). De hecho, el modelado y la ejecución del proceso de desarrollo de software son una áreas principales de la investigación en ingeniería de software (Maurer y Kaiser, 1998), y su propósito es proponer soluciones a los problemas en el contexto organizacional con base en la explotación de las tecnologías de coordinación e integración (Warboys, Kawalek, Robertson y Greenwood, 1999).

En la búsqueda de la calidad en la enseñanza de la ingeniería de software basada en procesos, se han utilizado diversos enfoques. Por ejemplo, en ciertos cursos, se entrega a los estudiantes el documento de especificación de requerimientos. El propósito es que realicen el trabajo que se señala, cubriendo todas las etapas del desarrollo del producto, a partir del seguimiento de algunos procesos descritos de manera textual (Upchurch y Sims-Knight, 1998). Otros investigadores han modelado el proceso de desarrollo de software utilizando técnicas orientadas a objetos, con el propósito de comprender la complejidad del proceso paso por paso (Oktaba e Ibargüengoitia, 1998). También, se utilizan estándares y prácticas aceptados por la comunidad como base para introducir el proceso de desarrollo de software (Robillard,1998; Jaccheri y Lago, 1997; y Mayr, 1997). Además, algunos expertos recomiendan la integración de procesos y el trabajo en grupo en el diseño de planes de estudios relacionados con la ingeniería de software (Bagert, Hilburno, Hislop, Lutz, McCracken y Mengel,1999).

En el Centro de Investigación Científica y de Superior de Ensenada (CICESE), se imparte la asignatura obligatoria de Ingeniería y metodología de la programación, dentro del programa de maestría en Ciencias de la Computación. Las características del curso permiten tomarlo como referencia para realizar un proyecto de mejoramiento de procesos. En este artículo, se describe la aplicación de las técnicas de modelado de procesos en la parte práctica del curso de ingeniería de software para identificar las fortalezas y debilidades del proceso de desarrollo utilizado, y las acciones que se siguieron para mitigar los problemas detectados. En la segunda sección se señala la metodología que sirvió como base para hacer visible el proceso, evaluarlo y proponer mejoras. En la tercera sección se describen los pasos seguidos en el estudio del proceso de desarrollo, al tomar como referencia las etapas de un proyecto de mejoramiento de procesos y adaptarlas a las necesidades específicas del caso de estudio. La cuarta sección reporta las características generales de la sesión de laboratorio del curso, en donde los estudiantes desarrollan un sistema de software y resume las deficiencias detectadas en la coordinación del trabajo entre los participantes del curso. En la quinta sección se indican las acciones que se tomaron para resolver los problemas detectados. La sexta sección expone los resultados obtenidos al poner en marcha los procesos mejorados. Finalmente, se describen las líneas que se seguirán en el curso para el mejoramiento de procesos y las conclusiones del trabajo.

En el modelado de procesos se contemplan cuatro aspectos: funcional, desempeño, organizacional e informativo (Curtis, Kellner y Over,1992). En el aspecto funcional se consideran las actividades del proceso que están siendo ejecutadas y los flujos de entidades (documentos) más relevantes. En el aspecto de comportamiento o desempeño se presta atención al tiempo en que se realizan las actividades, así como al modo en que se efectúan (condiciones, secuencia e iteraciones). La vista organizacional del proceso se enfoca en el lugar físico, dentro de la organización donde se realizan las actividades y en la persona que tiene la responsabilidad de efectuarlas. Por último, el aspecto informativo aborda el aporte de los documentos en la coordinación y comunicación entre las funciones.

La descripción de un proceso puede tomar muchas formas y es posible usar un lenguaje gráfico para exponerlo. Los modelos gráficos ayudan a representar el proceso en estudio al disminuir la complejidad, propiciar un entendimiento común entre los participantes y permitir el estudio de alternativas (Miers, 1996); también, se pueden utilizar para influenciar, controlar y dirigir lo que acontece en el mundo real (Warboys et al. 1999). En el contexto organizacional, permiten la captura del comportamiento del proceso para su análisis posterior y también actúan como depósitos del conocimiento de la organización con el fin de facilitar el aprendizaje acerca de la organización y sus procesos (Ould, 1995).

La técnica para elaborar los diagramas del proceso de desarrollo de software en estudio fue la Role Activity Diagram (RAD). Esta técnica describe al proceso desde el punto de vista de roles (Ould, 1995). Quienes ocupan los roles ejecutan actividades y toman decisiones de acuerdo con las reglas de la organización; pueden realizar las actividades en paralelo y tener interacciones con otras funciones mientras progresa el trabajo con el fin de alcanzar las metas del proceso. Las acciones pueden incluir el uso o producción de información o documentos. En la mayoría de los casos, el proceso de modelado conduce a la identificación inmediata de opciones de rediseño (Miers, 1996).

El éxito del proyecto en el curso depende de la colaboración que se logre entre los estudiantes, en tanto que la coordinación de los esfuerzos que realiza cada uno de los participantes de acuerdo con su puesto, es esencial para cumplir las metas del curso. La investigación de las interacciones, actividades, puestos y documentos que se producen mientras se trabaja en el proyecto permite mejorar el proceso de desarrollo de software.

Tabla I. Etapas en el estudio del proceso de desarrollo de software y el mejoramiento de las actividades de la fase de análisis del proyecto

En la etapa de definición, se aborda el proceso de desarrollo de software como una unidad integrada de las actividades de aseguramiento de calidad, administración e ingeniería del producto. La investigación del proceso de desarrollo comienza a partir de que cada estudiante tiene asignado un cargo en el proyecto; y, termina, cuando se entrega un producto funcional al cliente. En la primera etapa del estudio, se determina el estado actual del proceso y se generan modelos de las actividades e interacciones de cada uno de los agentes. En la segunda etapa, se evalúa, proponen mejoras y se ejerce el proceso de desarrollo tomando como referencia los modelos generados en el rediseño de la fase de análisis de sistemas.

La etapa de captura y representación tiene como objetivo conocer el estado actual del proceso, para lo cual, se usan distintas fuentes de información. En el caso particular de esta investigación, se consideraron los documentos generados durante los proyectos de cursos anteriores, entrevistas a participantes en dichos proyectos y revisión de las notas del curso:

a. Documentación de proyectos realizados con anterioridad. Desde 1994 se ha impartido la asignatura metodología e ingeniería de la programación en el CICESE. Los proyectos elegidos fueron DASIS (enero a abril) y GENSIS98 (septiembre a diciembre). Ambos fueron realizados en 1998 por los estudiantes del primer año de la maestría. La decisión para tomar estos proyectos como base para modelar el proceso de desarrollo se debe a que la información generada se encuentra en un depósito de información electrónico accesible; los documentos están organizados por agentes y son los que están mejor documentados, ya que, a diferencia de los proyectos anteriores, en éstos se encuentra información del perfil de cada agente en el proyecto de software y los documentos generados durante el ciclo de vida del proyecto. Otro factor que se consideró fue la semejanza entre los proyectos que se realizaron, ya que la plataforma de desarrollo, métodos de análisis y diseño, y tipos de revisiones técnicas fueron los mismos. Además, el primer autor participó como estudiante en el proyecto DASIS; y en el segundo, como auxiliar en el proceso de desarrollo. La información de los proyectos corresponde a: 1) planeación estratégica (misión, visión, valores, reglas), ejercicio que se lleva a cabo al principio del curso; 2) descripción del perfil de cada agente (metas, actividades, relación con otros participantes, herramientas de apoyo y bibliografía); y 3) documentos asociados con el proyecto (requerimientos, especificación del software, diseño, módulos de código, manual de usuario, planes de trabajo de cada una de las funciones, minutas de reuniones técnicas, reportes de avance de actividades, entre otros).

b. Entrevistas semiestructuradas. Se preparó un guión para realizar las entrevistas a los estudiantes que ocuparon un puesto en los proyectos DASIS o GENSIS98. Se consideró el análisis del perfil de cada agente (inciso a), con información basada en la bibliografía de esta disciplina tecnológica y no en la experiencia práctica (esta investigación documental es realizada por los estudiantes al principio del curso). De los 28 estudiantes (14 en cada proyecto), se tomó una muestra de 10 estudiantes, cada uno de ellos tenía un puesto distinto. De esta manera, se contó con observaciones para cada uno de los 10 puestos disponibles en el curso. Las entrevistas se realizaron del 23 al 29 de julio de 1999. La duración de cada una fue aproximadamente de una hora. En ellas se investigó las actividades que en realidad fueron ejecutadas, su secuencia, los documentos generados, las herramientas utilizadas y las interacciones con otros puestos, con el fin de verificar y completar la información descrita en el perfil de cada agente. En estas entrevistas, también se preguntó por los problemas que enfrentaron al desempeñar sus actividades, así como sus sugerencias para mejorar la parte de laboratorio del curso.

c. Documentación teórica del curso. En este rubro, se analizó el material utilizado en la teoría del curso, las referencias bibliográficas y la secuencia de los temas, con el propósito de verificar que, en la parte de teoría, se traten los tópicos necesarios para llevar a cabo las actividades del laboratorio del curso. El tema que se revisó con un grado de detalle mayor fue el de análisis de sistemas, ya que éste es la base para el rediseño de procesos en esta investigación.

La captura y representación del proceso parte del análisis de las fuentes descritas en los párrafos previos y permite la generación de varios modelos para comprender el proceso de desarrollo vigente. Los diagramas de apoyo utilizados para enfocarse en las distintas perspectivas del proceso fueron: la imagen rica, cuyo propósito es tener una imagen detallada de la problemática (Warboys et al., 1999; Wastell et al., 1996); diagrama general del proceso de desarrollo de software, en el que se agrupan las actividades en las áreas de administración, control y desarrollo (Donaldson y Seigel, 1997); el diagrama de transición de estados, para identificar el comportamiento dinámico del proceso; y la matriz rol-actividad-documento con el fin de identificar las responsabilidades de cada puesto, las relaciones entre ellos y los documentos que se generan o utilizan en cada una de las actividades.

Se representaron en diagramas RAD la información depurada de las actividades efectuadas por cada uno de los agentes, la interacción que tuvo lugar entre ellos y los documentos o productos que se generaron durante el ciclo de vida del proyecto. El enfoque para representar el proceso tomó como referencia las actividades que ejecuta cada agente o puesto (Ould, 1995; Kawalek, 1994).

La evaluación y el rediseño del proceso se enfocaron a las actividades que se realizan en la etapa de análisis del ciclo de vida de un proyecto de software. Las razones para tratar con esta etapa se deben a que, por ser la primera fase del proyecto, los estudiantes aún no están familiarizados con el proceso que se utiliza. Además, un estudio realizado indica que se dedica mucho tiempo a esta fase del proyecto (34% en DASIS y 46% en GENSIS98) y se descuidan las actividades de codificación y pruebas de sistema (García Mireles y Rodríguez Jacobo, 2000).

Para evaluar el proceso de análisis, se tomó como referencia la bibliografía básica de ingeniería de software (Sommerville, 1995; Pressman, 1993; Fairley, 1985) y literatura especializada (Dorfman y Thayer, 1990; Ayer, 1992). Fue de especial interés la revisión de temas relacionados con la preparación de cuestionarios para las entrevistas, identificación y clasificación de requerimientos, contenido y formato de los documentos de requerimientos del cliente y especificación de software. Además, se analizaron los temas que corresponden a la administración de éstos, criterios de calidad aplicados en esta etapa del ciclo de vida del proyecto, y la relación de dichas necesidades con la planeación del proyecto y administración de configuración.

El rediseño del proceso fue resultado de la etapa anterior, y en él se presenta la información en diagramas RAD. En esta fase del proyecto de mejoramiento del proceso, se toma como referencia la etapa de análisis del ciclo de vida tradicional ("cascada") de un proyecto de software y se divide en tres partes, de acuerdo con los hitos de esta fase del proyecto y según las etapas de la administración de requerimientos: elaboración del documento de requerimientos, validación de los éstos por el cliente y elaboración de la especificación del software.

Los nuevos modelos generados para la etapa de análisis del sistema fueron presentados a dos estudiantes involucrados con estas actividades, quienes ocuparon los cargos de analista e ingeniero de control de calidad en los proyectos evaluados. Las pláticas informales que se llevaron a cabo con ellos (se realizaron a finales del mes de agosto de 1999 con una duración aproximada de 30 minutos) y tuvieron como fin validar la claridad y el rediseño completo del proceso. Se les explicó el propósito del modelo y el significado de cada elemento gráfico. De acuerdo con su percepción del proceso de desarrollo, indicaron que el modelo es adecuado.

El propósito de generar modelos es utilizarlos para ejecutar el proceso. Las mejoras al proceso de análisis se aplicaron en el periodo que comprende de septiembre a diciembre de 1999, en el curso ingeniería y metodología de la programación donde participaron 15 estudiantes de nuevo ingreso al programa de maestría. Se presentó una clase en referencia al proceso de desarrollo de software y se entregaron los modelos a todos los estudiantes para que se familiarizaran con las actividades relacionadas con el análisis de sistemas. Después de la clase, se entrevistó informalmente a tres de los estudiantes, directamente involucrados con las actividades de esta etapa (ingeniero de requerimientos, arquitecto del sistema e ingeniero de control de calidad). Al final del curso se preparó un cuestionario de opinión y se entrevistó a los participantes responsables del análisis en ese curso. El propósito es conocer el impacto del enfoque de procesos en el curso de ingeniería y metodología de la programación.

• La fecha de entrega del sistema por desarrollar se rige por el calendario escolar (aproximadamente 3 meses).
• Los estudiantes cursan otras asignaturas (tres, en promedio) mientras trabajan en el proyecto.
• Algunos estudiantes no han cursado con anterioridad materias relacionadas con esta disciplina tecnológica.
• La metodología de análisis y diseño orientada a objetos que se utiliza es Unified Modelling Language (UML).
• La plataforma de desarrollo para el sistema de software es el World Wide Web (WWW), por lo que es necesario familiarizarse con los lenguajes de programación enfocados a esta plataforma.
• Se requiere que los participantes generen un depósito de información centralizado en la plataforma WWW.
• Además, se proporcionan las facilidades para que utilicen el correo electrónico como apoyo a la comunicación.

Aunque el modelo del proceso de desarrollo de software se realizó con la información de la parte práctica del curso de ingeniería del software, las deficiencias detectadas también afectan la parte teórica. La actualización de la teoría incluyó cambiar el orden en que se imparten los temas, al tomar como referencia las etapas en que se lleva a cabo el proyecto de software e introducir el tema de ingeniería de procesos con, el propósito de preparar a los estudiantes para que comprendan los modelos que se les presentarán en las sesiones de laboratorio del curso.

Los resultados de las entrevistas y la evaluación de los modelos generados mostraron poca visibilidad en la fase de análisis del proyecto. Por tal motivo, se profundizó en la teoría de análisis de sistemas, y se indicaron los aspectos clave en la determinación de los requerimientos y la especificación, así como la administración de éstos durante el ciclo de vida del proyecto. Otro aspecto abordado en la teoría se refiere a los atributos de calidad que se revisan en los documentos producidos en la etapa de análisis y los tipos de revisiones técnicas que se pueden aplicar.

Finalmente, se proporcionó bibliografía actualizada y clasificada de acuerdo con el tema de estudio, con el fin de presentar y analizar los métodos y técnicas utilizados en las distintas disciplinas de la ingeniería del software. Para cada uno de los temas, se indicaron de dos a cinco referencias clave. Además, se incluye una lista de bibliografía de apoyo con el fin de utilizarse como una guía para que el estudiante conozca, con mayor profundidad, las actividades que corresponden al puesto asignado.

En la parte práctica del curso, la estrategia de mejora implicó rediseñar los procesos que corresponden a la etapa de análisis, en el ciclo de vida del proyecto, debido al impacto que tiene esta fase en el desarrollo del sistema de software. Con el propósito de verificar la precisión de los modelos generados, fueron validados por participantes en los cursos anteriores. En la nueva propuesta, las responsabilidades del analista fueron asignadas a los puestos de ingeniero de requerimientos y de arquitecto del sistema. La meta del primero es elaborar el documento de requerimientos, etapa en la que es indispensable la comunicación estrecha con el cliente y sus representantes, para identificar las necesidades que el sistema de software debe satisfacer; y la meta del segundo es proponer una solución a las necesidades del cliente, que sea representada en un lenguaje de análisis de sistemas (UML).

Las tareas que se realizaron durante la etapa de análisis del proyecto y las interacciones que se llevan a cabo entre los participantes permitieron generar los modelos actualizados para los procesos de elaboración del documento de requerimientos, validación de requerimientos y construcción de la especificación del sistema de software (véase Figura 2). Con la nueva definición de procesos, los estudiantes pueden entender mejor qué deben hacer, qué pueden esperar de sus compañeros y qué deben proveer. Los procesos están divididos en roles. Un rol involucra un conjunto de acciones que se llevan a cabo por un individuo o un grupo dentro de la organización. Además, un rol incluye la lógica que controla las acciones de acuerdo con las reglas de la organización. También, un rol tiene los recursos necesarios para lograr sus actividades (Ould, 1995).

Figura 2. Diagrama RAD para la elaboración del documento de requerimientos

Los productos que se generan (documento de requerimientos del cliente y especificación del sistema de software) tienen como función principal facilitar la comunicación entre el cliente y el grupo de desarrollo, guiar la creación y modificación de los productos de software, dirigir la planificación del proyecto y garantizar la calidad del sistema de software construido (Rombach, 1990). La creación de estos documentos brinda a los estudiantes la oportunidad de modelar un problema real de un cliente, y de enfrentarse a las cuestiones de la descripción del producto de software. Al hacerlo, se introduce a los participantes en los problemas asociados a las descripciones en lenguaje natural y la representación de las características del producto de acuerdo con la metodología de análisis de sistemas empleada (UML, en el caso de estos cursos). Durante la elaboración de estos documentos, se reconcilian conflictos e inconsistencias producidos en la comunicación entre el cliente y el grupo de desarrollo, así como los que se presentan entre los mismos miembros del grupo de desarrollo de software. Además, obliga a los estudiantes a trabajar en sus habilidades de lectura y comprensión (Upchurch y Sims-Knight, 1998).

Otro aspecto importante en el rediseño de procesos se refiere a las entidades (documentos) que sirven de entrada o salida para las actividades señaladas en los modelos (Curtis et al., 1992). La evaluación de los documentos utilizados en esta fase del proyecto permitió la elaboración de estándares para los documentos de requerimientos del cliente y la especificación del sistema de software. También, se desarrollaron las guías para realizar la primera entrevista con el cliente y la lista de atributos de calidad por revisar en el documento de requerimientos. Como lo indica Sommerville (1995), los documentos generados durante el desarrollo del proyecto de software son particularmente importantes, ya que es la única manera tangible de representar el software en las etapas tempranas de su evolución. Además, Humprey (1989) señala que la estandarización de los documentos utilizados en el proceso de desarrollo ayuda a reducir el problema de entrenamiento y facilita la verificación de los criterios de calidad acordados.

Un proyecto de modelado de procesos no termina con el rediseño del proceso, sino que se requiere entrenar a los usuarios de éste y evaluar el desempeño con los nuevos cambios. Además de incluir el tema de ingeniería de procesos en la parte teórica del curso, también se proporcionó asesoría a los estudiantes involucrados en la etapa de análisis, para resolver sus dudas respecto al uso de los modelos de procesos y documentos estandarizados. Sin el entrenamiento adecuado, los efectos de la actualización del proceso degradan su calidad, en lugar de lograr la meta de un proceso efectivo y eficiente (Sommerville, 1995).

Tabla II. Concentrado de frecuencias de la encuesta de opinión aplicada a los estudiantes (N = 3) sobre el enfoque de procesos en el curso de ingeniería y metodología de la programación

Como se puede observar, se obtuvieron resultados prometedores al utilizar el enfoque de procesos en el curso. La mayoría de las calificaciones se encuentran en las categorías "estoy de acuerdo" y "estoy totalmente de acuerdo". Es natural que existan diferencias en el grado de detalle entre el proceso de modelado y las actividades reales del proyecto. Caputo (1998) señala que la meta del mejoramiento de procesos no es crear un proceso perfecto, sino generar procesos que permitan mejorar el desempeño. De hecho, Warboys et al. (1999) hacen la diferencia entre proceso genérico y proceso adaptado. En el caso particular de este estudio, se puede considerar que el modelo utilizado tiene los elementos fundamentales para lograr las metas del proceso, pero debido a la naturaleza del curso de ingeniería del software, no está adaptado y asociado a individuos y máquinas para llevar a cabo el proceso ni a las características particulares del proyecto que realizaron los estudiantes. Esto podría ser una de las razones para que algunas preguntas fueran calificadas como "no estoy seguro".

Se requiere poner mayor atención a los documentos que se generan durante la etapa de análisis. Los resultados de la entrevista indican que falta claridad en la descripción de cada una de las partes del documento de requerimientos y especificación. También, indican que se puede integrar la herramienta para generar los diagramas en lenguaje UML con el procesador de textos para facilitar y automatizar la generación del documento de especificación de software.

a. Congruencia del modelo del proceso con las actividades reales del proyecto. Los estudiantes señalaron que los diagramas resultaron útiles como guía para conocer el trabajo que implica su puesto, porque les permiten visualizar, de manera simple, las actividades que están realizando y enfocar sus esfuerzos hacia una meta. El grado de detalle presentado en los modelos fue adecuado, ya que les brindó la facilidad para determinar las actividades que prosiguen sin necesidad de especificar una técnica particular para ejecutarlas. Los modelos presentados en el curso cumplen lo que establece Miers (1996) en el sentido de que una buena definición de proceso debe concentrarse en la esencia de éste, reflejando el mundo real y manejando la complejidad del mismo. Además, se ajustan a lo que indica Ould (1995), quien señala que una buena descripción del proceso será aquella que comunique detalladamente las actividades a quienes las efectuarán y que sea suficientemente precisa para permitir una evaluación de conformidad. También, como lo expresan Warboys et al. (1999), los RAD permiten la descripción de comportamientos complejos de una manera altamente legible y logran la captura apropiada de las reglas de la organización.

b. Estándares en el proyecto. Los participantes indicaron que los estándares fueron una buena guía para elaborar los documentos de requerimientos y especificación, y sirvieron de referencia en las revisiones de este tipo de productos. Este resultado constata lo establecido por Humprey (1989), en el sentido de que la estandarización ayuda a reducir el problema de entrenamiento. Sin embargo, sugirieron cambiar el orden de algunas secciones de los documentos para mejorar la presentación, y solicitaron un ejemplo escrito completo que sirviera de guía.

c. Capacitación. La clase teórica de procesos les permitió ubicarse en el contexto general de desarrollo de sistemas de software, aunque solicitaron que se les proporcionaran los modelos de proceso para cada uno de los puestos en la empresa. Consideraron que las asesorías fuera de clase permitieron exponer, de forma relajada, los aspectos difíciles en las actividades que estaban realizando y les sirvió para orientar sus esfuerzos en el desarrollo del sistema de software. Los participantes apreciaron la importancia de compartir información en un proyecto colaborativo e identificaron la necesidad de los procesos de software para guiar las prácticas del equipo y hacer visible el proceso. Se percataron de los costos y beneficios del trabajo en equipo y comprendieron que un proyecto de desarrollo de software no sólo es generar código en un lenguaje de programación.

Se observó que las técnicas de modelado de procesos son herramientas eficaces para hacer visible el proceso, permiten identificar la problemática particular de los proyectos de software analizados e identificar las áreas del proceso que son susceptibles de mejora. En esta investigación, los modelos aislaron las cuestiones relacionadas con la fase de análisis de sistemas, lo que facilitó la actualización de los tópicos en la sesión teórica del curso, y sirvieron de guía para rediseñar los procesos que pertenecen a dicha etapa del proyecto. Los modelos descritos contribuyen a que los estudiantes tengan una mejor comprensión de sus responsabilidades en el proceso y les permiten enfocar sus esfuerzos hacia las actividades que son significativas en el desarrollo del proyecto, esto les brinda autonomía al reducir el número de interacciones con el instructor. Los resultados preliminares, utilizando procesos rediseñados, sugieren que los modelos son una guía poderosa para entrenar a los participantes del proyecto.

Los modelos facilitan la colaboración entre los distintos miembros del grupo al determinar explícitamente los tipos de interacción que existen en cada etapa del desarrollo de un sistema de software. No es necesario que los estudiantes investiguen cuáles son las actividades que corresponden a sus puestos, ni con quién deben interaccionar durante el proceso, sólo deben preocuparse por comprender cómo realizar sus tareas y adaptarlas al proyecto de desarrollo de software en el que están trabajando.

Un segundo paso, conociendo las virtudes de estos modelos, es extenderlos a un ambiente de desarrollo distribuido, donde los estudiantes están en localidades geográficas diferentes. En este ambiente, la investigación se enfocará a las interfaces que deberán existir en el proceso, para que funcione de manera adecuada; además de recomendar herramientas de apoyo a la comunicación y coordinación.

Ayer, S. (1992). Documenting the software development process: A handbook of structured techniques. Nueva York: McGraw-Hill.

Bagert, D. J., Hilburn, T. B., Hislop, G., Lutz, M., McCracken, M. y Mengel, S. (1999). Guidelines for software engineering education version 1.0. (Reporte técnico CMU/SEI-99-TR-032 ESC-TR-99-002). Pittsburgh, PA: Carnegie Mellon University, Software Engineering Institute.

Caputo, K. (1998). CMM Implementation guide: Choreagraphing software process improvement. Reading, MA: Addison Wesley-Longman.

Clark, B. K. (2000). Quantifying the effects of process improvement on effort. IEEE Software, 17 (6), 65-70.

Collofello, J. S., Kantipudi, M. y Kanko, M. A. (1994). Assessing the software process maturity of software engineering courses. En Proceedings of the 25th SIGCSE Technical Symposium on Computer Science Education (pp. 16-20). Phoenix, AR: ACM Press.

Curtis, B., Kellner, M. I. y Over, J. (1992). Process modeling. Communications of the ACM, 35 (9), 75-90.

Donaldson, S. E. y Seigel, S. G. (1997). Cultivating successful software development: a practitioner's view. Upper Saddle River, NJ: Prentice-Hall PTR.

Dorfman, M. y Thayer, R. H.. (1990). Standards, guidelines, and examples on system and software requirements engineering. Los Alamitos, CA: IEEE Computer Society Press.

Fairley, R. (1985). Ingeniería de software. (Trads. A. Sáchez y P. L. Flores-Suárez). México: McGraw-Hill. (Trabajo original publicado en 1985).

García Mireles, G. A. y Rodríguez Jacobo, J. (2000). Manual de procedimientos para la elaboración del documentos de requerimientos en el desarrollo de software (Informe técnico CICESE CTCCT2001, serie Electrónica y Telecomunicaciones). Ensenada, B. C.: CICESE.

García Mireles, G. A. y Rodríguez Jacobo, J. (2000, junio). Propuesta para mejorar la enseñanza de la ingeniería del software basada en proyectos. Cartel presentado en el Congreso de Educación Abierta y a Distancia (CEAD 2000). Ensenada, B. C.:ANUIES-UABC-CICESE

Herbsleb, J., Zubrow, D., Goldenson, D., Hayes, W. y Paulk, M. (1997). Software quality and the capability maturity model. Communications of the ACM, 40 (6), 30-40.

Humphrey, W. S. (1989). Managing the software process. Reading, MA: Addison-Wesley.

Jaccheri, M. L. y Lago, P. (1997). Applying software process modeling and improvement in academic setting. En Proceedings of the 10th Conference on Software Engineering Education and Training (pp. 13-27). Virginia Beach, VA: IEEE Computer Society Press.

Kawalek, P. (1994). Comments on the use of RADs in case studies. Disponieble en FTP: ftp://ftp.cs.man.ac.uk/pub/IPG/pk94.zip (10 de junio de 2000).

Licea, G., Rodríguez, J. y Favela, J. (1996). Evolución de procesos de desarrollo en la enseñanza de ingeniería de software. En Memorias del V Congreso Iberoamericano de Educación Superior en Computación (pp. 223-231). México: Facultad de Ciencias, UNAM.

Maurer, F. y Kaiser, G. (1998). Software engineering in the internet age. IEEE Internet Computing, 2 (5), 22-24.

Mayr, H. (1997). Teaching software engineering by means of a "virtual enterprise". En Proceedings of the 10th Conference on Software Engineering Education and Training, (pp. 176-184). Virginia Beach, VA: IEEE Computer Society Press.

Miers, D. (1996). Use of tools and technology within a BPR initiative. En C. Coulson-Thomas (Ed.), Process re-engineering: Myth and reality, (pp.142-165). Londres: Kogan Page Limited.

Oktaba, H. e Ibargüengoitia, G. (1998). Software process modeled with objects: Static view. Computación y Sistemas, 1 (4), 228-238.

Ould, M. A. (1995). Business processes: Modeling an analysis for re-engineering and improvement. Chichester: John Wiley and Sons.

Paulk, M. C., Weber, C. V., Curtis, B. y Chrissis, M. B. (Eds.) (1995). The capability maturity model: Guidelines for improving the software process. Reading, MA: Addison-Wesley.

Pressman, R. (1993). Ingeniería del software. Un enfoque práctico (3ª. ed.) (Trads. C. Cervigon y L. Hernández Yañez). Madrid: McGraw-Hill. (Trabajo original publicado en 1992).

Robillard, P. N. (1998). Measuring team activities in a process-oriented software engineering course. En Proceedings of the 11th Conference on Software Engineering Education and Training. Atlanta: IEEE Computer Society Press.

Rombach, H. D. (1990). Software specifications: A framework. En M. Dorfman y R. H. Thayer (Eds.), Standards, guidelines, and examples on system and software requirements engineering (pp.368-407). Los Alamitos, CA: IEEE Computer Society Press.

Sommerville, I. (1995). Software engineering (5ª ed.). Harlow: Addison-Wesley.

Tomayko, J. E. (1987). Teaching a project-intensive introduction to software engineering (Reporte técnico CMU/SEI-87-TR-20 ESD-TR-87-171). Pittsburgh, PA: Carnegie Mellon University, Software Engineering Institute.

Upchurch, R. L. y Sims-Knight, J. E. (1997). Designing process-based software curriculum. En Proceedings of the 10th Conference on Software Engineering Education and Training (pp. 28-38). Virginia Beach, VA: IEEE Computer Society Press.

Upchurch, R. L. y Sims-Knight J. E. (1998). In support of student process improvement. En Proceedings of the 11th Conference on Software Engineering Education and Training. Atlanta: IEEE Computer Society Press.

Warboys, B., Kawalek, P., Robertson, I. y Greenwood, M. (1999). Business information systems: A process approach. Londres: McGraw-Hill.

Wastell, D. G., White, P. y Kawalek, P. (1994). A methodology for business process redesign: Experiences and issues. Journal of Strategic Information Systems, 3 (1), 23-40.