INGENIERÍA DE SOFTWARE E INGENIERÍA DEL CONOCIMIENTO:...

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

INTERRELACIONADAS

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

1a. edición: 2014© Universidad de Medellín

ISBN: 978-958-8815-31-2

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, c2014.

716 p.; 17 x 24 cm

ISBN 978-958-8815-22-0

1.Contratos y responsabilidad 2. Contratos comerciales internacionales 3. Contratos comerciales 4. Derecho comercial 5. Jurisprudencia comercial. I Universidad de Medellín.

CDD 346.07 / M 337

Catalogación bibliográfica - Universidad de Medellín. Biblioteca Eduardo Fernández Botero. María Isabel Quintero Bedoya.

© 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

© 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

Editor:Leonardo David López EscobarDirección electrónica: [email protected] de Medellín. Medellín, ColombiaCra. 87 No. 30-65. Bloque 20, piso 2.Teléfonos: 340 52 42 - 340 53 35Medellín - Colombia

Distribución y ventas:Universidad de Medellíne-mail: [email protected]; www.udem.edu.coCra. 87 No. 30-65 / Teléfono: 340 52 42 - Mede-llín, Colombia

Corrección de estilo:

Diseño portada:Claudia Castrillón Á[email protected]

Diagramación:Hernán D. Durango [email protected]

Impresión: Xpress Estudio Gráfico y Digital S.A. Av. Américas No. 39-53 / PBX (+57 1) 602 0808 - 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.

▪ 197

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 Ins-tituto 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. 13615, Mérida, Yucatán, México. Dirección electrónica: [email protected]; http://www.matematicas.uady.mx

** Facultad de Matemáticas, Universidad Autónoma de Yucatán, Anillo Periférico Norte, Tablaje Cat. 13615, Mérida, Yucatán, México. Dirección electrónica: [email protected]; http://www.matematicas.uady.mx

*** Facultad de Matemáticas, Universidad Autónoma de Yucatán, Anillo Periférico Norte, Tablaje Cat. 13615, Mérida, Yucatán, México. Dirección electrónica: [email protected]; http://www.matematicas.uady.mx

**** Facultad de Matemáticas, Universidad Autónoma de Yucatán, Anillo Periférico Norte, Tablaje Cat. 13615, Mérida, Yucatán, México. Dirección electrónica: [email protected]; http://www.matematicas.uady.mx

Omar S. Gómez • GerzOn e. Gómez • antOniO a. aGuileta • raúl a. aGuilar

▪ 198

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 software1 [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 ne-cesarios 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ís2 comen-zaron 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).

1 A este modelo se le conoce como Modelo de Madurez de Capacidades, en Inglés, Capa - bi-lity 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.

PrOceSO de SOftware PerSOnal en la academia: exPerienciaS de aPlicación en méxicO

▪ 199

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.

12.1 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 constru-ye, 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 ejerci-cios 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.


▪ 200

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

PSP2.1

– Plantillas de diseño

PSP1

– Estimación de tamaño– Reporte de pruebas

PSP1.1

– Planificación de tareas– Planificación de calendario

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 an-teriores se usan para estimar el tiempo que le llevará construir el siguiente programa. Durante la construcción de cada programa, se registran los tiem-pos 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


▪ 201

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.

12.2 TRABAJO RELACIONADO

Existen algunos reportes de experiencias de aplicación del PSP en la aca-demia [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 estu-diantes, 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 licen-ciatura, 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 estudian-tes [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


▪ 202

[20, 21, 5, 3], hojas de cálculo [2, 1, 11, 20, 24, 25, 3] y programas infor-má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 ca-lidad 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 comentarios3 de estudiantes que llevaron este curso:

“It is very time consuming and very frustrating to look at all [the] do-cuments 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 motiva-tional 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].

12.3 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 2012.

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.


▪ 203

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 estudian-te. 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 ho-ras 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

PSPDescripción

Tamaño (LOC)

Esfuerzo (Mins)

1 v0

Cálculo de promedio y desviación estándar

de un conjunto de números almacenados en

una lista enlazada.

140.1 169.9

2 v0.1 Contador de líneas de código fuente. 218.14 339.71

3 v1

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.

249.36 283

4 v1.1

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.

231.21 189.43

5 v2Integración numérica de una función em-

pleando la regla de Simpson.123.07 219.57


▪ 204

Prog.Versión

PSPDescripción

Tamaño (LOC)

Esfuerzo (Mins)

6 v2.1Análisis semántico de un programa que

funciona como línea de comandos.267.29 327.57

7 v2.1

Uso de operaciones básicas sobre una tabla

de símbolos, como son: inserción, asigna-

ción, búsqueda e impresión (en pantalla)

de la tabla.

285.79 261.71

8 v2.1Uso de operaciones para gestionar un árbol

n - ario.297 274.93

De un total de 19 estudiantes inscritos en el curso, sólo 14 lo comple-taron 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.

12.4 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 presen-tan 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.

12.4.1 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


▪ 205

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 r2 observados en los catorce estudiantes.

Tabla 2. Correlaciones observadas entre tamaño y esfuerzo.

Estudiante Coeficiente de correlación r Coeficiente de determinación r2

1 0.8510 72.42%

2 0.5342 28.54%

3 0.4396 19.32%

4 0.7671 58.84%

5 0.7041 49.58%

6 0.3713 13.79%

7 0.3196 10.21%

8 0.1956 3.82%

9 0.7076 50.07%

10 0.3507 12.30%

11 0.5731 32.85%

12 0.5176 26.79%

13 0.4702 22.11%

14 - 0.4122 16.99%

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 - 1.0 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 determi-nación r2 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 calcula-ron a partir de las mediciones que representan el total de líneas de código


▪ 206

(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, indi-can un coeficiente de determinación r2=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.

-50

0

50

100

150

200

250

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

Po

rcen

taje

de

erro

r en

esti

mac

ión

(%

)

Figura 2. Error en estimación con respecto al tamaño.


▪ 207

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 identi-ficar 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 ver-siones 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].

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


▪ 208

-50

0

50

100

150

200

1 (v0) 2 (v0.1) 3 (v1) 4 (v1.1) 5 (v2) 6 (v2.1) 7 (v2.1) 8 (v2.1)


Po

rcen

taje

de

erro

r en

esti

mac

ión

(%

)

Figura 3. Error en estimación con respecto al esfuerzo.

12.4.3 Calidad del Producto

El otro componente principal del PSP se refiere a la calidad, donde se pro-mueve 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 con-siderablemente, 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.

12.4.4 Productividad

A nivel empresarial, la productividad es una medición relevante para cuan-tificar 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.


▪ 209

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.

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

0

25

50

75

100

1 (v0) 2 (v0.1) 3 (v1) 4 (v1.1) 5 (v2) 6 (v2.1) 7 (v2.1) 8 (v2.1)


Nú

m. d

e d

efec

tos

rem

ovi

do

s en

pru

ebas

/K

LO

C

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 pre-tenden 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 re-gistro de tiempos y tamaños, dos estudiantes pretenden llevar un registro de errores para tener mayor control sobre la calidad de sus productos. De


▪ 210

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 pro-ceso 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”.

25

50

75

100

125

1 (v0) 2 (v0.1) 3 (v1) 4 (v1.1) 5 (v2) 6 (v2.1) 7 (v2.1) 8 (v2.1)


Lín

eas

de

cód

igo

/Ho

ra

Figura 5. Productividad observada en los distintos programas.

Sobre la dificultad percibida de aprender PSP, los estudiantes manifes-taron 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


▪ 211

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 de-fectos 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 produc-tos 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 mani-festaron 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 impor-tante: 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”.

12.5 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


▪ 212

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 razo-nable - 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 disminu-yeron 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 de-ben 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.


▪ 213

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 discipli-nadas 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 indica-dores 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 Ex-periences from Finland. In Software Quality, ECSQ 2002, J. Kontio and R. Conradi, Eds., vol. 2349 of Lecture Notes in Computer Science. Springer Berlin Heidelberg, 2002, pp. 175 - 185.

2. Abrahamsson, P., and Kautz, K. The Personal Software Process: Experiences from Denmark. In Euromicro Conference, 2002. Proceedings. 28th (2002), pp. 367 - 374.


▪ 214

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. 42 - 48.

4. Cannon, R. L. Putting the Personal Software Process (sm) into Practice. Confe-rence on Software Engineering Education and Training 0 (1999), p. 34.

5. Carrington, D., McEniery, B., and Johnston, D. PSP(sm) in the Large Class. In Software Engineering Education and Training, 2001. Proceedings. 14th Conf. on (2001), pp. 81 - 88.

6. Carver, J., Jaccheri, L., Morasca, S., and Shull, F. Issues in Using Students in Empirical Studies in Software Engineering Education. In METRICS ‘03: Proce-edings of the 9th International Symposium on Software Metrics (Washington, DC, USA, 2003), IEEE Computer Society, p. 239.

7. 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. 143 - 152.

8. Ferguson, P., Humphrey, W., Khajenoori, S., Macke, S., and Matvya, A. Results of Applying the Personal Software Process. Computer 30, 5 (1997), pp. 24 - 31.

9. Hayes, W. Using a Personal Software Processsm to Improve Performance. In Software Metrics Symposium, 1998. Metrics 1998. Proceedings. Fifth International (1998), pp. 61 - 71.

10. Hayes, W., and Over, J. Personal software process (psp): An Empirical Study of the Impact of PSP on Individual Engineers. Tech. Rep. CMU/SEI - 97 - TR - 001, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, June 1997.

11. 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. 322 - 325.

12. Humphrey, W. PSP(sm): A Self - improvement Process for Software Engineers, First ed. Addison - Wesley Professional, 2005.

13. Humphrey, W. S. Characterizing the Software Process: A Maturity Framework. IEEE Software 5, 2 (1988), pp. 73 - 79.

14. Humphrey, W. S. Managing the Software Process. Addison - Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1989.

15. Humphrey, W. S. A Discipline for Software Engineering. Addison - Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1995.


▪ 215

16. Höst, M., Regnell, B., and Wohlin, C. Using Students as Subjects: A Compa-rative Study of Students and Professionals in Lead - time Impact Assessment. Empirical Softw. Engg. 5, 3 (Nov. 2000), pp. 201 - 214.

17. Johnson, P., and Disney, A. The Personal Software Process: A Cautionary Case Study. Software, IEEE 15, 6 (1998), pp. 85 - 88.

18. Jørgensen, M., and Sjøberg, D. I. K. Software Process Improvement and Human Judgement Heuristics. Scand. J. Inf. Syst. 13 (June 2001), pp. 99 - 121.

19. Kelly, D., and Culleton, B. Process Improvement for Small Organizations. Computer 32, 10 (1999), pp. 41 - 47.

20. Lisack, S. The Personal Software Process in the Classroom: Student Reactions (An Experience Report). In Software Engineering Education amp; Training, 2000. Proceedings. 13th Conference on (2000), pp. 169 - 175.

21. Maletic, J. I., Marcus, A., and Howald, A. Incorporating PSP into a Traditional Software Engineering Course: An Experience Report. In Proceedings of the 14th Conference on Software Engineering Education and Training (Washing-ton, DC, USA, 2001), CSEET ‘01, IEEE Computer Society, pp. 89 - .

22. Morisio, M. Applying the PSP in Industry. Software, IEEE 17, 6 (2000), pp. 90 - 95.

23. Nichols, W., and Salazar, R. Deploying TSP on a National Scale: An Experience Report from Pilot Projects in Mexico. Tech. Rep. CMU/SEI - 2009 - TR - 011, Software Engineering Institute, Carnegie Mellon, Pittsburgh, PA, March 2009.

24. Prechelt, L., Unger, B., and Gramberg, O. Experience Report: Teaching and Using the Personal Software Process (PSP), 1997. Submission to ESEC’1997.

25. Runeson, P. Experiences from Teaching PSP for Freshmen. In Software En-gineering Education and Training, 2001. Proceedings. 14th Conference on (2001), pp. 98 - 107.

26. Runeson, P. Using Students as Experiment Subjects - An Analysis on Graduate and Freshmen Student Data. In Proceedings of the 7th International Confe-rence on Empirical Assessment in Software Engineering (Keele University, UK, 2003), pp. 95 - 102.

27. Svahnberg, M., Aurum, A., and Wohlin, C. Using Students as Subjects – An Empirical Evaluation. In ESEM ‘08: Proceedings of the Second ACM - IEEE international symposium on Empirical software engineering and measurement (NY, USA, 2008), ACM, pp. 288 - 290.

28. Tuma Solutions, LLC. Process dashboard, 1998 - 2012. version 1.15.0.1.

29. Wohlin, C. The Personal Software Process as a Context for Empirical Studies. Software Process Newsletter 12 (1998), pp. 7 - 12.

INGENIERÍA DE SOFTWARE E INGENIERÍA DEL CONOCIMIENTO:...

Documents

Transcript of INGENIERÍA DE SOFTWARE E INGENIERÍA DEL CONOCIMIENTO:...