INGENIERÍA DE SOFTWARE E INGENIERÍA DEL CONOCIMIENTO: DOS DISCIPLINAS INTERRELACIONADAS

Transcripción

1 INGENIERÍA DE SOFTWARE E INGENIERÍA DEL CONOCIMIENTO: DOS DISCIPLINAS INTERRELACIONADAS

2 INGENIERÍA DE SOFTWARE E INGENIERÍA DEL CONOCIMIENTO: DOS DISCIPLINAS INTERRELACIONADAS 1a. edición: 2014 Universidad de Medellín Antonio A. Aguileta Bell Manrique Losada Carlos Mario Zapata Jaramillo Darío Rodríguez Demetrio A. Ovalle Carranza Edison Spina Edwin H. Hincapié - Corrales Fabio Alberto Vargas Germán Urrego - Giraldo Gerzon E. Gómez Gloria Liliana Vélez Gloria Lucía Giraldo Gloria Piedad Gasca Guillermo González - Calderón Héctor J. Ortiz Pabón Hernán Merlino ISBN: Jaime Alberto Echeverri Javier M. Reyes Vera John Branch John W. Castro Jonás Montilva Jorge Eliécer Giraldo Plaza Jovani Alberto Jiménez Builes Juan Carlos Hernández Juan P. Ucán Judith Barrios Liliana González - Palacio Lillyana María Giraldo Lina María Giraldo Luis Joyanes Marcel J. Simonette María Clara Gómez Mauricio González - Palacio Mónica Tentori - Espinosa Omar S. Gómez Óscar Dieste Óscar H. Arenas - Arenas Óscar Mauricio Salazar Paola - J Rodríguez - C Patricia Pesado Ramón García - Martínez Raúl A. Aguilar Roberto Manjarrés Rodrigo Zalapa - Cardiel Sandra Mateus Sebastián Martins Silvia T. Acuña Vianca Vega Contratos internacionales / José Luis Marín Fuentes; Universidad de Medellín; editor Leonardo David López Escobar. -- Medellín: Sello Editorial Universidad de Medellín, c p.; 17 x 24 cm ISBN Contratos y responsabilidad 2. Contratos comerciales internacionales 3. Contratos comerciales 4. Derecho comercial 5. Jurisprudencia comercial. I Universidad de Medellín. CDD / M 337 Catalogación bibliográfica - Universidad de Medellín. Biblioteca Eduardo Fernández Botero. María Isabel Quintero Bedoya. Editor: Leonardo David López Escobar Dirección electrónica: ldlopez@udem.edu.co Universidad de Medellín. Medellín, Colombia Cra. 87 No Bloque 20, piso 2. Teléfonos: Medellín - Colombia Corrección de estilo: Diseño portada: Claudia Castrillón Álvarez claudiadisenografico@gmail.com Distribución y ventas: Universidad de Medellín selloeditorial@udem.edu.co; edu.co Cra. 87 No / Teléfono: Medellín, Colombia Diagramación: Hernán D. Durango T. hernandedurango@gmail.com Impresión: Xpress Estudio Gráfico y Digital S.A. Av. Américas No / PBX (+57 1) Bogotá, Colombia Todos los derechos reservados. Esta publicación no puede ser reproducida, ni en todo ni en parte, por ningún medio inventado o por inventarse, sin el permiso previo y por escrito de la Universidad de Medellín. Hecho el depósito legal.

3 Capítulo XII Proceso de software personal en la academia: experiencias de aplicación en México Omar S. Gómez * Gerzon E. Gómez ** Antonio A. Aguileta *** Raúl A. Aguilar **** INTRODUCCIÓN En la actualidad, la construcción de sistemas de software es una actividad que demanda un importante número de recursos humanos. La mayoría de los sistemas software se construye por equipos de ingenieros, donde de manera individual, cada ingeniero suele producir una serie de componentes pequeños que son ensamblados para producir un sistema software funcional. Cualquier mejora en la eficiencia o productividad de los ingenieros incidirá de manera positiva en los productos software resultantes. En la década de 1980, Watts Humphrey dirigió un programa en el Instituto de Ingeniería de Software (en Inglés, Software Engineering Institute * Facultad de Matemáticas, Universidad Autónoma de Yucatán, Anillo Periférico Norte, Tablaje Cat , Mérida, Yucatán, México. Dirección electrónica: omar.gomez@uady.mx; ** Facultad de Matemáticas, Universidad Autónoma de Yucatán, Anillo Periférico Norte, Tablaje Cat , Mérida, Yucatán, México. Dirección electrónica: gerzon.gomez@uady.mx; *** Facultad de Matemáticas, Universidad Autónoma de Yucatán, Anillo Periférico Norte, Tablaje Cat , Mérida, Yucatán, México. Dirección electrónica: aaguilet@uady.mx; matematicas.uady.mx **** Facultad de Matemáticas, Universidad Autónoma de Yucatán, Anillo Periférico Norte, Tablaje Cat , Mérida, Yucatán, México. Dirección electrónica: avera@uady.mx; matematicas.uady.mx 197

4 Omar S. Gómez GerzOn e. Gómez antonio a. aguileta raúl a. aguilar o SEI), donde se desarrolló un modelo para evaluar y mejorar la madurez y la capacidad de las organizaciones dedicadas a la construcción de software 1 [13, 14]. Críticas iniciales a este modelo sugerían que no podía aplicarse en organizaciones pequeñas, debido a la importante cantidad de recursos necesarios para implementarlo [23]. Ante estas críti cas, Humphrey desarrolló un proceso de mejora personal tomando como referencia el modelo CMM. Durante algunos años, escribió más de 60 programas que refinaron este proceso y, posteriormente, comenzó a aplicarlo en grupos de estudiantes adscritos a la Maestría en Ingeniería de Software de la Universidad de Carnegie Mellon. A este proceso individual, Humphrey lo llamó Proceso de Software Personal (en Inglés, Personal Software Process o PSP) [15]. PSP aborda directamente la calidad y la eficiencia en la construcción de software. Se dice que ayuda a los ingenieros a mejorar en sus estimaciones con respecto al tamaño y tiempo que les lleva construir un componente de software. PSP también ayuda a los ingenieros a mejorar la calidad de sus productos, reduciendo sus tasas de inyección de defectos. Diversas compañías que aplican los principios del PSP mues - tran un aumento de calidad en sus productos de software, así como una reducción en los tiempos de desarrollo [10, 8, 19]. Hasta hace poco, el PSP se enseñaba exclusivamente a profesionales, pero se comenzó a impartir en la academia, como parte de cursos en distintas universidades alrededor del mundo [24, 5, 21, 25, 3, 2, 1, 11, 20]. En México, algunas instituciones de educación superior del país 2 comenzaron a incluir en sus planes de estudio cursos de PSP, no obstante, no se han encontrado reportes de experiencias de cursos PSP impartidos en un ámbito académico en el país. En este Capítulo se describen la experiencia y los resultados obtenidos al enseñar PSP durante el semestre agosto - diciembre de 2012 a estudiantes de séptimo semestre inscritos en la Licenciatura de Ingeniería de Software de la Facultad de Matemáticas de la Universidad Autónoma de Yucatán (FMat - UADY) A este modelo se le conoce como Modelo de Madurez de Capacidades, en Inglés, Capa - bility Maturity Model o CMM. 2 Tales como: Universidad Autónoma de Yucatán, Centro de Investigación en Matemáticas A.C., Instituto Tecnológico y de Estudios Superiores de Monterrey, Universidad Autónoma de Zacatecas, Universidad Autónoma de Nuevo León, entre otras instituciones.

5 Proceso de software Personal en la academia: experiencias de aplicación en méxico Aunque se puede argumentar que las experiencias de un curso tienen un valor limitado para la industria (ya que se emplean estudiantes en lugar de profesionales), diversos estudios indican que los estudiantes también son representantes válidos de profesionales en la industria [18, 16, 6, 26, 27]. En este sentido, la experiencia aquí reportada ofrece conocimiento útil sobre los efectos del PSP. Este Capítulo se organiza de la siguiente manera: en la sección 2 se presenta un panorama general del PSP. En la sección 3 se discute el trabajo relacionado. En la sección 4 se describe el contexto del curso impartido en la FMat - UADY. En la sección 5 se presentan los resultados del curso. En la sección 6 se discuten los resultados obtenidos. Por último, en la sección 7 se presentan las conclusiones Proceso de Software Personal (PSP) El PSP se diseñó con la finalidad de aplicar la mejora de procesos de una organi - zación a un nivel individual y en él se describe una metodología que dirige al inge - niero de software hacia un trabajo definido, disciplinado y de mejora continua. El objetivo del PSP es que el ingeniero de software sea capaz de controlar y gestionar los productos de software que construye, conforme aprende a mejorar en sus estima - ciones, así como aprende a mejorar la calidad de esos productos. Esta mejora se logra conforme el ingeniero avanza a lo largo de varias versiones de este proceso. En cada versión se introducen nuevos elementos a la línea base del PSP. En la Figura 1 se muestra la progresión de versiones de este proceso. En cada versión del proceso, el ingeniero realiza uno o varios ejercicios de pro - gramación, siguiendo los lineamientos de la versión del PSP en la que se encuentre. En cada ejercicio, el ingeniero recolecta y analiza distintas mediciones sobre su trabajo. Posteriormente, emplea sus mediciones para realizar diferentes análisis con el fin de mejorar su trabajo. Los cursos de adiestramiento en PSP incluyen el desarrollo varios ejercicios de programación y varios informes. Cada versión del PSP se comprende de tres fases que son: planificación, desarrollo y postmortem. La fase de planificación se usa para documentar el plan del producto a construir (ejercicio de programación). En la fase de desarrollo se realizan varias actividades como son: diseño, codificación, compilación y pruebas. En la fase de postmortem se complementa el plan de la fase inicial con diferentes mediciones obtenidas tras la construcción del producto. 199

6 Omar S. Gómez GerzOn e. Gómez antonio a. aguileta raúl a. aguilar PSP3 o, Proceso Software en Equipo (TSP) Fomentar el espíritu de grupo Gestión de riesgos Planificación y seguimiento del proyecto PSP2 Revisiones de código Revisiones de diseño PSP1 Estimación de tamaño Reporte de pruebas PSP2.1 Plantillas de diseño PSP1.1 Planificación de tareas Planificación de calendario 200 PSP0 Proceso actual Mediciones básicas PSP0.1 Estándar de codificación Propuesta de mejora al proceso Medición de tamaño Figura 1. Versiones del proceso PSP (adaptado de [12]). PSP comienza con la versión cero (PSP0), es decir, con el proceso de desarrollo de software actual que usa el ingeniero. En esta versión sólo se registran tiempos y defectos de los programas que el ingeniero realiza; se establece una serie de mediciones base del proceso actual como son: tiempo dedicado a la programación, defectos inyectados y tamaño del programa (medido en líneas de código, en Inglés, LOC). PSP0.1 extiende el proceso mediante la adición de un estándar de codificación y el desarrollo de un plan de mejora del proceso personal (en Inglés, Process Impro - vement Proposal o PIP). El PIP ayuda al ingeniero a registrar sus ideas para mejorar su propio proceso. En las versiones PSP1 y PSP1.1 (estimación y planificación), de acuerdo con las mediciones recolectadas en PSP0 y PSP0.1, el ingeniero estima qué tan grande será el programa a realizar y prepara un informe de prueba (PSP1). Las mediciones acumuladas de los ejercicios de programación anteriores se usan para estimar el tiempo que le llevará construir el siguiente programa. Durante la construcción de cada programa, se registran los tiempos de las distintas fases del proceso (planificación, desarrollo y postmortem) así como los tamaños en LOC de cada programa. Esta información se usa para estimar el tamaño y el esfuerzo necesarios para construir el siguiente

7 Proceso de software Personal en la academia: experiencias de aplicación en méxico programa. En PSP1.1 se añade a lo anterior la planificación y programación de las distintas actividades de este proceso. En PSP2 y PSP2.1 (gestión de calidad y diseño) se añaden dos nuevas fases al proceso: revisión de diseño y revisión de código. La prevención y eliminación de defectos es la parte central de PSP2. En esta versión del proceso, los ingenieros aprenden a evaluar y mejorar sus estimaciones, así como a recolectar el número de defectos que se inyectan y se remueven en cada actividad del desarrollo. Los ingenieros elaboran y usan listas de comprobación para revisar tanto sus diseños como sus códigos. Finalmente, PSP2.1 introduce técnicas de especificación de diseño y análisis con el fin de reducir los defectos inyectados durante el diseño TRABAJO RELACIONADO Existen algunos reportes de experiencias de aplicación del PSP en la academia [24, 5, 21, 25, 3, 2, 1, 11, 20]. A continuación se describe de manera general el contexto de estas experiencias, los resultados obtenidos, así como algunas reacciones por parte de los estudiantes que recibieron este curso. Contexto. Para obtener el contexto donde se reportan las experiencias al enseñar PSP, se toman en cuenta los siguientes elementos: tipos de estudiantes, año de la carrera en que se impartió PSP, número de estudiantes, lenguaje de programación usado, nivel de cobertura de aplicación del PSP y las herramientas de soporte utilizadas. PSP se ha impartido tanto en posgrado [21, 5, 24, 25, 3], como en licenciatura, durante los dos primeros años de la carrera [11, 20, 5, 25, 3], en el tercer año [24], así como en cuarto y quinto año [2, 1, 21]. El número de estudiantes que tomaron este curso varía entre grupos de 20 a 31 estudiantes [2, 1, 5, 24, 25] hasta grupos que incluyen entre 100 y 360 estudiantes [11, 20, 5, 25]. Los estudiantes que han tomado este curso han trabajado principalmente con los lenguajes de programación Java [2, 1, 5, 24, 25], C++ [2, 1, 11, 3] y C [25]. PSP se ha enseñado como un único curso [2, 1, 11] y como parte de algún otro curso [11, 20, 21, 5, 25, 3]. También se ha impartido en su totalidad [20, 25, 3, 2, 1] (todas sus versiones), así como se ha impartido de manera parcial [11, 5, 21, 3]. En los cursos de PSP se han usado distintos tipos de herramientas de soporte para la recolección de mediciones como son: formularios impresos 201

8 Omar S. Gómez GerzOn e. Gómez antonio a. aguileta raúl a. aguilar [20, 21, 5, 3], hojas de cálculo [2, 1, 11, 20, 24, 25, 3] y programas informáticos [24, 3]. Resultados. En la mayoría de las experiencias reportadas, el PSP ha ayudado a los estudiantes a mejorar sus estimaciones [21], mejorar la calidad de sus productos [1], o ambas [2, 11, 24, 25]. No obstante, en otras experiencias no se ha logrado observar los beneficios del PSP en cursos universitarios [20, 5]. Reacciones de los estudiantes. Las reacciones de los estudiantes con respecto al PSP han sido variadas. Algunos comentan que esta metodología les ha ayudado a tomar conciencia sobre el proceso de desarrollo de software [2, 1, 5], aunque otros estudian - tes se quejaron del tiempo y el esfuerzo requerido para recolectar las distintas medi - ciones [2, 1, 11, 20, 21, 5, 3] y de la falta de motivación [5, 24]. A continuación se muestran algunos comentarios 3 de estudiantes que llevaron este curso: It is very time consuming and very frustrating to look at all [the] documents during the process [2]. The biggest difficulty was motivation. It was distracting having to stop and record the data every few minutes, it was time consuming and it had the ability to be as distracting as the recorded interruptions. The motivational difficulty relates to the effort required. The value of the data has to outweigh the effort required to collect the data to improve the motivation to collect the data [5]. It has been nice to experience how a software process [...] can be carried out. It is much different from my earlier experiences. [...] This one has an advantage [in comparison to] others, since it makes [...] the process visible to its user. Afterwards [...] it is possible to evaluate the process on the basis of facts and not feelings [2] CONTEXTO DEL CURSO IMPARTIDO EN LA FMAT - UADY El año académico en la Universidad Autónoma de Yucatán (UADY) consta de dos semestres y cada semestre suele dividirse en 16 semanas. El curso de PSP aquí repor - tado se llevó a cabo durante el semestre agosto - diciembre del año Este curso se ofrece en el programa de Licenciatura en Ingeniería de 3 Los comentarios se presentan en el idioma original para preservar su contenido. 202

9 Proceso de software Personal en la academia: experiencias de aplicación en méxico Software de la Facultad de Matemáticas (FMat) como parte de una serie de cursos de libre elección que complementan la formación del estudiante. Estos cursos se organizan en áreas de concentración. El curso de PSP pertenece al área de concentración denominada como: mejora del proceso software. El curso de PSP se dividió en 16 semanas, donde en cada semana se impartieron dos sesiones (lunes y miércoles) con una duración de dos horas por sesión. En total, los estudiantes desarrollaron ocho programas y elaboraron dos informes que entre - garon en la mitad y al final del curso. En la Tabla 1 se muestra una breve descripción de los programas usados durante el curso y se muestra el promedio de las líneas de código escritas, así como el esfuerzo promedio en minutos que les llevó a los estudiantes realizar cada programa. Como material del curso se usaron dos de los libros de Humphrey [15, 12]. La meta del curso consistió en aprender todo el proceso PSP (hasta la versión 2.1). Tabla 1. Descripción de los programas usados durante el curso PSP, promedio del tamaño (medido en LOC) y promedio del esfuerzo (medido en minutos) de cada programa. Prog. Versión PSP 1 v0 Descripción Cálculo de promedio y desviación estándar de un conjunto de números almacenados en una lista enlazada. Tamaño (LOC) Esfuerzo (Mins) v0.1 Contador de líneas de código fuente v1 4 v1.1 5 v2 Cálculo de los parámetros de regresión lineal b0 y b1, así como de los coeficientes de correlación r y r2 dado un conjunto de pares de valores. Cálculo de rangos, ya sea de LOC o páginas, de acuerdo con los tamaños relativos: muy pequeño, pequeño, mediano, grande, muy grande. Integración numérica de una función empleando la regla de Simpson

10 Omar S. Gómez GerzOn e. Gómez antonio a. aguileta raúl a. aguilar Prog. Versión PSP 6 v2.1 7 v2.1 8 v2.1 Descripción Análisis semántico de un programa que funciona como línea de comandos. Uso de operaciones básicas sobre una tabla de símbolos, como son: inserción, asignación, búsqueda e impresión (en pantalla) de la tabla. Uso de operaciones para gestionar un árbol n - ario. Tamaño (LOC) Esfuerzo (Mins) De un total de 19 estudiantes inscritos en el curso, sólo 14 lo completaron de manera satisfactoria; se tuvo una tasa de deserción del 26%. Los estudiantes inscritos en este curso se encontraban en el inicio de su cuarto año de la carrera (séptimo semestre). Como herramienta de soporte para la recolección de mediciones se empleó el Process Dashboard [28]. Se decidió en este curso usar una herramienta de soporte, con el fin de: 1) reducir el esfuerzo que conlleva recolectar manualmente las medi - ciones y 2) minimizar las reacciones de los estudiantes al tener que usar formularios impresos para recolectar manualmente sus mediciones RESULTADOS De manera general, el PSP puede descomponerse en dos componentes: uno referente a las estimaciones y el otro a la calidad. En esta sección se presentan los resultados del curso PSP impartido en FMat - UADY estructurados de acuerdo a estos dos com - ponentes. Con respecto a las estimaciones, se analiza la precisión de las estimaciones referentes al tamaño y al esfuerzo. Con respecto a la calidad, se analizan los defectos removidos en la fase de pruebas. Se observa que las mediciones recolectadas en cursos de PSP están sujetas a errores [7, 17], por lo cual no debieran empleare como un único indicador de éxito o fracaso. Al igual que Abrahamson y Kautz [1], los resultados aquí reportados no pretenden realizar afirmaciones sobre alguno de estos dos indicadores, sino contribuir a una mayor discusión sobre el uso de PSP en el ámbito académico Tamaño En PSP, la estimación de tamaño se realiza con el fin de obtener un estimado preciso del esfuerzo requerido para construir un producto. Para medir el 204

11 Proceso de software Personal en la academia: experiencias de aplicación en méxico tamaño, se emplean líneas de código fuente (en Inglés, LOC), ya que se tiene cierta evidencia de que éstas correlacionan razonablemente bien con el esfuerzo de desarrollo [15, 12]. Con respecto a la correlación entre tamaño y esfuerzo, en la Tabla 2 se muestran los resultados del coeficiente de correlación r y del coeficiente de determinación r 2 observados en los catorce estudiantes. Tabla 2. Correlaciones observadas entre tamaño y esfuerzo. Estudiante Coeficiente de correlación r Coeficiente de determinación r % % % % % % % % % % % % % % El coeficiente de correlación r mide el grado de asociación y dirección entre dos conjuntos de datos (que generalmente representan dos variables: dependiente [y] e independiente [x]). El valor de este coeficiente puede variar entre a +1.0, donde valores cercanos a ±1.0 indican una correlación lineal (positiva o negativa). Por el contrario, valores cercanos a cero indican la ausencia de correlación entre los dos conjuntos de datos. Se dice que una correlación es fuerte cuando su valor es mayor o igual que 0.8. Por otra parte, se describe como una relación débil cuando su valor es menor que 0.5 (en el caso de la correlación lineal positiva). El coeficiente de determinación r 2 indica la fluctuación de los valores de la variable dependiente que se pueden explicar con una relación lineal sobre los valores de la variable independiente. Los valores de este coeficiente oscilan entre 0 y 1 (en caso de representarse como porcentaje, 0 y 100%). Estos coeficientes se calcularon a partir de las mediciones que representan el total de líneas de código 205

12 Omar S. Gómez GerzOn e. Gómez antonio a. aguileta raúl a. aguilar (LOC) de los ocho programas así como por el esfuerzo total que le llevó a cada estudiante desarrollar los programas. Por ejemplo, las mediciones de tamaño y esfuerzo del estudiante 1, indican un coeficiente de determinación r 2 =72.42%, es decir, que el 72.42% de la variación total en el esfuerzo de desarrollo (variable dependiente) se puede explicar con una relación lineal entre el tamaño (variable independiente) y el esfuerzo. El otro 27.58% de variación restante permanece sin explicar. Como se observa en la Tabla 2, sólo las mediciones de los estudiantes 1, 4, 5 y 9 pueden explicar aproximadamente el 50% o más de la variación entre estas dos variables. Retomando las estimaciones con respecto al tamaño, cabe señalar que los estudian - tes generaron sus estimaciones a partir de las mediciones que ellos previamente recolectaron de programas anteriores. Al comienzo del proceso, las variaciones en las estimaciones pueden fluctuar de manera considerable; no obstante, según alguna evidencia [9], conforme madura este proceso (versiones 2 y 2.1) la fluctuación en las estimaciones tiende a estabilizarse dentro de un 25% de margen de error. La Figura 2 muestra un diagrama de cajas con la distribución de la precisión de las estimaciones con respecto al tamaño de los programas usados en el curso PSP Porcentaje de error en estimación (%) (v0.1) 3 (v1) 4 (v1.1) 5 (v2) 6 (v2.1) 7 (v2.1) 8 (v2.1) Número de programa y versión de PSP Figura 2. Error en estimación con respecto al tamaño. 206

13 Proceso de software Personal en la academia: experiencias de aplicación en méxico En esta figura, se tienen varios diagramas de caja que representan los programas 2 a 8 (versiones 0.1 a 2.1 del PSP). El primer programa se omitió, ya que en esta versión del proceso no se realiza una estimación del tamaño. Un diagrama de caja es un tipo de gráfico donde se representan los cuartiles de un conjunto ordenado de datos. Este diagrama se compone de un rectángulo o caja y dos brazos o bigotes. La caja representa el 50% de los datos, la línea que divide la caja representa la mediana y cada brazo representa el 25% de los datos. Este diagrama es útil para identificar valores atípicos y para evaluar la simetría de la distribución de los datos. Como se observa en esta figura, al inicio del proceso los estudiantes tienden a sobrestimar su trabajo, no obstante conforme avanzan las versiones del PSP, sus estimaciones tienden a estabilizarse hacia cierto grado de subestimación. Tomando como valor de referencia el 25% de margen de error en las estimaciones, a excepción del programa 2 y 6, se observa que las medianas del resto de los programas se aproximan o están dentro de este valor de referencia. Con respecto a los programas 6, 7 y 8, que representan la versión 2.1 del proceso, el 36%, 50% y 71% (respectivamente) de los estudiantes fueron capaces de estimar dentro del 25% de margen de error que se menciona en la literatura [9] Esfuerzo PSP emplea las estimaciones de tamaño para calcular el esfuerzo estimado. En la Figura 3 se muestra un diagrama de cajas donde se representa la distribución de la precisión de las estimaciones del esfuerzo. De manera similar a las estimaciones de tamaño, se observa que al inicio del proceso los estudiantes tienden a sobrestimar el esfuerzo de desarrollo, pero conforme avanzan en el proceso sus estimaciones tienden a mejorar. Volviendo a tomar como valor de referencia el 25% de margen de error en las estimaciones, a excepción del programa 1, se observa que las medianas del resto de los programas se encuentran dentro de este valor de referencia. Tomando como referente la versión 2.1 del proceso, el 64%, 79% y 71% de los estudiantes que desarrollaron los programas 6, 7 y 8 (respectivamente) fueron capaces de estimar dentro un 25% de margen de error. 207

14 Omar S. Gómez GerzOn e. Gómez antonio a. aguileta raúl a. aguilar Porcentaje de error en estimación (%) (v0) 2 (v0.1) 3 (v1) 4 (v1.1) 5 (v2) 6 (v2.1) 7 (v2.1) 8 (v2.1) Número de programa y versión de PSP Figura 3. Error en estimación con respecto al esfuerzo Calidad del Producto El otro componente principal del PSP se refiere a la calidad, donde se promueve la habilidad de encontrar y remover defectos en fases tempranas del proceso de desa - rrollo. Las revisiones de diseño y de código son actividades que se incorporan en PSP a partir de la versión 2 del proceso. Al incluir estas actividades en fases tempranas del proceso de desarrollo, se espera que los defectos encontrados en compilación y prue - bas disminuyan considerablemente, aumentando así la calidad del producto. En la Figura 4 se muestra un diagrama de cajas con la distribución de defectos removidos en la actividad de pruebas de los distintos programas. Como se observa en esta figura, los defectos tienden a reducir conforme avanzan las versiones del proceso Productividad A nivel empresarial, la productividad es una medición relevante para cuantificar los productos o servicios generados en términos del tiempo requerido para producirlos. En PSP, la productividad individual se mide de acuerdo a las líneas de código produ - cidas por hora (LOC/Hora). En la Figura 5 se muestra el diagrama de cajas con la distribución de productividades de los estudiantes en los distintos programas desarro - llados durante el curso. 208

15 Proceso de software Personal en la academia: experiencias de aplicación en méxico Como se observa en esta figura, las medianas presentan cierto grado de varia - bilidad en los ocho programas. En el programa 5 se observó la menor productividad (28 LOC/Hora), mientras que la mayor productividad se presentó en el programa 4 (73 LOC/Hora). De manera general, en el curso se observó una productividad media de 53 LOC/Hora Reacciones de los Estudiantes Con el fin de obtener una retroalimentación del curso, al final de éste, se les pidió a los estudiantes evaluar de manera anónima el PSP, así como la herramienta de apoyo (Process Dashboard [28]) que usaron para recabar las mediciones Núm. de defectos removidos en pruebas /K LOC (v0) 2 (v0.1) 3 (v1) 4 (v1.1) 5 (v2) 6 (v2.1) 7 (v2.1) 8 (v2.1) Número de programa y versión de PSP Figura 4. Defectos removidos por cada mil líneas de código (en Inglés, KLOC) en la actividad de pruebas. Se le pidió a los estudiantes describieran: 1) aspectos del PSP que pretenden aplicar como profesionales, 2) la mayor dificultad de aprender el proceso y 3) aspec - tos positivos y negativos del PSP. Referente al primer cuestionamiento, los estudiantes coincidieron en pretender usar el registro de tiempos para tener mejores estimados con respecto al tiempo y tamaño de los productos a construir. Además del registro de tiempos y tamaños, dos estudiantes pretenden llevar un registro de errores para tener mayor control sobre la calidad de sus productos. De 209

16 Omar S. Gómez GerzOn e. Gómez antonio a. aguileta raúl a. aguilar manera similar, otros dos estudiantes pretenden trabajar más en el diseño conceptual para evitar la propagación de defectos en fases tardías del proceso de desarrollo. Algunos comentarios obtenidos respecto a este punto fueron los siguientes: Siento que lo que más aplicaría y a mi criterio sería la gestión de mis tiempos y probablemente la gestión de mis defectos. La estimación de tiempos y líneas de código para un proyecto. La parte de estimar tiempos y tamaños me parece más útil ya que permite demostrar la valía de un ingeniero en demostrar objetivamente estimaciones de sus capacidades Líneas de código/hora (v0) 2 (v0.1) 3 (v1) 4 (v1.1) 5 (v2) 6 (v2.1) 7 (v2.1) 8 (v2.1) Número de programa y versión de PSP Figura 5. Productividad observada en los distintos programas. Sobre la dificultad percibida de aprender PSP, los estudiantes manifestaron cierta dificultad para acostumbrarse a registrar sus tiempos y sus defectos, ya que no estaban habituados a este tipo de actividades. Otra de las dificultades que se mencionó es tener que codificar sin depurar su código simultáneamente. Los estudiantes suelen depurar su código conforme codifican, pero PSP exige disciplina para llevar a cabo, en orden, el proceso de desarrollo. Otra de las dificultades mencionadas es tener que hacer revisiones de diseño, ya que los estudiantes suelen encontrar defectos sólo durante la verificación del producto y no en fases tempranas del proceso

17 Proceso de software Personal en la academia: experiencias de aplicación en méxico de desarrollo como lo es el diseño. A continuación se muestran algunos comentarios de los estu - diantes con respecto a este punto: Siento que la dificultad yace en adaptarse y familiarizarse con la captura de los tiempos. Adaptarme al método de programación (sin pruebas en tiempo de codificación). Verificación de defectos, pues no estás acostumbrado a encontrar defectos en fases tempranas, esto incluye las revisiones y la etapa de pruebas también, pues antes las pruebas eran más informales. Sobre aspectos positivos del PSP, los estudiantes reconocen las bondades del pro - ceso, al ayudarles a contar con estimaciones precisas de los productos a construir. Re - conocen el profesionalismo que brinda este proceso, así como reconocen tener más confianza ya que se conocen mejor. Aunque los estudiantes usaron como soporte una herramienta para recolectar mediciones, el principal aspecto negativo del PSP, de acuerdo con las impresiones de los estudiantes, es que es un proceso tedioso, que implica cierta complejidad para entenderlo así como requiere disciplina para seguirlo. Sobre la evaluación de la herramienta de soporte, los estudiantes manifestaron que fue bastante útil para recolectar las mediciones. A continuación se muestran algunos comentarios de los estudiantes referentes al uso de la herramienta: Utilizar esta herramienta considero que aligeró el curso ( ) sin duda ayudó en gran medida para concentrarnos en lo que realmente era importante: entender y aprender PSP. Muy sencilla, automatiza gran parte de las tareas que sin ella sería muy compli - cado y tedioso. Muy buena, simplificó mucho el registro de tiempos y de defectos, así como su categorización de estos DISCUSIÓN Los resultados observados con respecto a las estimaciones de tamaño y esfuerzo sugieren que los estudiantes no mejoran considerablemente en sus estimaciones du - rante las distintas versiones del proceso. Sin embargo, con 211

18 Omar S. Gómez GerzOn e. Gómez antonio a. aguileta raúl a. aguilar respecto al esfuerzo se observa que, conforme los estudiantes avanzan en las versiones del PSP, se incre - menta la precisión en sus estimaciones. Este aumento de precisión se corrobora de acuerdo con los resultados publicados en la literatura [9]. Por otra parte, se dice que las líneas de código (LOC) correlacionan razonable - mente bien con el esfuerzo de desarrollo [15]. No obstante, de acuerdo con los resul - tados obtenidos, esta afirmación se corrobora parcialmente en un 28%, pues sólo en las mediciones de cuatro de los catorce estudiantes se obtuvieron coeficientes de determinación iguales o superiores al 50%. En cuanto a la calidad, se observa una disminución en la densidad de defectos durante la actividad de pruebas. De aproximadamente una tasa de remoción de 20 defectos/kloc al inicio del proceso, los defectos disminuyeron al final del proceso en una tasa de remoción de 3 defectos/kloc. Es decir, se observó un factor de mejora de 6.6. Por su parte, Hayes reportó un factor de mejora de 2.5 [9], mientras que Abrahamson y Kautz reportaron un factor de mejora de 4.2 [1]. En cuanto a la productividad, se observa una variabilidad en las distintas versiones del proceso. Es difícil apreciar una mejora en la productividad a lo largo del proceso, es decir, no se observa ganancia o pérdida sustantiva de la productividad. Este hallazgo se corrobora de acuerdo con los resultados reportados en [9]. Con respecto a las reacciones de los estudiantes, la mayoría aprecia las bondades del PSP, reconocen que mantener un registro de sus mediciones les ayuda a mejorar en sus estimaciones de tamaño y esfuerzo así como les ayuda a mejorar la calidad de sus productos. Sin embargo, aun empleando una herramienta de soporte, los estu - diantes se quejan de lo tedioso que es seguir el proceso. Esta apreciación muy pro - bablemente se deba al cambio de paradigma y a la falta de disciplina con que se enfrentan los estudiantes al aprender PSP. Como ya se mencionó, los resultados observados en este curso no se deben tomar de forma literal para indicar el éxito o fracaso del PSP. El objetivo del curso no es evaluar PSP, sino permitir que los estudiantes exploren las características de este proceso. La experiencia de impartir PSP en la FMat - UADY ha sido fructífera ya que, como menciona Wohlin [29], este curso ofrece un contexto idóneo para llevar a cabo estudios experimentales donde se pongan a prueba diversas hipótesis sobre la inge - niería de software. 212

19 Proceso de software Personal en la academia: experiencias de aplicación en méxico 12.6 CONCLUSIONES Comenzar a impartir cursos universitarios sobre mejora de procesos como PSP, es un indicador de que se está comenzando a tomar en cuenta las necesidades de la industria del software con respecto a la formación de recursos humanos especializados en temas de control y mejora de procesos. PSP es un proceso donde el ingeniero de software aprende a controlar y desarrollar su propio proceso de construcción de software. No obstante, como se discute en la literatura [22, 4], el clima organizacional es un factor determinante para que el ingeniero continúe aplicando prácticas disciplinadas como las descritas en el PSP. En este Capítulo se presentó un reporte sobre las experiencias obtenidas en México tras enseñar PSP en un curso universitario. Los distintos indicadores que aparecen en este Capítulo se obtuvieron del curso PSP impartido durante el semestre agosto - diciembre 2012 de la Licenciatura en Ingeniería de Software de la FMat - UADY. Aunque los resultados obtenidos no indican una mejora significativa con respecto a las estimaciones de tamaño y esfuerzo, los defectos removidos en la actividad de pruebas se redujeron en un factor de 6.6. Se observa que el uso de actividades preventivas, como son las revisiones de diseño y código, demuestran ser efectivas. Se espera que esta experiencia sirva de guía para aquellos académicos interesados en introducir PSP en cursos universitarios. En la FMat - UADY se pretende seguir impartiendo este curso con la finalidad de: 1) enseñar a los estudiantes a seguir un proceso disciplinado de desarrollo de software y 2) realizar investigación en IS a partir de las mediciones que generan los estudiantes. REFERENCIAS BIBLIOGRÁFICAS 1. Abrahamsson, P., and Kautz, K. Personal Software Process: Classroom Experiences from Finland. In Software Quality, ECSQ 2002, J. Kontio and R. Conradi, Eds., vol of Lecture Notes in Computer Science. Springer Berlin Heidelberg, 2002, pp Abrahamsson, P., and Kautz, K. The Personal Software Process: Experiences from Denmark. In Euromicro Conference, Proceedings. 28th (2002), pp

20 Omar S. Gómez GerzOn e. Gómez antonio a. aguileta raúl a. aguilar 3. Borstler, J., Carrington, D., Hislop, G., Lisack, S., Olson, K., and Williams, L. Teaching PSP: Challenges and Lessons Learned. Software, IEEE 19, 5 (2002), pp Cannon, R. L. Putting the Personal Software Process (sm) into Practice. Conference on Software Engineering Education and Training 0 (1999), p Carrington, D., McEniery, B., and Johnston, D. PSP(sm) in the Large Class. In Software Engineering Education and Training, Proceedings. 14th Conf. on (2001), pp Carver, J., Jaccheri, L., Morasca, S., and Shull, F. Issues in Using Students in Empirical Studies in Software Engineering Education. In METRICS 03: Proceedings of the 9th International Symposium on Software Metrics (Washington, DC, USA, 2003), IEEE Computer Society, p Disney, A. M., and Johnson, P. M. Investigating Data Quality Problems in the PSP. In Proceedings of the 6th ACM SIGSOFT international symposium on Foundations of software engineering (NY, USA, 1998), SIGSOFT 98/FSE - 6, ACM, pp Ferguson, P., Humphrey, W., Khajenoori, S., Macke, S., and Matvya, A. Results of Applying the Personal Software Process. Computer 30, 5 (1997), pp Hayes, W. Using a Personal Software Processsm to Improve Performance. In Software Metrics Symposium, Metrics Proceedings. Fifth International (1998), pp Hayes, W., and Over, J. Personal software process (psp): An Empirical Study of the Impact of PSP on Individual Engineers. Tech. Rep. CMU/SEI TR - 001, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, June Hou, L., and Tomayko, J. Applying the Personal Software Process in CS1: An Experiment. In Proceedings of the twenty - ninth SIGCSE technical symposium on Computer science education (New York, NY, USA, 1998), SIGCSE 98, ACM, pp Humphrey, W. PSP(sm): A Self - improvement Process for Software Engineers, First ed. Addison - Wesley Professional, Humphrey, W. S. Characterizing the Software Process: A Maturity Framework. IEEE Software 5, 2 (1988), pp Humphrey, W. S. Managing the Software Process. Addison - Wesley Longman Publishing Co., Inc., Boston, MA, USA, Humphrey, W. S. A Discipline for Software Engineering. Addison - Wesley Longman Publishing Co., Inc., Boston, MA, USA,