TSPi en Proyectos Open Source

Fernando López Trujillo*, Carlos Eduardo Marulanda Echeverry, Marcelo

López Trujillo ***

*Servicio Nacional de Aprendizaje SENA, flopez918@gmail.com

**Grupos de investigación competitividad y finanzas y marketing, Departamento de
Administración, Universidad Nacional de Colombia sede Manizales,
cemarulandae@unal.edu.co. Grupo de investigación GITIR Universidad de Caldas,
carlose@ucaldas.edu.co.
*** Grupo de investigación GITIR Universidad de Caldas, mlopez@ucaldas.edu.co

RESUMEN

Se presentan las practicas, métodos y roles para el trabajo productivo de los colectivos de
personas involucradas en proyectos Open Source en el marco del proyecto de I+D
“Arquitecturas computacionales para valorar la gestión tecnológica en las PYMES de
Manizales”.

Considerando que las fallas de los proyectos Open Source se deben más a problemas de
trabajo en equipo que a problemas técnicos, se exponen los resultados alcanzados al aplicar
TSPi a colectivos de desarrollo de software libre. Se propone un marco de trabajo
fundamentado en TSPi, como desarrollar productos Open Source en ciclos, unas líneas base
para calidad y desempeño, una guía para valorar roles de equipo, unos elementos para
definir métricas de trabajo en equipo, una guía de solución a problemas de trabajo en
equipo, unas prácticas de comunicación interna y externa y unas prácticas para gestionar
planes y estrategias.

ABSTRACT

Presents the practices, methods and roles for the productive work of froups of people
involven in Open Source Projects in the framework of the R&D “computing architectures
to assess technology management in the enterprises small and medium enterprises of
Manizales”

Whereas the failure of open source projects are due more to problems with teamwork of
technical problems, we present the results achieved by applying a collective TSPI free
software development. It proposes a framework based on TSPI as Open Source product
development cycles, a base line for quality and performance, an instrument to assess team
roles, elements to define metrics of team work, a guide for solving problems teamwork,
communication practices internally and externally and practices to manage plans and
strategies.
 1. Introducción
Los desarrollos de la industria de
software en la actualidad requieren de
trabajadores del conocimiento con altas
competencias personales y profesionales,
además de características que permitan a
un equipo de trabajo actuar como un
experto, con cualidades como:
• Excelente comunicación
• Facilidad de interacción en un
equipo de trabajo
• Conocimientos técnicos de diseño
de software y experiencia en el
uso de metodologías
• Capacidad de innovación y
creación
• Habilidades para el trabajo
colaborativo
La complejidad y amplitud de personas
involucradas en productos de software
Open Source, exige que las aplicaciones
sean desarrolladas por equipos de
trabajo. Situación que hace necesario
redefinir y restablecer una dinámica
propia para cualquier desarrollador de
software Open Source.
El trabajo en equipo requiere de un
sistema que permita cumplir los objetivos
por encima de las consideraciones
personales, definiendo el trabajo que debe
hacerse y el planteamiento de las
estrategias, actividades y tareas para
realizarlo. Para mantener una adecuada
relación de equipo es necesario establecer
metas comunes, participar y alinearse con
un plan de acción y contar con un
adecuado liderazgo. Se requiere
igualmente que cada componente del
equipo reconozca las debilidades y
fortalezas de sus compañeros, además de
apoyarlos y estar presto a solicitar
colaboración cuando se necesite. El
trabajo en equipo es una habilidad que se
adquiere con la práctica y se mejora todos
los días con la apropiación de
conocimiento y experiencia.
El método denominado TSPi (Team
Software Process Introduction) fue
desarrollado por Watt Humphrey en
1999. Su objetivo era crear un proceso
operativo que sirviera a todos aquellos
que intervienen en la fabricación de
software para realizar aplicaciones con un
alto grado de calidad. Considerando la
conformación de equipos de trabajo
comprometidos para el cumplimiento de
los objetos trazados y que sus miembros
tuvieran formación y entrenamiento en el
tema. El propósito del TSPi es conformar
y guiar a los equipos de trabajo, los cuales
son la base de la una gran cantidad de
proyectos de Ingeniería [1].
El entorno en el cual está defino el
método TSPi (figura 1) se fundamenta en
los siguientes aspectos:
Figura 1. Entorno
Fuente: ingsw.ccbas.uaa.mx
PSP (Personal Software Process), modelo
de trabajo que permite a los profesionaes
del software, mejorar la forma en la que
diseñan y desarrollan las aplicaciones de
software, teniendo en cuenta conceptos
como la planeación, la calidad, la
estimación de costos, la productividad y
la competitividad. Sin dejar de lado que le
permite al desarrollador Open Source
identificar sus fortalezas y debilidades y
reconocerse en un continuo proceso de
autoaprendizaje, autodisciplina y Una de las características más
automejoramiento.
CMMI (Capability Maturity Model
Integration), modelo utilizado en la
administración de Software con un
conjunto de proceso y prácticas
compuestos por modelos de referencia,
material de entrenamiento y métodos de
evaluación en la administración y que
incluyen: un procedimiento documentado,
una provisión de medios y formación, una
ejecución sistemática, universal y
uniforme, un proceso de medición y de
verificación
1.1.Principios y Objetivos de TSPi
TSPi procura desarrollar una aplicación
de software considerando varios ciclos de
desarrollo incremental con altos niveles
de calidad, llevando a cabo un proceso
con un equipo eficiente y colaborativo.
Permite lograr paso a paso el
cumplimiento de los objetivos; guía la
aplicación de conocimientos de ingeniería
de software y procesos en un ambiente de
trabajo en equipo; establece con precisión
el rol o papel de los integrantes, sus
deberes y responsabilidades y responde a
preguntas como ¿qué?, ¿cómo? y
¿cuándo?. Ejecutando las fases del
proyecto; así como generando habilidades
y competencias para el trabajo con los
demás.
Para encontrar el nivel óptimo de
aprendizaje de los miembros del equipo,
se debe procurar experiencia en las
diversas fases del desarrollo de un
proyecto de software y en lo posible un
conocimiento anterior del modelo PSP, ya
que este ayuda a realizar un seguimiento,
evaluación y verificación más simples y
rápidos, en el marco del desarrollo del
proyecto.
importantes de resaltar de TSPi, es que
mantiene un balance ideal entre el
producto, el proceso que se elabora y el
equipo de trabajo, ya que define con
detalle cada una de las fases y tareas a
realizar, con formatos, guiones y
esquemas que permiten registrar y hacer
seguimiento al proceso. Igualmente
desarrolla la guía de procedimientos
desde el inicio, los pasos, el análisis y
reportes de los registros en cada etapa del
proyecto
TSPi está basado en cuatro principios
básicos :
1. Aprender eficientemente con un
proceso definido y con una rápida
retroalimentación.
2. La productividad del equipo es el
resultado de: metas específicas, un
equipo de trabajo que se apoya y
la capacidad de entrenamiento y
liderazgo.
3. La práctica de desarrollo se basa
en la resolución efectiva de
problemas y una guía que aporta
respuestas efectivas.
4. La formación y desarrollo de
nuevo conocimiento es más
efectiva cuando se construye
sobre experiencia y conocimiento
anterior.
TSPi contempla siete decisiones de
diseño principales, que en conjunto
constituyen su estrategia, éstas son:
1. Contar con una guía basada en el
enfoque PSP, considerando el
aprendizaje y entrenamiento
previos, además de la
 autodisciplina de los miembros
del equipo.
2. Aplicar el método en cada uno de
sus ciclos, los cuales incluyen:
requerimientos completos,
planeación, diseño,
implementación y pruebas. En el
primer ciclo se pretende un
producto base para los siguientes
ciclos. En todos los ciclos pueden
hacerse modificaciones de roles,
procesos o decisiones sobre todo Figura 2. Estructura
en lo referente al incremento de la
calidad. Una vez se ha avanzado TSP plantea múltiples ciclos de desarrollo
en los ciclos se hace revisión del que pueden planearse para obtener un
funcionamiento del equipo. producto final. Cada ciclo contiene las
3. Definir lineamientos que permitan mismas fases y siempre tiene como base
medir el proceso y los ciclos en el ciclo de desarrollo que lo antecede, con
cuanto a su avance, rendimiento y excepción del primer ciclo, (figura 3).
calidad, para mejorar y rectificar
en caso de ser necesario, de
acuerdo a la planeación previa y a
los registros del proyecto.
4. Establecer medidas de evaluación
del progreso del equipo y de cada
uno de sus miembros, permitiendo
que todos conozcan el desempeño
para procurar el mejoramiento
general del mismo.
5. Definir evaluaciones del rol del
equipo y de los miembros con
honestidad para tomar las
decisiones más acertadas. Figura 3. Ciclos de desarrollo
6. Disciplina de alto nivel en el Fuente: Humphrey, 2000
desarrollo de las tareas dentro del
proceso. El ideal es iniciar siempre con una
7. Desarrollar una guía de las versión prototipo o pequeña de la
desavenencias y problemas aplicación e ir incrementando el tamaño y
generados en el equipo, para dar el contenido en cada ciclo, considerando lo
apoyo necesario a cada unos de siguiente:
los miembros de trabajo.
1. Se debe producir una versión que
1.2.Estructura y formato de TSP pueda ser probada y que
(Figura 2) represente el producto final.
2. Cada ciclo debe ser lo
suficientemente pequeño como
 para desarrollar una versión del
producto en el tiempo disponible.
3. Los productos de cada ciclo, al
combinarse, deben conformar el
producto de software final
deseado.
1.3.Fases del Ciclo TSP
Las fases en las que se divide el proceso
de TSP son las siguientes:
Lanzamiento
Que consta de: revisión de los objetivos
del proyecto, descripción de la estructura
general de TSP y del contenido,
formación de equipos de ingenieros y
asignación de roles, descripción de las
necesidades del cliente
Estrategia
Que consta de: creación de un diseño
conceptual del producto, establecimiento
de la estrategia de desarrollo,
estimaciones iniciales del tamaño y el
esfuerzo requerido y la identificación de
los riesgos.
Planeación
Que consta de: estimación del tamaño de
cada parte a ser creada, identificación de
las tareas a ser realizadas y asignación de
estas a los miembros del equipo, y la
definición de plan de calidad que fije
parámetros a ser alcanzados.
Requerimientos
Que consta de: análisis de las necesidades
del sistema, entrevistas con el cliente y
especificación de los requerimientos,
finalmente se formula un plan para
realizar las pruebas del sistema.
Diseño
Que consta de: diseño del proceso
creativo para construir el producto,
producción de una especificación
completa y precisa del producto,
desarrollo del diseño completo y
formulación del plan de prueba para la
integración.
Implementación
Que consta de: traducción a código,
revisión, compilación y prueba.
Pruebas
Que consta de: verificación del sistema y
documentación de usuario
1.4.Equipo TSP
TSP asigna las responsabilidades
mediante los roles, los cuales son:
• Líder del Equipo. Dirige,
asegurando el reporte de los datos
de los procesos.
• Líder de desarrollo. Guía al
equipo en el diseño y desarrollo.
• Líder de Planeación. Guía en la
planeación y seguimiento del
trabajo.
• Líder de Calidad/Proceso. Define
las necesidades del proceso y
administrar el plan de calidad.
• Líder de Requerimientos/Soporte.
Dirige el desarrollo de
requerimientos de software y
administra el plan de la
configuración.
2. TSP en Proyectos de Open
Source
 2.1.Líneas de base para calidad y
desempeño
Las comunidades Open Source pueden
aplicar el modelo TSPi para reducir el
promedio de tiempo empleado en un
proyecto de desarrollo de software; al
igual que garantizar la calidad de las
pruebas. Un problema permanente en el
desarrollo de software Open Source
siempre ha sido el gran porcentaje de
tiempo que las comunidades utilizan para
el mantenimiento de un producto que ya
ha sido liberado por no realizar un
seguimiento riguroso en todo el ciclo de
vida que se empleó para su realización.
Para hacer referencia a la línea base de
calidad y desempeño en la realización de
un proyecto de software, a continuación
se mencionan los beneficios de utilizar el
modelo TSP tomado del SEI1
“The most significant benefit is
improved productivity and/or
schedule reduction resulting from
early defect removal and
improved planning and tracking.
Early defect removal (a) reduces
average time to remove a defect
from hours to minutes, (b) reduces
testing costs/schedules by 20% to
48%, (c) increases the non-test
costs/schedules by 5% to 10%,
and (d) yields net average savings
of about 25%. Improved planning
and tracking increases task hours
per week by up to 50%. Task hour
increases translate directly to
productivity increases.”
Otro concepto importante para las
comunidades es el de calidad, uno de los
1
Instituto de Ingeniería de software fundado por el
Congreso de los Estados Unidos para desarrollar
modelos de evaluación y mejora en el desarrollo de
software. http://www.sei.cmu.edu/tsp/start/case/
factores claves del éxito es el hecho de
aceptar los errores en una etapa temprana
del proyecto, lo cual puede llevar a
identificar la calidad y mejorar de esta
manera el desempeño en el proceso. El
verdadero enfoque TSPi se aplica a nivel
de desempeño, sin embargo la decisión de
utilizar TSPi indica un mecanismo que se
ocupa de aumentar en una organización el
rendimiento y la calidad en los procesos.
Es importante destacar los principios de
gestión de calidad en un proceso de
desarrollo de software, estos son:
• En cualquier programa de calidad
el principal objetivo es satisfacer
al cliente
• Se debe conservar un programa
efectivo de calidad en todo el
proceso de desarrollo de software.
• Es importante percibir que la
calidad es primordial y todo el
equipo debe participar en
revisiones y mejoramiento
continuo.
• Para incrementar la calidad se
deben hacer cambios en los
procesos. La calidad de un
producto es determinada por la
calidad de los procesos utilizados.
• Sin medición la calidad es solo
una palabra llamativa.
• Es muy importante encontrar el
problema más temprano que tarde.
En conclusión en los equipos de
desarrollo que incorporan el TSPi hay
muchas posibilidades de medir la calidad,
una de las más tenidas en cuenta es la
programación o el porcentaje de tiempo
de desarrollo utilizado en las pruebas y
defectos encontrados por los sistemas de
prueba, las pruebas de aceptación y el
manejo adecuado de los errores o
defectos.

2.2.Guía para valorar roles de
equipo y métricas de trabajo en
equipo
Las personas que conforman los equipos
de trabajo TSPi deben cumplir con unos
objetivos que son medibles, esto con el
fin de obtener resultados significativos. El
hecho de tener objetivos medibles es con
frecuencia difícil de establecer y pueden
dar como resultado final la inversión de
mucho tiempo de trabajo; para mejorar
esto se recomienda a los equipos de TSPi,
establecer medidas para solo algunos
objetivos y que estos sean razonables y
coherentes (tratar de medir todo no es
aconsejable). De hecho, se sugiere que se
empiece con 3 o 4 objetivos básicos tales
como el costo y la programación, la
capacidad del producto, la calidad y el
desempeño del equipo. Una vez que se
tenga esta experiencia, se deben definir
más objetivos que contengan información
básica, esto último se recomiendo hacerlo
en el próximo ciclo del proyecto Open
Source.
La medición de objetivos algunas veces
es simple pero no todas las veces. Un
objetivo para ser medible, debe ser
específico y preciso. Algo que los equipos
deben conocer es lo que desean alcanzar,
pero muchas veces no se dan cuenta si lo
logran o no; en el trabajo de desarrollo de
software es de las cosas más difíciles de
conocer. Los objetivos de calidad son
muy importantes, pero muy pocas veces
claros y medibles, en TSPi la calidad es
una parte fundamental para el
establecimiento de los procesos.
Otro factor definitivo para el éxito de un
proyecto, es la selección de los miembros
del equipo en el momento de definir los
roles en el proyecto, para esto se pueden
emplear algunos instrumentos que nos
permiten perfilar a los integrantes del
equipo. Uno de estos instrumentos puede
ser una encuesta que sirve para indagar
sobre la experiencia, algunas preguntas
claves para realizar este tipo de sondeo
son:
• Describa su experiencia relevante
en proyectos de desarrollo
software.
• Qué intereses tiene a la hora de
participar en un proyecto de
desarrollo
• Describa los proyectos de
desarrollo en los que ha
participado.
• Describa posiciones de liderazgo
que le ha tocado asumir en
proyecto de software.
• Califique de 1 a 5 su preferencia
en los roles.
Cuando un equipo empieza a trabajar
integrando a cada uno sus miembros de
manera eficaz, es recomendable emplear
un lenguaje en común: la misión, la
visión, los procesos, los métodos y la
terminología.
Adicionalmente los equipos de trabajo
deben tener:
• Objetivos comunes.
• Reglas acordadas
• Habilidades de los miembros
claras.
• Ambiente propicio de trabajo.
• Capacidad de trabajo con equipos
interdisciplinarios.
Otros factores importantes es la
capacitación de un equipo TSPi, el
requisito clave es que todos los miembros
del equipo sean capaces de hacer
acuerdos en los procesos y comprender
los principios detrás de los métodos de
TSPi. Es recomendable que todos sean
capaces de planificar y realizar un
seguimiento de su trabajo para poder
medir y gestionar la calidad de los
productos que se producen.
De igual manera la alta dirección, el líder
del equipo, cualquier miembro del equipo
y cualquier otra persona que participe en
el proyecto deben estar capacitados en los
métodos que se van a utilizar para trabajar
los procesos y las prácticas de manera
efectiva. A continuación se plantean los
temas principales que los miembros del
equipo deben conocer:
• Planeación
• Reporte del proyecto
• Medidas
• Calidad
• Diseño
• Proceso
• PSP, TSP y soporte
Para finalizar, una vez se conformen e
identifiquen los equipos de trabajo a parte
del proceso inicial de capacitación se
debe preparar la etapa de lanzamiento de
TSPi. En la preparación de esta etapa es
importante tener en cuenta los siguientes
pasos:
a. Establecer las funciones de lo
que se va a desarrollar y los
objetivos del equipo de trabajo
b. Establecer los roles y los
objetivos de los integrantes del
equipo
c. Definir la estrategia de
desarrollo
d. Hacer un plan general
e. Hacer un plan de calidad
f. Balancear el plan teniendo en
cuenta las cargas de trabajo
g. Elaborar el proyecto de
riesgos
h. Diseñar el reporte para el
instructor
i. Revisar el plan con el
instructor
j. Análisis de Postmortem,
nuevo equipo revisa proceso
2.3.Guía de solución de trabajo en
equipo
Para hablar de las buenas prácticas que se
deben de tener en cuenta para la
conformación de los equipos efectivos de
trabajo es adecuado empezar por conocer
los posibles fallos que se han presentado
en las prácticas de TSPi (Humphrey,
2000). Algunas de ellas se mencionan a
continuación:
• Conflictos del equipo de trabajo:
La falta de un liderazgo claro y
coherente en los equipos de
trabajo terminará agotando la
energía y desperdiciando el
tiempo de trabajo del equipo.
• Ambiente caótico de trabajo: No
contar con un soporte adecuado
tanto en las herramientas de
trabajo como habilidades
inadecuadas de los miembros del
equipo para la realización de sus
tareas.
• Metas imposibles: Cuando se
tienen objetivos muy ambiciosos
que no se pueden alcanzarse, se
tendrán horarios irreales y esto se
convierte en un esfuerzo
inadecuado para conseguir el
éxito. Este tipo de
comportamiento siempre destruye
un proyecto y a menudo conduce
al fracaso total.
• La moral de los problemas.
Cuando los miembros del equipo
están preocupados por las
evaluaciones, promociones,
 salario, o seguridad en el empleo,
no pueden concentrarse en su
trabajo.
El éxito de los equipos tiene mucho
sentido cuando todos sus integrantes
tienen un norte, una visión clara y
convincente; es importante que el equipo
crea que esta visión se puede alcanzar, y
que todos los miembros se comprometan
a trabajar coordinadamente para lograrlo.
Además, los equipos de éxito necesitan
una formación adecuada recursos y la
debida orientación y apoyo. Si cualquiera
de estas condiciones falta, el equipo
puede fallar, y puede incluso luchar
valerosamente contra la corriente, pero no
es probable que tenga éxito. Para
establecer todas estas condiciones, se
necesita un proceso de trabajo en equipo,
se necesita de un líder que sea capaz de
actuar como un orientador y motivador.
El líder debe velar por un buen ambiente
de trabajo aportando aspectos
significativos para lograrlo.
A continuación se mencionan algunos de
los principios para resolver problemas
acorde a la guía de TSP y TSPi, de
acuerdo a un reporte técnico publicado
por el SEI 2 en marzo del 2010,
a. El equipo de trabajo debe cumplir
un compromiso, para esto es
importante tener un plan antes de
empezar a trabajar. Las
comunidades Open Source
depende de las personas y los
equipos de trabajo deben de ser
capaces de hacer, lo que dicen que
van a hacer o sino no
sobrevivirán.
b. Cuando las personas se involucran
realizando un plan desde el
2
Extending Team Software Process (TSP) to Systems
Engineering: A NAVAIR Experience Report. Page 21.
principio, ellas mismas se
comprometen con el plan.
c. En la realización del plan de
trabajo se debe tener claridad en
las horas por semana que se van a
trabajar. Es importante
preguntarse: qué tan grande es el
producto?, cuánto tiempo se
tardará en construir ?
d. El plan debería de basarse en un
proceso y las personas que hacen
el trabajo deberían apropiarse del
mismo.
e. Seguir un proceso y recoger la
información del mismo. Si un
proceso se rompe, se debe
modificar el plan para reflejar el
cambio establecido, esto es
posible si se tiene una
planificación detallada y un
seguimiento adecuado.
f. Los planes deberían ser más
detallados para las actividades de
la semana. Los planes más
detallados motivan a los
integrantes del equipo a trabajar
en las tareas porque siente que los
plazos son más cortos y las tareas
son más precisas.
3. Practicas de comunicación
interna y externa
La comunicación interna y externa se
concibe como mediación entre los
procesos que se realizan en una
organización o en grupo social, el cual
debe establecer con claridad los
indicadores, metas y medios de
evaluación al igual que otras áreas de
resultados. Es por ello que su desarrollo
debe partir de la estrategia general del
desarrollo del modelo TSPi, para apoyar
funcionalmente la gestión del equipo de
trabajo, para acoplarse a la realidad de la
aplicación de software y la percepción de
los diferentes usuarios.
Desarrollar una estrategia de
comunicación, permite alinear a toda el
equipo de trabajo en una misma
dirección, sintonizando a todos sus
miembros en el cumplimiento de unos
objetivos comunes y permitiendo
escuchar las opiniones de los clientes,
como parte de la gestión.
Esta estrategia de comunicación puede
conducir también al establecimiento de
redes internas de comunicación, las cuales
a su vez coadyuvan a la optimización de
los recursos de comunicación propios, al
correcto análisis de requerimientos con
los usuarios, los objetivos del proyecto la
resolución de necesidades de
información, el cumplimiento de los
plazos, así como el presupuesto que se
requiere para su ejecución.
Periódicamente el equipo debe evaluar
esta estrategia y determinar el
cumplimiento de los indicadores y metas
establecidas en el proyecto como una
forma de evaluar su efectividad y la
mejora. Como resultado de esta
evaluación se deberán tomar acciones
para mejorar los procesos de
comunicación del equipo.
La calidad del proceso de comunicación
interna y externa de un equipo de trabajo
permite modificar los procesos de
desarrollo de forma positiva, integrar a
los ingenieros a las normas, objetivos y
metas, estimular al aumento de la
productividad del trabajo, crear ventajas,
fortalecer su posicionamiento, elevar la
competencia del personal y aumentar la
satisfacción de los clientes. En otro caso,
faltando a la efectividad, se obtienen
pérdidas económicas, productos
inutilizados, esfuerzos desperdiciados,
conflictos laborales y clientes
insatisfechos.
Además se puede lograr adquirir
conciencia en las personas, mejorar las
características comunicativas de la
capacitación, estructuras funcionales del
trabajo en equipo, estrategias
comunicativas para hacerle saber a la
gente cuáles son las metas e interacción
integral con los colaboradores,
Los equipos de trabajo, como generadoras
de conocimiento, deben establecer
mecanismos formales e informales que
faciliten el intercambio y la circulación de
saberes a lo largo de todos sus procesos.
Las innovaciones no son un fenómeno de
carácter individual si no un proceso
colectivo, que resulta de la capacidad para
interactuar y cooperar, de la presencia de
una estructura institucional adecuada,
capaz de promover las capacidades
innovativas [2].
Considerando que los cambios
producidos por el uso de modelos como
TSPi y su efecto en la comunicación [3],
[4], y la relevancia que adquieren los
procesos de aprendizaje de los miembros
del equipo en el desarrollo de ventajas
competitivas dinámicas, [5], [6], [7], [8],
las ventajas comparadas, el uso de
herramientas tecnológicas, la generación
de conocimiento y la consolidación de
redes juegan un papel fundamental [9].
Disponer de tecnologías de
comunicación, por ejemplo, no garantiza
la existencia de bidireccionalidad en los
procesos de interacción, ni la autonomía e
implicación de los actores que requiere la
generación de conocimiento; base del
incremento de la competitividad [10].
Y con el uso del modelo TSPi es muy
común que se generen problemas en los
equipos de trabajo, dado que los seres
humanos poseen una gran complejidad,
como cuando no se reconoce el estatus o
nivel de otros miembros del equipo, o
cuando no hay coordinación adecuada o
cuando todos están tan ocupados que no
atienden las necesidades de los demás y
en gran medida esta situaciones se pueden
corregir realizando reuniones periódicas
para la presentación de informes,
opiniones, ideas, para la redefinición de
roles, procesos, planes, medidas y demás.
4. Prácticas para gestionar planes
y estrategias
Todo equipo de trabajo está formado por
un conjunto de personas y recursos
(físicos, intelectuales, financieros,
tecnológicos entre otros) que necesitan
ser alineados, esto, con el fin de alcanzar
el objetivo común del proceso, desarrollar
el proyecto de software, con base en el
cumplimiento de un ciclo de vida óptimo
que le permita alcanzar las metas y los
objetivos.
La planeación actúa como puente entre lo
que se quiere y lo que se tiene [11],
establecen que la mayoría de los líderes,
gestores o directores, reconocen el
proceso de planificación como ayuda al
aumento de la racionalidad en las
actividades. Por su parte [12], considera
que se debe planear para alcanzar los
objetivos, al igual que plantea que la
planeación ayuda a la adaptación a los
cambios, identificar oportunidades y
predecir imprevistos.
[13], establece que la planeación “es la
determinación de los objetivos, elección
de los cursos de acción para lograrlos,
con base en la investigación y elaboración
de un esquema detallado que habrá de
realizase en un futuro”. De manera
similar [12], enuncia que en la planeación
se determina por anticipado cuáles son los
objetivos que deben cumplirse; así como,
los planes y estrategias se deben
establecer para alcanzarlos. Por otro lado
para [13], la planeación “consiste en fijar
el curso concreto de acción que ha de
seguirse, estableciendo los principios que
habrán de orientarlo, la secuencia de
operaciones para realizarlo, y la
determinación de tiempo y numero
necesarios para su realización”.
La acción de planificar significa
establecer anticipadamente objetivos. La
planeación sostiene los actos o
actividades en un proyecto, basada en
métodos, procedimientos y planes, de
igual forma, establece las tareas que
deben ejecutarse para alcanzar los
objetivos de un proyecto, bosquejar cómo
éstas se deben ejecutar, e indicar cuándo
deben ser ejecutadas. Por medio de la
planeación el equipo de trabajo garantiza
su supervivencia en el futuro [14].
Es posible inferir la importancia del
proceso de planeación como pilar
fundamental del desarrollo de un proyecto
y su pertinencia tal como sigue:
• La eficiencia es un resultado del
orden.
• Lo central es dirigir: se necesita
primero hacer planes sobre la
forma en que los ciclos se
coordinaran.
• El objetivo se cumple si el plan se
detallaran para que pueda ser
realizado integra y eficazmente.
• Todo control es imposible si no se
compara con un plan previo.
TSPi requiere que se diseñe un plan antes
de iniciar la fase de requerimientos por
las siguientes razones:
• En el proceso de diseño del plan
los equipos de trabajo tienen una
 visión general del trabajo a
realizar
• El plan provee las bases para el
seguimiento y evaluación del
trabajo
• Es definitivo para comprometer el
equipo de trabajo en la realización
del proyecto
Uno de los mayores problemas en el
desarrollo del software es la construcción
de grandes sistemas, que se ha resuelto
con el desarrollo de módulos y
componentes, los cuales son pequeñas
partes del proceso, pero que requieren en
algún momento el ensamble o la
integración con los demás y en este paso
se pueden presentar más dificultades,
para los cual TSPi plantea como
estrategia el desarrollo de un sistema
cíclico incremental de versiones.
Y aparece también la necesidad de
gestionar los riegos toda vez que en
cualquier proyecto se presenta y se deben
establecer estrategias como:
• Definir criterios iniciales
• Determinar las posibles
alternativas
• Identificar los riesgos y beneficios
• Realizar un comparativo de
alternativas
• Documentar
5. Caso práctico. Aplicación TSPi
a un proyecto Open Source,
una solución académica para la
hoja de vida de los aprendices
del SENA - Regional Caldas.
En el Centro de Comercio y servicio del
SENA regional Caldas, se llevó a cabo la
aplicación del modelo TSPi en el grupo
de Tecnología en Análisis y desarrollo de
sistemas de información.
Antes de realizar la fase de lanzamiento
se llevó a cabo una capacitación de PSP
nivel 0.1 para que los aprendices
comprendieran los conceptos básicos de
este modelo. En este tipo de experiencias,
lo más complicado era crear la cultura de
la medición en la implementación del
código que se genera, esto quizás por no
contar con una buena experiencia en
programación.
Luego se determinaron los roles donde no
se tuvo en cuenta el sistema de la
encuesta 3 debido a que los aprendices
tenían una mínima experiencia en
proyectos de desarrollo de software.
Entonces se procedió a socializar con el
grupo los roles que tiene TSPi4, con eso
se pretendía aterrizar la idea y acercar a
los jóvenes a los perfiles expuestos, como
el grupo era de 20 aprendices se
conformaron cuatro grupos de cinco
personas, los roles determinados para
cada integrante se asignaron de acuerdo a
sus competencias. Era muy importante
para el instructor que cada integrante del
equipo interiorizara sus funciones dentro
del grupo, todo esto con el fin de fijar un
compromiso de cada uno, en esto se
trabajó una semana.
Luego se procedió a continuar con el
documento de lanzamiento donde se
tuvieron en cuenta los aspectos
mencionados anteriormente (fase de
lanzamiento en el tema “Guía para valorar
roles de equipo y métricas de trabajo en
equipo”).
3
Vista en la sesión “Instrumento para valorar roles de
equipo y métricas de trabajo en equipo”
4
Los Roles de TSPi son: líder del proyecto, líder de
planeación, líder de desarrollo, líder de calidad y líder
de soporte
 En la fase de Estrategia se dieron las
Para llevar a cabo estos pasos se les pautas necesarias para abordar esta etapa,
facilitó a los aprendices un formato que también se trabajó sobre un documento
les servía como guía para diligenciar este guía para que los aprendices tuvieran en
documento, el cual se reviso con cada cuenta algunos aspectos importantes que
grupo, determinando los objetivos se prepararon en la fase anterior, a
planteados y las mediciones propuestas continuación se mencionan algunos
por cada objetivo 5. puntos importantes: funciones
identificadas, responsables en el ciclo de
Cabe anotar que se fijaron reuniones vida de acuerdo a las competencias de
semanales entre los equipos y reuniones equipo de trabajo, estrategia de calidad,
semanales de cada líder con el instructor. estimación del tamaño del producto y los
Para una mejor comunicación se planes de mitigación de los riesgos entre
propusieron las siguientes herramientas otros.
libres (tabla 1).
De lo anterior destacamos la estrategia de
Tabla 1. Herramientas aseguramiento de la calidad donde se hizo
Herramienta Descripción
un proceso de capacitación más amplio,
Wikispaces Para publicar el informe en este proceso se tuvieron en cuenta:
individual y de grupo.
También para publicar la • Normas y procedimientos para el
información general y una uso del sistema de control de
pizarra de avisos.
Dot Project Para realizar el plan de
versiones.
actividades detallado, • Normas para el nombramiento de
seguimiento y publicar clases, variables y documentos.
documentos entregables • Procedimiento para el control de
Google Docs o Para trabajo colaborativo. versiones de documentos.
Microsoft Azure Aquí se deben de publicar
todos los documentos que • Estándares de documentación
se piden en las diferentes • Estándares de desarrollo
etapas del TSP • Estándares de nombramiento y
TORTOISE_SVN Sistema de control de almacenamiento de archivos
(Subversion) versiones utilizado por los
que desarrollan en PHP • Formato del código fuente.

También se dio la posibilidad para que en En la Fase de Planeación, los líderes de

los grupos se incorporaran herramientas planeación aprendieron a realizar planes
de la web social. Esto permitió mucha detallados con el apoyo por supuesto de
diversidad de estrategias de los demás integrantes del equipo. Como
comunicación. Al final un grupo se había mencionado anteriormente, la
descubrió como trabajar los proyectos con herramienta propuesta era del Dot Project,
las herramientas de www.zoho.com. pero estaba abierta la posibilidad de
utilizar otra herramienta, de este manera
algunos adoptaron el Microsoft Project y
otros descubrieron el Zoho Project. En el
5
En esta parte se hizo mucho énfasis en el plan de proceso de planeación inicialmente se
calidad, así como tener un plan de riesgos detallado. tuvieron que modificar muchas de las
actividades y hacer ajustes por la poca
experiencia de los aprendices en éste tipo
de proyectos.
En la fase de requerimientos y diseño se
empleo una considerable parte del tiempo
con el propósito de realizar un repaso
para reforzar los conocimientos en el
tema.
La fase de Implementación se basó en la
estrategia que se había plateado acerca de
la reutilización, para ésto se realizo una
investigación de marcos de trabajo en
PHP. Se escogió en marco de trabajo
denominado CODEIGNITER debido el
poco tiempo que se tenía y la poca
experiencia en programación del lenguaje
PHP; éste marco de trabajo no era tan
complejo y permitía una mejor
comprensión por parte de los aprendices,
de esta forma todos terminaron
comprendiendo esta herramienta.
En la fase de Pruebas es importante
destacar el hecho que desde la fase de
requerimientos se hizo seguimiento y se
emplearon listas de chequeo con el fin de
realizar un aseguramiento de la calidad
permanente.
Por último en la fase de Postmortem se
realizo una síntesis rigurosa y exhaustiva
teniendo en cuenta: análisis de resultados,
reporte del ciclo y evaluación del equipo
y de pares.
Es importante mencionar que en este caso
práctico sólo se alcanzó a realizar un
ciclo.
6. Conclusiones
• El desarrollo de un modelo como
TSP le aporta a administradores
de sistemas, como a ingenieros, la
importancia de la planeación
evaluación y seguimiento de los
proyectos que desarrollan.
• El uso de TSP genera una
administración de calidad
efectiva, integral y holística en el
marco de la optimización de los
recursos y el cumplimiento de los
objetivos y metas.
• Es fundamental para el desarrollo
del modelo, involucrar a los
ingenieros en la medición,
administracióny mejora de los
procesos, como una fortma de
retroalimentación de su quehacer
en el área de TI.
• El uso de TSP coadyuva a acelerar
la transición a organizaciones
maduras y a equipos de desarrollo
de software de alto rendimiento.
7. Referencias
[1].Humphrey, W. (2000). The Personal
Software Process (PSP) (CMU/SEI-2000-
TR-022). Pittsburgh: Carnegie mellin
University.
[2].Boscherini, F., & Yoguel, G. (2000).
Aprendizaje y competencias como
factores competitivos en el nuevo
escenario. Madrid: Dávila.
[3].Castells, M. (1998). La era de la
información: Economía, Sociedad y
Cultura Sociedad Red Vol. 1. Madrid:
Alianza.
[4].Denning, P., & Metcalfe, R. (1997).
Beyond calculation, the next fifty years of
computing. Nueva York: Springer-Verlag.
[5].Storper, M. (1997). Regional
Economies as relational assets, en:
Society, place, economy. Estates of the art
in economic geography;); . Londres: Lee
R., Willis, J.
[6].Boscherini., F. (2000). Territorio,
conocimiento y competitividad de las
empresas. Madrid: Dávila Editores.

[7]. Bell, M., & Pavitt, K. (1995). The

development of technological
capabilities; en: Trade, technology and
international competitiviness; Economic
Development Institute. World Bank: Irfan
ul Haque (ed.);.

[8].Ernst, D., & Lundvall, B. (1997).

Informatión technology in the learning
economy. Documento de trabajo, Nº 12,.
Dinamarca: DRUID, Aolborg.

[9].Borello, J., Milesi, D., Novick, M.,

Sonia, R., & Yoguel, G. (2003). Las
nuevas tecnologías de información y
comunicación en la industria argentina.
Buenos Aires: Miño y Dávila editores.

[10].Pujol, A., & Navarra, J. (2001).

Tecnologías de Gestión y Aprendizaje
Organizacional. La habana: Cuba.

[11].Noe, A. y. (1996). Management of

Organizations. Estados Unidos: Irwin.

[12].Chiavenato, I. (2000). Introducción a

la Teoría General de la Administración.
5ta. Bogotá: McGraw Hill.

[13].Münch, L. y. (2008). Fundamentos

de Administración. . España: Editorial
Trillas, S. A.

[14].Azuaje, E. (2005). Pensamiento

Gerencial su desarrollo. Universo
Gerencial. Venezuela.