FINTDI 2009

107

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.

Martín Llamas Nistal, Manuel Caeiro Rodríguez y Juan Manuel Santos Gago, editores
FINTDI 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

108

FINTDI 2009

o

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].

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.

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.

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].

TABLA I. COMPARATIVA DE CURSOS PSP.
Centro
Universidad Umeå
(Suecia),
Universidad de
Utah, Universidad
Purdue, Montana
Tech y Universidad
Drexel (EE.UU) [3]

Universidad de
Zagreb (Croacia)
[8]

Universidad de
Oulu (Finlandia)
[9]
Milwaukee School
of Engineering
(EE.UU) [10]

Lund University
(Suecia) [11]

Figura 2. Flujo del proceso PSP.

Universidad de
Memphis (EE.UU)
[12]

Entorno del
curso
Enseñanza
dirigida
básicamente
a estudiantes
de primer o
segundo
semestre.

Estudiantes
de años
superiores.
Se sugirió la
enseñanza
para
estudiantes
de inicio de
curso.
Estudiantes
de años
superiores.
Estudiantes
de segundo
año.

Estudiantes
de primer
año y de
postgrado.
Cursos de
primer y
segundo año.

Nivel de
cobertura
Versión
ligera de
PSP y una
versión
completa en
cursos de
Ingeniería
del
Software.
Curso de
Ingeniería
del
Software.
Enseñanza
de PSP
simplificado.

Herramientas de
soporte
En algunos casos
se usaron hojas de
cálculo para
recopilar la
información y en
otros se usó una
herramienta
propia
desarrollada.
Herramienta
desarrollada.

Cursos de
Ingeniería de
Software
Curso de
Proceso de
Ingeniería
del
Software.
Curso de
introducción
a PSP.

Documentos
electrónicos
(hojas de cálculo).
Registro manual
de los datos de los
procesos.

Curso de
Ingeniería
del
Software.

Herramienta de
trabajo propia.

Martín Llamas Nistal, Manuel Caeiro Rodríguez y Juan Manuel Santos Gago, editores
FINTDI 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

Herramienta
basada en Excel.

FINTDI 2009

109

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.

Martín Llamas Nistal, Manuel Caeiro Rodríguez y Juan Manuel Santos Gago, editores
FINTDI 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

110

FINTDI 2009

TABLA II. ASIGNATURAS SOBRE INGENIERÍA DE SOFTWARE EN GRADO DE
INGENIERIA INFORMÁTICA.

Centro

Curso

Asignaturas

Univ. de Deusto

4

Univ. Autónoma
de Madrid
Univ. San Jorge de
Zaragoza
Univ. Europea de
Madrid

4

Ingeniería de
software I y II
Ingeniería de
software
Ingeniería de
software
Introducción a la
ingeniería del
software
Ingeniería del
software y
Ampliación
Ingeniería del
software e Ing.
software avanzada
Ingeniería de
software
Ingeniería de
software I y II
Ingeniería del
software I y II
Procesos de
desarrollo de
software
Ingeniería del
software de
gestión
Ingeniería del
software

3
2

Univ. Rey Juan
Carlos

2y3

Univ. Alcalá de
Henares

2

Univ. Santiago de
Compostela
Univ. Católica San
Antonio de Murcia
Univ. Politécnica
de Madrid
Univ. de Murcia

3
3y4
3y4
3

Univ. de Vigo

2

Univ. de Rioja

2

V.

Temario
publicado
Si

PSP

No

-

No

-

Si

No

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

Semana

Teoría

Práctica

1

El trabajo del ingeniero
de software
Introducción a PSP

Investigación sobre
fallos del software
Modelado con ETVX.

Gestión y control del
tiempo
Medición del tamaño
de software
Estimaciones de
tiempo y tamaño
Planificación del
proyecto
Microsoft Project

Programa con listas y
cálculos estadísticos
Conteo manual del
tamaño de programas
Programa de conteo de
tamaño de programa
Estimación del tamaño
de un programa
Programa para calcular
regresiones lineales
Planificación de tareas
y calendario
Planificación de tareas
con Ms-Project
Programa para calcular
rangos de tamaños
relativos
Gestión de la
configuración con
SourceSafe

No
2
3
4
5

Si

No

No

-

6
7
8

Si

No

9

No

-

10

No

-

No

-

Seguimiento de
proyectos
Gestión personal de la
configuración
Aplicación de la
técnica del valor
ganado
Gestión de la
configuración

No

-

*: Utilizando la herramienta PSP Student Workbook.

No

-

11

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 20082009. 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.

Contexto
PSP
PSP
general
PSP0*
PSP0.1
PSP0.1*
PSP1*
PSP1
PSP1.1*
PSP1.1*

-

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.

Martín Llamas Nistal, Manuel Caeiro Rodríguez y Juan Manuel Santos Gago, editores
FINTDI 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

FINTDI 2009

111

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.
Figura 3. Resumen del plan de proyecto.

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

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.

Programa con listas y
cálculos estadísticos
Conteo manual del tamaño
de programas

Programa de conteo de
tamaño de un programa

Contexto
PSP
PSP0
PSP0.1

PSP0.1

Estimación del tamaño de
un programa

PSP1

Programa para calcular
regresiones lineales

PSP1

Planificación de tareas y
calendario

PSP1.1

Programa para calcular
rangos de tamaños relativos

PSP1.1

Criterios
Registra correctamente los
tiempos y defectos.
Aplica los métodos de
distribución normal y
logarítmica en la tabla de
tamaños relativos de programas.
Registra correctamente los
tiempos y defectos y el tamaño
del programa.
Identifica adecuadamente las
clases y estima el tamaño del
software apropiadamente.
Aplica los métodos A, C y D de
PROBE para realizar
estimaciones de tamaño y
tiempo.
Planifica adecuadamente las
tareas y el calendario aplicando
la técnica de valor ganado.
Elabora pruebas correctas de
software y obtiene el valor
ganado real

Martín Llamas Nistal, Manuel Caeiro Rodríguez y Juan Manuel Santos Gago, editores
FINTDI 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

112

FINTDI 2009

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.

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.

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

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.

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

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 7. Evaluación de realización de estimaciones PSP.

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

Figura 9. Promedio finales de evaluaciones.

Martín Llamas Nistal, Manuel Caeiro Rodríguez y Juan Manuel Santos Gago, editores
FINTDI 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

FINTDI 2009

113

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

Martín Llamas Nistal, Manuel Caeiro Rodríguez y Juan Manuel Santos Gago, editores
FINTDI 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

114

FINTDI 2009

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]
[2]

[3]
[4]
[5]

[6]
[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]
[15]

[16]
[17]

M. Morisio, ―Applying PSP in industry,‖ IEEE Software 17, 6, 2000,
pp.90-95.
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.
J. Börstler et al., ―Teaching the PSP: challenges and lessons learned,‖
19, 5, 2002, pp. 42–48.
W. Humphrey, , ―PSP: a self-improvement process for software
engineers,‖ Addison-Wesley. 2005.
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.
W. Humphrey, ―Introduction to the personal software process,‖ Pearson
Educación, Madrid, 2001.
I. Hirmanpour y S. Khajenoori, ―Personal Software Process Technology:
An Experiential Report,‖ Proceedings of ISECON 2000, v 17,
Philadelphia, pp. 115.
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.
P. Abrahamsson y K. Kautz, ―Personal software process: classroom
experiences from Finland,‖ Proceedings of the seventh European
conference on software quality, Helsinki, Finlandia, 2002.
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.
P. Runeson, ―Experience from Teaching PSP for Freshmen,‖
Proceedings of. 14th Conference on Software Engineering Education &
Training, pp. 98-107, 2001.
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.
L.Prechelt, B. Unger y O. Gramberg, ―Experience report: teaching and
using the personal software process (PSP),‖ Institut für
Programmstrukturen und Datenorganisation, 1997.
W. S. Humphrey, ―Using a defined and measured personal software
process,‖ IEEE Software, 1996.
T.B. Hilburn y M. Towhidnejad, ―Integrating the personal software
process across the undergraduate curriculum,‖ Frontiers in Education
Conference Proceedings, 1997.
Página web del SEI. http://www.sei.cmu.edu/tsp/tools/academic/.
Consulta realizada en Septiembre 2009.
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.

Martín Llamas Nistal, Manuel Caeiro Rodríguez y Juan Manuel Santos Gago, editores
FINTDI 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

Sign up to vote on this title
UsefulNot useful