Unidad 1. Introduccion A TSP

Desarrollo de software en equipo (TSP )
Unidad 1. Introduccin a TSP
Ingeniera en Desarrollo de Software

6 Semestre
Programa de la asignatura:
Desarrollo de software en equipo (TSP)
Clave:
15143636
Universidad Abierta y a Distancia de Mxico
Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

ndice
1. Introduccin a TSP ......................................................................................................... 2
Presentacin de la unidad .................................................................................................. 2
Propsitos .......................................................................................................................... 3
Competencia especfica ..................................................................................................... 3
1. 1. Proceso de Desarrollo de Team Software Process (TSP) .......................................... 3
1.1.1. Principios y objetivos de TSP ................................................................................... 6
1.1.2. Estrategia de TSP .................................................................................................... 7
1.1.3. Equipo TSP .............................................................................................................. 8
1.2. Estructura del Team Software Process (TSP) ............................................................. 9
1.2.1. Disciplina de equipo ............................................................................................... 11
1.2.2. Disciplina de administracin ................................................................................... 12
1.2.3. Disciplina de ingeniera........................................................................................... 12
1.3. Ciclo de vida del Team Software Process (TSP) ....................................................... 13
1.3.1. Fase de lanzamiento .............................................................................................. 14
1.3.2. Fase de estrategia .................................................................................................. 22
1.3.3. Fase de planeacin ................................................................................................ 25
1.3.4. Fase de requerimientos .......................................................................................... 26
1.3.5. Fase de diseo ....................................................................................................... 27
1.3.6. Fase de implementacin......................................................................................... 28
1.3.7. Fase de pruebas..................................................................................................... 29
1.3.8. Fase post mrtem................................................................................................... 31
Cierre de la unidad ........................................................................................................... 33
Para saber ms ................................................................................................................ 34
Fuentes de consulta ......................................................................................................... 34

1. Introduccin a TSP
Presentacin de la unidad
Bienvenido a la asignatura Desarrollo de software en equipo TSP (Team Software Process),
la cual forma parte del octavo semestre de la igeniera en Desarrollo de Software.
La metodologa PSP (Personal Software Process) est orientada a un contexto individual del
ingeniero en desarrollo de software, mientras que el TSP se enfoca en los equipos y roles de
trabajo. Es necesario contar con la metodologa PSP, porque gua a cada individuo a
alcanzar sus objetivos personales como parte de un proyecto de desarrollo de software, pero
sin olvidar que lo ms importante es la colaboracin, la retroalimentacin entre los miembros
del equipo de desarrollo y, por supuesto, conseguir los objetivos trazados al inicio del
proyecto.
En la Unidad 1. Introduccin a TSP, aprenders los elementos, objetivos y principios en los
cuales se basa esta metodologa, as como su estrategia y estructura, que se aplica a todo el
ciclo de desarrollo del proyecto.
Relacin entre PSP y TSP

Contenido de la imagen basado en Tuya, Javier y otros, (2007). Imagen basada en Dreamstime (2013).

Propsitos
Al trmino de esta unidad logrars:
Identificar los elementos y objetivos que componen la metodologa TSP.

Comprender la relacin que existe con PSP.
Conocer la estructura TSP.
Comprender la estrategia que sigue TSP para el desarrollo de sistemas de calidad.
Competencia especfica
Identificar la metodologa Team Software Process (TSP) para comprender los

conceptos principales y el ciclo de vida a partir del marco contextual del desarrollo de
software.
1. 1. Proceso de Desarrollo de Team Software Process (TSP)

El Team Software Process (TSP) fue creado por Watts Humphrey en 1996. Es un proceso y
una metodologa de desarrollo de software en equipo, que guan a los ingenieros para
asegurar la calidad en las diferentes etapas del ciclo de vida de desarrollo de software y,
principalmente, la productividad de los equipos de trabajo integrados por ingenieros,
administradores y desarrolladores de software (Gomez y Ania, 2008). Cuando se habla de
objetivos de un proyecto de desarrollo de software, hay uno en particular que se debe
cumplir: el tiempo del proyecto puede rebasar lo planeado. Para esto, implementar la
metodologa TSP dentro de una organizacin ayuda a tener una mtrica exacta de costos.
Tambin la experiencia de proyectos pasados cuenta mucho.
Para comprender la metodologa TSP es necesario saber qu es un proceso de desarrollo
de software (la primera se realiza dentro del segundo). Tambin denominado ciclo de vida
de desarrollo de software, consiste en una estructura que indica las etapas que debe
cumplir todo desarrollo de software. Existen muchos modelos de ciclo de vida; TSP puede
utilizar cualquiera, pero el de cascada es el ms utilizado. El 90% de los que existen en la
actualidad estn basados en l.
El modelo en cascada indica que todo desarrollo basado en l debe cumplir con las
siguientes fases:
Anlisis y definicin de requerimientos: es muy importante conocer qu desea el

cliente, para esto se hace el levantamiento de requerimientos, que consiste en visitas

al cliente para saber cmo quiere que funcione el sistema solicitado. Despus de
esto, los analistas e ingenieros de software crean las especificaciones del sistema.
En esta fase se integra la documentacin requerida para el arranque del proyecto, la
cual cambiar de acuerdo con la metodologa propuesta; pero nunca deben de faltar
los documentos donde se muestren los objetivos, visin, roles, puestos y
requerimientos del sistema a desarrollarse.
Diseo del sistema y el software: los analistas e ingenieros de software establecen

una arquitectura completa del sistema, el diseo nos muestra cmo va a funcionar y
si se va a comunicar con otro sistemas.
Implementacin y prueba de unidades: prcticamente, en esta fase se desarrolla

por completo el sistema.
Integracin y pruebas del sistema: aqu se observa ya un producto terminado. Las

personas designadas en el rea de pruebas y calidad de software revisan que el
sistema no tenga fallos; si los hay, se devuelve el producto a los desarrolladores para
que hagan las modificaciones correspondientes.
Funcionamiento y mantenimiento: una vez que el sistema fue aprobado por las
personas designadas en el rea de calidad y pruebas, se le entrega al cliente la
primera versin terminada del sistema, para que la pruebe en el rea de produccin y
verifique el correcto funcionamiento. Si hay nuevos requerimientos se regresa a la
primer fase para realizar las mejoras para el sistema (Sommerville, 2006).
En la siguiente figura se muestra una representacin del modelo en cascada:

Definicin de
requerimientos
Diseo del
sistema y del
software
Implementacin y
prueba de
unidades
Integracin y
prueba del
sistema
Funcionamiento y
mantenimiento
Figura 1. Modelo en cascada (Sommerville, 2006).
Se dice que el TSP es un proceso de desarrollo porque cumple con esta estructura, pero con
fases propias que ms adelante se explicarn.
Se recomienda el uso de TSP en grupos de 2 a 20 personas y en desarrollos de sistemas
que sean a gran escala.
El TSP se centra en la administracin de proyectos, en la construccin de los equipos de
trabajo de acuerdo a los roles y en el perfil de cada persona que se necesita para los
distintos puestos dentro del proyecto.
En un proyecto de desarrollo de software, se selecciona la cantidad de personal requerida
para los puestos de acuerdo a lo robusto que sea el sistema, pero los puestos necesarios
que propone la metodologa TSP son: lder de equipo, administrador de desarrollo,
administrador de planeacin, administrador de calidad de proceso y administrador de

soporte, cargos que se explicarn con ms detalle en el Tema 1.3. Ciclo de vida del Team
Software Process.
TSP se enfoca en la gestin del equipo de trabajo, y el PSP en la calidad, pero no de todo el
proceso de desarrollo ni del equipo, sino de la calidad y la gestin individual, especialmente
en los desarrolladores de software, para tener una mtrica exacta de su productividad y, con
base en esto, mejorar la calidad en su trabajo.
Piattini (2011) afirma que el TSP se basa en los siguientes elementos:
Administracin autodirigida para equipos de trabajo. Como ya se mencion, a

comparacin de PSP, TSP est totalmente orientado a equipos de trabajo.
Est integrado por indicadores: stos sealan los pasos a realizar y el orden a seguir.
Es un sistema de administracin de calidad: TSP tiene como principal propsito
asegurar la calidad en el desarrollo de software y, de este modo, conseguir la
satisfaccin total del cliente.
La estrategia del equipo est dirigida al desarrollo rpido: al utilizar la
retroalimentacin entre los miembros del equipo se evita cometer errores observados
en desarrollos pasados.
Proceso operativo apoyado por la formacin y capacitacin proporcionadas al equipo,
y dirigido a toda el rea de desarrollo. Aun cuando los desarrolladores ya cuenten con
la experiencia y la capacidad de ejecutar el trabajo, siempre hay cosas nuevas y
especficas que pueden aprenderse durante el desarrollo del proyecto.
Modelo de coaching: mtodo cuyo propsito es instruir y dirigir a las personas con el
propsito de que logren los objetivos y desarrollen habilidades especficas de
acuerdo a las actividades y roles que desempeen dentro del proyecto.
Un punto muy importante de TSP es lograr la comunicacin entre los miembros del equipo
de desarrollo del proyecto, ya que cada individuo tiene un estilo propio para llevar a cabo las
tareas. Sin embargo, el objetivo siempre ser asegurar la calidad durante todo el proceso de
desarrollo de software.
1.1.1. Principios y objetivos de TSP

El objetivo de TSP es mejorar y asegurar la calidad y productividad en un proyecto de
desarrollo de software. Para ayudar a alcanzar los costos y tiempos planeados, los objetivos
del proyecto los establecen los ingenieros de software, de acuerdo con la metodologa TSP.
Es importante que todos los involucrados tengan claros los objetivos para poder llegar a la
meta en tiempo y forma, pero para lograrlo se debe asignar a cada persona en el puesto
indicado de acuerdo con sus habilidades, conocimientos y experiencia. As se asegura un
6

buen ambiente de trabajo y que en todo momento exista comunicacin y retroalimentacin

dentro del equipo.
TSP est basado en cuatro principios fundamentales (Tuya, J. y otros, 2007):
1. El aprendizaje es mucho ms eficaz si se sigue un proceso claro y bien definido y,
adems, si existe retroalimentacin entre los miembros del equipo. TSP cuenta con
mediciones claras y est diseado para utilizarse de manera cclica, esto permite al
equipo recibir informacin continua sobre su desempeo y avances dentro del
proyecto.
2. Para que el trabajo sea productivo es necesario definir objetivos claros, liderazgo y un
ambiente de trabajo agradable.
3. Es importante contar con guas apropiadas para dar solucin a los problemas de
desarrollo que surjan durante el tiempo que dure ste.
4. Las instrucciones son ms claras cuando ya se haba adquirido el conocimiento y la
experiencia en situaciones pasadas. TSP se basa en el conocimiento y la experiencia
sobre equipos de desarrollo de software.
Hasta ahora se ha revisado el significado de TSP y sus diferencias con PSP; pudiste
observar que aunque las dos buscan la calidad, TSP se enfoca en los equipos de trabajo de
desarrollo de software, y PSP en cada una de las personas lo integran. Tambin se revis lo
correspondiente al significado del ciclo de vida de desarrollo de software como un proceso;
se explic a detalle el modelo en cascada y cada una de sus fases; por ltimo, los principios
y objetivos que tiene esta metodologa.
En el siguiente subtema se revisar la estrategia de TSP, con la cual podrs identificar la
importancia de los equipos de trabajo, as como las estrategias para conformar uno para
implementar esta metodologa de desarrollo de software dentro de una organizacin.
1.1.2. Estrategia de TSP

Las estrategias son actividades bien estructuradas y planificadas para lograr el objetivo o los
objetivos que se tengan planeados.
La estrategia de TSP es muy importante para que esta metodologa se implemente de
manera correcta, ya que indica la mejor forma de aplicar los procesos que conforman TSP
en todo el ciclo de vida de desarrollo del proyecto, y en cada una de sus etapas.
TSP se conforma de ocho procesos: lanzamiento, estrategia, plan, requerimientos, diseo,
implementacin, prueba y post mrtem, los cuales se explicarn con ms detalle en el Tema
1.3. Ciclo de Vida del Team Software Process (TSP). Toda la fase de desarrollo de software

debe cumplir con un ciclo, el cual ser elegido de acuerdo al tamao y la complejidad del
proyecto.
Por ejemplo, tomemos el modelo en cascada, el cual cuenta con cinco fases que son:
definicin de requerimientos, diseo del sistema y de software, implementacin y prueba de
unidades, integracin y pruebas del sistema, funcionamiento y mantenimiento.
La estrategia principal de TSP se basa en la bsqueda de la mejor manera de introducir sus
ocho procesos dentro de cada fase del ciclo de vida del proyecto, que en este caso sera el
modelo en cascada (Piattini, 2011). Siempre se inicia con una junta donde los lderes e
ingenieros de software presentan los objetivos del proyecto a cada uno de los miembros del
equipo; posteriormente, se aplican los otros siete restantes procesos. En la siguiente fase
(diseo del sistema y de software, segn el modelo cascada) se aplican los mismos ocho
procesos, pero se trabaja sobre lo que ya se haya desarrollado en el ciclo anterior. Con esto
se logra que el producto que, en este caso sera el software que se est desarrollando,
aumente su funcionalidad.
Como pudiste darte cuenta, la estrategia de TSP indica que no importa el modelo de ciclo de
vida que se elija para el desarrollo de software, siempre se van a utilizar los ocho procesos
que nos marca esta metodologa, y se van a implementar en cada una de las fases de
desarrollo del ciclo de vida del software a desarrollar. En el siguiente captulo aprenders las
principales caractersticas que se requieren para integrar los equipos de trabajo, de acuerdo
con algunas condiciones sealadas por el TSP.
1.1.3. Equipo TSP

En el contexto de TSP (metodologa creada para los grupos de trabajo y la
retroalimentacin), para que un equipo se forme hay algunas condiciones que deben
crearse, las cuales se mencionan a continuacin (Piattini, 2011):
Debe estar formado por al menos dos personas.

Los integrantes del equipo deben trabajar en conjunto para lograr el objetivo del
proyecto.
Todos los miembros del equipo deben de apoyarse mutuamente. Para lograr el
objetivo principal del proyecto se necesita de la ayuda y la colaboracin de todos los
miembros del equipo.
Cada persona tiene un rol especfico (establecidos por los ingenieros de software y
administradores del proyecto), el cual debe seguir porque es una gua de sus
deberes.
Para conformar un equipo efectivo de ingenieros se necesita que:


Los integrantes estn cualificados con las capacidades y habilidades propias de su

rol.
El objetivo del proyecto debe ser claro, realista y bien definido.
Los recursos que se asignen al equipo deben de ser acordes al trabajo que van a
realizar.
Los integrantes deben de estar motivados y comprometidos para lograr el objetivo.
Los miembros deben de ser disciplinados y responsables en su trabajo.
Para formar el equipo de trabajo se deben de dar las siguientes condiciones:
El equipo debe formar una estrategia de trabajo en la que todos estn de acuerdo.
Establecer objetivos en comn y definir los roles por parte de los miembros del
equipo.
Definir procesos en comn.
Todos los miembros deben de participar en la creacin de un plan.
El equipo deber negociar el plan con la administracin.
La administracin revisar y aceptar el plan realizado por el equipo.
Los miembros deben de realizar su trabajo de acuerdo al plan.
Deber existir comunicacin frecuente entre los miembros del equipo.
Todos los integrantes debern cooperar y estar comprometidos con un objetivo en
comn.
Los lderes debern de obtener feedback (retroalimentacin) y deben de buscar
liderazgo que mantenga motivados a los miembros del equipo.
En este subtema se revis lo referente a las condiciones necesarias para crear equipos de
trabajo adecuados para implementar la metodologa TSP. En la siguiente actividad
identificars los elementos de la metodologa TSP y la relacin que existe entre ellos.
1.2. Estructura del Team Software Process (TSP)

TSP es una estructura porque se conforma de partes y procesos que se encuentran
relacionados, adems indican las acciones o actividades a ejecutar y el orden en el cual
deben desarrollarse. Esto es muy importante en la implementacin de TSP, ya que indica los
pasos a seguir al momento de crear el equipo, trabajar y ejecutar acciones individuales.
Una de las ms grandes ventajas de TSP consiste en que proporciona una estructura bien
definida para guiar a los ingenieros y administradores, con el objetivo de llevar por buen
camino al equipo de trabajo. Esta estructura tambin especifica los pasos y medidas
necesarios para formar un equipo eficaz y un buen ambiente de trabajo.

En la siguiente figura se muestra la estructura de TSP:

TSP
TSP
trabajo en
creacin
equipo
del equipo
Planes personales
Mtodo de planeacin
Valor agregado
Mtricas de calidad
Procesos definidos
Disciplina
ingenieril
Compromisos
Planes agresivos
Calidad propia
Objetivos del proyecto
Plan propio
Plan detallado
Roles
Roles del equipo
Disciplina
de equipo
Prioridad en la
calidad
Costo de la calidad
Seguir el proceso
Revisin de status
y calidad
Comunicacin
Disciplina de
administracin
Equipos
integrados
Figura 2 Estructura de TSP (Gomez y Ania, 2008).
En los recuadros de la parte superior de la imagen se encuentra la metodologa que va a

usarse. Por ejemplo, la disciplina ingenieril hace referencia a PSP ya que se trata del trabajo
y habilidades que cada miembro del equipo debe tener. En las siguientes dos disciplinas, de
equipo y de administracin, se crean los equipos y se ejecuta el trabajo; para ello, se utiliza
la metodologa TSP. El conjunto de las tres da como resultado equipos de trabajo bien
conformados e integrados.
Cada una nos muestra los pasos (en TSP se llaman fases) bien definidos y estructurados
que van a ejecutarse; se forman equipos integrados hasta que hayan completado al 100%
todas sus fases. A continuacin se explicarn cada una de las disciplinas que conforman la
estructura de TSP.
10

1.2.1. Disciplina de equipo

En este subtema aprenders la disciplina de equipo con sus respectivas fases.
La disciplina de equipo consiste en una serie de reglas que deben llevarse a cabo a lo largo
del proceso de desarrollo de software. Estas reglas tambin pueden ser vistas como fases
dentro de esta disciplina y a continuacin se explicarn a detalle cada una:
Compromiso: todos los miembros debern tener bien claro cules son los
compromisos con la organizacin y con el cliente, de acuerdo a los objetivos
planteados al inicio del proyecto.
Planes agresivos: son acciones planeadas y bien estructuradas para ejecutarse
rpidamente y lograr objetivos a corto plazo; proporcionan el desempeo eficiente de
los miembros del equipo sin que se sientan presionados y reduzcan su productividad.
Calidad propia: cada desarrollador debe colocar su propio sello al desarrollo en las
pruebas a su cargo, las cuales se realizan de acuerdo al funcionamiento que debe
tener el mdulo del sistema que estn desarrollando. Es muy importante hacer
nfasis en que las pruebas son provisionales, porque las personas de calidad en la
fase de pruebas del ciclo de vida del proyecto las hacen de una manera ms
detallada, con protocolos y estndares bien definidos por el administrador de calidad
de proceso. Esto se ver ms a detalle en la unidad 3. Gestin en TSP.
Objetivo del proyecto: el equipo debe dar su punto de vista de los objetivos que se
plantean al inicio del proyecto, y as tener una visin ms clara acerca de a dnde se
desea llegar.
Plan propio: cada equipo debe de tener su propio plan, establecido por los
administradores al inicio del proyecto. Aprenders cmo hacer uno en la unidad 2.
implementacin de TSP.
Plan detallado: en la documentacin que se crea al inicio del proyecto (donde se
exponen los objetivos, los requerimientos del sistema, etc.) debe haber un plan
detallado sobre las actividades a realizarse a travs de todo el ciclo de vida del
proyecto, y sobre los riesgos que puedan surgir durante el desarrollo del software.
Todo esto lo veremos con ms detalle en el subtema 2.2. Ejecutar el trabajo en
equipo.
Roles: cada miembro del grupo debe tener bien claro cul es su rol dentro del
equipo; los roles se asignan con base en las capacidades y cualidades de cada
persona, y son establecidos por los ingenieros y administradores al inicio del
proyecto.
Recursos del equipo: el equipo debe de utilizar, de manera correcta, los recursos
proporcionados por parte de la empresa que solicita el proyecto de software, por lo
que contrata o integra un equipo TSP.
11

En conclusin, puede decirse que la disciplina de equipo indica reglas muy precisas que
guan las actividades para que se logren los objetivos del proyecto.
1.2.2. Disciplina de administracin
Esta disciplina muestra la forma en que los administradores del proyecto deben guiar al
grupo para cumplir los objetivos del proyecto de software.
Prioridad de calidad: en todo desarrollo de software, el principal objetivo debe ser la

calidad y la satisfaccin del cliente. Esta calidad se logra mediante una buena
planeacin y ejecucin al pie de la letra la metodologa TSP.
Costo de la calidad: de acuerdo a la calidad ser el coste. Debe asegurarse que los
costos sean adecuados para llegar a la calidad planeada al inicio del proyecto,
adecuados al tiempo y de acuerdo con lo robusto del sistema que vaya a
desarrollarse. Cabe mencionar que esta planeacin se hace al inicio del proyecto por
parte de los ingenieros y los administradores.
Seguir el proceso: al inicio del proyecto se establecen procesos bien definidos, y los
administradores deben de revisar se cumplan. Esto se aprender en el tema 1.3.
Ciclo de vida del Team Software Process (TSP).
Revisin de status de calidad: para este fin, tanto los desarrolladores como los
administradores utilizan plantillas y reportes, que t aprenders a hacer en la unidad
3. Gestin en TSP.
Comunicacin: la comunicacin entre los miembros del equipo no solo permite que
se llegue a los objetivos deseados, tambin sirve para tener un buen ambiente de
trabajo y llevar a cabo la retroalimentacin que ayuda a no repetir errores ya
cometidos, en el mismo proyecto o en anteriores.
Como se puede notar, la disciplina de la administracin se basa en los administradores y en

la forma de medir el nivel de calidad del desarrollo del proyecto. En el siguiente subtema
conocers la disciplina que est orientada a las personas que conforman el equipo de
desarrollo de un proyecto.
1.2.3. Disciplina de ingeniera

Esa disciplina se basa totalmente en PSP, ya que es necesario medir la calidad respecto a
las habilidades individuales de los miembros del equipo, quienes deben saber que forman
parte del grupo y, al mismo tiempo, ser responsables de sus actividades de acuerdo a los
roles que se les hayan asignado. La disciplina de ingeniera se conforma por las siguientes
actividades:
12

Planes personales: cada miembro del equipo debe conocer su rol dentro del
proyecto y estar consciente de su responsabilidad para que el objetivo se cumpla.
Mtodo de planeacin: cada miembro debe manejar y planear correctamente sus
tiempos y las responsabilidades que tiene.
Valor agregado: cada miembro del equipo aportar su experiencia y conocimiento en
el desarrollo de los proyectos.
Mtricas de calidad: las mtricas son una referencia exacta para medir el nivel de
algo en especfico. En este caso sirven para controlar, medir, monitorizar, predecir y
probar el desarrollo de software. Por ejemplo, una mtrica podra ser una plantilla
donde muestre los avances que ha tenido el proyecto mes con mes. Esta fase se
explicar con ms detalle en el tema 3.2. Diagnstico: Mtricas de calidad versus
trabajo realizado.
Procesos definidos: muestran a los miembros del equipo un panorama general para
comenzar con el desarrollo del software.
Es muy importante entender con claridad cul es la estructura de TSP y su objetivo en cada
disciplina. Como pudiste aprender, las disciplinas son como recetas de cocina que dicen qu
acciones tomar en todas y cada una de las fases de desarrollo del proyecto. En el siguiente
tema aprenders la forma en que est estructurado el ciclo de vida de la metodologa TSP.
1.3. Ciclo de vida del Team Software Process (TSP)

El ciclo de vida del TSP se conforma de una serie de ciclos (puede ir desde uno hasta un
nmero indefinido, dependiendo de la magnitud del proyecto), organizada en ocho fases.
stas comienzan con los requerimientos del producto de software, donde se establece lo que
se quiere lograr y comienza con la creacin de diseos detallados del software, que es
revisado por todo el equipo. Posteriormente, dicho diseo se convierte en cdigo, el cual
tambin es revisado y analizado para realizar las pruebas pertinentes; finalmente se analiza
la calidad del producto de software terminado. Es entonces cuando el ciclo de vida del TSP
llega a su fin (Nord, R; McHale, J., & Bachmann, F., 2010).
En la aplicacin del ciclo de vida del proceso de software de equipo de TSP, se definen las
fases del desarrollo de software que se realizarn por parte del equipo de trabajo, las cuales
describen una serie de pasos para ayudar a alcanzar productos de calidad. La metodologa
del TSP contempla ocho faces de desarrollo bien definidas (ver figura 1.1), que deben
llevarse a cabo de manera cclica durante el proceso de desarrollo de software. Es preciso
mencionar que el equipo de trabajo realizar el proceso de desarrollo de software y de
control de la calidad; sin embargo, el encargado de revisar que esto se cumpla es el
administrador de calidad dentro de los roles del equipo, lo que se explicar en el subtema
13

1.3.1. Fase de lanzamiento. Cada una de las fases describe las actividades que les son
propias, y que se explican a continuacin (Humphrey, 1999).
Lanzamiento
Estrategia
Planeacin
Requerimientos
Diseo
Implementacin
Pruebas
Post mrtem
Figura 3. Fases del ciclo de vida del TSP (Humphrey, 1999).
1.3.1. Fase de lanzamiento

En este subtema se revisarn las directrices a seguir para dar comienzo con el desarrollo del
producto de software.
Dentro de la fase de lanzamiento se establecen las metas y objetivos del equipo de proyecto;
tambin se determinan los roles y responsabilidades que desempearn cada uno de los
integrantes, y la manera idnea para forma el equipo de trabajo. Las metas y objetivos se
llevan a cabo de forma individual y en equipo, en la tabla 1 observars un ejemplo de los
objetivos planteados de manera individual.
Es de gran importancia definir los objetivos de tal manera que sean medibles, y as
determinar la calidad del producto generado (ver tabla 1). Deben establecerse objetivos
ambiciosos para los miembros del equipo, pero sin alejarse de la realidad (ser un miembro
eficiente del cooperativo, realizar un trabajo personal disciplinado, etc.). Poner los objetivos
por escrito ayudar de manera significativa al equipo para determinar, de forma peridica,
hasta qu grado fue cumplido cada objetivo planteado. Todos los miembros del equipo
deben estar comprometidos con los objetivos programados y participar activamente con l.
Tabla 1. Objetivos propuestos para los miembros del equipo y sus indicadores
14

Objetivos
Ser un
miembro del
equipo
cooperativo y
efectivo
Realizar un
trabajo
personal
disciplinado
Planear y dar
seguimiento al
trabajo
personal
Hacer
productos de
calidad
Indicador 1
El promedio de
la evaluacin de
cada miembro
del equipo,
efectuada por los
pares acerca de
la disposicin a
ayudar y la
aportacin del
trabajo, debe ser
mayor a 3 (sta
es una medicin
de la eficacia y
eficiencia que el
equipo
establece,
determina, y
califica).
El porcentaje de
los datos
personales
(desempeo,
eficacia,
etctera)
registrados debe
ser 100%.
Indicador 2
Indicador 3
Indicador 4
La densidad
de defectos
encontrados
durante la
prueba de
unidad debe
La densidad
de defectos
encontrados
durante y
despus de la
prueba de
El promedio de
la evaluacin de
cada miembro
del equipo,
efectuada por
los pares acerca
de la
contribucin
general hecha al
equipo, debe ser
mayor a 3.
El porcentaje de
semanas
registradas en el
documento
semanal debe
ser 100%.
El porcentaje de
las tareas del
proyecto con
plan y datos
reales
registrados en
forma
correspondiente
debe ser 100%.
El porcentaje de La densidad de
defectos
defectos
encontrados
encontrados
antes de la prime durante la
compilacin
compilacin
debe ser mayor
debe ser menor
El porcentaje de
los datos del
proyecto
personal
registrados en
las formas
correspondientes
debe ser 100%.
15

a 70%.
a 10/KLOC.
ser menor a
5/KLOC.
unidad debe
ser 0.
Gmez y Ania, 2008

Tabla 2. Objetivos propuestos por el equipo y sus indicadores
Objetivos
Indicador 1
Indicador 2
El porcentaje de
La cantidad de
defectos
defectos
Crear producto de
encontrados antes
encontrados en la
calidad
de la primera
prueba del sistema
compilacin debe
debe ser 0.
de ser 80%.
Llevar a cabo un
proyecto
productivo y bien
administrado
El error en la
estimacin del
producto debe ser
menor a 20%.
Terminar el
proyecto a tiempo
El total de das de
retraso o adelanto
para completar el
ciclo debe ser
menor a 4.
El error en el
nmero de horas de
desarrollo debe ser
menor a 20%
Indicador 3
Al terminar el
proyecto se debi
haber incluido el
100% de las
funcionalidades.
El porcentaje de
datos del proyecto
debe ser 100%.
Gmez y Ania, 2008

En la tabla 1y 2 se muestran los objetivos planteados y sus indicadores, que son los criterios
a evaluar en cada objetivo, a los cuales se les establece un valor que el equipo asigna para
que puedan ser medidos.
En la fase de lanzamiento se programa una serie de reuniones, donde participan todos los
miembros del equipo para generar el plan del lanzamiento. Se recomienda dar seguimiento a
los planteamientos que se presentan a continuacin:
Las empresas necesitan
metas de gestin de
requisitos del producto.
Qu?
Cmo?
Cundo?
Quin?
Qu
tan
bien?
Qu
pasa
si...?
16

Los objetivos
del equipo
Diseos
conceptuales
Productos
planeados
La
estrategia
de equipo
El equipo
define el
proceso
Plan de
tareas
Funciones
del equipo
Plan de
calendario
Planes de
trabajo
Plan de
calidad
Evaluacin de
riesgos
Plan de
alternativas
Plan de valor
agregado
Tamao de
estimaciones
Figura 4. Lanzamiento del TSP (Queensland, 2010).
17

Las preguntas que se plantean en el esquema anterior: qu?, cmo?, quin?, qu tan
bien? y qu pasa si...?, permitirn establecer las bases de una estrategia del lanzamiento
para llegar a la culminacin del proyecto; en conjunto con la anterior, se deben tomar en
cuenta los requerimientos que sern establecidos por parte del cliente (Queensland, 2010).
Como se mencion anteriormente, en la fase de lanzamiento se asignan las tareas y roles
del equipo de trabajo, a continuacin de describen los roles del TSP.
Roles de TSP
Lder del proyecto
Es aquel que lleva el mando del equipo, el que lo dirige, esta figura se asegura de que todos
realicen y completen su trabajo, reporten sus procesos tal cual como fue planeado en fin, es
el que maneja los alcances del proyecto (Osorio, 2013, p.2).
El ingeniero que tenga este rol debe realizar reportes semanales sobre los avances del
equipo (Osorio, 2013). En la siguiente tabla se muestra un ejemplo para generar los reportes
de avances del equipo.
18

Tabla 4. Reporte de avances de equipo

Reporte semanal TSP
Nombre:
Fecha:
Equipo:
Ciclo:
Datos semanales
Horas del proyecto para esta
semana
Horas del proyecto de este ciclo
a la fecha
Valor ganado para esta semana
Valor ganando en este ciclo a la
fecha
Horas totales para las tareas
terminadas en esta fase a la
fecha
Semana:
Planeado
Actual
Datos
semanales por
rol
Horas
planeadas
Horas actuales
Valor planeado
Valor agregado
Tareas de
desarrollo
terminadas
Horas
planeadas
Horas actuales
Valor ganado
Semana
planeada
Seguimiento de asuntos o riesgos
Estatus
Otros asuntos
importantes
LE Lder de equipo
AP Administrador de planeacin
AD Administrador de
desarrollo
ACP Administrador de
calidad/proceso
AA Administrador de
apoyo
UABC, 2005
19

El lder de proyecto es el representante ante el cliente, el encargado de la integracin de la

planeacin e implementacin de todas las tareas de los involucrados en el desarrollo del
producto de software, con el objetivo de culminar el proyecto.
Administrador de desarrollo
Los administradores de desarrollo guan al equipo en la planificacin y seguimiento del
desarrollo del producto de software.
Su principal objetivo se centra en la fase de diseo del proyecto. Aqu toma el mando del
proyecto el ingeniero con mayor conocimiento en diseo, quien formular las actividades que
requiera esta etapa, adems de asegurarse de que todas se realicen a cabalidad (Osorio,
2013).
Las funciones principales del administrador de desarrollo son (Osorio, 2013):
Proponer estrategias de desarrollo (se describirn ms delante).

Auxiliar al lder de proyecto para estimar los tiempos, recursos y tamao del producto
de software.
Dirigir el anlisis de alto nivel.
Dirigir el diseo.
Dirigir la implementacin de pruebas.
Colaborar con el equipo de desarrollo.
Como podrs darte cuenta, el administrador de desarrollo debe de colaborar muy de cerca
con cada uno de los miembros del equipo que desempean los distintos roles.
Administrador de planeacin
El administrador de planeacin es el principal responsable de llevar el control de los planes
del equipo, y de dar apoyo a cada miembro cuando se presenten problemas que estn
relacionadas con el plan.
Debe dirigir la generacin del plan de trabajo en cada ciclo de desarrollo y establecer cmo
estarn definidas las partes del producto final. Administra el qu, quines, cmo, cundo y
dnde se va a hacer. De ello depende la complejidad y factibilidad del proyecto. Est ligado a
los objetivos propuestos, hasta dnde se va a llegar (Osorio, 2013).
20

Administrador de calidad
El administrador de calidad se encarga de proponer el plan de calidad tanto para el proceso
como para el producto. Tiene la responsabilidad de determinar las necesidades que se
presenta dentro del proceso, y le da seguimiento a la calidad del producto.
Tambin determina las necesidades dentro del proceso de calidad que se implementar en
el proyecto de software y le da seguimiento, con el fin de mantener la calidad del producto
(Osorio, 2013).
Sus funciones bsicas son stas:
Mantener estndares de desarrollo.

Mantener los patrones de calidad que se deban seguir durante el mismo proceso.
Dirigir las inspecciones de calidad del producto de software.
Registrar y documentar las reuniones que se hagan relacionadas con el equipo y su
proyecto software, como todos los roles anteriores.
Colaborar con el equipo de desarrollo de software (Osorio, 2013).
Es de suma importancia que el administrador de calidad revise que todo el equipo de trabajo
alcance los estndares y patrones de calidad; debe alertar al lder del proyecto sobre
cualquier trabajo que no los cubra.
Administrador de configuraciones
La administracin de configuraciones es considerada uno de los factores de mayor
influencia para lograr el ptimo desarrollo de productos software de alta calidad, porque es la
encargada de garantizar que los cambios sean efectivos y eficientes (Osorio, 2013,).
El administrador de configuraciones debe poseer un documento donde integre el
seguimiento del proceso, es decir, un proceso documentado para realizar el manejo de la
configuracin de los productos y subproductos, donde se indiquen los procedimientos
necesarios para llevar a cabo las labores de administracin de configuraciones tales como:
Establecer los nmeros de las versiones de los productos o que indican dichos
nmeros.
Mantener la trazabilidad (conocer el histrico del proyecto, en este caso las
versiones del producto) de los productos y subproductos desarrollados (Osorio,
2013).
Coordinar todas las actividades de cambio que realice cualquier miembro del equipo.
Administrar el versionamiento (la gestin de los cambios que se realicen en el
producto de software); es decir, administrar el control de cambios y su sistema,
21

recomendar los cambios o ajustes que deben realizarse, verificar, mantener y

evaluar la persistencia del sistema, fomentar la reutilizacin del cdigo y recursos
Sentirse parte del desarrollo.
Sin duda alguna, la fase de lanzamiento es una de las etapas primordiales y ms

importantes dentro del ciclo de vida del TSP. De ella emana lo que se va a hacer, cmo se
va a hacer y hasta dnde se quiere llegar, la culminacin de esta fase dar el banderazo de
inicio a la de estrategia.
1.3.2. Fase de estrategia

Ya se explic lo que debe realizarse en la fase de lanzamiento para dar inicio al desarrollo
del producto de software. Ya se elaboraron los equipos y se asignaron los roles, ahora es
necesario plantear las estrategias a seguir para dar seguimiento a desarrollo del producto de
software. En esta fase conocers las estrategias de desarrollo para entender lo que se va a
producir en cada ciclo, analizars e identificars las estimaciones de tamao y esfuerzo que
se requieran.
En la fase de la estrategia los equipos idean un diseo conceptual del producto previsto. De
igual manera se hacen estimaciones sobre el tamao y el tiempo que tomar el desarrollo,
teniendo en cuenta que el tiempo que se llegue a considerar debe ser acorde con el tiempo
que se tiene disponible. La fase de estrategia contempla los siguientes puntos principales:
Medir el tiempo real del desarrollo y el tiempo disponible.
El largo alcance de internet en tiempo real. Tomado de http://www.corbax.com/blog/img/tiempo-real.jpg
Crear el diseo conceptual del producto: es el punto de arranque para realizar la

planificacin del proyecto. Se establece un plan para la elaboracin del producto.
Para la elaboracin del diseo conceptual, los miembros del equipo deben basarse
en experiencias previas con la finalidad de saber cmo puede desarrollarse el
siguiente producto; para esto se utilizan los diagramas UML (lenguaje unificado de
22

modelado), lenguaje grafico que permitir especificar, visualizar, construir y

documentar un sistema de software. Reviste gran importancia como gua del equipo
de trabajo en todo el proceso.
Diseo y reorganizacin. Tomado de http://www.logismarket.es/ip/blife-diseno-y-reorganizacion-de-almacenesdiseno-y-reorganizacion-de-almacenes-491419-FGR.jpg
Establecer la estrategia de desarrollo: el equipo decide cul es la mejor manera para

dividir el trabajo entre los ciclos y lo que ser producido en cada uno de stos. Puede hacer
uso de herramientas CASE.
Estimacin de tamao y esfuerzo: se refiere al tamao estimado que tendr el producto y
el tiempo que se llevar en realizarlo. Debe considerarse el tiempo disponible para hacer los
a ajustes necesarios a la estrategia, y que los tiempos puedan coincidir. Puedes hacer uso
de la gua del PMBOK (captulo 6.1.) para realizar estas estimaciones.
23

Plan de gestin de riesgos: para realizarlo se debe estar totalmente comprometido con el
proyecto, para elaborar un producto de calidad. En la siguiente tabla se muestra un ejemplo
de gestin de riesgos. Corresponde a un plan de riesgos que se implement en el desarrollo
y mantenimiento de componentes para Web 2.0 en bibliotecas especializadas.
Tabla 5. Ejemplo de gestin de Riesgos
Riesgo RI-05. Inexperiencia del equipo informtico/bibliotecario en el desarrollo e
implementacin del proyecto.
Aspectos a considerar
Por qu el riesgo es importante? Podra alterar la calidad del producto,
provocar atrasos en el desarrollo e implementacin del proyecto.
Qu informacin se necesita para seguir el estado del riesgo:

o Documentos de estado de avances de trabajos individuales, en donde se
explayen las tareas realizadas y las dificultades presentadas; si stas
fueron solucionadas con xito y cmo se consigui.
o Planilla de informe de errores y soluciones.
Los responsables de realizar el control del riesgo son el jefe del proyecto y los
integrantes del equipo de trabajo.
Para realizar un adecuado control del riesgo se necesitar personal capacitado

en validar las funciones desde el punto de vista tcnico/bibliotecolgico. Si el
control corresponde a una actividad informtica, el personal deber tener
amplios conocimientos sobre la tecnologa incluida en el proyecto; si el control
corresponde a una actividad bibliotecolgica, deber poseer el conocimiento de
la tecnologa aplicable a la bibliotecologa.
Plan de accin
Cursos de capacitacin de tecnologa y administracin de componentes web.
2.0 para el personal bibliotecario.
Realizar talleres y actividades integradoras.
Reuniones semanales entre informticos y bibliotecarios.
Contratar personal Informtico especializado en:
Tecnologa web.
Base de datos.
Diseo de pginas web.
Plan de contingencia
Disparador: el plan de avance no refleja los resultados esperados, falta de
calidad en el producto.
Contratar una consultara experta en tecnologa Web 2.0.
Kuna, Caballero et l., 2008
24

El TSP recomienda que las estrategias definidas sean documentadas para darles un
continuo seguimiento.
En este subtema se describi lo que es una estrategia y la manera en que debe
desarrollarse. Esto tiene como objetivo hacer un producto de calidad, para ello el equipo
debe estar de acuerdo con los criterios de la estrategia y darle seguimiento. Lo ya
mencionado permitir saber cmo se va a realizar el producto de software. Estas estrategias
ayudarn al equipo a preparar la planeacin, la cual se explicar en el siguiente subtema.
1.3.3. Fase de planeacin

En la fase de lanzamiento, el equipo debi haber analizado las necesidades y creado un
diseo conceptual de la estimacin de tamao del producto; en la fase de estrategia, debi
realizar una estimacin de tiempo que llevar el desarrollo. stas son las bases para el
siguiente proceso que, en este caso, es la planeacin.
Dentro de la fase de planeacin los miembros del equipo generan un plan de trabajo, que
puede contener un inventario de los elementos que sern utilizados. ste puede contener:
Estimacin del tamao de cada parte a ser desarrollada: ste ser determinado
por el tamao del trabajo.
Identificacin de las tareas, estimacin el tiempo necesario para completarlas:
para esto es necesario asignar las tareas a cada miembro del equipo.
Cronograma semanal para tareas terminadas: se puede hacer uso de
herramientas como Microsoft Project, y hacer diagramas de Gantt para llevar el
control de las actividades; all se programan las tareas y se propone una duracin,
fecha de inicio y trmino. Por ltimo, se lleva el control semanal sobre el porcentaje
de cumplimiento.
Plan de calidad: es un documento que especifica quin, cundo y qu
procedimientos y recursos asociados deben aplicarse a un proyecto, producto,
proceso o contrato especfico (Secretara Central de ISO, 2005).
Es posible observar los formatos de un plan de gestin de calidad para un programa de

capacitacin en la pgina de Dharma Consulting Especialistas en Project Managemen, ah
encontrars herramientas gratuitas de gestin de proyectos y podrs observar los
lineamentos establecidos para realizar un control de calidad.
Los objetivos de calidad, que se encuentran en la lnea base de calidad del proyecto, se
refieren a la medicin con la que se evaluar el cumplimiento de las metas establecidas por
el equipo de trabajo. La mtrica se refiere, de igual manera, a una medida que proporciona
25

una indicacin cuantitativa (dimensin o tamao de algunos atributos). Otra observacin

importante es el sponsor, patrocinador o cliente.
La complejidad para elaborar un plan de desarrollo depende del tamao del proyecto. El
hacer un plan permitir trabajar de una manera ms eficiente en el rubro de calidad. En el
siguiente subtema se aplicar lo planeado con base en los requerimientos del desarrollo del
software.
1.3.4. Fase de requerimientos

A continuacin revisars algunas recomendaciones necesarias para conocer las
especificaciones de requerimientos de software, el anlisis de necesidades y los criterios
necesarios para realizar lo que en verdad se quiere.
Una vez que se ha concluido con la fase de planeacin se pueden gestionar los
requerimientos, stos se establecen al entrevistar a los clientes para determinar lo que se va
a producir (Humphrey, 1999). En esta fase se construyen las especificaciones de
requerimiento de software; esto nos sirve de gua durante el proceso del desarrollo del
producto. Es importante que el equipo de trabajo lleve estos requerimientos en documentos y
que todos lleguen a un acuerdo acerca de lo que se va desarrollar.
En muchas ocasiones los requisitos que especifica el cliente llegan a ser imprecisos, lo que
ocasiona que los requerimientos sufran cambios de manera constante. Los clientes creen
estar seguro de sus deseos, pero esto no siempre es as. Por ello no se debe caer en
suposiciones, y s tener muy claro lo que el cliente desea en realidad.
La fase de requerimientos sugiere las siguientes actividades.
Anlisis de necesidades del cliente. Se realiza una serie de preguntas y respuestas que
deben ser lo suficientemente claras para poder analizar las necesidades del cliente. Debe de
haber participacin de todos los involucrados, integrantes del equipo y cliente, para llegar a
un acuerdo mutuo. En este punto, TSP indica el qu, pero las preguntas respecto al cmo se
debe general al interior del equipo, de tal manera que puedan recolectar la informacin
necesaria.
Especificacin de requerimientos. stos se clasifican en:
Requerimientos funcionales: describen los servicios que debe proporcionar el

sistema y el comportamiento que tendr en ciertas circunstancias. Los requerimientos
dependern del tipo de software que est en desarrollo. A continuacin se presenta
un ejemplo de requerimientos funcionales para un sistema de biblioteca universitaria,
26

denominado Libsys, utilizado por estudiantes y personal docente que solicitan libros y
documentos de otras bibliotecas.
Requerimientos funcionales de Libsys (Olivera, 2010):
1. El usuario deber tener la posibilidad de buscar en el conjunto inicial de la base de
datos o seleccionar un subconjunto.
2. El sistema deber proporcionar visores adecuados para que el usuario lea
documentos en el almacn de documentos.
3. A cada pedido se le deber asignar un identificador nico (id_pedido), que el
usuario podr copiar al rea de almacenamiento permanente de la cuenta.
Requerimientos no funcionales: son aquellos requerimientos que no estn

involucrados directamente a las funciones del sistema. Pueden ser las capacidades
de almacenamiento o restricciones de tiempo de respuesta. Ejemplo: si se requiere
desarrollar un programa para un cajero automtico y el cliente desea que el programa
est funcionando las 24 horas del da, en este caso se observa que el requerimiento
no funciona, es decir, la disponibilidad.
Es indispensable que los requerimientos sean examinados por el equipo de trabajo para
desarrollar un plan de pruebas.
En conclusin, la fase de requerimiento nos da a conocer lo que el cliente desea y las
funciones que se proponen para el producto a realizar; se llega a un acuerdo mutuo sobre lo
que se va a construir.
1.3.5. Fase de diseo

En este subtema conocers los aspectos bsicos para crear el diseo del producto de
software. Aqu se genera la estructura general del producto; para esto se deben definir las
especificaciones del diseo del software. Se debe generar un diseo completo de los
requisitos para poder precisar claramente el producto que va a desarrollarse
(Humphrey, 1999).
Despus de que se tienen bien definidos los requisitos, se deben llevar acabo las siguientes
actividades:
Crear un diseo de alto nivel: describen los componentes principales del sistema y
la forma en que interactan entre s. El equipo puede trabajar de forma independiente
ya que es posible separar el diseo en partes. Esto se refiere a la creacin de las GUI
27

(interface grfica de usuario), que ser la va de comunicacin entre el usuario y el

sistema (software).
Inspeccionar el diseo: al inspeccionar se puede mejorar de manera importante la

calidad de los diseos, pero para esto se tiene que estar lo mejor documentado
posible.
Desarrollar un plan de evaluacin: disear la estructura principal de los

requerimientos del sistema permitir la implementacin y codificacin de ste.
1.3.6. Fase de implementacin

Ahora aprenders las acciones que se llevan a cabo en la etapa de implementacin, que
est relacionada con la codificacin y el uso de estndares dentro del sistema.
En esta fase se realiza la implementacin del producto de software; se empieza a
decodificar, pero antes se debe inspeccionar minuciosamente el cdigo del software (Gmez
y Ania, 2008).
Los estndares en esta fase cumplen un papel muy importante. El equipo de trabajo debe
definir estas normas al inicio de proyecto; esto puede hacerles ahorrar mucho tiempo en
desarrollo del sistema.
Como ya se mencion, los estndares de diseo dentro de esta fase son fundamentales. A
continuacin se muestran algunos de ellos:
Revisin de estndares
Estndares de codificacin
Estndar de tamao
Estndar de defectos
Prevencin de defectos
En la fase de aplicacin es muy frecuente encontrar errores de transcripcin y de

codificacin, errores producidos al pulsar una tecla por otra. Por esta razn, varios
programadores deben revisar e inspeccionar el cdigo (Humphrey, 1999).
El uso de estndares te permitir encontrar y mitigar errores de escritura, as ahorrars
tiempo y esfuerzo; pero para esto se necesitan hacer las pruebas correspondientes que
veras en el siguiente subtema.
28

1.3.7. Fase de pruebas

Esta fase es una da las ms importantes ya que debe probarse el producto y evaluar,
detectar y corregir todos sus defectos; de esta manera se evita que los costos lleguen a
elevarse considerablemente (Gmez y Ania, 2008).
En esta etapa se realizan diferentes pruebas al sistema, con el fin de asegurar su calidad y
evaluar el desempeo del equipo de trabajo. Para administrar las pruebas se debe tener una
lista de pasos a seguir; se hace por partes, de manera gradual, y se empieza desde el primer
nivel hasta el ms alto para que, al final, se integre de tal manera que todos los elementos
estn incluidos y que funcionen correctamente.
A continuacin se muestra una gua que contempla TSP para llevar el control de las pruebas
al sistema.
Tabla 6. Integracin y pruebas del sistema
Propsito
Para guiar a un equipo a travs de la integracin y prueba de

los componentes del producto en un sistema.
Los criterios de ingreso
El equipo cuenta con un plan y una estrategia de desarrollo.
Componentes implementados, inspeccionados, y la unidad
probada bajo control de configuracin.
General
Cuando los defectos se encuentran en construccin, integracin o
en la prueba del sistema, el responsable de calidad/proceso
determina si la prueba debe continuar. Todo defecto que se
encuentra en la integracin o pruebas del sistema se consigna en
el registro de defectos, y debe de ser revisado por todo el equipo
para determinar:
Cuntos defectos similares pueden permanecer en el
producto.
Cmo y cundo encontrar y corregir esos defectos.
El proceso cambia para prevenir defectos similares en el
futuro.
Paso Actividades
Descripcin
1
Prueba descripcin El administrador de calidad describe:
general del
El proceso de pruebas de integracin y de sistema.
proceso.
La necesidad de componentes de calidad antes de probar.
La necesidad y el contenido de las normas de ensayo.
La estrategia para el manejo de componentes de baja
calidad.
2
Desarrollo de
El administrador de desarrollo conduce el progreso de la
29

pruebas
Construir
prueba.
El jefe del equipo de ayuda a asignar el desarrollo de la
prueba y ensayo entre los miembros del equipo.
Los miembros del equipo de pruebas realizan sus tareas de
desarrollo de las pruebas.
Definir los procesos y procedimientos de generacin
requeridas.
Desarrollar los procedimientos de ensayo de la integracin
y las instalaciones.
Desarrollar los procedimientos de ensayo de sistemas e
instalaciones.
Medir el tamao y el tiempo de funcionamiento para cada
prueba.
Revisar los materiales de prueba y corregir errores.
El equipo construye el producto y comprueba que est
completo. Verifica que todas las piezas necesarias estn a
la mano.
Integracin
Prueba del
sistema
Documentacin
El encargado del desarrollo del software, consigna todos

los errores en el registro de defectos.
El gerente de desarrollo o alternativas:
Conduce las tareas de integracin.
Comprueba la integridad y la integracin de la prueba del
producto.
Escribe todas las actividades de prueba en el registro de la
misma.
El encargado del desarrollo del software, registra todos los
defectos en el registro de defectos.
El gerente de desarrollo o alternativas conduce las tareas de
prueba del sistema.
Prueba el producto en condiciones normales y de estrs.
Prueba el producto para la instalacin, la conversin y la
recuperacin.
Consigna todas las actividades de prueba en el registro de
la prueba.
El propietario del producto (desarrollador) asienta todos los
errores en el registro de defectos.
El gerente de desarrollo o suplente se encarga de:
Producir el contorno usuario-documentacin y tareas.
La asignacin de estas tareas al equipo de documentacin.
30

Criterios de salida
Revisar el esquema con el equipo de pruebas de

integridad.
Elaborar la documentacin de usuario de primer ciclo.
Producir, revisar y corregir la documentacin del usuario.
Un ciclo-1 integrado y probado del producto.
Formas logD y LOGTEST completadas para todas las
pruebas.
Documentacin del usuario completada y revisada.
Datos de tiempo, tamao y defectos introducidos en el
sistema de apoyo TSPI.
Humphrey, 1999
En conclusin, si no se llevan a cabo las pruebas al producto de software no se podr

garantizar su funcionamiento, lo cual ocasiona que no sea un producto de calidad. sta es
una de las ltimas fases del ciclo de vida del TSP. Ahora se tiene que hacer un anlisis de
todo lo ocurrido durante el desarrollo del producto en la fase post mrtem.
1.3.8. Fase post mrtem

sta es la fase de la culminacin del proceso de TSP. Se comienza con la evaluacin de
todas las tareas que se definieron para el proyecto, se verifican las metas del plan de calidad
y del trabajo del equipo.
Es necesario hacer un registro de todos los datos en formatos para su revisin, ver tabla 6.
(Humphrey, 1999).
A continuacin se ofrece un ejemplo de cmo registrar los datos para la fase post mrtem.
Tabla 7. Recoleccin de Datos
Propsito
Recoger, analizar y registrar los datos del proyecto para evaluar el
equipo y el desempeo de cada funcin.
Identificar las formas de mejorar el proceso de ciclo 2 para producir
el informe ciclo-1.
Los criterios de ingreso Los ingenieros han completado y probado el producto.
Se han reunido todos los datos y completado todos los formularios.
General
El informe de ciclo-1 contiene un anlisis del proyecto por cada
funcin.
El rendimiento general del equipo: lder del equipo.
Plan de actuacin frente al actual: gerente de planificacin.
Diseo de producto global y las normas: gerente de desarrollo.
31

Paso
1
Actividades
Post mrtem
descripcin
general del
proceso.
Revise los
datos de
proceso.
Evaluar el
desempeo
del rol.
Ciclo de
preparacin1. Informe
Preparar
evaluaciones
de funciones
Criterios de salida
Gestin del cambio y proyecto de apoyo: gerente de soporte.

La calidad de proceso y producto: gestor de calidad/proceso.
El informe ciclo debe:
Utilizar los datos de proceso para apoyar las declaraciones de los
ingenieros.
Cuidadosamente considerar el significado de los resultados
obtenidos.
Sea breve y conciso.
Descripcin
El instructor describe el proceso post mrtem.
La necesidad de una informacin completa y precisa del proceso.
El contenido del informe de ciclo.
El proceso de evaluacin por pares y formas.
El responsable de calidad/proceso dirige el equipo en el anlisis de
los datos del proyecto y la identificacin de las reas problemticas a
mejorar.
El liderazgo, la planificacin, el proceso, la calidad o el apoyo.
Acciones y responsabilidades del equipo sugeridas.
reas de instructor o instalacin mejora.
Los ingenieros encargados de preparar y presentar PIP en estas
sugerencias de mejora.
El lder del equipo lo conduce en la evaluacin de la eficacia de las
funciones del equipo, las acciones del instructor y las instalaciones
de apoyo.
Cundo eran eficaces.
Dnde hay margen de mejora.
El lder del equipo lo conduce al esbozar el informe ciclo-1.
La asignacin de trabajo; informe a los miembros del equipo.
Obtencin de compromisos para la seccin informe de terminacin.
Montaje, revisin y correccin del informe completo.
Cada ingeniero completa una evaluacin del equipo y de cada
participacin individual con base en el formulario PEER.
Dificultad y la contribucin de cada funcin.
Los porcentajes deben sumar 100%.
La eficacia de cada papel en escala de uno (inadecuado) a cinco
(superior).
El ciclo de desarrollo ha resultado en un producto de alta calidad con
toda la documentacin requerida.
El producto terminado est bajo control de la configuracin.
Todos los datos de proceso se han evaluado y presentado PIP.
32

Las evaluaciones interpares se realizaron y sometieron (PEER).

El informe ciclo-1 se ha completado y presentado.
El cuaderno del proyecto se ha actualizado.
Humphrey, 1999
Al hacer la revisin de los datos de todo el proceso debe examinarse lo que cada miembro
del equipo hizo, adems de identificar qu parte del proceso realiz. Despus se hace una
comparacin del rendimiento obtenido por el equipo en lo planeado y metas fijadas al inicio
del ciclo, as se podrn identificar las reas del problema. Cuando se utiliza el proceso post
mrtem se podrn hacer los cambios necesarios para el prximo ciclo, corregir problemas
encontrados y determinar cules fueron las causas que ocasionaron las fallas para,
posteriormente, tomar medidas preventivas. Esto permitir llevar al equipo a la mejora
continua.
Cierre de la unidad
El TSP es una metodologa que sirve de gua para los ingenieros informticos; provee
mtodos para el fcil desarrollo de software por medio de miembros que llegan a formarse
en equipos, los cuales se desenvuelven de una manera organizada; tienen su roles y
actividades propias, los dirige un lder que recopila informacin y los mantiene ordenados
para lograr los objetivos planteados.
El ciclo de vida del TSP es una serie de ciclos que se llevan a cabo durante el desarrollo del
producto de software. Comienza con la declaracin de las necesidades del producto y
finaliza con la entrega final.
La fase de lanzamiento es pieza clave para el inicio del desarrollo del software; es aqu
donde se forman los equipos y se asignan las actividades que desempearan cada uno de
los miembros, como ya se explic aqu; pero esto lo vers con ms detalle, junto con la
elaboracin de planes de riesgo y calidad, en la prxima unidad.
Si se desea desarrollar un software, siempre es imprescindible utilizar un mtodo como lo es
el TSP, para lograr un producto confiable y de buena calidad; asimismo nos permitir mejorar
de una manera significativa todos los procesos implicados en el desarrollo.
33

Para saber ms
En la pgina del Institute Carnegie Mellon
(http://www.sei.cmu.edu/library/abstracts/reports/10tr031.cfm), existe mucha informacin
acerca de las herramientas de medicin de la calidad del desarrollo de software, entre ellas
TSP, sobre la que encontrars diversos artculos y documentos.
Tambin puedes consultar un caso de uso de PSP y TSP en el documento Uso de
tecnologas y metodologas de desarrollo, de Roy Steeven Yarce David, que se encuentra
accesible en la seccin Material de apoyo.
Es recomendable revisar el documento de Watss S. Humprey, The Team Software Process,
donde se explica la metodologa TSP. La versin original de este documento, escrito en
ingls, se encuentra en la seccin Material de apoyo; si no posees el nivel de comprensin
de este idioma, puedes utilizar alguna de las diversas herramientas de traduccin que se
encuentran en Internet.
Fuentes de consulta
Colomo, R., y Paniagua, F. et al. (2011). Team Software Process. Madrid:

Universidad Carlos III de Madrid. Recuperado de http://ocw.uc3m.es/ingenieriainformatica/desarrollo-de-sistemas-de-informacion-corporativos/material/TSP.pdf/view
Dharma Consulting Especialistas en Project Management (2013). Herramientas

gratuitas de gestin de proyectos. Recuperado de
http://dharmacon.net/herramientas/gestion-proyectos-ejemplos/
Gmez, A. y Ania, I. (2008). Introduccin a la computacin. Mxico: Cenage Learning.
Humphrey, W. (1999). Introduction to the Team Software Process. Massachusetts:

Addison Wesley Professional.
Kuna, H., Caballero, S. et al. (2008). Plan de Riesgos para la implementacin de

componentes de web 2.0. Recuperado de
http://www.amicus.udesa.edu.ar/documentos/6jornada/documentos/pdf/PONENCIA%
20MISIONES%20RIESGOS%20web2.0.pdf
Nord, Robert, McHale, J., & Bachmann, F. (2010). Combining Architecture-Centric

Engineering with the Team Software Proces. Pensilvania: Carnegie Mellon University
34

Olivera Sosa, . G. (2010). Planificacin y modelado. Escrcega: 2010.
Osorio, H. R. (2010). Roles en TSP. [En lnea]

http://es.slideshare.net/hansellramos/roles-para-t-s-p
Piattini, V. (2011). Calidad de sistemas de informacin. Mxico: AlfaOmega/Ra-ma.
Queensland, T. U. (2010). Lecture 14: The Team Software Process. CSSE3002 The
Software Process. Recuperado de
http://itee.uq.edu.au/~csse3002/Lectures/Lect14.pdf
Real Academia Espaola (2009), Diccionario de la lengua espaola, 22a. ed.

Recuperado de http://lema.rae.es/drae/?val=equipo
Secretara Central de ISO. (2005). Norma Internacional ISO 9000:2005. Sistemas de

gestin de la calidad. Fundamentos y vocabulario. Ginebra: ISO. Recuperado de
http://www.congresoson.gob.mx/ISO/normas/ISO-90002005_Fundamentos_y_Vocabulario.pdf
Sommerville, I. (2006). Ingenieria de software. Madrid: Pearson Educacin.
Trujillo, D. (2009). Team Software Process. [Mensaje de un blog]. Recuperado de

http://dtrujilloa-tsp.blogspot.mx/
Tuya, Javier; Ramos Romn, Isabel & Dolado Cosn, Javier (2007). Tcnicas
cuantitativas para la gestin en la ingeniera del software. La Corua, Espaa:
Netbiblo
Bibliografa de la imagen:
Dreamstime (2013). Engranajes del asunto. Recuperado de:

http://thumbs.dreamstime.com/x/engranajes-del-asunto-28681457.jpg
Fecha de consulta: 5 de junio del 2013
35

Unidad 1. Introduccion A TSP

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Unidad 1. Introduccion A TSP

Încărcat de

Drepturi de autor:

Formate disponibile

Desarrollo de software en equipo (TSP )

Unidad 1. Introduccin a TSP

Ingeniera en Desarrollo de Software

Unidad 1. Introduccin a TSP

Universidad Abierta y a Distancia de Mxico

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP )

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP )

Relacin entre PSP y TSP

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP )

Identificar los elementos y objetivos que componen la metodologa TSP.

Comprender la estrategia que sigue TSP para el desarrollo de sistemas de calidad.

Identificar la metodologa Team Software Process (TSP) para comprender los

1. 1. Proceso de Desarrollo de Team Software Process (TSP)

Anlisis y definicin de requerimientos: es muy importante conocer qu desea el

Desarrollo de software en equipo (TSP )

Diseo del sistema y el software: los analistas e ingenieros de software establecen

Implementacin y prueba de unidades: prcticamente, en esta fase se desarrolla

Integracin y pruebas del sistema: aqu se observa ya un producto terminado. Las

En la siguiente figura se muestra una representacin del modelo en cascada:

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP )

Desarrollo de software en equipo (TSP )

Administracin autodirigida para equipos de trabajo. Como ya se mencion, a

1.1.1. Principios y objetivos de TSP

Desarrollo de software en equipo (TSP )

buen ambiente de trabajo y que en todo momento exista comunicacin y retroalimentacin

1.1.2. Estrategia de TSP

Desarrollo de software en equipo (TSP )

1.1.3. Equipo TSP

Debe estar formado por al menos dos personas.

Para conformar un equipo efectivo de ingenieros se necesita que:

Desarrollo de software en equipo (TSP )

Los integrantes estn cualificados con las capacidades y habilidades propias de su

Para formar el equipo de trabajo se deben de dar las siguientes condiciones:

1.2. Estructura del Team Software Process (TSP)

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP )

En la siguiente figura se muestra la estructura de TSP:

En los recuadros de la parte superior de la imagen se encuentra la metodologa que va a

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP )

1.2.1. Disciplina de equipo

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP )

1.2.2. Disciplina de administracin

Prioridad de calidad: en todo desarrollo de software, el principal objetivo debe ser la

Como se puede notar, la disciplina de la administracin se basa en los administradores y en

1.2.3. Disciplina de ingeniera

Desarrollo de software en equipo (TSP )

1.3. Ciclo de vida del Team Software Process (TSP)

Desarrollo de software en equipo (TSP )

1.3.1. Fase de lanzamiento

Desarrollo de software en equipo (TSP )

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP )

Gmez y Ania, 2008

Gmez y Ania, 2008

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP )

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software