Programación Matemática y Software (2015) 7 (3): 36-43.

ISSN: 2007-
3283

Implementación de metodología TSPi en centros universitarios

de desarrollo de software

TSPi implementation in software development centers for academic purposes

José Alberto Vela Dávila1*

1
Instituto Tecnológico Superior de Fresnillo / Universidad Politécnica de Zacatecas
Fresnillo, Zacatecas, México
* Correo-e: [email protected]

PALABRAS CLAVE: RESUMEN

procesos, planeación, estándares, Actualmente los ingenieros en sistemas no sólo deben ser expertos en tecnologías
TSPi, métricas, metodologías de la información, además deben poseer formación como ingenieros de
software capaces de atender las demandas actuales de las organizaciones en
cuanto a modelos y estándares de calidad. En este artículo se describe la
experiencia de la implementación de la metodología Team Software Proccess
(TSP) para el desarrollo de software en la carrera de Ingeniería en Sistemas
Computacionales del Instituto Técnológico Superior de Fresnillo. Se instruyó a
los estudiantes de la carrera en cuanto a procesos. Además se incluye el
análisis del comportamiento de los estudiantes al ser integrados a equipos de
trabajo dentro de centros de desarrollo de software con librerías de procesos
establecidas. Por lo tanto, fueron disciplinados para trabajar siguiendo
estándares, respetando tiempos, planificaciones y haciendo uso de algunas
métricas para medir el desempeño de los proyectos. Con ello adquirieron
bases para la gestión y seguimiento de un proyecto de software, con la intención
de cubrir las necesidades actuales de la industria.

KEYWORDS: ABSTRACT

process, schedules, standards, TSPi,

metrics, methodologies Nowadays, the computer systems engineers not only have to be experts in
informa- tion technologies, but also must be formed as software engineers
capable to attend the present demands from different organizations, referring to
models and quality standards. In this paper it is presented the process
implementation on software de- velopment done in the Computer Systems
Major of a College or University, using the TSPi methodology. The paper shows
the experience on preparing the students of Process Major, including the students
behavior at the moment of being integrated to working teams within the Software
development centers with libraries of processes established, then after this, they
are disciplined to work following different stan- dards, respecting times,
schedules using metrics to measure the performance of the projects, giving the
basis to the management and the tracking of a software project covering so the
present needs of the software industry.

Recibido: 7 de febrero de 2015• Aceptado: 25 de junio de 2015 • Publicado en línea: 30 de octubre de 2015
1
 Programación Matemática y Software (2015) 7 (3): 36-43. ISSN: 2007-

1 InTRODuCCIÓn [4]. Esto les

Hace algunos años, cuando los proyectos de

software eran pequeños, el desarrollo del software
se hacía de forma artesanal, es decir, parecía
innecesario el uso de metodologías, estándares y
menos procesos que incluyeran las mejores
prácticas. A medida que los proyectos fueron cada
vez más grandes en tamaño y complejidad, las
compañías acumularon fracasos y las posibilidades de
éxito de los proyectos disminuyeron drásticamente,
tal como lo muestran las estadísticas del libro A
discipline for software engineering [1].
Los proyectos de desarrollo de software ge-
neralmente comparten un problema: “la crisis del
software”. Un término con el que muchos autores
engloban los problemas comunes de los proyectos
de software, como: costos de desarrollo que
sobrepasan lo presupuestado; software que
presenta una gran cantidad de errores, y tiempos de
desarrollo o entrega fuera del calendario estipulado
[2].
Debido a lo anterior, las organizaciones de
desarrollo de software requieren alternativas para
abordar estos problemas. Como una solución viable se
propone la implementación de la metodología Team
Software Process (TSP) o proceso de desarrollo de
software en equipo. Ésta permite enfrentar el desafío
de la crisis del software a través del incremento en
la productividad, disminución de defectos de los
equipos, disminución de los errores insertados y el
cumplimiento de la calendarización en el tiempo
estipulado. Se eligió TSP porque es una metodología
que ha mostrado ser provechosa, como lo muestra
el reporte de Noopur Davis y Julia Mullaney [3], en
el cual se presentan los beneficios obtenidos de 20
proyectos TSP en 13 organizaciones alrededor del
mundo.
El reto que se encuentra al implementar TSP es
que se aplica en equipos de trabajo que
pertenecen a empresas grandes e importantes; por
lo tanto se asume que ya estaban entrenados en y
dominaban la metodología. Con este artículo se
contestará a la pregunta ¿qué pasa cuando se
instruye a estudiantes de Ingeniería en Sistemas
Computacionales para desarrollar software
utilizando procesos por primera vez, específicamente
TSP?
De acuerdo con Humprey [4], antes de adoptar
TSP se debe entrenar a cada uno de los miembros
de los equipos en proceso personal para el
desarrollo de software (PSP, por sus siglas en inglés)

2
 Programación Matemática y Software (2015) 7 (3): 36-43. ISSN: 2007-

permitirá aprender una disciplina personal de

trabajo, los introduce al uso de procesos, así como
al empleo y seguimiento de métricas. A partir de
lo anterior, en el Instituto Tecnológico Superior de
Fresnillo se decidió dar formación a dos equipos de
trabajo como prerrequisito. Cada equipo estuvo
integrado por tres hombres y una mujer con
edades entre 20 y 22 años. Se les capacitó primero
en PSP y después en TSP con el desarrollo de un
proyecto por equipo. Este artículo muestra el
resultado e impacto de la formación de estos
estudiantes de la carrera de Ingeniería en Sistemas
en el uso y aplicación de esta metodología
orientada a procesos. Es importante resaltar que
para agilizar el registro de datos y su posterior
análisis, algunas de las formas de TSP se
sustituyeron con el uso de Process Dashboard. Éste
es una herramienta de software libre creada con el
propósito de facilitar el uso de TSP y PSP, y de
esta manera disminuir la curva de adopción de
estas metodologías [5]. Esta herramienta fue de-
sarrollada originalmente por la defensa de los
Estados Unidos en 1998 y ha continuado su
desarrollo bajo la dirección de Tuman Solutions
(empresa de desarrollo de software). En la tabla 1
se muestran las fun- cionalidades y fortalezas de
esta herramienta.
Este documento está estructurado como sigue:
la primera sección muestra las metodologías de
procesos utilizadas; en la siguiente se describe la
experiencia obtenida durante el desarrollo de este
proyecto, que incluye la formación de los
estudiantes miembros de los equipos, el escenario
y el proceso de desarrollo del proyecto; en la
penúltima sección se realiza el análisis de los
datos, y finalmente se presentan las conclusiones.

2 METODOLOGÍAS DE PROCESOS

Las metodologías de procesos TSP y PSP que se

describen a continuación fueron creadas por Watts
Humphrey para proporcionar un marco de
referencia en el desarrollo de software. Proveen
lineamientos sobre los procedimientos, así como
la adopción de estrategias para el uso de métodos
de desarrollo que sirvan tanto para el programador
como para el equipo [3].

• Proceso personal para el desarrollo de software

(PSP). Es una disciplina de trabajo. El PSP está
compuesto de formas y estándares; provee un
marco definido para medir, analizar y
administrar

3
 Programación Matemática y Software (2015) 7 (3): 36-43. ISSN: 2007-

el trabajo personal. El PSP divide el desarrollo Una vez terminada la formación, se ejecutó el
de un programa en seis etapas: planeación, proyecto piloto, durante el cual se registraron tanto
diseño, codificación, compilación, pruebas y los datos estimados como los reales a través de una
postmortem. Durante el desarrollo de este herramienta de seguimiento y administración de
programa se registran los datos o métricas, como proyectos llamada Process Dashboard. Finalmente
el tiempo de desarrollo o el tamaño de los se realizó el análisis del impacto en los proyectos.
programas. Posteriormente los datos son
Para realizar este análisis, al no contar con
analizados y utilizados como una forma de
datos históricos, pues se está arrancando con un
mejorar el desempeño personal [1]. PSP también
nuevo proyecto piloto, se decidió consultar algunos
refiere cómo estimar y planear proyectos
artículos, como [2, 9, 10], entre otros. En ellos se
además de administrar la calidad.
reportan resultados de la ejecución de proyectos
• Proceso para el desarrollo de software en utilizando TSPi, que sirven como referencia para
equipo (TSP). Es un marco de trabajo para poder medir el impacto del proyecto.
desarrollo de software y un proceso estructurado
para construir y guiar equipos de trabajo [6, 7].
B. Escenario de aplicación
Es una guía paso a paso para lograr un proyecto
de software en equipo, define claramente los
roles que cada miembro debe desempeñar, así El Instituto Tecnológico Superior de Fresnillo,
como sus respon- sabilidades [8]. conocido por sus siglas ITSF, es un tecnológico
• Introducción al Proceso para el desarrollo descentralizado que se encuentra ubicado en
de software en equipo (TSPi). Es una versión Fresnillo, Zacatecas, México. En esta institución se
académica de TSP. Es un proceso definido que imparte el programa educativo de Ingeniería en
proporciona un marco de desarrollo y para esto Sistemas Computacionales. Como una forma de que
utiliza formas, procesos, estándares y métodos los estudiantes relacionen la teoría con la práctica
necesarios para desarrollar productos de y desarrollen habilidades y destrezas relacionadas
software de alta calidad [9][8]. con su carrera, se decidió crear una área de
desarrollo cuyo objetivo inicial fue que los
estudiantes desarrollaran proyectos de software
3 EXPERIEnCIA
utilizando estándares internacionales probados, de
manera que cuando se integren a la industria la
A. Formación de los estudiantes curva de adaptación sea menor.
Por lo mencionado en la introducción, se
En esta sección se describe el proceso seguido para decidió implementar TSPi. En esta primera ocasión se
la formación de los alumnos en TSPi, que se muestra integraron dos equipos, y cada uno desarrolló un
en la figura 1. Como se puede apreciar, primero se proyecto real propuesto por ellos durante un
semestre, como parte de la residencia profesional.
Como estrategia para agilizar la recolección de
métricas y el seguimiento del proyecto se
determinó utilizar la herramienta Process
Dashboard [5], la cual sustituye algunas formas de
TSPi. En la tabla 1 se puede observar la
funcionalidad de la herramienta y en la tabla 2 se
puede ver la equivalencia de formas con TSPi.

C. Desarrollo del proyecto

Figura 1. Resumen del trabajo realizado

Una vez que los integrantes de los equipos

entrenó a los miembros de los equipos en el uso del contaban con un entrenamiento previo en PSP, se
proceso personal de desarrollo de software (PSP), les proporcionó una introducción a TSPi y se les
y se proporcionó una introducción básica al uso de enseñó a seguir los scripts de TSPi. Por lo tanto, se
procesos siguiendo TSPi. siguió el proceso de desarrollo que establece
Humphrey en su

4
 Programación Matemática y Software (2015) 7 (3): 36-43. ISSN: 2007-

Tabla 1. Funcionalidades de Process Dashboard

planeación, administrador de calidad y procesos (se
FuNCIONALIDADES DE LA HERRAMIENTA PROCESS fusionaron los roles), administrador de desarrollo y
DASHBOARD FuNCIONALIDAD DESCRIPCIÓN administrador de configuraciones o soporte.
Además del rol de TSPi, todos los miembros del
Tiempo, defectos, tamaño, datos
Recolección de datos actuales vs planeados equipo fueron ingenieros de desarrollo. TSPi sugiere
Planeación Plantillas, formatos, valor ganado el uso de tres ciclos de desarrollo; en este caso
sólo se utilizó un ciclo por tratarse de un proyecto
Reportes y estadísticas de
Seguimiento valor ganado piloto.
Gráficas y reportes que ayudan a Tal como lo muestra la figura 2, la siguiente etapa
Análisis de datos analizar tendencias históricas
es la planeación. Para ello, en lugar de utilizar la
Exportar datos Exportar a otros formatos forma sump, los equipos utilizaron la opción WBS
Multiplataforma Desarrollado en Java de dashboard, que permite crear una lista de
tareas con tiempo y tamaño estimado. En la etapa
de re- querimientos se utilizó el estándar de
libro Introduction to the team software process [8].
documentación SRS IEEE830; en la etapa de diseño,
El primer paso fue ejecutar el script general
un documento llamado “Diseño de alto nivel”, que
llamado “script de desarrollo del proceso de TSPi”,
concentra el diseño de la base de datos y la
que tiene como objetivo guiar a un equipo en el
arquitectura descrita con el modelo 4+1 vistas. El
desarrollo de un proyecto de software. En la figura 2
software se codificó en PHP. En la etapa de
se muestra el ciclo de desarrollo con las etapas que
pruebas se crearon el plan y los casos de prueba, y
se siguieron para el desarrollo de los productos.
finalmente se llevó a cabo una junta de postmortem
en la cual se analizó si se cumplieron los objetivos
definidos en el plan de calidad. Pos- teriormente se
analizó el desempeño individual de los miembros del
equipo, así como del conjunto.
Se utilizó también una versión inicial de la
biblioteca de procesos llamada “Tritón”, que se
desarrolló en el Centro de Investigación en
Matemáticas (CIMAT) por el grupo de ingeniería de
software y que puso a disposición de las
universidades en Zacatecas.
Nuevamente, para agilizar el registro de métricas
y el seguimiento a los proyectos, se utilizó la
Figura 2. Ciclo de desarrollo TSPi [1]
herramienta Process Dashboard. La tabla 2 muestra
las formas que se utilizaron como fuente de datos y
Tal como lo muestran el script y la figura 2, el para control del proyecto.
primer paso es ejecutar el lanzamiento 1; es decir, Con el objetivo de lograr que los estudiantes
el que corresponde al ciclo uno. Para esto se consultó apliquen de forma adecuada el TSPi, se aplicaron
el script específico para el lanzamiento 1, el cual, y monitorearon de manera especial los principios
entre otras cosas, indica que se debe: crear la básicos de TSPi que se muestran en la tabla 3.
estrategia, definir los equipos y establecer los
papeles para cada uno de los integrantes. Para ello 4 AnÁLISIS DE DATOS
se utilizó la forma “Info”, que permite recabar
datos de la experiencia, disponibilidad y Objetivo 1. Que los estudiantes den seguimiento al
habilidades de los miembros de los equipos, con la proyecto a través del valor ganado y que cumplan con
finalidad de asignar las funciones en el equipo. Por el valor planeado
lo tanto, se asignó a cada uno de los integrantes de
los equipos el papel para desempeñar durante el
D. Seguimiento del proyecto mediante el uso
desarrollo del proyecto. Las funciones adoptadas
del valor ganado.
fueron: líder de equipo, administrador de

Una de las métricas más importantes para dar

5
 Programación Matemática y Software (2015) 7 (3): 36-43. ISSN: 2007-

seguimiento a proyectos es el valor ganado

(EV).

6
 Programación Matemática y Software (2015) 7 (3): 36-43. ISSN: 2007-

Tabla 2. Equivalencias de formas TSPi en Dashboard

Tabla 4. Valor ganado por semana equipo 1
EQuIVALENCIA EN PROCESS
FORMA TSPI DESCRIPCIÓN DASHBOARD SEMANAS CPV VG CuMPLIMIENTO
Muestra la lista de tareas Semana 1 7.30% 6.20% 84.93%
Work break Down
Tas el tiempo real de
Structure (WBS) Semana 2 12.80% 10.40% 81.25%
k ejecución así como el
estimado
Se registran horas Semana 3 22.60% 13.70% 60.62%
Schedule semanales Calendario individual
Reporte semanal de Semana 4 30.40% 23.20% 76.32%
trabajo
Week Reporte semanal de valor Semana 5 38.20% 34.80% 91.10%
realizado ganado
Semana 6 45.40% 39.50% 87.00%
Se define la estrategia de
Strat desarrollo Semana 7 51.70% 45.90% 88.78%
Muestra datos de
Semana 8 61.50% 49% 79.67%
tamaño, tiempo, Work break Down
incluye
Sump productividad, cpi, Semana 9 69.60% 54.80% 78.74%
Structure (WBS)
porcentaje Reuse y
porcentaje new reuso Semana 10 77.70% 56.70% 72.97%

Resume los datos para el Semana 11 84% 73.40% 87.38%

Sums tamaño del producto
Semana 12 92.50% 73.90% 79.89%
Registro de tiempo por
Logt Registro de tiempo Semana 13 98.40% 78.90% 80.18%
tarea
Semana 14 100% 89.60% 89.60%

Semana 15 100% 100% 100%

Tabla 3. Principios de TSPi aplicados

PRINCIPIO TSPI APLICADO COMO SE HACÍA ANTES

El análisis de estos datos se llevó a cabo a través
de la implementación de juntas de seguimiento
Integración de equipos y roles
No existían roles semanales o también llamadas juntas de estatus, en
bien definidos
las cuales se revisó el valor ganado acumulado por
Trabajo en equipo, integrantes No se conocía un proceso de semana planeado y real.
comprometidos integración de equipos
En la gráfica 1 y 2 se puede observar que se
Estimación y delimitación del cumple uno de los objetivos primordiales que es
No se estimaban los proyectos
proyecto
enseñar al estudiante a registrar el valor ganado y a
Seguimiento a los proyectos a Sólo se establecían fechas de
través de valor ganado dar seguimiento al proyecto a través de éste.
entrega,
Reuniones semanales de
se confía en la palabra
seguimiento

Reuniones informales sin agenda

Se definen objetivos que no son
Establecimiento de objetivos
medibles

Seguimiento a procesos a través

de scripts No existían procesos documentados

Se calcula determinando el porcentaje que le valor ganado real acumulado (VG) / valor ganado
corresponde a una tarea del total de horas planeado acumulado (CPV).
planeadas para el proyecto. Por ejemplo: si el
proyecto se calcula en 1,000 horas, una tarea que se
estime en 16 horas, representa 1.6% del valor
ganado [4]. En la tabla tabla 4 se muestra un
porcentaje de cumplimiento del valor ganado
planeado para el equipo 1, y en la tabla 5, para el
equipo 2. Éste se calculó al dividir el valor actual
entre el valor real. Porcentaje de cumplimiento =
7
 Programación Matemática y Software (2015) 7 (3): 36-43. ISSN: 2007-

Gráfica 1. Valor ganado por semana equipo 1

Si bien se puede observar que no se cumple al

100% con el valor ganado planeado por semana, se
ve que el valor que se va ganando por semana se
va

8
 Programación Matemática y Software (2015) 7 (3): 36-43. ISSN: 2007-

Tabla 5. Valor ganado por semana equipo 2

SEMANAS CPV VG CuMPLIMIENTO

Semana 1 6.40% 3.80% 59.38%

Semana 2 14.90% 10.10% 67.79%

Semana 3 22.80% 17.50% 76.75%

Semana 4 30.60% 24.30% 79.41%

Semana 5 36.50% 35.80% 98.08%

Semana 6 43.80% 38.60% 88.13%

Semana 7 51.90% 47.30% 91.14%

Semana 8 59.90% 54.70% 91.32%

Gráfica 2. Valor ganado por semana equipo 2
Semana 9 68.30% 59.90% 87.70%

Semana 10 76.80% 69.80% 90.89%

manteniendo constante (sobre todo en el equipo 2) Semana 11 83.70% 72.60% 86.74%

a medida que avanzan las semanas y se va Semana 12 91.50% 82.50% 90.16%

asimilando el uso de TSPi, lo cual permitió el retraso Semana 13 100% 100% 100%
de sólo una semana en la agenda para el equipo 1 y
ninguna semana de retraso para el equipo 2. Tabla 6. Estimación y datos reales de los proyectos piloto
En el comportamiento del equipo 1 se puede
observar que la semana 11 y 12 fueron críticas, EQuIPO 1 EQuIPO 2
MEDIDA
debido
a que no se obtuvo valor ganado, se invirtió el
tiempo
ESTI- ESTI-
en revisión y corrección de errores. MACIÓN
ACTuAL
DESVIA-
CIÓN MACIÓN
ACTuAL
DESVIA-
CIÓN

Agenda
14 15 7.1 13 13 0.0
(Semanas)
Objetivo 2. Terminar el proyecto dentro de la
agenda establecida Esfuerzo
2080.75 2144.8 3.1 1267.5 1236.2 -2.5
(horas)

La estimación del proyecto se hizo a través del

método de estimación de tareas que los alumnos Tabla 7. Muestra tabla 3 estimación vs actual del artículo
aprendieron en PSP llamado estimación basada en con referencia 2
proxys o Proxy based estimating (PROBE, por sus
MEASuRE ESTIMATION ACTuAL DEVIATION
siglas en inglés) [1]. Los resultados obtenidos se
pueden ver en la tabla 5. Schedule [SEM] 13 14.0 7.7%
La fórmula que se utilizó para obtener la Effort [HRA] 950.0 1121.0 18.0%
desviación, tanto de esfuerzo como de número de Size [KLOC] 6.9 8.5 22.5%
semanas de duración del proyecto, fue la siguiente:
100* ((Actual x – Estimado x)/ Estimado x), en Tabla 8. Muestra tabla 4 resultados del objetivo 1 del
donde x se sustituye por esfuerzo, semanas o artículo con referencia 2
tamaño.
Debido a que no se cuenta con datos históricos, MEASuRE GOAL ACTuAL DEVIATION
se decidió medir el impacto del trabajo realizado
comparándolo con otro proyecto similar. En este
caso se trata del mencionado en el artículo “A Schedule deviation
> 8%
7.7% -3.8%
(1 week)
small settings case study using TSPi in a software
Effort deviation < 15% 18.0% 20.2%
proyect” que aborda los beneficios de usar TSPi en un
proyecto de software. En las tablas 6 y 7 se muestran Cost deviation < 15% 18.0% 20.2%

algunos de los datos obtenidos en el proyecto ya

mencionado así
como las metas que planearon alcanzar con respecto a desviaciones en la agenda, el esfuerzo y

9
 Programación Matemática y Software (2015) 7 (3): 36-43. ISSN: 2007-

el tamaño de los programas. En la tabla 8 se muestra Como se puede ver en la tabla 5, la desviación
el porcentaje de desviación de la agenda del proyecto del proyecto piloto del equipo 1 es de 7.1% con
del artículo [2]. respecto a las semanas planeadas de desarrollo
contra las reales. Si se compara con la desviación
mostrada en

1
 Programación Matemática y Software (2015) 7 (3): 36-43. ISSN: 2007-

la tabla 6 del artículo [2], se puede observar que la Tabla 9. Muestra tabla 6 resultados del objetivo 3 del artículo
desviación del equipo del ITSF es un poco menor y
cumple con la meta que allí se establece; es decir, MEASuRE GOAL ACTuAL DEVIATION
una desviación de agenda menor a 8% equivalente
Project productivity
a una semana de retraso. La desviación del equipo 2 [LOC/Hour] > 7.3% 7.6% 3.9%
es cero. Se considera que esto sucedió debido a que % Released defects < 5.0 3.8 -24.8%
es más preciso y fácil estimar un proyecto de pocas
líneas.
En cuanto a la desviación del esfuerzo, se Tabla 10. Productividad de los equipos
puede observar que las métricas de ambos equipos
están por
debajo del objetivo utilizado en el artículo NÚMERO DE LÍNEAS
HORAS TOTALES PRODuCTIVIDAD
comparado; es decir, equipo 1, 3.1; equipo 2, -2.5. DESARROLLADAS PARA
ESFuERZO LOC X HORA
En los dos casos menor a la meta establecida <15%. EL PROYECTO

De esta manera se puede afirmar, a partir de las Equipo 1 20055 2144.8 9.4
mediciones, que el impacto de utilizar TSPi en Equipo 2 17850 1984 9.0
estudiantes de ingeniería es positivo.

Objetivo 3. Productividad aceptable de acuerdo a estándar que los obligó a establecer disciplina de
estándares de la industria trabajo. De acuerdo

El esfuerzo, la cantidad de líneas desarrolladas en

el proyecto y la productividad de los equipos son
datos relevantes en todo trabajo de desarrollo de
software. Por este motivo se muestran esos
indicadores en la tabla
10. Como se puede observar, la productividad es de
9.4 y 9 líneas de código por hora, para los equipos 1
y 2 respectivamente. Estos indicadores están por
encima de la productividad que muestra la tabla 9,
los cuales son resultados del trabajo tomado como
referencia. La productividad está incluso por encima
del estándar de la industria, entre 6 y 8 líneas de
código por hora, según algunos artículos [1, 7, 10].
Estos resultados se explican porque son proyectos
controlados y asistidos por asesores para lograr un
correcto entrenamiento en el uso de TSPi por parte
de los estudiantes.

5 COnCLuSIOnES

El objetivo final es entrenar a los alumnos en el uso

de TSPi para que cuando se integren a la industria
puedan ser agentes de cambio al aplicar estas
metodologías con una curva de aprendizaje lo más
corta posible, de manera que puedan ser
productivos en un tiempo menor al que
necesitarían de no contar con esta capacitación.
Uno de los retos importantes fue observar y
medir el rendimiento de los equipos de trabajo, una
vez que se les exigió utilizar una metodología

1
 Programación Matemática y Software (2015) 7 (3): 36-43. ISSN: 2007-

con los resultados mostrados en la sección

“Análisis de datos”, se puede determinar que los
estudiantes adoptaron el uso de procesos. Esto les
permitió dar seguimiento a su trabajo, semana
tras semana, a través de métricas como el valor
ganado, así como tomar decisiones para realizar
ajustes en los casos en que fueron necesarios y
monitorear el proyecto. De esa manera el
proyecto pudo ser entregado en tiempo y con base
en una agenda establecida desde la planeación
inicial, basada en estimaciones realizadas por los
mismos alumnos, que emplearon el método PROBE
de PSP [1].
También se llevó a cabo una administración de
riesgos, con intención de medir, controlar o
disminuir el impacto de alguna situación no
planeada que pudiera afectar el desarrollo del
proyecto. Como resultado se observó que los
riesgos se pudieron identificar fácilmente; sin
embargo, fue más difícill para los equipos definir
la estrategia adecuada para evitar o disminuir el
impacto del riesgo.
Cabe mencionar que es importante la im-
plementación de herramientas computacionales
robustas que apoyen y faciliten la asimilación de
me- todologías de desarrollo de procesos, por
ejemplo: TSPi. Un trabajo futuro será implementar
metodologías ágiles dentro del centro de desarrollo
de software de la institución para poder medir el
nivel de adopción de éstas y compararlo con los
resultados obtenidos con la herramienta TSPi.
Además se pretende realizar una investigación que
dé seguimiento a los alumnos que participaron en
estos proyectos y medir su desempeño dentro de la
industria.

1
 Programación Matemática y Software (2015) 7 (3): 36-43. ISSN: 2007-

REFEREnCIAS

1. Humphrey, W. S., A discipline for software

7. Nichols, W. R., Deploying TSP on a National
engineering. Nueva York: Addison-Wesley, 1995. p.
Scale: An Experience Report from Pilot Projects in
816.
Mexico. Softw. Eng. Process Manag, 2009,
2. Calvo Manzano, J., Cuevas, G., San Feliu, T.,
1(March), pp. 53- 57.
Caballero, E., I. Journal and I. Technologies, A Small
8. Humphrey,W. S., Introduction to the team software
Settings Case Study using TSPi in a Software Project ”
process. Nueva York: Addison-Wesley.
International Journal, vol. 2, pp. 245-250, 2008.
9. Calvo-Manzano, J., Cuevas, G., San Feliu, T., Impact
3. Mullaney, J., Davis, N. The Team Software Process
of TSPi on Software Projects. Electronics, Robotics and
(TSP) in practice: a summary of recent results,
Automotive Mechanics Conference, 2007. CERMA/
Software Engineering Institute, 2003. En línea.
IEEE, 2007, pp. 706-711.
4. Humphrey, W. S., TSP: Leading a Development
10. Calvo-Manzano, J., San Feliu, T., Análisis de la
Team. Nueva York: Addison-Wesley, 2006.
calidad y productividad en el desarrollo de un
5. Tuman D., Functionality. The Software Process
proyecto software en una microempresa con TSPi,
Dashboard Initiative (consultado: marzo de 2013).
EICIS. Revista Española de Innovación, Calidad e
Disponible en: http://www.processdash.com/
Ingeniería del Software, 2009, 5(2), pp. 28-37.
functionality
6. Humphrey, W. S., TSP: Coaching Development
Teams. Nueva York: Addison-Wesley, 2006.

Acerca de los autores

José Alberto Vela Dávila es Maestro en

Ingeniería de Software por el Centro de
Investigación en Matemáticas (CIMAT),
campus Zacatecas en 2008. Su trabajo de
investigación fue “Ambientes de
Desarrollo de Software basado en
componentes”.
Actualmente es candidato al Doctorado
en Ciencias Computacionales del CIMAT, en la línea
de investigación de Human Computer Interaction
(HCI). Se desempeña como docente del programa
educativo de Ingeniería en Sistemas Computacionales
en el Instituto Tecnológico Superior de Fresnillo y la
Universidad Politécnica de Zacatecas. Sus áreas de
interés son: brain computer interface, ingeniería de
software, redes y cómputo paralelo.