Ingeniería del software - Computational Biology and...

Ingeniería del software

Una experiencia para fomentar la motivación en las prácticas de una asignatura de desarrollo de software

Antonio Garrido Departamento Sistemas Informáticos y Computación

Universidad Politécnica de Valencia Camino de Vera s/n, 46071 – Valencia (Spain)

[email protected]

Resumen En este artículo se presenta una experiencia real para fomentar la motivación del alumno en las prácticas de laboratorio de una asignatura de desarrollo de software. En el artículo se describe brevemente la asignatura y las competencias formativas que se esperan de ella, así como todas las actividades que se efectuaron y en qué momento del curso. Cada actividad se encuentra profundamente detallada, incluyendo sus objetivos y ventajas. Finalmente, el análisis de los resultados y su discusión demuestra que esta experiencia resulta efectiva, a la vez que satisfactoria, tanto para el alumno como para el profesor.

1. Introducción

En la actualidad, muchos son los profesores universitarios que se encuentran en sus clases con situaciones de falta de motivación por parte de los alumnos. “Mis alumnos no asisten a clase”, “los alumnos que asisten a clase tienen una actitud muy pasiva”, “los alumnos son meros espectadores que no participan en la clase”, “no consigo que mis alumnos estén motivados”, y un largo etcétera son comentarios que hemos oído y vivido en demasiadas ocasiones. El profesorado, y también la universidad como marco institucional, es cada vez más consciente de que este tipo de situaciones se puede evitar siguiendo una metodología más activa [7]. En este tipo de metodología, el alumno pasa a jugar un papel mucho más importante, representando el eje central del proceso de enseñanza-aprendizaje, y su actitud debe ser más activa y participativa. El principal inconveniente al que nos enfrentamos es que esto supone un cambio de mentalidad y de

actitud importante: se requiere un mayor esfuerzo por parte del alumno y, más importante aún, hacer frente a una fuerte inercia fruto de muchos años de una metodología poco activa y participativa. A pesar de ello, es evidente que hay que afrontar este cambio con voluntad y ambición, pues la aplicación de nuevas metodologías es esencial en el marco de un Espacio Europeo de Educación Superior (EEES) [3].

Aunque el profesorado universitario está realizando grandes esfuerzos para adaptar y replantear su docencia hacia un proceso dirigido hacia el aprendizaje [6], hay que admitir que aún queda bastante por hacer debido, principalmente, a que los cambios a realizar no son nada sencillos. No obstante, es en la parte correspondiente a las prácticas de laboratorio donde las metodologías activas se pueden poner en marcha de una forma más sencilla e intuitiva, principalmente por cuatro motivos: i) los contenidos prácticos y su estructuración son más flexibles; ii) las características del trabajo a realizar se prestan a una mayor participación; iii) el alumno es el verdadero artífice del trabajo (el profesor pasa a ser un elemento más pasivo); y iv) el ratio de alumnos por profesor es menor. Es concretamente en esta parte en la que nos centraremos en este artículo, precisamente en ¿cómo podemos fomentar todavía más la motivación del alumno en las prácticas de laboratorio de una asignatura de desarrollo de software? En este artículo no se presentarán métodos nuevos, sino una combinación de los más comunes (que vienen utilizándose desde hace tiempo) basada en una experiencia real realizada en la asignatura Técnicas Avanzadas para Desarrollo de Software durante el curso académico 2003-2004.

El artículo se organiza de la siguiente forma. El apartado 2 proporciona el contexto docente en el que ser enmarca la asignatura en la que se realizó esta experiencia, mientras que el apartado

240 Ingeniería del software 3 presenta una breve descripción de la asignatura. En el apartado 4 se detalla la experiencia para fomentar la motivación en las prácticas de laboratorio, explicando las actividades y ventajas más importantes. En el apartado 5 se realiza el análisis de los resultados. Finalmente, el apartado 6 incluye las conclusiones de esta experiencia.

2. Contexto docente. Intensificación de “Ingeniería del Software”

En la Escuela Técnica Superior de Informática Aplicada (ETSIA) de la Universidad Politécnica de Valencia (UPV), la mayoría de asignaturas relacionadas con la ingeniería del software se encuentran agrupadas en la intensificación de Ingeniería del Software de tercer curso. El objetivo es el de formar a profesionales con una sólida base teórica y práctica en ingeniería del software a través del aprendizaje y aplicación de las notaciones, técnicas, herramientas y métodos más aceptados en esta disciplina. Esta intensificación consta de tres asignaturas obligatorias (núcleo de intensificación) y cuatro optativas, todas ellas de 6 créditos (3 créditos de teoría + 3 créditos de prácticas), tal y como se indica en la Tabla 1.

Tipo Asignatura

El proceso de software Laboratorio de desarrollo de sistemas de información Núcleo Técnicas avanzadas para desarrollo de software Arquitecturas de sistemas de bases de datos Desarrollo de aplicaciones en entornos Web Desarrollo de software basado en componentes

Optativa

Programación avanzada en Internet

Tabla 1. Asignaturas de la intensificación de Ingeniería del Software

Concretamente, la asignatura Técnicas Avanzadas para Desarrollo de Software (DSW) está posicionada en el cuatrimestre B del tercer curso. Esta asignatura se ha impartido por primera vez, por pertenecer al plan de estudios iniciado en 2001, durante el curso 2003-2004 con un total de 69 alumnos matriculados. La asignatura (tanto la

parte teórica como la parte de prácticas de laboratorio) la ha impartido un único profesor.

3. Breve descripción de la asignatura

La asignatura DSW se organiza en 4 horas semanales, 2 dedicadas a teoría (1 grupo) y 2 más a prácticas de laboratorio (2 grupos). Puesto que la asignatura se imparte en el último cuatrimestre de la titulación y la mayoría de alumnos no pretende continuar con sus estudios en un segundo ciclo, DSW está planteada bajo un enfoque eminentemente práctico, enseñando a los alumnos a trabajar de forma ingenieril y disciplinada en el desarrollo de aplicaciones software.

El objetivo global de la asignatura es aprender y poner en práctica los conceptos avanzados de la orientación a objetos, creación de componentes, diseño de interfaces gráficas de usuario y acceso a bases de datos para desarrollar software (incluyendo software para sistemas operativos visuales, para la Web y para dispositivos móviles). Dicho objetivo general surge de las siguientes competencias:

• Saber aplicar los principios de diseño en la

construcción de interfaces gráficas de usuario en entornos de tipo RAD.

• Saber desarrollar componentes (Windows y Web) reutilizables.

• Conocer mínimamente las arquitecturas más comunes de aplicaciones que trabajan con bases de datos.

• Conocer las formas de acceso a bases de datos desde el sistema operativo Windows.

• Conocer la estructura de las aplicaciones Web.

• Conocer las necesidades, limitaciones y tipología en el desarrollo de software para dispositivos móviles.

• Saber construir software que utiliza bases de datos en entornos conectados y desconectados, accediendo a los mismos mediante aplicaciones visuales y a través de la Web.

• Saber construir aplicaciones sencillas para dispositivos móviles.

• Saber trabajar en un equipo con capacidad autónoma.

XI Jornadas de Enseñanza Universitaria de la Informática 241

Estas competencias se desarrollan en tres

bloques que representan los contenidos teóricos y prácticos de la asignatura (ver Tabla 2).

Bloque 1. Introducción al desarrollo de aplicaciones visuales Tema 1. Entornos de programación RAD en la ingeniería del software Tema 2. Interfaces de usuario. Diseño y construcción Práctica 1. Introducción y repaso del entorno Visual C# .NET Práctica 2. Construcción de una sencilla aplicación visual (editor de textos MDI)

Bloque 2. Desarrollo de software de gestión Tema 3. Desarrollo de componentes reutilizables Tema 4. Desarrollo de aplicaciones de gestión para bases de datos Práctica 3. Acceso a bases de datos en ADO .NET. Uso desde Visual C# .NET Práctica 4. Desarrollo del caso de estudio trabajando con BD

Bloque 3. Desarrollo de software para aplicaciones a través de redes

Tema 5. El modelo Cliente / Servidor Tema 6. Internet. Aplicaciones para la Web y servicios Web Tema 7. Introducción al desarrollo de software para dispositivos móviles Práctica 5. Integración del caso de estudio para su uso a través de la Web

Tabla 2. Contenidos teórico-prácticos de la asignatura

El primer bloque abarca las competencias sobre construcción de interfaces gráficas de usuario y entornos de tipo RAD. El segundo bloque comprende las competencias formativas de desarrollo de componentes reutilizables, trabajo y acceso a bases de datos. El tercer bloque se corresponde con las competencias de aplicaciones Web y desarrollo de software para dispositivos móviles. Finalmente, la competencia de trabajo en equipo se lleva a cabo en la parte práctica de los tres bloques, y en especial en los dos últimos, mediante el desarrollo de un caso de estudio.

En el planteamiento inicial de DSW se utilizó como referencia una asignatura del plan de estudios anterior de contenidos similares, Laboratorio de Ingeniería del Software [1][4].

Obviamente, el cambio del plan de estudios se aprovechó para realizar una fuerte remodelación de la asignatura, principalmente en lo que a la parte de prácticas de laboratorio se refiere, tal y como se detalla en el siguiente apartado.

4. El papel de las prácticas de laborato-rio. ¿Cómo fomentar la motivación?

Las prácticas de laboratorio son un recurso muy valioso, especialmente en una asignatura de desarrollo de software. Es en el laboratorio donde los alumnos mejor asimilan los conceptos presentados en las clases teóricas [4]. Por lo tanto, se pretende poner de manifiesto la importancia de seguir y cumplir un método correcto en el desarrollo completo de un proyecto software (caso de estudio) [2]. En este proceso de desarrollo, los alumnos pasan por todas las etapas que constituyen un proyecto software hasta llegar a la entrega del producto final, como son: i) planificación del proyecto; ii) especificación de requisitos; iii) análisis y modelado; iv) diseño; v) implementación y pruebas; y vi) documentación (con la obtención del manual de usuario). Sin embargo, de acuerdo a nuestra experiencia en asignaturas de similar tipología, la realización completa de un caso de estudio puede no ser suficientemente motivadora y requerir complementos extra que fomenten todavía más la parte de laboratorio. Estos complementos son los que se exponen a continuación. Para ello, se seguirá una exposición cronológica tal y como sucedió en la experiencia realizada en la asignatura DSW en el curso académico 2003-2004, incluyendo las acciones y actividades más significativas, desde el primer día de clase hasta el último.

4.1. El primer día de clase

Tradicionalmente, en el primer día de clase se presenta la asignatura, sus objetivos, contenidos (teórico-prácticos), metodología a seguir, tipo de evaluación, bibliografía, etc. Ante esta avalancha de información sobre la organización de la asignatura, el alumno se ve en una posición muy limitada: las decisiones sobre la organización de la asignatura son inamovibles, no se pueden cambiar y, por tanto, hay que amoldarse necesariamente a

242 Ingeniería del software

ellas. Es evidente que una situación en la que todo está decidido es altamente desmotivadora.

A fin de minimizar la desmotivación inicial, antes de presentar la organización de la asignatura se indicaron las funciones y competencias de un ingeniero técnico en informática con perfil profesional de desarrollo de software1. Esto dio pie a una serie de comentarios y a una larga discusión por parte de los alumnos sobre dichas competencias, reflejando sus opiniones, actitudes, preocupaciones e intereses. Esta simple actividad aportó dos ventajas inmediatas: i) desde el primer momento se fomentó la participación (los alumnos son libres de expresar sus opiniones y discutirlas en voz alta); y ii) el profesor pudo conocer qué objetivos resultaban más interesantes para la clase (habría que trabajarlos con mayor profundidad), y sobre todo permitió reconocer algunas de las lagunas existentes en los conocimientos fijados como prerrequisitos de la asignatura.

Una vez comentadas las competencias se pasó a posicionar la asignatura dentro del marco de la intensificación. En este punto se plantearon las interrelaciones entre las asignaturas. Esto es importante pues evita que los alumnos consideren una asignatura como un elemento aislado del resto de las asignaturas, a la vez que se indica cómo sus distintos objetivos se complementan entre sí. Adicionalmente, se preguntó a los alumnos para conocer el porcentaje matriculado en cada una de las asignaturas anteriores. Esto permite conocer la homogeneidad, o no, del alumnado, pudiendo ayudar a enfatizar mejor unos aspectos que otros. Desgraciadamente, en nuestro caso se pudo constatar una gran heterogeneidad pues los alumnos no seguían un patrón común en sus matrículas.

Finalmente, se realizó la tradicional presentación de la asignatura con sus objetivos, contenidos, metodología, etc. En lo que respecta a la parte de prácticas de laboratorio, se les preguntó de nuevo su opinión acerca del tipo de prácticas que más les atraía y la forma de llevarlas a cabo. Para ello, el profesor proponía tres alternativas:

1. Sesiones de prácticas independientes, donde en

cada una de ellas se estudia y desarrolla un

1 Actualmente, estas competencias están claramente definidas en el borrador del libro blanco del grado en Ingeniería Informática, disponible en la dirección Web: www.aneca.es/modal_eval/conver_docs_titulos.html

contenido práctico en concreto. En esta alternativa no se utiliza un único caso de estudio a lo largo del curso, sino que en cada sesión se puede trabajar sobre un apartado muy concreto de casos totalmente independientes (en esta alternativa no existe una continuidad real del trabajo realizado entre dos sesiones consecutivas).

2. Sesiones de prácticas donde hay que resolver un caso de estudio propuesto por el profesor. El profesor plantea el problema y las fechas límites de los entregables. En este caso sí existe una continuidad real entre sesiones consecutivas, pero todo el proceso está muy delimitado.

3. Sesiones de prácticas donde hay que resolver un caso de estudio propuesto por los alumnos. Ellos organizan equipos de trabajo, proponiendo el problema a resolver y las fechas límite de los entregables. Al igual que en la segunda alternativa, sí existe una continuidad real entre sesiones y, además, el problema a resolver lo eligen los alumnos (y por tanto es distinto para cada equipo).

Las distintas opiniones de los alumnos crearon

una importante discusión en la clase que ellos mismos trataron de resolver, animados por el profesor. Unos pocos alumnos eligieron la primera y segunda alternativa (resultaban las alternativas a las que estaban más acostumbrados), mientras que la mayoría se veía atraído por la tercera. Tras sugerir varias modificaciones sobre las tres alternativas y realizar varias votaciones (se dio el caso de que hubo que votar hasta tres veces), se descartaron alternativas y se llegó a un consenso común con la tercera alternativa2. Esta tercera alternativa se plasmó posteriormente por escrito para reflejar el tipo de prácticas a realizar y la normativa consensuada por los alumnos y el profesor. Al finalizar esta clase se planteó una futura reunión, esta vez en horario de consultas, para delimitar por parte de cada equipo de trabajo el caso de estudio a resolver.

Desde el punto de vista del alumno, el resumen que se puede hacer del primer día de clase es que en esta asignatura se fomenta con intensidad la participación, y la opinión del

2 Es importante destacar que fueron los propios alumnos los que se encargaron de demostrar que la tercera alternativa resultaba la más pertinente en una asignatura de desarrollo de software.


alumno es importante, a la vez que tenida en cuenta. Desde el punto de vista del profesor, se puede indicar que se ha permitido conocer el nivel previo de los alumnos, sus intereses y se ha seleccionado una alternativa de prácticas atrayente, y por tanto más motivadora, para el alumno.

4.2. La primera reunión en horario de consul-tas. Propuesta del caso de estudio

En esta primera reunión, cada grupo de alumnos propone al profesor el caso de estudio a desarrollar. Previamente, el profesor ha planteado un conjunto de problemas tipo (casos de estudio de ejemplo) con los requerimientos mínimos que debe cubrir y cumplir el trabajo de la asignatura (desarrollo de una aplicación con interfaz gráfica de usuario, con acceso a una base de datos tanto de forma local como remota vía Web, etc.) Es decir, en esta reunión se establece el contrato de aprendizaje [5] de las prácticas de la asignatura, concretando los siguientes puntos:

• Composición del equipo de trabajo. Se

establece un tamaño máximo de 4 personas y un mínimo de 2.

• Descripción del caso de estudio a desarrollar. Los alumnos proponen el enunciado del problema, características y alcance del mismo. El problema debe satisfacer unos contenidos mínimos exigibles y, de forma optativa, una serie de características adicionales a modo de ampliación que puede proponer tanto el grupo como el profesor. Esto permite determinar la nota máxima a la que se puede aspirar en la parte de prácticas3. Todos los casos de estudio consistían en el desarrollo de un sistema de información para la resolución de un problema real. Los problemas eran bastante dispares, aunque todos ellos implicaban el desarrollo de una aplicación de gestión: gestión de una cadena de tiendas/almacenes mayoristas de ropa, gestión de un taller de automóviles,

3 Es digno de mención que todos los grupos propusieron un caso de estudio lo suficientemente completo para optar a la máxima nota aunque, finalmente, no todos la consiguieron. Esto pone de manifiesto el interés y motivación que mostraron desde el inicio de la asignatura.

gestión de un restaurante, gestión de una agencia inmobiliaria, gestión de una empresa constructora, gestión de un colegio, etc.

• Entregables a proporcionar al profesor al final de cada una de las etapas del desarrollo, tal y como se indican al principio del apartado 4.

• Calendario de entregas. En la delimitación de las fechas límites de los entregables es donde los alumnos muestran un mayor desconcierto. Esto es totalmente razonable teniendo en cuenta su falta de experiencia en este tipo de desarrollos y, considerando que las fechas de los entregables siempre le vienen impuestas por el profesor. Para evitar este desconcierto inicial, el profesor aconsejó unas fechas aproximadas que, con mínimas variaciones, fueron aceptadas por todos los grupos.

• Reparto de porcentajes de la nota de prácticas a los entregables. En este caso, son los propios alumnos los que deciden la parte de la nota final de prácticas que recae sobre cada uno de los entregables. Evidentemente, existen unos límites razonables delimitados por el profesor y que los alumnos reconocían como correctos. Esto resulta especialmente motivador, pues el alumno sabe, en todo momento, cuántos puntos lleva superados en la asignatura (con las ventajas que esto supone) [6].

La combinación de los tres elementos clave

como desarrollo de un caso de estudio, trabajo en equipo y contrato de aprendizaje aporta claras ventajas ampliamente reconocidas, a saber:

• Permite establecer mayores semejanzas entre

el problema a resolver y un problema real. Adicionalmente, el profesor puede aconsejar sobre la viabilidad del problema (principalmente al tener en cuenta las limitaciones temporales de la asignatura), guiando a los alumnos en función de sus necesidades más concretas.

• Permite acotar las actividades y definir los resultados en unos plazos concretos.

• Establece un compromiso alumnos-profesor para efectuar un mejor seguimiento del proyecto.

• El alumno asume un mayor protagonismo en el proceso de aprendizaje, relegando a un segundo plano el papel de enseñanza por parte del profesor.

244 Ingeniería del software • Existe una mayor implicación personal del

alumno y se potencia el trabajo dentro de un equipo de desarrollo, fomentando su autosuficiencia.

• El escenario de trabajo es más agradable y motivador al pasar de unas condiciones impuestas por el profesor a unas formalizadas bajo común acuerdo.

Además de las ventajas anteriores, existe una

ventaja más subjetiva. Es bastante conocida la reticencia de gran parte del alumnado de asistir a los horarios de consultas para resolver sus dudas, que se acumulan hasta pocos días antes del examen. En esta experiencia, se requiere acudir al profesor en su horario de consultas para proponer el caso de estudio a desarrollar. Esta primera reunión se realiza en grupo, relajando parte de la tensión y hace que los alumnos pierdan ese “miedo inicial”. Esto favorece que, posteriormente y a lo largo del curso, la asistencia en las horas destinadas a consulta sean más frecuentes, bien asistiendo de forma grupal (mayoritariamente) o de forma individual.

4.3. Transcurso de las prácticas de laboratorio

Las prácticas de laboratorio se organizaron en tres bloques. El objetivo del primer bloque es el de recordar y familiarizarse con el entorno de trabajo, en nuestro caso Visual C# .NET. En general, este entorno ya es conocido por los alumnos por haberlo utilizado en alguna asignatura cursada anteriormente. No obstante, las tres primeras sesiones consisten en la construcción de aplicaciones muy sencillas (un juego simple y un editor de texto con interfaz multidocumento) para introducir al alumno en la construcción de aplicaciones visuales.

El objetivo del segundo bloque es proporcionar al alumno, en sólo tres sesiones, los conocimientos tecnológicos esenciales (modelos, componentes y posibilidades) para desarrollar aplicaciones visuales más complejas que accedan a bases de datos. A partir de aquí, las restantes sesiones de laboratorio del curso (resto del bloque dos y bloque tres por completo de la Tabla 2) son de dedicación exclusiva para el desarrollo del caso de estudio. En estas sesiones, los alumnos trabajan en equipo de forma autónoma y el profesor se dedica simplemente a tutelar y resolver las consultas surgidas durante el desarrollo del

proyecto. Además, dicha tutela resulta cada vez menos guiada y directa, de forma que los alumnos aprenden a ser autosuficientes en la resolución de sus propios problemas. Esta forma de trabajar proporciona una gran ventaja: promueve la independencia de los equipos de alumnos, así como su capacidad y destreza para buscar información en manuales, libros, ayudas on-line e Internet, accediendo a información complementaria. Es decir, se fomenta la autosufiencia del alumno, tanto de forma individual como grupal.

Por lo demás, las prácticas transcurrieron con absoluta normalidad, con una asistencia regular superior al 95% (a pesar de no haber control de asistencia). Los entregables se realizaron con normalidad y dentro de los plazos que los propios alumnos marcaron en su contrato de aprendizaje.

4.4. Último día de clase

El último día de clase se reservó para la realización de presentaciones voluntarias. Los grupos que habían realizado extensiones al trabajo básico de la asignatura, por ejemplo utilizando tecnologías adicionales no presentadas propiamente en la asignatura, tuvieron la oportunidad de exponer su trabajo y resultados. Las ventajas de realizar esta presentación son varias. En primer lugar, los alumnos que realizan la presentación practican la exposición oral, habilidad que tradicionalmente no se impulsa lo suficiente. En segundo lugar, los alumnos que asisten a la presentación conocen lo realizado por otros grupos y aprenden nuevos conceptos y tecnologías complementarias a las analizadas en clase. Obviamente, la realización de la presentación se valora positivamente en la nota final, favoreciendo la participación del alumnado. Finalmente, se realizó una recopilación de estas presentaciones y se dejaron disponibles en la Web para su consulta y/o descarga.

5. Análisis de resultados. Discusión

El análisis y discusión de esta experiencia se puede hacer tanto desde un punto de vista cuantitativo como cualitativo. En lo que respecta al análisis cuantitativo, me basaré en los resultados obtenidos por la “encuesta de evaluación de la docencia” que elabora el Instituto de Ciencias de la Educación (ICE) de la UPV.


Esta encuesta es anónima y la cumplimentan los alumnos al final del curso, evaluando distintos apartados como: dominio de la asignatura por el profesor, organización, claridad y desarrollo del programa, interacción profesor-alumno, motivación, satisfacción general, etc. En concreto, he seleccionado las cuatro preguntas más relacionadas con el objetivo de este artículo, que me han permitido valorar esta experiencia de motivación:

1. ¿Se da a la asignatura un enfoque aplicado,

ofreciendo demostraciones y transferencias a la vida real y profesional? Esta pregunta permite valorar si el enfoque es pertinente para el futuro profesional del alumno.

2. ¿Se establecen conexiones con los contenidos de otras asignaturas? Esta pregunta permite conocer la relación y cómo el enfoque se contextualiza en una intensificación (o plan de estudios).

3. ¿Se dialoga con los alumnos sobre la marcha de las clases, tomando en cuenta sus opiniones? Esto permite valorar si la opinión del alumno es importante y tenida en cuenta.

4. ¿Se consigue que los alumnos estén motivados por la asignatura? Esta pregunta es, sin duda, la más relevante en este artículo y permite distinguir si la motivación de los alumnos es, o no, elevada.

0%

10%

20%

30%

40%

50%

60%

70%

TED MBD IND MBA TDA S/C

1. Utilización de enfoque aplicado

2. Enfoque contextualizado

3. Tener en cuenta opiniones

4. Motivación por la asignatura

TED: Totalmente En DesacuerdoMBD: Más Bien en DesacuerdoIND: Término Medio

MBA: Más Bien de AcuerdoTDA: Totalmente De AcuerdoS/C: No Contesta

Figura 1. Análisis de cuatro preguntas que pueden ayudar a conocer el interés y motivación del alumno

Los resultados de estas cuatro preguntas aparecen en la Figura 1. En dicha Figura se puede observar que ni un solo alumno está en desacuerdo con lo cuestionado en las preguntas anteriores, es decir, valoran la experiencia utilizada en la asignatura de una forma muy positiva. Más concretamente, un elevado

porcentaje (superior al 85%) de los alumnos está de acuerdo en afirmar que se ha utilizado un enfoque aplicado que desarrolla competencias profesionales, en el que sus opiniones se han tenido en cuenta positivamente y que les ha motivado satisfactoriamente. Concretamente, en la pregunta cuatro, la más reveladora para evaluar el carácter motivador de la experiencia utilizada, el 85% de los alumnos afirma haber estado motivado: el 40% está más bien de acuerdo y el 45% restante está totalmente de acuerdo.

Obviamente, la motivación del alumno es importante tanto para la realización de las prácticas de laboratorio de una asignatura como para su parte teórica. No obstante, esta motivación también debería verse reflejada en la calificación final de la asignatura. Por tanto, otro criterio cuantitativo importante para analizar el éxito de la experiencia aquí presentada es el índice de alumnos que superan las prácticas de laboratorio de la asignatura y, de forma global, la asignatura en su totalidad. En lo que respecta a la parte de prácticas de laboratorio, el 100% de los alumnos presentados aprobó (con una nota media de 8.1); únicamente 5 alumnos abandonaron las prácticas a mitad de curso por sobrecarga de trabajo. Finalmente, en lo que respecta a la asignatura en su globalidad, los resultados fueron muy similares: el 94% de los alumnos presentados aprobó la asignatura y sólo el 6% no fue apto, con la distribución de calificaciones presentada en la Tabla 3.

Rango de

calificación %

Suspenso 6% Aprobado 22% Notable 58%

Excelente 14%

Tabla 3. Distribución de calificaciones finales

Además del análisis cuantitativo anterior, también se ha realizado un análisis cualitativo. Al finalizar la asignatura, los alumnos cumplimentaron una nueva encuesta (esta vez diseñada por el profesor y completamente personalizada para la asignatura) consistente en preguntas abiertas para expresar su opinión de forma anónima. En esta encuesta se solicitaba la impresión de las prácticas de laboratorio (interesantes, útiles, complejas, etc.), la estrategia seguida, valoración del trabajo realizado,

246 Ingeniería del software principales inconvenientes con los que se habían encontrado y qué modificaciones sugerían en la asignatura. Las respuestas fueron muy satisfactorias. Absolutamente todos los alumnos opinaban que las prácticas les habían parecido de las más interesantes que habían realizado en la titulación, coincidían en que habían estado muy motivados y habían aprendido muchas cosas útiles para su futuro profesional (aunque también reconocían que habían tenido que trabajar muy duro y con constancia). Esta valoración objetiva reafirma la opinión subjetiva del profesor al manifestar la visión tan positiva de esta experiencia y la sensación de contar con alumnos que se sienten realmente motivados. Además, esto ayuda notablemente a crear un ambiente en el aula mucho más agradable, donde tanto el profesor como el alumno se encuentran más a gusto.

6. Conclusiones

La principal conclusión que se puede extraer es que la experiencia presentada en este artículo ha resultado ser muy positiva. Por tanto, personalmente creo que se ha logrado el objetivo buscado desde el primer momento (incluso más de lo que se podía esperar inicialmente): fomentar la motivación del alumno y conseguir que alcance las competencias deseadas. Después de poner en práctica esta experiencia en la asignatura de DSW, puedo afirmar que se ha conseguido una mayor implicación personal por parte del alumno, lo que también redunda en una mayor satisfacción del profesor. Sin embargo, soy consciente de que la experiencia presentada en este artículo puede no ser de fácil aplicación en otras materias o en asignaturas donde el número de alumnos sea muy elevado (por ejemplo en las de primeros cursos), pero al menos sí en la mayoría de aquéllas que requieran un trabajo en equipo sobre un caso de estudio.

En el curso actual la asignatura acaba de comenzar y de momento sólo se ha hecho la clase de presentación. No obstante, desde esta primera clase ya se ha seguido la misma estrategia y los resultados han sido muy similares: al principio los alumnos se sienten un poco cohibidos, pero finalmente su participación se incrementa notablemente, incrementando su motivación por la asignatura. En lo que respecta al modelo a utilizar en las prácticas de laboratorio, los alumnos han decidido, de nuevo, la alternativa que se

corresponde con la experiencia presentada en este artículo. En principio, esto me hace confiar en un éxito similar para el curso actual, a la vez que me permitirá refinar y mejorar la estrategia y las actividades planteadas.

Referencias

[1] Canós, J.H.; Penadés, M.C.; Pelechado, V.; Sánchez, J. La Ingeniería del Software en los planes de estudio de la Escuela Universitaria de Informática de la UPV. Actas de las II Jornadas de Ingeniería del Software (JIS’97), 1997.

[2] Cheston, G.A.; Tremblay, J.P. Integrating software engineering in introductory computing courses. IEEE Software, pp. 64-71, Sept/Oct, 2002.

[3] European Ministers of Education, The European Higher Education Area - Bologna Declaration, Bologna on the 19th of June 1999.

[4] Garrido, A.; Penadés, M.C.; Pelechado, V. Un modelo de evaluación de prácticas en Laboratorio de ingeniería del software. Actas de las VII Jornadas de Enseñanza Universitaria de Informática (JENUI 2001), pp. 222-227, 2001.

[5] Knowles, M. Using learning contracts: practical approaches to individualising and structuring learning. San Francisco, Jossey Bass, 1986.

[6] Marqués, M.; Tomás, V.R.; Sanz, I. Tratando de fomentar la motivación del estudiantado. Actas de las X Jornadas de Enseñanza Universitaria de Informática (JENUI 2004), pp. 329-336, 2004.

[7] Zabalza, M.A. Enseñar en la Universidad. Competencias docentes del profesor universitario. Ed. Narcea, 2002.

RAMALA: un modelo para la formación en los procesos de gestión de proyectos software

Javier García Guzmán, Antonio de Amescua Seco, Yaser Rimawi, Tomás San Feliu Dpto. de Informática

Universidad Carlos III de Madrid 28911, Leganés, Madrid, Spain

e-mail:{jgarciag, amescua}@inf.uc3m.es; [email protected]; [email protected]

Resumen El propósito de este trabajo es la definición y la aplicación de un modelo que facilite la docencia en la definición e implantación de procesos de gestión de proyectos software en distintos tipos de aplicaciones, de tal manera, que los alumnos comprendan la importancia de este tipo de procesos para el éxito de los proyectos informáticos. Asimismo, se presentará un estudio analítico de los resultados obtenidos mediante la aplicación de este modelo.

1. Descripción del problema a resolver

El principal factor de éxito de los proyectos software reside en una gestión eficiente del proceso, la tecnología, el personal y el producto a realizar [10]. Por tanto, para una correcta formación de futuros desarrolladores de software, es necesario que éstos aprendan los fundamentos de la gestión integral de los proyectos software. En la Universidad Carlos III de Madrid, la docencia en relación con los procesos de gestión de proyectos software se realiza en la asignatura de Planificación y Gestión de Proyectos Informáticos (PGSI en adelante) (7 créditos), perteneciente al segundo ciclo de los estudios en Ingeniería Informática. Esta asignatura tiene como objetivos: • Distinguir los distintos procesos que cubre la

gestión de proyectos informáticos • Conocer y comprender los fundamentos de

una adecuada gestión de proyectos informáticos

• Conocer y aplicar los principios del trabajo en equipo

• Especificar eficazmente los requisitos de un proyecto software

• Planificar y realizar el seguimiento de los procesos implicados en un proyecto

Durante los últimos cursos, aunque se realizaban ejercicios parciales acerca de las problemáticas de cada uno de los procesos de gestión tratados en la teoría, se han detectado un conjunto de dificultades que impedían que se consiguieran totalmente los objetivos anteriores: • Los alumnos no comprendían cómo se podían

aplicar en una organización software, de una manera práctica, los contenidos teóricos adquiridos en la asignatura.

• Los alumnos tenían dificultades para comprender la visión integral de todos los procesos de gestión de los proyectos software presentados.

• Los alumnos no podían acceder a métodos y herramientas que permitieran, de una manera práctica, evaluar la situación actual de una organización, definir los procesos de gestión a implantar y simular la implantación de los mismos.

Por tanto, el propósito de este trabajo es la definición y la aplicación de un método y un modelo de conocimiento que facilite la docencia en la definición e implantación de procesos para la gestión integral del desarrollo de sistemas informáticos, de tal manera, que los alumnos aprendan la importancia de este tipo de procesos para el éxito de los proyectos software y sean capaces de poner los conocimientos teóricos en la practica de un modo claro y eficiente.

2. Objetivos

Los principales objetivos que se pretendían satisfacer con la realización de este trabajo de innovación docente son:

248 Ingeniería del software 1. Desarrollar un modelo de evaluación y

definición de los procesos de gestión de los proyectos software de una organización que permita a los alumnos evaluar la situación actual de una organización, definir los procesos de gestión a establecer y simular la implantación de los mismos.

2. Facilitar a los alumnos las herramientas software de ayuda que permitan lograr una mayor comprensión de los conceptos teóricos expuestos, siendo necesario un menor esfuerzo para su puesta en práctica por parte de los alumnos.

3. Determinar la validez y facilidad de aplicación del modelo de evaluación y definición de los procesos de gestión de los proyectos software, para la docencia de la gestión integral de proyectos software en los estudios de grado.

3. El modelo RAMALA

En la primera fase de este trabajo de innovación docente se ha definido un modelo que permita a los alumnos poner en práctica los conceptos teóricos relacionados con la gestión integral de los proyectos software. El modelo RAMALA es un modelo de mejora de procesos de la gestión de proyectos software basado en el estándar internacional Project Management Body of Knowledge (PMBOK) [10] elaborado por el Project Management Institute (PMI), los modelos de referencia en la ingeniería del software como ISO 12207[3], IEEE 1074[2], SW-CMM[5,6], CMMI[9,11], ISO 15504[4] y las metodologías de gestión de proyectos mas destacadas como Prince2 y Métrica3, DOIT, TenStep, etc. La arquitectura lógica del modelo se muestra en la Figura 1 El proceso de trabajo definido en el ámbito del modelo RAMALA de mejora de procesos consta de las siguientes fases: • Establecimiento de la base de conocimiento. • Evaluación y definición del conjunto estándar

de procesos de una organización. • Seguimiento de la mejora de procesos.

3.1. Establecimiento de la base de conocimiento

El propósito de esta fase es la creación de una base de conocimiento para la mejora de procesos de gestión de proyectos software basándose en el estándar internacional de la gestión de proyectos PMBOK, las prácticas relacionadas con la gestión de proyectos de los diferentes modelos de referencia en la ingeniería del software, los activos de proceso de las más destacadas metodologías en la gestión de proyectos y el conocimiento de expertos en la mejora de procesos software. Las actividades a realizar en esta fase son: 1. Definición de una estructura estándar para los

modelos de referencia software. 2. Identificación de la técnica de definición de

procesos y los elementos de definición de proceso.

3. Detalle de los procesos. 4. Enriquecimiento del detalle de los procesos con

activos de metodologías de referencia. El resultado de la realización del trabajo de esta fase consistirá en: I. Un repositorio donde se encuentran

almacenadas todas las prácticas relacionadas con la gestión de proyectos.

II. Asociación de todas las prácticas de la gestión de proyectos del modelo de referencia seleccionado a las actividades de los procesos del marco de procesos

III. Asignación de todos los activos de proceso disponibles de las metodologías en la gestión de proyectos a los atributos y elementos de proceso correspondientes dentro de la base de conocimiento

3.2. Evaluación y definición del conjunto estándar de procesos de una organización

El propósito de esta fase es la extracción y determinación de los procesos de la organización en el ámbito de la gestión de proyectos desde el conjunto de procesos de referencia almacenados en la base de conocimiento de procesos elaborada en la fase anterior, mediante la elaboración de una evaluación formal contra un modelo de referencia en la ingeniería del software seleccionado por la organización.


Figura 1.

PMBOKGuidePr

áctic

as

Subprácticas

Activi da d es

Tareas

Modelos deReferencia Software

CMMICMMISO 15504SPICEIEEE...

Detalle de

Procesos

Base de Conocimiento de Procesosen la Gestión de Proyectos

Informáticos

Metodologías en laGestión de Proyectos

PRINCEMETRICA 3

DOITTENSTEP

...

Activos de

Proceso

Métricas

Plan

tilla

s

Documentos

Conjunto Estándar de Procesos en la

Gestión de Proyectos dentro de la Organización



MedianteEncuestas

Gestión de ProyectoEspecifico dentro de la

OrganizaciónConjunto Definido de

Procesos para unProyecto Determinado

Detectar Necesidadesde MejoraCICLO DE

MEJORA

Banco de Datosde Proyectos de la

Organización


Organización

Datos de Proyectos

Mejoras Establecidas

PMBOKGuidePr

áctic

as

Subprácticas

Activi da d es

Tareas

PMBOKGuidePr

áctic

as

Subprácticas

Activi da d es

Tareas





Detalle de

Procesos

Base de Conocimiento de Procesosen la Gestión de Proyectos

Informáticos


PRINCEMETRICA 3

DOITTENSTEP

...


PRINCEMETRICA 3

DOITTENSTEP

...

Activos de

Proceso

Métricas

Plan

tilla

s

Documentos





MedianteEncuestas


Organización


OrganizaciónConjunto Definido de

Procesos para unProyecto Determinado

Detectar Necesidadesde MejoraCICLO DE

MEJORA


Organización


Organización

Datos de Proyectos

Mejoras Establecidas

Figura 2. Arquitectura lógica del modelo RAMALA

Las actividades a realizar en la fase de evaluación y definición del conjunto estándar de procesos de una organización son: 5. Evaluación y definición del estado actual de la

práctica de la organización. 6. Personalización de los procesos y actividades

de la organización. El resultado de la realización del trabajo de esta fase consistirá en: IV. Un repositorio donde se encuentran

almacenados el conjunto estándar de procesos de la organización

V. Establecimiento del grado de satisfacción, mediante indicadores, de las prácticas, actividades, y procesos con respecto a los procesos y actividades de referencia

3.3. Seguimiento y mejora de los procesos

El propósito de esta fase es la determinación del cumplimiento de los procesos de gestión establecidos por la organización en sus proyectos reales y agrupar la información final de los proyectos para utilizarla como base para futuras mejoras de la gestión de proyectos.

Las actividades a realizar en la fase de seguimiento de la mejora de procesos son: 7. Definición de los procesos de proyecto. 8. Agrupación de los resultados del proyecto

como instancias de activos de proceso. 9. Establecimiento de mecanismos de

recuperación de datos de los proyectos. El resultado de la realización del trabajo de esta fase consistirá en: VI. Un repositorio donde se encuentran

almacenados los procesos definidos para cada proyecto dentro de la organización.

VII. Un repositorio donde se encuentra almacenada toda la información y documentación de los proyectos de la organización como instancias de los activos de proceso del conjunto de procesos definidos para cada proyecto.

VIII. Mecanismos de recuperación automática de la información de los proyectos desde la base de conocimiento de la organización.

4. El software RAMALA

Una vez definido el modelo RAMALA, en la segunda fase de este proyecto de innovación

250 Ingeniería del software docente, se ha desarrollado un software que permita a los alumnos la aplicación, de una

manera eficiente, del citado modelo.

Servidor de Base de Datos

Usuarios remotos

Servidor de AplicacionesServidor de Base de Datos

DLLs ActiveX

Servidor Web

Servidor de lógica de negocio

Base de datosrelacional

A los clientes

PáginasASP

- SO Windows 2000- SQL Server 2000

- SO Windows 2000- Servicios de componentes COM+ (MTS)

- SO Windows 2000- Internet Information Server 5.0

Usuarios corporativos

Figura 3. Plataforma tecnológica elegida para el Software Ramala

El software RAMALA ofrece a los alumnos las siguientes utilidades: • Acceso a la base de conocimiento, donde los

alumnos podrán consultar: • Los diferentes modelos de referencia

software almacenados en el Software RAMALA.

• Las definiciones de proceso. • Activos de proceso de las metodologías en

la gestión de proyectos dadas de alta dentro del Software RAMALA.

• Evaluación del estado actual de sus procesos software en la gestión de proyectos con respecto a un modelo de referencia software seleccionado por la organización.

• Definición del conjunto de procesos software de la organización en la gestión de proyectos.

• Recopilación los diferentes activos de proceso de la organización y asociarlos a los procesos.

• Identificación de los procesos y actividades necesarias para llevar a cabo los diferentes proyectos de la organización.

• Análisis de resultados de proyectos con el objetivo de detectar oportunidades de mejora en los procesos de la organización.

5. Experiencias de la utilización de RAMALA para la docencia en mejora de procesos software

Finalmente, la última fase de este proyecto de innovación docente consistía en determinar la validez y facilidad de aplicación del modelo de evaluación y definición de los procesos de gestión de los proyectos software, para la docencia de la gestión integral de proyectos software en los estudios de grado. La experimentación realizada tiene dos grandes objetivos:

1. En primer lugar, determinar si el modelo

definido permite a los alumnos mejorar su comprensión de los conceptos teóricos de una buena gestión integral de proyectos software (que se encuentran debidamente especificados en PMBOK).

2. En segundo lugar, determinar si el software RAMALA es válido para la docencia en gestión de proyectos software, es decir, que pueda ser aplicada productivamente en cualquier centro que imparta estudios de grado de Ingeniería de


Software, para que los alumnos pongan en práctica los conceptos teóricos de la gestión integral de proyectos software.

Para lograr los objetivos relativos a esta experimentación, se ha contado con la participación de los alumnos de la asignatura Planificación y Gestión de los Sistemas Informáticos (PGSI) en la Universidad Carlos III. La asignatura se impartió en el primer cuatrimestre del año académico 2003/2004. El número de alumnos matriculados fue de 73 alumnos. De los cuales asistieron a las prácticas un total de 65 alumnos. La formación teórica básica de la asignatura PGSI ha ocupado un total 12 horas lectivas. El proceso seguido fue el siguiente: • Formación en la mejora y definición de

procesos, impartida a lo largo de tres clases con un total de 6 horas.

• Formación especifica del proceso de planificación de proyectos, impartida a lo largo de tres clases, habiéndose impartido un total de 6 horas.

• Para los grupos que fueron a utilizar la herramienta se les impartió una sesión de uso de la herramienta de 1 hora y también disponían de manuales on-line.

La práctica de la asignatura consistía en la definición de un proceso de gestión de proyectos que debía implantarse en una PYME de 24 personas cuya estructura organizativa había sido simulada para la realización de a práctica. El proceso debía seguir los requisitos establecidos en PMBOK y CMMI. Los 65 alumnos presentes en prácticas se dividieron en dos grupos. Quedando la configuración siguiente: • 32 Alumnos que utilizaron Ramala agrupados

en 8 grupos. • 33 Alumnos que no utilizaron Ramala

agrupados en 8 grupos. Cada miembro del equipo informó de la actividad realizada mediante una hoja de cálculo, donde se detallaba el consumo de tiempo de cada actividad.

5.1. Análisis de la mejora su comprensión de los conceptos teóricos de una buena gestión integral de proyectos software

Para evaluar la mejora para la comprensión de los conceptos teóricos de una buena gestión integral de proyectos software que proporciona RAMALA, se han analizado los datos recogidos de los cuestionarios de evaluación subjetiva. Este estudio se divide en dos aspectos diferentes: • Capacidad de representación. • Capacidad de evaluación El número de encuestas procesadas en el momento actual corresponde a 65 alumnos de PGSI. Indicar que todos los encuestados conocían métodos de mejora y que todos ellos han valorado positivamente la herramienta. A continuación se analizará, por separado, cada uno de los aspectos mencionados anteriormente. A) Capacidad de representación Estos aspectos se han estudiado mediante el análisis de las respuestas ofrecidas a las preguntas 1, 2, 3, 4 y 5. A nivel general, la capacidad de representación de la herramienta se ha considerado elevada y capaz de cumplir con los requisitos del modelo de tal manera que la mayor parte de las respuestas ofrecidas se encuentra entre los valores “Totalmente de acuerdo” y “De acuerdo en líneas generales”. B) Capacidad de evaluación Este aspecto se puede estudiar mediante el análisis de las respuestas ofrecidas a la pregunta 6. Si se estudia la pregunta 6, se obtiene que los resultados de la evaluación de la herramienta Ramala, el 37,5% de los que ofrecieron respuesta se declararon “Totalmente de acuerdo” y el 62,5% restante estuvo “De acuerdo en líneas generales” con la facilidad de interpretación de los resultados. C) Validez de los resultados obtenidos Este aspecto se ha estudiado mediante el análisis de los resultados obtenidos. Para ello, se parte del hecho consistente en que si los resultados obtenidos tienen una gran disparidad, su validez podría ser cuestionada, haciéndose imprescindible una indagación para la confirmación de los resultados obtenidos.

252 Ingeniería del software A ¿Qué puesto ocupa en la organización? SI NO

B ¿Conoce alguna otra herramienta de mejora relacionada con los procesos de gestión de proyectos

Mejora importante

Equivalente a otros métodos

Peor que otros

C En caso afirmativo, ¿cómo valoraría la herramienta propuesta en relación con las herramientas conocidas?

Respuesta Totalmente

de acuerdo De acuerdo en líneas generales

Poco de acuerdo

Totalmente en desacuerdo

NS/NC

1 La herramienta me permite definir el marco de procesos de una manera clara Comentarios

2 La herramienta me permite definir elementos de un proceso desde la entrada hasta la salida Comentarios

3 La herramienta me permite introducir las métricas que me pueden servir para controlar el proceso 4 La herramienta me permite identificar los procesos en cada proyecto de una manera clara Comentarios

5 La lista de activos recogidos por la herramienta me pueden ser útiles Comentarios

6 Los resultados de la evaluación me son fáciles de interpretar y me ayudan a tomar decisiones Comentarios

Figura 4. Encuesta de evaluación subjetiva

Se puede observar que la mayor parte de las desviaciones oscilan entre el rango de 0,66 y 0,44, valores aceptables lo cual asegura su validez. Sin embargo la pregunta número 2 “La herramienta permite definir elementos de un proceso desde la entrada a la salida”, la desviación típica alcanza un valor de 1,29, indicativo que es necesaria una indagación adicional para verificar su validez.

5.2. Análisis de la mejora en la productividad y calidad en los trabajos prácticos realizados por los alumnos

Para realizar el análisis de la mejora en la productividad y calidad en las prácticas realizadas por los alumnos se ha decidido realizar un estudio

analítico de los trabajos proporcionados por los alumnos. El principal requisito relacionado con esta experimentación consistía en que todos los grupos establecieran un proceso de gestión de proyectos software con un nivel de calidad final similar, todos ellos sobrepasando un nivel mínimo prefijado en el comienzo del curso. Este nivel de calidad mínimo está fijado en una evaluación positiva (por encima del 75%) de los procesos de gestión de proyectos software establecidos siguiendo el método de evaluación SCAMPI[11]. Se ha elegido este modelo para asegurar que el nivel mínimo de calidad ofrecido por los trabajos sea extrapolable a otros centros de estudios de grado u organizaciones de desarrollo de software.

70%

74%

78%

82%

86%

90%

94%

98%

Sin RAMALA Con RAMALA

Figura 5. Calidad del trabajo de los alumnos


Como conclusión final se ha obtenido que los niveles de calidad de los trabajos realizados son los siguientes: • Los niveles de calidad obtenidos, tanto si se

utiliza RAMALA como si no, se pueden considerar equiparables (todos mayores del 75%), aunque en esta experiencia práctica, los grupos que utilizaron RAMALA consiguieron, por término medio, mejores resultados.

• El hecho de que el nivel de calidad sea equiparable tanto si se utiliza RAMALA como si no, asegura que el estudio de la productividad facilitada por RAMALA sea válido (a parecidos niveles de calidad demostraremos que el esfuerzo necesario utilizando RAMALA es menor).

• Una de las conclusiones más claras de este trabajo de innovación docente consiste en que el esfuerzo necesario para establecer en una organización un proceso de gestión de proyectos software es menor en caso de utilizar el modelo y el software RAMALA.

En la tabla 1 se muestra el esfuerzo acumulado para los seis grupos de alumnos que han trabajado “sin Ramala” y que han acumulado un esfuerzo de 62.099 minutos (1034 horas). El esfuerzo total de los grupos que han utilizado la herramienta Ramala fue de un total de 44.706 (745 horas).

Número Grupos

Tiempo (minutos)

Promedio (minutos)

Sin Ramala 6 62099 10349,8

Con Ramala 7 44706 6386,5

Tabla 1. Esfuerzo General

Se ha utilizado el diagrama de cajas y bigotes (“Box-and-Whisker plot”) para representar la distribución de los esfuerzos de los grupos según categoría. En este tipo de diagrama, la caja central indica el rango en el que se concentra el 50% central de los datos. Sus extremos son, por lo tanto, el 1er y 3er cuartil de la distribución. La línea central en la caja es la mediana. El resultado obtenido se presenta en la figura 5.

Estos resultados indican que la distribución de esfuerzo necesario para establecer un proceso de gestión de proyectos software con RAMALA es, por término medio, inferior al necesario en caso de no utilizar la herramienta. En caso de utilizar RAMALA la mediana se sitúa en los 4.000 minutos, mientras que si no se utiliza este indicador se establece en 9.000 minutos.

Comparativa de esfuerzos

0 3 6 9 12 15(X 1000)

Con Ramala

Sin Ramala

Figura 6. Distribución de esfuerzos

Además, el esfuerzo mínimo necesario para establecer un proceso es inferior en caso de utilizar RAMALA que si no se utiliza. Sin embargo, se ha detectado que los esfuerzos son más dispersos en caso de utilizar RAMALA, hecho que se ha debido a que, para algunos equipos de trabajo, la usabilidad de la herramienta RAMALA debería mejorarse para aumentar la efectividad de la misma. Si se analizan independientemente los resultados por fase (análisis de la situación actual, diseño de los nuevos procesos, implantación de la mejora y gestión de las actividades de mejora) se obtiene que el esfuerzo en las fases de análisis de la situación actual y definición de los nuevos procesos, por término medio, es menor si se utiliza RAMALA. El esfuerzo mínimo también es inferior usando RAMALA, aunque el máximo es similar tanto si se utiliza RAMALA como si no. Sin embargo, el esfuerzo de la implantación de la mejora, si se utiliza RAMALA, es muy inferior al equiparable a otras actividades de implantación realizadas sin el soporte de RAMALA.


6. Conclusiones y futuras líneas de trabajo

Como conclusión a este trabajo de innovación docente, se puede concluir que: • Se ha definido y desarrollado un modelo y un

software para la docencia gestión integral de procesos software basada en una base de conocimiento que permite a los alumnos, evaluar y definir sus procesos de gestión de proyectos. Esta base de conocimiento:

- Tiene al PMBOK como su estructura estándar de procesos.

- Los procesos en esta estructura se detallan utilizando las mejores prácticas de los diferentes modelos de referencia software como CMM, CMMI y SPICE. El resultado es una meta definición del proceso de gestión de proyectos software.

- Los procesos detallados se enriquecen con diferentes activos pertenecientes a las metodologías más destacadas en la gestión de proyectos.

• En cursos anteriores de planificación y gestión de sistemas informáticos, se había detectado que el esfuerzo necesario para realizar las prácticas era muy alto en relación a la carga docente de la asignatura. A partir del análisis realizado de la aplicación de RAMALA, se puede afirmar que la herramienta permite reducir el esfuerzo necesario para realizar prácticas con un nivel de calidad alto, ajustando el esfuerzo necesario a la carga docente de la asignatura.

Con el propósito de mejorar los resultados obtenidos en sucesivos cursos, se han establecido las líneas de trabajo futuras: • Extender el modelo RAMALA de manera que

incluya otras áreas del proceso software a parte del área de gestión de proyectos, lo que supone: - Establecer estructuras de proceso. - Integrar las nuevas estructuras de proceso

con la estructura del modelo RAMALA. • Definir un módulo para que se puedan definir

los procesos gráficamente siguiendo la notación Erikson-Pencker [7].

Referencias

[1] García Guzmán, J. Aproximación formal para la mejora de procesos software, Tesis Doctoral, Universidad Carlos III de Madrid, Noviembre 2001.

[2] Institute of Electrical and Electronics Engineers. ANSI/IEEE Std. 1074-1991, IEEE Standard for Software Life Cycle Processes. The Institute of Electrical and Electronics Engineers, New York: IEEE Computer Society, 1991.

[3] ISO 12207, International Organization for Standardization, ISO/IEC Std. 12207, Information Technology – Software Life Cycle Processes, 1995.

[4] ISO 15504, International Organization for Standardization, ISO/IEC Std.15504, Software Process Improvement and Capability dEtermination, 1997.

[5] Paulk M., Garcia S., Chrissis M., and Bush M. Capability Maturity Model for Software, Version 1.1, CMU/SEI-93-TR-24. Technical Report. Software Engineering Institute. Carnegie Mellon University, 1993.

[6] Paulk M., Garcia S., Chrissis M., and Bush M. Capability Maturity Model for Software, Version 1.1, CMU/SEI-93-TR-25. Technical Report. Software Engineering Institute. Carnegie Mellon University, 1993.

[7] Penker M. and Ericson H. “Business Modeling With UML”, OMG Press, 2000.

[8] Pfleeger S. “Software Engineering: Theory and Practice”. Prentice-Hall, 1998.

[9] Phillips M. “CMMI V1.1 Tutorial”. Software Engineering Institute. Carnegie Mellon University, 2003.

[10] Project Management Institute (PMI), “The Project Management Body of Knowledge (PMBOK)”, Project Management Institute, Upper Darby, PA, 1987.

[11] Software Engineering Institute. "CMMI for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS, V1.1)", Carnegie Mellon University, March, 2002.

Una propuesta de aprendizaje para el desarrollo orientado a objetos de proyectos software

Mª Carmen Penadés, Eliseo Marzal, Antonio Garrido Dpto. de Sistemas Informáticos y Computación

Universidad Politécnica de Valencia Camino de Vera, s/n. 46022 - Valencia

e-mail: {mpenades, emarzal, agarridot}@dsic.upv.es

Resumen Actualmente, el perfil profesional de Ingeniero del Software exige unas capacidades básicas que la universidad española debe potenciar. En este artículo se presenta una propuesta de aprendizaje para el desarrollo orientado a objetos de proyectos software como una alternativa flexible para garantizar dichas capacidades. Nuestra propuesta plasma cuáles son las habilidades que se deben satisfacer para cada capacidad, indicando además las actividades básicas para su consecución y cómo realizar su seguimiento. Tras analizar los resultados de una aplicación real de dicha propuesta, y examinar sus ventajas e inconvenientes, podemos afirmar que se trata de una propuesta eficaz y recomendable.

1. Motivación

El desarrollo de proyectos software es una de las competencias esenciales del informático con perfil profesional de Ingeniero del Software [2]. En la universidad española, esta habilidad se desarrolla en las asignaturas pertenecientes a la disciplina de la Ingeniería del Software. Así por ejemplo, en el plan de estudios de la titulación de Ingeniero Técnico en Informática de Gestión (ITIG) ofertada por la Universidad Politécnica de Valencia, UPV, (B.O.E. nº 259 de 17/10/2001), la asignatura de Ingeniería del Software de Gestión describe brevemente su contenido como: “Diseño, propiedades y mantenimiento del software de gestión. Planificación y gestión de proyectos informáticos. Análisis de aplicaciones de gestión”. A nuestro entender, la competencia que un alumno, futuro profesional de desarrollo de software, debe poseer es la de ser capaz de participar y desarrollar cualquiera de las actividades implicadas en las fases del ciclo de

vida de desarrollo de software [8], mediante el uso de diferentes metodologías y paradigmas de desarrollo. Sin embargo, esta competencia es demasiado genérica y debe concretarse en otras más sencillas [1]:

• Saber realizar eficazmente la administración

de proyectos software (gestionando tiempo, recursos, hitos, etc.)

• Saber diseñar la arquitectura del sistema a desarrollar, estableciendo sus elementos e interrelaciones.

• Tener un conocimiento amplio de las técnicas, métodos y herramientas de análisis, diseño y desarrollo.

• Saber realizar una implementación, total o parcial, utilizando distintos lenguajes de programación.

• Saber verificar y validar el producto para la aceptación del cliente, implantarlo y ponerlo en explotación.

La mayoría de las capacidades anteriores tiene

un carácter predominantemente práctico. Por lo tanto, la consecución de las mismas tiene importantes implicaciones en la forma de proponer y organizar el proceso de aprendizaje: el alumno debe jugar un papel fundamental, algo cada vez más necesario en el marco de un Espacio Europeo de Educación superior (EEES) [5], y esencial en el aprendizaje del desarrollo de proyectos software.

Basándonos en nuestra experiencia como docentes en asignaturas de la disciplina de Ingeniería del Software [3][4], en este trabajo presentamos una propuesta de aprendizaje para el desarrollo de proyectos software siguiendo el paradigma orientado a objetos (OO). Hemos optado por la orientación a objetos debido a sus claras ventajas: i) mayor facilidad para modelar el

256 Ingeniería del software problema, ii) mayor disponibilidad de herramientas en todas las fases del desarrollo, y iii) se ha convertido en un estándar de facto ampliamente aceptado por las universidades y empresas, tanto nacionales como internacionales [1][2][7].

El artículo se organiza de la siguiente forma. El apartado 2 presenta nuestra propuesta de aprendizaje, desglosada en un conjunto de plantillas e indicando cuáles son los criterios de seguimiento y evaluación. En el apartado 3 se expone una aplicación real de dicha propuesta a una asignatura troncal que se imparte actualmente en la UPV. El análisis y discusión de los resultados se presenta en el apartado 4. Finalmente, el apartado 5 expone las conclusiones del artículo.

2. Una propuesta de aprendizaje

Nuestra propuesta de aprendizaje va encaminada a que el alumno sea capaz de realizar, desde un enfoque OO, un proyecto de desarrollo de software. Se hace especial hincapié en las actividades básicas del proceso, sin fijar ningún modelo de proceso específico. En esta propuesta, el alumno como sujeto activo, debe alcanzar la competencia citada anteriormente. Con este objetivo se han identificado un conjunto de conocimientos y habilidades que los alumnos deben adquirir y que hemos agrupado en capacidades. Se han identificado un total de seis capacidades básicas:

• Saber realizar un plan de proyecto software. • Saber hacer el modelado conceptual OO de un

sistema de información. • Saber hacer el diseño OO de un sistema de

información. • Saber hacer una implementación OO de un

sistema de información. • Saber diseñar casos de prueba. • Saber realizar una instalación y puesta en

marcha de un producto software desarrollado.

El desarrollo de la propuesta se basa en seguir el esquema: competencia, capacidad, habilidad y actividad. Alcanzar una competencia supone alcanzar las capacidades requeridas, que a su vez implica desarrollar las habilidades asociadas a cada capacidad. Finalmente, se definirán un

conjunto de actividades cuya realización ayudará al desarrollo de cada una de las habilidades.

En los siguientes apartados se desarrolla la propuesta, definiendo con mayor detalle cada una de las capacidades básicas identificadas. También se citan los criterios de evaluación, así como la importancia de un proceso de seguimiento.

2.1. Capacidades

Por simplicidad, hemos definido una plantilla que recoge el desarrollo de cada capacidad (ver Tabla 1). La plantilla consta de cuatro apartados. En primer lugar aparece el nombre de la capacidad a alcanzar. En segundo lugar, se indican los conocimientos previos o capacidades requeridas al alumno para poder desarrollar adecuadamente la capacidad en cuestión. El tercer apartado es el más importante pues supone el desglose de la capacidad en un conjunto de habilidades que el alumno debe ejercitar. Finalmente, aparece un apartado de resultados que indica el conjunto de artefactos que el alumno debe ser capaz de producir una vez alcanzada dicha capacidad.

Capacidad n Prerrequisitos Pn.1

. . . Hn.1 Hn.2

Habilidades

. . . Resultados

Tabla 1. Plantilla de definición de capacidades1

Es importante destacar en este punto que si un alumno no dispone de los conocimientos establecidos como prerrequisitos de una capacidad, existe una carencia. Ésta se debe subsanar para que no se convierta en un impedimento al desarrollar las habilidades específicas de la misma. La situación deseable es que dichas carencias se detecten lo antes posible. La solución más sencilla para que no afecten al proceso de aprendizaje de la capacidad en sí misma es que el prerrequisito pase a ser otra habilidad más a desarrollar.

1 Tanto las capacidades como los prerrequisitos y habilidades asociadas a cada una de ellas, aparecen etiquetadas con un número para facilitar su identificación y posterior referencia.


Capacidad 1 Saber realizar un plan de proyecto software Prerrequisitos - -

H1.1 Conocer en qué consiste la administración de proyectos software y sus principales características. H1.2 Conocer las principales tareas que desempeñan los administradores de proyectos software.

Habilidades

H1.3 Saber utilizar una herramienta de planificación para la elaboración de un plan de proyecto. Resultados Diagrama de Gantt, diagrama de recursos y diagrama de costes.

Capacidad 2 Saber hacer el modelo conceptual orientado a objetos de un sistema de información Prerrequisitos P2.1 Conocer los fundamentos del paradigma OO.

P2.2 Saber pensar y razonar sobre un problema de acuerdo con el paradigma OO. H2.1 Conocer los beneficios que aporta la construcción de modelos en la resolución de problemas. H2.2 Saber razonar sobre el sistema de información, a distintos niveles de abstracción. H2.3 Saber diferenciar el modelado conceptual del diseño de sistemas de información. H2.4 Conocer cuáles son los elementos esenciales que ha de proporcionar un método de modelado OO. H2.5 Conocer al menos una notación de modelado OO.

Habilidades

H2.6 Saber utilizar una herramienta que dé soporte a la notación de modelado OO vista. Resultados Modelos que den cuenta de la estructura, comportamiento y funcionalidad del sistema.

Capacidad 3 Saber hacer un diseño orientado a objetos de un sistema de información Prerrequisitos P3.1 Conocer los fundamentos del paradigma OO.

P3.2 Saber interpretar un modelo conceptual OO de un sistema de información. H3.1 Saber construir una solución software a partir de los resultados del modelo conceptual. H3.2 Conocer distintos patrones arquitectónicos. H3.3 Comprender el diseño software como un conjunto de objetos que interactúan entre ellos. H3.4 Saber diseñar un sistema siguiendo una arquitectura de tres capas o niveles. H3.5 Saber utilizar una herramienta que dé soporte a la notación de diseño OO vista.

Habilidades

H3.6 Saber utilizar una herramienta que permita el diseño de la interfaz gráfica. Resultados Arquitectura del sistema, diseño de objetos, diseño de mensajes y diseño de la interfaz gráfica.

Capacidad 4 Saber hacer una implementación orientada a objetos de un sistema de información Prerrequisitos P4.1 Conocer los fundamentos del paradigma OO.

P4.2 Conocer y saber interpretar un diseño OO de un sistema de información. H4.1 Conocer y saber utilizar un lenguaje OO. H4.2 Saber utilizar el polimorfismo y el enlace dinámico/estático en la implementación. H4.3 Saber construir programas y razonar sobre la ejecución y terminación de los mismos. H4.4 Conocer y saber utilizar un entorno integrado de desarrollo para construir un programa OO. H4.5 Saber implementar en un lenguaje de programación OO un diseño de objetos. H4.6 Saber implementar una arquitectura de tres niveles.

Habilidades

H4.7 Saber razonar por analogía para entender y reutilizar código dado. Resultados Producto software.

Capacidad 5 Saber diseñar casos de prueba Prerrequisitos P5.1 Saber interpretar un modelo conceptual OO de un sistema de información.

P5.2 Saber interpretar un diseño OO de un sistema de información. H5.1 Conocer los principales tipos de casos de prueba. H5.2 Saber detectar los casos de prueba para el sistema de información.

Habilidades

H5.3 Saber preparar los datos de prueba y extraer conclusiones en base a los resultados de las pruebas. Resultados Casos de prueba.

Capacidad 6 Saber realizar una instalación y puesta en marcha de un producto software desarrollado Prerrequisitos P6.1 Conocer el productos software desarrollado.

H6.1 Saber definir y configurar la instalación de un producto software. Habilidades H6.2 Saber hacer un manual de usuario y un manual de instalación.

Resultados Instalación del producto software, manual de usuario y de instalación.

Tabla 2. Capacidades a garantizar en nuestra propuesta

258 Ingeniería del software La Tabla 2 muestra la definición de todas las capacidades básicas identificadas en la propuesta, utilizando la plantilla definida en la Tabla 1. Para un mejor entendimiento de los prerrequisitos y habilidades que se detallan, debemos aclarar que se asume un conocimiento de los fundamentos del paradigma OO, previo al desarrollo de las capacidades básicas. Esto se ve reflejado, por ejemplo en la capacidad 2. Sus prerrequisitos son: conocer los fundamentos del paradigma OO (P2.1) y saber pensar y razonar sobre un problema de acuerdo con el paradigma OO (P2.2).

A partir de la información recogida en la Tabla 2, sólo falta definir el conjunto de actividades concretas que cada docente realizará para conseguir que los alumnos adquieran las capacidades requeridas para el desarrollo de proyectos software. Este paso se traduce en la aplicación de la propuesta a un contexto específico que dependerá de cada Universidad, de sus planes de estudios y de los propios docentes. En nuestro caso, en el apartado 3 se detalla su aplicación en una asignatura del actual plan de estudios de la UPV.

Llegados a este punto se plantea una cuestión clave, desde el punto de vista docente: ¿cómo evaluar si un alumno ha alcanzado las capacidades exigidas? La respuesta se basa en considerar dos aspectos: el seguimiento del proceso de aprendizaje y la evaluación del mismo una vez finalizado.

2.2. Seguimiento y evaluación

Desde un punto de vista docente, pensamos que dada una capacidad o conjunto de ellas, no sólo es importante que el alumno finalice su aprendizaje adquiriendo dichas capacidades, sino que también es importante el proceso seguido para alcanzarlas. Esta cuestión es mucho más relevante en el caso que nos ocupa, el desarrollo de proyectos software. Por ello, en nuestra propuesta, la evaluación se plantea como una evaluación de ambos aspectos. Se mide tanto los resultados parciales que se van alcanzando en el desarrollo de las distintas habilidades como el resultado final alcanzado. La nota final del alumno en el proyecto software es la suma de las notas obtenidas en la consecución de cada capacidad. De esta forma, al resultado final, es decir, al producto software, el docente le asigna una nota que no es más que otra

nota a considerar en el cálculo final. Se les pueden asignar distintos porcentajes a las notas obtenidas por capacidad, en función de las actividades concretas que se realicen y el tiempo que se dedique a las mismas.

En cuanto a la forma de evaluar cada capacidad, de forma general podemos decir que consiste en la realización de una prueba objetiva que demuestre la consecución de la misma. Sin embargo, una gran mayoría de habilidades tienen que ver con la construcción de un cierto artefacto software. Por ello, la evaluación propuesta no consiste sólo en la realización de pruebas objetivas que midan el conocimiento teórico, sino también el práctico.

La evaluación se realizará atendiendo a dos criterios: conocimientos teóricos y conocimientos prácticos asociados a cada capacidad. Existirán dos tipos de pruebas para medir dichos conocimientos: i) el examen teórico que, como su nombre indica, medirá la parte más teórica de la capacidad y podrá ser oral o escrito; y ii) los entregables, que servirán para evaluar la parte más práctica y se corresponderán con el artefacto o conjunto de artefactos que se deban desarrollar dentro de cada capacidad. Ambas pruebas serán evaluadas por el docente y puesto que los aspectos son complementarios, el peso de cada uno de ellos en la evaluación de cada capacidad debería ser del 50%. No obstante, se puede variar su peso, atendiendo a condicionantes concretos, que deberá plasmar cada propuesta. En nuestro caso, en el siguiente apartado, también se detallarán los pesos específicos que se han aplicado al seguir este método de evaluación, basado en nuestra experiencia anterior en otras asignaturas [6].

3. Una aplicación real: ISG

Esta propuesta de aprendizaje se está aplicando actualmente a la asignatura de Ingeniería del Software de Gestión (ISG). Es una asignatura troncal que se imparte en 3º curso de la titulación de ITIG. Su carga lectiva es de 12 créditos, repartidos en 6 créditos teóricos y 6 de prácticas de laboratorio. La asignatura es anual y su organización docente son 4 horas semanales (2 horas de teoría y 2 horas de prácticas). La asignación docente actual es de 2 profesores en teoría y 4 profesores en prácticas. En las clases teóricas, el método docente es lección magistral y


realización de problemas en el aula. En cuanto a las prácticas, éstas se realizan por parejas y cada grupo de laboratorio tiene un máximo de 38 alumnos.

Una descripción detallada de los contenidos teóricos y prácticos de ISG queda fuera del alcance de este artículo. Lo que exponemos a continuación es cómo se ha aplicado la propuesta de aprendizaje en esta asignatura, entre cuyos objetivos está el desarrollo de proyectos software.

En primer lugar, hemos clasificado las habilidades en función de un mayor contenido teórico o práctico, entendido este último como una necesidad de disponer y utilizar herramientas de apoyo para su consecución. Esta separación nos ha permitido ubicar las habilidades como parte de los contenidos vistos en las sesiones de teoría o de prácticas. Es necesario resaltar que en algunos casos la separación no ha sido trivial, puesto que en el desarrollo de software ambos conceptos guardan una estrecha relación. La Tabla 3 muestra el resultado de dicha separación, y en ella podemos ver la correspondencia entre las habilidades y las actividades que las desarrollan. Por ejemplo, las habilidades 1 a 5 relacionadas con la capacidad 2 (H2.1 – 2.5) se desarrollan en las clases teóricas, como parte de los contenidos del Tema 4 (Modelado OO) mientras que la habilidad 6 (H2.6) se adquiere en la Práctica 6 de tres sesiones (P6-A, P6-B y P6-C). Esta distribución de habilidades entre sesiones de teoría y prácticas supone cumplir la siguiente restricción: debe existir una sincronización temporal entre ambas sesiones. Antes de cualquier sesión de prácticas se ha visto la teoría necesaria. En el resto del apartado nos vamos a centrar en explicar con detalle lo que consideramos de más interés en la aplicación de la propuesta: la organización de las clases prácticas, los entregables que se realizan y el porcentaje de cada uno de ellos sobre la nota final. Durante el primer cuatrimestre de la asignatura, se realizan un total de 12-13 sesiones de prácticas (P1-P4) encaminadas a que los alumnos desarrollen habilidades directamente relacionadas con la programación OO, y el entorno de programación escogido (en nuestro caso Microsoft Visual C# .NET, por tratarse del entorno que posteriormente se utilizará en las asignaturas de la intensificación de Ingeniería del

Habilidad Actividad H1.1 – 1.2 T3.Administración de Proyectos

H1.3 P5. Planificación

H2.1 – 2.5 T4. Modelado OO

H2.6

P6-A. Diagrama de Clases P6-B. Casos de uso y Escenarios P6-C. Diagramas de Secuencia

H3.1 – 3.4 T5. Diseño OO

H3.1, H3.5 P7-A. Diseño de Clases

H3.4 P7-B. Diseño Arquitectónico

H.3.6 P7-C. Diseño IGU

H4.1 – 4.2 T1. Programación OO

H4.3 – 4.4 P1, P2, P3, P4. Programación OO

H4.5 – 4.7 H5.1 – 5.3

P8. Implementación

H5.3, H6.1 Entrega producto SW

H6.2 - -

Tabla 3. Desarrollo de habilidades

Software [9]). Estas sesiones también sirven para que los alumnos afiancen conocimientos ya adquiridos en otras asignaturas (prerrequisitos). En concreto, las habilidades H4.3 y H4.4 se ejercitarían en estas prácticas. El desarrollo del proyecto software se realiza durante el segundo cuatrimestre, y es durante este tiempo cuando realmente el alumno desarrolla las capacidades básicas identificadas en nuestra propuesta. Se les propone un caso de estudio que describe un cierto sistema de información, y los alumnos desarrollan las habilidades propuestas realizando una serie de prácticas que detallamos a continuación. Para ello se dispone de aproximadamente 13-14 sesiones.

En la primera práctica de este cuatrimestre (P5), los alumnos realizan la planificación del caso de estudio utilizando MS Project, analizando la viabilidad del proyecto con los recursos disponibles y costes obtenidos. Para esta práctica se dispone de 2 horas y el entregable es voluntario.

La siguiente práctica (P6) se dedica al modelado conceptual. La duración es de 6 horas y se utiliza como herramienta Rational Rose. Esta

260 Ingeniería del software práctica consta de tres sesiones (P6-A, P6-B y P6-C). En concreto, en la primera sesión (P6-A) los alumnos realizan el diagrama de clases en UML. En la segunda sesión (P6-B), realizan los casos de uso y los escenarios. Por último, en la tercera sesión (P6-C) se realizan los diagramas de secuencia. La valoración de esta práctica tiene un peso del 30% sobre la nota final.

Las cuatro siguientes sesiones se dedican al diseño de la aplicación. Las 8 horas se estructuran en tres sesiones (P7-A, P7-B y P7-C). La primera sesión (P7-A) se dedica al diseño de clases y atributos, disponiendo de 3 horas. En la segunda sesión (P7-B) se realiza el diseño arquitectónico, y más concretamente la capa de persistencia del sistema (el tiempo asignado es de 3 horas). Por último, en la tercera sesión (P7-C) se realiza el diseño de la interfaz gráfica (2 horas). El bloque de diseño de la aplicación tiene un peso del 30%.

A continuación, se realiza la implementación de los escenarios necesarios para el correcto funcionamiento de la aplicación (P8). Se dispone de 10 horas (5 sesiones) y se establece un hito en la tercera sesión con los escenarios que deberían estar implementados hasta ese momento. Al finalizar las 5 sesiones se entrega la aplicación. Esta práctica tiene un peso del 40% en la nota del caso de estudio.

El profesor evalúa cada entregable, comunicando la nota a los alumnos y proporcionando una realimentación de los errores cometidos. Además de la clara ventaja de aprender de sus propios errores, los alumnos conocen en todo momento la parte de prácticas que tienen superada.

Tras la última sesión de prácticas se realiza la prueba y evaluación de la aplicación entregada. El profesor plantea una serie de casos de prueba para evaluar el correcto funcionamiento de la aplicación. Cada grupo de trabajo dispone de 15 minutos para probar su aplicación junto con el profesor.

En resumen, el alumno realiza un entregable voluntario (el de la práctica P5) y un total de 7 obligatorios (los correspondientes a las prácticas P6, P7 y P8).

4. Análisis y discusión de resultados

El objetivo de este apartado es realizar un análisis de las impresiones de la propuesta de aprendizaje

presentada en este artículo. En primer lugar, realizaremos un análisis cuantitativo basándonos en algunos de los resultados obtenidos en la aplicación de nuestra propuesta en la asignatura de ISG. Concretamente, analizaremos el grado de adquisición de las capacidades propuestas.

En la Figura 1 se muestran los primeros resultados de este análisis. Para ello, se ha comparado el número de alumnos que han adquirido las habilidades a desarrollar (considerados aptos) en cada uno de los 7 entregables obligatorios de las prácticas P6, P7 y P8, frente a los alumnos que no las adquirieron (no aptos) sobre una muestra total de 162 alumnos.

0%

20%

40%

60%

80%

100%

P6-A P6-B P6-C P7-A P7-B P7-C P8

Aptos No aptos Figura 1. Análisis de resultados de los entregables

obligatorios

Como puede observarse en la Figura 1, los resultados son bastante elocuentes. La inmensa mayoría (porcentajes superiores al 80-90%) de los alumnos demostraron las habilidades requeridas, obteniendo una calificación media de 7.12 (con una desviación estándar de 1.58). La calificación más baja, y por tanto la habilidad que les resultó más costosa fue la de “saber diseñar un sistema siguiendo una arquitectura de tres capas” (P7-B). Hasta cierto punto, esto es razonable pues para los alumnos resulta totalmente nuevo el planteamiento de la arquitectura de un desarrollo software. Por el contrario, la calificación más alta, y por tanto las habilidades que les resultaron más sencillas de asimilar fueron la de “saber construir una solución software a partir del modelo conceptual” y “saber utilizar una herramienta que dé soporte al diseño OO” (P7-A). Esto pone de manifiesto que la elección de una metodología OO supone un acierto a medio-largo plazo, tanto por su importante repercusión en el ámbito profesional como en el ámbito docente.


En la Figura 2 se presenta la distribución de

calificaciones. En este caso, se indican los porcentajes de alumnos que han obtenido las distintas calificaciones tras realizar las pruebas para evaluar sus habilidades teóricas y prácticas. En dicha figura se observa cómo claramente las capacidades prácticas se asimilan mejor, obteniéndose mejores calificaciones. Concretamente, en las capacidades prácticas el índice total de alumnos aptos fue del 90.71%, frente al 68.52% que fue el índice en las capacidades teóricas. Además, también es significativo que el 65% de los alumnos obtuvo una calificación superior al aprobado en las pruebas de habilidades prácticas, mientras que este porcentaje fue sólo del 37% en las pruebas teóricas. De nuevo, esto pone de manifiesto que en una propuesta de aprendizaje para el desarrollo de proyectos software, fomentar el trabajo práctico resulta esencial.

0%

10%

20%

30%

40%

50%

60%

Suspenso Aprobado Notable ExcelenteRango de calificaciones

Capacidades teóricas Capacidades prácticas Figura 2. Comparación en el rango de calificaciones de

las habilidades teóricas y prácticas

Si realizamos un análisis cualitativo de nuestra propuesta de aprendizaje, podemos diferenciar una serie de ventajas e inconvenientes. Las ventajas más destacadas son:

• Existe una realimentación del alumno al ir

conociendo su evolución (y resultados de las prácticas) de forma periódica. Esto favorece e incrementa la participación del alumno en el proceso de aprendizaje, haciendo que su comportamiento sea más activo y dinámico.

• Los alumnos aprenden más y mejor. Este modo de trabajo les permite asimilar más fácilmente los conceptos necesarios para alcanzar sus capacidades, además de hacerlo de una forma eficiente.

• Los alumnos aprenden en un escenario más realista, donde existe una mayor interacción con el profesor (que actúa en el rol de cliente).

• Los alumnos conocen de primera mano el proceso de desarrollo de un proyecto software. La puesta en práctica de las actividades básicas, trabajar en equipo, respetar plazos de entrega, conseguir objetivos, obtener beneficios (no económicos pero sí en cuanto a su calificación), etc., les permitirá convertirse en futuros profesionales más capacitados.

No obstante, también hay que ser realista en la

definición de la propuesta y reconocer la existencia de algunas desventajas: • El profesor se enfrenta a una inercia

importante en la forma de trabajar del alumno. Tradicionalmente, el alumno no suele jugar un papel tan activo en su proceso de aprendizaje y poner en marcha esta propuesta resulta un poco duro (e incluso frustrante algunas veces), especialmente en sus primeras etapas.

• El seguimiento y evaluación del proceso de aprendizaje en esta propuesta representa una ardua tarea para el profesor. La realización de muchas prácticas con entregables supone una sobrecarga importante en las tareas de corrección.

• Proponer una planificación tan estricta al alumno dificulta, algunas veces, el desarrollo de su capacidad de planificación. De hecho, se ha dado el caso de que prácticas con un plazo de entrega más estricto tienen un mayor porcentaje de alumnos presentados, mientras que aquéllas en las que los plazos son más relajados (sin tantos entregables intermedios), el porcentaje de alumnos presentados es menor. Por lo tanto, es importante que el profesor proporcione actividades al alumno para fomentar su autoplanificación.

Finalmente, teniendo en cuenta las ventajas,

inconvenientes, apreciaciones personales tras su aplicación real y resultados anteriores, consideramos que esta propuesta de aprendizaje resulta una alternativa altamente recomendable

262 Ingeniería del software para el aprendizaje del desarrollo OO de proyectos software. El estudiante adquiere conocimientos básicos, sobre los cuales, posteriormente puede ir asimilando más fácilmente conocimientos más específicos (dependientes del proceso seguido y de la metodología y/o tecnología utilizada) que cursará en otras asignaturas relacionadas con la materia de ingeniería del software.

5. Conclusiones

En este artículo hemos presentado con detalle una propuesta para facilitar el aprendizaje del desarrollo OO de proyectos software. La viabilidad de esta propuesta viene contrastada por los resultados obtenidos y por este motivo sigue actualmente en curso. Una clara ventaja de esta propuesta es que resulta flexible y abierta a cambios. Por ejemplo, en un curso académico como el actual en el que se disponen de menos semanas lectivas, su adaptación es sencilla, permitiendo una aplicación prácticamente directa que no conlleva serios problemas.

Las prácticas propuestas permiten desarrollar correctamente las habilidades necesarias. Esto permite cumplir las expectativas de lo que el mercado laboral espera de los futuros ingenieros del software. Adicionalmente, la forma en la que se desarrollan dichas prácticas se aproxima a la idea de un marco de educación superior (EEES): prácticas en grupos, mayor independencia por parte del alumno, autosuficiencia en el proceso de aprendizaje, mejor seguimiento (entregables realizados) y una realimentación constante de los resultados obtenidos (corrección y comentarios de los mismos). No obstante, es importante resaltar que para una mejor aplicación de esta propuesta, el ratio profesor-alumnos debería ser mayor, contando con una menor cantidad de alumnos por profesor. Como ampliación a corto plazo, se desea desarrollar una plataforma común de comunicación para fomentar el trabajo colaborativo entre alumnos-profesor e intercambiar información y conocimientos.

Referencias

[1] ACM-IEEE. Computing Curricula 2001. En: http://www.computer.org/education/cc2001.

[2] Agencia Nacional de Evaluación de la Calidad y Acreditación (ANECA). Libro Blanco del Título de grado en Ingeniería Informática. En: http://www.aneca.es/modal_eval/conver_docs_titulos.html

[3] Canós, J.H.; Penadés, M.C.; Pelechado, V.; Sánchez, J. La Ingeniería del Software en los planes de estudio de la Escuela Universitaria de Informática de la UPV. Actas de las II Jornadas de Ingeniería del Software (JIS’97), 1997.

[4] Canós, J.H.; Penadés, M.C.; Pelechado, V.; Sánchez, J.; Ramos, I.; Gonzalez, A. La Ingeniería del Software en los planes de estudio: ¿dos perspectivas de una disciplina o más de lo mismo?. Actas de las IV Jornadas de Enseñanza Universitaria de la Informática (Jenui’98), 1998.

[5] European Ministers of Education, The European Higher Education Area - Bologna Declaration, Bologna on the 19th of June 1999.

[6] Garrido, A.; Penadés, M.C.; Pelechano, V. Un modelo de evaluación de prácticas en Laboratorio de Ingeniería del Software. Actas de las VII Jornadas de Enseñanza Universitaria de la Informática (Jenui 2001), 2001.

[7] Marcos, E.; Pérez-Chirinos, C. La orientación a objetos hoy. Monografía revista Novática, 143, 2000.

[8] Thayer, R.H. Software System Engineering: A Tutorial. Computer, 35(4), pp. 68-73, 2002.

[9] ETSIA. Titulaciones Oficiales. Plan 2001 (Intensificación en Ingeniería del Software). En: http://www.eui.upv.es/webei/la_escuela/ti tulaciones/ITIG01/optativas.php#INS

Docencia en la Gestión de Proyectos de Desarrollo de Software:

uso de la Dinámica de Sistemas

Ricardo Colomo Palacios, Ángel García Crespo, Antonio Amescua Seco Dpto. de Informática

Universidad de Carlos III de Madrid 28911 Leganés (Madrid)

e-mail: {ricardo.colomo, angel.garcia, antonio.amescua}@uc3m.es

Resumen La carencia de gestores competentes de proyectos de desarrollo de software ha sido detectada como uno de los problemas que pueden justificar la denominada “crisis del software”. Una de las soluciones que se apuntan para paliar este problema es el uso de simuladores basados en la dinámica de sistemas para entrenar a este tipo de gestores, necesitados de conocimientos teóricos y formación práctica para el desempeño superior de sus tareas. El presente artículo describe la experiencia docente llevada a cabo en el curso 2004/05 con un doble objetivo: primeramente, desarrollar de forma colaborativa modelos basados en la dinámica de sistemas y, en segundo lugar, utilizar los modelos desarrollados como vehículo experiencial para la formación de alumnos de último curso de Ingeniería Informática en las competencias propias de los gestores de proyectos de desarrollo de software.

1. Introducción

Boehm subrayó la importancia de la gestión de los proyectos de desarrollo de software afirmando que una gestión pobre puede aumentar los costes del software más rápidamente que cualquier otro factor [4], adicionalmente, recientes investigaciones demuestran la conveniencia del empleo de la dinámica de sistemas para la formación de gestores de proyectos de desarrollo de software [16], [18]. Muchas universidades forman a los estudiantes de ingeniería informática para la gestión de proyectos de desarrollo de software mediante lecciones de tipo conferencia

que no aportan la formación práctica, que, para este tipo de proyectos es tan necesaria, como difícil abordar. La simulación está a medio camino entre la clase teórica y la experiencia práctica, y ha sido adoptada por áreas profesionales diversas en campos como el militar, el del entretenimiento o el de la ingeniería civil. La gestión de proyectos de desarrollo de software es altamente compleja, comparable al pilotaje de aviones en condiciones difíciles [16]. Algunas de las competencias que se desarrollan con este tipo de simulaciones son las relativas a planificación, seguimiento y control, mientras que otras competencias, como el liderazgo, la comunicación o el trabajo en equipo, necesitan de otros métodos de entrenamiento.

Teniendo en cuenta, por una parte las carencias de la formación práctica de gestores de proyectos de desarrollo de software, y por otra, los beneficios del uso de herramientas de simulación para la educación en Ingeniería Informática, se ha implantado dentro del marco de una asignatura optativa de quinto curso en la Universidad Carlos III de Madrid la utilización de dinámica de sistemas para la simulación de situaciones relativas al rol de gestor de proyectos.

El artículo, tras realizar una introducción teórica de la Dinámica de Sistemas en el apartado 2, describe la asignatura marco de la iniciativa en el apartado 3, expone los resultados docentes en el punto 4 y concluye en el apartado 5 con las principales conclusiones y mejoras al modelo y su aplicación.


264

2. Dinámica de Sistemas

2.1. Origen y aplicaciones.

La Dinámica de Sistemas nace a finales de los años 50 cuando Jay Forrester del M.I.T. estudia por encargo de General Electric la demanda de una planta situada en Kentucky. De su análisis surge el artículo “Industrial Dynamics a major Breakthrough for decision makers” [9] que posteriormente se amplía en el trabajo “Industrial Dynamics” [10]. El propósito de la Dinámica de Sistemas es facilitar la comprensión de la relación entre el comportamiento del sistema a lo largo del tiempo y su estructura, políticas y reglas de decisión [23]. La dinámica industrial, denominación adoptada por Forrester, se transformó en Dinámica de Sistemas en el momento en que se comenzó a usar en diferentes áreas que poseían un sistema continuo: desarrollo urbano, sociología o economía. Actualmente la Dinámica de Sistemas tiene numerosas aplicaciones en ámbitos científicos, sociales o de negocio [5], para lo que ha resultado crucial la aparición de paquetes de software (VenSim, iThink, Powersim Studio...) que han simplificado la codificación de los modelos gracias al empleo de elementos gráficos que sustituyen las sentencias tipo FORTRAN de las primeras herramientas (Dynamo, SimScript, GPSS…).

2.2. La dinámica de sistemas en los proyectos de desarrollo de software.

La aplicación de la dinámica de sistemas en la gestión de proyectos de desarrollo de software tiene su origen en el uso para la gestión de proyectos de la dinámica de sistemas iniciada por Roberts en 1964 [20]. Tomando como referencia la línea de investigación del profesor Roberts, la primera aplicación de la dinámica de sistemas al proceso de desarrollo de software es el modelo desarrollado por Abdel-Hamid y Madnick [1]. El modelo, que plasma los elementos de gestión para un proyecto pequeño o mediano de desarrollo de software utilizando el modelo de construcción en cascada, ha servido de base para numerosos modelos posteriores, que tratan, bien de

complementar el modelo general mediante su aplicación en una determinada organización [13], [14], [22] o bien analizar y resolver problemas de gestión específicos [7], [15], [6], [2].

Mención aparte merece el denominado “Modelo Dinámico Reducido” [21]. El modelo desarrollado en España por investigadores de la Universidad de Sevilla, es obtenido por simplificación del modelo de Abdel-Hamid y Madnick [1], alcanzando la reducción de los diferentes factores un 51%. De esta forma, dada su simplicidad es en especial útil a la hora de mostrar a personal novel en gestión de proyectos de desarrollo de software el comportamiento básico de un proyecto de estas características.

2.3. Los modelos de Dinámica de Sistemas aplicados a la formación de gestores de proyectos de desarrollo de software.

El potencial de los simuladores para el entrenamiento de gestores está plenamente justificado [18]. Los entornos de tipo “simulador de vuelo” enfrentan a los gestores con situaciones reales lo que les permite formarse sin los riesgos del mundo real. El uso específico para el entrenamiento en proyectos de desarrollo de software cuenta con experiencias plenamente documentadas. Por una parte, la Australian Computer Society auspicia desde 1994 un simulador del tipo “Juego de Guerra” sobre la temática del desarrollo de software que es actualmente utilizado por diversas firmas de consultoría locales para la formación de sus gestores de proyecto [24].

En el ámbito universitario se ha demandado la presencia de dinámica de sistemas en la totalidad de los estudios de ingeniería [19] y más concretamente en el ámbito de la Ingeniería del Software, diversos autores han implantado con éxito el uso de la dinámica de sistemas para la educación universitaria en la Ingeniería de Software, tanto en Europa [18] como en Estados Unidos [3], [16].

Sin embargo, la probada valía de la modelación para la formación de los gestores de proyectos de desarrollo de software no ha servido para incluir en la recomendación curricular de la Ingeniería del Software [12] (la más reciente de las que constituyen el esfuerzo curricular conjunto de ACM e IEEE relativo a la Informática)

XI Jornadas de Enseñanza Universitaria de la Informática

265

materias relativas a la dinámica de sistemas aplicada a la gestión de proyectos de desarrollo de software.

2.4. Enseñanza de la Dinámica de Sistemas en la educación superior en España.

La enseñanza de la dinámica de sistemas en entornos universitarios para programas de primer y segundo ciclo tiene una distribución limitada. Los campos por los que se extiende su docencia abarcan tanto las ingenierías como los relacionados con la gestión de recursos naturales o biológicos y la simulación del comportamiento humano.

La dinámica de sistemas es aplicada en la docencia de la Ingeniería Informática tanto técnica como superior generalmente para ilustrar la simulación de sistemas continuos mediante los diagramas de Forrester y los causales. Ejemplos de este tipo de docencia son los que se imparten en la Universidad de Málaga, Huelva, Alicante o Almería, entre otras universidades españolas.

En lo que al uso de la dinámica de sistemas para los proyectos de desarrollo de software se refiere, dos iniciativas docentes merecen ser mencionadas. Primeramente, la Universidad del País Vasco, a través de la asignatura optativa de segundo ciclo “Métricas y Modelos en la Ingeniería del Software” [25] apuesta por el entrenamiento en la gestión de proyectos utilizando las herramientas Stella y Vensim y en segundo lugar, la Universidad de Sevilla, cuenta con la asignatura troncal de quinto curso“Ingeniería de Software III” [26] en la que, entre otros contenidos, se aborda el modelo desarrollado por Abdel-Hamid y Madnick [1].

3. La asignatura “Control de la Producción Software”

‘Control de la producción software’ es una asignatura optativa cuatrimestral de quinto curso de 6 Créditos de la titulación: Ingeniero en Informática de la Universidad Carlos III de Madrid. El curso académico 2004/05 ha sido el primero en el que la asignatura se ha impartido, habiéndose matriculado un total de 12 alumnos.

El objetivo de la asignatura es dotar a los alumnos de mecanismos para el desempeño excelente del rol de Jefe de Proyecto mediante la

identificación, definición y evaluación de los parámetros cruciales para la gestión de un proyecto software. Dichos parámetros, tanto cualitativos como cuantitativos, se extraen tanto de conceptos globales de las normas de estandarización como de los modelos de madurez para proyectos de desarrollo de software, y su aplicación tiene el objetivo de proporcionar al gestor un conjunto de factores que reflejen el estado del proyecto y le permitan controlar su avance.

3.1. Dinámica del curso

La asignatura tiene un carácter eminentemente práctico. Tras exponer profusamente el marco teórico expuesto anteriormente, se abordan los conceptos básicos de Dinámica de Sistemas y de los modelos específicos para proyectos de desarrollo de software: los modelos de Abdel Hamid [1] y el Modelo Dinámico Reducido [21]. Asumiendo la máxima del profesor Pestel, autor de la modelización del mundo en 1974 [17], que ha afirmado en alguna ocasión que la técnica de dinámica de sistemas se puede aprender en menos de veinticuatro horas, se ha diseñado un plan por el que el alumno debe entregar, utilizando para ello la herramienta VENSIM [27], primeramente ejemplos simplificados relacionados con la dinámica de los proyectos de desarrollo de software, para posteriormente construir de forma pautada su sistema de control de proyectos de desarrollo de software basado en un subconjunto de indicadores.

La experimentación con las variaciones que los distintos factores implican en la gestión de un proyecto de desarrollo de software supone una experiencia que constituye para el alumno su primera prueba situacional como Jefe de Proyecto, y le enfrenta ante circunstancias que fuera de un modelo dinámico, no se pueden reproducir de forma concurrente.

La nota final depende de diversos factores, entre los que destacan la implementación del modelo realizado utilizando la herramienta VENSIM [27] y el informe que debe elaborar en el que reproduce su solución a una situación concreta en la que inciden diversos factores del modelo. Los criterios numéricos de los diferentes


266

factores que determinan la nota del alumno se incluyen a continuación: • Participación (10%). • Modelización en VENSIM (50%) • Informe (30%) • Presentación oral (10%)

4. Resultados obtenidos

Los distintos grupos de alumnos han desarrollado diferentes modelos abordando la problemática de la gestión de proyectos de desarrollo de software, con especial atención a los aspectos de productividad, entre los que se encuentran la productividad grupal, la motivación, las capacidades y conocimientos de los integrantes del proyecto, y la diferenciación entre horas laborales y horas productivas.

Los diversos aspectos que se han modelizado utilizando la herramienta VENSIM [27] están presentes en las figuras 1, 2, 3, y 4 siendo extraídos de diversas publicaciones relacionadas con la gestión de proyectos de desarrollo software [8], [11] y de la experiencia de los alumnos en la realización de proyectos de desarrollo de software en diferentes momentos de la carrera.

Para la realización del modelo se han tomado como referencia los modelos citados [1], [21], simplificando en lo posible su complejidad, pero añadiendo aspectos relacionados con la motivación, del entorno laboral, y de la productividad personal y del equipo, como se muestra en la figura 1, cubiertos con menor profundidad por los modelos de de Abdel Hamid [1] y el Modelo Dinámico Reducido [21], y que se han considerado importantes para la formación de responsables de proyecto sensibilizados con las denominadas Soft Skills.

El primer modelo (figura 1) que los estudiantes desarrollan de modo colaborativo presenta cuatro variables de nivel que determinan el comportamiento del sistema:

• Trabajo restante • Trabajo realizado • Personal • Coste

Las variables, en función de los diferentes valores de las constantes permiten detectar el estado del proyecto y actuar de forma simulada sobre las constantes de modo que, bajo la premisa de la invariabilidad del plazo de entrega, los costes y el personal se verán modificados por las acciones que los alumnos emprenden en el entorno de la herramienta.

El modelo cuenta adicionalmente con 88 variables adicionales, entre las denominadas variables auxiliares, cuyos valores no dependen de sus valores en anteriores momentos de la simulación, y constantes, valores que no pueden ser modificados durante la ejecución de una simulación convencional. En este último caso, y con el objeto de servir de “simulador de vuelo” se han utilizado este tipo de objetos para que los alumnos experimenten con sus valores en las diferentes situaciones que se les presentan.

Un caso típico que contempla el modelo es el decrecimiento de alguno de los factores de motivación, típicamente salario, condiciones de trabajo o carrera profesional, que hace descender las horas productivas a través de su incidencia en la productividad, y en consecuencia, los costes. Otra de las contingencias que el alumno debe afrontar y modelizar es la disyuntiva entre la pérdida a corto plazo en la productividad originada por la formación en horario laboral, y los beneficios que reporta a medio plazo en el mejoramiento de capacidades, y por ende, de la productividad.

Como se ha señalado anteriormente, la focalización en los aspectos relacionados con la productividad, no ha permitido en el curso académico 2004/05 el crecimiento del modelo y la interconexión con factores como el reclutamiento o la movilidad del personal asignado al proyecto, que serán abordados en futuros años.

El número de alumnos matriculados en la asignatura, doce en total, posibilitó la creación de dos grupos de trabajo dedicados al desarrollo del modelo y permitió una supervisión y una colaboración alumno-profesor que cristalizó tanto en la calidad del modelo, como en la reducida tasa de ausentismo durante la docencia de la asignatura.


267

Tasa Formación

Vacaciones

Enfermedades

Asustos propios

Horas JornadaLaboral

compromisosempresa

Horas extraregaladas

Skills

Definicion deTrabajo y Roles

Dinámica delgrupo

Politica y Admin de laCía

SupervisiónRelación con el

Superior Condiciones deTrabajo

Salario

Relaciones con los compañeros

Posición Social

Seguridad

Logro

Otras bajas

Reconocimiento

Productividadgrupal

Idondeidad deFormación Inicial

Ocio en horas detrabajo

Experiencia

Horas Sindicales

Horas disponibles

ratio medio horasextras

Productividad Equipo

RT Seguridad

RT Posición Social

RT Vida Privada

RT Relaciones con los compañeros

RT Salario

Vida Privada

RT Condiciones deTrabajo

RT Relación con elSuperior

RT SupervisiónRT Politica y Adminde la Cía

Factores Higiene

FactoresMotivación

Motivación

Responsabilidad

Avance

Crecimiento

RT Logro

RT Reconocimiento

RT Responsabilidad

RT Avance

RT Crecimiento

Satisfacción

Horas noproductivas

trabajoinicial

planificado

pAnalistas

pProgramadores

pBecarios

clabAnalista

clabProgramadorclabBecario

cinfAnalistacinfProgramador

cinfBecario

Proyecto acabado

Fin de proyectoTiempo para

acabar<Time>

NecesidadesBrutas

TRABAJORESTANTE

TRABAJOREALIZADO

Flujo productivo

PERSONALEntrada

Salida

productividadnominal

RatioProductividad

Horas productivas

Total Personal

Coste horario promedioCoste horario total planificado

productividadcomposición equipo

nAnalistas nProgramadoresnBecarios

cLaboralcInfraestructura

COSTE TOTAL

Figura 1. Implementación del modelo de productividad


268

RequisitosPendientes

AnalistasNuevos Requisitos Cumplidos

NumeroAnalistas

Planificado


Programadores

RequisitosCompletados

Analistas

Analistas/Requisito·Mes

Requisitos Iniciales <ProductividadAnalistas>

<ProductividadProgramadores>

<FINAL TIME>

Programadores/Requisito·Mes


ProgramadoresCumplidosProgramadores

Requisitos aTransferir AP

Transferencia A-P

Requisitos aTransferir PB


Becarios


BecariosCumplidosBecarios

Becarios/Requisito·Mes

<ProductividadBecarios>

Trasferencia P-B

Nuevos Analistas Analistas Prescindibles

ProductividadMinima

NumeroProgramadores

PlanificadoNuevosProgramadores

Programadores Prescindibles

Numero BecariosPlanificadoNuevos Becarios Becarios Prescindibles

Figura 2. Presión y reductores

seg.social

COSTETOTAL

productividadbecarios

IRPF

horas acoste.analista

coste programador horas p

horas b coste becario

product total

productividadanalistas

productividadprogramadores

Errores Programación

coste total jefeproyecto

Jefe Proyecto horas jp

Coste totalanalistas

N. Analistas

Coste totalprogramadoresN. Programadores

Coste totalbecarios

N. Becarios

Coste Jefeproyecto

Costes Indirectos

%costes indmensuales


269

Figura 3. Efectos de la presión y sus reductores

Seguridad SociaCOSTETOTAL

ProductividadBecarios

IRPF

HorasAnalista/Mes

CosteAnalista/Hora

CosteProgramador/Hora

HorasProgramador/Mes

HorasBecario/Mes

CosteBecario/Horas

ProductividadTotal

ProductividadAnalistas

ProductividadProgramadores

ErroresProgramación

Coste Total JefesProyecto/Mes

N. Jefe Proyecto

Horas JefeProyecto/Mes

Coste TotalAnalistas/MesN. Analistas

Coste TotalProgramadores/MesN. Programadores

Coste TotalBecarios/MesN. Becarios

Coste JefeProyecto/Hora

Costes Indirectos

% Costes IndirectosMensuales

CosteProductividad

Factor coste

Figura 4. Dimensionamiento de un proyecto en función del tipo de personal

5. Conclusiones

Si bien la inmersión de los profesores de la asignatura ha conllevado un elevado número de horas para la preparación de la misma, dividida en la búsqueda de información, aprendizaje de la herramienta, preparación de las clases teóricas y seguimiento del trabajo práctico de los alumnos, dicho esfuerzo se ha visto recompensado por los resultados obtenidos. La comprensión de los distintos parámetros con los que tiene que ‘jugar’ un gestor de proyectos y su interrelación han sido fácilmente transmitidos y comprendidos por los alumnos, aunque en determinados momentos veían la herramienta como un fin y no como un medio para analizar los factores. Pero una vez realizado el modelo y puesta en marcha la simulación, su interés aumentaba y podían

observar como una variación de alguno de los factores generaba situaciones en principio imprevistas que tenían la necesidad de gestionar.

Las simulaciones han permitido el debate entre los grupos de trabajo, aumentando la participación e interés del alumnado.

Referencias

[1] Abdel-Hamid T. K., Madnick S. E., Software Project Dynamics: An Integrated Approach, Prentice-Hall 1991.

[2] Aranda, R.R., Fiddaman, T. & Oliva, R., Quality microworlds: modeling the impact of quality initiatives over the software product life cycle. American Programmer, 6, 5, 52-61 1993.


270

[3] Baker, A.; Navarro, E.O. & van der Hoek, A. An Experimental Card Game for Teaching Software Engineering. Conference on Software Engineering Education and Training. 2003

[4] Boehm, B., Software Engineering Economics, Prentice-Hall. 1981.

[5] Cauldfield, C.W.& Paul Maj, S. A Case for system dynamics. Global Journal of Engineering Education, Vol 6 Nº 1, 2002.

[6] Chichakly, K.J., The bifocal vantage point: managing software projects from a systems thinking perspective. American Programmer, 6, 5, 18-25, 1993.

[7] Collofello, J.S.; Tvedt,J.; Yang, Z. , Merrill, D., & Rus I., Modeling Software Testing Processes, Proceedings of Computer Software and Applications Conference, 1995.

[8] Cuevas, G.: Gestión del Proceso Software. Centro de Estudios Ramón Areces. Madrid, 2002.

[9] Forrester, J. W. Industrial Dynamics: A Major Breakthrough for Decision Makers. Harvard Business Review 36(4):37-66. 1958

[10] Forrester, J.W., Industrial Dynamics. Waltham: Pegasus Communications, 1961.

[11] Herzberg, F.: One more time: How do you motivate employees?. Harvard Business Review, Sep – Oct 1987, pp 109-120.

[12] LeBlanc, R. & Sobel, A. K. Software Engineering 2004. http://sites.computer.org/ccse

[13] Lin C.Y., Walking on Battlefields: Tools for Strategic Software Management, American Programmer, Mayo 1993, pp. 33-40.

[14] Lin C.Y., Abdel-Hamid T., Sherif J.S., “Software-Engineering Process Simulation Model (SEPS)”, Journal of Systems and Software, 38, 1997, pp. 263-277.

[15] Madachy, R., System Dynamics Modeling of an Inspection-based Process, Proceedings of

the 18th International Conference on Software Engineering, Berlin, Germany, 1996.

[16] Merrill, D. & Collofello, J.S.. Improving Software Project Management Skills using a Software Project Simulator. Frontiers in Education Conference 1997.

[17] Mesarovic, M. &Pestel, E., Mankind at the Turning Point, The second Report to the Club of Rome, 1974

[18] Pfahl, D.;Koval, N. & Ruhe, G. An Experiment for Evaluating the Effectiveness of Using a System Dynamics Simulation Model in Software Project Management Education. Proceedings of the Seventh International Software Metrics Symposium. 2001

[19] Radzicki, M.J. & Karanian, B.A. Why every engineering student should study System Dynamics. Frontiers in Education Conference. 2002

[20] Roberts, E.B. The Dynamics of Research and Development. Tesis Doctoral, M.I.T., 1964

[21] Ruiz, M.; Ramos, I. & Toro, M. A simplified model of software Project dynamics. The journal of Systems and Software. 59, 299-309. 2001

[22] Smith BJ, Nguyen N, Vidale RF, "Death of a Software Manager: How to Avoid Career Suicide through Dynamic Software Process Modeling", American Programmer, May 1993, pp. 10-17.

[23] Wolstenholme, E.F., System Enquiry: a System Dynamics Approach. John Wiley & Sons, 1990.

[24] Yourdon, E. Death March. Prentice Hall. 2004

[25] http://www.sc.ehu.es/jiwdocoj/mmis/mmis-info.htm

[26] http://www.lsi.us.es/docencia/pagina_asignatura.php?id=16

[27] http://www.vensim.com

Propuesta de Contenidos para asignaturas sobre Calidad del Software y Sistemas de Información

Félix García, y Mario Piattini Grupo Alarcos

Escuela Superior de Informática Universidad de Castilla-La Mancha

13001 Ciudad Real e-mail: {Felix.Garcia, Mario.Piattini}@uclm.es

Resumen La calidad de los Sistemas de Información (SI) es un aspecto clave a considerar y constituye un objetivo estratégico en las organizaciones ante la competitividad del mercado actual. Debido a la importancia que la calidad del software está adquiriendo en las empresas, es fundamental que los futuros profesionales adquieran la formación necesaria. Para ello se deben ofertar en los planes de estudio de las titulaciones de Ingeniería en Informática asignaturas específicas que proporcionen un enfoque integrador de los aspectos relacionados con la calidad de los SI. En este artículo se analiza la situación actual en la docencia de la calidad del software en las Universidades españolas delimitando a partir de cuerpos de conocimiento como SWEBOK (Software Engineering Body of Knowledge) y CSQE (Certification Software Quality Engineer) las áreas que se deberían cubrir. Ante la necesidad de ofrecer asignaturas específicas sobre la calidad en la Ingeniería del Software se plantea el temario de la asignatura “Calidad del Software” y también se proponen los contenidos que se deberían incluir en una asignatura sobre “Calidad de los SI” que tendría un mayor alcance y englobaría, además de la calidad del software, otras dimensiones de la calidad de los SI.

1. Introducción

La calidad de los sistemas de información (SI) se ha convertido hoy en día en uno de los principales objetivos estratégicos de las organizaciones, debido a que cada vez más, los procesos principales de las organizaciones -y su supervivencia- dependen de los sistemas informáticos para su buen funcionamiento.

En la evolución experimentada por la calidad de los SI se ha pasado de un tratamiento centrado fundamentalmente en la inspección y detección de errores en los programas, a una aproximación más sistemática, dada la importancia que ha adquirido la calidad en la Ingeniería de Sistemas y en la Ingeniería del Software. En los últimos años se han publicado diversos estudios y estándares en los que se exponen los principios que se deben seguir para la construcción y mejora de productos y servicios de calidad como los estándares ISO 9000:2000 [12] e ISO 15504 [8], los modelos de madurez CMM [26], CMMI [27], etc. Todo ello ha influido de forma significativa en el papel que actualmente tiene la calidad en las organizaciones, que pasa a convertirse en una filosofía, una ventaja competitiva y una cultura que afecta a toda la organización. La demanda de software por parte de las organizaciones y, en general, de la sociedad ha crecido mucho más deprisa que la capacidad de la industria para producir software de calidad, haciendo crónica la denominada “crisis del software”. Desde hace varios años se viene insistiendo en esta crisis y en los desastres que los fallos de software pueden llegar a causar en las organizaciones [20; 28].

Todo ello motiva la importancia de ofrecer una formación en calidad de SI a los futuros ingenieros software. En este artículo proporcionamos una panorámica general sobre la docencia en la calidad del software/SI en las universidades nacionales estableciendo en primer lugar las áreas relacionadas con la calidad del software en base a dos propuestas de enseñanza: la primera más “académica” según el SWEBOK [32] y, la segunda, más “empresarial” de acuerdo a la ASQ (American Society for Quality) [2]; y en segundo lugar se analiza la cobertura que ofrecen las asignaturas a las distintas áreas. Además, ante

272 Ingeniería del software la necesidad de ofrecer una visión integrada de la calidad del software/SI a los alumnos de Ingeniería en Informática, se proponen las asignatura “Calidad del Software” y “Calidad de los SI”, analizando los contenidos que deberían incluir cada una de ellas,

2. SWEBOOK.

El cuerpo de conocimiento de la Ingeniería del Software SWEBOK [32] es un proyecto de la IEEE Computer Society (IEEE-CS) y actualmente se encuentra siendo debatido por el subcomité JTC1/SC7 para su aprobación como informe técnico (ISO TR 19759). Su principal objetivo es el establecimiento de un cuerpo de conocimiento de la Ingeniería del Software (IS) promoviendo una visión consistente del mundo de la IS, clarificando el papel de la IS respecto a otras disciplinas relacionadas y proporcionando las bases para el desarrollo de planes de estudios o materiales para certificaciones individuales.

Según la división del conocimiento de la IS que establece el SWEBOK en calidad del software se incluyen las técnicas estáticas de la calidad, es decir, aquellas que no requieren la ejecución del software que está siendo evaluado, mientras que las técnicas dinámicas se tratan en el área de conocimiento de pruebas del software. Este estándar divide a su vez la calidad del software de acuerdo a la siguiente estructura tal y como se representa en la Figura 1:

Calidad del Software

Fundamentos de la Calidad del Software

Consideraciones Prácticas

Procesos de Gestión de la Calidad del

Software

Ética y Cultura en Ingeniería del Software

Valor y Costes de la Calidad

Modelos y Características de la

Calidad

Mejora de la Calidad

Aseguramiento de la Calidad del Software

Verificación y Validación

Revisiones y Auditorías

Requisitos de Calidad de la Aplicación

Caracterización de Defectos

Técnicas de Gestión de Calidad en el Software

Medición de la Calidad Software

Figura 1. Descomposición de los temas del área de conocimiento Calidad del Software del SWEBOK

3. ASQ

La ASQ [2] es una asociación cuyo objetivo es “promover la mejora de los resultados de negocio en base al aprendizaje avanzado, la mejora de la calidad, y el intercambio de conocimiento”. Esta asociación profesional establece varias certificaciones sobe calidad en diferentes ámbitos de actuación. Para la certificación de Software Quality Engineer (CSQE) la ASQ establece un cuerpo de conocimiento que consta de varias áreas (ver Tabla 1):

Tabla 1. Cuerpo de Conocimiento de la ASQ

Áreas CSQE Materias A. Filosofía y Principios de la Calidad B. Estándares, Especificaciones y Modelos C. Herramientas y Habilidades de Liderazgo

I. Conocimiento

General, Conducta y

Ética D. Conducta Ética y Desarrollo Profesional A. Metas y Objetivos - Metas y Objetivos de la Calidad - Servicios subcontratados - Planificación - Documentación de Sistemas de Gestión de la Calidad SW - Requisitos del Cliente B. Metodologías - Revisión, Inspección y Pruebas - Métodos de Gestión del Cambio - Coste de la Calidad (COQ) - Seguimiento de los datos de la calidad - Informe de Problemas y Procedimientos de acciones correctivas - Procesos de Mejora de la Calidad

II. Gestión de la Calidad del

Software

C. Auditorías - Desarrollo y Administración de Programas

- Preparación y Ejecución de la Auditoría - Informe y Seguimiento de la

Auditoría A. Condiciones del Entorno B. Gestión de Requisitos C. Ingeniería de Requisitos D. Métodos y Herramientas de Análisis, Diseño y Desarrollo

III. Procesos de Ingeniería del Software

E. Gestión del Mantenimiento


Áreas CSQE Materias

A. Planificación B. Seguimiento y Control

IV. Gestión de Programas y

Proyectos C. Gestión de Riesgos A. Métricas y Teoría de la Medición B. Medición del Proceso y Producto

V. Métricas del Software, Medición y

Métodos Analíticos C. Técnicas Analíticas

A. Teoría B. Revisiones e Inspecciones C. Planificación y Diseño de Pruebas

VI. Verificación y Validación del

Software D. Ejecución y Evaluación de Pruebas A. Infraestructura de la Configuración B. Identificación de la Configuración C. Control de la Configuración D. Contabilización del estado De la Configuración E. Auditoría de la Configuración

VII. Gestión de la

Configuración del Software

F. Aspectos de Entrega y Distribución

4. La Docencia sobre Calidad del Software en las Universidades Españolas.

En este apartado se proporciona una panorámica general sobre la docencia sobre la calidad del software en las universidades españolas. Para ello, se han estudiado las asignaturas relacionadas, teniendo en cuenta la información disponible en las páginas Web de las titulaciones de informática a fecha de febrero de 2005. En primer lugar cabe destacar que en las universidades españolas en general se reducen los aspectos de la calidad del software propuestos por el SWEBOK a un par de temas dentro de las asignaturas de Ingeniería del Software o SI. Por los que respecta a las áreas del CSQE, las áreas III, VI y VII se suelen tratar con suficiente profundidad en las asignaturas antes mencionadas. El área IV se suele incluir en las anteriores o en la asignatura de Planificación/ Gestión de Proyectos/Sistemas Informáticos. Sin embargo, los apartados I y II apenas son tratados (con excepción del I.A y I.B en las universidades

que incluyen alguna asignatura sobre ética o deontología profesional) y el V muchas veces no lo es con la dedicación suficiente. En algunas universidades españolas se ofertan asignaturas que permiten profundizar en algunos aspectos de la calidad. Sobre estas asignaturas se ha realizado un estudio más detallado. Las universidades que ofertan tales asignaturas son: Universidad Politécnica de Valencia (UPV), Universidad del País Vasco (EHU), Universidad Politécnica de Madrid (UPM), Universidad de Sevilla (US), Universidad de Murcia (UM), Universidad de Valladolid (UV), Universidad de Zaragoza (UZ), Universidad Educación a Distancia (UE) y Universidad de Castilla-La Mancha (UCLM).

El primer paso del análisis realizado ha sido el de establecer el conjunto de áreas relacionadas con la calidad del software. En base a los contenidos del SWEBOK y del CSQE se han seleccionado las siguientes áreas: • Conceptos Básicos sobre la Calidad del

Software, en la que se proporciona una introducción a la calidad software incluyendo su definición y características generales, así como los beneficios que aporta a las organizaciones.

• Valor y Coste de la Calidad, que trata esencialmente de la evaluación de los costes de la calidad y su impacto sobre los productos y procesos. Los costes relacionados con la calidad pertenecen a las siguientes categorías: de prevención, de valoración, internos de fallos, externos de fallos [5].

• Modelos y Características de la Calidad del Software, que aborda los distintos estándares, especificaciones y modelos relacionados con la calidad del software donde se incluyen: modelos de calidad del producto como el de McCall [17] o los estándares ISO 9126-1 [10] e ISO 14598 [9]; modelos de calidad del proceso como los modelos de madurez CMM [26], CMMI [27], el estándar ISO 15504 [8] y otros modelos relacionados. También se incluirían en esta área la familia de normas ISO 9000:2000 [10] para certificación de calidad y modelos y propuestas de mejora de la calidad como TQM [1], IDEAL [18], etc.

• Gestión de la Calidad del Software, que incluye los aspectos relacionados con la planificación, evaluación y seguimiento de los


programas de calidad identificando los requisitos de personal y calendario necesarios para satisfacer los objetivos de calidad de la organización. Los procesos relacionados con la gestión de la calidad se tratan de forma separada en las áreas de aseguramiento de la calidad, revisión y auditoría y medición del software.

• Aseguramiento de la Calidad del Software, que incluye los contenidos relacionados con los medios necesarios para asegurar que el software satisface los requisitos del usuario [30].

• Revisión y Auditoría, que trata aspectos de revisiones, inspecciones y auditorías del software.

• Verificación y Validación, en la que se abordan tanto los aspectos de gestión de estas actividades como los métodos concretos de evaluación de productos para determinar si satisfacen los requisitos del usuario y los objetivos del proyecto.

• Medición del Software, que incluye el estudio de las métricas del software [3], tratando la medición del proceso, proyecto y productos. También se incluyen las metodologías y estándares relacionados con la medición como PSM (Practical Software Measurement) [19], ISO 15939 [11], etc., así como técnicas analíticas de evaluación de la calidad (diagramas, gráficos y herramientas) y aspectos de la fiabilidad software.

El siguiente paso en el análisis realizado ha consistido en estudiar si las asignaturas con contenidos relacionados con la calidad software (cuyas siglas se encuentran en la tabla 2) incluyen los aspectos tratados en las áreas propuestas.

Tabla 2. Siglas de las asignaturas estudiadas

Siglas Asignatura ACS Auditoría y Calidad del Software (UM) CSI Calidad de Sistemas de Información

(UCLM) CS Calidad del Software (UE/UV)

DSIC Desarrollo de Sistemas de Información Corporativos (UC3M)

ESI Evaluación de Sistemas de Información (UPM)

GC Gestión de la Calidad (UZ) IS3 Ingeniería del Software III (US)

MMIS Métricas y Modelos en la Ingeniería de Software (UPV/EHU)

PS El Proceso del Software (UPV) En la tabla 3 se resume la cobertura que en las

diferentes universidades se presta a estos contenidos, señalando además de las asignaturas que los tratan, si estos contenidos se contemplan prácticamente de manera total (T) o parcial (P).

Tabla 3. Tratamiento de las áreas relacionadas con la calidad de SI en algunas universidades nacionales

Asignaturas ÁREA

ACS CSI CS(UE) CS(UV) DSIC ESI GC IS3 MMIS PS 1. Conceptos Básicos

sobre Calidad SW – T T – – – P – – –

2. Valor y Coste de la Calidad – P – – – – P – – –

3. Modelos y Características de la

Calidad SW – T T – P – P – T P

4. Gestión de la Calidad SW – – P – P – P T P –

5. Aseguramiento de la Calidad Software – – P – P – – – – –

6. Revisión y Auditoría T – – – P T P – – –

7. Verificación y Validación – – – – P P – – – –

8. Medición del Software – T P P – – – P P P


Como se puede observar en la tabla 3, no existe un consenso en los contenidos impartidos por las distintas universidades españolas en relación a la calidad del software. En algunos casos sólo se incluyen en asignaturas de calidad del software aspectos como la auditoría, la medición o algunos modelos de referencia y en general no existen asignaturas en las que se traten con profundidad todos los aspectos relacionados con la calidad software. Tal y como se reconoce en el SWEBOK, los contenidos relacionados con la calidad abarcan casi todas las áreas de la Ingeniería del Software. Ello dificulta la posibilidad de abordar con profundidad la calidad del software en una única asignatura y por ello, los contenidos de asignaturas sobre calidad software se suelen complementar con los contenidos de otras asignaturas incluidas en los planes de estudios de las distintas universidades, como Ingeniería del Software, Planificación y Gestión de Proyectos, etc. Sin embargo es importante proporcionar a los futuros ingenieros en informática una visión integral de la calidad del software incluyendo todos sus contenidos relacionados, de forma que se analicen ampliamente sus aspectos más significativos y se proporcione una panorámica general del resto, que podría ampliarse con los contenidos de otras asignaturas relacionadas. En el siguiente apartado se presenta una propuesta con los contenidos que bajo nuestro punto de vista deberían tratarse en una asignatura sobre calidad en función del alcance que se le quiera dar.

5. Temario Propuesto.

Analizados los planes de estudio de las universidades y estudiados también los nuevos contenidos que aportan los principales libros del tema [4;13;14;16;25;30;31] proponemos dos temarios, según el alcance que se le quiera dar a la asignatura (que puede ser restringido a la calidad del software o ampliado hasta abarcar toda la calidad de un sistema de información).

5.1. Calidad del software

En la tabla 4 se presentan los contenidos que a nuestro juicio se podrían incluir en una asignatura sobre calidad del software:

Tabla 4. Propuesta de Temario para la asignatura “Calidad del Software”

Tema 1. Introducción a la Calidad Tema 2. Técnicas de Calidad Parte I. La

Calidad Tema 3. Modelos y Normas de Calidad Tema 4. Modelos de Calidad del Producto Software

Parte II. Calidad

del Producto Tema 5. Fiabilidad

Tema 6. Proceso Software Parte III. Calidad

del Proceso Tema 7. Evaluación y Mejora de Procesos Tema 8. Metodologías y Estándares de Medición Software

Parte IV. Medición

del Software Tema 9. Métricas del Software

Como se puede observar en la Tabla 4, el temario queda estructurado en cuatro bloques principales que permiten tratar los distintos aspectos relacionados con la calidad software. Dentro del primer bloque, en el primer tema se aborda la calidad desde un punto de vista introductorio aportando una visión de la calidad en general presentando su definición, evolución histórica, tipos de calidad, conceptos relacionados y los costes de la calidad para a continuación introducir la calidad en el software. El tema 2 se dedica a presentar las diversas técnicas y herramientas relacionadas con la calidad clasificándolas en herramientas básicas, de gestión, de creatividad, estadísticas, de diseño y de medición [21]. El siguiente tema está orientado a presentar los diversos estándares y modelos relacionados con la calidad desde un punto de vista general.

El segundo bloque aborda la calidad en el producto software. En el tema 4 se estudian modelos y normas concretos relacionados con la calidad del producto software y en el tema 5 se aborda de forma separada un factor significativo en la calidad de los productos software como es su fiabilidad, presentando los métodos y técnicas relacionadas.

El bloque III analiza la calidad de los procesos software. En el tema 6 se presenta una panorámica general de los procesos software abordando sus características generales y su gestión, dentro de la cual se presta una especial atención en presentar el

276 Ingeniería del software modelado y las tecnologías relacionadas con los procesos. El tema 7, por su parte, se centra en presentar las propuestas relacionadas con la evaluación y mejora de los procesos software en el contexto de las normas o modelos de madurez a los que pertenecen.

Finalmente en la parte IV se estudia la medición del software presentando en primer lugar las metodologías y estándares relacionados (tema 8) y a continuación en el tema 9 se proporciona una panorámica general a las propuestas de métricas del software existentes en la bibliografía, clasificándolas en función de si son métricas relacionadas con el proceso, los proyectos o los productos.

Con el temario propuesto se proporciona una cobertura adecuada a las áreas 1, 2, 3, 5 y 8 (ver tabla 3), ya que consideramos que en el contexto de la asignatura de calidad del software son aspectos no abordados con la profundidad necesaria en otras asignaturas del plan docente. Estos contenidos se complementa con los de las asignaturas: Planificación y Gestión de los SI, que incluye algunos aspectos de gestión de la calidad (área 4); Auditoría y Seguridad Informática que aborda de forma parcial el área 6, mientras que la verificación y validación (área 7) es tratada en las asignaturas de Ingeniería del Software.

El temario propuesto junto con los contenidos de otras asignaturas permitiría obtener a los futuros ingenieros en informática una visión completa de los aspectos relacionados con la calidad del software. Si se quiere proporcionar una panorámica más general de la calidad en el mundo de la informática estos contenidos se podrían ampliar mediante la introducción de una asignatura más completa denominada “Calidad de los SI”. Los contenidos de esta posible asignatura se analizan en el siguiente apartado.

5.2. Calidad de los Sistemas de Información

Suponiendo que los temas básicos relacionados con los SI se tratan en las asignaturas de SI, la asignatura de calidad de los SI debería proponer una visión holística de la calidad [29], en la que se consideren diferentes dimensiones (ver Figura 2).

La calidad del software es una dimensión esencial de la calidad de los SI, por lo que sus contenidos deberían incluirse en dicha asignatura (ver tabla 4). Sin embargo, la calidad del software no es la única dimensión de la calidad de los SI,

sino que también hay que considerar la calidad de la infraestructura (hardware, software de base, etc. mantenido y soportado por el SI); calidad de la gestión, que incluye los aspectos de gestión relacionado con la función de los SI; calidad de la información, que trata la calidad de los datos y de la información resultante de los SI; calidad de servicio, que aborda la calidad desde el punto de vista de los servicios que ofrecen los SI, incluyendo la calidad de los procesos de soporte, de los clientes y del personal implicado.

Calidad de los procesos

de negocio soportados por

SI

Calidad de la información

Calidad del software

Calidad de la infraestructura

Calidad de la gestión

Calidad del servicio

Calidad del personal

Calidad de la

empresaCalidad de SI



SI



SI

Calidad de la informaciónCalidad de la información



Calidad de la infraestructuraCalidad de la

infraestructura







Calidad de la

empresaCalidad de SI

Figura 2. Dimensiones de la Calidad

De acuerdo a los aspectos que tratan las distintas dimensiones de calidad de los SI, y teniendo en cuenta que la calidad de la gestión se abordaría en la asignatura de Planificación o Gestión de Proyectos, la asignatura de “Calidad de los SI” incluiría los siguientes temas: • Parte I. Calidad del software, que incluye el

temario de la asignatura “Calidad del Software” (ver tabla 4)

• Parte II. Calidad del personal. Se abordan dos temas fundamentales: - La calidad personal, basada en enseñar

a los alumnos como deben gestionar la calidad de sus proyectos cuando asumen su rol de ingenieros software. Para este tema se imparte la técnica PSP (Personal Software Process) [6] mostrándoles un enfoque disciplinado para el desarrollo de software.

- La calidad en equipo, fomentando la disciplina en el proceso y proporcionando las guías necesarias para el trabajo en equipo. Para ello se imparte TSP (Team


Software Process) [7]. Tal y como se indica en [22], al usar TSP como material didáctico de apoyo se fomenta el aprendizaje a través de la práctica obteniéndose importantes beneficios para los alumnos como: formación en el proceso de desarrollo incremental e iterativo; roles y responsabilidades bien definidos; incorporación de las métricas en el proceso de desarrollo; uso de técnicas de inspección y revisión de los productos; insistencia en la estandarización de la documentación y del código y análisis postmortem.

• Parte III. Calidad de la información. Como se indica en [24], cada vez hay más expertos tanto en el mundo académico como profesional que insisten en la necesidad de formar a los alumnos en Calidad de Datos. Para ello en este tema se imparte el “Information Quality Curriculum Model” (IQCM) [15] en el que los contenidos son: Introducción a los SI (IQ1), Gestión de los Datos (IQ2), Análisis de los requisitos de la Información y Diseño de Sistemas (IQ3), Proyectos de SI (Diseño físico e implementación) (IQ4) y Gestión de la Información (IQ5).

• Parte IV. Calidad del servicio, en la que se deben explicar, aunque no con demasiada profundidad, modelos como SERVQUAL [23], que cada día es mas utilizado en el ámbito de los SI y QUALIT, que combinan la calidad de servicio con la calidad de la información y de los sistemas [33].

• Parte V. Calidad de la infraestructura, en la que de forma muy general se presentan los aspectos de calidad en las infraestructuras del SI como las redes, hardware relacionado, etc. El contenido de esta parte se podría profundizar en otras asignaturas relacionadas con el área de Arquitectura e Ingeniería de Computadores.

6. Conclusiones

La calidad constituye aspecto fundamental en el mundo de la Ingeniería del Software, al igual que ocurre en otras ingenierías, en el que ocupa una posición estratégica y necesaria para ofrecer una mayor confianza al cliente sobre los productos y

servicios ofrecidos. Las diversas normas, estándares y metodologías relacionados con la calidad o aspectos de la calidad software están ofreciendo a las empresas y departamentos de desarrollo informático la posibilidad de adaptarse a una nueva forma de trabajo caracterizada principalmente por buscar la satisfacción de los clientes y disponer de una mejor visibilidad y control de la calidad de los procesos y de los productos finales. Ello posiciona la docencia de la calidad del software/SI como un tema importante a considerar en la formación de los futuros ingenieros en informática.

En este artículo hemos analizado el tratamiento de la calidad software en los principales currículos internacionales, así como los contenidos relacionados con la calidad que son impartidos en algunas universidades españolas. Como conclusión se puede afirmar que a la calidad del software no se le da toda la importancia que tiene para la correcta formación de profesionales de los SI. Habitualmente se incluye una introducción a la calidad como parte de las asignaturas relacionadas con la IS, pero en general no se incluye una asignatura que permita profundizar todos los aspectos relacionados con la calidad con el rigor y la extensión necesaria. Por ello, en este artículo se proponen los contenidos que deberían incluir las asignaturas sobre calidad en la IS, en concreto una asignatura sobre “Calidad en el Software” que podría ofertarse como optativa de segundo ciclo de 4,5 o 6 créditos. También se proponen los contenidos de una asignatura sobre “Calidad en los SI” que englobaría la calidad del software junto a otras dimensiones de calidad.

Referencias

[1] Arthur, L. J. Improving Software Quality: An Insider's Guide to TQM, John Wiley & Sons, 1993.

[2] ASQ, American Society for Quality. En http://www.asq.org/cert/types/csqe/bok.html

[3] Fenton, N. and Pfleeger, S. Software Metrics: A Rigorous & Practical Approach, Second ed, International Thomson Computer Press, 1998.

[4] Horch, J. W. Practical Guide to Software Quality Management, Artech-House Publishers, 2003.

278 Ingeniería del software [5] Houston, D. Software Quality Professional,

ASQC, 1(2), 1999. [6] Humphrey, W. Introduction to Personal

Software Process. Addison Wesley, 1997. [7] Humphrey, W. Introduction to Team Software

Process. Addison Wesley, 2000. [8] ISO/IEC 15504 TR2:1998, Software Process

Assessment - Part 2: A reference model for processes and process capability. International Organization for Standardization, 1998.

[9] ISO/IEC 14598-1 Information Technology-Software Product Evaluation-Part 1: General overview, 1999.

[10] ISO/IEC 9126-1: Software Engineering - Product quality - Part 1: Quality model, 2001.

[11] ISO/IEC, ISO 15939: Software Engineering - Software Measurement Process, 2002.

[12] ISO/IEC 90003:2004, Software and Systems Engineering-Guidelines for the Application of ISO9001:2000 to Computer Software: ISO and IEC, 2004.

[13] Jarvis, A., Crandall, V. Inroads to Software Quality: "How to" Guide and Toolkit, Prentice-Hall, 1997.

[14] Juran, J. Juran’s Quality Handbook, 5th ed., New York: McGraw-Hill, 1999.

[15] Kahn, B.K. and Strong, D. Where is Information Quality in Information Systems Education?. Data and Information Quality, Calero et al. (eds.), 199-222, 2002.

[16] Kan, S. H. Metrics and Models in Software Quality Engineering, Second ed, Addison-Wesley, 2002.

[17] McCall, J.A. Factors in Software Quality - General Electric, June, 1977.

[18] McFeeley, R. IDEAL: A User's Guide for Software Process Improvement. Handbook CMU/SEI-96-HB-001, 1996. En: http://www.sei.cmu.edu/publications/documents/96.reports/96.hb.001.html

[19] McGarry, J., Card, D., Jones, C., Layman, B., Clark, E., Dean, J., and Hall, F. Practical Software Measurement. Objective Information for Decision Makers. Addison-Wesley, 2002.

[20] National Institute of Standards and Technology (NIST). “Balridge National Quality Program," 2003. En http://www.quality.nist.gov

[21] Okes, D., Organize Your Quality Tool Belt, Quality Progress, 25-29, 2001.

[22] Oktaba, H., Ibargüengoitia, G. Calidad en Procesos de Software: Ejemplo de TSP. En

Calidad en el desarrollo y mantenimiento del software, Piattini, M., García, F. (eds), 251-271, 2002.

[23] Parasuraman, A., Zeithaml, V.A. y Berry, L. SERVQUAL: A Multiple-Item Scale for Measuring Customer Perceptions of Service Quality. Marketing Science Institute, 86-108, 1986.

[24] Piattini, M., Calero, C. y Ruiz, F. Análisis del tratamiento de las bases de datos en los currícula internacionales: comparación con el currículum de Blesa et al. (1999), JENUI´2002, 155-162, 2002.

[25] Piattini, M. y García, F. Calidad en el Desarrollo y Mantenimiento del Software, Ra-Ma, 2002.

[26] Software Engineering Institute, “The Capability Maturity Model: Guidelines for Improving the Software Process”, Carnegie Mellon University, 1995.

[27] Software Engineering Institute, "Capability Maturity Model Integration for Software Engineering (CMMI), Carnegie Mellon University CMU/SEI-2002-TR-028, ESC-TR-2002-028, 2002.

[28] Standish Group, Extreme Chaos 2001. En http://www.standishgroup.com/sample_research/PDFpages/extreme_chaos.pdf

[29] Stylianou, A.C., Kumar, R.L. An integrative framework for IS quality management. Communications of ACM, 43(9), 99-104, 2000.

[30] Schulmeyer, G.C and McManus, J.I. Handbook of Software Quality Assurance, 3rd ed, Prentice Hall, 1999.

[31] Sunders, J., Curran, E. Software Quality: A Framework for Success in Software Development and Support, Addison-Wesley, 1994.

[32] SWEBOK. Guide to the Software Engineering Body of Knowledge. IEEE Computer Society, 2004.

[33] Wilkin, C. y Castleman, T. Development of an Instrument to Evaluate the Quality of Delivered Information Systems. Proceedings of the 36th Hawaii International Conference on System Sciences, IEEE Computer Society, 1-10, 2003.

Trabajo en equipo en proyectos de desarrollo de software:

estrategia docente e infraestructura software

Patricio Letelier, Mª Carmen Penadés y Juan Sánchez Departamento de Sistemas Informáticos y Computación

Universidad Politécnica de Valencia {letelier, mpenades, jsanchez}@dsic.upv.es

Resumen En términos de contratación y promoción, cada vez se valora más la capacidad de un individuo para participar de manera efectiva en un equipo. El trabajo en equipo es un escenario laboral habitual en proyectos de desarrollo de software. En este artículo presentamos una estrategia docente que hemos venido aplicando y refinando, tanto en escuela como en facultad, para ofrecer a nuestros alumnos una experiencia formadora de trabajo en equipo dentro del contexto de metodologías para el desarrollo de software. Además, describimos la implantación de una infraestructura software de apoyo al trabajo cooperativo, la cual hemos incorporado este último año académico.

1. Introducción

En la actualidad la mayor parte del software no puede desarrollarse de manera individual y exige la participación de equipos de desarrollo, que en algunos casos ni siquiera comparten el mismo lugar o país de trabajo. Así, para un ingeniero informático es importante contar con los conocimientos y habilidades para participar eficazmente en un equipo de trabajo en el contexto de un proyecto de desarrollo de software. Sin embargo, en muchas universidades los estudiantes de informática terminan la carrera sin haber desarrollado un proyecto software de tamaño significativo y sin haber trabajado en un equipo de desarrollo.

En la UPV, desde hace 5 años hemos venido depurando una estrategia para integrar de manera

efectiva en asignaturas de último curso (en escuela y en facultad) la experiencia práctica del trabajo en equipo en el marco de metodologías para el desarrollo de software. Las asignaturas involucradas son: Laboratorio de Desarrollo de Sistemas de Información (LSI-ETSIA), optativa de 3er año de la Escuela Técnica Superior de Informática Aplicada y Laboratorio de Sistemas de Información (LSI-FI), optativa de 5º año de la Facultad de Informática. Paulatinamente hemos ido introduciendo en estas asignaturas mejoras e innovaciones (métodos activos [8], evaluación continua [7], metodologías de desarrollo [5,6], trabajo en equipos, etc.), todas ellas avaladas por la entusiasta participación y positiva valoración de los alumnos.

El objetivo de este artículo es describir el estado actual de nuestra propuesta docente en dichas asignaturas, y especialmente, presentar los resultados de la reciente puesta en marcha de una infraestructura software para apoyar el trabajo en equipo, la cual permite a los miembros de cada equipo compartir información relativa al proyecto a través de la Web.

Lo que resta del artículo está organizado como se indica a continuación. La sección 2 presenta el método docente y de evaluación en las asignaturas involucradas, así como la planificación de las actividades. En la sección 3 se describe la infraestructura software que estamos utilizando en dichas asignaturas para apoyar el trabajo en equipo. En la sección 4 se comentan algunos trabajos relacionados. Finalmente, la sección 5 presenta las conclusiones y trabajo futuro.


2. Trabajo en equipo en asignaturas LSI

LSI-FI y LSI-ETSIA son asignaturas de 6 créditos. El horario de la asignatura se organiza en una sesión semanal de 3 horas en laboratorio y una sesión de 2 horas, cada 2 semanas y en aula. Normalmente se dispone de 12 sesiones de laboratorio y 6 sesiones de aula. La matrícula en estas asignaturas oscila entre 40 y 50 alumnos. El objetivo específico de LSI-FI y LSI-ETSIA es: “capacitar al alumno para participar efectivamente en un proyecto de desarrollo de software siguiendo una metodología”. Esto supone conseguir que el alumno sea capaz de: • Aplicar una metodología de desarrollo en un

proyecto software • Trabajar en un equipo de desarrollo,

desempeñando un rol • Realizar la planificación y control del tiempo

del proyecto • Comunicarse con el cliente para capturar y

validar los requisitos • Negociar con el cliente las características del

producto incorporadas en los plazos establecidos

• Realizar presentaciones de seguimiento del proyecto mostrando los resultados al cliente

Esencialmente en estas asignaturas se aborda un proyecto de desarrollo en equipo siguiendo una metodología. Los alumnos se organizan en equipos de 6 a 8 integrantes. Cada equipo tiene asignado dos profesores, uno actuando como cliente y el otro como instructor. El cliente atiende todo lo referente a requisitos del producto y a las características incorporadas en los plazos establecidos. El instructor ofrece un apoyo metodológico a lo largo del proyecto. Esta separación de roles de los profesores hace más realista el desarrollo de proyecto y permite que los alumnos ejerciten distintos mecanismos de interacción: equipo-cliente (captura de requisitos y negociación) y equipo-instructor (asesorando en la correcta aplicación de la metodología seguida).

2.1. Método docente

Básicamente los tipos de actividades que se realizan a lo largo del curso son:

• Sesiones de trabajo en equipo, realizadas en

horario de laboratorio, o bien en horarios acordados por propio equipo, al que asisten todos o parte de los integrantes

• Sesiones de trabajo con el cliente realizadas en horario de laboratorio y en tutorías

• Sesiones de trabajo con el instructor, realizadas en horario de laboratorio y en tutorías.

• Presentaciones de seguimiento ante el cliente, al final de cada fase o iteración.

• Presentaciones técnicas de la arquitectura ante el instructor. Se realizan dos; una revisión de la arquitectura de los datos y otra de la arquitectura del código.

En la primera sesión se realiza la presentación de la asignatura; se comentan los objetivos, el método docente, el método de evaluación, etc. Además, en esta sesión se da comienzo oficial al proyecto de desarrollo, haciendo públicos los equipos. Los equipos se configuran previamente, respetando sólo dos criterios: que los integrantes sean del mismo grupo horario e intentando una distribución equitativa por sexo. Cada equipo tiene establecida una metodología de desarrollo. Cada integrante tiene asignado un rol (Jefe, Analista/Diseñador, Programador, Tester, etc.), de acuerdo con la metodología de desarrollo. En LSI-FI la mitad de los equipos trabaja con una metodología ágil y la otra con una metodología de corte tradicional. Hemos seleccionado Extreme Programming (XP) [1] como metodología ágil por ser sin lugar a dudas la más popular y de la cual se dispone de mayor cantidad de información. Por otra parte, utilizamos Rational Unified Process (RUP) [4] como metodología tradicional, por contar con una especificación muy detallada. Aunque RUP es una marca comercial, la subscripción al IBM Scholars Program1 permite disponer de todo el material asociado (y de otros productos) para propósitos académicos. Lo ideal sería que los alumnos pudiesen experimentar con ambos tipos de metodologías y desempeñando todos los roles, pero por las restricciones naturales de una asignatura esto no es factible. Sin embargo, la

1 www.developer.ibm.com/university/scholars/


puesta en común que se realiza en las sesiones de seguimiento permite a los alumnos conocer el tra-

1 2 3 4 5 6 7 8 9 10 11 12

Fin Fase de Inicio

Fin Fase de Elaboración

Fin 1era iteraciónde Construcción

Fin 2da iteraciónde Construcción

Proyecto RUP

Fin Fases de Exploración y de Planificación

Fin 1ra iteración

Fin 2da iteración

Fin 3ra iteración

Proyecto XP

1 2 3 4 5 6 7 8 9 10 11 12

Fin Fase de Inicio

Fin Fase de Elaboración

Fin 1era iteraciónde Construcción

Fin 2da iteraciónde Construcción

Proyecto RUP

Fin Fases de Exploración y de Planificación

Fin 1ra iteración

Fin 2da iteración

Fin 3ra iteración

Proyecto XP

Figura 1: Planificación del proyecto

bajo de otros equipos. En la FI, debido a que los alumnos no tienen una asignatura previa donde se describan dichas metodologías, realizamos dos presentaciones a modo de introducción, proporcionándoles además material completen-tario. A la semana siguiente de las presentaciones se efectúa un breve examen de conocimientos de ambas metodologías. En LSI-ETSIA, sin embargo, todos los equipos trabajan con la misma metodología, XP. Los alumnos de la ETSIA tienen la posibilidad de cursar una optativa previa llamada “El Proceso del Software” (PSW), en la cual se introducen de forma teórica las metodologías de desarrollo y los estándares de proceso software. Sin embargo, de acuerdo con nuestra experiencia consideramos que resulta más adecuado y efectivo trabajar con una metodología ágil en 3er curso con los Ingenieros Técnicos en Informática. Pensamos que una metodología ágil está más cercana al perfil profesional y entorno de trabajo al que se enfrentarán. Además, salvo algunas prácticas puntuales tales como pruebas y refactoring, la sencillez de XP favorece el hecho que los alumnos asimilen rápidamente la metodología. A los alumnos que no han cursado previamente PSW se les proporciona un documento resumen de XP que les permite nivelar sus conocimientos al respecto.

2.2. Planificación del proyecto

La Figura 1 muestra la planificación global del proyecto a lo largo de las 12 semanas disponibles (sin incluir días festivos ni vacaciones). La sesión de presentación e inicio del proyecto corresponde a la semana 0, no incluida en la Figura 1. Los

principales hitos del proyecto tanto para equipos RUP como para equipos XP son distribuidos en el calendario de manera que cada hito coincide con la presentación de seguimiento respectiva. Además, alrededor de las semanas 7-8 y 10-11 se realizan las dos presentaciones para revisión de la arquitectura. Esta planificación, ajustada al calendario académico, es inamovible para así lograr una adecuada duración y número de iteraciones. Aunque es difícil, se intenta hacer coincidir las presentaciones de seguimiento con las sesiones de aula, establecidas oficialmente cada dos semanas. Sin embargo, la no coincidencia con un par de sesiones oficiales de aula no ha presentado mayores inconvenientes, principalmente porque no supone mayor dedicación horaria de parte del alumno y tampoco deberían producirse solapes con otras asignaturas. Tanto en los proyectos RUP como XP el producto no se finaliza por completo durante la asignatura. En el caso de RUP, faltarían quizás algunas iteraciones de construcción y la posterior Fase de Transición. En el caso de XP serían necesarias iteraciones adicionales para tener un producto totalmente operativo. Sin embargo, de acuerdo con los objetivos de la asignatura esto no reviste mayor importancia, puesto que es más relevante que los equipos asimilen la rutina de iteraciones, presentaciones de seguimiento, control de su productividad y negociación de compromisos con el cliente. A continuación se describe brevemente lo que implica cada fase/iteración. Los detalles metodológicos quedan fuera del alcance de este artículo. En las tres primeras semanas de trabajo, los equipos XP realizan las Fases de Exploración y de

282 Ingeniería del software Planificación. El resultado final es la obtención del conjunto de historias de usuario y la planificación de la entrega. En estas sesiones hay una gran interacción entre los miembros del equipo y el cliente, pues se trata de establecer requisitos y acordar una planificación. Para los equipos RUP estas primeras semanas corresponden a la Fase de Inicio. En esta fase los equipos RUP suelen requerir mucho más apoyo del instructor que los equipos XP, principalmente en lo que respecta a comprender los artefactos que se utilizarán y la forma incremental e iterativa en la cual se generan. Por este motivo, damos ya definida una configuración de RUP para proyecto pequeño, exigiendo la utilización de sólo algunos artefactos. Entre ellos: Plan de Desarrollo, Glosario, Visión, Modelo de Casos de Uso, Modelo de Análisis/Diseño, Modelo de Datos, Modelo de Implementación, Modelo de Despliegue, Casos de Prueba y Código. Así, el hito para los equipos RUP en la Fase de Inicio se concentra en el avance de los artefactos Plan de Desarrollo y Visión.

Posteriormente, los equipos XP desarrollan tres iteraciones de construcción, según los contenidos inicialmente pactados con el cliente y las negociaciones por cambios en los requisitos. La planificación se va ajustando según se tiene un conocimiento más exacto de la productividad del equipo (medida en XP como la Velocidad de Proyecto).

Los equipos RUP durante la Fase de Elaboración tienen como objetivo avanzar suficientemente el Modelo de Casos de Uso y en menor medida los otros artefactos que determinan la arquitectura del sistema. Con esto deberían ser capaces de planificar los casos de uso que serán implementados en las dos iteraciones de construcción que se efectuarán a continuación.

Tanto en el caso de XP como de RUP, las presentaciones de seguimiento en las iteraciones de construcción incluyen los siguientes aspectos: revisión del plan indicando posibles incidencias, demostración de la versión actual del producto, resultados de las pruebas de aceptación, métricas de tamaño del producto y productividad del equipo.

2.3. Método de evaluación

Se utiliza un esquema de evaluación continua basado en los hitos del proyecto. Cada uno de los

cuatro hitos y sus correspondientes presentaciones de seguimiento tienen una calificación doble. Además, se otorga otra calificación doble a cada una de las revisiones técnicas. También se evalúa con una calificación simple los siguientes conceptos: el examen de conocimientos RUP y XP (sólo en LSI-FI), la actualización de los Registros de Tiempos (donde se registra la dedicación de cada integrante en el proyecto según lo propuesto en Personal Software Process [3]) y la actualización de los artefactos en el sitio Web del equipo. Con todo esto, cada alumno tiene alrededor de 10 calificaciones, las cuales son simplemente promediadas para obtener la nota final.

La fecha de la presentación de la última iteración se hace coincidir con la fecha oficial del examen de la asignatura. Es decir, en lugar de examen final simplemente se realiza una presentación de seguimiento del proyecto, similar a las anteriores.

Un elemento importante a mencionar es el procedimiento seguido para establecer la calificación de cada alumno en los hitos del proyecto y las revisiones técnicas. Inmediatamente después de las presentaciones correspondientes, el cliente y el instructor acuerdan una nota para cada equipo. Dicha nota se multiplica por el número de integrantes del equipo y esta cantidad se le hace llegar por email al jefe del equipo, quien debe acordar su distribución con el resto de integrantes y devolver la puntuación decidida para cada uno de los miembros. Este mecanismo ha resultado efectivo para establecer necesarias diferencias en cuanto a la dedicación y compromiso con el proyecto. Por otra parte esto añade una cuota de realismo en cuanto a la valoración y crítica del trabajo de cada integrante.

3. Infraestructura software de apoyo

La coordinación y el compartir información habían sido dos aspectos problemáticos detectados en años anteriores. Los alumnos disponen de un espacio privado asociado a sus cuentas de usuario, pero este no es fácil de acceder desde fuera del campus. Por otra parte cada asignatura dispone de un sitio web denominado microweb donde se les puede dejar disponible material a los alumnos, es decir, es sólo comunicación en un sentido, desde el profesor al alumno. Claramente estos recursos


Figura 2: Página de inicio del Portal

resultaban insuficientes para conseguir una interacción adecuada entre los integrantes de un equipo, su cliente y su instructor. Ante esto, algunos equipos utilizaban discos virtuales y foros para solventar estas deficiencias.

El año 2004 planteamos como Proyecto de Innovación Docente (PID) la implantación de una infraestructura software de apoyo al trabajo cooperativo y nos fue concedido un becario y una máquina para actuar como servidor. Estudiamos algunas herramientas para gestión de contenidos y trabajo cooperativo, seleccionando finalmente Microsoft SharePoint. Su elección se basó principalmente en el hecho que la tenemos disponible a través de la suscripción de nuestro departamento a la Academic Alliance de Microsoft. Por otra parte, SharePoint es muy sencillo de instalar, configurar y utilizar, ofreciendo una serie de integraciones interesantes con otros productos Microsoft. Además, las extensiones que hemos implementado se realizan fácilmente como webparts, módulos programados en C#.

Los objetivos planteados para esta infraestructura software de apoyo se resumen a continuación: • Proveer a cada equipo de un sitio web para

compartir información entre ellos y con su cliente e instructor

• Proporcionar en línea plantillas para la generación de artefactos del proyecto

• Facilitar la comunicación en el equipo, haciendo disponible la información de contacto, correo a todo el equipo y tablón de anuncios.

• Ofrecer espacio para descarga de material de las asignaturas

• Ofrecer enlaces de interés para las asignaturas

• Ofrecer facilidades de administración para la configuración de equipos y sitios asociados

• Proveer mecanismos de control de acceso para la información privada de cada equipo y su posterior publicación una vez acabado el curso

• Proveer facilidades para seguimiento y evaluación de los equipos

Hasta el momento disponemos de una primera

versión de esta infraestructura, que ha sido utilizada con éxito durante este curso académico en las dos asignaturas involucradas.

La Figura 2 muestra la página de inicio del portal (https://pid.dsic.upv.es). En el apartado cursos se encuentra la información de los proyectos en curso y terminados en cada asignatura así como el calendario de actividades


Figura 3: Sitio Web de equipo

de la asignatura. Cada integrante tiene acceso sólo al sitio web de su equipo. Una vez terminado los proyectos, éstos quedan disponibles a cualquier visitante del portal en modo sólo consulta. Además, hay un apartado de material para las asignaturas y de enlaces de interés. También existe un espacio de fotografías para almacenar fotos de los equipos y del desarrollo de las actividades. La Figura 3 muestra la página web del sitio de un equipo XP. En ella podemos observar los siguientes elementos: a. Información de contacto de los integrantes del

equipo b. Envío de email a todos los integrantes del

equipo c. Tablón de anuncios

d. Información de contacto del cliente y del instructor

e. Registros de Tiempo de cada uno de los integrantes del equipo

f. Enlaces de interés para los miembros del equipo

g. Pestañas para los distintos grupos de artefactos generados, de acuerdo con la metodología que utiliza el equipo. Para cada artefacto se proporciona una plantilla directamente accesible al crear un nuevo artefacto.

Cada integrante de equipo puede modificar su información personal en el sitio de su equipo así como toda la información compartida. En la pestaña “Seguimiento” los equipos deben dejar

g

a

b f

c

d

e


disponible todo el material expuesto en cada presentación de seguimiento o técnica. La configuración del portal mediante las facilidades de SharePoint es muy sencilla. La mayor parte de la funcionalidad descrita anteriormente se puede implantar arrastrando elementos predefinidos en las áreas correspondientes del portal. Sin embargo, hay un esfuerzo considerable tras la definición manual de los sitios de equipos, los usuarios de cada sitio, el establecimiento de los permisos y todos los posteriores cambios que suelen presentarse en los equipos (particularmente altas y bajas de integrantes). Es por esto que se desarrollaron webparts específicas para la gestión del portal, ofreciendo facilidades para cargar los grupos de alumnos desde los listados de matriculados, gestión de equipos con la creación automática de los correspondientes sitios y permisos. La creación de los sitios de equipos se realiza a partir de plantillas predefinidas de sitios según la metodología del equipo. También se ha automatizado la finalización del proyecto, en la cual los proyectos pasan a un estado terminado quedando disponibles para consulta de los visitantes y quitando los permisos de modificación a los integrantes del equipo.

4. Trabajos relacionados

A continuación comentaremos algunas propuestas docentes (publicadas) cercanas a la nuestra en cuanto a su interés por conseguir una formación de equipos de desarrollo y el trabajo de coordinación de los mismos.

En [9] se describe una experiencia en la organización de un curso de análisis y diseño orientado a objetos dirigido a estudiantes que ya han cursado alguna materia de ingeniería del software y que tienen cierta práctica en lenguajes de programación como Java. El caso de estudio o proyecto aborda el desarrollo de un sistema software que se ha dividido en seis subsistemas. Cada equipo de desarrollo debe abordar la construcción de un subsistema y la integración con el resto. Para cada subsistema existen 3 versiones (3 equipos de desarrollo distintos de 5 personas) que deben negociar la venta de su producto al resto de los grupos, y también la compra de los otros subsistemas. En la experiencia se aborda el trabajo dentro de un

equipo, la coordinación con el resto de los equipos y se resalta la importancia de utilizar estándares de documentación y comunicación.

En la Universidad de Kiel, D. Frosch ([2]) propone un curso de ingeniería del software para estudiantes de sistemas de información y de administración de empresas, que se centra en los aspectos prácticos de UML para la construcción de modelos de requisitos. El objetivo del curso es simular un entorno real de trabajo en el cual los estudiantes puedan demostrar sus conocimientos prácticos de UML en el desarrollo de un caso para un cliente, en este caso una empresa real de desarrollo de software. Los estudiantes se organizan en equipos que deben encargarse de gestionar el proyecto, estimar costes y mantener una comunicación fluida con el cliente. Con respecto a la evaluación de resultados se tiene en cuenta la utilización de UML, la cooperación real con el cliente y la cooperación y comunicación entre los componentes de cada grupo. Por último K. Todd Stevens [10] describe una propuesta de enseñanza de ingeniería del software que prima los aspectos prácticos (desarrollo de casos de estudio) sobre los contenidos teóricos. El núcleo central lo constituye el desarrollo en equipo de un proyecto o caso de estudio. Lo más destacable en nuestra opinión de la experiencia radica en los comentarios de los estudiantes referentes a la utilidad del trabajo en equipo, la interacción individual, la importancia de una buena planificación y la necesidad de una buena gestión o dirección del equipo.

5. Conclusiones

En este artículo hemos presentado nuestra estrategia de formación en trabajo en equipo en el contexto de metodologías de desarrollo de software. El esquema planteado ha sido fruto de una serie de refinamientos y desafíos que emprendimos hace cinco años. Estamos muy satisfechos por los resultados obtenidos, confirmados por la positiva valoración de los alumnos a través de las encuestas y al alto grado de participación y compromiso demostrado en las actividades involucradas. Desde el punto de vista docente estamos convencidos que los objetivos planteados por las asignaturas LSI se cumplen y el alumno consigue experimentar una situación de trabajo en equipo que resulta ejemplar respecto a

286 Ingeniería del software las competencias que tendrá que exhibir en su vida profesional como ingeniero de software.

Los Registros de Tiempo de los alumnos nos han permitido confirmar que el tiempo promedio de dedicación del alumno está alrededor de 110 horas, incluyendo las horas de laboratorio y de aula. Esto representaría unos 4 ECTS desde el punto de vista del alumno. Por otra parte, desde la perspectiva del profesor, es indudable que tras el esquema obtenido hay mucho esfuerzo en planificación y preparación de material, todo ello con junto a más horas que las habituales de contacto con los alumnos, especialmente en tutorías. Sin embargo, pensamos que dicho esfuerzo ha valido la pena y en la situación actual, similar a lo que experimentan los alumnos al alcanzar una rutina sostenible de desarrollo en iteraciones, nosotros los profesores también hemos alcanzado un nivel sostenible de repetición de esta estrategia.

El éxito que hemos conseguido con la infraestructura software de apoyo al trabajo cooperativo nos anima a seguir añadiéndole funcionalidad. En la actualidad estamos desarrollando webparts para automatizar el procesamiento de los Registros de Tiempos y para permitir gestionar las evaluaciones del proyecto en los sitios de cada equipo.

Referencias

[1] Beck K. Extreme Programming Explained: Embrance Change. Addison-Wesley, 1999.

[2] Frosch D. Using UML in Software Requirements Analysis Experiences from Practical Student Project Work. Informing Science + Information Technology Education Joint Conference, InSITE 2003. http://proceedings.informingscience.org/IS2003Proceedings/docs/032Frosc.pdf

[3] Humphrey, W.S. Introducción al proceso software personal. Addison-Wesley, 2001.

[4] Kruchten, P., The Rational Unified Process: An Introduction. Addison –Wesley, 2004.

[5] Letelier P., Canós J.H. Working with Extremme Programming in a Software Development Laboratory. Proceedings Fifteenth International Conference on Software Engineering and Knowledge Engineering, SEKE 2003, San Francisco, Julio 2003, pp. 612-615.

[6] Letelier P., Canós J.H. An Experiment Comparing RUP and XP. Springer-Verlag, Lectura Notes in Computer Science Vol. 2675, Proceedings of IV International Conference on Extreme Programming, XP 2003, Génova, Italia, Mayo 2003, pp. 41-46.

[7] Letelier P. Una Experiencia en Evaluación Continua Multicriterio Aplicada en un Laboratorio de Desarrollo de Software. Actas de las VIII Jornadas de Enseñanza Universitaria de la Informática (JENUI 2002), Cáceres del 10 al 12 de Julio 2002, pp. 295-302.

[8] Letelier P. Métodos Activos para Mejorar la Enseñanza-Aprendizaje en un Laboratorio de Desarrollo de Software. Actas del 2do Congreso Internacional de Docencia Universitaria e Innovación, Tarragona, 1, 2 y 3 de Julio 2002. http://cidui.upc.es/upc/-

ice/bbdd/congreso.nsf/web/, pp. 135. [9] Pollice G. Software development theory and

practice in the college curriculum. The Rational Edge. January 2004. http://www.therationaledge.com/content/j

an_04/k_theorypractice_gp.jsp. [10] Stevens T. Experiences Teaching Software

Engineering for the First Time. 6Th Annual Conference on Innovation and Technology in Computer Science Education, ITICSE 2001. http://www.radford.edu/~kstevens2/iticse

2001.pdf.

Date post:	13-Oct-2018
Category:	Documents
Upload:	lamtuong
View:	213 times
Download:	0 times

Ingeniería del software - Computational Biology and...

Documents