Linear and Multiple Regression

Purdue University

Resumen

Los estudiantes que tomaron el curso de PSP son estudiantes que han completado cursos básicos de programación. Para este ensayo inicial de la enseñanza del PSP se consideraron los registros, de tiempo, trabajo y defectos, para que los estudiantes diligencien los formularios durante las tareas de programación. Estas formas son proporcionadas en medios electrónicos.

Resultados

En la evaluación de los registros presentados por los estudiantes, sólo el 40% de los alumnos de la muestra presentaron datos utilizables. En el registro de tiempo, algunos estudiantes no calcularon el tiempo total gastado en el programa, o no registraron sus tiempos de interrupción. El registro de las líneas de código no se realizaba correctamente en muchos casos, pues los espacios para registrarse eran con frecuencia vacíos o estaban incorrectos. Varios estudiantes informaron los tiempos en horas en lugar de minutos, a pesar del hecho de que se les informaba en la parte superior del formulario, que lo diligenciaran en minutos.

Después de aplicar una encuesta a los estudiantes, estos consideraron que entienden los temas PSP y fueron capaces de completar los registros, a pesar de que no estaban muy convencidos de éstos. También indican que los datos de sus registros no son exactos. Hay una negativa mucho más alta que indica que los estudiantes no reconocen el valor de PSP en su formación.

Un problema con la incorporación de PSP en un curso, es que los temas de programación tienen que ser cubiertos en la misma profundidad, y cualquier tiempo utilizado en la clase en la explicación de PSP quita tiempo antes dedicado a temas exclusivamente de programación. En el trabajo desarrollado se identificó que algunos estudiantes no estaban diligenciando correcta y

37

completamente los registros, pues consideran que los mismo implican demasiado tiempo como para realizarse con la seriedad esperada.

Observaciones

No se tiene definida una estrategia de aprendizaje concreta, y el estudiante debe mantener un registro de cada una de las actividades propuestas en PSP y con base en ello se hace una serie de análisis estadístico sobre su desempeño en cada una de las prácticas propuestas.

5.3.4 Loyola University –Chicago, USA

Loyola University

Resumen

Este trabajo informa sobre un experimento de TSP con un grupo de posgrado de Ingeniería de Software. Los estudiantes tienen experiencia en construcción de software y conocen los conceptos básicos de desarrollo de software en equipo. Los equipos están conformados por personas con culturas y procedencias diferentes, y un papel que se asigna de acuerdo con los roles de TSP; los productos se deben entregar a un cliente real. Cada estudiante debe trabajar como programador.

El equipo debe completar dos ciclos de desarrollo de acuerdo con un cronograma. Deben empezar a trabajar con una breve declaración del problema y seleccionar las funciones que se ejecutarán en cada ciclo; completan una o más fases del TSP cada semana y todas las fases se realizan de forma secuencial en el desarrollo de cada ciclo.

La dinámica de trabajo del equipo es definida por agendas de las reuniones que requieren el registro del tiempo en minutos y el registro las actividades realizadas para realizar el seguimiento al desarrollo del proyecto. Los scripts de TSP dan estructura a las actividades semanales del equipo, en los cuales se deben plasmar los resultados obtenidos.

Resultados

Los defectos se suman para todo el ciclo como una medida de alto nivel de la calidad del producto. La calidad del producto al final del ciclo dos, es de unos veinte errores por cada mil líneas de código. Se observa una gran variación en la tasa de los defectos de los diferentes

38

equipos, esto puede estar influenciado tanto por el tiempo que tienen los equipos de trabajo para realizar las pruebas, como por la poca cultura de los equipos para registrar errores y así obtener resultados completos. En términos generales, la calidad del producto es razonable en comparación con los equipos del mundo real.

Cuando se utiliza TSP con sólo unas pocas semanas de entrenamiento, los equipos de estudiantes lograr una productividad en desarrollo de software similar a los del mundo real de las organizaciones.

Los resultados del tiempo en cada una de las fases de TSP durante todo el ciclo de vida, se observa que un 15% está dedicado a las pruebas y que las fases que más consumen tiempo son las de Desarrollo y la de administración, la cual incluye las reuniones de equipo; un 42% está dedicado a estas dos fases. A continuación se muestran los tiempos de cada fase. Administración en cada fase del proyecto 19,3%, Lanzamiento 3,3%, Estrategia y planeación 9,3%, Requerimientos 8,2, Diseño 16,5%, Implementación 22,8%, Pruebas 15,1% y Postmorten 5,5%.

Los estudiantes que completan el curso desarrollan un aprecio por el proceso y aceptan el análisis de datos como un elemento central y fundamental de desarrollo de software. Ellos adquirieron una comprensión de las métricas e informaron de sus avances semanales, la superación de algunas de sus tendencias a trabajar de forma rápida, sin tener en cuenta las consecuencias y los resultados no necesariamente óptimos.

Observaciones

En este trabajo, los equipos de trabajo recopilaron la información de su proceso de desarrollo y posteriormente se analizaba semanalmente su desempeño. Cada equipo debe gestionar los formularios definidos en TSP. No se evidencia una estrategia de aprendizaje en el curso.