Experiencia s Docent Es Psp

Experiencias Docentes en la Aplicación del Proceso

Software Personal en Primero de Grado de Ingeniería

Informática

Leonardo Bermón-Angarita, Alvaro Fernandez Del Carpio, María Isabel Sanchez-Segura,

Javier García-Guzmán, Antonio Amescua Seco

Departamento de Informática

Universidad Carlos III de Madrid

Leganés, Madrid, España

{lbermon, arfernan, misanche, jgarciag, amescua}@inf.uc3m.es

Abstract— Este artículo presenta resultados de la enseñanza a alumnos de primero de carrera de Grado en Ingeniería Informática utilizando el Proceso Software Personal. Por medio de la revisión de conceptos teóricos y el desarrollo de prácticas basadas en una evaluación continua, los estudiantes entienden qué es un proceso de software, adquieren habilidades para conocer cómo desarrollan personalmente sus programas en forma disciplinada y recolectan métricas que pueden incorporarse como mejoras. Con la introducción de PSP en el primer año de grado, los estudiantes van adquiriendo disciplina en el proceso de gestión de su tiempo y logran gestionar sus trabajos prácticos entendiendo y aplicando las tareas básicas de Ingeniería de Software desde etapas tempranas de formación.

Palabras clave-proceso personal; ingeniería de software;

mejora de proceso; docencia informática

I. INTRODUCCIÓN

El desarrollo de software requiere el uso disciplinado de prácticas establecidas. El uso de planes y procedimientos conlleva a la eficiencia en el trabajo para obtener un producto de calidad [1]. Sin embargo, los estudiantes en sus primeros cursos de informática basan su trabajo en ideas intuitivas sobre cómo desarrollar software [2]. Es necesario que los estudiantes en etapas tempranas conozcan y desarrollen competencias acerca del proceso de software y mejoren su nivel de formación basado en la codificación y depuración de errores [3].

Una disciplina que permite desarrollar dichas competencias es el Proceso Software Personal (Personal Software Process – PSP), el cual se fundamenta en que los desarrolladores recolecten medidas relacionadas con sus productos de trabajo y los procesos para desarrollarlos [4].

Este artículo pretende determinar si aplicar un enfoque orientado al proceso basado en PSP, ayudará a adquirir disciplina en el desarrollo de software en primero de grado de Ingeniería Informática como parte de la formación inicial de los estudiantes aprendiendo hábitos de medición, estimación, planificación y seguimiento de tareas. Los beneficios esperados con la impartición de este curso son las capacidades y competencias que los estudiantes obtendrán para desarrollar software de manera predecible, evitando sobrecostos y entregas

tardías en el desarrollo de proyectos. La investigación realizada tiene en cuenta la falta de experiencia en programación y la carencia de una disciplina previa en el desarrollo de tareas.

Los resultados obtenidos demuestran un nivel favorable de aceptación en la introducción de conceptos básicos de PSP en el desarrollo de pequeños programas con un enfoque basado en clases teóricas y prácticas, una evaluación continua de las prácticas realizadas y el uso de herramientas tecnológicas que apoyen las tutorías y el material de aprendizaje del curso.

Este artículo se ha estructurado en las siguientes secciones. La primera sección presenta la introducción. La segunda sección describe conceptos fundamentales de PSP. La tercera sección muestra un resumen de la aplicación de PSP en planes de estudios. La cuarta sección expone la aplicación de PSP en cursos de informática en España. La quinta sección describe el contexto, planificación, desarrollo y evaluación del curso impartido. La sexta sección presenta un análisis de los resultados obtenidos. En la séptima sección se presentan las lecciones aprendidas. Finalmente, se exponen las conclusiones y trabajo futuro.

II. PROCESO PERSONAL SOFTWARE

El Proceso Software Personal es una infraestructura definida y medible de procesos que ayuda a los desarrolladores de software a estimar y planificar sus proyectos, medir y realizar seguimiento de su trabajo, y mejorar la calidad de los productos desarrollados [5].

El Proceso Personal Software fue desarrollado por Watts Humphrey en el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon [6]. PSP surgió como una propuesta de aplicar modelos de mejora de procesos dirigidos a grandes organizaciones (como Capability Maturity Model – CMM) a proyectos pequeños e individuales [7].

PSP es un proceso evolutivo como se muestra en la Fig. 1. Los niveles de procesos PSP son [6]:

PSP0: Es el nivel básico de PSP donde se realiza un registro de los tiempos y defectos durante el desarrollo.

o PSP0.1: Incluye medición de tamaño de los programas y una propuesta de mejora del proceso.

FINTDI 2009 107

Martín Llamas Nistal, Manuel Caeiro Rodríguez y Juan Manuel Santos Gago, editoresFINTDI 2009: Fomento e Innovación con Nuevas Tecnologías en la Docencia de la Ingeniería

ISBN 978-84-8158-463-9 © 2009 IEEE, Sociedad de Educación: Capítulos Español y Portugués

mailto:amescua%[email protected]

o

Figura 1. Niveles de procesos PSP.

PSP1: Incluye el método PROBE para realizar estimaciones de tamaño de programa y tiempo de desarrollo. El método está basado en un análisis de regresión lineal aplicado a datos históricos.

o PSP1.1: Añade la planificación de tareas y calendario y la técnica de valor ganado para la realización de seguimiento del proyecto.

PSP2: Incluye revisiones de diseño, revisiones de código y medición y evaluación de la calidad.

o PSP2.1: Incluye técnicas de especificación de diseño y técnicas de prevención de defectos.

PSP3: Se aplican métodos de verificación de diseño para adaptar PSP al ambiente de la organización.

PSP se basa en una serie de elementos [4]: Guiones para realizar tareas dentro del proceso; Formularios para registrar datos acerca del proceso; y Estándares para establecer pautas de codificación, conteo de líneas de código y tipos de defectos.

El flujo de procesos de PSP se muestra simplificado en la Fig. 2. Primero se planifica el trabajo. Se continúa con las fases de diseño, codificación, compilación y pruebas. A medida que el trabajo se realiza, se registran datos de tiempos y defectos. Al finalizar el proyecto, se realiza un análisis post-mortem para completar el resumen del plan de proyecto [6].

Figura 2. Flujo del proceso PSP.

III. PSP Y CURSOS DE INGENIERÍA DEL SOFTWARE

Entre algunos desafíos que se encuentran en el aprendizaje del proceso de software está la madurez de los estudiantes para que reconozcan el valor de una disciplina aplicada al proceso de software (cuestión que todavía no han experimentado en etapas tempranas) y una introspección forzada para conocer cómo se desarrolla individualmente el software comprendiendo sus hábitos y prácticas de desarrollo para mejorar [2].

La aplicación de PSP en los programas curriculares de ciencias de la computación se remonta a mediados de la década de los 90. Muchas universidades han incorporado su enseñanza a estudiantes de cursos de primeros años como también a estudiante graduados con la finalidad de intentar transmitir los beneficios que trae consigo la aplicación de PSP.

Basado en las experiencias obtenidas, se han recopilado resultados sobre su aplicación. Según [3], los factores importantes para la enseñanza del PSP son: el entorno del curso, el nivel de cobertura y las herramientas de soporte. El entorno depende de la audiencia, del nivel del curso y del contenido del tema. Según los casos de estudio publicados, su enseñanza puede ser satisfactoria en cualquier entorno, pero muestran dificultad de integración con otros cursos.

Estos factores permiten evaluar las experiencias obtenidas en algunos centros de estudio como se presenta en la Tabla I.

TABLA I. COMPARATIVA DE CURSOS PSP.

Centro Entorno del

curso

Nivel de

cobertura

Herramientas de

soporte

Universidad Umeå

(Suecia),

Universidad de

Utah, Universidad

Purdue, Montana

Tech y Universidad

Drexel (EE.UU) [3]

Enseñanza

dirigida

básicamente

a estudiantes

de primer o

segundo

semestre.

Versión

ligera de

PSP y una

versión

completa en

cursos de

Ingeniería

del

Software.

En algunos casos

se usaron hojas de

cálculo para

recopilar la

información y en

otros se usó una

herramienta

propia

desarrollada.

Universidad de

Zagreb (Croacia)

[8]

Estudiantes

de años

superiores.

Se sugirió la

enseñanza

para

estudiantes

de inicio de

curso.

Curso de

Ingeniería

del

Software.

Enseñanza

de PSP

simplificado.

Herramienta

desarrollada.

Universidad de

Oulu (Finlandia)

[9]

Estudiantes

de años

superiores.

Cursos de

Ingeniería de

Software

Documentos

electrónicos

(hojas de cálculo).

Milwaukee School

of Engineering

(EE.UU) [10]

Estudiantes

de segundo

año.

Curso de

Proceso de

Ingeniería

del

Software.

Registro manual

de los datos de los

procesos.

Lund University

(Suecia) [11]

Estudiantes

de primer

año y de

postgrado.

Curso de

introducción

a PSP.

Herramienta

basada en Excel.

Universidad de

Memphis (EE.UU)

[12]

Cursos de

primer y

segundo año.

Curso de

Ingeniería

del

Software.

Herramienta de

trabajo propia.

108 FINTDI 2009



Los resultados de la aplicación de PSP en las universidades anteriormente mencionadas fueron:

- Aceptación de la enseñanza del curso: Su enseñanza resultó generalmente buena [3]. Los estudiantes de Escuela de Ingeniería de Milwaukee se enfocaron principalmente en aprender los componentes de los procesos de medición en lugar de hacer el seguimiento y medición de sus datos [10]. El curso en la Universidad de Lund fue trasladado al segundo año con la finalidad de que los estudiantes adquirieran primeramente habilidades de programación antes de usar PSP. Los estudiantes del primer año tuvieron más preguntas sobre programación que sobre los procesos de PSP. Debido a que los estudiantes del primer año no cuentan aún con las habilidades suficientes de programación se recomendó su enseñanza para el segundo año [11]. De manera similar en la Universidad de Memphis se concluyó que aún es prematura la enseñanza de PSP en cursos de primer y segundo año, ya que los estudiantes no están listos para apreciar los beneficios de su aplicación aunque ellos encontraron que aprender las partes de PSP es fácil [12].

- Conocimientos requeridos: Debido a que los estudiantes de los primeros años no cuentan con los conocimientos estadísticos necesarios, se aconsejó la enseñanza de los procesos básicos del PSP en los primeros años y los conceptos que requieren estadística para los últimos [3]. Los estudiantes de la Universidad de Oulu mostraron problemas con contenidos orientados a las matemáticas [9]. Los estudiantes de la Escuela de Ingeniería de Milwaukee necesitaron conocimientos previos en Programación orientada a objetos, Diseño de software y Estructuras de datos [10]. Para los alumnos del primer año en la Universidad Lund se usó Java como lenguaje obligatorio [11].

- Motivación: Se determinó que la motivación es un punto importante para los estudiantes y no se aconsejó reducir el número de ejercicios ya que los estudiantes no pueden ver claramente su progreso. Ya que el curso de PSP en la Escuela de Ingeniería de Milwaukee no requería exámenes, los alumnos estuvieron menos motivados para llevar la lectura de los textos de estudio. Para ello, los instructores debieron reforzar continuamente los hábitos del proceso. Los estudiantes percibieron que al destinar más tiempo para registrar y analizar programas complejos, mejora la calidad de sus programas. Así también, descubrieron que pueden ser mejores programadores aplicando técnicas simples y prácticas [10].

- Registro de información: Los estudiantes de la Universidad de Oulu presentaron problemas en el llenado de los formularios [9]. Para los estudiantes de la Escuela de Ingeniería de Milwaukee el llenado de formularios fue una tarea aburrida e incómoda [10]. Los estudiantes de primer año de la Universidad Lund registraron de manera incompleta la información [11]. En la Universidad de Memphis muchos estudiantes estuvieron de acuerdo que usar el Resumen del Plan de Proyecto les ayudó a entender mejor los procesos de desarrollo de software y a seguir los pasos más rigurosamente. También estuvieron de acuerdo en que el registro del seguimiento ayudó a mejorar sus habilidades de estimación de esfuerzo [12].

- Productividad: El trabajo en parejas obtuvo buenos resultados [3]. Se consiguió una disminución de defectos durante las fases de compilación y pruebas [8]. Los estudiantes de la Universidad de Oulu no mostraron una significativa mejora en la estimación del esfuerzo y los defectos encontrados en la fase de pruebas disminuyeron en un factor de 4:2. El esfuerzo de codificación disminuyó de 40% a 24% pero el esfuerzo de planificación se incrementó de 4% a 26% [9]. Los programas desarrollados por los estudiantes de primer año de la Universidad Lund eran pequeños y no se tuvo total certeza si realmente reportaron todos los defectos encontrados. Estos estudiantes mejoraron su productividad de PSP0 a PSP1 [11].

Similarmente, en una evaluación que se realizó a estudiantes de otras 20 universidades alemanas, se encontró dificultad en la resolución de los ejercicios, ya que el nivel de experiencia de programación y de conocimientos teóricos era muy diverso [13]. Se obtuvo un nivel de aceptación moderada de motivación del curso y el nivel de dificultad de las clases teóricas fue ligeramente bajo. Como puntos vitales en la enseñanza de PSP, se concluyó la importancia de enfocar la asignatura en aspectos relevantes de PSP y cómo implementarlos, sin perderse en detalles. Algunos problemas al usar PSP en la enseñanza fueron: requiere una gran disciplina, es necesario el soporte de una buena herramienta para la gestión de la información recolectada, las hojas de cálculo provistas son bastante inflexibles y especializadas para su uso.

Algunos estudios recomiendan incluir PSP como elemento fundamental dentro de los planes curriculares [3] [14] y concretamente en introducir sus conceptos en los primeros cursos de las titulaciones [15].

IV. APLICACIÓN DE PSP EN INFORMÁTICA EN ESPAÑA

En consultas realizadas en páginas web de más de 30 universidades españolas, los conceptos de PSP se incluyen generalmente en asignaturas como Ingeniería de software I y II, Calidad de sistemas de información, Planificación y gestión de proyectos informáticos, y Análisis y gestión del desarrollo de software. Estas asignaturas se encuentran en titulaciones como Ingeniería técnica en informática de sistemas, Ingeniería técnica en informática de gestión e Ingeniería informática.

A nivel de programas adaptados al EEES en la titulación de Grado en Ingeniería Informática, en la Tabla II se presenta un listado de universidades que ofrecen dicha titulación y las asignaturas relacionadas con Ingeniería del software junto con los cursos donde se imparten.

Las asignaturas relacionadas con la Ingeniería de software se imparten generalmente a partir del segundo curso o en cursos superiores. Para la mayoría de las asignaturas no se obtuvo información específica sobre sus contenidos. En los casos donde están publicados no se incluye PSP dentro de sus contenidos.

Por lo tanto, la aplicación de principios de ingeniería de software basados en PSP en un primer curso de grado en Ingeniería Informática es un aspecto novedoso y relevante de este estudio.

FINTDI 2009 109



TABLA II. ASIGNATURAS SOBRE INGENIERÍA DE SOFTWARE EN GRADO DE

INGENIERIA INFORMÁTICA.

Centro Curso Asignaturas Temario

publicado

PSP

Univ. de Deusto 4 Ingeniería de

software I y II

Si No

Univ. Autónoma

de Madrid

4 Ingeniería de

software

No -

Univ. San Jorge de

Zaragoza

3 Ingeniería de

software

No -

Univ. Europea de

Madrid

2 Introducción a la

ingeniería del

software

Si No

Univ. Rey Juan

Carlos

2 y 3 Ingeniería del

software y

Ampliación

Si No

Univ. Alcalá de

Henares

2 Ingeniería del

software e Ing.

software avanzada

No -

Univ. Santiago de

Compostela

3 Ingeniería de

software

Si No

Univ. Católica San

Antonio de Murcia

3 y 4 Ingeniería de

software I y II

No -

Univ. Politécnica

de Madrid

3 y 4 Ingeniería del

software I y II

No -

Univ. de Murcia 3 Procesos de

desarrollo de

software

No -

Univ. de Vigo 2 Ingeniería del

software de

gestión

No -

Univ. de Rioja 2 Ingeniería del

software

No -

V. APLICACIÓN DE PSP EN PRIMERO DE GRADO DE

INFORMÁTICA

Para describir la aplicación de los conceptos de PSP en un curso de primero de grado en Ingeniería Informática se describirá a continuación su contexto, planificación, desarrollo, la práctica final y finalizando con su evaluación.

A. Contexto del curso

Las experiencias se basan en la aplicación de PSP durante la impartición de una asignatura de primero de grado en la titulación de Ingeniería Informática de la Universidad Carlos III de Madrid. La asignatura fue Principios de Ingeniería de Software y estaba formada por 8 grupos (1 bilingüe) con un total de 278 estudiantes y 5 profesores durante el curso 2008-2009. Las prácticas se realizaron en parejas en 7 de los grupos e individuales en uno de ellos.

B. Planificación

El curso se planificó con una duración de 11 semanas por ser bajo régimen cuatrimestral y desarrollándose a través de una clase teórica y una práctica a la semana. Un resumen de los temas de estas clases se presenta en la Tabla III. En el curso se impartieron conceptos de PSP referentes a los niveles PSP0, PSP0.1, PSP1 y PSP1.1. Durante el curso no se profundizó en aspectos de programación. Para la realización de algunas prácticas se entregó material de aprendizaje adicional para completarlas con éxito. Cada práctica tenía un peso diferente de evaluación debido a su complejidad y esfuerzo de resolución.

TABLA III. RELACIÓN DE CLASES TEÓRICAS Y PRÁCTICAS.

Semana Teoría Práctica Contexto

PSP

1 El trabajo del ingeniero

de software

Investigación sobre

fallos del software

-

2 Introducción a PSP Modelado con ETVX. PSP

general

3 Gestión y control del

tiempo

Programa con listas y

cálculos estadísticos PSP0*

4 Medición del tamaño

de software

Conteo manual del

tamaño de programas

PSP0.1

5 Estimaciones de

tiempo y tamaño

Programa de conteo de

tamaño de programa

PSP0.1*

6 Planificación del

proyecto

Estimación del tamaño

de un programa PSP1*

7 Microsoft Project Programa para calcular

regresiones lineales

PSP1

8 Seguimiento de

proyectos

Planificación de tareas

y calendario PSP1.1*

9 Gestión personal de la

configuración

Planificación de tareas

con Ms-Project

-

10 Aplicación de la

técnica del valor

ganado

Programa para calcular

rangos de tamaños

relativos

PSP1.1*

11 Gestión de la

configuración

Gestión de la

configuración con

SourceSafe

-

*: Utilizando la herramienta PSP Student Workbook.

C. Desarrollo

El curso iniciaba cada semana con una clase teórica donde se impartían los conceptos fundamentales acerca del proceso de software, y los procesos y formularios PSP necesarios para la realización de las prácticas.

Las clases prácticas iniciaban con una lectura de su enunciado y a continuación, se describía por medio de un guión el proceso PSP específico para su realización y los formularios con datos a recolectar. Los estudiantes procedían a realizar la práctica o a resolver dudas sobre su resolución. Los estudiantes tenían un nivel de conocimientos muy básico en programación obtenido del curso de Programación del cuatrimestre anterior.

Las tareas de programación se realizaron con lenguaje Java utilizando como plataforma de desarrollo Eclipse Europa. Los estudiantes tenían una semana de plazo para el desarrollo y entrega de la práctica.

El material sobre el proceso PSP para elaborar las prácticas fue generado por los estudiantes utilizando la herramienta PSP Student Workbook [16]. Esta herramienta desarrollada por el SEI, proporciona soporte para la recolección de datos del proceso, análisis de datos históricos y producción de reportes. En la Fig. 3 se presenta un ejemplo de un resumen del plan de proyecto generado a partir de la herramienta.

Para la gestión de los materiales de aprendizaje del curso, publicación de anuncios, gestión de grupos, y publicación y entrega de las prácticas se utilizó la plataforma SelCampus de nuestro grupo de investigación. Dicha plataforma es un sistema de gestión de aprendizaje implementado por medio del sistema Dokeos [17]. En la Fig. 4 se muestra la sección del buzón de tareas de la plataforma con algunas prácticas enviadas.

110 FINTDI 2009



Figura 3. Resumen del plan de proyecto.

Figura 4. Recepción de prácticas en SelCampus.

Los estudiantes debían enviar al buzón de tareas de SelCampus tanto el código fuente de los programas desarrollados como los formularios PSP generados en la herramienta PSP Student Workbook.

D. Práctica Final

Una vez finalizadas las prácticas de la asignatura se procedió a publicar el enunciado de la práctica final del curso. Los estudiantes tuvieron tres semanas de plazo para su elaboración. La práctica final consistió en utilizar el proceso PSP1.1 para el desarrollo de un algoritmo que implementara la solución al problema del cálculo del grado de coincidencia de dos cadenas de texto. El problema fue presentado en el enunciado del caso práctico considerado en la asignatura de Estructura de Datos y Algoritmos del mismo cuatrimestre.

E. Evaluación

La evaluación del curso se basó en criterios de evaluación continua donde el conjunto de actividades realizado durante el curso tuvo mayor importancia frente al examen final tradicional. Durante el cuatrimestre se realizó una verificación constante del avance del trabajo realizado por los estudiantes.

A medida que se desarrollaban las prácticas, se publicaban las notas respectivas para que los estudiantes y profesores realizaran un seguimiento semanal del trabajo. Además, otro recurso bastante utilizado por los estudiantes fueron las tutorías resueltas de manera presencial y por medios electrónicos.

Para el cálculo de la nota final de la asignatura, las prácticas tuvieron un porcentaje asignado del 60% de la nota final del curso, la práctica final un porcentaje de 30% y el examen final un porcentaje de 10%.

El examen final fue de dos tipos dependiendo si el estudiante realizó o no la evaluación continua. El examen para estudiantes que cumplieron la evaluación continua fue tipo test con 30 preguntas sobre los contenidos teóricos y prácticos de la asignatura. El examen para estudiantes que no realizaron dicha evaluación fue un caso práctico sobre el proceso de desarrollo de un programa donde se debían realizar formularios PSP.

VI. ANÁLISIS DE LOS RESULTADOS OBTENIDOS

Los resultados obtenidos se analizan desde las evaluaciones realizadas a los estudiantes sobre las prácticas.

Los criterios usados para evaluar las prácticas concernientes a PSP se presentan en la Tabla IV. Estos criterios permitieron determinar el nivel de aprendizaje y habilidad adquirida en la aplicación de PSP en el desarrollo de pequeños proyectos. Cada criterio de evaluación tenía un conjunto de subcriterios con pesos diferentes utilizando una escala numérica de uno a diez sin decimales.

TABLA IV. CRITERIOS DE EVALUACIÓN

Práctica Contexto

PSP

Criterios

Programa con listas y

cálculos estadísticos

PSP0 Registra correctamente los

tiempos y defectos.

Conteo manual del tamaño

de programas

PSP0.1 Aplica los métodos de

distribución normal y

logarítmica en la tabla de

tamaños relativos de programas.

Programa de conteo de

tamaño de un programa

PSP0.1 Registra correctamente los

tiempos y defectos y el tamaño

del programa.

Estimación del tamaño de

un programa

PSP1 Identifica adecuadamente las

clases y estima el tamaño del

software apropiadamente.


regresiones lineales

PSP1 Aplica los métodos A, C y D de

PROBE para realizar

estimaciones de tamaño y

tiempo.

Planificación de tareas y

calendario

PSP1.1 Planifica adecuadamente las

tareas y el calendario aplicando

la técnica de valor ganado.


rangos de tamaños relativos

PSP1.1 Elabora pruebas correctas de

software y obtiene el valor

ganado real

FINTDI 2009 111



En las Fig. 5, 6, 7 y 8 se presentan resúmenes con los promedios de evaluación obtenidos de todos los grupos sobre la capacidad de registrar correctamente los tiempos para las diferentes fases, la identificación de diferentes tipos de defectos, la realización de estimaciones y la planificación y seguimiento de las prácticas.

Figura 5. Evaluación de registro de tiempos PSP.

Figura 6. Evaluación de registro de defectos PSP.

Figura 7. Evaluación de realización de estimaciones PSP.

Figura 8. Evaluación de planificación y seguimiento PSP.

La Fig. 5 muestra que los datos de registro de tiempos eran cada vez más consistentes pero en las dos últimas prácticas no se realizó un seguimiento detallado de dichos registros debido a que se dio mayor importancia a la evaluación de otros aspectos de PSP. Los valores altos se deben a que esta actividad de medición es la más sencilla y es el núcleo básico de PSP.

La evaluación del registro de defectos en la Fig. 6 indica una tendencia de mejora en la identificación y registro de defectos. Sin embargo, no se registraron adecuadamente todos los defectos detectados porque tendían a ser agrupados. Los valores bajos se deben a que los estudiantes tuvieron dificultades en el entendimiento del concepto de defecto y cómo se registra.

La evaluación de estimaciones en la Fig. 7 presenta también una tendencia creciente en la mejora de las estimaciones realizadas en las prácticas. Las estimaciones inician con unos valores bajos debido a que inicialmente no se identificaron correctamente las clases, hubo confusión en los conceptos de líneas bases, reutilizadas y nuevas reutilizadas, y en el cierre correcto de prácticas anteriores que influyeron en que el registro histórico presentara errores que se reflejaron en las estimaciones.

La evaluación de la planificación y seguimiento del proyecto se presenta en la Fig. 8. Estas tareas, que se realizaron en la práctica de PSP1.1 y en la práctica final, presentan una evaluación cercana al 50% debido principalmente a que el concepto de valor ganado aunque fue entendido y calculado correctamente a nivel de planificación, fue mal interpretado y calculado durante el seguimiento del proyecto.

El promedio final de evaluaciones de la Fig. 9 presenta porcentaje altos en la realización correcta del registro de tiempos y defectos que reflejan que sus conceptos fueron comprendidos. Los conceptos de estimaciones, y planificación y seguimiento presentan valores medios debido a su complejidad y los diferentes errores cometidos en su realización.

Teniendo en cuenta que no tenemos mecanismos para evaluar más profundamente estos resultados ya que es la primera vez que se imparte este curso, el análisis realizado manifiesta porcentajes superiores al 50% en los aspectos evaluados que hacen favorable la incorporación de conceptos de PSP en nuestro curso de primero de grado.

Figura 9. Promedio finales de evaluaciones.

112 FINTDI 2009



Esta conclusión también es apoyada por la retroalimentación obtenida por los estudiantes a partir de las encuestas docentes realizadas donde la estimación del nivel de habilidades alcanzado por los estudiantes obtuvo una media de 3.39 con una desviación de 0.96 y un nivel de satisfacción de 3.59 con media de 1.08.

Los resultados académicos del curso reflejan un alto número de estudiantes aprobados. El porcentaje total de aprobados fue del 63.67%, el porcentaje de suspensos es bajo, 13.31% y los no presentados 23.02%.

VII. LECCIONES APRENDIDAS

La incorporación de PSP en etapas tempranas de aprendizaje permite a los estudiantes entender mediante una serie de ejercicios prácticos qué es un proceso y una disciplina para realizarlo, así como adquirir el hábito de realizar mediciones, aspecto clave no sólo del desarrollo personal si no en cualquier faceta de la vida. Además, al recolectar datos sobre cómo desarrollan sus programas, se obtiene una línea base que ayudará a planificar trabajos futuros.

El éxito en la impartición de la asignatura se fundamentó en una adecuada coordinación entre las clases teóricas y prácticas, un seguimiento continuo del trabajo realizado y mecanismos de soporte basados en herramientas, tecnologías de la información y tutorías para ayudar a los estudiantes.

A. Problemas presentados

Algunos problemas que se presentaron durante el transcurso de la asignatura fueron:

Dificultades en la realización de las prácticas debido al conocimiento básico previo de conceptos y del lenguaje de programación de los estudiantes.

El trabajo en parejas no fue realizado apropiadamente ya que en algunos casos las prácticas eran repartidas por los estudiantes y desarrolladas individualmente.

Los estudiantes se enfocaron en rellenar los formularios pero no siguen los procesos PSP definidos.

Problemas al usar las herramientas de cálculo estadístico.

PROBE es un método de estimación complejo donde algunos estudiantes confunden los conceptos de líneas bases, nuevas, modificadas, reutilizadas y nuevas reutilizadas.

B. Propuestas de mejora

Algunas propuestas de mejora para solucionar estos problemas son:

Reducir la complejidad de las prácticas: Para afrontar el nivel básico de conocimiento de programación, las prácticas a desarrollar tendrán el nivel de esfuerzo de los ejercicios realizados en el curso de Programación del cuatrimestre anterior y de las prácticas paralelas a ser realizadas en el curso de Programación Orientado a Objetos del mismo cuatrimestre.

Hacer énfasis en los procesos PSP: Para que los estudiantes no se limiten a llenar los formularios, se debe exigir el conocimiento y aplicación de los guiones de procesos PSP y luego presentar cómo se desarrollan los guiones utilizando la herramienta.

Incorporar ejemplos detallados de diseño conceptual: El concepto fundamental del método PROBE es la identificación de los proxies del programa. Pare ello se debe profundizar en aspectos de diseño conceptual, presentar ejemplos y mostrar errores comunes. A partir de un buen entendimiento del diseño conceptual se podrá explicar mejor el método PROBE, presentando ejemplos reales con código que faciliten el aprendizaje de las estimaciones de las partes de un programa.

Seguimiento más estricto del desarrollo de las prácticas para verificar que se está trabajando realmente en parejas. El seguimiento se realizará por medio de preguntas a los integrantes de los grupos sobre las prácticas realizadas.

VIII. CONCLUSIONES Y TRABAJO FUTURO

El trabajo realizado en la asignatura se centró en desarrollar habilidades concretas en Ingeniería del Software que involucran el registro y estimación de tamaños y tiempos a medida que se elaboran las prácticas semanales. El curso se enfocó en el desarrollo de competencias para entender el proceso de software y no en profundizar aspectos de programación. De esta manera, los estudiantes perciben por primera vez que la tarea de desarrollar software es un proceso complejo con un conjunto de actividades de ingeniería que requiere técnicas para construir software que van más allá de sus competencias iniciales sobre codificación de programas.

PSP contiene un número significativo de plantillas y formularios. Se recomienda tener una herramienta que automatice dicho proceso. Por ejemplo, PSP Student Workbook facilita llenar los formularios PSP e implementa un registro histórico para poder llevar a cabo las estimaciones.

Con la impartición de los conceptos de PSP en etapas tempranas de formación y una evaluación continua basada en la realización de prácticas semanales, los estudiantes comienzan a desarrollar competencias en el área de Ingeniería del Software.

El curso impartido muestra una diferencia significativa entre los resultados encontrados al comienzo y al final del proceso. A medida que se realiza una nueva práctica, las medidas presentadas en los formularios de recolección de datos mejoran debido a que deben ser llenados nuevamente y se ha obtenido realimentación a través de tutorías y presentación de errores comunes en las clases.

Estableciendo comparativas con los cursos de PSP impartidos en otras universidades, se puede determinar que existen varias coincidencias en cuanto al grado de completitud de la información entregada (tiempos y defectos), incorporación de herramientas de apoyo, problemas de habilidades en programación, impartición de primeros niveles de PSP y capacidad de adquirir hábitos con las técnicas aprendidas que se pueden aplicar en cursos posteriores, a pesar

FINTDI 2009 113



que los estudiantes de primer año no perciban aún completamente los beneficios de PSP.

El trabajo futuro se basará en la elaboración de material de aprendizaje teórico y práctico de los niveles faltantes (PSP2, PSP2.1 y PSP3) en una asignatura posterior del plan de estudios y la elaboración de material de aprendizaje a nivel de equipos de trabajo basado en Team Software Process (TSP).

RECONOCIMIENTOS

Agradecemos a los integrantes del grupo de investigación ―Software Engineering Lab‖ de la Universidad Carlos III de Madrid que participaron durante el desarrollo de la asignatura.

REFERENCIAS

[1] M. Morisio, ―Applying PSP in industry,‖ IEEE Software 17, 6, 2000, pp.90-95.

[2] D.A. Umphress y J.A. Hamilton, ―Software process as a foundation for

teaching, learning, and accrediting,‖ Software Engineering Education and Training, 2002. Proceedings 15th Conference, pp.160–169.

[3] J. Börstler et al., ―Teaching the PSP: challenges and lessons learned,‖

19, 5, 2002, pp. 42–48.

[4] W. Humphrey, , ―PSP: a self-improvement process for software engineers,‖ Addison-Wesley. 2005.

[5] P. Ferguson, W. Humphrey, S. Khajenoori, S. Macke, A. Matvya,

―Results of applying the personal software process,‖ IEEE Computer, 30, 5, 1997, pp 24-31.

[6] W. Humphrey, ―Introduction to the personal software process,‖ Pearson

Educación, Madrid, 2001.

[7] I. Hirmanpour y S. Khajenoori, ―Personal Software Process Technology:

An Experiential Report,‖ Proceedings of ISECON 2000, v 17, Philadelphia, pp. 115.

[8] Z. Car, ―A Method for teaching a software process based on the personal

software process,‖ Proceedings of the 21st IASTED International Conference Applied Informatics AI 2003, Innsbruck, Austria, 2003, pp.

1115-1120.

[9] P. Abrahamsson y K. Kautz, ―Personal software process: classroom experiences from Finland,‖ Proceedings of the seventh European

conference on software quality, Helsinki, Finlandia, 2002.

[10] D. Suri y M. J. Sebern, ―Incorporating Software Process in an Undergraduate Software Engineering Curriculum: Challenges and

Rewards,‖ Proceeding of the 17th Conference on Software Engineering Education and Training (CSEET'04), 2004.

[11] P. Runeson, ―Experience from Teaching PSP for Freshmen,‖

Proceedings of. 14th Conference on Software Engineering Education & Training, pp. 98-107, 2001.

[12] J. I. Maletic, A. Marcus y A. Howald, ―Incorporating PSP into a

Traditional Software Engineering Course: An Experience Report,‖ Proceedings of the 14th Conference on Software Engineering Education

and Training, 2001.

[13] L.Prechelt, B. Unger y O. Gramberg, ―Experience report: teaching and

using the personal software process (PSP),‖ Institut für Programmstrukturen und Datenorganisation, 1997.

[14] W. S. Humphrey, ―Using a defined and measured personal software

process,‖ IEEE Software, 1996.

[15] T.B. Hilburn y M. Towhidnejad, ―Integrating the personal software process across the undergraduate curriculum,‖ Frontiers in Education

Conference Proceedings, 1997.

[16] Página web del SEI. http://www.sei.cmu.edu/tsp/tools/academic/. Consulta realizada en Septiembre 2009.

[17] Página web de la herrmienta Dokeos. http://www.dokeos.com/es.

Consulta realizada en Septiembre 2009.

Leonardo Bermón Angarita. Es candidato a Ph.D. en Computer Science y pertenece al grupo Software Engineering Lab de la Universidad Carlos III de Madrid. Tiene un BSc y un MSc en Computer Science de la Universidad Industrial de Santander, Colombia. Sus áreas de investigación son la Definición y Mejora del Proceso de Software y la Gestión del Conocimiento.

Álvaro Fernández del Carpio. Es candidato a Ph.D. en Computer Science y pertenece al grupo Software Engineering Lab de la Universidad Carlos III de Madrid. Tiene un MSc en Computer Science de la Universidad Carlos III de Madrid. Sus actuales intereses son: Mejora de Procesos de Software, Entornos de Trabajo Colaborativo, Modelos de Evaluación y Living Labs.

María Isabel Sánchez Segura. Es profesora del Departamento de Informática de la Universidad Carlos III de Madrid desde 1998. Sus intereses de investigación incluyen: Ingeniería de Software, Sistemas Interactivos y Usabilidad en Sistemas Interactivos. Posee un BSc en Computer Science, un MSc en Software Engineering, y un Ph.D. en Computer Science de la Universidad Politécnica de Madrid.

Javier García Guzmán. Tiene un BSc en Engineering y un Ph.D. en Computer Science (Universidad Carlos III de Madrid). Tiene experiencia de más de 9 años como Ingeniero de Software y consultor en empresas públicas y privadas. Ha participado en numerosos proyectos de investigación financiados con recursos públicos y privados (europeos y nacionales).

Antonio Amescua Seco. Es Ph.D. en Computer Science y es Catedrático de la Universidad Carlos III de Madrid. Ha sido Director del desarrollo de la metodología METRICA V3, estándar obligatorio para la Planificación y Desarrollo de Sistemas de Información en la Administración Pública Española. Actualmente dirige el grupo de investigación SEL (Software Engineering Lab) llevando a cabo proyectos de investigación e innovación tecnológica financiados tanto por empresas privadas como por entidades públicas.

114 FINTDI 2009



http://www.sei.cmu.edu/tsp/tools/academic/

http://www.dokeos.com/es

Experiencia s Docent Es Psp

Documents

Transcript of Experiencia s Docent Es Psp